AAC encoder acting very strangely

[TCmullet]

Sometimes I have to process a defective audio track.  I convert from the 128 kbps vbr AAC that came with my video to .WAV.  Then I do Audacity processing.  Then I select my new wav to mux back into the video, encoding to aac.  I prefer to encode the audio to a higher bitrate than the original so as to preserve quality as much as possible.  Sometimes I'd set it to 224.  Generally, my output is going to get reencoded again later, so a high bitrate here is only intermediate.

What is strange is when I set the bitrate to 384kbsp.  When I set to 128, it takes about 2-3 minutes to re-encode the file.  (audio is aac/lav and video mode is set to "copy".)  BUT, when I set the audio bitrate to 384kbps, it takes LONGER, a whopping 12+ minutes!  I have NEVER known an audio encoder's speed of operation to be affected by the target bitrate.  Yes, the output file is bigger, but I/O time for writing a file where the audio is 4X bigger should not be significantly longer as the bulk of the file processing is still video data which has not changed.

Why is 384 taking a LOT longer than 128???

[eumagga0x2a]

Please specify the AAC encoder and the muxer you are using. Does the issue affect a particular encoder or all AAC encoders equally?

[TCmullet]

For aac, I always use "lav", only because I've never been able to find any info about the 2 choices and why one would pick one over the other.  Yes, it's "lav".

And these are TS files, with high video bitrate H264 video.

[eumagga0x2a]

Please test with other AAC encoders and with other muxers (esp. mp4v2 because it doesn't use the bundled libavformat) so that the issue can be located.

[TCmullet]

I don't understand why I have to run a battery of tests beyond the 2 that I did.  So I have to encode via the other aac codec with 128 and 384 bitrates also?

(I thought there would be a simple explanation as to why a higher bitrate takes a lot longer, that I wasn't aware of.)

(I am using 2.7.1 64-bit.)

[eumagga0x2a]

I don't understand why I have to run a battery of tests beyond the 2 that I did.

Offloading the inital assessment of the problem to the reporter might help to locate the problem and maybe speed up the search for a fix. Whoever is going to investigate the issue will have to run this "battery of tests" first.

So I have to encode via the other aac codec with 128 and 384 bitrates also?

Yes, to be able to judge how bitrate affects the encoding speed for the particular encoder.

(I thought there would be a simple explanation as to why a higher bitrate takes a lot longer, that I wasn't aware of.)

No, no idea.

(I am using 2.7.1 64-bit.)

I don't think that a recent nightly would behave differently here, but using nightly is usually preferable both from the point of view of the best possible experience as well as for reporting bugs.

[eumagga0x2a]

I can confirm that the lavc AAC encoder becomes very slow at high bitrates (640 kbit/s is more than 4x slower than 128 kbit/s). Other AAC encoders are not affected with FAAC being by far the fastest. The issue is not muxer-related.

[eumagga0x2a]

By the way, the same speed degradation at higher bitrates when encoding to AAC affects ffmpeg itself, so the problem is probably located within libavcodec. In an unlikely case that nobody has reported it yet, you might want to report this issue to ffmpeg developers then.

[TCmullet]

Thank you for those confirmations.  I almost didn't even report it here, as I am drowning in dozens of videos I have to get out each week.  But as this tool is free, I feel obligated to at least report it.  I don't feel I would have the technical basis for reporting it to any group outside this one.

It was only my broader experiences with mp2, mp3, and other audio encoders that it seemed odd that the TARGET bitrate could affect encoding speed at all (with any significance).

While we're on the topic of AAC encoders, as there are only two in the dropdown list, FDK and lav, could you please tell me what you know about how one would decide which to use (for the layman)?  I don't know what "FDK" or "lav" really mean.  But I just want to know how to make an intelligent, valid (and of course non-harmful) decision.  I don't know why you mentioned your "FAAC" as that is not one of the dropdown choices.  To be specific, are the encoded outputs different in any way?  Hopefully not.  But then there's still the mystery of why use one over the other.

[eumagga0x2a]

I tested on my main system, i.e. on Linux, where faac libs are installed, so Avidemux picks them during build. FDK should be at least as good as lavc or even better.

FDK is an AAC encoder developed by the Fraunhofer Institute. lavc = libavcodec, a core component of FFmpeg, used by numerous multimedia applications like VLC and also by Avidemux.

Of course, encoder output differs between different encoders. This is the very purpose of having more than one single encoder.

[TCmullet]

Of course, encoder output differs between different encoders. This is the very purpose of having more than one single encoder.

This has not been obvious, as I've always thought the ONLY difference between one encoding and another is the bitrate.  If there can be any difference about the encoded files IF the bitrates are the same, it sure would be nice to see a comparison somewhere so that one can pick their encoder intelligently.  "Just listening for a few seconds" to each output is not going to be good enough.  I always thought the *standard* (for aac, mp2, mp3 or whatever) dictated exactly what the output must look like for a given bitrate, and that the multiple encoders was simply "me too".  (Although I did read years ago that Fraunhoffer's MP3 "Pro" was smaller files with same quality as non-Pro.  But I thought that was probably due to an enhanced standard.)

[eumagga0x2a]

The most obvious starting point would be https://trac.ffmpeg.org/wiki/Encode/AAC

Any lossy encoding is a tradeoff between the audible quality and the bitrate, so "just listening" to the results with the particular audio source in mind is IMHO the best way to choose the best compromise.

[TCmullet]

I agree, but I was referring to differences between aac audio encoders *at the same target bitrate*.

For now, as you haven't given me any reason why I should consider switching from lav to FDK, I'll stick with lav.  And as I cannot wait 15-20 min. for each 384kbps encode, I'll settle for a tradeoff at 224kbps, taking 5-7 min. (vs 2-3 for 128).  All sources are 128kbps to begin with before I convert to wav and do audacity massage.  I'm just wanting to avoid "compression" generation loss, especially as each file I create is an intermediate file to receive a final video and audio compression later.  Would like to use a high value of 384 or higher, but takes too long for the value received.

And somewhere, I thought I discovered that these encodes are all VBR anyway, with the specified bitrate being the Maximum bitrate, not the average or constant.   (Btw, my video source is all 14mbps cbr until I finally feed it into a last audio/video encode which will optimize all for a lower bitrate.)