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

[D Richard Felker III]

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.

i also expect some demuxers will just ignore all the complexity and
implement broken approximate seeking based on a single index chunk or
something..

> 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..

> another problem with it is that every chunk would store pointers to all 
> previous chunks thats O(n^2) storage, so the number of index chunks would 
> need to be small -> their local (unindexed if damaged) area would be large

what about arranging these index backpointers in some sort of binary
tree structure? :)

> iam really not happy with my current solution either, its just that i havnt 
> found a really better one, i found a few different ones but they suck too in 
> one or another way, and it could be that no solution exists to all the 
> constraints & goals we are considering

with all the complexity and all the indexing solutions sucking so
much, i'm almost beginning to doubt whether we even want to have an
index. since a valid demuxer will need to be able to seek without
index too, it might just make sense to always seek without index, and
save some space (perhaps we could even use the space savings we get
for some sort of extra error resilience and make ivan happy..)

of course i'm not decided on this yet or anything, but maybe it's
really something to consider..

there's also the idea we had while arguing with ivan and others, of
making a separate 'nut recovery' file that would contain all the
packet headers but not data, and that could be distributed to repair
corrupt files. if we made a spec for such a thing, it could also serve
as an external-index file and be stored alongside the nut file for
applications with slow-media..

rich