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

[Oded Shimon]

On Fri, Jan 13, 2006 at 07:46:26PM +0100, Michael Niedermayer wrote:
> On Fri, Jan 13, 2006 at 03:26:22PM +0200, Oded Shimon wrote:
> > 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...
> 
> my vote is for a single timestamp per syncpoint
> 
> your analysis of complexity is not completely objective, multiple timestamps 
> all else equal are more complicated then a single one, so demuxer complexity
> is higher the index format also needs to deal with various special cases like
> zero back ptrs in the mutiple ts case ...

I have already decided zero back ptr is completely unallowed except for 
EOR, so it is irrelavent. Added demuxer complexity is very minimal, 
especially when compared against the new muxer complexity.

> the strict DTS rule is a subset of the MN rule, so a simple muxer can always
> use the DTS rule and have no more complexity then with multiple timestamps
> if for whatever reason the muxer doesnt follow the strict DTS rule then it
> would have some additional complexity to deal with
> keeping track of all syncpoints and keyframes is pretty much needed for the
> index anyway, you could also store backptrs for every stream and syncpoint
> instead of the keyframes for the index sure ...

You forgot EOR, even with strict DTS you need it, so if you handle it you 
might as well handle all of it.

> one possible method to simplify single ts + MN rule / SP TS selection might
> be the following (assuming my headache doesnt affect my abbility to think)
> 
> 1. add exactly one "virtual/imaginary" syncpoint stream
> 2. every time the muxer is feeded with a packet, add a virtual syncpoint with
> its dts=pts equal to either the pts or dts (always choose the same but either
> seems ok)
> 3. discard these virtual syncpoints as needed
> 4. write them like the other packets filling in ptrs and such

Completely confused by this explanation. Doesn't matter, I've more or less 
figured out everything necessary for implementing this method.

Since (I think) we have completely prooved that both methods are 100% 
working, the tradeoff here is purely:
1. complexity and allowing several syncpoints with no frame inbetween
2. overhead of (most likely) 1 byte per syncpoint for almost any file

My vote is still 2, and I have a feeling Rich will flame on the several 
syncpoints thing, however I'm gonna start implementing single ts, and if 
Rich agrees with it then I'm OK with finalizing it...

BTW, Rich won't be back until Monday.

- ods15