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

[Michael Niedermayer]

Hi

On Fri, Jan 20, 2006 at 04:21:06PM +0200, Oded Shimon wrote:
> On Fri, Jan 20, 2006 at 03:13:15PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Fri, Jan 20, 2006 at 02:59:25PM +0100, Michael Niedermayer wrote:
> > [...]
> > > [...]
> > > > BTW, does anyone have a good idea for efficient but simple data structure 
> > > > for decoded index?... The naive way requires 
> > > > streams*syncpoints*sizeof(uint64_t) memory, which is too much. (5mb of 
> > > > ram?..) Any other idea I can think of requires some complication for 
> > > > just using the values or changing them... (I still want the ability to 
> > > > dynamically build the index while playing)
> > > 
> > > 5mb? i came up with 10mb for a 4gb 10stream file, and for thouse now shouting
> > > 10mb isnt an issue for 4gb files, it is a big issue as thats RAM and a DVD
> > > player shouldnt need 10mb RAM for the index
> > > ahh, one solution, drop the PTS and the index will need <200kb in RAM
> > > and yes every demuxer will do this IMHO, it doesnt even break optimal
> > > seeking:
> > > exact seeking: find the prevous syncpoint P for timestamp X then find the
> > > earliest syncpoint which has a keyframe prior P in every wanted stream
> > > optimal seeking: do the same but additionally check if syncpoint P itself
> > > already contains a keyframe for every stream we want (0 seeks) and if so
> > > check if they are before X (1 extra seek)
> > > now let the flamewars begin again about why 10mb memory, 64x larger RAM 
> > > and 10x larger index in the file is worth saving 1 _rarely_needed_ seek
> > > for optimal seeking
> > 
> > after thinking about it a little the RAM argument obviously is silly
> > just have an array of indexes/pointers (4*syncpoints bytes) and let
> > these point into a array which has stream_id+pts entries its not as
> > simply as a simple flat array but it needs just 4*syncpoints + 10*keyframes
> > bytes, instead of 8*streams*syncpoints
> 
> I already did something similar and crazier:
> 
> struct syncpoint_list {
> 	off_t * pos;
> 	uint64_t * pts;
> 	int len;
> } s;
> uint64_t * p = s->pts;
> 
> for (i = 0; i < sl->len; i++) {
> 	int n = s->pos[i] % (nut->stream_count + 1);
> 	for (j = 0; j < n; j++) {
> 		stream = p[j] % nut->stream_count;
> 		pts = p[j] / nut->stream_count;
> 		...
> 	}
> 	p += n;
> }
> 
> 
> But I evantually decided it is not worth it. BTW, without the pts, decoded 
> index is still nowhere near <200kb, it is atleast 1mb to store just off_t 
> of syncpoint positions.

if you do store them all, a player can always choose to keep as much or
as little in RAM as it wants, and i wouldnt be surprised if many just
extract the video key pos + pts and discard the rest ...


> 
> > a player chould also choose to simplify the PTS based on the set of active
> > streams during index loading
> 
> In libnut API active_streams is defined at nut_seek, not init.

sure, but not everyone will use libnut

[...]

-- 
Michael