On Fri, Mar 03, 2006 at 07:21:08PM +0100, Michael Niedermayer wrote:
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
I still intend to have the flag... Just automatically set it on
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
No objection
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?
Everybody will use Snow! :P Saddens me that they still haven't been obsoleted...
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 ...
Yeah I said myself, it's just not right.
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
I'm somewhat confused by that statement.. You mean, you don't mind a rule "all info packets must come after main headers", but against "all info packets with X must come after main headers". Well, OK, how do you feel about: all info packets must come after main headers all info frames must be hapter_id < 0 And... all info frames must have chapter_start<=pts<=chapter_end . I think these are all the restrictions I'm interested in. - ods15