[FFmpeg-trac] #2686(avcodec:open): Native AAC encoder collapses at high bitrates on some samples

FFmpeg trac at avcodec.org
Mon Sep 23 20:21:39 CEST 2013


#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]:
 > 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
 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


More information about the FFmpeg-trac mailing list