[FFmpeg-devel] [PATCH] libmpcodecs support

[Reimar Döffinger]

On Sat, Jan 15, 2011 at 02:11:28PM +0100, Michael Niedermayer wrote:
> On Sat, Jan 15, 2011 at 12:57:50PM +0100, Reimar D?ffinger wrote:
> > On Sat, Jan 15, 2011 at 03:45:09AM +0100, Michael Niedermayer wrote:
> [...]
> > > > > > I also suspect vf_palette might already be handled by libavfilter.
> > > > > > It might also be worth double checking vf_yuvcsp but I guess this one
> > > > > > is not yet supported by libavfilter.
> > > > > > 
> > > > > > I didn't check the code carefully yet, but I wonder how did you handle
> > > > > > filters like vf_screenshot or vf_hue which require some external
> > > > > > control/command to trigger some actions ?
> > > > > 
> > > > > vf_hue worked when i did a quick test
> > > > 
> > > > Yes, I guess you can set hue at the begining with a parameter and then
> > > > you can't change it dynamically. This is certainly OK for now.
> > 
> > Not sure what exactly you meant to say, but within MPlayer VFCTRL_SET_EQUALIZER
> > handles setting hue.
> > For a player such a control that is handled by whatever filter can handle it
> > has the advantage that runtime changes will be handled in the most efficient
> > way possible without the need for user configuration, for libavfilter that
> > approach is likely too unpredictable though.
> 
> i see nothing unpredictable on it

Let me explain: hue adjustments could be done for free for yuv<->rgb conversions.
This combined with above approach means that the results of the VFCTRL_SET_EQUALIZER will
mean that if you have
-vf swapuv
the behaviour off hue adjustment will be completely different for a RGB vs. a YUV
codec because for RGB you have the filters
scale(convert to yuv), swapuv, output
here hue adjustement would be done in scale, before swapuv.
With YUV input you'd only have
swapuv, output
and thus hue would be adjusted in output, i.e. after swapuv.