For FDK AAC encoding, can you please add support for VBR modes and also for overriding bandwidth/cutoff (low-pass) frequency? Both are natively supported by the encoder library.
Thank you!
VBR modes have been added by this commit (https://github.com/mean00/avidemux2/commit/ae6849b78cb157725505ba998a5390dbe19b98e8). Manually overriding cut-off frequency is so strongly discouraged in the library documentation that I am not eager to implement it – and if, should it be a menu from maybe 8 kHz up to 20? Should it be assumed that the user knows that this won't work for profiles with SBR?
For now, whoever needs the best quality, should choose "Very High Bitrate" VBR mode which gives a cut-off > 19 kHz.
Quote from: eumagga0x2a on August 13, 2023, 06:18:47 PMVBR modes have been added by this commit (https://github.com/mean00/avidemux2/commit/ae6849b78cb157725505ba998a5390dbe19b98e8). Manually overriding cut-off frequency is so strongly discouraged in the library documentation that I am not eager to implement it – and if, should it be a menu from maybe 8 kHz up to 20? Should it be assumed that the user knows that this won't work for profiles with SBR?
For now, whoever needs the best quality, should choose "Very High Bitrate" VBR mode which gives a cut-off > 19 kHz.
Good to hear.
With VBR mode 5 available, the need for overriding the frequency is largely irrelevant.
When will a Win64 build be available with this commit?
Thanks!
Quote from: MswolJ on August 13, 2023, 09:45:15 PMWhen will a Win64 build be available with this commit?
When the maintainer of the project finds time to do that, so actually anytime soon or not so soon.
Hmm.. spent the time to try to build this project myself and received a bunch of errors in "nvenc". Plenty of references to "VBR".
Related or coincidence?
Sample below:
src/libavcodec/nvenc.c: In function 'nvenc_override_rate_control':
src/libavcodec/nvenc.c:925:10: error: 'NV_ENC_PARAMS_RC_VBR_MINQP' undeclared (first use in this function); did you mean 'NV_ENC_PARAMS_RC_VBR'?
925 | case NV_ENC_PARAMS_RC_VBR_MINQP:
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
| NV_ENC_PARAMS_RC_VBR
This was my 64-bit attempt. The 32-bit attempt ran into some different, really squirrelly issues.
Do you cross-compile (https://github.com/mean00/avidemux2/blob/master/cross-compiling.txt)? The version of nv-codec-headers should be 11 something, don't try to use the master.
Quote from: eumagga0x2a on August 19, 2023, 06:26:32 AMDo you cross-compile (https://github.com/mean00/avidemux2/blob/master/cross-compiling.txt)? The version of nv-codec-headers should be 11 something, don't try to use the master.
OK, pulled the most recent 11 version.. seemed to get past that. Now failing here...
[ 77%] Linking CXX static library libADM_libmp4v2.a
cd /home/ubuntu/avidemux2/buildMingwPluginsCommon-x86_64/ADM_muxers/muxerMp4v2/libmp4v2 && /usr/bin/cmake -P CMakeFiles/ADM_libmp4v2.dir/cmake_clean_>
cd /home/ubuntu/avidemux2/buildMingwPluginsCommon-x86_64/ADM_muxers/muxerMp4v2/libmp4v2 && /usr/bin/cmake -E cmake_link_script CMakeFiles/ADM_libmp4v>
/home/ubuntu/cross-build/mxe/usr/bin/x86_64-w64-mingw32.shared-ar qc libADM_libmp4v2.a CMakeFiles/ADM_libmp4v2.dir/src/3gp.cpp.obj CMakeFiles/ADM_lib>
/home/ubuntu/cross-build/mxe/usr/bin/x86_64-w64-mingw32.shared-ranlib libADM_libmp4v2.a
make[2]: Leaving directory '/home/ubuntu/avidemux2/buildMingwPluginsCommon-x86_64'
[ 77%] Built target ADM_libmp4v2
make[1]: Leaving directory '/home/ubuntu/avidemux2/buildMingwPluginsCommon-x86_64'
make: *** [Makefile:139: all] Error 2Guess I need to just want for the pros to build..
Just disable the build of MP4v2 muxer in CMakeLists.txt. On Fedora, I don't have to care because I build against the system libmp4v2.
In doubt, please post the actual error (not the final failure at the end), you missed it.
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x4dc): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x4e4): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x506): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x533): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x569): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x57d): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x5ae): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x5d5): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x608): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x61c): relocation truncated to fit: R_X86_64_32S against `.>
CMakeFiles/ADM_vf_FluxSmooth.dir/objects.a(ADM_vidFluxAsm.cpp.obj):ADM_vidFluxAsm:(.text+0x64d): additional relocation overflows omitted from the out>
collect2: error: ld returned 1 exit status
You haven't read the how-to then. It is explicitly stated there that fluxSmooth and ivtvDupeRemover cannot be compiled with the updated gcc in MXE (the assembler code needs a fix).
However, if I am not mistaken, there is more stuff which MXE devs have changed: Qt5 in MXE now uses some icu*.dll libs (icudt66.dll, icuin66.dll and icuuc66.dll), which don't get automatically packaged yet. Please add these three DLLs to the list in create_release_package() in the bootstrap script.
Sorry for inconvenience, the official build node uses an old MXE where these changes are not necessary or even can cause build failures. It is just for people who start afresh.
Quote from: eumagga0x2a on August 19, 2023, 09:34:15 PMYou haven't read the how-to then. It is explicitly stated there that fluxSmooth and ivtvDupeRemover cannot be compiled with the updated gcc in MXE (the assembler code needs a fix).
It was quite painful to get this far... did read those instructions, but obviously forgot.
I followed that instruction and the one about python. It actually built some files this time... have yet to test.
You will need to copy the icu*.dll libs mentioned above manually from MXE into the Avidemux program directory, else it won't run.
Struggling a bit trying to get the python from my old script for CLI working...
adm.audioCodec(0, "FDK_AAC", "bitrate=320", "afterburner=True", "profile=2", "sbr=False");
Tried including bitrate_mode and other things...
Also struggling trying to convert that to VBR 5 (Highest quality). No luck yet.
Disclaimer: I was able to test on Linux only, so if the library in MXE lacks functionality, adding any features to plugin will have no effect at best and break the encoder at worst.
Please have a look at the modified structure holding encoder parameters: https://github.com/mean00/avidemux2/blob/master/avidemux_plugins/ADM_audioEncoders/fdk-aac/fdk_encoder.h (or configure the encoder graphically, export project script and re-use relevant parts in other scripts).
Quote from: eumagga0x2a on August 20, 2023, 06:45:30 PMDisclaimer: I was able to test on Linux only, so if the library in MXE lacks functionality, adding any features to plugin will have no effect at best and break the encoder at worst.
Please have a look at the modified structure holding encoder parameters: https://github.com/mean00/avidemux2/blob/master/avidemux_plugins/ADM_audioEncoders/fdk-aac/fdk_encoder.h (or configure the encoder graphically, export project script and re-use relevant parts in other scripts).
Hrmm.. I was honestly unaware of the project export ability... Imagine all the time spent using Google + 'trial and error'!
Perhaps bitrate must be set to 128 in all VBR cases (as UI locks to this)?
Let me look into it..
--
Can I ask you a separate question? Through "trial and error".. mostly error, I ended up downmixing the audio (5.1->stereo) of the same file about 20 times. I noticed the final output had a pretty drastic shift. I calculated it to about ~50ms per run. Is this normal? Or did I goof something else up?
Bitrate is ignored when in VBR mode (set by library to -1 internally, see Avidemux log). The configuration dialog disables the bitrate menu exactly in order to stop people from contemplating the best value ;D
I am unaware of any audio delay introduced by downmixing. Do you refer to downmixing in audio filters or to special case of downmixing in the a52dec (liba52) AC3 decoder?
Confirmed.. VBR5 working with..
adm = Avidemux()
adm.videoCodec("Copy")
adm.audioClearTracks()
adm.setSourceTrackLanguage(0,"Eng")
adm.audioAddTrack(0)
adm.audioCodec(0, "FDK_AAC", "bitrate=128", "bitrate_mode=5", "profile=2", "afterburner=True")
adm.audioSetMixer(0, "STEREO");
adm.audioSetDrc(0, 0)
-----
On the delay...
To make a long story short.. I stumbled onto this delay using my script where I copy the video directly and create one audio track from the original file, downmixed to 2.0 (using above params).
In testing (and failing) at initially getting VBR working via my python script.. I ended up running the script 15-20 times against the same 5 second file. The output became the new input, became the output, input again... on and on. After those 15-20 times, opened the video.. and noticed the audio was way off.
So, I decided to do a controlled test. I ran the process exactly 50 times against the same file, that was modified after each run and used again. After 50 times, noticed the audio was seconds out of sync. So, started over again and eventually increased the shift, ran the 50 processes again. Once I added -50ms shift for each run.. after 50 times, video and audio were completely in sync -- or at least, within my perception.
I suppose the issue w/ this test is that it is going from 2.0 to 2.0... not 5.1 or 6.1 to 2.0..
Does the cumulative loss of sync after multiple generations of processing depend on the presence of B-frames in the video or on the container (e.g. MKV vs MP4)? Does it depend on audio encoder (libavcodec vs fdk-aac)?
In this test... it is always FDK-AAC... after the first encode, I am using the same file that is encoded over and over again. It is all I have tried this with.
Your B-Frame question.. I cannot answer. I am not as well-versed in this area as yourself :) I will need to go to the books on that.
I've updated MXE setup scripts and the how-to, now cross-compiling should work "out of the box".
I tried it out... did work out of the box.
Thank you, this feedback is actually very helpful right now.
Just for clarity: Did you use Avidemux source including the latest bump of libaom version to 3.7.0? If you did, you should be able to increase "speed" in the configuration of the AV1 (libaom) video encoder to 11 (which should work with 3.7.0 when "realtime" "usage" is selected).
Quote from: eumagga0x2a on September 09, 2023, 07:54:29 AMThank you, this feedback is actually very helpful right now.
Just for clarity: Did you use Avidemux source including the latest bump of libaom version to 3.7.0? If you did, you should be able to increase "speed" in the configuration of the AV1 (libaom) video encoder to 11 (which should work with 3.7.0 when "realtime" "usage" is selected).
I did everything by the book per the cross-compiling.txt.... cloned the repo, ran mxe-setup.sh, then the 64-bit compile command. I hope that answers your question. If not, I will try again!
I do have a question..
Most of the time when I use avidemux, I'm doing a direct copy of video and downmixing audio. I notice CPU usage is very low during this process. I think at one point, I am bottlenecked on HDD... but is there anyway to increase CPU usage, specifically via python script?
Quote from: MswolJ on September 09, 2023, 09:09:07 PMI hope that answers your question.
No, it doesn't as the repo is a moving target (sometimes a fast moving target).
Quote from: MswolJ on September 09, 2023, 09:09:07 PMIf not, I will try again!
Honestly, this would be an overkill. There was some work done (https://github.com/mean00/avidemux2/commits/master) on libaom-based AV1 video encoder plugin recently, it would be nice to know whether the code you cloned already included these changes. "Help" --> "About Avidemux" shows the hash of the last commit in your local clone. Alternatively, opening the configuration dialog of the AV1 (libaom) encoder and being able to increase "Speed" to 11 hints at the (currently) latest code.
Quote from: MswolJ on September 09, 2023, 09:09:07 PMI'm doing a direct copy of video and downmixing audio. I notice CPU usage is very low during this process. I think at one point, I am bottlenecked on HDD
Audio processing in Avidemux should be on a separate thread. I don't think that muxing itself can be reasonably multi-threaded, and neither is FDK_AAC (AFAIK). While most video encoders allow some multi-threading, tunable by an option in the plugin configuration and thus via tinyPy scripting, none of audio encoder plugins and hardly any of the audio encoder libraries support multi-threading.
When you mux into a MP4, the biggest speed gain could be reached by disabling optimizing for streaming which otherwise rewrites the entire file in-place (moving the index from the end to the beginning of the file), a very slow operation when performed on a harddisk.
f645a801d9b-fflibs 6.0
aom speed only goes to 10.
For "fun", I cloned and compiled again.
This time... dd023f161ea-fflibs 6.0
But aom speed still stops at 10
For the range of the "speed" parameter in the configuration dialog of the AV1 encoder plugin to be 0-11, libaom in MXE must be at version 3.7.0. That said, if you only compiled Avidemux afresh but didn't re-create MXE, the resulting Avidemux will still use libaom 3.6.1 with "speed" parameter range of 0-10 (actually, 0-6 for "good quality" and 5-10 for "realtime", but we cannot reflect such fine details in GUIs created using Avidemux toolkit).
The tricky / expensive part is MXE, not Avidemux. Rebuilding MXE was taking over 5 hours on my previous hw, down to less than an hour on my current one. Still a major effort comparing with a full Avidemux build talking less than three minutes now.
Correct, did not re-create MXE. I didn't measure.. but yes, MXE took around an hour. I am running things in a fairly restricted VM though...