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

[Rich Felker]

On Mon, Nov 20, 2006 at 11:32:37PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Nov 20, 2006 at 07:41:48PM +0200, Oded Shimon wrote:
> > On Mon, Nov 20, 2006 at 12:37:22PM -0500, Rich Felker wrote:
> [...]
> > > > that too, iam not sure if theres anything in the spec which forbids it or
> > > > if theres anything which would break, iam just mentioning it ...
> > > 
> > > Starting at arbitrary timestamp is totally legal and it was always my
> > > intent for it to be legal. Obviously streaming is not possible either
> > > if you don't allow for this..
> 
> IIRC someone originally wanted timestamps to start from 0, we then realized
> thats not possible and then we agreed that it should be close to 0 or
> something (and no iam not at all trying to say that i am against arbitrary
> start timestamps ...)

I never agreed to such a thing because it was always my intent that
you could split and recombine files across media without loss of
information. Also there's no reasonable way to specify "close to 0".

> > I've never actually tested it, but AFAIK libnut is completely safe and 
> > non-breaking on this issue.
> 
> theres at least one issue with random start timestamps
> try 1e9999 as start timestamp and tell me if that worked :)
> while the fileformat of course has no problem with arbitrary integers,
> implementations will ...
> making it clear that 0 should be used as start where possible reduces
> the issue but doesnt solve it

I think it's clear that if you use idiotic time values you'll have
problems with implementation support. IMO it's fine to say just that
implementations SHOULD NOT go out of their way to support excessively
large values for any field in a NUT file.

> > It's actually not that bad in implementation - just keep last_info and 
> > last_info_redundant (to know if to place another one now), a few more if's 
> > together with syncpoint writing, and you're done.
> > 
> > Or do you mean complexity in demuxer? In which case, yes, it is somewhat 
> > ugly... But I don't really agree in demuxer searching for info packets 
> > anywhere after main headers anyway.

Demuxer of course..

> thats perfectly fine, i never proposed that demuxers should search for them
> its just that if a demuxer wants to or needs to then it should be technically
> possible to find them

It is always possible via linear search. If the demuxer SHOULD NOT
search for them then we should not go out of our way to make it easy
to search... Just my 2¢...

> > > I'd like to request a minor
> > > revision: instead of requiring positive chater id's to start from 1,
> > > just require them to be contiguous. This keeps implementation simple
> > > (array storage can be used), but the first element need not reflect
> > > "chapter 1" in a user sense.
> > 
> > I preffer this.
> 
> same issue as with timestamps, may i limit that to 31 bit or more
> precissely int32_t?

I don't even care if you limit it to int16_t...

> and is it really that simple? i mean with the start from 0 its a
> count=MAX(count, id); realloc(count); store
> with the contiguous ones lets say you receive
> 100,101,102,103,104,105,99,100,101,...
> 
> here the first info packet with 99 was damaged ...

Yes, I see. You can remap them, I suppose it's a little painful tho..

> then what about mixing that with normal info packets? i mean info packets
> with chapter id 1,2,3
> and then midstream info packets 4,5,6,7, ...
> and if you now cut the file, you loose contiguousity ...
> 
> i think these things need to be resolved before we can think about allowing
> chapter ids to start at >0

Bleh..

Rich