#2686: Native AAC encoder collapses at high bitrates on some samples ------------------------------------+----------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Changes (by cehoyos): * keywords: native aac encoder sound quality 256kbps 320kbps => aac * version: 1.0.7 => git-master * component: FFmpeg => avcodec Comment: Did the output (aac) files sound better with the (original!) release 1.2? (Not a later release of the 1.2 series.) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:1> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples ------------------------------------+----------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by Kamedo2): Oops, you said original release 1.2. Release 1.2 and 1.2.1 had the same behavior -- the first sample collapses at 432-464kbps. As for N-54096-ge41bf19 I've got from git -- the first sample collapses at 256-432kbps. These two groups have the distinct "degradation range". Release 1.2 and 1.2.1 have much narrower degradation range, and the 1.2* is less severe at the range. N-54096-ge41bf19 at 352kbps is the worst quality. {{{ ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers built on Jun 20 2013 03:06:34 with gcc 4.8.1 (GCC) configuration: --enable-version3 --enable-nonfree --enable-libfdk-aac --extra- ldflags=-static --extra-cflags='-march=native' --optflags=-O2 libavutil 52. 18.100 / 52. 18.100 libavcodec 54. 92.100 / 54. 92.100 libavformat 54. 63.104 / 54. 63.104 libavdevice 54. 3.103 / 54. 3.103 libavfilter 3. 42.103 / 3. 42.103 libswscale 2. 2.100 / 2. 2.100 libswresample 0. 17.102 / 0. 17.102 [flac @ 03295c20] max_analyze_duration 5000000 reached at 5015510 microseconds Input #0, flac, from 'C:\Users\PCC\Documents\ABC- HR\ffmpeg_aac320k_collapse.flac ': Duration: 00:00:18.01, bitrate: 573 kb/s Stream #0:0: Audio: flac, 44100 Hz, stereo, s16 Output #0, mp4, to 'C:\Users\PCC\Documents\ABC- HR\05-true_my_heart_2m50s_320k_12 .mp4': Metadata: encoder : Lavf54.63.104 Stream #0:0: Audio: aac ([64][0][0][0] / 0x0040), 44100 Hz, stereo, fltp, 32 0 kb/s Stream mapping: Stream #0:0 -> #0:0 (flac -> aac) Press [q] to stop, [?] for help size= 289kB time=00:00:18.01 bitrate= 131.3kbits/s video:0kB audio:285kB subtitle:0 global headers:0kB muxing overhead 1.321136% }}} -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:3> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by cehoyos): * keywords: aac => aac regression * status: new => open * reproduced: 0 => 1 -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:5> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by cehoyos): Without trying myself, I would bet that the patch only applies to current git head. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:7> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by cehoyos): I can confirm that the patch does not apply. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:9> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): I successfully applied the patch. klaussfreire's repository is in here. http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/143216.html Or, you can use https://dl.dropboxusercontent.com/u/81238453/aac.patch (Thank you Takuan @K4095) to patch from current git head. However, still, it has a distinctive bug. The sound disappears partially when the sound is white noise-like. The bug #2706 was that the sound warbles when the sound was a sine wave. That was solved by this patch, but this creates new problem. {{{ ffmpeg54292 -v 9 -loglevel 99 -filter_complex "aevalsrc=-0.5+random(0)" -c:a aac -strict experimental -ar 4 4100 -ac 2 -b:a 256k -t 4 "C:\Users\PCC\Documents\ABC- HR\whitenoise_256k.mp4" ffmpeg version N-54292-g97947d9 Copyright (c) 2000-2013 the FFmpeg developers built on Jun 30 2013 20:34:13 with gcc 4.8.1 (GCC) configuration: --enable-gpl --enable-version3 --enable-nonfree --enable- libfdk -aac --extra-ldflags=-static --extra-cflags='-march=nocona -mfpmath=sse' --optfl ags=-O2 libavutil 52. 38.100 / 52. 38.100 libavcodec 55. 18.100 / 55. 18.100 libavformat 55. 10.100 / 55. 10.100 libavdevice 55. 2.100 / 55. 2.100 libavfilter 3. 77.101 / 3. 77.101 libswscale 2. 3.100 / 2. 3.100 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 3.100 / 52. 3.100 Splitting the commandline. Reading option '-v' ... matched as option 'v' (set logging level) with argument '9'. Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument '99'. Reading option '-filter_complex' ... matched as option 'filter_complex' (create a complex filtergraph) with argument 'aevalsrc=-0.5+random(0)'. Reading option '-c:a' ... matched as option 'c' (codec name) with argument 'aac' . Reading option '-strict' ... matched as AVOption 'strict' with argument 'experim ental'. Reading option '-ar' ... matched as option 'ar' (set audio sampling rate (in Hz) ) with argument '44100'. Reading option '-ac' ... matched as option 'ac' (set number of audio channels) w ith argument '2'. Reading option '-b:a' ... matched as option 'b' (video bitrate (please use -b:v) ) with argument '256k'. Reading option '-t' ... matched as option 't' (record or transcode "duration" se conds of audio/video) with argument '4'. Reading option 'C:\Users\PCC\Documents\ABC-HR\whitenoise_256k.mp4' ... matched a s output file. Finished splitting the commandline. Parsing a group of options: global . Applying option v (set logging level) with argument 9. Applying option filter_complex (create a complex filtergraph) with argument aeva lsrc=-0.5+random(0). Successfully parsed a group of options. Parsing a group of options: output file C:\Users\PCC\Documents\ABC- HR\whitenoise _256k.mp4. Applying option c:a (codec name) with argument aac. Applying option ar (set audio sampling rate (in Hz)) with argument 44100. Applying option ac (set number of audio channels) with argument 2. Applying option b:a (video bitrate (please use -b:v)) with argument 256k. Applying option t (record or transcode "duration" seconds of audio/video) with a rgument 4. Successfully parsed a group of options. Opening an output file: C:\Users\PCC\Documents\ABC-HR\whitenoise_256k.mp4. detected 8 logical cores [Parsed_aevalsrc_0 @ 0140bea0] compat: called with args=[-0.5+random(0)] [Parsed_aevalsrc_0 @ 0140bea0] Setting 'exprs' to value '-0.5+random(0)' [audio format for output stream 0:0 @ 01412880] Setting 'sample_fmts' to value ' fltp' [audio format for output stream 0:0 @ 01412880] Setting 'sample_rates' to value '44100' [audio format for output stream 0:0 @ 01412880] Setting 'channel_layouts' to val ue '0x3' Successfully opened the file. [audio format for output stream 0:0 @ 01412880] auto-inserting filter 'auto-inse rted resampler 0' between the filter 'Parsed_aevalsrc_0' and the filter 'audio f ormat for output stream 0:0' [AVFilterGraph @ 0039f3c0] query_formats: 3 queried, 6 merged, 3 already done, 0 delayed [Parsed_aevalsrc_0 @ 0140bea0] sample_rate:44100 chlayout:mono duration:-1.00000 0 [auto-inserted resampler 0 @ 0039f2a0] [SWR @ 00393160] Using double precision m ode 0.707107 0.707107 [auto-inserted resampler 0 @ 0039f2a0] ch:1 chl:mono fmt:dblp r:44100Hz -> ch:2 chl:stereo fmt:fltp r:44100Hz Output #0, mp4, to 'C:\Users\PCC\Documents\ABC-HR\whitenoise_256k.mp4': Metadata: encoder : Lavf55.10.100 Stream #0:0, 0, 1/44100: Audio: aac ([64][0][0][0] / 0x0040), 44100 Hz, ster eo, fltp, 256 kb/s Stream mapping: aevalsrc -> Stream #0:0 (aac) Press [q] to stop, [?] for help No more output streams to write to, finishing. size= 141kB time=00:00:04.01 bitrate= 288.4kbits/s video:0kB audio:140kB subtitle:0 global headers:0kB muxing overhead 1.001409% 0 frames successfully decoded, 0 decoding errors [AVIOContext @ 0141b640] Statistics: 30 seeks, 197 writeouts }}} The output mp4 I'm going to post sounds nothing like white noise. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:11> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Another type of holes. There are no holes like this in the original sound, but are present in encoded mp4s. [[Image(http://i41.tinypic.com/axisf5.png)]] -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:13> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by cehoyos): Replying to [comment:14 klaussfreire]:

