The controversies so far... 1. checksum in frame headers/syncpoints I did very much like the elegance with the syncpoints, however I did not like the hacks in code to accomplish this (frame header parser in find_syncpoint, put_frame using put_syncpoint to a temporary buffer, demuxing frame header is dependant of "saw syncpoint" context). So I have no strong feelings either way with this. I do have a small proposal for overhead reduction in new method (if it's stupid say so and I'll drop it) - has_checksum being implicit by the rules it is manditory for - so you can save frame codes or a byte for coded flags... Come to think of it, the frame header for a frame that needs has_checksum is large already anyway... 2. limiting max_distance, max_frame_size I say, keep them VLC, but add a MUST in spec regarding their value... Using 'u(16)' is as silly as using it for the 'tmp_mul' vars in the main header which also have a MUST restriction... 3. prefix/compression for frames Not sure if this is an actual controversy, possibly the flamewar going on has nothing to do with this (let's keep mplayer g5926 flames for another mailing list :). I'm quite against the prefix stuff, for a completely other reason - it's a silly complexity for something that does not belong in the container. If you're gonna do this, you might as well compress the frames with bzip2 while you're at it. underhead is nice, but not that nice, this will be nothing but a legacy feature in the future... 4. Info frames/streams/packets The first problem: limiting positions where info frames/packets should be Michael you said you're strongly against this, but you also said a muxer should place them sanely and the demuxer should not go crazy looking for them. IMO there should be rules that you can't just put the frames/packets all over the place as you please, and I'd like to find the best ones that stay fully featured while still allowing the demuxer to not have to search everywhere for them. Second problem: dump info streams? There is some advantage to this - info frames don't really have stream like behavior, unless you repeat them often. A NUT-aware streaming server could give the info frame relavent to current position just once, and not be wasteful and repeat often or at all... Info streams can work if you put an EOR closely after the frame, but that is not semantically correct... What I hate about dumping info streams though is some complication to my demuxer api (each call can give a frame or a packet, instead of always a frame), and, if we do dump info streams, I very much want a restriction that info packets that are global (chapter_id >=0 ?) can only come after main headers, and not wherever... Thinking again about my streaming example, the file isn't seekable anyway, and if you dump it, and you're still using the info frames instead of remuxing them to info packets, you deserve what you get of an unseekable/bad seekable file... (Which would nicely discourage using info frames in places where it is inappropiatte - not live streams..) - ods15