[Mplayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.14,1.15

[Fabian Franz]

Am Sonntag, 9. Februar 2003 01:26 schrieb Arpi:
>
> MCF guys said (and says) that we should not support any existing interfaces
> but introduce a new one and implement various wrappers and converters...
> it's silly. the container must be able to contain the existing formats,
> without the need of demuxer/player know how to convert codec details.

agree.

>
> also, each codec has its 'selected' API, depending on its origin.
> so i suggest something like:
> for(;;){
>    byte      codec_header_type if ==0 then break;
>    v         codec_header_len
>    len*byte  codec header bytes
> }

Why not use almost the same format as for packet-info-type, as such

for(;;){
                type                            b
                if(type=="") break;
                codec_header              b
        }

so it would be for example...

[12]WAVEFORMATEX[codec_header_len]len*bytes

Or is this waste of space ?

But it has the advantage, that no-one can mix them up so easily ...

I would like it even better, if it was like info-packet, so codec-specific 
data was no more than a info-packet (but perhaps thats overkill and way too 
complex):

So structure:

 for(;;){
                type                            b
                if(type=="") break;
                name                            b
                value                           b
        }

type: CODECHEADER
name: WAVEFORMATEX
value: [...]

cu

Fabian

>
> and pre-define some types for the alerady existing interfaces, like
> 1=bitmapinfoheader/waveformatex 2=imagedesc/sounddesc 3=mpeg4es/aac etc...
>
> maybe we should separate audio and video versions of the headers, but since
> there are pairs, and the type (audio vs. video) is already given in header
> bytes it has no much sense.
>
> the idea: these headers should be read & passed to the codecs, and it will
> find the right one it requires.
>
> maybe we could reduce and allow only one (one type) codec header per
> stream, simplifying encoder and demuxer. it is enough for 99% of codecs,
> only a few supports more than one codec API and even tehy are easily
> convertable.
>
>
> A'rpi / Astral & ESP-team