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

[Oded Shimon]

On Fri, Jan 13, 2006 at 08:56:21PM +0100, Michael Niedermayer wrote:
> 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:
> > > 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?

Well, the spec nowhere says that it is not allowed...

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

Well, sounds insane, I can't even begin to think how well this would work, 
and the problem is that (i'm guessing) it deals with the optional high 
level muxer which reorders packets to meet MN rule, and the low level muxer 
is the one that is supposed to deal with syncpoints...

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

OK, umm, I'm trying, but as I feared it is getting increasingly much more 
complicated, especially the interleaved dts cache flushing part... I'm 
still highly suggesting multiple ts. The overhead is REALLY not an issue 
now, so it's not an excuse IMO... (You do remember that it is as many ts's 
as the amount of delay>0 streams, plus one, right? So rarely EVER is more 
than two ts necessary..)

Is 50kb for a 700mb file worth it...

> > BTW, Rich won't be back until Monday.
> 
> good ;)

Bleh.. I need him for my protection! :)

- ods15