[MPlayer-G2-dev] transcode filters

[Mikhail Ramendik]

Hello,

D Richard Felker III wrote:

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

OK. So why the name change from one stupid name to another stupid name?
And smartdeinter is at least understandable as Windows-speak; kerndeint
is not understandable period (for me a "kernel" is an OS kernel anyway,
and I suspect it's the same for the majority of Linux and BSD users).

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

Point taken. Why not "Open Video API" then? 

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

Well, I see what Microsoft ended up doing when they rejected standards.
I see what Linus Torvalds ended up doing when he went about trying to
implement a standard (Posix). 

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

Slow? Exactly how *can* it be slow (or fast), when by far the most CPU
time is spent in either codecs or filters, and the much of the code
there is the same?

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

And how then can one write anything that is, well not mplayer? Like a
visual recoding tool, a video editor, etc. Write them against a current
version of the MPlayer API, and then have to modify it every time it
changes?

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

What's "use"? Do you consider any processing of your code's output by
proprietary software "use"? If I somehow use mencoder to stream video
over the Net, and somebody receives it and plays it on MS Media Player,
is that wrong?

I *am* for the GPL. It's just a question of where use ends and
interoperability begins.

Yours, Mikhail Ramendik