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

[Oded Shimon]

On Fri, Jan 06, 2006 at 05:11:09PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Fri, Jan 06, 2006 at 04:27:11PM +0200, Oded Shimon wrote:
> > On Fri, Jan 06, 2006 at 02:57:12PM +0100, Michael Niedermayer wrote:
> > > On Thu, Jan 05, 2006 at 08:13:20PM -0500, Rich Felker wrote:
> [...]
> > > > 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.
> > > 
> > > yes and iam sure someone would do that, but its unavoidable, some people
> > > encode files with infinite keyint (ive seen such files), thats exactly the
> > > same, you have a file in which you cant seek, OTOH pts/back_ptrs can be
> > > all set equal without much noticeable effect 
> > 
> > Well, if someone did such a crazy thing, I want to atleast be able to seek 
> > in the audio of the file without having to demux it from the file.
> 
> and you can! but why on earth do you want exact seeking in such broken file
> why do you always resort to justify your design with cases which are so
> unrealistic and broken that normal playback and seeking cant even work

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.

> 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 ...

You might be only interested in the audio to begin with.

> > > > > 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..?
> > > 
> > > num_of_nonkey_frames_since_last_syncpoint is so you can know that its intra
> > > only "locally"
> > 
> > I'm still totally lost on this idea. Do you mean storing this in the index? 
> > In the syncpoint?... What does it do? I'm guessing not in the syncpoint, 
> 
> no, in the syncpoint
> 
> 
> > 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
> 
> 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
> 
> 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

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've grown rather indifferent of this whole thing. I see pros and cons to 
both methods. I'm still leaning towards percision stuff, but mostly right 
now all I care about is getting you and Rich to agree on something, 
whichever it may be. As I see it:

There is an increase in overhead, and nobody cares
There is an increase in percision of seeking, and nobody cares

The problem is, we can't decide which part people don't care about more. 
People don't really care about an additional 200kb of overhead for a 700mb 
file, and they don't care about being to seek to an exact moment. However, 
both Rich and you care about one of these. :/

Optionality, weird as it is, is still a solution.

- ods15