Avidemux Forum

Avidemux => Main version 2.6 => Topic started by: butterw on February 17, 2021, 10:34:23 AM

Title: Avidemux2.7.9-dev version (old thread)
Post by: butterw on February 17, 2021, 10:34:23 AM
EDIT: This is not the current dev version thread.

This thread is exclusively for feedback/info (features/bugs) about the dev versions of Avidemux v2.7
https://github.com/mean00/avidemux2

Latest dev builds (x64) http://www.avidemux.org/nightly/
The win64 builds (cross-compiled with MinGW) are also provided as ZIP archives.
ffmpeg version (https://github.com/mean00/avidemux2/blob/master/cmake/admFFmpegVersion.cmake)

updated to FFmpeg v4.4:
- 210611 mouse wheel hover over thumb scroller now works. new: cut prev/next point display, ! toolbar buttons change.
- 210510

based on FFmpeg v4.2.4 (x264 core 155):
- 210426 new: Filters can be disabled. !!! in this version disabled filters are enabled with the project script save.
- 210326
- v2.7.8 Mar 06 2021 +fix for some hevc .ts files
- v2.7.7 Mar 04 2021
- 210215 linux/mac: doesn't have the new time display LCD font.

Known issues:
- [Win/video output: dxva2] GUI becomes unresponsive when video frame rate (ex:59.94fps) is close to monitor refresh rate (ex: 60Hz).

Release Changelog (https://files.videohelp.com/u/295418/Avidemux_changelog.txt)
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on February 17, 2021, 10:49:00 AM
In the Color Temperature Filter, the second parameter is called "U-V plane angle of Attack" (range [0-180] with a default value of 30).

Is this some kind of Tint adjustment ? If so, that would be a better name...
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on February 17, 2021, 11:05:00 AM
Yes, it is the hue angle. Looks like a trap for translators.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on February 18, 2021, 02:26:10 AM
The Color Temperature filter do shear mapping along the UV plane in the YUV 3D space. The amount is set be the Temperature, the direction is set by the Angle. That 30 deg direction happens to connect the yellow and the blue areas of the chroma plane.
I dont think that hue (==rotating the chroma plane) would be the most accurate replacement, but feel free to change it :)
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on February 18, 2021, 09:17:40 AM
Would UV angle be OK ?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on February 18, 2021, 10:36:10 AM
"Chroma angle"? "Chroma transformation angle"?

Quote from: szlldm on February 18, 2021, 02:26:10 AMI dont think that hue (==rotating the chroma plane) would be the most accurate replacement

But it is effectively modifying hue + saturation in one step, no?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on February 18, 2021, 10:46:15 AM
It is incredibly important to get wording, grammar, case and punctuation right from the start on, before translators – myself included – submit updates. Later changes mean that the hell of identifying and often manually fixing all affected translations ensues, including languages I have no idea about.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on February 18, 2021, 12:56:52 PM
The description of artPixelize needs a fix too. It cannot be just "Pixelize" as lrelease will create just a single source for both the name and description.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on February 22, 2021, 03:18:27 PM
In the Crop GUI, the position of the Autocrop button between OK and Cancel seems odd. It would be more logical to place it to the Right of the Reset Button.

Edit: Also AutoCrop on black borders often comes up 2 pixels short on both sides ex: 640x480 input, Autocrop top/bottom:58 vs real: 60.




Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on February 22, 2021, 03:54:01 PM
Quote from: butterw on February 22, 2021, 03:18:27 PMn the Crop GUI, the position of the Autocrop button between OK and Cancel seems odd.

So does Qt following platform guidelines. We have no say in that.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: budda on February 26, 2021, 07:58:41 AM
1) Can Avidemux get QAAC support? Officially its seems copyright protected, so software cant be packed with it. But possible for custom support like in foobar- if exists in folder= use it, add some option for it. QAAC q wins vs FDK aac.
Presets example (at least possible can be helpful to somebody):
.aac for video ~200kb/s --tvbr 91 --ignorelength --adts --gapless-mode 1 - -o %d
.m4a iTunes Standart ~128kb/s -s -a 128 -q 1 --ignorelength - -o %d
.m4a iTunes Plus ~256kb/s -s -v256 -q 2 --ignorelength - -o %d
.m4a Alac -s -A --ignorelength - -o %d

2) Good if will be more that 1 default preset.
3) If working with many files but need use same resize same eq presets how possible save it like preset or?
4) VHS is great! But is possible to add tint filter but by mask. I mean mask for shadows or highlights or midtones. Coloring by mask its really cool thing for film effects or some other creative ideas.
5) Connect Avidemux with Reaper daw can be great idea at this time.



Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 01, 2021, 02:50:22 PM
in r210228_win64Qt5_54 portable:
! I'm getting a weird "digital clock" style font in the time display. 
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 01, 2021, 04:07:21 PM
Same here. It's hard to read. It's much better if set to bold.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 04:32:14 PM
Quote from: szlldm on March 01, 2021, 04:07:21 PMIt's much better if set to bold.

This option has been carefully evaluated and discarded as the E1234 font, now bundled with Avidemux, doesn't have a native bold variant and synthetic emboldening doesn't match the gradients of fonts elsewhere in the GUI.

The digital clock design solves the long-standing issue of variable width font used to display rapidly changing numbers. This was causing shifting during playback, especially bad in on-the-fly filter preview. In absence of a viable solution with platform-specific monospace fonts, this one makes IMHO a lot of sense from usability and design POV.

Quartz watches with liquid crystal displays were an incredible hype in the days of my youth, so I am used to the look. It may be slightly more difficult to read in stop mode, but I think it is vastly better readable during playback (at least I could hardly read the display before this change).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 04:47:40 PM
To clarify the choice, here are the requirements:

1. Fixed width, so no shifting

2. Available on every target platform (Linux, macOS, Windows from 7 on)

3. If we cannot rely on a platform-specific font, then the font must have a compatible license allowing redistribution and bundling.

4. Nice to have: small size as we need just 12 characters.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 01, 2021, 05:10:38 PM
This new font looks awful on Windows, is there a way to override it ?
If not I'll have to stick with dev version r210215_.





Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 05:12:08 PM
Quote from: butterw on March 01, 2021, 05:10:38 PMis there a way to override it ?

By building your own patched version of Avidemux.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 01, 2021, 05:14:10 PM
This is a major issue I think.
There should at least be a way to override to keep Avidemux usable until a better solution can be found.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 05:15:16 PM
If too many users on Windows complain, I have no issue with making it Linux- and macOS-only as I have no personal reason to want it this way or another on Windows.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 05:26:28 PM
Quote from: butterw on March 01, 2021, 05:14:10 PMThere should at least be a way to override to keep Avidemux usable

Please don't exaggerate.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 01, 2021, 06:53:56 PM
- I've never noticed the issue this is supposed to address, does it exist on Windows ?
- There are plenty of popular cross-platform GUIs, it's hard to believe this is the best available option.
- Avidemux is a mature GUI that hasn't seen a interface change in years, most users are probably not new users, so any change has to provide a clear improvement. Without a doubt this LCD font looks a lot worse than what was available previously. It's very hard to read (on Windows) despite being a much larger font size.

- Why not make the font for The GUI user customizable ?
There are certainly better fonts available on Windows (including the platform fonts).


 


Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 06:58:46 PM
It turns out to be that whatever default font is used on Windows 10 (Segoe UI?), the digits are actually monospaced thus avoiding shifting. This renders the use of a custom monospace font to fix shifting a solution in search of a problem on Windows, so I've made it macOS- and Linux-only (https://github.com/mean00/avidemux2/commit/94562282a88f2e019a4758ad8b0d0aef04da1d6d).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 08:12:02 PM
Quote from: butterw on March 01, 2021, 06:53:56 PMAvidemux is a mature GUI that hasn't seen a interface change in years, most users are probably not new users, so any change has to provide a clear improvement.

This was the reason to introduce the solution with the custom font as it is an improvement over variable-width fonts (except of on the majority platform, which is now sorted out).

Quote from: butterw on March 01, 2021, 06:53:56 PMWithout a doubt this LCD font looks a lot worse than what was available previously.

Sorry, I don't agree. It fits well the thumb slider, even more resembling a physical device interface (which I value a lot).

Quote from: butterw on March 01, 2021, 06:53:56 PM- Why not make the font for The GUI user customizable ?

IMHO, all interfaces should inherit the system-wide font choices whenever possible for the sake of consistency. Time display in Avidemux is a special case as it has to deal with rapidly changing content which may pose a problem with variable width fonts so it generally makes sense to hardcode it to a custom solution as I didn't find a satisfactory platform-specific solution with available monospace fonts.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 01, 2021, 09:02:13 PM
Looking at screenshots, it looks like the bottom part of the LCD font isn't displaying correctly on my Windows system, making it very hard to read. I haven't seen screenshots on linux/mac so I'll reserve my judgment on whether it can be an improvement there.
A lot of this is subjective of course, still with a wide range of display sizes, and with different user expectations as to what an editor GUI should look like, it would probably be a lot safer to make the fonts user configurable (on Windows at least, this is a very common GUI feature).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 09:22:48 PM
I've made a screenshot, attached to this post, what time display looks like on my desktop with E1234 font.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 01, 2021, 10:16:38 PM
GUI text is displayed a lot smaller on my system apparently (Win10 @1080p), and the bottom of the LCD font is like chewed, which makes it unreadable. Might be caused by the ClearType text tuner ?

From your screenshot, it looks OK but a bit weird. A normal font with monospace digits would be more readable.


Note: Attachments are only visible if you are logged in, it seems.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 01, 2021, 10:53:19 PM
Quote from: butterw on March 01, 2021, 10:16:38 PMA normal font with monospace digits would be more readable.

From purely utilitarian POV, probably yes, but this solution has a benefit of maximally reducing flicker and provides a reference to physical world (thinking about digital recorders with such displays). A "normal" fixed width font looks somewhat inconsistent and usually has a zero with a central slash or dot, very helpful for coding but alien to normal users. Already tried that.

Anyway, I acknowledge that the issue of rapidly shifting text doesn't affect Windows 10 with the default font, so Windows users of the release version won't get to see a digital clock look.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: budda on March 02, 2021, 01:59:27 PM
Possible on modern monitors font looks too small. So need better type of report: monitor size ``, screenshot.
My monitor 24`` Dell 1920x and visually all fine. Possible need just 2x view mode for modern large monitors.

Testing last beta few days, after coding a lot of video was see just minor problem. Once program was running using total 4GB+ of ram (even when i closed video but keep program open). After restart all become normal, and wasnt repeat again. (Task Manager> Program avidemux.exe was 300mb+ like always but total ram used was displays as 5.1GB Ram used.  Also sometimes when loading large file from HDD, HDD start work very loud on Win7 and slow. Reboot helps. And main windows on fast SDD. If log need i can send it.

Small features that can be useful- copy paste timecode (copy now possible but not paste). If loaded few segments of video need some neutral visual marker to view transient position.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 02, 2021, 04:07:56 PM
The new font is much better. Thanks!
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 02, 2021, 05:27:34 PM
Thank you for pointing me to DSEG fonts. It was an epic effort for a first-time FontForge user like me to adapt one of these fonts to the needs of Avidemux, however :-)
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 02, 2021, 05:44:33 PM
Quote from: budda on March 02, 2021, 01:59:27 PMPossible on modern monitors font looks too small. So need better type of report: monitor size ``, screenshot.
My monitor 24`` Dell 1920x and visually all fine. Possible need just 2x view mode for modern large monitors.

Avidemux uses autoscaling feature of the Qt toolkit. Unless the user tweaks dpi value, Qt should magnify all elements of the GUI if necessary. Font size should match the default font size specified by the operating system.


Quote from: budda on March 02, 2021, 01:59:27 PMSmall features that can be useful- copy paste timecode

The code looks like this feature was present at some time in the past or started and not completed. On my radar for future versions.

Quote from: budda on March 02, 2021, 01:59:27 PMIf loaded few segments of video need some neutral visual marker to view transient position.

