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

[Michael Niedermayer]

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

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

[...]

> > > > we should either _require_ subtitles to have short keyint (repeat if needed,
> > > > subs are small anyway) or store subtitles non interleaved and seperate so they
> > > > can be read quicker and independantly or find a way so the player can find the
> > > > subtitle and then jump to the video/audio frames
> > > 
> > > Non-interleaved is impossible for streaming playback without seeking,
> > > and thus not an option. Repetition of subs is possibly an idea, but
> > > I'd rather not. The big syncpoints are less expensive IMO.
> > > 
> > > > 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

[...]
-- 
Michael