[NUT-devel] Issues

[Michael Niedermayer]

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

[...]
-- 
Michael