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

[FFmpeg]

#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%20mp3%20audio

 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