[NUT-devel] Info packets in NUT stream (spec bugs?)

[Michael Niedermayer]

Hi

On Wed, Nov 15, 2006 at 02:17:03AM +0200, Oded Shimon wrote:
> On Tue, Nov 14, 2006 at 07:04:43PM +0200, Oded Shimon wrote:
> > On Sun, Nov 12, 2006 at 05:27:06PM +0200, Oded Shimon wrote:
> > > On Fri, Nov 10, 2006 at 08:57:23AM +0200, Oded Shimon wrote:
> > > > On Mon, Nov 06, 2006 at 01:44:19PM +0100, Michael Niedermayer wrote:
> > > > > On Mon, Nov 06, 2006 at 10:56:57AM +0200, Oded Shimon wrote:
> > > > > > On Sun, Nov 05, 2006 at 09:32:44PM +0200, Oded Shimon wrote:
> > > > > > > On Sun, Nov 05, 2006 at 07:07:22PM +0100, Michael Niedermayer wrote:
> > > > > > > > On Sun, Nov 05, 2006 at 09:48:46AM +0200, Oded Shimon wrote:
> > > > > > > > > On Sun, Nov 05, 2006 at 12:19:53AM +0100, Michael Niedermayer wrote:
> > > > > > > > > > the big problem with simply allowing arbitrarily placed info is that it 
> > > > > > > > > > makes the info useless for the normal nut file case as the info cannot be
> > > > > > > > > > found its like a dvd with chapters but the information about where the
> > > > > > > > > > chapters begin is stored at the begin of the chapters, you end up with
> > > > > > > > > > a O(n) search ...
> > > > > > > > > > so ive some concerns with just saying its ok for streaming, as that
> > > > > > > > > > leads to nut files laying around which are encoded for streaming ...
> > > > > > > > > 
> > > > > > > > > The proposal I had for this is - info packets not written after main 
> > > > > > > > > headers are only allowed in real time streaming, and must have 
> > > > > > > > > chapter_id!=0, and any info packets written after main headers, both in 
> > > > > > > > > file and in streaming scenario, MUST be repeated together with all main 
> > > > > > > > > headers. No demuxer would have to search anything past main headers, any 
> > > > > > > > > info packets given during demuxing is "information update". In the file 
> > > > > > > > > scenario, all info must be written after the main headers, so no searching 
> > > > > > > > > necessary.
> > > > > > > > 
> > > > > > > > hmm, rich what is your oppinion about that? iam unsure if iam against it
> > > > > > > > or not ...
> > > > > > > 
> > > > > > > - ods15
> > > > > > 
> > > > > > Objections? Commit? 48 hour notice from now.
> > > > > 
> > > > > i object until i heard a comment from at least rich, comments from
> > > > > everyone else are of course welcome too
> > > > 
> > > > This is a new proposal: Basically identical to the previous one, only info 
> > > > packets SHOULD NOT appear "in the wild" in non-realtime-streams instead of 
> > > > MUST NOT. Making the distinction between file and realtime streams less 
> > > > strict. Demuxers still SHOULD NOT search for info packets anywhere except 
> > > > after the main headers. I think this is most clean...
> > > > 
> > > > Comments?
> > > 
> > > Repost. ... 48 hour notice ...
> > 
> > Committed
> 
> OK, I'm sorry I committed this so hastily. You said you object until you 
> have heard from Rich. I talked to Rich on IRC and he seemed apathetic on 
> the issue and unwilling to reply on it. I changed my proposal to be 
> somewhat saner with a less strict distinction between realtime and 
> non-realtime streams, and you have not made any objection reply since.
> 
> Can we discuss this now?

yes we can, what about keeping the current info after header + info must
be identical rule
with an exception like
if a nut "file" is transmitted over the network and no out of band method
to update metadata is available then info packets may be placed between
?syncpoints? the contents of these info packets may change and they do
override the info packets after the mainheader. for the normal info
packets after the mainheaders the normal rules apply (=no changes)
dumping such a network stream to disk does not constitute a valid nut
file, to convert such a stream to a valid nut file it is needed to
read the whole to find the most up to date info and then place this
after every main/stream header group

to simplify this conversation every of the "new" info packets must
contain a pointer to the previous "new" info packet?

and some approproate stuffing/empty info packet should be added
after all main/stream headers?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is