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

[Michael Niedermayer]

Hi

On Fri, Jan 13, 2006 at 09:04:26PM +0200, Oded Shimon wrote:
> 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 

great :)


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

what was the EOR problem? we dont allow EOR + delay>0 or do we?


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

the idea is to handle syncpoints like audio & video packets, they should end up
with correct ts and position automagically even with MN rule


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

good ;)

[...]

-- 
Michael