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

[Oded Shimon]

On Sun, Jan 01, 2006 at 05:14:07PM +0200, Oded Shimon wrote:
> 1. The solution above, and simple give up giving the CLOSEST keyframe to a 
>    specific position, but still enough info to decode requested position.
> 2. The solution of chaanging back_ptr's, which is rather complicated, DOES 
>    indeed solve EVERYTHING, but raises complexity of muxer greately, and 
>    for reasons I'll not detail here, makes it possible to have 2 subsequent 
>    syncpoints with no frame between them.
> 3. Give up fullfilling the promise of "have an index, then no more than a 
>    single file seek to seek to position". I highly dislike this solution.
> 4. Something else out of the box. Maybe go back to old solutions - keyframe 
>    index. (If nobody remembers, the probably with keyframe index is that 
>    you simply cannot seek to arbitrary position in file, only to 
>    syncpoints, because you need "last_pts" state information)
> 
> I vote for 2. It's the "ideal" solution as it always does the right thing.

Sigh, wrong again, I found a situation it breaks.

> "out of the box" solutions i've considered - storing pts and keyframe for 
> every stream in syncpoint, storing maybe 2 ts's in a single syncpoint.
> I haven't been able to find a way to actually use these solutions.
> Does anyone have other ideas?

Yet again, a new idea:

Every syncpoint has the pts and back_ptr for EVERY stream, where the pts is 
the pts of the last keyframe in the stream.

It might sound crazy, but I think done right, it will not take 
significantly more overhead than current method. It's low overhead, low 
complexity, and I'm pretty sure it solved everything. The only part left, 
is decideding how to code it in syncpoint. My best suggestion:

	pts				v
	if (pts&1) back_ptr_div8	v
	else back_ptr_div8=0
	pts = pts>>1

pts is ofcourse in timebase of stream. Index is a whole other story. 
Thoughts, anyone?

- ods15