[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