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

[D Richard Felker III]

On Wed, Feb 12, 2003 at 09:36:39PM +0000, Diego Zuccato wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Michael Niedermayer wrote:
> 
> > 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)
> > any comments?
> What about packing together frames for all the streams? So that a
> "chunk" contains (for example) audio, video and subtitles for a certain
> video frame (= a single timestamp). If all the chunks contain the same
> number of streams, you can avoid repeating 64-bit IDs and just use 16-
> (or 24-) bit "size" fields. And you can possibly avoid'em too if the
> stream is fixed-size for every chunk (like CBR mp3).
> And a micro-index for each (key)frame that points to at least 3 next and
> 3 prev (key)frames (should be quite fault-tolerant... an error in the
> micro-index is detected comparing its value to the ones stored in the
> others, and if 2 out of 3 agree, the different one is damaged).

How does such a 'micro-index' help you? You still have to read thru
the whole file to seek to a particular time. The only way an index is
at all useful is when you can read the whole index at once at the
beginning and then have it available for seeking to arbitrary
positions.

Rich