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

[Michael Niedermayer]

Hi

On Thursday 03 March 2005 22:10, D Richard Felker III wrote:
[...]
> > > > +index_distance
> > > > + distance at which indexes are approximately stored, or 0 if there
> > > > are + no indexes in the file
> > > > + in every [x*index_distance, (x+1)*index_distance) interval, there
> > > > + must be an index packet for every stream, and these packets must be
> > > > + located prior to all frames within the interval
> > > > + reasoning: this ensures good error recovery as there are many and
> > > > + evenly distributed indexes, and also allows very quick finding of
> > > > the + index packets
> > > > +
> > > > +index_modulo
> > > > +index_id
> > > > + each index packet contains every index_moduloth's keyframe of a
> > > > stream, + so the i'th keyframe of a stream will be at least in
> > > > packets with + (i % index_modulo) == index_id
> > > > +
> > > > +index_increment
> > > > + the index_id increment value, this MUST be a relative prime to
> > > > + index_modulo
> > >
> > > I'm confused what index_increment is used for.
> >
> > hmm, not much, theres probably no need to store it in the file at all
> >
> > > > + 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


> 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 :)


> But I'm probably still confused, so 
> could you just give a good clear explanation of what's going on? :)

for each stream the keyframes are split in n(=index_modulo) classes, so that 
all keyframes in class(i) have keyframe_number % n == i

each index_packet then simply contains what class(index_id) contains
and index_id is simply incremented by index_increment (% index_modulo)

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

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

[...]
-- 
Michael

"nothing is evil in the beginning. Even Sauron was not so." -- Elrond