Feature Request: VBR Mode and Cutoff/Bandwidth for FDK AAC

[eumagga0x2a]

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).

[MswolJ]

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).

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?

[eumagga0x2a]

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

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?

[MswolJ]

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..

[eumagga0x2a]

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)?

[MswolJ]

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.

[eumagga0x2a]

I've updated MXE setup scripts and the how-to, now cross-compiling should work "out of the box".

[MswolJ]

I tried it out... did work out of the box.

[eumagga0x2a]

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).

[MswolJ]

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).

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?

[eumagga0x2a]

I hope that answers your question.

No, it doesn't as the repo is a moving target (sometimes a fast moving target).

If not, I will try again!

Honestly, this would be an overkill. There was some work done 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.

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

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.

[MswolJ]

f645a801d9b-fflibs 6.0

aom speed only goes to 10.

[MswolJ]

For "fun", I cloned and compiled again.

This time... dd023f161ea-fflibs 6.0

But aom speed still stops at 10

[eumagga0x2a]

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.

[MswolJ]

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...