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

[Michael Niedermayer]

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

a player chould also choose to simplify the PTS based on the set of active
streams during index loading

[...]
-- 
Michael