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

[Oded Shimon]

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



There is another suggestion:
1. back_ptr is to be changed:
It does NOT point to the nearest syncpoint with keyframe, it points to the
nearest syncpoint, with a keyframe that has a pts LOWER than the ts said
in the syncpoint!

2. the ts of syncpoint is: pts of last keyframe written to file, including 
one right after the syncpoint. Actually, it can be just about anything and 
it'll still be correct, but this is best IMO.


Note that this basically means, syncpoints after a keyframe will STILL not 
point it, until the syncpoint's ts is high enough.


If I'm not mistaken, this method will work perfectly for all cases, it has 
only 2 big flaws:

1. I think it adds muxer complexity, is there any way to know the correct 
back_ptr now without indexing all (some) of the keyframes?

2. Current index method will not work, as it is built on this assumption:
   All back_ptr's point to either:
   1. this syncpoint
   2. 1 syncpoint back
   3. same syncpoint as last back_ptr

This change breaks that assumption. :(



Does anyone have any other ideas? My vote is for this method, and to 
rethink index. Basically something like this should not be horribly 
expensive:

    for(i=0; i<stream_count; i++) {
        j = 0;
        while (j < syncpoints) {
            repeat                      v
            type   = repeat & 1
            repeat = repeat >> 1
            b      = repeat & 1
            repeat = repeat >> 1
            if (!type && !b) {
                b                       v
                type = b & 1
                b    = (b >> 1)
            }
            repeat++
            if (type) {
                for(k=0; k<repeat; k++)
                    syncpoint[j+k].stream[i].back_ptr = syncpoint[j-b].pos_div8
            } else {
                for(k=0; k<repeat; k++)
                    syncpoint[j+k].stream[i].back_ptr = syncpoint[j+k-b].pos_div8
            }
            j += repeat
        }
    }


Just 250 bytes more over old method! :)


I think we have perfection:
a syncpoint back_ptr points to INTERESTING keyframes, not to arbitrary 
ones. Index is still small.

Help me with muxer implementation, there might be a way to do this without 
remembering all keyframes... ?


Regarding EOR - the back_ptr of a syncpoint is set to zero if ts of EOR 
is set for this stream to BEFORE the the ts of the syncpoint. Otherwise, It 
points to a valid EOR. Basically, same rules.

- ods15