[Ffmpeg-devel] [PATCH] x264 interface update

Michael Niedermayer michaelni
Wed Dec 21 13:40:25 CET 2005


Hi

On Wed, Dec 21, 2005 at 07:25:36AM +0000, Robert Swain wrote:
[...]
> > > > 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?

where is the problem? if the user sets bitrate but leavs the tolerance at
default thats what she wants ...


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

no clue


> happy with the cqp variable?

partly

PS: this can be applied if the x264 devels agree (or dont care) 

[...]
-- 
Michael





More information about the ffmpeg-devel mailing list