[MPlayer-dev-eng] Re: [PATCH] tv color controls

[Ivan Kalvachev]

2006/3/26, Alban Bedel <albeu at free.fr>:
> On Sun, 26 Mar 2006 16:21:19 +0300
> "Ivan Kalvachev" <ikalvachev at gmail.com> wrote:
>
> > 2006/3/26, Alban Bedel <albeu at free.fr>:
> > >
> > > Hi,
> > >
> > > currently the tv color controls can't be really used interactivly. Their is
> > > some commands to change them but they are not bound by default, and it is
> > > imho a bit awkward to have 2 different set of controls.
> > >
> > > So here is my take at the problem. This patch first add a function to the
> > > tv api to query the current color settings and fix tv_set_colors_options()
> > > to give a correct return value (and not success in all case).
> > >
> > > Then it fix the v4l input to avoid rounding problems when converting from
> > > the internal v4l range (0/65535) to mplayer's range (-100/100). Currently
> > > the v4l driver use a 2nd order polynomial to convert the contrast value,
> > > that seems totaly useless and it would make the back conversion a pain.
> > > So i changed it to use the same linear approximation as all the other color
> > > controls.
> > >
> > > Finnaly it add the needed code to the color control property and a bunch of
> > > options to control the behaviour. -notv-colors disable the whole thing
> > > giving the old behaviour. -notv-contrast, -notv-hue, etc disable single
> > > controls, this can be needed if the card/driver is buggy or too
> > > limited (like v4l who can't report that it doesn't support a specific
> > > control).
> >
> > I would like if you are not creating 8 new global options that are
> > used only by  v4l. Better add them as -tv suboptions.
>
> They are not specific to v4l, they will work for any tv input. The problem
> with the -tv suboption is that it's common to mplayer and mencoder. But
> these options only make sense with mplayer.

We have hue,saturation etc.. in the -tv options.

> > In case you wonder what key binding to use, i think that the
> > coresponing keys (1,2,3,4) but with pressed shift would make most
> > sense (!@#$)
>
> No, the whole point of this patch is the exact opposite, i don't want
> yet another set of keys.

I hope you are not replacing or overriding the same functionality of
vo. It would be outrageous.

Aafter looking twice in the code, it seems like you do).
This is inacceptable.