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

[D Richard Felker III]

On Wed, Feb 05, 2003 at 12:00:09AM +0100, Michael Niedermayer wrote:
> > > 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 ...

Hmm, what are you saying? Are there any formats right now that don't
totally suck? Perhaps .mov/.mp4 is ok; I don't know anything about it.
But all the rest (avi, asf, ogm, ...) are quite bad.

> 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)

Should index be at the beginning or the end? IMHO, from a player's
perspective, it makes a lot more sense to have it at the beginning, so
you don't have to seek to the end of the media. Also this is nice for
playing files before they finish downloading.

On the other hand, I *like* the fact that AVI puts the index at the
end, because then if a file doesn't quite fit on a CD, or if my
download fails right near the end, I can still watch the whole movie
without an index. So from a file sharing perspective, I think it makes
the most sense to put the worthless/redundant info (i.e. index) at the
end...

Not sure which is best overall.....

> * simple 

Oh well, guess we can't use MCF... :)))

> * 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)

How does cutting work with codec/stream/global headers? Perhaps the
spec should require the player to keep seeking forward until it finds
these headers if they're not right at the beginning. That way we could
get by with only repeating headers once every few minutes, and as long
as no one cut out a really tiny segment of the movie, you'd always
have at least one good set of headers in the clip for the player to
use.

Also, another idea... Perhaps there should be a "reset pts timer"
packet or something similar at the beginning of files, so that when
you cat two files together, the player knows that all timestamps in
the second file are starting from a new base. Or perhaps there's a
different way to handle this...

> details:
> all packets:
>   forward & backward pointer to next / prev packet vlc encoded

Agree!

> 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 

For constant fps, non-keyframes probably don't even need a timestamp.

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

Perhaps one checksum per GOP would make more sense. (i.e. include a
checksum in keyframes based on everything since the last keyframe).
That would save a good bit of space. Like you said, checksums are NOT
useful for determining if single frames are damaged -- it's better to
just let the decoder do error concealment. What they are good for is
telling the user what parts of a file need to be re-downloaded, and
for this purpose, one per keyframe should be a plenty.

> 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)

I'm not even sure multiple video streams are necessary or useful...

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

:))

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

You're also forgetting subtitles. IMO it might be nice to support
embedding any of the standard subtitle formats as a raw text file in a
single packet at the beginning of the file. That would let users have
the option to use all the fancy features of different subtitle formats
rather than just plain single-font text subtitles. (Perhaps even
vobsub could work...)

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

I know nothing about vlc codes, sorry. :(

> any comments?

Yes, see above. Overall, excellent! I'd like to see what Arpi has to
say.

Rich