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