#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%20mp3%20audio
>
>
>
> > 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
_______________________________________________
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
http://avcodec.org/mailman/listinfo/ffmpeg-trac
