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

[Rich Felker]

On Mon, Jan 09, 2006 at 10:44:59PM +0100, Michael Niedermayer wrote:
> > > > MPlayer's demux_nut.c will probably just use only audio and video streams 
> > > > as active streams.
> > > 
> > > lavf will have sub streams active too, i see no logic reason why not and if
> > 
> > Certainly they shouldn't be active if the user doesn't want to see subs..
> 
> sure but if the user wants to see them they will be active and shown
> immedeatly after seeking, IMHO a format which displays something else
> at timestamp X depending upon how you reched X is broken dont you agree?

The format doesn't display anything; the player does. I'm not saying
the person making the file decides which way it should work, rather
that the person watching the file decides. Just like the person
watching might decide to use -framedrop or -hardframedrop even though
they give blatently incorrect output.

> > It doesn't make seeking slow with our method. See pros and cons below;
> > with our method seeking is always fast regardless of which streams are
> > active.
> 
> well there are no restrictions upon keyframe repeation, keyframe distance
> or enough information in the index to skip from a subtitle keyframe to
> a video keyframe, so that is going to be slow in practice no matter if
> you accept it or not and with some additional restrictions and info it
> would be much faster, avi, for example doesnt has that problem as it 
> has enough info in its index to do that skip ...

As long as we have both the keyframe-since-last-syncpoint flag and the
nonkey-frame-since-last-syncpoint flag, that's all you need..

> > "Limited seek info" (your method)
> > - extremely low overhead
> > - approximate seeking is very fast
> > - accurate seeking is very slow, even with index
> 
> its slower but the only cases where its
> very slow are the ones with weird and "broken" streams and these will give
> you a headache no matter what index and syncpoints you use unless of coarse
> you dont display some streams after seeking but that again is something i
> consider wrong

It's always very slow when seeking to an exact keyframe for a single
stream in a file with multiple streams. This is what I meant.

> > - demuxer implementation is somewhat more complex
> 
> i dont see why

Again if you only care to have your demuxer do really bad approximate
seeking, it's not more complex.

If you want my old requirement (latest point such that ALL streams
have keyframe between that point and target pts) then it's somewhat
more complicated due to syncpoint timestamp not having a good
definition. (As far as Oded and I can tell, it's impossible to make a
good definition for it without complicating the muxer a LOT..)

If you're writing a demuxer that can seek to any keyframe, it will
have lots of complications. This is the case I'm assuming since I want
a complete, full-featured demuxer.

Rich