[MPlayer-users] Re: lavc-Options for *BEST* quality?
Michael Niedermayer
michaelni at gmx.at
Wed Feb 5 00:00:09 CET 2003
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
More information about the MPlayer-users
mailing list