[MPlayer-G2-dev] transcode filters

[D Richard Felker III]

On Tue, Apr 20, 2004 at 11:55:05PM +0400, Mikhail Ramendik wrote:
> > > > 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
> 
> Then why the strange name change, so that a transcode user would never
> guess it's the same?

The transcode one has a very stupid name. WTF does "smart" mean? It's
windows-speak. "smartyuv" is an especially dumb name, since the basic
filter should either support multiple colorspaces (oh I forgot,
transcode's api is too broken to do this) or use the standard
colorspace for video (yuv).

Now kerndeint is a very stupid name too. It's a motion-adaptive
deinterlacer, which is totally different from a kernel deinterlacer
(e.g. pp=fd).

> > > 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.
> 
> I just think that first, a clear API should be published and promoted as
> an open standard - preparing to be "The Linux Video API", not "the
> MPlayer API".

It's even more stupid to call it something to do with Linux. Linux is
a kernel/operating system (depending on your viewpoint :) which has
NOTHING to do with video. Why should something that's usable on any
semi-sane OS be called the "Linux Video API"??

> It may be that GStreamer is already set up as that. If this is indeed
> so, then perhaps MPlayer should support GStreamer? (I may not like it,
> objects don't seem to belong -- but I think it's important to have a
> standard even if I don't support it).

Uhg. This kind of blind standard-worship really annoys me. Even if a
standard is really horrible, you'll support it just for the sake of
having a standard??

> Once a standard is established - and the word of the MPlayer people
> means *much* in this regard - I think transcode will be under much
> pressure to conform.

I couldn't care less what transcode does. I've always found it slow,
awkward, and just plain broken.

> In fact I agree it should be based on the MPlayer API. But, it should be
> a clean, simple, FIXED (no new versions without backward compatibility),
> and well described standard. Like those that drive the Internet.

No. The internet needs to keep working and interoperating with old and
new systems which are upgraded (or not) independently of one another,
and which use independent implementations of the same standards.
There's no such need with the MPlayer API. I'm against gratuitous
breaking of compatibility, but sometimes it must be done to overcome
limitations in the old design.

> It *may* resolve the licensing debate on the way. Then again it may not.

IMO it has nothing to do with the licensing debate, unless you mean
the stuff you originally wrote about allowing proprietary software to
use our code.

Rich