[MPlayer-dev-eng] Nut startcodes

[D Richard Felker III]

On Mon, Apr 26, 2004 at 11:57:31PM +0300, Ville Saari wrote:
> On Mon, Apr 26, 2004 at 06:20:01AM -0400, D Richard Felker III wrote:
> 
> > 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.
> 
> This is what I proposed, however there's a problem: muxer might not have
> any power to force encoder to emit an I-frame. For example if it is muxing
> already encoded elementary streams from files. If there is just one stream
> that can have predictive frames, then the muxer can output a startcode when
> it sees an I-frame, but what if there is more than one such stream and their
> I-frames are not synchronized?

It doesn't matter. Startcodes are not keyframe markers. Only a very
broken demuxer would only seek to startcodes. Rather, startcodes are
there for two purposes:

1. to make the binary timestamp search possible -- you need a way to
   sync to the frame starting from an arbitrary byte position.

2. to facilitate error recovery if a frame header is damaged.

In order to make seeking most efficient, it makes sense to put
startcodes right before some or all of the I frames. But if there are
too many I frames, you don't have to, and likewise it's perfectly
acceptable to put startcodes before non-keyframes.

> I suggest that the "must" in your description is replaced with "should".

Which one? The "predictive" coding I talk about is on the container
level, not the codec level. You're not allowed to use relative pts
deltas for the first frames after a type2 startcode because...what
would they be relative to?? If you got there by seeking, you simply
don't know.

> If not all the streams start with an I-frame after a seek, then the
> demuxer or the decoder must ignore any non-I-frames and display blackness
> or non-changedness or silence or whatever is appropriate for the stream
> until an I-frame is met.

No, it just seeks to a keyframe.

> If frame accurate seek
> is needed and the skipping of predictive frames would lead past the required
> start position, then an earlier startcode has to be selected.

Agree. If you want to seek to time X (and assuming you don't have an
index) you binary search for the first startcode before time X, then
walk the packets to the timestamp you want.

Rich