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

[Michael Niedermayer]

Hi

On Wed, Jan 18, 2006 at 10:03:26PM +0200, Oded Shimon wrote:
[...]
> > > > 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)) ?..

that several syncpoint would have the same pts? well that will always
happen, think about a single stream in a file 300frame GOP and more then
1 syncpoint within a GOP

[...]

-- 
Michael