[NUT-devel] Issues

[Michael Niedermayer]

Hi
On Sun, Mar 05, 2006 at 02:59:09PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sat, Mar 04, 2006 at 06:48:34PM +0200, Oded Shimon wrote:
> > 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?..
> 
> no, there is no such spec
> 
> 
> > 
> > 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 :/
> 
> this is not a cosmetic issue, you guys want restrictions which make no sense
> and which restrict actually usefull and needed cases
> 
> 
> heres what i have in my nut fork on my disk: (note, there are no info streams)
> 
> Rules for realtime streams:
> 
> If a info packet X is transmitted anywhere then an info packet with the same
> chapter and stream_id MUST be placed so that there is never a mainheader
> and following frame covered by the info packet without the info packet
> inbetween
> example: M(mainheader) F(frame covered by infoPacket) f(other frame) I(info)
>  M f f M f I f F F M I F F M I F F f f M f f M
> as a special exception very large and unimportant info packets can be 
> transmitted less often
> 
> If 2 info packets have the same chapter_id and stream_id then the earlier
> MUST be ignored (the last info packet is the most correct, this allows
> updating or correcting info)
> 
> 
> Rules for non realtime streams:
> 
> 2 info packets with the same chapter_id and stream_id MUST be identical
> 
> Every info packet which is stored anywhere in the file MUST also be stored
> after every mainheader-streamheader set


rich, do you agree with these and removial of info streams?

[...]
-- 
Michael