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

[Oded Shimon]

On Fri, Jan 13, 2006 at 11:26:13AM +0200, Oded Shimon wrote:
> On Thu, Jan 12, 2006 at 09:01:41PM +0100, Michael Niedermayer wrote:
> > On Thu, Jan 12, 2006 at 09:27:52PM +0200, Oded Shimon wrote:
> > > On Thu, Jan 12, 2006 at 08:06:47PM +0100, Michael Niedermayer wrote:
> > > > On Wed, Jan 11, 2006 at 08:59:25PM +0200, Oded Shimon wrote:
> > > > > There's one part I still have problem with - what is "current_dts"?... 
> > > > > unfortunately, dts is not monotone across streams... you can't just grab 
> > > > > the dts of the last frame put in the file, because you could end up with 
> > > > > non monotone syncpoint ts.
> > > > 
> > > > well choosing dts is easy, do strict dts ordering
> > > 
> > > I thought we discussed this... :)
> > > Didn't we finally decide on loose MN rule, not strict dts?
> > 
> > iam fine with either but in that case here dts ordering is easier ...
> 
> You'll have to decide between the 2. Either we do strict dts and single 
> syncpoint ts, or loose MN rule and several ts's per syncpoint. It is simply 
> impossible to have both... (If it is possible, which I doubt, it is very 
> very complicated - start by picking the "refernce" ts for the syncpoint)

max(dts) across all streams, not including the frame right after the syncpoint.

> I vote for MN rule and several ts... It is simpler, and in any sane 
> situation, it will only add a SINGLE ts per syncpoint. Having more than one 
> delayed stream in a single file is extremely rare...
> 
> Also loose MN rule seems to please more people than strict DTS...
> 
> Only reason I'm slightly leaning towards single ts is because we already 
> made a nice compression for syncpoints and adding several (optional) pts's 
> in a compact way would be non trivial...

I went over all the details with uau, assuming we allow multiple syncpoints 
in a single position, it IS possible to do everything, the solution is 
"flawless", except that it is much much more difficult to implement. At the 
very least, you need to cache all/some syncpoints and keyframes so you 
can choose back_ptr's correctly, also flushing dts cache for EOR situation 
and now for this max(dts) thing is rather complicated (you have to flush 
the cache interleaved...). What makes it particularly annoying is that all 
this extra handling only comes up at extreme scenarios, so someone could 
make a non compliant muxer and it would be very hard to tell (without 
inspecting the source).

The second solution comes with NO caching cost, and very little complexity:

...write_frame...
if (is_key) {
        old_back_ptr = stream->back_ptr;
        stream->back_ptr = nut->last_syncpoint;
        if (nut->last_syncpoint != old_back_ptr) stream->key_pts = pts;
        if (nut->last_syncpoint - old_back_ptr > nut->max_distance) put_syncpoint();
}

and that's IT. put_syncpoint just grabs the stream->back_ptr and 
stream->key_pts, and it's done. Simple as that...

The overhead cost is, like I said, most likely a SINGLE ts per syncpoint, 
which most likely takes a single byte!...

Demuxer complexity is the same for both solutions...

So, Michael, what's your vote?.. My vote is to second solution...

(BTW, here's a situation where you have to interleave flush dts cache:
A:   0 1 2       6
V1: I     I   I
V2: I       I
pts:0 1 2 3 4 5 6
dts:- - - - 0 1 2 3 4 5

You have to put 3 syncpoints before A6...)

- ods15