Visual display of segment layout atop of navigation bar may be evaluated in the future.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 02, 2021, 06:02:42 PM
Quote from: eumagga0x2a on March 02, 2021, 05:44:33 PM
Quote from: budda on March 02, 2021, 01:59:27 PMPossible on modern monitors font looks too small. So need better type of report: monitor size ``, screenshot.
My monitor 24`` Dell 1920x and visually all fine. Possible need just 2x view mode for modern large monitors.

Avidemux uses autoscaling feature of the Qt toolkit. Unless the user tweaks dpi value, Qt should magnify all elements of the GUI if necessary. Font size should match the default font size specified by the operating system.

Does Avidemux or Qt have a custom dpi scaling option (if so how to specify it ?), or does it use the system setting ?

Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 02, 2021, 06:48:22 PM
On Windows, Qt should obey the scale factor set for each display in system settings. You can disable autoscaling by setting env var QT_ENABLE_HIGHDPI_SCALING to 0 or force a particular value using QT_SCALE_FACTOR (I think any non-integer values look horribly).

https://doc.qt.io/qt-5/highdpi.html
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 02, 2021, 07:15:10 PM
Setting the windows env variable QT_SCALE_FACTOR to a value greater than 1 scales all elements of the interface including the font.
On my system the text looked OK at 1.1, but the icons/layout did look somewhat ugly. 2 is HUGE.

It would be good if it was possible to scale only UI font size, without changing system settings.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 02, 2021, 07:35:55 PM
On Linux at least, there is a rather poorly documented env var QT_FONT_DPI. You could try whether it has any effect on Windows.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 02, 2021, 08:09:09 PM
Quote from: eumagga0x2a on March 02, 2021, 07:35:55 PMOn Linux at least, there is a rather poorly documented env var QT_FONT_DPI. You could try whether it has any effect on Windows.

Works for me. The default was 96*1.25x=120. Setting it to 125 provides a boost to the text size.

EDIT: it seems the effect is not the same for different versions of Avidemux though ?
OK for r210228_win64Qt5_54, but doesn't affect VC++ x64 210216_.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 03, 2021, 11:56:49 AM
Quote from: budda on March 02, 2021, 01:59:27 PMOnce program was running using total 4GB+ of ram (even when i closed video but keep program open)

It would be helpful to know which kind of operation resulted in high memory usage or memleak, i.e. the type and codecs used in the source video, the decoder in use, the filter chain, the encoder, the output container.

I presume you were using the latest nightly.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 03, 2021, 11:57:49 AM
Quote from: butterw on March 02, 2021, 08:09:09 PMit seems the effect is not the same for different versions of Avidemux though ?
OK for r210228_win64Qt5_54, but doesn't affect VC++ x64 210216_.

The VC++ build node uses a version of Qt too old for that.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 03, 2021, 10:47:13 PM
Quote from: eumagga0x2a on March 02, 2021, 05:44:33 PM
Quote from: budda on March 02, 2021, 01:59:27 PMSmall features that can be useful- copy paste timecode
The code looks like this feature was present at some time in the past or started and not completed. On my radar for future versions.
Go to time: Ideally it should be able to paste timecode from the clipboard in timecode OR tinyPy pts format.

Quote from: eumagga0x2a on March 02, 2021, 05:44:33 PM
Quote from: budda on March 02, 2021, 01:59:27 PMIf loaded few segments of video need some neutral visual marker to view transient position.

Visual display of segment layout atop of navigation bar may be evaluated in the future.
+1 for display, navigation and selection of segments.     
The graduations displayed currently don't seem to serve any purpose.



Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 04, 2021, 12:14:00 PM
Avidemux v2.7.7 x64 Mar 04 2021 test build is available.

The cross-compiled Win64 version uses Qt v5.15.0
VC++ 210216_ was using Qt 5.12.5 (doesn't support QT_FONT_DPI)
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: budda on March 05, 2021, 06:07:41 PM
How in Avidemux reduce using CPU ? If i dont want 100% cpu load to keep cores in safe what to do?
I member that for example x*ilisoft allows enable custom cores that can be used for coding. Some old good software like S*orenson Squeeze was create number of renders depend on numbers of cores, also allow set priority for coding process.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 05, 2021, 07:08:34 PM
You can set CPU affinity for avidemux.exe in Windows task manager. Encoding process priority has nothing to do with limiting CPU usage, it can be set in Avidemux in encoding dialog.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 05, 2021, 07:26:53 PM
- Encode with process priority set to low: if you are using the computer at the same time it helps keep the system responsive but also reduces the load because other tasks aren't as intensive.
- At system level on windows, you can limit to 95% in power plan >perf options.
- Encoders have options to control the number of threads/cores they use.
 
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 05, 2021, 08:08:35 PM
The ability to throttle maximum CPU load per application may be desirable in poorly designed consumer devices with insufficient cooling like most of laptops are.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: budda on March 06, 2021, 02:52:04 PM
- Was make test render with same settings. Input 1080p resolution output 702x302
Avidemux_2.7.8 r210306 = cpu load 99-100% vs old 2.7.5 Cpu load 40-50 but coding speed slower ~1.5x.
Seems new Avidemux good for modern Cpu and old for old.)

- I hope subtitles plugin gets realtime preview instead of reopen each time preview after edit.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 09, 2021, 08:31:54 PM
Quote from: budda on March 06, 2021, 02:52:04 PMAvidemux_2.7.8 r210306 = cpu load 99-100% vs old 2.7.5 Cpu load 40-50 but coding speed slower ~1.5x.

Could be the effect of multi-threaded decoding in the new or single-threaded encoding in the old version. Unless overheating is the problem, it makes no sense not using 100% per CPU core during encoding with a software encoder like x264. However, you should set the priority of the process to low in order to avoid slowing down other tasks.

Quote from: budda on March 06, 2021, 02:52:04 PMSeems new Avidemux good for modern Cpu and old for old.)

No, not at all.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 11, 2021, 06:07:17 AM
Quote from: eumagga0x2a on March 09, 2021, 08:31:54 PM
Quote from: budda on March 06, 2021, 02:52:04 PMAvidemux_2.7.8 r210306 = cpu load 99-100% vs old 2.7.5 Cpu load 40-50 but coding speed slower ~1.5x.

Could be the effect of multi-threaded decoding in the new or single-threaded encoding in the old version.
I have similar experience (AMD Ryzen 5 2400G, Xubuntu 20.04):
A have actually never found out, why converting movies recorded from DVBT-2 (conversion from H265 1920x1080, 50FPS to x264 960x540, 50FPS) always worked only on 25-32% CPU with Avidemux 2.7.5. And other movies downloaded from the internet (so various codecs and FPS) I could convert also to x264 using 90% CPU. As a workaround when I convert DVBT-2 files, I convert 3 different files at once.
Now with Avidemux 2.7.8 the multithread conversion is faster for one file, but less efficient (CPU consumption is 3 times higher but conversion is just 2 times faster).
Overheating is not problem for my computer and I also do not have any troubles with running another processes - just the efficiency surprised me.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 11, 2021, 12:16:01 PM
With a HEVC source it might be beneficial to use even VA-API hw accel (it is almost for sure beneficial to use VDPAU if you have an NVIDIA graphics card). You didn't clarify whether this option is available for you.

The problem with VA-API is the terribly inefficient NV12 to yuv420p / YV12 pixel format conversion. With VDPAU, we get yuv420p right away from the driver.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 11, 2021, 12:58:56 PM
Just tested NV12 conversion in dummyVideoFilter::getNextFrame, with
image->convertToNV12(..);
image->convertFromNV12(..);
roundtrip i get >350fps with 720p source (sw decoded).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 11, 2021, 03:14:47 PM
Quote from: eumagga0x2a on March 11, 2021, 12:16:01 PMWith a HEVC source it might be beneficial to use even VA-API hw accel (it is almost for sure beneficial to use VDPAU if you have an NVIDIA graphics card). You didn't clarify whether this option is available for you.
If I look to Preferences - HW Accel there are only VDPAU (NVIDIA) and LIBVA (Intel) options. Both of them produce broken output so I do not use them.
This is the same for

BTW: I can use VA-API on my system, it works with mpv and ffmpeg version 4.2.4-1ubuntu0.1. But I do not know how to set ffmpeg to produce output file with similar size as Avidemux can (setting up ffmpeg is magic for me so I use Avidemux instead).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 11, 2021, 04:01:32 PM
Minor GUI issue (with Win64Qt5 v2.7.8) with filters that don't have a configure GUI:
- the option is still present in the menu when they are added to the filter chain (configure menu entry should be disabled).
- Configure Button is enabled when they are made partial


Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 11, 2021, 06:04:25 PM
Quote from: signy13 on March 11, 2021, 03:14:47 PMIf I look to Preferences - HW Accel there are only VDPAU (NVIDIA) and LIBVA (Intel) options. Both of them produce broken output so I do not use them.

Why didn't you report this right away, at least the libva part? Could you please build Avidemux off the current git master yourself instead of using an appImage and check whether VA-API / libva hw accelerated decoder for H.264 works? If it doesn't work either, please redirect Avidemux stdout and stderr to a file and attach this file to your reply.

It might be better to start a new topic for that.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 11, 2021, 06:06:52 PM
Quote from: butterw on March 11, 2021, 04:01:32 PMMinor GUI issue (with Win64Qt5 v2.7.8) with filters that don't have a configure GUI:
- the option is still present in the menu when they are added to the filter chain (configure menu entry should be disabled).
- Configure Button is enabled when they are made partial

This is not a GUI issue but an API shortcoming. There is no way to know whether a filter has a real configuration dialog. All filters have a configure function by API requirement, it may just return 1 and do nothing.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 17, 2021, 08:09:50 AM
Quote from: eumagga0x2a on March 01, 2021, 10:53:19 PM
Quote from: butterw on March 01, 2021, 10:16:38 PMA normal font with monospace digits would be more readable.

From purely utilitarian POV, probably yes, but this solution has a benefit of maximally reducing flicker and provides a reference to physical world (thinking about digital recorders with such displays). A "normal" fixed width font looks somewhat inconsistent and usually has a zero with a central slash or dot, very helpful for coding but alien to normal users. Already tried that.
I can see your point. At first I found the font weird but somehow cool.
Now, after days of using Avidemux it got worse - I noticed that for me is quite difficult to read it (to recognize the time) and I would appreciate "normal" monospaced font much more.

I looked for monospaced font on my system and there are couple of them with GNU or SIL Open Font License.
From these fonts I like the Noto Mono the most, it has very good readability in my opinion (and its size is 108kB).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 21, 2021, 06:06:18 AM
I changed files ADM7SEG.* in avidemux2/avidemux/qt4/ADM_userInterfaces/ADM_gui/fonts/with font NotoMono-Regular.ttf (I created SFD file in Font Forge) and I an happy with the result (you can see screenshot in the attachment).
It would be great if other users have an option to change the LCD font without compilation from source.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 21, 2021, 12:53:26 PM
At very small font sizes and with the fallback Qt style (i.e. "windows" instead of "fusion") the LCD font becomes indeed difficult to read. Below two screenshots as attachments – how it is supposed to look (how I see it on my desktop, Cantarell 11 pt + fusion Qt style) and how it looks with DejaVu Sans 10 pt + windows Qt style.

Readable:
avidemux-time-display-lcd-style.png

Not so much:
avidemux-time-display-tiny-fonts-qt-windows-style.png
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 21, 2021, 01:18:29 PM
You managed to find some very old or modified version of the font. The modern Noto Sans Mono, provided by some Linux distributions (however not by default), is very different. Old or new, it looks out of place at larger font sizes for me (the big reason I looked for a concept which would justify the font looking different).

Glad you found a solution for you, but I would politely ask you to rename the font (simple find and replace does the trick) if you redistribute it.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: budda on March 21, 2021, 03:16:18 PM
Memory leak wasn't avidemux issue. Other time torrent client brings same issue until get restarted. Seems reason is custom Windows tweaks for performance or memory got bad sectors.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 22, 2021, 06:00:36 AM
Quote from: eumagga0x2a on March 21, 2021, 12:53:26 PMAt very small font sizes and with the fallback Qt style (i.e. "windows" instead of "fusion") the LCD font becomes indeed difficult to read.
For me is the LCD font always difficult to read - for example number 4 looks quite different from "normal" 4 etc. Even 0 broken into pieces... It is very different from everything I can see on my desktop and this is probably the reason of bad readability.

