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