[MPlayer-dev-eng] Lots of stuff for NUT
Oded Shimon
ods15 at ods15.dyndns.org
Wed Jan 11 14:21:38 CET 2006
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.
:)
> > 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
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:
video audio subtitle1 subtitle2
the subtitles are still the fake subtitles, they are a bit of a worst case
scenario, they never line up (subtitle1 is when video->pts % 100 is 0, and
subtitle2 is when video->pts % 100 is 1)
the back_ptr's are already in their coded form. They are already divided by
8, the data here is the actual data necessary to be written in each
syncpoint.
- ods15
-------------- next part --------------
A non-text attachment was scrubbed...
Name: back_ptr.bz2
Type: application/octet-stream
Size: 77031 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060111/6232d814/attachment.obj>
More information about the MPlayer-dev-eng
mailing list