[MPlayer-dev-eng] Lots of stuff for NUT

[Rich Felker]

On Fri, Jan 06, 2006 at 12:07:19AM +0100, Michael Niedermayer wrote:
> > I don't think we ever had a _usable_ index that was less than 100k/hr.
> > It was just ideas that never worked out in practice because of
> > mistaken assumptions, afaik.. :( Certainly an index that gives
> > less-precise seeking than binary search or else requires you to still
> > do several levels of refinement via binary search is almost useless
> > since the bound of usability has already been crossed. (For local files
> > and fast media, binary search of the whole file is plenty fast. For
> > remote files or slow/non-random-access media, as soon as there's any
> > binary searching it's beyond usability.)
> 
> ok, one example, 1 video, 1 audio stream
> average 100 video frames between keyframes
> 1 hour 3600*25/100 keyframes = 900 -> 900 points we can seek to ignoring
> various dont show the video seek more exactly to the audio stream stuff
> which IMHO is not worth the mess and AFAIK most players dont even support it
> 
> to stay below 10k we have 11 bytes per syncpoint in the index, thats for
> pts + position, so even without any compression thats trivial

OK, this is common but it's also a stupid special case to make
promises based on. For example if you make a file the same length
that's just audio, the index will suddenly become 100x as big, just
because you removed the stream with high keyint. This kind of
instability in size and seekability is what I consider unacceptable.

Behavior should be invariant under adding streams. Adding a stream
should not make a file smaller.

If you want to talk about idiotic things windows kids will do, imagine
them adding a useless no-content stream with huge keyint to make the
index smaller, and ruining seeking in the process... This is a valid
file under your proposal.

> > Also there's the other big thing which is exact audio seeking in files
> > with other streams. If you think it's stupid to want to seek to exact
> > audio time in a music video, what about a song with a text track for
> > lyrics? It would be stupid to only be able to seek to the times when
> > new lyrics appear (or when there are no lyrics), imo...
> 
> yes, how does pts per stream solve that? displaying incorrect lyrics or
> none? thats not a solution IMHO thats a dirty hack

If the user wants to see the lyrics, the player enables them as an
active stream and the seeks accordingly. Note that you're _still_ able
to start decoding audio at the requested timestamp, and you never have
to read more than n_act_streams * max_distance data assuming the text
stream is intra-only.

On the other hand (the case I care about most), if you have no
interest in the lyrics, you just _ignore_ the stream entirely and you
can play the file as if the lyrics weren't there at all, with full
seeking.

There's also a middle-ground of seeking based on the audio stream and
not displaying any lyrics until the next text frame. (And likewise for
video..) You may not consider these behaviors 'good' but IMO it's up
to the player/user to decide if they want this.

> we should either _require_ subtitles to have short keyint (repeat if needed,
> subs are small anyway) or store subtitles non interleaved and seperate so they
> can be read quicker and independantly or find a way so the player can find the
> subtitle and then jump to the video/audio frames

Non-interleaved is impossible for streaming playback without seeking,
and thus not an option. Repetition of subs is possibly an idea, but
I'd rather not. The big syncpoints are less expensive IMO.

> what about back_ptr+pts+num_of_nonkey_frames_since_last_syncpoint per
> stream and syncpoint? that would often allow us to do such jumps but not
> always, for that we would probably need a few more things per stream and
> syncpoint ...

Hmm, I don't follow..?

Rich