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

Alban Bedel albeu at free.fr
Sun Mar 26 16:47:50 CEST 2006


On Sun, 26 Mar 2006 17:24:02 +0300
"Ivan Kalvachev" <ikalvachev at gmail.com> wrote:

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

Sometimes i wonder if you really read the patch before posting.
Read again, these options are FLAGS, they have nothing to do with
the initial color settings on the tv input.

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

Why ? On my hw the vo have no color control support, so i would prefer
using the tv capture hw than some slow software filters. BTW if you had
looked closer at the patch you would have noticed that these options you
bitch about are just there to enable what you want: using only the vf/vo
controls.

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

Now calm down a bit. I have no pb with keeping the current default and
making the proposed code optional (instead of the inverse). But compromise
doesn't seems to belong to your vocabulary. REJECT, REJECT, yeah with such
an attitude things will go forward.

	Albeu




More information about the MPlayer-dev-eng mailing list