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

[Rich Felker]

On Fri, Jan 06, 2006 at 06:13:59PM +0100, Michael Niedermayer wrote:
> > Wait, you say I CAN? I can't seek in this file at all with the single 
> > back_ptr situation. See end of mail though.
> 
> noone stops you from seeking to any syncpoint ignoring back ptrs ...

Yes, a player can do such a thing, but the results will be rather
broken just like MPlayer's seeking in most formats. :P Especially in
the absence of a good definition of the ts in the syncpoint, it could
be completely meaningless..

I'd like to point out that the most primitive, most-bashed container
format, AVI, makes it easy to find any keyframe in any stream. I
realize that there are much worse containers than AVI such as OGM and
MOV; however, I think AVI is pretty baseline and if we make something
where the user/player has even less useful information for seeking
than AVI, it's pretty sad..

I'm still open to other methods that allow the demuxer to find any
keyframe given a pts. I think the index thing I was talking about
maybe has some chance of being accepted since it doesn't look very
expensive, and this is of course sufficient for finding any keyframe
in files with index, which at least brings us up to the level of AVI.
I'd still like to find a clever way to do it with the non-index seek,
so that players lacking index don't have to do O(backptr) searches.

> > In such a "funny" file, the only corret thing for the demuxer to do is to 
> > seek right before the subtitle keyframe, and now it's the players job to 
> > ignore the video stream until it sees a keyframe. No sane demuxer will 
> > seek, read a frame, then seek again, and then start playing still with 
> > that frame. that is not what we want.

I don't see why it can't..

> i wouldnt call it "funny", 300 frame GOPS are the most common thing for
> the videos floating around, so where do you place subtitles? you have no
> choice due to the timestamp ordering (assume pts=dts) and they wont change
> after every second so you will end with plenty of seriously missmatched
> keyframes similar to this "funny" file this is a practical issue, its not
> about optimaliy but about the time a seek will need and its not a millisec
> but several seconds on slow media (media speed similar to local bitrate)
> 
> this is related as missmatched keyframes is what makes the pts+ptr per stream
> neccessary
> my argument is that seriously missmatched keyframes are the only case where
> pts+ptr per stream have a real advantage and seriously missmatched keyframes
> cause other more serious problems which we havnt solved yet

If you have a player where the media speed is this slow, I think the
solution is pretty obvious. You only treat a single stream as active
for seeking purposes, namely the one that's most relevant to the type
of media you're playing (normally video if it's a multistream file).
Then after seeking you just show no subs/audio until the next keyframe
for the sub/audio stream arrives.

Some people have complained about missing subs, but I don't see it as
that big a deal. I've never said that the player MUST go through hoops
to do frame-exact seeking or ensure that all streams are synced, just
that there must be a way for an advanced player that wants to do these
things to do so.

> > Optionality, weird as it is, is still a solution.
> 
> not for rich IIRC

Right..

Rich