[MPlayer-G2-dev] transcode filters

[Arpi]

Hi,

> > > The chrominance component shifted to the left or right compared to
> > > luminance. This seems to happen in some broadcast situations. Granted
> > > this is not *widely* necessary.
> > 
> > swscaler can do this, see -ssf
> 
> Oops, thanks.
> 
> (Looks like the real advantage of transcode is a better filter
> documentation. With mplayer, who'd have guessed one needs to look to the
> scaler when one wants to shift color, rather than, well, scale?)

it was a side-effect of swscaler, and as it can be done, no one wrote a
separate filter for this funcion later

> > > 
> > > smartdeinter uses some thresholds (all tune-able) to detect motion
> > > areas, and only applies a deinterlacing algorithm to where it has
> > > detected motion.  (smartyuv is a yuv-optimized version of the same).
> > 
> > kerndeint?
> 
> Will check this out (will need to compile a new version of mplayer for
> that). It's a recent addition, however; transcode had one for quite some
> time. Is this a case of work duplication? Would not a more standard API
> prevent *that* kind of duplication?

afair it is ported from transcode

> The real debate was about the merits of a standard plugin API for
> various video processing apps. I just used the filter situation as an
> example. MEncoder and transcode are two Free Software solutions; they
> lack each other's cool features, and possibly do duplicate work, because
> no such API is present.

but why dont you tell this ti the transcode people?
our filter api is much more powerful than their one. at least we
beleieve so, so we won't go for their api.
also they took and ported many of mplayers filters, so they should have
support our api, and not inverse.


A'rpi / MPlayer, Astral & ESP-team

--
PyMaViS - my answer to worm storm - http://mplayerhq.hu/~arpi/pymavis/