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