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

[Rich Felker]

On Tue, Nov 21, 2006 at 06:32:03PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Mon, Nov 20, 2006 at 08:57:36PM -0500, Rich Felker wrote:
> [...]
> > > > 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.
> 
> what is excessively large? whats idiotic? thats not a good way to specify
> the valid range of a value
> >32bit is idiotic for many people iam pretty sure, still its not enough
> if your input data is in nanosecond precission ...
> 
> and its neither reasonable to assume that everyone has to spend an hour
> per field to guess what range of values would have to be supported to handle
> all non idiotic cases

My idea is that what's idiotic changes with time. That's why we use
vlc rather than fixed-size fields. Unlike other potential areas of
abuse in the spec, I don't see any realistic issue with people
intentionally choosing initial timestamps that will cause trouble with
some implementations. Generally the only things people would choose
for starting timestamps would be 0, the end timestamp of another file,
or the current unix time (seconds since the epoch). All of these will
fit ok in 64bit as long as a sane timebase is used.

> > 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¢...
> 
> well there really are 2 cases IMHO
> A. midstream info packets are not allowed in normal nut files
> B. midstream info packets are allowed in normal nut files
> 
> for A i agree that the pointers and repeating shouldnt be required, there may
> be other reasons though why repeating the info makes sense ...
> 
> for B i dont agree, simply because if info is there, then there are cases
> where the user will want to have that info, think of some capture of odeds
> radio stream, its not unlikely to think that the user would want to seek to
> a specific song (she knows the song title but not the time to seek to)

Arrg, this is what I was saying way back about info streams and I got
flamed to death. Anyway such file has no index already, so it's not
meant to be searchable by index, and searching by chapter _name_ does
not work with binary search so linear search is the natural
requirement anyway.

If a user wants to be able to search this file they'll probably remux
it to make a complete nut file (one with index and repeated headers).
While there are some questions to answer I'd be generally ok with
mandating that a "complete" nut file must not have info except after
the headers and that it must be repeated and identical. On the other
hand I think it still might be best to just always mandate this, so
that a complete nut file can be generated just by appending to an
incomplete one. I fear if we don't allow this people will make
"append-based" completion utilities anyway because it's so much more
convenient.

Rich