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

[Oded Shimon]

On Wed, Nov 15, 2006 at 03:07:49AM +0100, Michael Niedermayer wrote:
> 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:
> > > > > 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?

Do you suggest adding some sort of flag to info packets saying if they are 
"new" ones or "header" ones?

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

Well, for one, this stuffing packet would violate the "identical info 
packets after main header" rule. Also, the main headers are in the 
begginning, and a smart network stream would have no reason to repeat 
them, so they will not point backwards to anything...

I don't think the pointer stuff helps at all - either the stream dumper is 
NUT aware, in which case it can rip out all the info packets found during 
dumping (and optionally add them to main headers somehow), or it is not 
NUT aware and it doesn't care anyway.

You seem to be scared of people putting info packets in the middle of 
files or in dumped realtime streams - I don't see this as an issue. 
Demuxers SHOULD NOT search for info packets anywhere except after the main 
header. If you were silly enough to stick an info packet somewhere in the 
middle, a demuxer will not see it until playbacking that point (you 
SHOULD NOT do this). And in the case of dumped realtime streams, you can 
fix them fairly easily by remuxing...

- ods15