On Fri, Mar 03, 2006 at 11:50:44PM +0100, Michael Niedermayer wrote:
On Fri, Mar 03, 2006 at 08:43:50PM +0200, Oded Shimon wrote:
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
OK, figured you'd be against... I'll outline what I want... (and I think what Rich wants) 1. Info packets, which can only come after main headers, are "global" in that they never provide new information - after reading them once when first reading main headers, you can safely skip all future info packets when you skip headers as well. This is basically the rule in the spec right now: All info packets MUST appear after main headers at begginning of file, and SHOULD be repeated after all main headers unless they are very large. 2. Info frames never store global info, and the only reason to use them would be that not all information is known when beginning to create the file (live streamm...). Finding info frames for a certain region does not need to parse the whole file, and not because the demuxer lives on an assumption that the muxer is sane, but because the spec explicitly says so. Michael, do you have a spec to accomodate these goals together with your own?.. One more idea: All info frames pts<=chapter_end and There must be a frame with pts==chapter_start (convert_ts or whatever) I'm hating that there is so much controversy over such a.. cosmetic issue :/ - ods15