[MPlayer-dev-eng] NUT (informal) proposal, based on discussions

[Oded Shimon]

On Wed, Jan 18, 2006 at 08:58:16PM +0100, Michael Niedermayer wrote:
> On Wed, Jan 18, 2006 at 09:30:56PM +0200, Oded Shimon wrote:
> > Actually I was reffering to audio being the only active stream, if I wanted 
> > video I would've went to I0... (Do backwards only B frames really exist? 
> 
> i dunno, the standard mentions them ...
> 
> > NUT can't handle them right anyway, and I'm not sure if we should at all, 
> > even though it is rather easy, use GOP boundries instead of keyframes..)
> 
> IMHO we should ignore such b frames ...

Agreed.

> > > so it seems we have
> > > per stream ptr&pts  O(streams log streams) overhead, O(log filesize) seeks
> > > per stream ptr&1pts O(streams log streams) overhead, O(log filesize) seeks
> > > 1 ptr+pts O(log streams) overhead and O(log filesize) seeks but not "optimal"
> > 
> > O(s*log(s))  is a bit unoptimistic, I think even false.
> > My syncpoint compression is worst case scenario O(s) and best case.. Well, 
> > still O(s) but with a much smaller constant. :)
> > 
> > IMO single back pts/ptr is O(1) really, and if you measure it differently, 
> > it is O(max keyint). It has little relavence to amount of streams...
> 
> well, no, your analysis is wrong :)
> if we assume similar streams (similar bitrate, frame rate, keyint, ...) which
> isnt really a unrealistic assumtation and more here for simplicity then 
> anything else then as you add more streams the distance in bytes between
> keyrames of one stream will increase proportionally to the number of streams
> so a back pointer will point proportionally farther -> log n factor for
> storing it unless you do something tricky ...

Ohhh, yes, I forgot extra streams actually take more space in regards to 
actual data... Damn side-effects :)


Any thoughts on other thing I said (max(key_pts)) ?..

- ods15