[NUT-devel] Issues

[Ivan Kalvachev]

2006/3/5, Michael Niedermayer <michaelni at gmx.at>:
> 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

Somehow I don't like to distinguish between realtime and non-realtime streams.

I am  concern about how will the later info stream be found on
seeking. It is quite possible for
it to be missed. (assuming you can seek in realtime stream, e.g. by
storing or buffering it).