On Fri, Mar 03, 2006 at 03:44:18PM +0100, Michael Niedermayer wrote:
absoloutely no gain. There's a pretty damn good chance that if the index is borked, the entire index is borked. not just a small piece of it. And the file still plays perfectly fine without the index... ("it will make <extreemly rare use case> slightly slower" ...)
its not slightly, and its not rare IMHO
but if you and rich prefer a single monolithic index then well lets return to that, its not the most critical issue ...
I prefer a monolithic index, but more importantly I want it to be writable in one pass without buffering. However, in order to write an index you need to have buffered all the data that goes into the index while writing the file, and if it was possible to buffer all that then it should be possible to reuse that memory (if nothing else) to store the whole nut-format index. Also, you could do a dummy-run first, writing the index to /dev/null to get its size, then once you know the size do the actual unbuffered write. This is similar to my recommended replacement for GNU libc's nonstandard asprintf: call snprintf once to get length, malloc, then snprintf again to store the string. Anyway, if there are good reasons that the broken-up index is better than monolithic, I'm happy to consider it. However, I believe the possibility of one index segment being broken and the rest being ok is extremely rare, like Oded said, and it's also (slightly) complicated for a demuxer to decide what to use the partial index for in this case anyway. Rich