[MPlayer-dev-eng] Re: [xine-devel] Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API

[Enrico Weigelt]

* Guenter Bartsch <bartscgr at t-online.de> [2003-06-29 23:36:52 +0200]:

<snip>
> my point exactly. this is just about defining simple, easy-to-use apis
> for various multimedia plugins/modules. i too think we should just
> define a basic set of functions which each plugin type should support,
> not more. the api should be extensible, though - both, individual
> implementations should be able to add fields and functions as well as
> there should be a possibility to add (probably optional) functions 
> to the api in the future 

ACK.

Perhaps many work is already done (i.e. libavcodec).

On a first thought, I see several modules in this project:

* audio codecs
    --> gets in an encoded audio stream and puts out another encoding
        which can be understood by the clients (e.g. audio hardware)
    --> allows querying available audio codecs and their options
    
* audio playback 
    --> gets in a audio stream (encoded in plain encodings like PCM)
    --> allows querying available audio playback devices, their options
        and supported encodings (ie. to use mpeg support, etc)

* audio recording
    --> pulls out a audio stream (encoded in a plain encoding like PCM)
    --> allows querying available audio recording devices, their options
        and supported encodings ...

* video codecs
    --> just like audio codecs, but for video stuff
    --> also handles scaling, colorspace conversions, ...
    
* video playback
    --> just like audio playback, but for video playback
    --> can take advantage of hardware accelearation, etc
    
* video recording
    --> just like audio recording, but for video
    --> can also use capturing hardware's features (i.e. DVB is already MPEG)

* input stream manager (former demux)
    --> splits off the input stream into substreams
    --> provides a common interface for selecting substreams (i.e. for
        multiple language audio, multiple views)
    --> also supports streaming protocols like rtsp
    
* output stream manager (former mux)
    --> puts multiple streams together to one (i.e. for mencoder or DVB out)
    --> maybe also supports streaming support like rtsp

Such a structure could bring a lot of advantages, i.e. for fully using 
hardware acceleration (MPEG-codec boards, etc), allowing an interface for
proprietary codecs (I ALSO DONT LIKE THEM!) and a very high flexibility
for dozens for applications beside simple video players (i.e. conferencing,
streaming servers, settop-boxes, ...)

But we first have to talk about the features such an API should support
and how it could be extended someday (or perhaps integrated as a subset
into a bigger API), so we can safe for many projects (not only mplayer)
in future.

One tricky point are bidirectional (?) protocols which report network
statistics, etc to the server (i.e. rtsp ?) ...


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/