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

[D Richard Felker III]

On Sun, May 02, 2004 at 03:42:58AM +0200, Michael Niedermayer wrote:
> > 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 :(

That's why I called them guidelines, not rules. Obviously they're not
suitable for all cases. But if someone is using intra-only video they
obviously don't care about space anyway...

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

Agree.

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

Again, that's why it's only a recommendation. If someone doesn't care
about space they can set it to put a startcode after each frame. But
still, max_distance can't be lower than the actual packet sizes! If
it's allowed to be lower than this, then we might as well not have it
at all, since it can't be used for error detection!

> 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

Hmm. This sounds accurate.

> 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

How do short startcodes add 3+1*stream_count overhead? This is
nonsense. They add constant overhead of 3 bytes per startcode, nothing
more.

> so 64k/16k would still need 0.06%, and provide little error protection 
> compared to other container formats

Obviously short startcodes should be placed more frequently than every
16k. I would think it would be desirable to put them after every 3-4
packets.

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

I was quoting your rule.

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

Hmm, maybe it's ok... I guess it's very unlikely for the first header
after a startcode to be damaged if the startcode itself isn't damaged.

Rich