[FFmpeg-devel] [PATCH] Apple RPZA encoder

[Jai Menon]

On 3/30/09, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Mon, Mar 30, 2009 at 10:17:43AM +0530, Jai Menon wrote:
>  > On 3/25/09, Michael Niedermayer <michaelni at gmx.at> wrote:
>  > > On Tue, Mar 24, 2009 at 03:39:11PM +0530, Jai Menon wrote:
>  > >  > On 3/24/09, Jai Menon <jmenon86 at gmail.com> wrote:
>
> [...]
>  > >  > +/* tuning parameters */
>  > >  > +#define SIXTEEN_COLOR_THRESH        24
>  > >  > +#define SKIP_FRAME_THRESH           13
>  > >  > +#define START_ONE_COLOR_THRESH      8
>  > >  > +#define CONTINUE_ONE_COLOR_THRESH   0
>  > >
>  > >  Encoders, especially such simple ones should be build to be RD optimal
>  > >  in as many aspects as possible
>  >
>  > The "parameters" so to say, give a good tradeoff between final output
>  > size and quality. But I don't think I understand correctly. If we were
>  > to use 16 colors everywhere, the output size will be absurdly large.
>
>
> please read doc/rate-distortion.txt
>  and if you dont understand it please try to explain what you dont understand
>  so i can improve it

I took some time off to wade through that doc. From what I understand,
I'll need a metric to represent the distortion and output rate.
Assuming I use a simple variant like least squares or sum of absolute
differences or whatever, I still don't understand how I can visualize
and RD curve for this (rpza) case. Do I fix the output size and
iterate over possible values for the lagrangian parameter to minimize
the bit cost? If I do that, I still don't quite get how I can
correlate that bit cost to rpza block coding. Any insights appreciated
:)

-- 
Regards,

Jai