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

[Rich Felker]

On Fri, Jan 06, 2006 at 05:11:09PM +0100, Michael Niedermayer wrote:
> stop this, please let us limit justifications to files which are
> in _practice_ playabe and seekable with all streams enabled assuming
> complete knowledge of all frame pts&pos
> 
> if i cant seek in a file with all streams enabled i delete it or reencode
> it, i wont start disabling random streams in the hope i might be able to
> read the subtitles and listen to the music without the video stream ...

I know Oded was replying to your hypothetical broken file, but I'm
talking about real files. Often I have music videos and want to play
them in my normal audio playlist with -novideo. In this case it's
desirable for them to behave like audio-only files, i.e. I want to be
able to seek to any point, not just to 10-15 second resolution.

> > because you said also back_ptr and pts, and you're against that. But we've 
> > already got all the information we need in the index, so what are you 
> > talking about?
> 
> its just showing that pts + back_ptr is not enough

It is enough unless you want to do the further optimizations like I
mentioned, which are pointless in my example IMO. However...

> ill explain again, you have 1 subtitle stream and 1 video stream
> the video stream is made of 300frame gops exactly
> the subtitle stream too has a keyframe every 300 video frames exactly but
> they are offset by 150 frames, so after seeking you must read 150frames 
> (=5sec delay if CBR and hardware reads at the CBR speed, which is quite
> likely if we have CBR)
> so every seek in this not so unrealistic file will need 5sec at minimum
> with all the index and syncpoints you proposed, even with complete knowledge
> of all keyframes
> the problem is you cant fetch the subtitle keyframe and then seek to the video
> keyframe as you dont know if there are any non-key subtitle frames between

If you think it's important to be able to do this I'm willing to
support it. In the index it takes no space anyway (for common case
files) because we already have a bitfield with only a couple bits
actually used. Could be even better if the stream header had an
intra-only flag (which would be optional, like fixed_fps, but might be
nice for the player to know anyway).

> now if the subtitle stream actually does contain non keyframes then you will
> either have to go with non-interleaving or find a way to find all the
> non-keyframes, repeating them wont work anymore

Now you're the one making unrealistic examples. :)

It's known that there will never be any low-cost way to seek in the
presence of multiple streams with inter frames that don't line up at
same (or nearly same) times. I dont think people will make such files
since other containers have little hope of handling them well too.

Rich