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

[Michael Niedermayer]

Hi

On Fri, Jan 06, 2006 at 06:30:44PM +0200, Oded Shimon wrote:
> 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.

noone stops you from seeking to any syncpoint ignoring back ptrs ...


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

[...]
> Optionality, weird as it is, is still a solution.

not for rich IIRC

[...]
-- 
Michael