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

[Oded Shimon]

On Tue, Jan 03, 2006 at 11:56:35AM +0100, Michael Niedermayer wrote:
> hmm, ok i think i see the problem now, i had the impression that we where
> talking about something else :)
> 
> so the problem is:
> 0123456 7 8 9
> KFFFFFF S K S
> 
> and we want to seek to ts 8 -> we will end at syncpoint for ts=7 and the
> previous keyframe which wont bring us to the optimal keyframe but an earlier
> one, thats something i never saw as a problem as i never wanted to be able
> to seek to every keyframe if now you want to find the optimal keyframe you
> would need to search the whole GOP ...
> 
> ok, heres an attempt to avoid the issue, iam using a single back ptr as
> example, generalizing it to multiple should be trivial ...
> 
> 1. keep track of the last written back pointer and the current (not written)
> back ptr / update it every time a new keyframe is given to the muxer
> 2. if the difference between the written and the internal pointers is
> larger then some threshold t then write a syncpoint with the internal
> back pointer
> (3. write more syncpoints to satisfy the other rules ...)

This is near identical to the rule I wrote up for this...
"if distance from last keyframe on this stream is bigger than max_distance, 
put syncpoint before next keyframe"

> the above case should then look like
> 
> 0012345688
> KSFFFFFFKS
> 
> there is one problem with this, it assumes that all timestamps are in the
> same timebase, if thats false theres a very small chance you might end a
> keyframe earlier, for me thats not a serious enough issue though ...
> if you are crazy enough its possible to store the single back ptr
> timestamp in the timebase of the farthest keyframe and store the corresponding
> stream id too

Yes, Rich and I already agreed that a good pts handling for syncpoints 
would be

coded_pts			v
pts = coded_pts/stream_count
stream = coded_pts%stream_count

It's even MORE compact than using a global timebase by my testing.

> [...]
> my system is trivial: linear search backward, for the case given it works
> as audio has many small intra only frames in practice

It is a solution, but it's flawed in several ways:

It does not fullfill my promise for single underlying stream seek to reach 
certain pts when you have index, however for something like this we could 
go back to old index method or try completely different index method. (The 
old index method was flawed because there is no way to start playing NUT at 
a random position, only at syncpoints.)

It does not work in the sense that you can't really search backwards in 
NUT, because all timestamps and just about everything in NUT are relative 
to last position, the best you can do is find closest syncpoint backwards 
and linear search from it to the syncpoint right after it, and repeat. This 
is rather complicated.


However, overhead with my idea is truely not that horrible. Removing back 
ptr's and per stream pts's altogether removes 160kb of overhead for a 700mb 
file (or possible 1mb to 1.5mb if you have 10 subtitle streams). It 
simplifies everything. Is the overhead really worth it?

- ods15