[MPlayer-dev-eng] nut seeking without an index

[Rich Felker]

On Wed, Sep 07, 2005 at 06:21:56PM -0400, Rich Felker wrote:
> > * updating the timetamps in the syncpoints to match the farthest rightward
> > keyframe of any stream require seekig back (i think this one wasnt proposed)
> 
> Could you explain this better? It sounds like it might be very good,
> but I don't really understand what you mean.

Oh, somehow I missed the "require seekig back" (sic) part. >_<
Anyway I don't see how this could help now... I was misreading it I
think and thought the "require seekig back" was referring to streams
in which you'd have to seek way back to find a keyframe... Or maybe it
still is and now I'm misreading it? I can't make any sense of it..

> > maybe richs idea with backward pointers at sync points can be amended a
> > little to solve the issue:
> > store a single pointer at every syncpoint which points back to a point so 
> > that every stream has at least 1 keyframe between the point and the current
> > sync point
> 
> This could be one hugeass useless backward pointer in the presence of
> subtitles. I know one anime movie (Tenshi no Tamago) with only about
> 10 lines of dialogue over 2 hours...

Unfortunately I can't come up with anything reasonable except either
having a backward pointer for each stream, or treating subtitle and
info streams separately and excluding them from the backpointer rules.
However I think the latter choice is bad, since it may be desirable to
seek according to an info stream, especially if the info stream
represents song/chapter/etc boundaries.

BTW one useful observation for keeping overhead down: as long as
backpointers always point to syncpoints, we can save a few bits by
storing backpointer>>3 rather than backpointer itself. This is because
the sync point startcode is 8 bytes long and doesn't overlap itself,
and it means we can store pointers up to 128k (instead of just 16k) in
a two-byte vlc (and up to 16M instead of 2M in 3-byte vlc).

Personally I'd still be interested in seeing if there's any way we can
do a sane distributed index....

Rich