Quote from: eumagga0x2a on March 21, 2021, 01:18:29 PMYou managed to find some very old or modified version of the font. The modern Noto Sans Mono, provided by some Linux distributions (however not by default), is very different.
I can not agree. I do not know how or when I got the NotoMono-Regular.ttf font so I tried to download it from 2 sites:
https://www.fontsquirrel.com/fonts/noto-mono
https://www.google.com/get/noto/#mono-mono
and did md5sum check - two downloaded files are exactly the same as the one I found in my system so I consider it as up-to-date.

Quote from: eumagga0x2a on March 21, 2021, 12:53:26 PMOld or new, it looks out of place at larger font sizes for me (the big reason I looked for a concept which would justify the font looking different).
It might be about difference between chosen system font and the time font in Avidemux. My default font "Sans regular" looks very similar to the NotoMono-Regular.ttf so it is OK for me.
How difficult it would be to give users a setting in Preferences, where everyone could choose their preferred font for the time field?
Dealing with Qt5 on my computer to be able to compile Avidemux took me a half a day and for most users is their own compilation just "mission impossible".

Quote from: eumagga0x2a on March 21, 2021, 12:53:26 PMGlad you found a solution for you, but I would politely ask you to rename the font (simple find and replace does the trick) if you redistribute it.
Good point. I just did what was the easiest way to fix what made my Avidemux using difficult (without necessity to change actual source code).
I have no intention to spread my compiled Avidemux (well, maybe except my girlfriend's computer). But if I wanted to share my compiled version with someone else, I'll do it in the proper way as you mentioned.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: budda on March 22, 2021, 11:11:12 AM
Quote from: signy13 on March 22, 2021, 06:00:36 AMNotoMono-Regular.ttf font
Language Support is good but at now most optimal font is Roboto.
- Comes from android to windows,
- Have good look if small,
- Many where used also for subtitles,
- Used by popular streams like YouTube.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 24, 2021, 12:22:50 AM
Quote from: signy13 on March 22, 2021, 06:00:36 AMDealing with Qt5 on my computer to be able to compile Avidemux took me a half a day and for most users is their own compilation just "mission impossible".

Could you please explain? On my Fedora Workstation it is just the question of installing two packages (qt5-qtbase-devel and qt5-linguist) which pull in all necessary Qt5 dependencies and you are set, ready to build and run Avidemux. Same on Debian Buster and on Ubuntu.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 24, 2021, 11:02:05 AM
Quote from: eumagga0x2a on March 24, 2021, 12:22:50 AM
Quote from: signy13 on March 22, 2021, 06:00:36 AMDealing with Qt5 on my computer to be able to compile Avidemux took me a half a day and for most users is their own compilation just "mission impossible".

Could you please explain? On my Fedora Workstation it is just the question of installing two packages (qt5-qtbase-devel and qt5-linguist) which pull in all necessary Qt5 dependencies and you are set, ready to build and run Avidemux. Same on Debian Buster and on Ubuntu.
Well it is quite off topic, I am sorry I mentioned that. I have had to update Qt5 for another software some time ago but this version had some missing files while compiling Avidemux (I found that other people have the same problem too). I downgraded Qt5 and it started working again.
The point is that compiling software is for most of users too difficult task and it would be nice if all users had an option to change the LCD font to some other monospaced font without compilation.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 24, 2021, 04:18:27 PM
Quote from: signy13 on March 24, 2021, 11:02:05 AMThe point is that compiling software is for most of users too difficult task and it would be nice if all users had an option to change the LCD font to some other monospaced font without compilation.

Agree 100%.  Don't you hate developers and programmers who seem to think that all their users must also be programmers, even though in real life there are probably 99% "just plain users" and 1% programmers, if that?

Any developer that thinks that all their users are able to (re)compile software needs a serious reality check.  That is true for any platform, but especially for Windows and MacOS users.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 26, 2021, 11:17:40 AM
210326 nightly is available

- Peek Original button has been added in the configure UI of some filters (in some cases it replaces side-by-side view).

! There should be a spinbox displaying the values of the parameters in the configure UI after the slider, it is missing in some of the new filters.

Some links to available documentation for new filters would probably be helpful (add to release notes ?).




Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 26, 2021, 08:50:47 PM
QuoteThere should be a spinbox displaying the values of the parameters in the configure UI after the slider, it is missing in some of the new filters.

They were left out deliberately, because most of the time their actual values have no meaning, rather the user change them through visual feedback.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 26, 2021, 09:10:35 PM
2.7.9 developement, 210326 nightly is available

New filters:
-Posterize
-Blur
-Chroma hold
-Mirror
-Chroma key
-Cartoon
-Dynamic threshold
-Analyzer
-Fit to size
-Grid
-Color balance
-Wavelet Sharpening
-Wavelet Denoising
-DelogoHQ
-Luma stabilizer


New features:
-Resample FPS now has a blending frames option
-Most of filters with preview now have a "Peek Original" button, to quickly compare input and filtered frames
-Shortcuts for filter manager operation (move up/down, make partial)

+Bugfixes

Feedbacks are welcome!
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 26, 2021, 09:47:55 PM
Quote from: szlldm on March 26, 2021, 08:50:47 PM
QuoteThere should be a spinbox displaying the values of the parameters in the configure UI after the slider, it is missing in some of the new filters.

They were left out deliberately, because most of the time their actual values have no meaning, rather the user change them through visual feedback.

The issue is that parameter values are not displayed with only the sliders.
Spinboxes also allow to set a value.

Visual feedback is not the only valid approach here.

 
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 26, 2021, 11:27:26 PM
Quote from: szlldm on March 26, 2021, 08:50:47 PM
QuoteThere should be a spinbox displaying the values of the parameters in the configure UI after the slider, it is missing in some of the new filters.

They were left out deliberately, because most of the time their actual values have no meaning, rather the user change them through visual feedback.

First of all, wherever did you get that crazy idea?  I ALWAYS want to be able to tweak the values using the numbers.  I may use visual feedback for gross settings but then I switch to the values for tweaking, OR for reusing a value that has worked before in a similar circumstance.  In fact I hate sliders that don't let you tweak up or down in increments of 1 to get to (or back to) a precise setting.  If it were up to me I'd put spinboxes (if that is the correct term, I am talking about the textboxes with numbers that can be adjusted up or down in increments of 1) on everything and omit sliders completely (except on something like moving forwards or backwards in the video; sliders are definitely useful there).

But anyway there apparently is no MacOS version of the new nightly (latest version for Catalina is March 6) so once again I am left out.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 27, 2021, 12:32:46 AM
The sliders can be adjusted in increment of 1, and the numeric value are shown during the adjusment.
But if you realy need some spinboxes, let us know which new filters would you like to have those.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 27, 2021, 01:25:24 AM
Quote from: szlldm on March 27, 2021, 12:32:46 AMThe sliders can be adjusted in increment of 1, and the numeric value are shown during the adjusment.
But if you realy need some spinboxes, let us know which new filters would you like to have those.

Well in order to do that I will need to be able to try the filters to see which one I might actually use, but I can't do that until there is a nightly for MacOS Catalina that includes those filters.  But once there is, I will let you know.  I will say that if DelogoHQ is anything like the current Delogo filter I'll definitely want them there, if they are not there already, and if Blur lets you blur a selected portion of the each frame (rather than just the entire frame) I would want them there as well. Selecting via "rubber bands" or sliders is okay for getting close, but for precision you really need to be able to move in increments of 1 pixel.  But as I said I have not been able to actually see how these filters work yet because there is no MacOS nightly build yet, so maybe those are already covered?

By the way, just as an aside I will just say that at some point in the future you might want to consider making a series of "how to" videos that explain how the various filters work and what the adjustments do, especially for the more complex filters.  Avidemux is the type of program where some things are very intuitive but others, not so much, even down to things like why you might prefer one filter over another for a specific task.  Short explainer videos might be helpful, they don't need to be more than just a few minutes long and don't need to dwell on anything that is already fairly obvious, maybe just enough to cover one filter, or two or three similar filters.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 27, 2021, 03:13:19 AM
QuoteI will say that if DelogoHQ is anything like the current Delogo filter I'll definitely want them there,

These two are very different in handling. The new DelogoHQ is a little bit trickier, therefore there is a Help button with instructions on how to use it. IMHO it worth the extra work to configure the filter.
Compare Delogo2 (left) to DelogoHQ (right) (https://user-images.githubusercontent.com/50839734/111248837-fdc0d480-860a-11eb-9a22-2b42eb6947ac.jpg)
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 27, 2021, 03:18:15 AM
Quote from: szlldm on March 27, 2021, 03:13:19 AM
QuoteI will say that if DelogoHQ is anything like the current Delogo filter I'll definitely want them there,

These two are very different in handling. The new DelogoHQ is a little bit trickier, therefore there is a Help button with instructions on how to use it. IMHO it worth the extra work to configure the filter.
Compare Delogo2 (left) to DelogoHQ (right) (https://user-images.githubusercontent.com/50839734/111248837-fdc0d480-860a-11eb-9a22-2b42eb6947ac.jpg)

Wow, that is exactly what I have been hoping for.  Any chance you can build a MacOS Catalina nightly soon?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 27, 2021, 03:33:14 AM
QuoteAny chance you can build a MacOS Catalina nightly soon?

I'm just a user/contributor, i have no influence on that.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 27, 2021, 04:29:32 AM
Quote from: szlldm on March 27, 2021, 03:33:14 AM
QuoteAny chance you can build a MacOS Catalina nightly soon?

I'm just a user/contributor, i have no influence on that.

Okay, thanks anyway.   eumagga0x2a is this something you could do?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 27, 2021, 04:38:26 AM
Quote from: Who on March 26, 2021, 11:27:26 PM
Quote from: szlldm on March 26, 2021, 08:50:47 PM
QuoteThere should be a spinbox displaying the values of the parameters in the configure UI after the slider, it is missing in some of the new filters.

They were left out deliberately, because most of the time their actual values have no meaning, rather the user change them through visual feedback.

First of all, wherever did you get that crazy idea?  I ALWAYS want to be able to tweak the values using the numbers.  I may use visual feedback for gross settings but then I switch to the values for tweaking, OR for reusing a value that has worked before in a similar circumstance.

There is another case when field for tweaking numbers is very useful - automation. For example I wrote a scripts which manipulates with a value in an opened Mplayer Delogo filter. This is quite easy when the script can just change numbers in a particular field. The same task is probably much more complicated (if not impossible) when sliders are the only way how to change values.
And for me personally is also very convenient to be able to set values by editing numbers (instead of interacting with a mouse) - a lot of people are used to use a keyboard much often then the mouse and they can be faster and more precise in comparison with using the mouse.

BTW it would be very convenient if there was alternative way how to set a mask for DelogoHQ filter in the same way as in Mplayer Delogo filter (when simple rectangle is sufficient). Being forced to create a picture with an appropriate mask makes creation of multiple delogo filters very tedious...
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on March 27, 2021, 11:44:50 AM
In all filters with a simple slider layout, there should be always be an associated spinbox when the parameter is integer or float, there is no reason not to.
Ex: Sharpness\Blur, Colors\Color Temperature, Colors\Hue, Noise\Wavelet denoiser.
Artistic\Cartoon, Artistic\Charcoal, etc.
Also there is an issue in Artistic\Vignette: no tooltips are displayed.

Arguably, it may not be indispensable to have a spinbox when the layout is more complex. For these filters it may be better to find a way to display a tooltip on the slider (currently the sliders don't have value tooltips unless they are moved).

Sliders could be added in Noise\FluxSmooth, Noise\Hqdn3d.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 27, 2021, 04:03:30 PM
Quote from: Who on March 27, 2021, 04:29:32 AMeumagga0x2a is this something you could do?

The refresh of official nightlies was requested a few days ago and the macOS build is the only one not done yet. I have no influence on when exactly and whether at all it happens.

There is a new problem with macOS/Homebrew as the Homebrew maintainers were keen to update Qt to 6.0.2 which requires some (or even a lot of) work to make Avidemux compile. I'm on it now.

Quote from: signy13 on March 27, 2021, 04:38:26 AMThere is another case when field for tweaking numbers is very useful - automation.

The presence or absence of spinboxes doesn't matter at all when the automation is done the proper way by using internal python scripting.

Quote from: butterw on March 27, 2021, 11:44:50 AMIn all filters with a simple slider layout, there should be always be an associated spinbox when the parameter is integer or float, there is no reason not to.

This is quite a pain to implement as we get two linked controls, fighting against each other and threatening to lock up from signal/slot recursion if sloppily coded. I must admit that I do prefer to have both (even for float point values) from usability POV, but I don't like how this looks.

Quote from: butterw on March 27, 2021, 11:44:50 AMAlso there is an issue in Artistic\Vignette: no tooltips are displayed.

This is trivial to add by using our enhanced version of QSlider.

Quote from: butterw on March 27, 2021, 11:44:50 AMcurrently the sliders don't have value tooltips unless they are moved

Bothers me a lot too. Other, more important tasks prevent me from fixing this myself at the moment.

The reason for going with tooltips was to show the value of the slider when there is no space for  anything else whatsoever.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 27, 2021, 05:48:59 PM
A fresh macOS Catalina nightly has been uploaded to https://avidemux.org/nightly/osx_catalina/
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 27, 2021, 06:58:42 PM
Quote from: eumagga0x2a on March 27, 2021, 04:03:30 PM
Quote from: signy13 on March 27, 2021, 04:38:26 AMThere is another case when field for tweaking numbers is very useful - automation.

The presence or absence of spinboxes doesn't matter at all when the automation is done the proper way by using internal python scripting.

As far as I know there is no way how to change one filter according of values from another filter.
For example I have a script, which puts two partial delogo filters. In the next step I configure one of the filters (X, Y, W, H) and put one of values into clipboard (more values would be also possible with another bash script). Then I open the second filter (just the partial dialog) and press a keyboard shortcut which runs an external script (written in bash) which opens the delogo filter and modifies a value (or possibly more values) of the second delogo filter and closes all the dialogues.

But I might be wrong so my question is: is there a way in TinyPy how to change properties of one partial delogo filter according to properties of previous/next partial delogo filter? For example get X and W values from one filter, do some math operation with them and then modify X and W values in previous filter?

From my point of view Avidemux has some limitations (for example no possibility of creating shortcuts for custom scripts) which I can partially remove by writing bash scripts so I do not have to do some repeated actions manually over and over again.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 27, 2021, 11:06:16 PM
Quote from: eumagga0x2a on March 27, 2021, 05:48:59 PMA fresh macOS Catalina nightly has been uploaded to https://avidemux.org/nightly/osx_catalina/
Thanks, much appreciated! I got it and am using it now, although as it happens I don't have anything right now that requires more than just basic processing, so no need to try the new Delogo filter yet (that is the only one I am certain I will be using, just not today).  My videos seem to go in batches, some require only the simplest of processing (basically cutting out extraneous material, and maybe a fade to black at the end or something), and others require a whole lot more, but today I'm doing simple ones.  Anyway, it seems to be working with no issues so far, just waiting to see if it still crashes at the end of some videos.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 28, 2021, 12:55:52 AM
Okay, first real quick comments on the 2.7.9 nightly:

1. It did not crash after the first video.  EDIT: But it did after the second one that I did. :(

2. If there is a way to get rid of those segmented numbers in the time display I am not finding it.

3. Even though I didn't think I would have an need to use a Delogo filter tonight, it turns out I did and of course I immediately found a situation where it doesn't work well. The problem occurs when there is a black border that is immediately adjacent to the bottom of the logo, or if the logo overlaps the black border.  In that case you get a trapezoidal shaped black space inside the logo area.  The only way to avoid it that I could find was to crop the border out BEFORE using the Delogo filter, then it only drew in color from the rest of the frame.  I do like that filter better than the original Delogo filter because you don't see that crosshatch pattern that sometimes occurred with the original.  I guess the only thing I wonder is what are the ideal settings for the blur and gradient for general use (in other words if what you are trying to eliminate is present on the screen through several scene changes), because I tried a few different combinations and none of them seemed to give the best results on every scene.  But using the mask is genius for getting rid of those weird-shaped things you want to eliminate every now and then!

Might have more to say after further usage but those are my initial observations.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 28, 2021, 02:53:10 AM
QuoteI immediately found a situation where it doesn't work well. The problem occurs when there is a black border that is immediately adjacent to the bottom of the logo, or if the logo overlaps the black border.  In that case you get a trapezoidal shaped black space inside the logo area.  The only way to avoid it that I could find was to crop the border out BEFORE using the Delogo filter, then it only drew in color from the rest of the frame.

Basically it works so, that "it eats away" the mask (white blob) by filling the boundary with neighbouring colors. If the area is immediately next to a black border, then it will fill with black color. If the mask  reach the edge of the image (like after you cropped), then it will "eat away" from the known boundaries.

QuoteI guess the only thing I wonder is what are the ideal settings for the blur and gradient for general use (in other words if what you are trying to eliminate is present on the screen through several scene changes), because I tried a few different combinations and none of them seemed to give the best results on every scene.

The Blur parameter controls the blur amount of the mask area, while increasing the Gradient parameter it will blur less near the edge of the mask area, and more at the center.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 28, 2021, 05:59:07 AM
I compiled Avidemux from fresh source yesterday and bumped into a not pleasant change. I have a Mplayer Delogo filter and I configure it by rewriting numbers (for example number in the field X):
In the previous versions (a week old and earlier) of Avidemux the changed number was processed immediately so the red rectangle (showing the filtered area) was redrawn. That was very convenient way of tuning values by a keyboard.

In the current version of Avidemux the change is not processed immediately and I have to do an other action (hit Tab key for example). This change makes this "keyboard tuning" of numerical values worse.
Is it possible to revert this change?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 28, 2021, 06:12:14 AM
Quote from: szlldm on March 28, 2021, 02:53:10 AM
QuoteI immediately found a situation where it doesn't work well. The problem occurs when there is a black border that is immediately adjacent to the bottom of the logo, or if the logo overlaps the black border.  In that case you get a trapezoidal shaped black space inside the logo area.  The only way to avoid it that I could find was to crop the border out BEFORE using the Delogo filter, then it only drew in color from the rest of the frame.

Basically it works so, that "it eats away" the mask (white blob) by filling the boundary with neighbouring colors. If the area is immediately next to a black border, then it will fill with black color. If the mask  reach the edge of the image (like after you cropped), then it will "eat away" from the known boundaries.

QuoteI guess the only thing I wonder is what are the ideal settings for the blur and gradient for general use (in other words if what you are trying to eliminate is present on the screen through several scene changes), because I tried a few different combinations and none of them seemed to give the best results on every scene.

The Blur parameter controls the blur amount of the mask area, while increasing the Gradient parameter it will blur less near the edge of the mask area, and more at the center.


Thanks for clarifying that.  Maybe would be a good idea to add that to the help text.

One other thing I have noticed about the new version, although this is a problem I have seen before, just more rarely:

1. Load a fairly long video

2. Edit out some portion of the video at the start or in the middle.

3  Go to near the end, and mark off a section using the A and B markers.

4. Apply a filter that can be made partial, such as "blacken borders."

5. After creating the filter right click on it to make it partial.  If you are lucky, it will copy the times exactly from the A and B markers.  If you are not, it will have those times offset by roughly the amount of time you edited out, or some fraction thereof.

This makes no sense to me - I mean, after all, the times corresponding to the A and B markers have to be stored or calculated in some way so they display correctly, so why is that time not always transferred precisely when you specify a partial filter?  It almost seems to me as if when you create a partial filter, it pick up the time from the wrong internal variables or something.  If you have not cut out any portion of the original video then the times will always be correct, but if you have made one or more cuts then it is a crap shoot - sometimes the times are correct and sometimes they are not.  But so far, I have been more unlucky in the Avidemux 2.7.9 nightly, because partial filter times have been more consistently wrong tonight.  Is it really so hard to just precisely copy the times from the A and B boxes of the GUI display when creating a partial filter, or is this another issue that nobody sees but me?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 28, 2021, 06:21:26 AM
Quote from: signy13 on March 28, 2021, 05:59:07 AMI compiled Avidemux from fresh source yesterday and bumped into a not pleasant change. I have a Mplayer Delogo filter and I configure it by rewriting numbers (for example number in the field X):
  • I select a digit in the number,
  • I write another number (just press a key on numpad).
In the previous versions (a week old and earlier) of Avidemux the changed number was processed immediately so the red rectangle (showing the filtered area) was redrawn. That was very convenient way of tuning values by a keyboard.

In the current version of Avidemux the change is not processed immediately and I have to do an other action (hit Tab key for example). This change makes this "keyboard tuning" of numerical values worse.
Is it possible to revert this change?

It is not just the Delogo filter. I have noticed the same thing about certain other filters as well.  Can't immediately give a specific example but I do agree that it was handy to see the result of what you have already typed in real time in certain filters.  Blacken borders is one that I know was changed in some way that makes it harder to see the results of the values you have entered, but I think that happened starting in 2.7.8.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 28, 2021, 08:16:55 AM
Quote from: Who on March 28, 2021, 06:21:26 AMIt is not just the Delogo filter. I have noticed the same thing about certain other filters as well.  Can't immediately give a specific example but I do agree that it was handy to see the result of what you have already typed in real time in certain filters.  Blacken borders is one that I know was changed in some way that makes it harder to see the results of the values you have entered, but I think that happened starting in 2.7.8.
I guess it affects more filters of Avidemux, I just did not checked it...
It does not affect Avidemux 2.7.8-210313 (compiled on 13 March).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 28, 2021, 02:38:57 PM
Quote from: Who on March 28, 2021, 06:12:14 AMOne other thing I have noticed about the new version, although this is a problem I have seen before, just more rarely:

1. Load a fairly long video

2. Edit out some portion of the video at the start or in the middle.

3  Go to near the end, and mark off a section using the A and B markers.

4. Apply a filter that can be made partial, such as "blacken borders."

5. After creating the filter right click on it to make it partial.  If you are lucky, it will copy the times exactly from the A and B markers.  If you are not, it will have those times offset by roughly the amount of time you edited out, or some fraction thereof.

Do you add (even temporarily) and preview any filter between steps 1 and 2? If you do, all the values used to calculate the start and end time will be completely off once you perform an edit = modify the duration as they come from the bridge instance (the translation layer between the editor and the filters) which is created only once.

Apart from that, both the code deriving the end time from video duration in the bridge constructor and its usage via createEmptyVideoFilterChain and createVideoFilterChain in GUIPlayback::initialize() are buggy, seem to be easy to fix.

My desperate idea to scale start and end time in the partial filter constructor in case the duration of the video as reported by the bridge and the one reported by the parent filter don't match makes the behaviour of the partial filter even more confusing.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 28, 2021, 02:47:59 PM
Quote from: signy13 on March 28, 2021, 05:59:07 AMI compiled Avidemux from fresh source yesterday and bumped into a not pleasant change. I have a Mplayer Delogo filter and I configure it by rewriting numbers (for example number in the field X):
  • I select a digit in the number,
  • I write another number (just press a key on numpad).
In the previous versions (a week old and earlier) of Avidemux the changed number was processed immediately so the red rectangle (showing the filtered area) was redrawn. That was very convenient way of tuning values by a keyboard.

The old behaviour, the default behaviour of QSpinBox, is called keyboard tracking and I actually dislike it very much as I prefer to fill in the values without the application starting to interpret them prematurally (I feel pressured). However, I do acknowledge that disabling keyboard tracking (https://github.com/mean00/avidemux2/blob/31ad3e68980de389ba7912a40752976aecb0198e/avidemux_plugins/ADM_videoFilters6/mplayerDelogo/qt5/DIA_flyMpDelogo.cpp#L438), contrary to swsResize filter, is not mandatory here and can be reverted without breaking functionality.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 28, 2021, 03:12:57 PM
Quote from: eumagga0x2a on March 28, 2021, 02:38:57 PM
Quote from: Who on March 28, 2021, 06:12:14 AMOne other thing I have noticed about the new version, although this is a problem I have seen before, just more rarely:

1. Load a fairly long video

2. Edit out some portion of the video at the start or in the middle.

3  Go to near the end, and mark off a section using the A and B markers.

4. Apply a filter that can be made partial, such as "blacken borders."

5. After creating the filter right click on it to make it partial.  If you are lucky, it will copy the times exactly from the A and B markers.  If you are not, it will have those times offset by roughly the amount of time you edited out, or some fraction thereof.

Do you add (even temporarily) and preview any filter between steps 1 and 2? If you do, all the values used to calculate the start and end time will be completely off once you perform an edit = modify the duration as they come from the bridge instance (the translation layer between the editor and the filters) which is created only once.

Sometimes I do that and sometimes I don't.  But what I don't understand is that the values shown in the A and B boxes always seem to be correct, and if I manually change the partial filter start and end times to match those then it always works.  So, why can't it just take the times from there rather than this "bridge instance" that you speak of?

Quote from: eumagga0x2a on March 28, 2021, 02:38:57 PMApart from that, both the code deriving the end time from video duration in the bridge constructor and its usage via createEmptyVideoFilterChain and createVideoFilterChain in GUIPlayback::initialize() are buggy, seem to be easy to fix.

My desperate idea to scale start and end time in the partial filter constructor in case the duration of the video as reported by the bridge and the one reported by the parent filter don't match makes the behaviour of the partial filter even more confusing.

You're talking about the internals of the program which I do not understand at all.  All I am saying is that when you go to make a filter partial, it should be getting its times from whatever internal variables provide the time to the A and B boxes in the GUI display, since in my experience those are always correct no matter how many edits you may have made or how many filters you have used.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 28, 2021, 03:17:13 PM
Quote from: eumagga0x2a on March 28, 2021, 02:47:59 PM
Quote from: signy13 on March 28, 2021, 05:59:07 AMI compiled Avidemux from fresh source yesterday and bumped into a not pleasant change. I have a Mplayer Delogo filter and I configure it by rewriting numbers (for example number in the field X):
  • I select a digit in the number,
  • I write another number (just press a key on numpad).
In the previous versions (a week old and earlier) of Avidemux the changed number was processed immediately so the red rectangle (showing the filtered area) was redrawn. That was very convenient way of tuning values by a keyboard.

The old behaviour, the default behaviour of QSpinBox, is called keyboard tracking and I actually dislike it very much as I prefer to fill in the values without the application starting to interpret them prematurally (I feel pressured). However, I do acknowledge that disabling keyboard tracking (https://github.com/mean00/avidemux2/blob/31ad3e68980de389ba7912a40752976aecb0198e/avidemux_plugins/ADM_videoFilters6/mplayerDelogo/qt5/DIA_flyMpDelogo.cpp#L438), contrary to swsResize filter, is not mandatory here and can be reverted without breaking functionality.

I guess that is the difference between people, I don't feel that the premature application of those values is pressuring in any way.  And for some filters, such as blacken borders, it is actually helpful to be able to see the area to be blackened change as you enter or change the numbers.

Maybe this could be made a configurable option so that those who like the old way can have it back?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 28, 2021, 03:23:34 PM
Quote from: eumagga0x2a on March 28, 2021, 02:47:59 PMThe old behaviour, the default behaviour of QSpinBox, is called keyboard tracking and I actually dislike it very much as I prefer to fill in the values without the application starting to interpret them prematurally (I feel pressured). However, I do acknowledge that disabling keyboard tracking (https://github.com/mean00/avidemux2/blob/31ad3e68980de389ba7912a40752976aecb0198e/avidemux_plugins/ADM_videoFilters6/mplayerDelogo/qt5/DIA_flyMpDelogo.cpp#L438), contrary to swsResize filter, is not mandatory here and can be reverted without breaking functionality.
Thank you for your info - as you can see I am just an user without any knowledge of programming (except SQL and a tiny bit of bash or Python scripting).
And thank you very much for enabling the keyboard tracking :-)
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 28, 2021, 03:33:26 PM
There is a misunderstanding, I pointed to the location which disabled keyboard tracking (so that you can instantly change it to your liking). I haven't re-enabled keyboard tracking here in the git master. I'll re-evaluate it later.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on March 28, 2021, 03:45:39 PM
Quote from: Who on March 28, 2021, 03:17:13 PMAnd for some filters, such as blacken borders, it is actually helpful to be able to see the area to be blackened change as you enter or change the numbers.

Except that this makes it impossible to input odd digits (e.g. you cannot input 72 starting with 7, you would need to input 2 first, than move the cursor, then input 7).

The alternative could be to allow odd values in input, but to correct them behind user's back later. The filter supports only even values for border with.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 28, 2021, 04:31:59 PM
Quote from: eumagga0x2a on March 28, 2021, 03:45:39 PM
Quote from: Who on March 28, 2021, 03:17:13 PMAnd for some filters, such as blacken borders, it is actually helpful to be able to see the area to be blackened change as you enter or change the numbers.

Except that this makes it impossible to input odd digits (e.g. you cannot input 72 starting with 7, you would need to input 2 first, than move the cursor, then input 7).

The alternative could be to allow odd values in input, but to correct them behind user's back later. The filter supports only even values for border with.
Ah, okay, never even thought about that.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: signy13 on March 28, 2021, 05:01:41 PM
Quote from: eumagga0x2a on March 28, 2021, 03:33:26 PMThere is a misunderstanding, I pointed to the location which disabled keyboard tracking (so that you can instantly change it to your liking). I haven't re-enabled keyboard tracking here in the git master. I'll re-evaluate it later.
Thank you for your notice, I changed the source code on my computer, recompiled and it works like a charm. My world is a bit nicer place to live again :-)
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: budda on March 28, 2021, 11:46:46 PM
I tried setting 1 core etc, using reg tweak - not helping. Latest avidemux still loads 97-100% cpu, 2.7.5 with same presets 40-50.
Also indexing of large .m2ts file- last build 1200 frames per sec and my hhd works wery loud, version 2.7.5 2900 fps per sec and i dont hear hdd (while windows and programs stored on sdd films on hdd). Sure last builds reads good audio data in large files.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Who on March 29, 2021, 05:32:32 AM
Quote from: szlldm on March 28, 2021, 02:53:10 AM
QuoteI immediately found a situation where it doesn't work well. The problem occurs when there is a black border that is immediately adjacent to the bottom of the logo, or if the logo overlaps the black border.  In that case you get a trapezoidal shaped black space inside the logo area.  The only way to avoid it that I could find was to crop the border out BEFORE using the Delogo filter, then it only drew in color from the rest of the frame.

Basically it works so, that "it eats away" the mask (white blob) by filling the boundary with neighbouring colors. If the area is immediately next to a black border, then it will fill with black color. If the mask  reach the edge of the image (like after you cropped), then it will "eat away" from the known boundaries.

Let me ask this - if you can make it "eat away" from only certain boundaries if the edge of the image is present, would there be any way to do that even if it's not at the actual edge of the image?  What I am beginning to see is that there are going to be times when something I want to get rid of is up against a black border that cannot be cropped out.  In most cases the black will be below the part to be blurred out.

I wonder if maybe you could maybe have checkboxes that say

"Don't fill from:  ☐ Top    ☐ Bottom    ☐ Left    ☐ Right"

and if any of those are selected, it would treat it as if an edge of the image were there, and fill only from the other (unchecked) directions.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on March 29, 2021, 09:28:19 AM
QuoteI wonder if maybe you could maybe have checkboxes that say

"Don't fill from:  ☐ Top    ☐ Bottom    ☐ Left    ☐ Right"

and if any of those are selected, it would treat it as if an edge of the image were there, and fill only from the other (unchecked) directions.

It expects arbitrary shaped masks, so "top/bottom/left/right" does not makes much sense.
The only way would be through the mask, for example gray pixels would be threated same as image edges.
I will investigate it.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on April 26, 2021, 04:41:33 PM
210426
It's now possible to enable/disable filters in the filter chain.
- Add the Dummy filter if you want to preview with all filters disabled.
!!! disabled state is not included in saved project script.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on April 26, 2021, 06:21:24 PM
Quote from: butterw on April 26, 2021, 04:41:33 PM!!! disabled state is not included in saved project script.

I bet it should not. The ability to disable filters somewhat fills the gap from the lack of two important things: filter preset management and undo/redo for the filter chain.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on April 26, 2021, 07:32:12 PM
Saving a project with disabled filters, they are enabled when you reload the project.
This will cause issues.
Adding an "enabled" default true property to filters would be the clean way to handle this.



Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on April 26, 2021, 08:15:03 PM
It is a stop-gap measure, not a design to be entrenched by more stop-gap measures.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on April 26, 2021, 09:09:42 PM
filter preset management ? It's easy to clear Filters and load a filter chain with a custom configuration from a script.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on April 26, 2021, 09:28:28 PM
Disabled active filters are actually empty shells for filter configuration. The purpose is to keep a particular filter configuration easily accessible for reuse, i.e. it is "pin current config to a preset list" functionality as offered by many applications, e.g. by The GIMP.

The other missing block is undo/redo, i.e. removing a filter from the list of active filters should not be an irreversibly destructive operation.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on April 27, 2021, 07:34:29 AM
Having an enable/disable for filters achieves that. The feature just needs to be supported in project files.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 18, 2021, 02:09:25 PM
https://github.com/mean00/avidemux2/commit/efa31757e7d0aed21cb5390fd27724e48a0efaab

I believe that causes an issue with copy/copy mp4 files muxed with avidemux played on PS3.

I'm guessing but it's the simplest revert test.  I would need a windows x64 .zip build to check without that commit.

The video plays normally until a few seconds left and an error code stops the video.

I don't need to give a sample because it happens with all mp4 I've muxed with May 10 nightly.  I'm not doing anything special here. any mkv x264/aac > copy/copy > mp4

Everything is fine with the last April nightly.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 18, 2021, 02:11:58 PM
Quote from: Anon40213 on May 18, 2021, 02:09:25 PMI believe that causes an issue with copy/copy mp4 files muxed with avidemux played on PS3.

This is purely a demuxer thing, irrelevant for the MP4 muxer.

Please provide samples I asked for.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 18, 2021, 02:16:27 PM
Quote from: Anon40213 on May 18, 2021, 02:09:25 PMI don't need to give a sample because it happens with all mp4 I've muxed with May 10 nightly.  I'm not doing anything special here. any mkv x264/aac > copy/copy > mp4

I don't have a PS3 to verify that a sample is compatible. So please provide one two – one which works, then the same video remuxed with the May 10 nightly which fails on your PS3.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 18, 2021, 07:32:09 PM
I've compared the internal structure of mp4 files produced by Avidemux with bundled FFmpeg 4.2.4 (I used 2.7.8 release) vs 4.4 as well as with the regular standalone ffmpeg 4.3.x and noticed one peculiarity in the stts atom / box in the output of Avidemux with FFmpeg 4.4, which matches the behaviour of PS3 to throw an error at the end of the file: the duration of the last frame is set to zero. This is not the case with the output of the MP4 muxer in 2.7.8.

I've uploaded two short samples in a ZIP archive to https://we.tl/t-p0pLbN5bcM (https://we.tl/t-p0pLbN5bcM), the first one created with the latest Avidemux, the second one is the first file with the duration of the last frame altered to match the duration of all other frames (stts still has two entries, which I cannot modify as this would require the file to be rewritten). Please try both on PS3 and report back.

It is possible that PS3 wants to have the stts table with a single entry (all frames have the same duration), or my first guess was wrong and something else causes the problem, in this case both files will fail to play without errors.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 20, 2021, 10:46:01 AM
Your samples confuse me because you used the PSP mux option so I'm left wondering if you think PS3/PSP are the same thing.  Both of them did work though because I suppose there is built in PSP compatibility there since they are both PlayStation brand.

I've realised I really do need to give samples so sorry for previously being an idiot.

https://we.tl/t-106KnZkgqj

Contains: SOURCE MKV, APRIL MP4, MAY MP4

File > Open > MKV file > Video Output: Copy > Audio Output: Copy > Output Format: MP4 Muxer > Click Configure > Muxing Format: MP4 > Optimize for Streaming: No optimization > Click OK > Save file.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 20, 2021, 02:35:08 PM
Quote from: Anon40213 on May 20, 2021, 10:46:01 AMYour samples confuse me because you used the PSP mux option so I'm left wondering if you think PS3/PSP are the same thing.

Yes, definitely, had to duckduckgo both (never came in touch with such hardware).

Thank you for the samples. As both my samples worked, it is clear that the problem is not related to stts and frame duration.

My second guess is that PS3 doesn't understand or doesn't like the content of the btrt atom / box (bitrate info), written by the newer libavformat in FFmpeg 4.4 when saving in MP4 mode. This atom is not written in PSP mode and it was not written by FFmpeg versions prior to 4.4.

We probably should try to find out whether it is the pure presence of the btrt atom which confuses PS3 or whether it is not happy with its content like the maximum bitrate (which is completely fake, hardcoded in Avidemux libavformat wrapper code).

I've uploaded your MP4-MAY sample to https://we.tl/t-80LnTwLais (https://we.tl/t-80LnTwLais) with 3 bytes starting at offset 0x10FBB09 modified to reduce the maximum video bitrate from 9000 kbps to 4000 kbps (which should be a reasonable value).

If this change satisfies the expectations of PS3, Avidemux is at fault and I need to try to implement a fix. If the problem persists, not supporting (or silently ignoring) btrt atom is a PS3 bug and there will be no fix as using the PSP mode solves the problem (unless you need to save video without audio, which libavformat in PSP mode would refuse to do).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 21, 2021, 11:12:20 AM
Unfortunately the problem indeed persisted.  I guess it's either PSP or find something else ASAP if I want to stay up to date.

Is there a ffmpeg ticket or commit about this change they made? I'd at least like to find out why this change had to be implemented all of a sudden.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 21, 2021, 11:32:31 AM
This FFmpeg enhancement was committed 4 year 8 months ago: avformat/movenc: implement writing of the btrt box (https://github.com/FFmpeg/FFmpeg/commit/3838e8fc210aa09a9f9058506c0ce80b6ad9b9c3).
It took that long from git master to release (ffmpeg devs are definitely not happy about that) bug report with patch (https://trac.ffmpeg.org/ticket/6575) until the enhancement made it into git master.

I looked into their code and I am not sure that it makes a lot of sense to write this optional atom. The problem is the maximum bitrate. Avidemux doesn't know it when it saves a video stream and while libavformat does a splendid job calculating the average bitrate, it uses the user-supplied value as the max bitrate if it is greater than the average (else we get max bitrate = average bitrate). It also doesn't calculate the buffer size (or it cannot guess anything reasonable).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 21, 2021, 11:41:20 AM
Why does using the PSP muxing mode pose a problem for you?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 21, 2021, 11:48:27 AM
Well, I throw my hands up.  You say it doesn't make much sense, seemingly only one person asked for it for streaming.  Couldn't they have created their own ffmpeg build with the patch?  So what about not streaming, that's why I select no optimization isn't it, to not have this atom? Or is playing a mp4 file for private viewing classified as streaming?

PSP feels dirty, it's for PSP.  What if I wanna play the mp4 elsewhere in the future and this PSP mux is an issue.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 21, 2021, 12:00:54 PM
For a fully correct assessment of PS3 compatibility, here is the SOURCE remuxed with the Avidemux off the current git master with FFmpeg patched to skip writing btrt atoms: https://we.tl/t-MYh9BfWook

Quote from: Anon40213 on May 21, 2021, 11:48:27 AMPSP feels dirty, it's for PSP.  What if I wanna play the mp4 elsewhere in the future and this PSP mux is an issue.

I don't think this can be a problem. At worst, you will need to remux the file to the usual MP4.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 21, 2021, 12:13:44 PM
Quote from: Anon40213 on May 21, 2021, 11:48:27 AMYou say it doesn't make much sense, seemingly only one person asked for it for streaming.

Well, writing software is not about majorities, it is mostly about merits.

Quote from: Anon40213 on May 21, 2021, 11:48:27 AMCouldn't they have created their own ffmpeg build with the patch?

They actually did. But as always, hardly anyone (for sure no-one with a PS3) tested developer builds.

Quote from: Anon40213 on May 21, 2021, 11:48:27 AMSo what about not streaming, that's why I select no optimization isn't it, to not have this atom?

This atom is standard-compliant and (formally) valid. There is no reason not to write it, apart from catering for broken implementations of the standard. The default streaming optimization rewrites the entire file to move the moov atom to the head of the file, without it a player cannot even know what is in the file unless it has read the end of the file which is only possible when either the server supports seeking or the entire file has been downloaded.

All that said, I still believe that the libavformat should have handled max bitrate calculation internally and both assuming the bit_rate field of AVCodecParameters struct may match the maximum bitrate and setting max bitrate to the average bitrate when this filed is at its default value (zero) make no sense.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 22, 2021, 10:42:47 AM
Quote from: eumagga0x2a on May 21, 2021, 12:00:54 PMFor a fully correct assessment of PS3 compatibility, here is the SOURCE remuxed with the Avidemux off the current git master with FFmpeg patched to skip writing btrt atoms: https://we.tl/t-MYh9BfWook

The plot thickens, it still has the error.

I also tried with the mediafire mp4 via the ffmpeg ticket out of curiousity and it outright refused to play it with the same error.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 22, 2021, 09:11:56 PM
I've uploaded three more samples in a ZIP, the names of the files are self-explanatory, please try and report back: https://we.tl/t-t9YD4iUqDJ (https://we.tl/t-t9YD4iUqDJ)

The samples created with ffmpeg were generated by

ffmpeg -i MP4-APRIL.mp4 -c copy output-filename.mp4
where output-filename.mp4 is a placeholder for whatever I used to describe the properties. Regarding the new sample created with Avidemux, FFmpeg in Avidemux was patched not only to skip writing the btrt atom but also to assign the last frame the same duration as the previous one instead of zero (which makes all frames the same duration).

The latest ffmpeg adds a colr (color primaries / transfer function / matrix / range info) atom to the equation.

Quote from: Anon40213 on May 22, 2021, 10:42:47 AMThe plot thickens, it still has the error.

So it is not the btrt atom *headscratch*
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 24, 2021, 11:53:22 AM
Error
adm-remuxed-from-april-no-btrt-no-zero-duration

Both OK
ffmpeg-v432-remuxed-from-april
latest-ffmpeg-remuxed-from-april
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 24, 2021, 12:03:52 PM
Thank you for testing, I don't have a theory at the moment. At least it is proven that new atom types written by very recent libavformat are not related to the issue. For a strict comparison, a test with FFmpeg 4.4 would be necessary (latest git is ahead of 4.4, of course), in case something was different in 4.4 only.

Just curious: does PS3 accept mp4 files without audio? If yes, does the error persist when no audio track is present?
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 24, 2021, 12:07:19 PM
It does accept mp4 without audio.

Can't check right now.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 26, 2021, 10:32:07 AM
Mkv source muxed in may 10 build to mp4 with the audio removed works so it is the audio.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 28, 2021, 05:01:11 PM
A next guess. There is a minor (39 ms) discrepancy between the duration of the audio track in the media header (mdhd) vs the edit list (elst) atom in the MP4-MAY sample, I've uploaded the MP4-MAY sample renamed to MP4-MAY-audio-mdhd-patched.mp4 with the duration in mdhd at offset 0x10FFD2C modified to match the MP4-APRIL sample: https://we.tl/t-NK3eS8lBu2 (https://we.tl/t-NK3eS8lBu2).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on May 30, 2021, 09:32:28 AM
Still has the error.

[muxerMp4] Fix audio tracks in German language tagged as English when saving to MOV (https://github.com/mean00/avidemux2/commit/d085728cba916181ba26c057ed43fa37282f6bc9)

Even if it seemingly makes no sense to do, I think it's worth a try muxing a file without that commit.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on May 30, 2021, 10:26:32 AM
Quote from: Anon40213 on May 30, 2021, 09:32:28 AMStill has the error.

I'm out of ideas.

Quote from: Anon40213 on May 30, 2021, 09:32:28 AM[muxerMp4] Fix audio tracks in German language tagged as English when saving to MOV (https://github.com/mean00/avidemux2/commit/d085728cba916181ba26c057ed43fa37282f6bc9)

Even if it seemingly makes no sense to do, I think it's worth a try muxing a file without that commit.

This commit affects the MOV muxer only, the preprocessor define

#ifdef MUXER_IS_MOV
...
#endif

means that the compiler doesn't get to see this code at all when building the MP4 muxer and thus MUXER_IS_MOV is not defined. This is not seemingly, it simply makes zero sense to suspect any link to the issue, period.
Title: Avidemux2.7.9 - 210611
Post by: butterw on June 12, 2021, 09:49:09 PM
Feedback on 210611
! [Filter Manager] If there is as single disabled filter, the preview still shows this filter applied. The workaround is too manually add a Misc/Dummy filter.

The new cut point display feature is a great new feature.
! It doesn't seem to take into accounts cuts done to the start of the video.

! However, the unused Search for previous black frame buttons should be removed.

The button I'm most likely to use is `go to First Frame`, adding buttons effectively shifts the position I know
>> this makes this version unusable for me because of this (toolbar buttons can still not be customized without recompiling).

Also worth considering: Too many similar buttons >> confusing interface.
The main strength of Avidemux IMO is its simple interface, make sure you keep it that way with any changes.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on June 12, 2021, 11:43:57 PM
Quote from: butterw on June 12, 2021, 09:49:09 PM! [Filter Manager] If there is as single disabled filter, the preview still shows this filter applied. The workaround is too manually add a Misc/Dummy filter.

Preview always show the selected filter's output. If you open preview on a disabled filter, the title of the preview's window explicitely shows "Preview / DISABLED filtername".

Quote from: butterw on June 12, 2021, 09:49:09 PM! It doesn't seem to take into accounts cuts done to the start of the video.
You can always jump to the begining anyway.

Quote from: butterw on June 12, 2021, 09:49:09 PM! However, the unused Search for previous black frame buttons should be removed.

The button I'm most likely to use is `go to First Frame`, adding buttons effectively shifts the position I know
>> this makes this version unusable for me because of this (toolbar buttons can still not be customized without recompiling).

Black frame search buttons could be placed after Go to first/last frames buttons.
IMHO using Home/End buttons is way faster.


Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on June 13, 2021, 12:35:02 AM
Quote from: szlldm on June 12, 2021, 11:43:57 PM
Quote from: butterw on June 12, 2021, 09:49:09 PM! It doesn't seem to take into accounts cuts done to the start of the video.
You can always jump to the begining anyway.
The suggestion is to add a red mark at the beginning so that I know I made a cut there.

Quote from: szlldm on June 12, 2021, 11:43:57 PM
Quote from: butterw on June 12, 2021, 09:49:09 PMThe button I'm most likely to use is `go to First Frame`, adding buttons effectively shifts the position I know
>> this makes this version unusable for me because of this (toolbar buttons can still not be customized without recompiling).

Black frame search buttons could be placed after Go to first/last frames buttons.

That's 12 Arrow buttons in the toolbar with only the 2 marker buttons as separator.
These unused Black frame search buttons should be removed, at least until the toolbar is made customizable.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: eumagga0x2a on June 13, 2021, 09:00:06 AM
Quote from: butterw on June 13, 2021, 12:35:02 AMThe suggestion is to add a red mark at the beginning so that I know I made a cut there.

I think it works as intended = no red marks at locations other than boundaries between two segments. Imagine, you run a project script and add a single segment. Did you make a cut if the start time in addSegment() is non-zero?

Quote from: butterw on June 13, 2021, 12:35:02 AMThese unused Black frame search buttons should be removed

They are not unused.

However, I think they are seldom used and the function is accessible via the Go menu, so I would support removing them from the navigation widget (as to me, I prefer not to click, so that the placement of buttons doesn't matter when keyboard shortcuts are provided).
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: Anon40213 on June 13, 2021, 03:46:40 PM
QuoteStill has the error.

QuoteI'm out of ideas.

Thought I would share that I encountered it outside of any avidemux use.  I grabbed a dailymotion video via hls and left it as is.
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on June 13, 2021, 04:51:07 PM
Quote from: eumagga0x2a on June 13, 2021, 09:00:06 AM
Quote from: butterw on June 13, 2021, 12:35:02 AMThese unused Black frame search buttons should be removed

They are not unused.

However, I think they are seldom used and the function is accessible via the Go menu, so I would support removing them from the navigation widget (as to me, I prefer not to click, so that the placement of buttons doesn't matter when keyboard shortcuts are provided).

- Previous Black Frame: Error (titled Info) "BlackFrame" "this feature is unsupported at the moment"
- Next Black Frame: this can work in some case, but it doesn't have a configurable tolerance for what constitutes a black frame, and also is not fast enough(ex: 150fps @720p).
- Go to next Prev/Next Cut Point is a more useful feature
- Given that these search for Black Frame actions are also available in the Go Menu, they should be removed from the toolbar until the buttons are made user configurable.

 
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on June 13, 2021, 08:44:40 PM
Quote from: eumagga0x2a on June 13, 2021, 09:00:06 AM
Quote from: butterw on June 13, 2021, 12:35:02 AMThe suggestion is to add a red mark at the beginning so that I know I made a cut there.

I think it works as intended = no red marks at locations other than boundaries between two segments. Imagine, you run a project script and add a single segment. Did you make a cut if the start time in addSegment() is non-zero?


The tooltip is labelled: "Go to the previous Cut Point", so yes if I've made a cut at the start of the video, it should go to the start of the video.



Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: szlldm on June 14, 2021, 09:41:27 AM
Quote from: butterw on June 13, 2021, 08:44:40 PMThe tooltip is labelled: "Go to the previous Cut Point", so yes if I've made a cut at the start of the video, it should go to the start of the video.

Actually removing portion of the video at the start or at the end, is not cutting, but trimming. So the button works exactly as the tooltip suggest  ;D
Title: Re: Avidemux2.7 - Latest dev Version thread
Post by: butterw on June 14, 2021, 11:25:01 AM
There's a stronger argument for that than for shifting well established toolbar button positions.

I would personally prefer having a marker at the start or at the end if a trim was made.
Visualizing where edits have been done is the main new added feature for me.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: butterw on June 17, 2021, 02:12:52 PM
Trimming videos is a common use case for Avidemux. So I'm confirming my feature request for the addition of a visual indicator (bar) on the timeline when the video has been trimmed (at the start of the end).
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on July 03, 2021, 06:45:02 PM
New nightly 210702
-Resample FPS filter now has Motion Interpolation option
-Chaining Resample FPS (with motion interpolation) and Change FPS slow motion effect can be achieved
-New filter: Quadrilateral transformation
-Search Black Frame buttons removed from the navigation widget
-Main window's widget visibilities are saved
-Rubber band visibility remembered per filter type
+bugfixes
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on July 15, 2021, 01:23:12 AM
New nightly 210714
-New filter: Image stabilizer (Reduce camera shakiness)
-Crop: autocrop can do perfect crops (if the scene is not too dark)
-swsResize: nearest neighbor option
-decoder support for planar GBR pixel format
-mp4 demuxer VP9 support
-fixing multithreaded decoding issues
-improved UI responsiveness during playback
-improved UI responsiveness during navigation (ie. performing repeated or continuous next frame/previous frame/etc. actions)
+bugfixes
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: dosdan on July 15, 2021, 10:42:37 PM
Quote from: szlldm on July 15, 2021, 01:23:12 AMNew nightly 210714
-New filter: Image stabilizer (Reduce camera shakiness)

Where can I find documentation on the role of the GRAVITY parameter?

Dan.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on July 15, 2021, 10:54:33 PM
Quote from: dosdan on July 15, 2021, 10:42:37 PMWhere can I find documentation on the role of the GRAVITY parameter?
There is none (yet)
Basically it means, with how much "force" will it pull back the frame to the center.
If the camera do panning, without "gravity" the frame would slide out of the image.

I'm thinking on an auto-gravity option.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: dosdan on July 16, 2021, 12:28:16 AM
Quote from: szlldm on July 15, 2021, 10:54:33 PMI'm thinking on an auto-gravity option.

An auto-crop/auto-zoom feature like in FFMPEG's libvidstab (based on http://public.hronopik.de/vid.stab/features.php?lang=en) would be nice. I made a batchfile testbench to experiment with it.

stab_testbench.bat
@echo off
setlocal
cls

rem Mode 1: Process file & then compare against original.
rem Mode 2: Compare two clips - no processing.
rem Mode 3: Final output processing of file - reanalyse.
rem Mode 4: Final output processing of file - reuse transform_vectors.trf.
rem Mode 5: Compares 2 processed versions (different output settings) - modes 3, 4, then 2.
set mode=1
set duration=30
set loglevel=info

rem *** Analysis Settings Modes 1,3 ***
set stepsize=2
set shakiness=10
set accuracy=15
set in_file=shaky_480p.mkv

rem *** Comparison Settings Modes 2,5 ***
set file1=30s_smoothing15.mkv
set file2=30s_smoothing30.mkv
set fontfile='c\:/windows/fonts/ariblk.ttf'
set fontsize=48

rem *** Output Settings Modes 1,3,4,5 ****
set outputname=Final.mkv
set smoothing=15
set unsharp=5:5:0.8:3:3:0.4
if %mode%.==5. set outputname=%file1%

rem *** Output Settings Mode 5 (clip from 2nd run) ****
set smoothing2=30
set unsharp2=5:5:0.8:3:3:0.4

if %mode%.==2. goto :COMPARE
if %mode%.==4. goto :OUTPUT_MODE
if %mode%. NEQ 1. (if %mode%. NEQ 3. (If %mode%. NEQ 5. (Echo Invalid mode # & goto :EOF)))

echo ***************************************************************************************
echo Analysing...
echo.
ffmpeg -i %in_file% -t %duration% -y -hide_banner -loglevel %loglevel% -vf vidstabdetect=stepsize=%stepsize%:shakiness=%shakiness%:accuracy=%accuracy%:result=transform_vectors.trf -f null -
echo.

if %mode%.==3.  goto :OUTPUT_MODE
if %mode%.==5.  goto :OUTPUT_MODE

:STAB_and_COMP
echo ***************************************************************************************
echo Stabilising and Comparing...
echo.
if "%loglevel%"=="debug" pause & echo.
ffmpeg -i %in_file% -t %duration%  -y -hide_banner -loglevel %loglevel% -preset slow -codec:a copy -filter_complex "vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=%smoothing%,unsharp=%unsharp%[stab],[0:v:0]pad=iw*2:ih[bg];[bg][stab]overlay=w,drawtext=text=Shaky:fontfile=%fontfile%:fontsize=%fontsize%:x=0:y=0,drawtext=text=Stabilised:fontfile=%fontfile%:fontsize=%fontsize%:x=w/2:y=0" compared.mkv
start /wait "C:\Program Files\MPC-BE x64\mpc-be64.exe" compared.mkv
goto :EOF

:COMPARE
echo ***************************************************************************************
echo Comparing...
echo.
echo ffmpeg -i %file1% -t %duration%  -i %file2% -t %duration% -y -hide_banner -loglevel %loglevel% -preset fast -codec:a copy -filter_complex "[0:v:0]pad=iw*2:ih[bg];[bg][1:v:0]overlay=w,drawtext=text=%file1%:fontfile=%fontfile%:fontsize=%fontsize%:x=0:y=0,drawtext=text=%file2%:fontfile=%fontfile%:fontsize=%fontsize%:x=w/2:y=0" compared.mkv
ffmpeg -i %file1% -t %duration%  -i %file2% -t %duration% -y -hide_banner -loglevel %loglevel% -preset fast -codec:a copy -filter_complex "[0:v:0]pad=iw*2:ih[bg];[bg][1:v:0]overlay=w,drawtext=text=%file1%:fontfile=%fontfile%:fontsize=%fontsize%:x=0:y=0,drawtext=text=%file2%:fontfile=%fontfile%:fontsize=%fontsize%:x=w/2:y=0" compared.mkv
start /wait "C:\Program Files\MPC-BE x64\mpc-be64.exe" compared.mkv
goto :EOF

:OUTPUT_MODE
echo ***************************************************************************************
echo Stabilising and Outputting... 
echo.
ffmpeg -i %in_file% -t %duration%  -y -hide_banner -loglevel %loglevel% -vcodec libx264 -tune film -preset slow -codec:a copy -filter_complex "vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=%smoothing%,unsharp=%unsharp%" %outputname%
if %mode%.==5. goto :2ND_RUN
goto :EOF

:2ND_RUN
echo ***************************************************************************************
echo Stabilising and Outputting (2nd run)... 
echo ffmpeg -i %in_file% -t %duration%  -y -hide_banner -loglevel %loglevel% -vcodec libx264 -tune film -preset slow -codec:a copy -filter_complex "vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=%smoothing2%,unsharp=%unsharp2%" %file2%
ffmpeg -i %in_file% -t %duration%  -y -hide_banner -loglevel %loglevel% -vcodec libx264 -tune film -preset slow -codec:a copy -filter_complex "vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=%smoothing2%,unsharp=%unsharp2%" %file2%
goto :COMPARE

It requires FFMPEG to have been compiled with libvidstab & libfreetype (for the titles on the side-by-side comparison). These titles also requires a font, here 'c\:/windows/fonts/ariblk.ttf'.

Here's a 30s side-by-side comparison of the result of operating in Mode 1, "Process file & then compare against original", of the shake reduction:

https://dl.dropbox.com/s/254fayqtsfilorz/compared.mkv

You can clearly see the auto-crop/auto-zoom in action.

The batchfile ends by automatically playing the comparison video in a video player in another window:

start /wait "C:\Program Files\MPC-BE x64\mpc-be64.exe" compared.mkv

If you want to try your IS method on this source, it's a 480p YT d/l of "What is "no-chilling" home brew?" https://www.youtube.com/watch?v=Ih3jg3Xdcvs

Dan.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on July 16, 2021, 01:08:15 AM
Thanks for the sample video! It is more shaky than those i tested with.
A fear an auto-zoom function would be problematic with the current filter, because it is single pass (for now). But an auto-gravity option would improve on it.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on August 02, 2021, 11:15:21 PM
New nightly 210731
-Image stabilizer auto-gravity option
-Feedback by busy cursor during navigation
-Resize and Crop filters display output aspect ratio and nearest common ratio (e.g 1.7778 and 16:9)
-Toolbar can be hidden
-Encoding dialog displays output file name (full path), option (default value can be set at the Preferences) for deleting first pass temporary files
-Properties dialog displays average video bitrate
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on August 23, 2021, 11:14:40 PM
New nightly 210823
-New filter: Zoom (partializable crop filter)
-New filter category: Transition
-New filters: Fade from image, Fade in, Fade out and Fade through
+bugfixes
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: eumagga0x2a on August 24, 2021, 06:07:38 AM
The last round of nightlies contains a major change in behaviour:

Bugfixes (incomplete list):

Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: Who on August 26, 2021, 05:07:51 AM
Quote from: eumagga0x2a on August 24, 2021, 06:07:38 AMThe last round of nightlies contains a major change in behaviour:
  • Segments are created automatically aligned at the PTS of the first frame (a video seems to start at zero). The purpose is to facilitate adding segments by hand via tinyPy scripts. Now it is not necessary to match a PTS in the source video perfectly, which was often a challenge. The duration of the segment is automatically reduced.
  • The frame matching the position of the marker B is now excluded from the range (as it should, actually). The reason is that in a typical use case editing an open GOP type video in copy mode, a standalone non-IDR keyframe at the end of video may be not fully decodable (it may require later frames which are missing). If marker B is set to the last picture of a video, it is now necessary to seek to marker A, reset markers and set marker A to extend marker B to the end of the video, else the last picture won't be included when saving the output. An option to extend (i.e. to reset)  the marker B alone is being contemplated.

I'm trying to understand what has been changed here.  A typical use case for me it to load a video, trim off a little at the start (in which case I have been setting the B marker to the first frame I want to keep), trim off a little at the end (in which case I set the A marker to the first frame I want to delete), and also sometimes remove one or more sections in the middle.  For those, I set the A marker to the first frame I want to remove, and the B marker to the first frame I want to keep following the delete.  Are you now saying this is going to change?  I really hope not.

Basically, most of the editing I do requires that I be able to make precise cuts at particular points.  I can't have frames left behind that should have been cut, nor cuts that extend beyond the cut points I set.  Please tell me you are not making Avidemux less precise in this regard.  I don't understand what you mean when you are talking about PTS, or a "GOP type video", all I know is you appear to be saying that setting the A and B points will not produce a precise cut as was the case in the past, or maybe that setting the B frame will not make the cut in the same place as it would have in the past?  I REALLY hope I am wrong about that.  Please be aware that some of us don't really understand or pay much attention to the various types of frames; as long as the cuts or edits are made where we set the markers we're happy.

Quote from: eumagga0x2a on August 24, 2021, 06:07:38 AMBugfixes (incomplete list):

  • .....
  • A lot of memory leaks all over the place found and fixed.
Could this be the reason that my Mac has sometimes been getting flaky and then crashing when I have been running Avidemux for several sessions?  Does Avidemux clear these memory leaks when the program is closed (prior to this version), or is that impossible to do?  You also mention that "fadeTo and fadeToBlack filters on macOS produced wrong colors (purple tint) – now fixed" but I assume that refers to the new filters introduced in version 210823, not the Fade To Black filter that's been part of Avidemux for many versions now, because I've never noticed a purple tint in that.  Anyway where I am going with this is that if these changes affect MacOS (ESPECIALLY the memory leak issue), how about making a new MacOS nightly? I would really like to see if those fixes stop all the annoying crashes that I have been blaming on Catalina all this time!
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: eumagga0x2a on August 26, 2021, 07:05:58 AM
Quote from: Who on August 26, 2021, 05:07:51 AMA typical use case for me it to load a video, trim off a little at the start (in which case I have been setting the B marker to the first frame I want to keep), trim off a little at the end (in which case I set the A marker to the first frame I want to delete), and also sometimes remove one or more sections in the middle. For those, I set the A marker to the first frame I want to remove, and the B marker to the first frame I want to keep following the delete.

Nothing has been changed here. The change affects the scenario when you save the selection from A to B. Now the picture matching B is not included (this is new, or, more precisely, this marks the return to the old behaviour from about 4 years ago).

Quote from: Who on August 26, 2021, 05:07:51 AMBasically, most of the editing I do requires that I be able to make precise cuts at particular points.  I can't have frames left behind that should have been cut, nor cuts that extend beyond the cut points I set.

As long as you re-encode, you can have the precision. There is none when you use the copy mode. Nothing has changed here.

Quote from: Who on August 26, 2021, 05:07:51 AMCould this be the reason that my Mac has sometimes been getting flaky and then crashing when I have been running Avidemux for several sessions?

I don't think so. But as the crash seemed to happen at the end of encoding, it might be related to the issues tackled by this commit (https://github.com/mean00/avidemux2/commit/1475d54e8a55a1a3cb80a30d8cc9edddf0cb4fb8) for the filter manager only. If you run Avidemux from Terminal, reproduce the crash and provide its "last words" (a couple of pages worth or console output, please), it might help to assess the problem.

Quote from: Who on August 26, 2021, 05:07:51 AMYou also mention that "fadeTo and fadeToBlack filters on macOS produced wrong colors (purple tint) – now fixed" but I assume that refers to the new filters introduced in version 210823, not the Fade To Black filter that's been part of Avidemux for many versions now, because I've never noticed a purple tint in that.

No, the fixes correct the issue in the old filters.

Quote from: Who on August 26, 2021, 05:07:51 AMhow about making a new MacOS nightly?

I'd love it (I have no control over when it happens).
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: Who on August 26, 2021, 04:31:34 PM
Quote from: eumagga0x2a on August 26, 2021, 07:05:58 AM
Quote from: Who on August 26, 2021, 05:07:51 AMCould this be the reason that my Mac has sometimes been getting flaky and then crashing when I have been running Avidemux for several sessions?

I don't think so. But as the crash seemed to happen at the end of encoding, it might be related to the issues tackled by this commit (https://github.com/mean00/avidemux2/commit/1475d54e8a55a1a3cb80a30d8cc9edddf0cb4fb8) for the filter manager only. If you run Avidemux from Terminal, reproduce the crash and provide its "last words" (a couple of pages worth or console output, please), it might help to assess the problem.

First, thank you for the detailed response.  It is strange I have never noticed the purple tint on the fade to black but I am not complaining!  But as for the crashes, it may be a different issue because they don't typically happen at the end of encoding, at least not as far as I can tell.  What happens is that the system starts getting unresponsive, particularly for other software - Avidemux will keep working fine until the system dies completely (usually indicated by the clock in the top bar not updating).  But for example I might try to open a web browser, or some other piece of software, and the icon in the dock will just bounce for two or three minutes and then stop.  Or if I try to close an open program, it will take several minutes, assuming the system doesn't freeze.  If I walk away and leave it alone, Avidemux will usually continue until it completes, but if I insist on trying to open or close programs the system will generally freeze completely and require a hard power off (using the power switch).  So far it has always come back up once I hit the power switch and then everything works as it should, which is what has made me suspect a memory leak of some kind, but I never knew what was causing it.  I can't say for certain it has been Avidemux but I definitely would like to try the new version to see if it reduces or eliminates the occurrences of this problem.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: eumagga0x2a on August 26, 2021, 04:46:40 PM
This indeed looks like a different issue. If all source videos triggering the problem were exclusively MPEG-TS or -PS files, then you should profit from some nasty debug messages disabled by this commit (https://github.com/mean00/avidemux2/commit/99784e3cbc540faf8aeda598f1e50a32bd1f5ad6). They could fill the log file /tmp/admlog.txt which is created when Avidemux is not run in Terminal with hundreds of megabytes of data.

In doubt, let a Terminal window open with top running while you are using Avidemux to monitor system load in real time.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: Who on August 26, 2021, 09:39:07 PM
Quote from: eumagga0x2a on August 26, 2021, 04:46:40 PMIn doubt, let a Terminal window open with top running while you are using Avidemux to monitor system load in real time.

This is a typical top line I see when I run top (not counting the column headers):
3044   Avidemux2.7  358.3 14:38:19 19/6  1    304   820M   0B     157M   3044  1    running  *1[3774]      0.00000 0.00000    501  4722093  1762  1911315+  553969+   18856886+ 7183590+  105089162+ 4365     6628    358.3 12246355863

The line continually changes (looks like every second or so) but Avidemux2.7 stays right up there.  Nothing else even comes remotely close in terms of CPU usage.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: eumagga0x2a on August 27, 2021, 12:10:33 PM
You Avidemux session continues since almost 15 hours – this is quite a long encode run! 358.3% CPU load and 820 MiB of allocated memory shoud not be critical (157 MiB of compressed memory indicates that the most of memory on the system is in use and that much memory allocated by Avidemux is not actively accessed).

Have you checked that /tmp/admlog.txt is not growing extremely fast and extremely large for the reasons I mentioned in my last reply?

To improve system responsiveness despite active encode running, you can use

renice -n <value> -p <PID of Avidemux process>
where <value> is a positive figure <= 20 and the PID should be used as reported by

ps -ef | grep Avidemux
(the second column is the PID).
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on September 05, 2021, 02:00:24 PM
New nightly 210905
-new Fade In and Fade Out filters
-x264 encoder has color properties
-Wavelet sharpener has a noise cutoff parameter (to remove sharpened compression artifacts)
-Partial filter markers behaviour changed (frame at B marker excluded)
-Main window's maximized state is persistent
-Reduced window size on loading a video
-Motion interpolation improved quality and performance
-VHS filter has a noise parameter
+bugfixes
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: Who on September 07, 2021, 10:31:47 PM
Well I am REALLY sorry to have to report this bug - this is the first time I have encountered a bug so bad that it caused me to restore a previous version from my Time Machine backup.  And unfortunately I did not notice this bug until I had already encoded a couple of videos, but for whatever reason they did not seem to be affected (at least I really hope not, my fear is this problem might have shown up in some random spot!).

The problem appears to be that the times you set for partial filters aren't honored, at least when using the Blacken Borders filter.  Instead, the start and/or end gets set to some completely random times! I did a little experimenting to see if I could figure out if there was any logical pattern to it, but it did not appear to be, except that in the very limited experimenting that I did the times actually used will be less than the times you set.  The times display correctly in the filters list, but Avidemux either isn't reading them correctly or something else is happening.  I kept thinking that surely I had somehow made a mistake, or that perhaps it was really doing the filtering but just not showing it in the filtered preview, but after extensive trial and error I figured out that no, it really was not using the times that had been set.  I tried closing and re-opening Avidemux and starting from scratch but had the same result.

So in frustration I went back to the version I'd been using in mid-August (which I think was actually from back in March or thereabouts) and loaded the exact same video and did everything the same as I had done it in the new version, and of course then the filter worked and it ran at the correct time.  I know this is why you release nightlies, to find stuff like this, but since some other issues had been fixed in the new version I was hoping this would be one I could use for a while.  I'm really kind of surprised no one else has reported this yet, maybe it is specific to the MacOS version?
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: eumagga0x2a on September 08, 2021, 03:47:21 AM
Should be fixed now (https://github.com/mean00/avidemux2/commit/fee0b39c5a713ac7ee53ee3bf509d33bf7ab68d0#diff-3168bdff6fe2f6f3e5a7b82161f7b36bdbbc88bb3047fd62c2b3b34e0a70336e), thank you for catching it.

The reason was my old blunder which was mostly harmless because it compared values one of which was factor 1000 too high, so that the faulty check actually almost never hit. szlldm has noticed the bug in the check and fixed the check, making it fatal.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: eumagga0x2a on September 08, 2021, 07:10:43 AM
Please try the new nightly.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: Who on September 08, 2021, 07:40:38 AM
It is very late at night here so I'm not ready to start encoding another full video yet (have to sleep sometime), but I did a quick check using the same original video where I had first noticed the problem, using the same filter in the same spot, and now it works as it should.  So, it does appear that the new nightly fixes the bug, so thanks very much for the quick response!
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on October 03, 2021, 09:17:33 PM
New nightly 211003
-new filter: Deband
-fix VDPAU
-preference for loading sequentially named images in reverse order
-menu actions to reset each marker separately
-support for PNG as mp4 video codec
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on October 27, 2021, 09:44:11 PM
New nightly 211026/211027
-HDR tone mapping (settings in Video menu and Preferences)
-TureHD decoder support
-redesigned VU meter (Audio metre)
-extended ProRes decoder support
-"Search previous black frame"
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: Anon40213 on November 04, 2021, 12:09:55 PM
Hi,

Win8.1 64 nightly211027

I just tried a new version and is the small loading circle on 211027 every time I move across the navigation line, no matter how small/big the step, supposed to be there? Can it be disabled if it's meant to be?

It's freaking me out a bit to see it there and is it saving something?  I'd rather not want to have to find some large cache has been stored somewhere that I got to delete every time I'm finished editing.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: eumagga0x2a on November 04, 2021, 08:24:29 PM
"Small loading circle" is called busy cursor. It provides feedback that the application is not idle, which is always the case when seeking. And yes, it is an enhancement. Navigation can be very slow in high resolution HDR videos, especially when HDR tone mapping is enabled. A lack of feedback may tempt user to repeat actions, further delaying execution of commands.
Title: Re: Avidemux2.7.9 - Latest dev Version thread
Post by: szlldm on November 11, 2021, 08:43:26 PM
New nightly 211111
-bugfixes&polish
-ffNvEnc can creat intra-only streams
-navigation during play (cursor keys for seeking, go to marker A/B, etc.)
-the Go menu has been extended with the not well known time jump commands
Title: Re: Avidemux2.7.9-dev version thread
Post by: butterw on July 01, 2022, 10:29:18 AM
The v2.7.9-dev versions discussed in this thread are no longer available at avidemux.org/nightly. Currently only v2.8.1-dev versions are available.
I understand that older dev versions are unsupported, but would it be possible to keep the older dev versions around for longer (in an old_versions subfolder) ?
 
Win64 builds list (via wayback machine):
https://web.archive.org/web/20210725134100/http://www.avidemux.org/nightly/win64/
The last listed version is avidemux_r210714_win64Qt5_67.zip. Versions starting from avidemux_r211003_win64Qt5_73.zip are also listed.
The files themselves are not available.
 
I've uploaded v2.7.9-dev 210611_win64 here:
https://files.videohelp.com/u/295418/avidemux_r210611_win64Qt5_64.zip