[Ffmpeg-devel] [PATCH] vbr audio encode

[Rich Felker]

On Sat, Aug 13, 2005 at 08:26:09PM -0400, Justin Ruggles wrote:
> Rich Felker wrote:
> > On Sat, Aug 13, 2005 at 06:15:14PM +0200, Michael Niedermayer wrote:
> > 
> >>Hi
> >>
> >>On Sat, Aug 13, 2005 at 12:40:13AM -0400, Justin Ruggles wrote:
> >>
> >>>Hello,
> >>>
> >>>The patch for vbr audio is pretty much ready.  From what I can tell, the
> >>>only codecs that support vbr are all external to ffmpeg (vorbis, lame,
> >>>faac).  After this, I might revisit simplifying the work I was doing on
> >>>adding vbr to ffmpeg's ac3 encoder, but that's for another day.
> >>>
> >>>I did implement both normalized & codec-specific quality scales.  The
> >>>normalized scale follows a similar pattern as video quality, using 0.01
> >>>to 255.  The options I chose were '-aq' for normalized, and '-aqc' for
> >>>codec-specific.
> >>>
> >>>The guideline I've used is to scale the normalized value to codec value
> >>>by holding to 0.01->best, 255->worst, and 128->default.  This can result
> >>>in a non-linear scale, but keeps uniformity of intent across codecs when
> >>>using the normalized scale.  A linear scale actually works for lame, but
> >>>that won't always be the case.
> >>
> >>a normalized scale if you want to add one should have the property that
> >>value X for one encoder gives approximately the same quality as value
> >>X for another encoder, that also contradicts a default == 128 rule
> >>
> >>iam not sure though if this is worth the work, maybe we should just
> >>drop the normalized scale support idea ...
> > 
> > 
> > I agree, normalized is not very useful..
> > It's really almost impossible to compare quality levels between
> > codecs, at least without intensive double-blind testing.
> 
> Sounds good to me.  I was going on the (pretty loose) assumption that
> the default values for an encoder give about the same quality, but
> you're right that it's not very accurate & it might even change over
> time as the libraries develop.  I'll resubmit the patch without the
> normalized scale and just do bounds checking in each encoder.  This will
> take some of the complexity out as well (flag2, extra variables).
> 
> About using a float value.  This is consistent with video.
> ffmpeg.c line 106:
> static float video_qscale = 0;

ffmpeg.c != lavc
If you check, lavc uses an integer for qscale. ffmpeg.c just uses
floats to present an mpeg-quantizer-lookalike scale to the user.

Rich