[MPlayer-dev-eng] MCF ( Multimedia Container Format ) : Invitation to participate

[Arpi]

Hi,

> On Monday 03 June 2002 00:12, Christian HJ Wiesner wrote:
> > While the basic data and block structure is fixed now and already
> > implemented in libmcf on CVS we are currently in the phase of deciding how
> > to support all the different codecs and formats. Easiest thing to do what
> > of course be to use the M$ dshow method of building a playback graph based
> > on the FourCC of the use codec. But as we are ware that this may cause
> > problem on other OS such as Linux or MacOS we were discussing alternative
> > solutions like a plugin structure ( f.e. a MPEG4 ISO video plugin to play
> > XviD and DivX5 ).
> I don't see where choosing the right video codec has anything to do with the
> file format. The only thing the file format has to signal is, what codec is 
> used, the player can then use this info to choose the right decoder. Mostly 
> FOURCC would be enough for this, maybe an extra field that gives the long 
> name of the codec. And a thought would be to use 8 or 16 char codec 
> identifier, as four char seems to get close to it's limit with all those 
> different codecs out there. Exisitng codecs could use their FOURCC padded 
> with spaces to the new identifier size.

imho this (longer than 4 fourccs) is not needed.

> Also you should add a field to store codec specific data, this is eg. needed
> to store the mpeg4 video headers.

yes, this one is very important!
most codecs have extra (global) info, usually placed in .avi or .mov headers.
they store extra parameters, huffman tables, color palettes, codebooks
tehre, they are common for all frames so better to place tehm in the header
than into each frame.

my idea about the ideal file format:

headers:
  - should have headers. headerless formats (like mpeg) are very limited
    (but may be edited using cut & dd :))
  - should allow at least 256, but better if unlimited number of audio,
    video and custom track types
  - track header should have a 'type' field, telling the demuxer the format
    of the header. why? currently, there are 3 big multimedia "platform":
    windows (microsoft's vfw/dshow/activex) quicktime and realmedia.
    they all have their set of codecs, and an own format (struct) of
    audio/video/other track headers.
    For windows, it's the BITMAPINFOSTRUCT (video) and WAVEFORMATEX (audio).
    For quicktime, it's ImageDescription (video) and SoundDescription(???) (audio)
    For real, there are also some struct, i don't know (didn't analized .rm yet)
    We could support these 3 at the beginning, while allowing other track
    headers in the future. Why is it good? Both encoders and players
    _have_to_ operate with these structs (codecs use it as in/output), so
    it's easier to both player and encoder writers to use these, wihtout
    converting them to some uniform struct and then trying to guess the
    missing fields in the player. Disadvantage: a general 'print file info
    only' tool have to know all these header structs. Or, we can add a very
    simplified 'general' header (like AVI's AVIStreamHeader) containing
    fourcc, width, height, color depth, aspect ratio, maybe bitrate,
    quality, just for info.
The actual way of implementing this can be the avi, asf or mov method,
they all are ok (variable size chunks, starting with chunk size followed by
chunk type, so demuxers can skip unknown stuff, while allowing unlimited
number of header defines)

avi is the simplest, mov is over-complicated, and asf is the same as avi but
uses 16byte guids and 64bit for everything so just waste of disk space

content:
there is 3 kind of 'content formats' out there:
1. avi/mov/mpeg-pes style: variable size chunks, starting with chunk size.
   raw seeking impossible, they usually have index table for seeking.
   .mov doesn't have chunk header, it's unplayable without the index.
   it isn't error-resistant at all, you can't re-sync if a chunk header is
   broken, maybe try guessing and brute-force decoding but it's a mess
2. asf, mpeg-ts (+ogg?) style: fixed size chunks, so raw seeking is possible
   (chunk position can be calculated). these chunks contain the real data
   chunks fragmented. i like this approach, imho it's the best we can have:
   raw seeking is possible without index, error-resistant, any size of the
   real data chunk is allowed, no mess with sync-words.
3. mpeg-ps/es style: fixed or variable sized chunks, separated by unique
   sync-words (00 00 01 xx for mpeg). raw seeking is possible, but after
   seeking, you have to search for the next sync-word, do some checks.
   big disadvantage: the content of the embedded data chunks are limited -
   they must _not_ contain the sync word! it's a real headache for codecs
   not designed for this. advantage over 2.: resistant against problem when
   parts of the file are shifted (few bytes missing) so the fixed-size chunks
   are all at wrong place so unrecoverable. may happen with streaming.
   mpeg-ts fixes it by adding micro-sized header to each block, so such
   shifting may be detected.

a-v sync/timing:
- fixed fps/sr - bad, forget it
- timestamps at fixed clock (90khz for mpeg, 1ms for asf), limited, forget it
- timestamps at custom clock (used in .mov files) - recommended

so, my opinion: we should NOT re-invent the wheel.
there are great, well-designed (i bet lots of ppl worked a lot on these)
file formats out there. they just don't apply our needs.
they were designed for different purpose and different transfer media.

but we could reuse the basid ideas of them, and combine the best part of all
file formats!

it should have headers like avi, content like mpeg-ts and timing like in mov

> All this was written out-of-the-blue, I haven't looked at the MCF specs yet.

Neither me :)

> Btw. we can even use windows dshow codecs through our dshow emulation layer 
> which is based on wine (code is inherited from aviplay project).

yes, and hopefully, sooner or later, we'll be able to use the realmedia and
the quicktime codec DLLs too

> Btw. as arpi is lazy ;) it would probably be a better idea to visit us on 
> #MPlayerDEV in ircnet (irc.netsurf.de and others).

good idea

> Or best thing keep the discussion on the mailinglist, this is the best way, 

agree


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu