Hi On Fri, Mar 03, 2006 at 08:43:50PM +0200, Oded Shimon wrote:
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
so a frame which has checksum=no will be legal and have a checksum? iam strongly against this, either no flag or a flag but not such a hack
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
commited [...]
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".
yes
Well, OK, how do you feel about: all info packets must come after main headers
iam very slightly against this but i dont really care
all info frames must be hapter_id < 0
And... all info frames must have chapter_start<=pts<=chapter_end .
is there anything info frames can what info packets cant? if no then i dont care about how info frames are restricted as i would simply choose not to use them otherwise i very strongly object against both [...] -- Michael