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

[Michael Niedermayer]

Hi

On Fri, Jan 13, 2006 at 10:18:02PM +0200, Oded Shimon wrote:
> 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...

maybe but if its allowed we will have many more issues to deal with
a demuxer in most frameworks (no noone will change their API for nut) can just
send packets to the decoder (or muxer in case of remuxing) 
what do you send to the decoder/muxer for EOR?
in case of 1in 1out decoders (again noone will rewrite their decoders for nut)
there are decode_delay frames in the decoder which must be output, if you
dont flush/output them, then you will receive them when you feed the next
frames in
should EOR produce decode_delay zero-keyframes? decode_delay+1? none? one?
what with remuxing do we loose the EORs?


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

does your muxer reorder packets to meet the MN or DTS rule? if no its not
compliant ...


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

the flushing is needed anyway, if you want delay>0 EORs as 1in 1out decoders
need the extra packets to output anything and for delay=0 EORs theres no
flushing if i understand it correctly so really i cant see how multiple ts
are going to simplify anything here ...

[...]
-- 
Michael