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

[Oded Shimon]

On Sun, Jan 01, 2006 at 01:35:40PM +0200, Oded Shimon wrote:
> On Sat, Dec 31, 2005 at 11:22:33PM -0500, Rich Felker wrote:
> > [...]
> 
> We have decided that MN rule is sufficient for "strict interleaving" with 
> strict "minimum" decode_delay. There is no "correct behavior", choosing 
> between dts and mts is practically arbitrary, so MN rule is the way to go.
> 
> 
> Now, I have some other bad news.
> Rich and I were discussing syncpoint timestamps a lot, and were unable to 
> choose between doing "max(past dts)" or "min(future pts)" (dts or mts).
> After much research: BOTH are wrong!
> 
> "|"  are syncpoints
> "A" is method "max(dts)" for syncpoints
> "B" is method "min(pts)" for syncpoints
> 
>               V
>   A:  0 1 2 3 4 5 6 7
> dts:-1|0|1|2|3|4|5|6|7
> pts: 0|1|2|3|6|4|5|7|8
>      I|P|P|P|I|B|B|P|P
> mts: 0|1|2|3|4|4|5|7|8
>   B:  1 2 3 4 4 5 7 8
>               ^
> 
> I Want pts "4.5". Both methods point me to syncpoint pointed by "V". This 
> syncpoint's back_ptr is pointing to the second "I". But look at what pts 
> that "I" has! "6"!! seek completely failed to give me requested position.
> 
> 
> I have a brand new suggestion:
> the pts of syncpoint is: MAX(pts of last keyframe across all streams)
> (including keyframe right infront syncpoint)
> 
> 
> It works perfectly correct in the scenario above. however, it does NOT work 
> correctly in this scenario:
> 
> A:   A1  A2  A3  A4  A5  A6  A7  A8
> V: I1  P2  I6  B3  B4  B5  P7  P8
> 
> All syncpoints between I6 to A6 will have pts 6.
> Say I only want audio, and I want pts "5.5", after a seek, I'll end up at
> "A3". Which is bad...

This seems like the best solution. We have several options...

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.

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

- ods15