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

[Oded Shimon]

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:
> > OK, this is common but it's also a stupid special case to make
> > promises based on. For example if you make a file the same length
> > that's just audio, the index will suddenly become 100x as big, just
> > because you removed the stream with high keyint. This kind of
> > instability in size and seekability is what I consider unacceptable.
> 
> the size of the index depends upon the number of points to which you can seek
> these are limited by the available keyframes, adding or removing a stream does
> not increase this number unless you design the muxer to do so
> 
> > Behavior should be invariant under adding streams. Adding a stream
> > should not make a file smaller.
> 
> another philosophical rule, its hard enough to design a format which
> fullfills the requirements of the end user, IMHO theres no need to add
> such rules
> 
> > 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.

> > > > Also there's the other big thing which is exact audio seeking in files
> > > > with other streams. If you think it's stupid to want to seek to exact
> > > > audio time in a music video, what about a song with a text track for
> > > > lyrics? It would be stupid to only be able to seek to the times when
> > > > new lyrics appear (or when there are no lyrics), imo...
> > > 
> > > yes, how does pts per stream solve that? displaying incorrect lyrics or
> > > none? thats not a solution IMHO thats a dirty hack
> > 
> > If the user wants to see the lyrics, the player enables them as an
> > active stream and the seeks accordingly. Note that you're _still_ able
> > to start decoding audio at the requested timestamp, and you never have
> > to read more than n_act_streams * max_distance data assuming the text
> > stream is intra-only.
> 
> first, the demuxer doesnt know if it is intra only, second while it seems
> possible it doesnt seem that easy, third dont we need a O(streamcount * log n)
> or such somewhere if we have no index
> and what if its not intra only? iam no subtitle expert but i would think
> there are some formats which work based on show x, change x, remove x
> style packets, change for example could be a palette change ...

I haven't given the bounds of linear search much thought, but I'm pretty 
sure you never have to check more than 2*max_distance area.

I have another thought. Maybe we should go back to single back_ptr in 
syncpoints, but the index will stay fully informational (pts and ptr per 
stream). In the case of no index, you have to binary search anyway, which 
means tons of seeks. After getting to your spot, linear search the whole 
back_ptr area, large as it may be, without caching it, and when done, seek 
again to the position you really wanted.

When you have an index, just go to the best position, and cache 
2*max_distance data.

This fullfills my old promise of never doing more than a single seek with 
index, and it fullfills all behavioral requirements. And keeps low 
overhead..

It has 2 big disadvantages - Implementation is completely different when 
there is an index and when there isn't, which annoyingly raises demuxer 
complexity. (In my current implementation, by the time you played the whole 
file or seeked enough, it will evantually turn into as if you read an 
index.) Second disadvantage is linear searching O(keyint) area... 
Considering this is only if you don't have an index, and you just did a 
binary search all over the file, it might not be that bad.

> > > 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, 
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?

- ods15