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

[Michael Niedermayer]

Hi

On Wednesday 05 February 2003 03:57, D Richard Felker III wrote:
> 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 know very little about mov/mp4 except that it might be patented, and that it 
often doesnt even store the correct width/height of the movie

>
> > 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.....
we could allow both options, but it would increase the complexity ...

>
> > * simple
>
> Oh well, guess we can't use MCF... :)))
or mp4/mov ...

>
> > * 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.
agree, but s/require/suggest/


>
> 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...
yes, write a small util which fixes the pts while merging the files, IMHO we 
should not allow to cat streams randomly, it messes them up too bad (global 
headers and which packet belongs to which of them issue, or we must put all 
global headers to each keyframe

[...]
> > 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.
hmm, and what happens if some of the frames get badly damaged? for example 
there are 300 frames between keyframes and we loose 100 on both sides so when 
should the middle 100 be displayed then (we dunno that they are the middle 
instead of from somewhere else)

>
> > 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.
hmm but with 300 frame distance that would be about 1-2mb to redownload 
instead of a single frame
we could allso allow checksums to cover multiple frames and be stored in non 
key frames but it increases the complexity slightly

>
> > 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...
diagree
1. different bitrates for streaming, yes we could use multiple files ...
2. multiple objects (subtitles for example could be considered as a mostly 
transparent video stream)

[...]
> > 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...)
yes, i thougt these could be considered to be a video stream (fourcc to 
identify the encoding, ...)

[...]

Michael