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

[Michael Niedermayer]

Hi

On Wed, Jan 11, 2006 at 03:21:38PM +0200, Oded Shimon wrote:
> On Wed, Jan 11, 2006 at 11:53:30AM +0100, Michael Niedermayer wrote:
> > On Wed, Jan 11, 2006 at 07:44:23AM +0200, Oded Shimon wrote:
> > > On Fri, Dec 30, 2005 at 09:10:02PM +0200, Oded Shimon wrote:
> > > > [...]
> > > 
> > > Good news. Rich and I were discussing on IRC, and Rich found out we DON'T 
> > > need to store per stream pts. 
> > 
> > so my feeling was correct ...
> 
> Yes, turns out we really should have not just agreed and left it like that. 
> :)

yes, flaming the hell out of each other is always a good idea :)


> 
> > > We need to store pts for every stream with 
> > > non zero decode_delay, and a SINGLE pts for all the decode_delay=0 streams. 
> > > (which is all but one stream most likely). These streams are strictly 
> > > interleaved, so a single pts for them works!
> > 
> > somehow i still belive a single pts for all streams is enough :)
> > 
> > what about:
> > current_dts is the dts of the current frame
> > S is the set of all keyframes which have pts <= current_dts
> > if adding a keyframe to S causes the backptr change to be >= t then write a
> > syncpoint, and assign the maximum pts from S to it
> 
> I'm completely confused by this explanation. Help me with an example. given 
> this scenario:
> 
> audio:   A0  A1  A2  A3  A4  A5  A6
> video: I0  P1  P2  I5  B3  B4  P6  P7
DTS:     -1 0 0 1 1 2 2 3 3 4 4 5 5 6 6
SP:     X0  X1      X2  X3  X4  X5  X6
SP_PTRA -   0       1   2   3   4   5
SP_PTRV -   0       0   0   0   2   2
SP_PTS  -   0       2   3   4   5   6

ok, ive added many syncpoints to make it more clear, obviously there
would be fewer in practice ...
and yes probably the pts selection could be improved by adjusting it
downward where possible (X2 2->1)


> 
> Tell me exactly what data is to be stored in several syncpoints spread 
> around this stream, most interestingly, the syncpoints between I5 and A5. 
> (For the sake of the example, there can be a syncpoint between each 
> frame...)
> 
> > > If we can make overhead less than linear to amount of streams, that would 
> > > kick ass. Any brilliant ideas anyone?...
> > 
> > maybe it would help if we could see some typical values for back ptrs ...
> > i would think they should fall in 2 categories
> > 1. the ones which have near zero ptrs all the time (audio)
> > 2. the ones which have large ptrs (video/subtitles)
> 
> Well, I'm assuming you mean you want an actual dump of back_ptr's, I have 
> attached here:

yes, ill look at this soon

[...]


-- 
Michael