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

[D Richard Felker III]

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);

Rich