Hi On Fri, Mar 03, 2006 at 07:31:12PM +0200, Oded Shimon wrote:
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...
iam weakly against the implicit checksum without a flag, why: * if by whatever reason a past timestamp is messed up the implicit rule would be messed up too * no way to add extra checksums if theres no flag
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...
well, iam certainly in favor of MUST restrictions on these values though i would prefer choosing a type which makes it impossible to violate the restriction maybe saying that a (de)muxer MUST treat a value outside the 1...x range as x would be a compromise
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...
you think all the new stuff the standard comitees will produce wont have redundant startcodes?
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.
ok
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...
iam strongly against EOR tricks ...
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...
i have no strong oppinion on mainheader-infopacket relative ordering as long as it doesnt depend on info packet contents [...] -- Michael