[MPlayer-G2-dev] transcode filters

[D Richard Felker III]

On Wed, Apr 21, 2004 at 12:52:29AM +0400, Mikhail Ramendik wrote:
> 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?

Well maybe it uses a kernel deinterlacer on the parts it decides to
deinterlace. I don't know. I haven't read the code or even tried it.

> And smartdeinter is at least understandable as Windows-speak; kerndeint

How is that understandible? What information does it convey? Nothing.

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

We don't cater to people who are too stupid to realize that the same
word can mean different things in different contexts. The people who
will be confused by this are the same stupid nerds who expect to see a
gui element when someone asks for a menu at a restaurant. FYI, a
kernel is a function k which is used to generate an integral operator
K, as in:

         /`
 Kf(x) = | k(x,y) f(y) dy
        ./

Often k(x,y) will be a function of x-y only, in which case you
actually have a convolution.

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

Because that sounds pompous, like we have some authority to define
what the API should be for everyone. Instead we'll make an API we
like. If others like it, they can use it. If not, they can write their
own.

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

This is not a valid analogy, for many reasons.

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

Most of the cpu time is spent wastefully copying buffers or converting
between colorspaces.

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

Only modify if you want to use the new libs. Otherwise you're free to
stick with the old ones.

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

No. What's wrong is for someone to make a proprietary NLE program that
uses GPL codecs, filters, etc.

Rich