Re: transcode filters

Hello,

Arpi wrote:

> > 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?)

> > > > decimate - NTSC decimation in pure software
> > > 
> > > What is NTSC decimation?
> > 
> > Removal of duplicate frames. Made as a part of the inverse telecine
> > process. MPlayer seems to have the whole process in one big whopping
> > filter (ivtc or detc); but heck, what if I need this stuff for other
> > purposes? 
> 
> there is such filter for duplicate (very similar) frame removal

I have not found it, but it's probably just me.

> > > > smartdeinter/smartyuv - "smart" deinterlacing, only deinterlaces motion
> > > > areas and keeps the full resoultion in others
> > > 
> > > Similar to pp=md.
> > 
> > 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?

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.

Yours, Mikhail Ramendik