[MPlayer-dev-eng] a few nut suggestions [short startcodes]

[D Richard Felker III]

On Wed, Oct 06, 2004 at 08:27:15PM +0200, Michael Niedermayer wrote:
> > btw like i said before, i agree with basically all your changes except
> > the keyframe startcode stuff. is there a good reason we can't discuss
> > all these changes and reach a common ground instead of forking?
> 
> certainly, lets discuss the syncpoint vs. keyframe index stuff :)

ok!

> what is the problem with the current (mncf) variant of it, it still has 
> syncpoints but the index points to keyframes instead of the syncpoints
> iam not against changing to a syncpoint index system, if there are problems 
> with the keyframe based indexes, but IMHO the syncpoint index is more 
> problematic

ok, i was confused and thought you were transitioning back to the old
system without syncpoints where we didn't have any good way to specify
when full timestamps have to be coded. i won't object to what you've
done if it actually works well. imo here is a comparison of the two
methods:

keyframe index:
- easy to find a keyframe for a given stream
- no search required

syncpoint index:
- always know all streams' timestamps immediately after seek.
- because a search is required, a player will always seek to the
  correct keyframe rather than doing bad overseeks (like mplayer..)
- smaller

i'd like to propose a third alternative that has the advantages of
both: just have one index, an index of (all) syncpoints. but for each
index entry, have a bitfield showing which streams have had a keyframe
since the last syncpoint.

- barely larger than the old unified syncpoint index
- easy to find a keyframe for a given stream
- requires at most one search per active stream to find the keyframe
  between two consecurive syncpoints, rather than searching over many
  syncpoints.

i'm not sure this is better than your per-stream indices, but it might
be worth considering.

i originally thought your idea was bad because it still required a
search: searching back to the previous syncpoint so you'd be able to
decode timestamps. but in fact you get the timestamp from the index,
and since it's a per-stream timestamp it's exact and the global
timestamp from the syncpoint is unnecessary.

> for example the case of subtitles where "keyframes" are 5min apart leads to 
> the "how do we find the last subtitle" problem with a keyframe index its 
> trivial, and for realtime streams where there is no index we have no hope of 
> seeking back anyway

what about a damaged file (index lost) or a partially-downloaded file
you want to preview? i still think the backwards-pointers at
syncpoints might be worthwhile, but they do add some overhead.

rich