[gst-devel] Re: [MPlayer-dev-eng] Re: [matroska-devel] Re: Common Opensource codec API

[Tuukka Toivonen]

On Thu, 25 Dec 2003, Attila Kinali wrote:

>> >>so, basically i think it would be interesting to see if it is possible
>> >>to agree on a common standard for free multimedia plugins, especially
>Leaving all politcal reasons aside, i don't think that this is as
>easy as you believe.

Certainly it is not easy. Or this thread wouldn't be necessary.

>Beside imho it wouldn't be a good idea. The power of opensource
>comes from diversity, if you restrict that by using a common plugin

If this diversity means that things just don't work, I disagree. And I feel
that this would be the result, because there are devices that produce video
in their own formats. Before any application can do anything with
these devices, they must understand the format. This can be achieved by
either doing format conversion in the kernel--which isn't a good idea nor
even allowed by the master kernel hackers--or by a plugin system that is
adhered by all applications.

A plugin must be delivered along with a device driver, but it makes no
sense to make one for each application. That would defeat the whole purpose
of device-independent API of drivers.

(Yet another method would be vloopback device, but I don't know much about
it, wouldn't it be quite inefficient?)

>interface code, so porting code from one interface to another
>(w/o optimizing to the new interface) is quite easy.

Maybe, if somebody does it. In many cases, nobody would do it, and there
would be cases "this web camera is supported by MEncoder but not xawtv".
Too little devices are supported in Linux anyway.

>The only place where a common api makes imho sense are the codecs
>as this code is quite complex and only a few people have enough

Hmm, maybe I'm ignorant, but if there's a common API for codecs why not
other even simpler things too?

>knowledge to handle that stuff properly. But there, we already have
>a quite common api for codecs: libavcodec

Yeah, and Gstreamer. Probably others too. Multiplicity is the problem.

>> >What I'd love to see is the codec API not being an actual lib, but just
>> >a protocol, like X.
>That's imho a quite bad idea. If you have ever written anything
>time critical with using X11 than you know how much time you loose
>just for the protokol conversion. Nevertheless X11 is a great protokol

I would understand "a protocol" same thing as "ABI". It's the API that
could be implemented differently e.g. in C++ and C and Python and Perl but
the protocol or ABI could be efficient, not necessarily pipe-oriented. When
passing around image buffers it certainly makes no sense to copy the data
through pipe if it's possible just to pass a pointer. This is how Gstreamer
already works even though it's "pipeline-oriented", as far as I understand.

What might make sense is to have a standard API but _not_ an ABI, because
it would allow just recompiling filters/codecs. I'm not sure if this makes
the problem any easier, though.