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

[Michael Niedermayer]

Hi

On Friday 04 March 2005 02:06, D Richard Felker III wrote:
> On Fri, Mar 04, 2005 at 01:44:16AM +0100, Michael Niedermayer wrote:
> > Hi
> >
> > On Friday 04 March 2005 00:23, D Richard Felker III wrote:
> > > On Thu, Mar 03, 2005 at 11:24:53PM +0100, Michael Niedermayer wrote:
> >
> > [...]
> >
> > > > > 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,
> >
> > well, the index is needed to find keyframes sometimes, imagine a cd or
> > dvd, a video on it which is encoded at a bitrate close to the max the
> > drive can deliver and a 10sec / 300frames keyframe distance, thats a
> > quite likely scenario IMHO
> > how do u seek in this without an index?
> > first problem is that the O(log n) style seeking based on syncpoints will
> > need several seeks on the drive, which might be slow
> > but the real problem is that after u found the right spot timewise u must
> > find a keyframe and based on the bitrate and 10sec interval that will
> > need 10sec in worst case and 5sec average
>
> i agree this scenario is bad, but compare it with yours. if the index
> is broken into 50 chunks, that's 50 seeks on a cd/dvd drive to load
> the index. if you do this at startup it'll be horribly slow to start
> playing, and if you do it when seeking, it will be just as slow or
> slower than my whole no-index binary search thing.

no, if its broken in 50 chunks, the demuxer only needs to get 7 chunks to find 
the closest keyframe, so its not really worse then old binary search

seek target      v
keyframe:   0123456789ABCDEFGH
chunk_id:   012345670123456701
            0       0       0
            0   4   0   4   0
            0   4 6 0   4 6 0
            0   456 0   456 0


[...]

>
> > this still applies to your proposal if a single index chunk gets damaged
> > and u want to seek to its local area
>
> yep. to me it makes sense that seeking will be slowed down in a file
> with damage..

i prefer fast seeking even in damaged files if its possible, and if not, a 
single index at the end seems like a much better solution complexity wise

[...]
-- 
Michael

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