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

[Michael Niedermayer]

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


> 
> > > 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¢...

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)


[...]
-- 
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