[MPlayer-dev-eng] Re: [MPlayer-users] Re: lavc-Options for *BEST* quality?

[Michael Niedermayer]

Hi

On Tuesday 04 February 2003 17:30, D Richard Felker III wrote:
[...]
> > > In any case, even if the savings in overhead are only 2-4 megs, I
> > > think doing vorbis-in-avi would be much better than ogm just for the
> > > sake of having an index.
> >
> > Several people tried to do Vorbis-in-AVI and failed. I'm pretty hopeful
> > that Matroska will come along in the not so far future so that we'll
> > finally have a rather feature-rich container format... And not that old
> > and totally outdated AVI.
>
> I don't want a "feature-rich" container format. I want something that
> handles vbr audio properly, that has an index, that's recoverable
> without the index (perhaps even somewhat seekable), and that supports
> subtitle streams. I don't know too much about Matroska, but MCF has
> all kindsa idiotic nonsense about menus and tags and its own idea of
> how codec plugins should work and other crap that doesn't belong in a
> movie file and that just wastes space and delays implementation so
> that we never get around to having a working standard. *sigh* Also it
> seems both these projects are led by Windows kids who think DShow is
> the coolest thing and probably have no idea about the proper way to
> design a media container.
yes, i have the same feeling, i looked at the MCF spec a few month ago and it 
was a total joke, far worse then AVI, IIRC the format was completely 
intolerant to errors, so if a single bit is changed the demuxer would detect 
a crc failure and drop one or more frames, AFAIK this is done because DShow 
codecs lock up if they get feeded with damaged data, a inserted or deleted 
byte will allso destroy the whole file IIRC

IMHO a new container format wouldnt be bad idea, as it seems all current 
formats do have some dissadvantages, even though it is perhaps not worth it 
for the 0.5 % overhead ...

i guess the primary goals should be:
* low overhead (ppl seem to care alot about 0.5% ... )
* optional index (undamaged files should allways have one)
* simple 
* extendible (optional headers which can be ignored)
* error tolerant
* allways correctly interleaved streams
* streamable (no seeking required for decoding)
* cutable (just chop it up and still be able to decode the fragments)

details:
all packets:
  forward & backward pointer to next / prev packet vlc encoded
  
global header packet
  64bit startcode
  length in time/video & audio stream count/version/...
  time resolution (so we dont waste bits for constant fps movies)
  checksum
  should be repeated a few times perhaps

per stream header packet
  64bit startcode
  stream id
  w/h/fourcc/samplerate
  depth/fps/bitrate/...
  checksum
  should be repeated a few times perhaps

codec specific header packet
  64bit startcode
  codec specific data
  checksum
  should be repeated a few times perhaps

per frame header packet
  64-bit startcode for keyframes
  timestamp vlc
  stream id vlc
  flags vlc
  frame bitstream
  optional checksum (depending upon flags)

timestamps 
  for non keyframes should be encoded as VLC difference from the last keyframe
  for keyframes simply relative to the file start & with the number of
  bits/resolution specified in the header 

optional checksum
16 or 32bit per frame checksums so files can be checked for damage quickly and 
the damaged frame redownloaded

unlimited number of audio / video streams (id stored as vlc too, as its very 
lame to waste 1 byte or even more per frame to encode video stream id #0)

index
  compressed (with bzip2 at least if noone has a better idea)

some optional headers 
  for author, comments, ...
  optionally compressed with bzip2 & allow repeating

user defined packet type which is ignored

for vlc coding some universal vlc code like exp golomb (h264 uses that too) 
might be a good choice

any comments?

[...]

Michael