Sorry, I expected to get email notifications, but got none.

You will get them if you add yourself to CC. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:15> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): In aacenc.c, changing {{{ s->lambda *= ratio }}} by {{{ s->lambda *= sqrtf(sqrtf(ratio)); }}} Fixes the white nose thing, so indeed it's RC messup. But that brings some other trouble in more normal signals, so I guess I'll have to play with RC a little bit more. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:17> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by cehoyos): Replying to [comment:16 klaussfreire]: You may also want to look at ticket #2706. (Is it a duplicate of this ticket?) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:19> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Maybe a very simple one-block one. I've been thinking such a simple lookahead might be enough to fix the bugs, with a better one perhaps for a further patch. I'll give this high priority, but we're only 3 days away from that deadline you know... -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:21> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Alright, attaching another version. This seems to work better, but it's a bit rushed. I'll try to improve on it, but if I delay, feel free to test this version. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:23> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): The patch does not apply, neither. I read http://ffmpeg.org/pipermail /ffmpeg-devel/2013-May/143216.html and http://ffmpeg.org/pipermail/ffmpeg- devel/2013-May/143222.html and guessed what should I do, but still, it fails. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:25> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Very good one! The only serious artifact I've heard so far is whitenoise.flac at 8, 16, 24, 32kbps and 192kbps. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:27> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Replying to [comment:28 Kamedo2]:

Whitenoise.flac at 384kbps, ffmpeg_aac320k_collapse.flac at 320kbps is strange, too.

I didn't try the collapse ones at 320k, though I tried at 384 and sounded nice. I'll try again when I have a chance though. However, whitenoise 384 gives me an error, seems 384kbps is too much for mono. The whitenoise I mention is generated with the random generator, I'll try with the flac first chance I get. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:29> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Isn't line 334 of libavcodec/aacpsy.c: {{{ for (g = 0; g < ctx->num_bands[j]-1; g++) { AacPsyCoeffs *coeff = &coeffs[g]; float bark_width = coeffs[g+1].barks - coeffs->barks; coeff->spread_low[0] = pow(10.0, -bark_width * PSY_3GPP_THR_SPREAD_LOW); coeff->spread_hi [0] = pow(10.0, -bark_width * PSY_3GPP_THR_SPREAD_HI); coeff->spread_low[1] = pow(10.0, -bark_width * en_spread_low); coeff->spread_hi [1] = pow(10.0, -bark_width * en_spread_hi); pe_min = bark_pe * bark_width; minsnr = exp2(pe_min / band_sizes[g]) - 1.5f; coeff->min_snr = av_clipf(1.0f / minsnr, PSY_SNR_25DB, PSY_SNR_1DB); } }}} strange? I doubt the sanity of lower spreading function at the highest band, because using -cutoff 18000 option improves the quality on problematic samples, and these problematic samples always includes strong 20-22kHz sounds. (The default cutoff is 18k at 192kbps, 20k at 256kbps, and 22k at 320kbps.) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:31> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Alright. Good catch. I'd recommend not ignoring, because masking within that band will still be important for bit allocation purposes. Rather, back-spreading rolloff (towards the lower frequencies) should be tweaked a bit. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:33> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Yes, will do this tonight (at work right now). -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:35> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): I hope you're testing with good headphones. HF quality is hard to gauge with speakers, especially since good speakers cost a fortune. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:37> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Replying to [comment:38 Kamedo2]:

Yes, I'm testing with good headphones.

The reason I mention this is because, from my experience, FAAC tends to have a low cutoff for some bitrates, that seem optimal with speakers, but sound noticeably dull with headphones. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:39> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): from line 300: {{{ const int chan_bitrate = ctx->avctx->bit_rate / ((ctx->avctx->flags & CODEC_FLAG_QSCALE) ? 2.0f : ctx->avctx->channels); }}} to: {{{ const int chan_bitrate = FFMIN(ctx->avctx->bit_rate, 240000) / ((ctx->avctx->flags & CODEC_FLAG_QSCALE) ? 2.0 : ctx->avctx->channels); }}} significantly improves the quality. Bitrates remain relatively high in this change. I have not tested all cases, but it works on 256kbps, 320kbps, and 384kbps on many sounds. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:41> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Yeah, but because you're capping psy's bitrate target to non-problematic rates. I don't think that's ideal, though that indeed proves the problem lies in psy. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:43> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): They go up because twoloop will push all scalefactors down uniformly until it achieves the desired bitrate, but: * It won't work with VBR, VBR almost wholly depends on psy to dictate scalefactor band noise floors. Twoloop will push scalefactors down a bit more I think but not much at those high bitrates * It's still suboptimal, it's better to let psy decide, since psy understands perceptual entropy better Sadly, I didn't have time today to work on it. Lets hope I can do so tomorrow. With your analysis I'm confident I can patch psy without having to cap anything. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:45> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Reading the specs right now. I had a hunch that the spec might say something about this. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:47> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Great! I'm goint to have time to test that improvement 5 hours later, so I'm going to test that. Extensively. And I think I have to look for ways to sharpen the LPF, using more order, at the cost of more computational time. Currently it's not very clear cut. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:49> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): The LPF could be accomplished by zeroing the coefficients in the FFT. To get the lowest possible ripple, the boundary coefficient needs some care, but AFAIR it's the best method, and it's free for something that's already doing FFT. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:51> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): [[Image(http://i44.tinypic.com/2s805y0.png)]] I used tx->frame_bits = FFMIN(2560, and psymodel.h line 32: {{{ #define AAC_CUTOFF(s) (s->bit_rate ? FFMIN3(FFMIN3(s->bit_rate/s->channels/2, 4000 + s->bit_rate/s->channels/4, 12000 + s->bit_rate/s->channels/16), 20000, s->sample_rate / 2): (s->sample_rate / 2)) }}} This is better on mono, surround, and on very low bitrates(such as 32kbps stereo). truncut.wav has few HF content, so the bitrate saturates in 172kbps. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:53> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): [[Image(http://i43.tinypic.com/15714c5.png)]] All are stereo. I listened to some of the encoded AACs, and there were no problem. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:55> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Recommended cutoff frequency for FFmpeg AAC. [[Image(http://i41.tinypic.com/28al1fn.png)]] psymodel.h line 32: {{{ #define AAC_CUTOFF(s) (s->bit_rate ? FFMIN3(FFMIN3(s->bit_rate/s->channels/2, 3000 + s->bit_rate/s->channels/4, 12000 + s->bit_rate/s->channels/16), 20000, s->sample_rate / 2): (s->sample_rate / 2)) }}} The LPF is not applied in VBR now, resulting in noticeably poor quality. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:57> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): How about the subjective quality on the various VBR modes, as compared to CBR (actually ABR, since a CBR setting in AAC produces ABR). I worked hard to get good results, but there's still problematic samples, that sound better on equivalent ABR than VBR. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:59> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Replying to [comment:60 klaussfreire]:

