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

[Mikhail Ramendik]

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

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

I would really support a socket-based interface.

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

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! 

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

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

> Anyway I would be very happy to have an profesional tech writer
> on our side :)

Warning: I'm somewhat limited on the time front. At present, I probably
won't take up things like detailed GUI descriptions - they take quite a
lot of time and are useful for just one application. But to work on open
standards specs is somewhat different: takes less drudgery, and the
effect is (in case of success) quite significant.

Yours, Mikhail Ramendik