[Ffmpeg-devel] [PATCH] flacenc - rice param search

[Justin Ruggles]

Michael Niedermayer wrote:
> Hi
> 
> On Tue, Jun 27, 2006 at 10:38:21PM -0400, Justin Ruggles wrote:
> 
>>Michael Niedermayer wrote:
>>
>>>Hi
>>>
>>>On Tue, Jun 27, 2006 at 02:27:06AM -0400, Justin Ruggles wrote:
>>>
>>>
>>>>Hello,
>>>>
>>>>Here is another update for the FLAC encoder.  I only added a few things,
>>>>but it's still a pretty large patch.
>>>>
>>>>1) search for optimal rice parameters and partition order. i also
>>>>modified the stereo method estimation to use this to calculate estimated
>>>>bit count instead of using just the pure sums.
>>>>
>>>>2) search for the best fixed prediction order
>>>>
>>>>3) constant subframe mode (good for encoding silence)
>>>>
>>>>Note that the regression test for the decoded wav file also changed.
>>>>This is due to FFmpeg's FLAC decoder truncating the file, which it did
>>>>before anyway...just at a different cutoff point.  The generated FLAC
>>>>files are still 100% lossless.
>>>>
>>>>With this update, FFmpeg's FLAC encoder has speed and compression
>>>>somewhere between "flac -1" and "flac -2".  On my machine, it's about
>>>>15% faster than "flac -2", and about 10% slower than "flac -1".  The
>>>>encoding parameters are identical to "flac -2" (fixed predictors, 1152
>>>>blocksize, partition order 0 to 3).
>>>
>>>
>>>applied
>>>
>>>[...]
>>>
>>
>>Great! Thanks. :)
>>
>>Now I have a question. I want to eventually add capability for the user
>>to specify the compression level. Would it be okay to use "-aq", which
>>uses avctx->global_quality, for this purpose?  I know it isn't really
>>"audio quality" since it's lossless, but it is compression quality, and
>>this seems like the simplest solution to me.
> 
> 
> no, quality is a distortion vs. bitrate thing not speed vs compressionrate

true. it really isn't the same concept.

> you can either add a option for every indvidually switchable thing or a
> single "compression level", later would certainly be usefull for using 
> external libs in ffmpeg too

Hmm.  Well there are so many options I never considered adding all of
them to AVCodecContext.  There would be six encoding parameters.  My
plan was to use an internal structure in the encoder for these options &
just set them based on the compression level, but if I can put them all
in AVCodecContext that would work, too.  They are:

* use_lpc - whether to use LPC mode or FIXED mode
* min_prediction_order
* max_prediction_order
* prediction_order_method - search method for selecting prediction order
* min_partition_order
* max_partition_order

In the case of putting all of these in AVCodecContext, does the AVOption
API provide for setting multiple fields with a single commandline option
or would it have to be done a different way?

> also note that nothing prevents us from adding lossy support to flac, after
> all the syntax just stores compressed samples, they dont have to be identical
> to the source ...

Hmm...well FLAC is similar to many speech codecs.  What kind of thing
did you have in mind?  I'm trying to imagine what could be done to limit
the bitrate in a lossy way and still use the FLAC bitstream syntax.  The
only thing that pops into my head is using a small frame size and
limiting the bits-per-sample on a per-frame basis.  I'm guessing there
could also be something done to the residual signal that would reduce
the bitrate and would generate a distorted/lossy decoded audio signal.

-Justin