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

[Michael Niedermayer]

Hi

On Thu, Jan 05, 2006 at 08:13:20PM -0500, Rich Felker wrote:
> On Fri, Jan 06, 2006 at 12:07:19AM +0100, Michael Niedermayer wrote:
> > > I don't think we ever had a _usable_ index that was less than 100k/hr.
> > > It was just ideas that never worked out in practice because of
> > > mistaken assumptions, afaik.. :( Certainly an index that gives
> > > less-precise seeking than binary search or else requires you to still
> > > do several levels of refinement via binary search is almost useless
> > > since the bound of usability has already been crossed. (For local files
> > > and fast media, binary search of the whole file is plenty fast. For
> > > remote files or slow/non-random-access media, as soon as there's any
> > > binary searching it's beyond usability.)
> > 
> > ok, one example, 1 video, 1 audio stream
> > average 100 video frames between keyframes
> > 1 hour 3600*25/100 keyframes = 900 -> 900 points we can seek to ignoring
> > various dont show the video seek more exactly to the audio stream stuff
> > which IMHO is not worth the mess and AFAIK most players dont even support it
> > 
> > to stay below 10k we have 11 bytes per syncpoint in the index, thats for
> > pts + position, so even without any compression thats trivial
> 
> 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 


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


[...]

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

[...]
-- 
Michael