[MPlayer-dev-eng] Nut startcodes

[D Richard Felker III]

Michael proposed (in "Cleaning your nuts" thread :) adding "type 1"
frames back into nut with 3-byte startcodes to improve error recovery.
What's everyone's opinion on this?

BTW, the spec right now is rather confusing regarding type 2 frames. I
have a proposed simplification. Get rid of frame "types" entirely and
just have frames and startcodes be two separate things. An 8-byte
startcode just serves as a sync point, and frames after the startcode
are forbidden from using any predictive coding that depends on frames
before the startcode. As a consequence, the first frame of each stream
after the startcode must fully encode its pts. In effect it's the same
thing as type 2 frames, but conceptually, it's nicer to separate the
startcode from the frame so that it doesn't belong to any particular
stream, but rather the file.

In this light, there's only one type of frame, and two types of
startcodes (not counting global/stream header, info, etc. startcodes):

1. Small (3-byte?) startcode. This one imposes no rules on the
   surrounding frames, and serves ONLY as an aid to error recovery. It
   can be used as frequently or infrequently as desired for the
   error-recovery needs of the user.

2. Large (8-byte) startcode. This one resets all predictive status for
   all streams (so subsequent packets must be fully coded), and thus
   provides a sync point for seeking. These SHOULD appear frequently
   enough to facilitate reasonable seeking. (Seeking is O(log n) with
   constant proportional to max distance between type-2 startcodes.)

A good demuxer should be able to seek to any frame, not just frames
immediately following type-2 startcodes.

Hmm, what else does NUT need? Mainly just a spec for the index; that's
all I can think of. And maybe clarify the way subtitles are stored.

Rich