[MPlayer-dev-eng] Nut startcodes

[Ville Saari]

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?

I suggest that the "must" in your description is replaced with "should".
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. Or the already catched streams might be decoded
at full speed without displaying until all the streams are ok if the
player wants to avoid displaying partial content. 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.

-- 
 Ville