[Ffmpeg-devel] [PATCH] x264 interface update

[Robert Swain]

Hello,

On 12/20/05, Michael Niedermayer <michaelni at gmx.at> wrote:
> Hi
> On Tue, Dec 20, 2005 at 08:50:36AM +0000, Robert Swain wrote:
> > What do you mean about flags1 being ported?
>
> there was the old system for setting stuff in AVCodecContext and the new
> through AVOption ...

OK.

> > > [...]

> > > avcodec_get_context_defaults() could _maybe_ be changed to extract and set all
> > > the defaults for AVCodecContext (patch welcome assuming this has no sideeffects)
> >
> > I wasn't suggesting that this be done. I just meant to enquire as to
> > whether putting s->ratetol = 1.0; in avcodec_get_context_defaults()
> > would produce the correct default value. I did some further testing
> > and in fact the default values in options[] are completely ignored.
> > Why are they there? Legacy? A hint at the default? Not updated to use
> > them yet?
>
> the default values in options[] should be used but arent yet, you can either
> set defaults in options[] and avcodec_get_context_defaults() or change the
> later to extract them from options[]

I've had a quick look at using avcodec_get_context_defaults() to
extract from options[] but encountered a problem which may make
another method preferable.

Some options depend on others, such as bit_rate_tolerance =
bit_rate*10. I could add something to indicate whether an option had
been set or not according to whether it depends on other variables or
not and then run an avcodec_fix_context_defaults() to set the
remaining options in whatever order is required.

The other method is to alter the meaning of those variables that do
depend on others such that they are orthogonal. That would be much
neater to me but I don't think that would get accepted. :) The
remaining method would be to set defaults in
avcodec_get_context_defaults() as we are now. Do you have any
suggestions?

> > The cqm* variables don't work. I don't know why, but all the strings
> > are coming through as null. The -cqm option is the most important in
> > my opinion, because JM format cqm file input is the most convenient.
> > Otherwise I think these have to be char * variables. :/

Getting back on topic for this thread, do you know why the cqm string
variables in the patch are not functioning as they should? And are you
happy with the cqp variable?

Rob