[Mplayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.54,1.55

[D Richard Felker III]

On Sat, May 01, 2004 at 02:31:37PM -0400, D Richard Felker III wrote:
> On Sat, May 01, 2004 at 01:54:16PM +0200, Michael Niedermayer wrote:
> > Hi
> > 
> > On Saturday 01 May 2004 07:34, D Richard Felker III wrote:
> > > On Sat, May 01, 2004 at 12:54:01AM +0200, Michael Niedermayer CVS wrote:
> > > > CVS change done by Michael Niedermayer CVS
> > > >
> > > > Update of /cvsroot/mplayer/main/DOCS/tech
> > > > In directory mail:/var2/tmp/cvs-serv2525
> > > >
> > > > Modified Files:
> > > > 	mpcf.txt
> > > > Log Message:
> > > > additional start_code rule (implemenattion does this since a long time
> > > > already)
> > > >
> > > >
> > > > Index: mpcf.txt
> > > > ===================================================================
> > > > RCS file: /cvsroot/mplayer/main/DOCS/tech/mpcf.txt,v
> > > > retrieving revision 1.54
> > > > retrieving revision 1.55
> > > > diff -u -r1.54 -r1.55
> > > > --- mpcf.txt	28 Apr 2004 03:19:35 -0000	1.54
> > > > +++ mpcf.txt	30 Apr 2004 22:53:59 -0000	1.55
> > > > @@ -234,6 +234,9 @@
> > > >  	0x11405BF2F9DBULL + (((uint64_t)('N'<<8) + 'S')<<48)
> > > >  frame_startcode
> > > >  	0xE4ADEECA4569ULL + (((uint64_t)('N'<<8) + 'K')<<48)
> > > > +	frame_startcodes MUST be placed immedeatly before a keyframe if the
> > > > +	previous frame of the same stream was a non-keyframe
> > > > +
> > >
> > > Very bad rule. What if you have an audio codec that alternates
> > > I/P/I/P/...?? This is a horrible waste. 
> > does such a audio codec exist?
> 
> No, but it might in the future so this is a dumb requirement. Keep in
> mind, if the spec says that these startcodes MUST exist, then we
> cannot remove the requirement in the future (even if we need to for
> future codecs!) or we might break compatibility with existing players.
> 
> > IMO if a (audio) codec supports P frames then the majority (>90%) of frames 
> > should be of P type, as P types should be smaller 
> 
> OK, my example was bad. s/P/B/ and it makes sense, i.e. IBIBIBIBI (or
> I0 I2 B1 I4 B3 I6 B5 ... in decode order) where every other audio
> packet is interpolated between the surrounding two.
> 
> > > There's no reason for such a 
> > > rule...
> > it allows simpler seeking, for example our current implementation cant seek to 
> > type 0 frames, so IMHO it isnt unreasonable to expect other simple demuxers 
> > to be incapable of seeking to startcode-less frames
> 
> Then it's an invalid implementation. A nut demuxer MUST be able to
> seek to any frame, since there are no longer frame types. Startcodes
> are just an aid to "sync on" when doing binary search.
> 
> > anyway, iam not against removing this after our implementation supports 
> > seeking to startcode-less frames and we see that doing so doesnt require 
> > overly complicated code
> 
> I can provide the pseudocode right here:
> 
> seek_to_start_code(); // use existing binary search
> while(p=get_next_packet() && p->pts < seek_pts);

BTW I also have recommended guidelines for placing type2 startcodes:

1. For files with video, put a type2 startcode before each keyframe of
   the primary video stream.

2. Always write a type2 startcode before the next frame is
   (last_startcode_distance+next_frame_size) > max_distance.

Actually rule 2 alone is a plenty. Rule 1 just helps speed up seeking
by a small constant. But about max_distance:

max_distance
        max distance of frame_startcodes, the distance may only be larger if
        there is only a single frame between the 2 frame_startcodes
        this can be used by the demuxer to detect damaged frame headers if the
        damage results in a too long chain
        SHOULD be set to <=16384 to ensure reasonable error recovery

The recommendation of 16384 is stupid. This will put startcodes every
couple frames for video, and thus require almost every frame to
contain a full timestamp (including audio frames!). Very bad. It
sounds to me like this recommendation was made with audio-only files
in mind, which (although interesting) are relatively unimportant in
practice (compared to movies).

Anyway there should be no fixed-size recommendation because it depends
on number of streams, bitrate, etc. IMO max_distance should generally
be proportional to nominal_bitrate*keyframe_interval/framerate.

One more thing: "the distance may only be larger if there is only a
single frame between the 2 frame_startcodes". This makes max_distance
totally useless, since it's used to detect invalid sizes. The user
should ensure that max_distance is considerably larger than any
possible frame (which is much larger than 16384!)...

Rich