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

[D Richard Felker III]

On Sun, Apr 18, 2004 at 02:58:12AM +0400, Mikhail Ramendik wrote:
> Hello,
> 
> Ivan Kalvachev wrote:
> 
> > > (SUMMARY. A general-purpose standard API for all multimedia
> > > processing, including codecs, filters, demuxing etc., would
> > > be very useful in GNU/Linux, and resolve many existing problems,
> > > including licensing. The MPlayer team is the best source for
> > > a standard that could be widely adopted. I would volunteer to
> > > do tech writing work on the spec).
> > 
> > Actually as somebody already have said there is an common api.
> > All players under linux use ffmpeg as primary codec monkey.
> > And the documentation of ffmpeg is smaller than the sample files.
> 
> ffmpeg is not yet a standard. And it does not support all things needed.
> For example, it seems to support DV video but not DV audio (strange, but
> true - it's better at the video than libdv, just no audio!)

We're talking about standard API, not the codec selection. It's not
really relevant that ffmpeg doesn't have DV audio, since it can be
added.

> > If you look for alternative of DirectShow, you may take a look of
> > GStreamer project. It is generally what are you trying to achieve.
> 
> Not really. Well, perhaps it is an alternative - but it assumes too much
> "windoze-like" stuff. And, Gnome is really overkill outside of explicit
> GUI works.

GStreamer uses GNOME? Uhg...

> I would really support a socket-based interface.

This is totally ignorant. (Read slow) Why does there need to be any
IPC? Everything can take place in one process.

> > I don't know details of it. But in general I could say that
> > if we try to use common standart/interface we should make it simple.
> > If we make it simple it won't have best available speed.
> 
> The Unix people have managed to keep stuff simple and yet *very*
> efficient. 

Actually not. It's just that efficiency doesn't matter for processing
text...

> An interface that is simple and yet efficient would be a true work of
> art. Supported by the well-known MPlayer team, it could stand a chance
> of becoming the standard. Not only ffmpeg, but other codecs could
> support it as well - and imagine availability of transcode's big set of
> filters for use outside of transcode, via this API! 

We're largely against a standard API because there's nothing to gain
from it, and all the people who want it want to make an API that
sucks.

> > All complications about direct rendering, slice rendering,
> > out of order rendering is to get maximum speed.
> 
> I think that, given careful analysis, these things could be fit into a
> simple logic. Two streams in each direction, maximum.

Huh? I don't understand what you mean.

> It's only as impossible as playing divx on a K6-200... (I mean, that too
> was impossible before ffmpeg/mplayer).

It's impossible now too except for crappy low-res stuff.

Rich