[NUT-devel] CVS: main/DOCS/tech mpcf.txt,1.117,1.118

Rich Felker dalias at aerifal.cx
Fri Mar 3 16:36:25 CET 2006


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




More information about the NUT-devel mailing list