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

[Michael Niedermayer]

Hi

On Saturday 01 May 2004 22:52, D Richard Felker III wrote:
> 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.
which would place a startcode before every frame in a intra only video 
stream :(

>
> 2. Always write a type2 startcode before the next frame is
>    (last_startcode_distance+next_frame_size) > max_distance.
sure, thats exactly what max_distance is supposed to guarantee

>
> 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.
IMHO thats a bad idea, because if someone for example encodes at a very high 
bitrate he doesnt care about space, and almost certainly wants best error 
recovery and startcodes between every frame

btw, the overhead per startcode should be approximately 8 + 3*stream_count, 
less if there is too little space for every stream to have a packet between 2 
startcodes

for 4 streams with the 16384 recommendation thats 0.12% in worst case.
IMHO its really a question about overhead vs. error robustness, but IMHO 16k 
is reasonable

as soon as we add short startcodes, assuming we do, we can raise this maybe, 
but short startcodes will also need 3+1*stream_count at absolute minimum IMHO
so 64k/16k would still need 0.06%, and provide little error protection 
compared to other container formats

>
> 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,
hmm, i thought thats identical to what u suggested in 2. above, at least its 
supposed to mean exactly the same

> since it's used to detect invalid sizes. 
frame + previous frames after startcode < max_distance -> OK
frame has startcode before and afterwards -> OK
else -> error

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en