[FFmpeg-devel] [PATCH] libmpcodecs support

[Reimar Döffinger]

On Sat, Jan 15, 2011 at 03:45:09AM +0100, Michael Niedermayer wrote:
> > > > Also vf_yvu9 is documented as "Deprecated in favor of the software
> > > > scaler". So I doubt it is a good idea to keep it.
> > > 
> > > why is it not droped from mplayer?
> > 
> > Probably because libmpcodec is mostly un-maintained since years, and
> > that the few person touching it fear removing anything, just in case
> > somebody might still be using it.
> > And maybe also to avoid breaking old scripts using "mplayer -vf yvu9".
> 
> suggest on mplayer-dev to remove it, if its really useless it should be
> removed from mplayer not just our copy

I do not know about this specifially, but usually there is one very special
corner-case that is not 100% (or only in a suboptimal way) implementable
using the other filter.
Usually that kind of thing is only changed if there is an issue with that filter,
otherwise there's not that much reason to make an effort to remove it.

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