[MPlayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.67,1.68

[D Richard Felker III]

On Thu, Mar 03, 2005 at 11:24:53PM +0100, Michael Niedermayer wrote:
> > > > > + index_increment / index_modulo SHOULD be approximately
> > > > > 2/(sqrt(5)+1)
> > > >
> > > > And confused why this should be true..
> > >
> > > so that the entries of n consecutive index packets are evenly
> > > distributed, note though i dont have a proof that the golden ratio is the
> > > optimal value here, i just think it is ...
> >
> > Hmm, I misunderstood before, I think.. I had the impression that you
> > were not indexing every single keyframe, only some of them, so that
> > the index would not become insanely huge for audio. 
> 
> no, you did not missunderstand, there can be fewer index_packets then 
> index_modulo, in which case not all keyframes would be in the index

ah, i see.

> > I also thought 
> > that the index entries for a section of the file would be local to
> > that section of the file, but now it sounds to me like maybe they're
> > distributed all over the place across all the indices, which would
> > really be a pain since it would require leaving appropriate space and
> > seeking back to write indices. 
> 
> yes, thats exactly why i expect to be flamed :)

yes, i think i will have to flame, peacefully though.
since the index is nonessential, i don't see why it's worthwhile to
make it error resilient like this. and the disadvantages are great,
both for muxing and demuxing.
the muxer has to seek, and can't write an optimal file without two
passes (it has to do some nasty hacks to leave space). in fact, since
offsets could change after filling in the indices and removing
inefficiency, it's even difficult to make a valid file with two
passes!

as for the demuxer, it has to seek all over the file to read the
index. this is slow; it would probably be just as fast to just use one
index chunk and then do a search for the keyframes not indexed in that
chunk, rather than reading all the indices.
on the other hand, if indices are local in time, then the demuxer only
needs to look at the ones local to the area it wants to seek to...

see more on this idea below..

> one method of muxing this is simply to reserve some space for each index at 
> the index_distance based positions, and at the end choose index_modulo, seek 
> to each reserved spot and write the index there

yes, this works, but it will waste some space. also i don't like the
principle of having to seek to write a valid file. my philosophy is
that good formats can always be written linearly with no buffering.

> i am considering to replace this by a similar system where only past keyframes 
> are stored ...

try this:
at each index_distance, store an index of whichever keyframes you want
to index since the previous index. ALSO, store the offsets and initial
timestamps of all previous index packets in the new index. this means
the very last index packet will tell the locations of all the index
packets, and it also makes seeking on partially-downloaded files work
very well since you can use the index to seek to most of the parts you
already have downloaded.

rich