[MPlayer-G2-dev] transcode filters

[D Richard Felker III]

On Tue, Apr 20, 2004 at 07:41:11PM +0400, Mikhail Ramendik wrote:
> 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?)

Someone who understands the theory behind video processing. You can
make an argument that there should be a good concept manual with
chroma shifting as a topic, for people who don't understand. Go ahead
and write it if you like. :) But when one filter can naturally do two
operations, and do so more efficiently by doing it that way, there's
no reason to make two separate filters.

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

Inverse telecine does not naturally make duplicate frames. We didn't
"hide" the decimation process inside the inverse telecine filters;
it's simply not happening.

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

It's called *gasp* decimate!

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

No. It would just mean there was essentially one app. With lots of
stupid mindless frontends for the same basic code. All with the same
limitations. And the same bugs. And the same slowness.

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

There's a little "duplicate" work, but for a good reason: because one
project does not like the approach the other one takes to solving a
problem. If they did, they would just reuse/port code from the other,
or not even write the other one to begin with.

Rich