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

[Michael Niedermayer]

Hi

On Thu, Jun 29, 2006 at 12:45:19AM -0400, Justin Ruggles wrote:
[...]
> > 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

ok, and maybe we can one day even use *partition_order for deciding which
block sizes to use in the videocodecs, it might be somewhat cleaner then
all the flags (partition_order of a block = (width+height)/2)

*prediction_order could similarly one day replace context_model, OTOH
you could use context_model instead of adding 3 new fields
maybe, positive numbers mean single prediction_order, negative mean
all with search method depending on value, i dont know if that would
fit your encoder design plans though?


> 
> In the case of putting all of these in AVCodecContext, does the AVOption
> API provide for setting multiple fields with a single commandline option

no


> or would it have to be done a different way?

yes, set them individually like with video codecs, of course a defaults like
feature could be added, maybe like:

char *AVCodecContext.preset_name / defaults

and defaults set to "high_quality" "fast" and such, this addition of course
would be very usefull for other codecs (like the x264 warper) too


> 
> > 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.

my idea was a viterbi based encoder similar to what loren did in adpcm

a (much) simpler method would be to use a per sample rate distortion
optimization so something like:

for(i=0; i<n; i++){
    predictor= lpc(previous_samples);

    for(j=current_sample - max_distortion; j<=current_sample + max_distortion; j++){
        int rd= number_of_bits_in_golomb(j - predictor)<<16;
        rd += quality * (current_sample - j) * (current_sample - j);
        if(rd < best_rd){
            best_rd= rd;
            best_sample= j;
        }
    }
}

and of course store less then the full 16bits of audio, in such a way
that mostly silent blocks have full 16bit and loud blocks have less as
the distortion should be less audible there, IIRC that can be done
with the "wasted_bits" field in flac

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is