Try this cutoff:

{{{ #define _AAC_CUTOFF(bit_rate,channels,sample_rate) (bit_rate ? FFMIN3(FFMIN3( \ bit_rate/channels, \ 3000 + bit_rate/channels/2, \ 16000 + bit_rate/channels/8), \ 20000, \ sample_rate / 2): (sample_rate / 2)) #define AAC_CUTOFF(s) ( \ (s->flags & CODEC_FLAG_QSCALE) \ ? _AAC_CUTOFF(s->bit_rate, s->channels, s->sample_rate) \ : _AAC_CUTOFF((int)(s->bit_rate * (s->global_quality ? s->global_quality : 120) / 120.0), 2, s->sample_rate) \ ) }}} I tried, but isn't this cutoff strange? It sounds like the lowpass is always 20kHz. The problem of ffmpeg_aacvbr_pulse1.flac is solved by this.

I'm using current git head 54813 + aac-improvements- wip-v2-rclookahead.2.patch + aacpsy.c Line 308 {{{ pctx->frame_bits = FFMIN(2560, chan_bitrate * AAC_BLOCK_SIZE_LONG / ctx->avctx->sample_rate); }}} -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:61> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Aren't you trying to access s->bit_rate when it's VBR? Or am I missing something? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:63> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Replying to [comment:63 Kamedo2]:

Aren't you trying to access s->bit_rate when it's VBR? Or am I missing something?

Yes, bit_rate in that case holds the default of 128kbps. Psy does the same, but it works well since that's considered to be AAC's transparent rate. So, for VBR, you make psy work at transparent settings, and compensate bit allocation based on RD scaling. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:65> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): I think I finally got VBR to talk to psy. It's looking good. I'll post an updated patch with all this in a while (still lots of tests to perform) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:67> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Replying to [comment:60 klaussfreire]:

{{{ #define _AAC_CUTOFF(bit_rate,channels,sample_rate) (bit_rate ? FFMIN3(FFMIN3( \ bit_rate/channels, \ 3000 + bit_rate/channels/2, \ 16000 + bit_rate/channels/8), \ 20000, \ sample_rate / 2): (sample_rate / 2)) #define AAC_CUTOFF(s) ( \ (s->flags & CODEC_FLAG_QSCALE) \ ? _AAC_CUTOFF(s->bit_rate, s->channels, s->sample_rate) \ : _AAC_CUTOFF((int)(s->bit_rate * (s->global_quality ? s->global_quality : 120) / 120.0), 2, s->sample_rate) \ ) }}}

I find it works better, the other was was pretty dull for 64k/ch, which ought to be transparent for AAC. This one also works on VBR.

The high cutoff causes trouble for whitenoise.flac below 55kbps. And I'm almost certain 16kHz is optimal at 128kbps stereo. http://d.hatena.ne.jp/kamedo2/20120221/1329845124 http://d.hatena.ne.jp/kamedo2/20120729/1343545890 [[Image(http://i43.tinypic.com/cmhx3.png)]] [[Image(http://i39.tinypic.com/2ecdv0o.png)]] -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:69> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Yes, I'm fixing the lower frequency right now. It's a matter with tonal band priorization that in VBR doesn't really work as intended. I'm preparing a better patch now. I'll test your cutoffs. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:71> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): After two days of toying around, the butterworth filter used in psy is actually counterproductive. Keeping all things equal, lowering the cutoff actually increases bitrate, if a fixed RD is forced. So, for VBR, it's a no-no. I'm trying an FFT-based LP by simply zeroing coeffs, with care at the boundary to minimize ripple, and it seems to work a lot better, at least for VBR. Right now, the implementation is just a POC. It's very dirty. But I'm getting convinced this is '''the''' way for VBR... and maybe for ABR too. I'm not sure. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:73> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): You're right, the one I have done right now is MDCT, because it's done within the bit allocator. But I've been meaning to implement an actual FFT filter later on, if not too hard, and '''if''' the technique pans out. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:75> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): BTW, wait before you redo that graph, I have a much better VBR patch almost ready. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:77> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by cehoyos): I believe your latest patch contains trailing whitespace (that cannot be committed to FFmpeg git), consider running tools/patcheck over the diff. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:79> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): [[Image(http://i41.tinypic.com/28mo7jn.png)]] Very strange behavior, and whitenoise.flac at -q:a 1 completely lacks LF contents. Somehow, this encoder tends to omit the lowest tone in white noise which is audible. -q:a 1.7 and -q:a 2.7 (the peak of bitrate) of whitenoise.flac is strange, too. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:81> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Ah, yeah, I know. It's probably the scaler offset. It must be unpredictable in whitenoise because of how flat the envelope is. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:83> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): I notice that the LPF on some short blocks is not working in at least -q:a 0.3 and 0.4. [[Image(http://i42.tinypic.com/okor9c.png)]] ||=Stereo Bitrate=||=VBR number=|| ||32||0.14|| ||64||0.25|| ||96||0.33|| ||128||0.39|| ||160||0.46|| ||192||0.55|| -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:85> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Replying to [comment:86 klaussfreire]:

I just want to preserve the HF component of transients. There might be better ways of doing that. I guess I'll keep iterating on it. However, I believe the way it's being done now works well. If you check, the LP cutoff is chosen from the allocation given by psy. Psy contains bit reservoir logic, which means it will momentarily increase bits (and cutoff) for some difficult transients. Right now, it works wonders for hi- hats.

I will probably have to be stricter about the cutoff, though. As you say, when the signal by itself (not by psy's indication, but signal strength alone) suddenly jumps in HF content, the result is unpleasant. I

So, if there is a group of beat sounds that is on the threshold of tonal/transients, the LPF is sometimes on and sometimes off? Currently, the on/off switch itself is audible and is quite annoying. It sounds like a stopwatch. think I have cleaned up most of those cases, but who knows. It's hard to discern those from actual transients. ffmpeg_aacvbr_pulse1.flac at -q:a 0.25 produces strange HF sounds. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:87> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): You seems to be using the heuristics that transients HF components are loud and tonal HF components are quiet. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:89> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Seeing the spectrogram, sometimes, up to 22kHz is encoded. No way we can hear that high. However, because of your algorithm, the cutoff seems to be much higher than it actually is, and the sound is much clearer in typical cases. But we have to be careful of exceptions. I think I feel strange when the encoded_highest_sound - normal_cutoff is more than 3kHz. Sounds something like plip, plip. Is coarse quantization at cutoff~cutoff*1.2 applied only to transients? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:91> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Is that included in a wip-v3-vbr.patch, or a new feature? It sounds like the extra HF content encode is only on transients. And some transients are indeed encoded up to 22kHz. Are HF contents over cutoff*1.2 totally discarded? (I believe this is the best move.) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:93> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Replying to [comment:93 Kamedo2]:

Is that included in a wip-v3-vbr.patch

Are HF contents over cutoff*1.2 totally discarded? (I believe this is

Yes the best move.) No, and maybe that's the problem. 1.2 just happens to be the point at which the increased quantization floor starts zeroing out all components. Until that, RD optimization brings down the quantization floor to maintain acceptable quality, so you don't notice the floor rising (and it fact it doesn't for fully tonal bands, that's what RD optimization is about, whereas it does rise for noisy ones). So, in essence, up to cutoff * 1.2, tonal components are retained at the expense of HF noise, which seems like a sensible tradeoff. What must be happening, is that, on some signals, the zeroing point happens above 1.2, significantly above. So it's perhaps wise to hardcode that 1.2 value, and force a zero on those bands instead. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:95> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): So, I tracked the anomaly near -q:a 1 to the ESC_BT codebook. It seems when noise floors are too low, the coefficients can't be properly encoded, and all kinds of bad things ensue. I'll see how to fix it. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:97> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): That's why I want to get rid of the butterworth. It's good, but FFT is better, since it's phase-linear. With all the quantization noise I don't think we care that much about ripple, but even if we did, FFTs can be made to minimize it. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:99> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Is the comment:97 fixable? I think it will contribute to higher quality in 160kbps and 192kbps. Currently, it is still worse than the mighty Apple AAC. I assume most blocks are long(1024 samples) tonal blocks, and short, transient blocks are rare, that are apparently causing problems, am I right? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:101> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Isn't aaccoder.c line 787~795 strange? I believe somewhere making cutoff value or using cutoff value should be the source of the trouble, which causes weird sounds in low bitrates such as -q:a 0.25. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:103> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Wow, great! -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:105> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Don't worry, for the new patch I'm using refbits instead of destbits, refbits is a direct derivation of lambda, so it won't change. I couldn't make the changing bandwidth work in a stable fashion without a lot more work, so I'll reserve that for a further patch, maybe. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:107> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Is the patch available now? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:109> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Damn. The patch works wonderfully well in VBR, but breaks CBR. I'll have to look into it during the weekend. Patience indeed. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:111> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): I've encoded weeks of AACs using v3 patch, using diverse samples and diverse bitrates and there were no problem(empty files, return with errors, freezes). -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:113> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Attached the current WIP. An explanation of what caused the bug for high q values: there was a bug in psy's threshold reduction for hole avoidance. When a second pass was needed, it would accumulate errors due to a simple typo (reduction += instead of reduction =). I don't have the 3GPP spec to check, but I just noticed the code made no sense with the +=, but did with =. Then there's the ESC_BT thing. I think most serious anomalies have been fixed in this bug, I haven't had time to properly test CBR, but it seems to mostly work now. That was very subtle bit reservoir a bug on my "lookahead" patch that didn't surface until I fixed psy. Anyway, I still would like to make VBR achieve lower bitrates without having to resort to LP filtering. I somehow sense it should be possible. In any case, I made CBR also use the same scalefactor-band-based LP filtering to remove the need for the butterworth that didn't save many bits anyway, and now it responds to the -cutoff argument, so if you don't like the default cutoff you can override yourself. It seemed worth parameterizing since I've found some sources that sound better at low bit rates with higher cutoffs, and some that don't. So it's source-dependent. Anyway, enjoy the patch, I'm not sure I'll have time to work on a more permanent (one that I'd push to trunk) one till next weekend. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:115> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): [[Image(http://i44.tinypic.com/2m43o9i.png)]] -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:117> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Yes, I was in the middle of tweaking rdlambda scale for VBR (which is what gives the tonality boost). It seems way off target for VBR, since a lambda that in VBR results in 64kbps, in CBR it will give you about 32 or less. With that properly tweaked, we can save lots of bits from noisy bands and put them to better use on tonal bands. For VBR, that means lower bitrates for the same quality level. Increasing cutoff like you did there has the unwanted side effect of lowering quality a bit too much on tonal bands, for a set file size. I do my tests by searching through -q:a until I get a file roughly the same size as a reference CBR-encoded version, and comparing quality among those. With higher cutoffs, that procedure resulted in noticeable distortion on the HF bands, which is why I left it at 1.6, and it's what I believe will be fixed by tweaking rdlambda for VBR. It can also be fixed by implementing codebook 13. But that's for another (future, way future) patch, since I see no easy way to implement CB 13 with twoloop, so I'll have to rewrite it. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:119> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Cool paper. Still, everything seems quite specific to Opus. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:121> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Yep, the cutoff is used as-is in this patch, the offset is already accounted for in its computation above that. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:123> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Or, I can drop fdk-aac and instead test on 3 bitrates. Do you have any idea? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:125> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Replying to [comment:126 cehoyos]:

Comparing with libfaac would be useful... Is comment:69 not enough? (The test was in 2012 July.)

-- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:127> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): I don't think many people will use libfaac. Both libfaac and libfdk_aac are non-free, and if many people prefer fdk-aac over faac, the new results of the new fdk-aac is more interesting than the another results of the old faac. (As far as I know, there are no blind test of fdk-aac.) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:129> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): This is not my last test, and for a desire to compare this encoder with other encoders, I can do so later. By that time, I hope the new VBR is the state-of-the-art encoder. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:131> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by puck): Hi All, Great to see that the native AAC encoder is getting some attention, and trying to make it mainstream. Using Windows 7 and Zeranoe's FFmpeg builds, I only get a choice of "The Native Encoder" or "libvo_aacenc". From what I have read "libvo_aacenc" only seams to support sterio not 5.1 or higher. I am no audiophile and a little hard of hearing so I cannot find fault with the Native Encoder but I can tell the difference between 2 and 6 channels :-) Keep up the good work on a great piece of software. Regards, Mark -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:133> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): [[Image(http://i44.tinypic.com/mijaq8.png)]] http://www.hydrogenaudio.org/forums/index.php?showtopic=98003 -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:135> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Oops, samples # 10 ~ # 12 and # 13 ~ # 16. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:137> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Great, I'm guessing it's the reason why some samples got much poorer results than the fdk. Should I abort the v4 abr test and instead test on v5 after the release of 5? I'm on holiday now, but after August 26th, I'll move to more quiet place, so I can test more effectively. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:139> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): How is the development of v5? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:141> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): I resumed the ABC/HR test, and I've done 10 samples out of 20. How is the development going? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:143> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Timothy_Gu): * cc: timothygu99@… (added) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:145> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Yes, please do. I'll make sure to address those concerns as well, and we'll save one round trip -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:147> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Oops, -b:a 128k, not -b:a 96k in the 128kbps exp+v4 column. By the way, why is the FFT used in LPF? Couldn't it use MDCT and simply zeroing higher coefficients? Maybe I am missing something. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:149> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by cehoyos): Replying to [comment:150 Kamedo2]:

and possibly... - libopus, vbr - libmp3lame, vbr

Do you have any idea?

If you have time, it would be interesting to compare to the quality of other FFmpeg audio encoders, ie ac3, eac3 and mp2. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:151> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by cehoyos): Replying to [comment:152 Kamedo2]:

Replying to [comment:151 cehoyos]:

...

If you have time, it would be interesting to compare to the quality of other FFmpeg audio encoders, ie ac3, eac3 and mp2. It may be wrong, but I guess the ac3 is the most used variant. The bitrate will be around 128kbps, so the extremely high bitrate of eac3 will not fit the frame,

I am not sure I understand you. Afaik, nobody ever made a listening test using different internal FFmpeg encoders (not even a very cursory one). It would be interesting to know that "96kb eac3 ~ 128 kb ac3 ~ 128kb aac ~ 256kb mp2" (I assume this isn't the case, just as an example). Even if done with much less effort than your above tests (if you just mention your impression of each encoder after a few tests), I believe this would be interesting information. It was sometimes claimed that the wma encoders produce abysmal quality, so your comment on them (possibly with higher bitrates) would also be welcome.

I think. Are there some important use of eac3 and mp2, other than the BD and VCD encoding? (For BD the space is huge and quality at lower bitrate is insignificant.)

I believe that ac3 is a very important codec (WMP plays it out-of-the-box in different containers), knowing if eac3 beats it would be interesting. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:153> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): This document recommends to use -cutoff 15000 option. Too outdated, the cutoff is automatically applied since July 2012. http://ffmpeg.org/ffmpeg-codecs.html#aac This is the data I sent in 2012. [[Image(http://i41.tinypic.com/24dri41.png)]] By the way, the progress of the listening test is 95%(19/20) now. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:155> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Cool. I'll try to work on this tonight. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:157> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Wow, this is fast! It's constantly doing more than 90x realtime on all the bitrate range on all kinds of music! -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:159> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): I listened to about 8 hours of songs, movies, sine and white noise, and 5.1ch surround source. I'd say that abr is mature. klaussfreire, could you add a "redirect" feature that when set bitrate is too high, redirect to the maximum bitrate possible, rather than to print the error message and stop. This simplify many batch encodes, including when encoding from hundreds of videos that have various audio frequencies and number of channels. Currently it gets: {{{ [aac @ 013efa60] Too many bits per frame requested }}} Also, I notice that this commandline {{{ ffmpeg -i ffmpeg_aacvbr_pulse1.wav -c:a aac -strict experimental -q:a 0.1 -ar 8000 -ac 1 ffmpeg_aacvbr_pulse1.mp4 }}} gets the same Too many bits warning, and lowering the quality -q:a don't work. It only works when using -b:a, or setting higher frequency such as -ar 22050. It could be a problem when encoding from a video taken by some old digital cameras with 8kHz pcm audio attached. The error message: {{{ ffmpeg56470.exe -y -i ffmpeg_aacvbr_pulse1.wav -c:a aac -strict experimental -q:a 0.3 -ar 8000 ffmpeg_aacvbr_pulse1.mp4 ffmpeg version N-56469-gf6622f9 Copyright (c) 2000-2013 the FFmpeg developers built on Sep 20 2013 15:29:55 with gcc 4.8.1 (GCC) configuration: --enable-gpl --enable-version3 --enable-nonfree --enable- libfdk -aac --extra-ldflags=-static --extra-cflags='-march=native -mfpmath=sse' --optfl ags=-O2 libavutil 52. 45.100 / 52. 45.100 libavcodec 55. 33.100 / 55. 33.100 libavformat 55. 18.100 / 55. 18.100 libavdevice 55. 3.100 / 55. 3.100 libavfilter 3. 86.102 / 3. 86.102 libswscale 2. 5.100 / 2. 5.100 libswresample 0. 17.103 / 0. 17.103 libpostproc 52. 3.100 / 52. 3.100 Guessed Channel Layout for Input Stream #0.0 : stereo Input #0, wav, from 'ffmpeg_aacvbr_pulse1.wav': Metadata: encoder : Coderium SoundEngine 4.59 Duration: 00:00:12.12, bitrate: 1411 kb/s Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, stereo, s16 , 1411 kb/s [aac @ 030cbf00] Too many bits per frame requested Output #0, mp4, to 'ffmpeg_aacvbr_pulse1.mp4': Metadata: encoder : Coderium SoundEngine 4.59 Stream #0:0: Audio: aac, 8000 Hz, stereo, fltp, 128 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s16le -> aac) Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height }}} I think this is about time we remove the -strict experimental flag. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:161> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): 15x speed is 'tolerable' :) I've encoded more than 50GB of mp4s, including surround 5.1ch with more than 1Mbps etc... and listened to 12 hours of mainly Pop music. v5 seems to be stable. Is fixing "Too many bits per frame requested" error easy? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:163> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): I prefer warnings, rather than the error messages and stop. Kind, and easier to use. By the way, I'll be free from September 28th, and I'm considering a listening test of - v4 abr - v6 abr - v6 vbr - fdk-aac vbr - ac3 abr - libmp3lame vbr I've got a request of testing libfaac, mp2, and eac3, but I'm running out of the "slot". From my normal non-blind listening of average music, my current impression is: {{{ fdk-aac > libmp3lame > v5 abr >> v4 abr > v5 vbr > ac3 }}} -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:165> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Well, v6 is almost ready. I just need to clean it up a bit. I'll probably do that tonight. In v6, my non-blind tests make me believe that {{{v6 vbr > v6 abr > v5 abr}}}. Not sure how you compare abr vs vbr, what I do is pick a file or set of files, do a binary search of the quality level that results in the same overall file size, and then compare. In that kind of test, v6 vbr sometimes requires '''lots''' more bits for some pathological files (techno seems to drive it crazy, can't blame it). I exclude those, since they're pathological. When I push the patches to the ML, I'll make most of what makes v6 vbr go crazy on techno (the relatively high peak bit rate allowance) configurable anyway. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:167> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

Replying to [comment:167 klaussfreire]:

...

Not sure how you compare abr vs vbr, what I do is pick a file or set of files, do a binary search of the quality level that results in the same overall file size, and then compare. In that kind of test, v6 vbr sometimes requires '''lots''' more bits for some pathological files (techno seems to drive it crazy, can't blame it). I exclude those, since

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Replying to [comment:168 Kamedo2]: they're pathological.

I compare abr vs vbr by a graph. I plot a "q vs bitrate" graph over a

"standard" set of large set of sounds I extracted from diverse CDs. Yeah, I've seen those

Then, search a number of q that have the desired bitrate. Then, make sure that average tested sample bitrate isn't very far from the "standard" bitrate.

Just '''how''' do you check bit rate? Because I've noticed {{{ffmpeg -i file}}} tends to give bogus rates when used on VBR-encoded files (not even average).

Also, I think it's beneficial for the end users to set the -q:a value and typically gets a file with the bitrate around the set value. If one sets -q:a 256k, one gets a file of roughly 256kbps.

That's not doable without refactoring ffmpeg. -q:a sets the global_quality parameter, which is specified to have a somewhat standardized interpretation (1.0 = 100%, what 100% means is what some other codec means by it, can't remember which OTOMH). However, you can get (I think) a similar result by specifying both -q:a and -b:a, like so: {{{ ffmpeg -i somefile.flac -c:a aac -b:a 256k -q:a 1 -strict experimental somefile.aac }}} Although that seldom gives you 256k. The bitrate there is like a lower bound (aim for 256k, spend more if needed). -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:169> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Replying to [comment:170 Kamedo2]:

...

...

Then, search a number of q that have the desired bitrate. Then, make sure that average tested sample bitrate isn't very far from the "standard" bitrate.

Just '''how''' do you check bit rate? Because I've noticed {{{ffmpeg -i file}}} tends to give bogus rates when used on VBR-encoded files (not even average). {{{filesize[Byte]*8/Sample_length[Sec]}}}, But be careful of very short files, it can be bogus too.

As long as you're not also estimating sample_length with ffmpeg, which will also give you bogus, it should be fine ;)

...

...

Also, I think it's beneficial for the end users to set the -q:a value and typically gets a file with the bitrate around the set value. If one sets -q:a 256k, one gets a file of roughly 256kbps.

That's not doable without refactoring ffmpeg. -q:a sets the global_quality parameter, which is specified to have a somewhat standardized interpretation (1.0 = 100%, what 100% means is what some other codec means by it, can't remember which OTOMH). Is LAME breaking the convention?

https://trac.ffmpeg.org/wiki/Encoding%20VBR%20%28Variable%20Bit%20Rate%29%20... I think so. At least, it seems to be backwards (higher q should mean higher quality, but lame does it backwards). -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:171> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Timothy_Gu): Replying to [comment:170 Kamedo2]:

...

...

Also, I think it's beneficial for the end users to set the -q:a value and typically gets a file with the bitrate around the set value. If one sets -q:a 256k, one gets a file of roughly 256kbps.

That's not doable without refactoring ffmpeg. -q:a sets the global_quality parameter, which is specified to have a somewhat standardized interpretation (1.0 = 100%, what 100% means is what some other codec means by it, can't remember which OTOMH). Is LAME breaking the convention?

https://trac.ffmpeg.org/wiki/Encoding%20VBR%20%28Variable%20Bit%20Rate%29%20...

...

However, you can get (I think) a similar result by specifying both

-q:a and -b:a, like so:

...

{{{ ffmpeg -i somefile.flac -c:a aac -b:a 256k -q:a 1 -strict experimental

somefile.aac

...

}}}

Although that seldom gives you 256k. The bitrate there is like a lower bound (aim for 256k, spend more if needed). Thank you for the info. Your behavior seems much like the cvbr(most used mode), Apple iTunes.

If someone is to implement cvbr, I suggest to do it like the libopus encoder wrapper, where users are allowed to choose a "vbr" option like this [http://ffmpeg.org/ffmpeg-codecs.html#Option-Mapping]. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:173> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2):

However, you can get (I think) a similar result by specifying both -q:a and -b:a, like so:

{{{ ffmpeg -i somefile.flac -c:a aac -b:a 256k -q:a 1 -strict experimental somefile.aac }}}

Although that seldom gives you 256k. The bitrate there is like a lower bound (aim for 256k, spend more if needed).

I tried it over 128 different songs and the result was: {{{-b:a 256k -q:a 1}}} - Average 247kbps - SD +/-33kbps - Min 161kbps - Max 300kbps {{{-q:a 1}}} - Average 235kbps - SD +/-30kbps - Min 154kbps - Max 287kbps (comment:160 change is not applied in this test.) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:175> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Wait a little bit, I'll get you the v6 patch asap, even if not as clean as I'd like it to be. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:177> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): So... latest patch attached. It's not final yet, mostly because it needs some polish. But its performance I find quite acceptable. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:179> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): This is the statistics of 25 samples I'm going to use in the test. ||= =||=v4 abr=||=v6 abr=||=v6 vbr q0.7=||=FDK vbr3=||=lame V5=||=ac3=|| ||=25 Average=||129||129||144||122||135||128|| ||=25 Std.Dev=||5||5||24||20||18||0|| ||=25 Min=||107||108||114||86||87||128|| ||=25 Max=||131||133||218||173||172||128|| ||=Max sample||25.Reunion Blues||26.French||26.French||10.||14.||29.|| ||=Std.Average=||128||128||127||127||130||128|| Unit is kbps. Std.Average is the average bitrate of my large collection of CDs encoded. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:181> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): [[Image(http://i43.tinypic.com/i53u6t.png)]] -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:183> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): PS: In aaccoder.c:1007, you can change {{{ //if (mb >= ESC_BT) break; }}} Into {{{ if (mb >= ESC_BT && sce->sf_idx[w*16+g] <= minscaler) break; }}} I think that could help, because, I believe, those bitrate peaks are due to abuse of ESC_BT bands. And that could also be the reason why some faint sounds get lost even at high Q, because AAC enforces a maximum dynamic range in scalers, and abusing of ESC_BT bands pushes that dynamic range in detriment of faint sounds. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:185> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Well, I've got something that might work, but since it means unconstraining vbr, it'll need some testing at lower bitrates. It'll take me time. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:187> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Nice, this will be useful. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:189> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Which version should I test? With or without comment:185? Or should I wait for something? I'm doing a batch encode, so I can redo anything without much effort. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:191> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Sorry about the delay. I wanted to give you a 6b patch, since I was making good progress, but I got stalled yesterday. I managed to remove (or, rather, ameliorate) those bitrate outliers, without constraining VBR. I noticed they were related to silence parts. It seems in the absence of any significant signal, it will try to encode the noise, and being noise, it's quite hard to encode. What I did is I modeled the absolute hearing threshold in aacpsy, and now that's performing better. But there's still a tendency to waste bits on noisy transients. I couldn't quite yet confirm it's a waste, all my attempts at saving bits in those, run afoul quality-wise. As if those bits were really needed. But I suspect there's still some work to be done in that regard. So in essence, I achieved some extra efficiency by modeling absolute hearing thresholds. Since you never know what SPL will the sample be playing at, I matched the masking curve's lowest point to 16-bit quantization noise. That should correctly match most playback situations, but I'd like people to comment if there was an explicit reason why absolute thresholds haven't been accounted for. As for your testing plans, you tell me. I can give you the current state of the encoder (I don't expect to do any more progress quickly, I tried lots of things and failed to improve it, so unless I get some kind of inspiration the encoder will remain as is for a while), or you can test the current one. Bitrate-wise, they're similar. The newest one performs a little better since it's unconstrained, but it still has a disadvantage against ABR regarding tonal, quiet passages. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:193> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Is the 6b patch available? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:195> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Just for convenience, The most outlier sample in below is death2 (for v6 + comment:185, q=0.7, 1). The rate is highest, and encodes slowest. http://www.rarewares.org/test_samples/ -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:197> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): It doesn't encode 7.1ch surround file from here. http://www-mmsp.ece.mcgill.ca/documents/AudioFormats/WAVE/Samples.html I used cbr and other 7.1ch files and the results are the same. {{{ ffmpeg_v6c185.exe -v 9 -loglevel 99 -y -i "8_Channel_ID.wav" -c:a aac -strict -2 -q:a 1 8chwav_q1.mp4 ffmpeg version N-56667-g32cde96 Copyright (c) 2000-2013 the FFmpeg developers built on Sep 29 2013 23:03:27 with gcc 4.8.1 (GCC) configuration: --enable-gpl --enable-version3 --enable-nonfree --enable- libfdk -aac --enable-libfaac --enable-libmp3lame --extra-ldflags=-static --extra- cflags ='-march=nocona -mfpmath=sse' --optflags=-O2 libavutil 52. 46.100 / 52. 46.100 libavcodec 55. 33.100 / 55. 33.100 libavformat 55. 18.102 / 55. 18.102 libavdevice 55. 3.100 / 55. 3.100 libavfilter 3. 87.100 / 3. 87.100 libswscale 2. 5.100 / 2. 5.100 libswresample 0. 17.103 / 0. 17.103 libpostproc 52. 3.100 / 52. 3.100 Splitting the commandline. Reading option '-v' ... matched as option 'v' (set logging level) with argument '9'. Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument '99'. Reading option '-y' ... matched as option 'y' (overwrite output files) with argu ment '1'. Reading option '-i' ... matched as input file with argument '8_Channel_ID.wav'. Reading option '-c:a' ... matched as option 'c' (codec name) with argument 'aac' . Reading option '-strict' ... matched as AVOption 'strict' with argument '-2'. Reading option '-q:a' ... matched as option 'q' (use fixed quality scale (VBR)) with argument '1'. Reading option '8chwav_q1.mp4' ... matched as output file. Finished splitting the commandline. Parsing a group of options: global . Applying option v (set logging level) with argument 9. Applying option y (overwrite output files) with argument 1. Successfully parsed a group of options. Parsing a group of options: input file 8_Channel_ID.wav. Successfully parsed a group of options. Opening an input file: 8_Channel_ID.wav. [wav @ 016bf2e0] Format wav probed with size=2048 and score=99 [wav @ 016bf2e0] File position before avformat_find_stream_info() is 128 [wav @ 016bf2e0] parser not found for codec pcm_s24le, packets or times may be i nvalid. [pcm_s24le @ 02c666e0] Channel layout '5.1' with 6 channels does not match speci fied number of channels 8: ignoring specified channel layout [wav @ 016bf2e0] parser not found for codec pcm_s24le, packets or times may be i nvalid. [wav @ 016bf2e0] Probe buffer size limit of 5000000 bytes reached [wav @ 016bf2e0] File position after avformat_find_stream_info() is 5002208 Guessed Channel Layout for Input Stream #0.0 : 7.1 Input #0, wav, from '8_Channel_ID.wav': Duration: 00:00:08.05, bitrate: 9216 kb/s Stream #0:0, 1226, 1/48000: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, 7.1, s32, 9216 kb/s Successfully opened the file. Parsing a group of options: output file 8chwav_q1.mp4. Applying option c:a (codec name) with argument aac. Applying option q:a (use fixed quality scale (VBR)) with argument 1. Successfully parsed a group of options. Opening an output file: 8chwav_q1.mp4. Successfully opened the file. detected 8 logical cores [graph 0 input from stream 0:0 @ 02cd9ac0] Setting 'time_base' to value '1/48000 ' [graph 0 input from stream 0:0 @ 02cd9ac0] Setting 'sample_rate' to value '48000 ' [graph 0 input from stream 0:0 @ 02cd9ac0] Setting 'sample_fmt' to value 's32' [graph 0 input from stream 0:0 @ 02cd9ac0] Setting 'channel_layout' to value '0x 63f' [graph 0 input from stream 0:0 @ 02cd9ac0] tb:1/48000 samplefmt:s32 samplerate:4 8000 chlayout:0x63f [audio format for output stream 0:0 @ 037acf80] Setting 'sample_fmts' to value ' fltp' [audio format for output stream 0:0 @ 037acf80] Setting 'sample_rates' to value '96000|88200|64000|48000|44100|32000|24000|22050|16000|12000|11025|8000|7350' [audio format for output stream 0:0 @ 037acf80] auto-inserting filter 'auto-inse rted resampler 0' between the filter 'Parsed_anull_0' and the filter 'audio form at for output stream 0:0' [AVFilterGraph @ 02d4fee0] query_formats: 4 queried, 6 merged, 3 already done, 0 delayed [auto-inserted resampler 0 @ 03672580] ch:8 chl:7.1 fmt:s32 r:48000Hz -> ch:8 ch l:7.1 fmt:fltp r:48000Hz [aac @ 02c66ae0] Unsupported number of channels: 8 Output #0, mp4, to '8chwav_q1.mp4': Stream #0:0, 0, 1/90000: Audio: aac, 48000 Hz, 7.1, fltp, 128 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s24le -> aac) Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [AVIOContext @ 0390e260] Statistics: 0 seeks, 0 writeouts [AVIOContext @ 016bf900] Statistics: 5013504 bytes read, 0 seeks }}} -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:199> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): FFmpeg crashes when the sampling rate is 7350Hz, both vbr and abr. Insignificant, but in case you have missed something. It worked on 96000, 88200, 64000, 48000, 44100, 32000, 24000, 22050, 16000, 8000Hz. {{{ ffmpeg56668.exe -v 9 -loglevel 99 -y -i ffmpeg_aac_lead_voice.flac -c:a aac -str ict -2 -ar 7350 -b:a 128k ffmpeg_aac_lead_voiceb128.mp4 ffmpeg version N-56667-g32cde96 Copyright (c) 2000-2013 the FFmpeg developers built on Sep 29 2013 23:03:27 with gcc 4.8.1 (GCC) configuration: --enable-gpl --enable-version3 --enable-nonfree --enable- libfdk -aac --enable-libfaac --enable-libmp3lame --extra-ldflags=-static --extra- cflags ='-march=nocona -mfpmath=sse' --optflags=-O2 libavutil 52. 46.100 / 52. 46.100 libavcodec 55. 33.100 / 55. 33.100 libavformat 55. 18.102 / 55. 18.102 libavdevice 55. 3.100 / 55. 3.100 libavfilter 3. 87.100 / 3. 87.100 libswscale 2. 5.100 / 2. 5.100 libswresample 0. 17.103 / 0. 17.103 libpostproc 52. 3.100 / 52. 3.100 Splitting the commandline. Reading option '-v' ... matched as option 'v' (set logging level) with argument '9'. Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument '99'. Reading option '-y' ... matched as option 'y' (overwrite output files) with argu ment '1'. Reading option '-i' ... matched as input file with argument '\ffmpeg_aac_lead_vo ice.flac'. Reading option '-c:a' ... matched as option 'c' (codec name) with argument 'aac' . Reading option '-strict' ... matched as AVOption 'strict' with argument '-2'. Reading option '-ar' ... matched as option 'ar' (set audio sampling rate (in Hz) ) with argument '7350'. Reading option '-b:a' ... matched as option 'b' (video bitrate (please use -b:v) ) with argument '128k'. Reading option 'ffmpeg_aac_lead_voiceb128.mp4' ... matched as output file. Finished splitting the commandline. Parsing a group of options: global . Applying option v (set logging level) with argument 9. Applying option y (overwrite output files) with argument 1. Successfully parsed a group of options. Parsing a group of options: input file ffmpeg_aac_ lead_voice.flac. Successfully parsed a group of options. Opening an input file: ffmpeg_aac_lead_voice.flac. [flac @ 0159f2e0] Format flac probed with size=2048 and score=50 [flac @ 0159f2e0] File position before avformat_find_stream_info() is 4374 [flac @ 030866e0] sample/frame number mismatch in adjacent frames Last message repeated 114 times [flac @ 0159f2e0] max_analyze_duration 5000000 reached at 5015510 microseconds [flac @ 0159f2e0] File position after avformat_find_stream_info() is 377856 Input #0, flac, from 'ffmpeg_aac_lead_voice.flac': Metadata: REPLAYGAIN_TRACK_PEAK: 0.67306519 REPLAYGAIN_TRACK_GAIN: -4.18 dB REPLAYGAIN_ALBUM_PEAK: 0.67306519 REPLAYGAIN_ALBUM_GAIN: -4.18 dB COMMENT : Encoded by FLAC v1.1.2a with FLAC Frontend v1.7.1 Duration: 00:00:24.68, bitrate: 471 kb/s Stream #0:0, 50, 1/44100: Audio: flac, 44100 Hz, mono, s16 Successfully opened the file. Parsing a group of options: output file ffmpeg_aac _lead_voiceb128.mp4. Applying option c:a (codec name) with argument aac. Applying option ar (set audio sampling rate (in Hz)) with argument 7350. Applying option b:a (video bitrate (please use -b:v)) with argument 128k. Successfully parsed a group of options. Opening an output file: ffmpeg_aac_lead_voiceb128. mp4. Successfully opened the file. detected 8 logical cores [graph 0 input from stream 0:0 @ 0159f100] Setting 'time_base' to value '1/44100 ' [graph 0 input from stream 0:0 @ 0159f100] Setting 'sample_rate' to value '44100 ' [graph 0 input from stream 0:0 @ 0159f100] Setting 'sample_fmt' to value 's16' [graph 0 input from stream 0:0 @ 0159f100] Setting 'channel_layout' to value '0x 4' [graph 0 input from stream 0:0 @ 0159f100] tb:1/44100 samplefmt:s16 samplerate:4 4100 chlayout:0x4 [audio format for output stream 0:0 @ 03142120] Setting 'sample_fmts' to value ' fltp' [audio format for output stream 0:0 @ 03142120] Setting 'sample_rates' to value '7350' [audio format for output stream 0:0 @ 03142120] auto-inserting filter 'auto-inse rted resampler 0' between the filter 'Parsed_anull_0' and the filter 'audio form at for output stream 0:0' [AVFilterGraph @ 030df400] query_formats: 4 queried, 6 merged, 3 already done, 0 delayed [auto-inserted resampler 0 @ 0307a240] ch:1 chl:mono fmt:s16 r:44100Hz -> ch:1 c hl:mono fmt:fltp r:7350Hz [aac @ 030ed9a0] Too many bits per frame requested, clamping to max }}} How is the development going? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:201> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Sorry, I've been having trouble making good, provable progress with v6b/v7, especially since I've got a few deadlines coming that require lot of my time. I'll try to fix the crashing, and get performance comparable to v6 without the VBR constraints, which I noticed are hurting quality on high bit rates. However, it seems the tendency to spend lots of bits on speech stems from psy itself, not anything else. It seems to estimate speech has a lot of perceptual entropy. It may be true, but there is some inefficiency that's hard to fix without deviating from the standards. So v7 will probably just address the bugs, crashing, some bugs in tonal band priorization in short window blocks, and stuff like that. About 7.1ch, there's another ticket for that, IIRC. While I will still take a look with the report in this ticket, I'd suggest you post the relevant bits on that ticket as well (for traceability you know) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:203> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

However, it seems the tendency to spend lots of bits on speech stems from psy itself, not anything else. It seems to estimate speech has a lot of perceptual entropy. It may be true, but there is some inefficiency

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Replying to [comment:203 klaussfreire]: that's hard to fix without deviating from the standards. Allocating less bits on short frame may help. It should increase the quality, although a strong tonality estimator is ideal. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:205> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

Replying to [comment:155 Kamedo2]:

...

This document recommends to use -cutoff 15000 option. Too outdated,

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Timothy_Gu): Replying to [comment:204 Timothy_Gu]: the cutoff is automatically applied since July 2012.

...

http://ffmpeg.org/ffmpeg-codecs.html#aac

Hi, I wrote the documentation. Thanks for the report for that. However, I currently don't have any time to fix the doc. So it would be very kind of you to send a patch to ffmpeg-devel mailing list. Thanks.

Patch sent. http://ffmpeg.org/pipermail/ffmpeg- devel/2013-October/149225.html -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:207> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): I'll be free from October 16th. klaussfreire, could you provide the current status of the encoder in 16th? I'd be happier if it reduces the bitrate on speech samples, but even when it doesn't, I'll start the test. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:209> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Sorry, I had the intention of posting it this weekend, but I've been up to my ears in deadlines. Will see about posting it tonight. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:211> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): klaussfreire, Thank you for all the effort to improve the FFmpeg. I've successfully patched and configured it. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:213> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Replying to [comment:212 klaussfreire]:

v7 patch is attached.

It's not commitable or complete yet. I know it was the idea, but I ran out of time, and since you'll be free and needing improvements to test... well... Will it take long to make the comittable version? If it takes long, maybe I should start testing now. Or, I can wait for more complete version.

-- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:215> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Then I'll start the test. BTW, the sine warbling problem #2706 reappeared in -q:a 0.1, 0.2, and 0.7. 50Hz and 7000Hz sine warbles with v7. Should I test v7, or v6? (+comment:185+comment:206) -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:217> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Seems like a hard problem. If you commit v7, people will have trouble handling the unexpectedly large file size of speech contents such as university lectures, and you probably can't fix it before the conference. Testing v6 may make more sense, probably with comment:185 and comment:206. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:219> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): What was the "quite significant bugs" of v6? I didn't find any problem in a non-blind listening test, and the v6 was extensively tested over many songs, speeches, tv source, and artificial sounds, and I believe v6 is safe and stable. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:221> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Then which version should I test? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:223> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): Comparison between v6 patch and v7 patch. The sound source is: - white noise, 5sec, stereo 48kHz - snippet of music albums, 300sec, stereo 44.1kHz - snippet of TV sources, 1200sec, stereo 48kHz [[Image(http://i43.tinypic.com/2dtnb79.png)]] The progress of the listening test is 8% (2 out of 25 samples). -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:225> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by michael): also the patch should be split into self contained fixes, 1 issue == 1 patch when its submitted to ffmpeg-devel. We can apply a huge monolithic patch too if thats the only option but it will give everyone working on aac headaches (that is you all) when theres a regression and git bisect then ends up just pointing to a huge all in one change. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:227> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): I always intended to push this forward, when testing is done, as a series of smaller patches. I'm not sure I can split all of it, but there are quite a few worthy split points. I think the main issue with the current patch is overall un-tidyness, with dead code left over from earlier attempts at some solutions for instance. That's what I think doesn't make it commitable yet, it has to be cleaned up. Plus, there are quite a few magic numbers that ought to be tunables. The slowness can be fixed later, encoding quality I believe being more important than speed, if needed. It's not '''that''' much slower anyway, still faster than realtime. VBR wasn't even working before, so even if imperfect, any improvements to VBR are commitable. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:229> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Woops. I just fixed M/S encoding. Had to tell ;) I was wondering whether your tests with faac/fdk used M/S encoding? -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:231> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Well, faac has a --no-midside, so I'd venture to guess that the default is to do M/S coding. -- Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:233> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): I'm close to posting a v8. Main improvement in v8 is, besides various subtle but significant bug fixes, that M/S coding properly works and, I believe, is robust enough to be on by default. But v8 won't have it on by default just yet. So, when I post it (I'm performing a last round of listening tests), be sure to run it with {{{-stereo_mode auto}}} to get results comparable to the other contenders. I just wanted to post the progress report early since this ticket has been silent for a while ;) -- Ticket URL: <https://trac.ffmpeg.org/ticket/2686#comment:235> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Sadly, no. I thought so, but further tests (at various bitrates) show saturation. Not the same issue as the original in the OP, but an issue nevertheless. I have only attacked M/S coding and some bit allocation inefficiencies, but the improvement seemed to improve those issues during initial tests since tonal band encoding improved significantly, but it's still not enough it seems to avoid clipping due to quantization noise. Since the original signal is saturated already, I may have a relatively easy fix for it: all quantization noise risks the same artifacts, but I believe there is only one fix, which involves tweaking rounding of strong signals. That needs careful calibration, however, in order to avoid modifying behavior on non-clipping signals (since rounding towards zero generally induces higher SNR), but I'll be travelling soon and won't be able to work much on it till jan 1st. -- Ticket URL: <https://trac.ffmpeg.org/ticket/2686#comment:237> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Kamedo2): The listening test of v4 abr, v7 abr, v7 vbr, libfaac vbr, fdk-aac cbr, libmp3lame vbr, ac3 cbr (7 encoders) at 128kbps is ongoing, and I've done 18 samples out of 25 samples (72%). -- Ticket URL: <https://trac.ffmpeg.org/ticket/2686#comment:239> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker

#2686: Native AAC encoder collapses at high bitrates on some samples -------------------------------------+------------------------------------- Reporter: Kamedo2 | Owner: Type: defect | Status: open Priority: normal | Component: avcodec Version: git-master | Resolution: Keywords: aac | Blocked By: regression | Reproduced by developer: 1 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by klaussfreire): Alright. I'm still not done with the clipping issue (it's proving to be more challenging than I thought). Though I do believe v8 will change things, because of M/S encoding (which all the other encoders you're testing I think use, except ac3, putting ffmpeg's AAC at a significant disadvantage). -- Ticket URL: <https://trac.ffmpeg.org/ticket/2686#comment:241> FFmpeg <http://ffmpeg.org> FFmpeg issue tracker