[MPlayer-G2-dev] An open, standard video/audio API?

[D Richard Felker III]

On Sat, Apr 17, 2004 at 10:35:24PM +0400, Mikhail Ramendik wrote:
> And the one thing that I feel is missing in [GNU/]Linux, while present
> (although crippled) in the Non-Free OS, is a clearly defined standard
> API for all multimedia stuff.

Why should there be such a thing? I've seen no good argument except
"windows has one" and that's stupid. Windows also has BSOD.

> A Free Software masterpiece, VirtualDub, is made possible by DirectShow.

No. VirtualDub is NOT a free software masterpiece. It's very buggy and
ugly. I don't think any serious release groups use it, and for good
reason.

> A clear (hmm, theoretically) interface to all possible codecs, the AVI
> file format, and some other stuff is just already there. Yes, it's
> stinky (the 4GB limit, and of course the lack of freedom). 

And the slowness? And the lack of good interoperation? Why do windows
users have to rip .vobs to their hd before they can encode??

> But GNU/Linux has none whatsoever. Video4Linux2 contains some Codec API,
> but who uses it? 

Uhg, v4l is stupid and should have absolutely nothing to do with
codecs.

> As a result, a GNU/Linux program that wants to use codecs, filters, etc,
> has to care about interaction with every library out there. Look at

What is such a program? Either a movie player, editor, or transcoder.
If you have a specialized app, say maybe a game, in which you want to
include video, you only need support for the particular codecs you'll
be using for your movies, not everything out there.

And if all you want is a movie player, you have MPlayer. What use is a
bloated API?

> From the discussion I saw here, it seems that while the MPLayer G2 core
> could be a sort of "clearing center" for multimedia processing under
> GNU/Linux, it will still have a pretty specific API.
> 
> My question: why not aim for a standard, generic, published,
> well-described multimedia processing API, one that would (because of its
> technical benefits and open nature) far surpass DirectShow?

Because it will be poorly designed and slow.

> It should work across machines (not to speak of working across very
> different programs). X-Windows might provide an example. And yes, I
> would support sockets as the main tool, and TCP sockets where possible.
> Among other things, this will allow interoperation of different
> machines, as already done in X.

This is totally idiotic. You don't transport uncompressed video over a
network.

> Just imagine: one machine to grab the source and apply pre-procesing
> filters, another to do the coding, and a third to stream the content,
> all communicating over the Open Multimedia Protocol. This would be the
> *easy* scenario; hard ones would include load balancing.

ROTFL!!! You really need to learn something before writing a proposal.
Your design here is much less efficient than processing on one
computer, not more efficient.

> In most cases of course the API would work on the same machine - but
> still provide nice separation for different tasks, so loved by the Unix
> world. A codec, a filter, a muxer or demuxer, a player would all
> communicate via socket streams. Each one easily replaceable, without
> micro-management from the player (common today). 

Now I need a 3GHz athlon to play a movie? NO THANKS!!!!!!!!!!!!!

> <Use_case> A user has installed a cool hardware MPEG5 decoder. He
> previously used to run MPlayer G2 for playing MPEG5 files; his brother
> ran XMMS G3, and used Transcode to convert MPEG5 to Theora for watching
> on his Zaurus handheld. 

Theora? Very bad idea, and it suggests you're just full of buzzwords
rather than knowledge. Theora is (a) bad compression, (b) bad
implementation, and (c) NOT ANY MORE PATENT-FREE THAN MPEG1/2/4!

> Among other matters, an open socket-based standards might resolve the
> recent licensing issue.
> 
> The problem with hardware player developers, as it seems to be, is that
> they just can't release all of the source to their firmware, because of
> licensing matters with other companies. 
> 
> But what if the components they use will all interact via a standard
> socket interface? In this way, as the GPL FAQ exlicitly says, they can
> use GPL-ed and non-GPL modules together!

HAHAHAHAHHA!
OK, I'm sorry, now you're a total idiot. This is exactly what we DO
NOT WANT!!!!!!!!

> Now for a bit of personal stuff. I am a tech writer with over 5 years of
> experience behind me.

A tech writer with no understanding of the tech. How typical...

> But of course, this is useful only if the developers here are willing to
> go that way. To develop an open standard for interaction between
> multimedia processing components. And to base the development of MPlayer
> G2 on this standard, not an internal API. 

I'm not willing.

> This could be a crucial step for development of GNU/Linux as a user OS.
> This may be an insane raving by a misguided guy. ANyway, replies will be
> very much appreciated :)

Yes, very misguided.

Rich