[Ffmpeg-devel] [PATCH] vbr audio encode

[Justin Ruggles]

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;

But with removing the normalized scale, it's passed directly as an
integer without scaling, so switching this to an integer will suffice.

One strange thing...I noticed that oggenc uses the -1 to 10 scale, but
libvorbis uses -0.1 to 1.0.  Should ffmpeg maintain consistancy with
oggenc or libvorbis?  My first thought was to mirror oggenc, but then
realized that a library API might be more stable over time than a
commandline frontend.  lame and faac use the same values for the lib and
the frontend.

-Justin