[MPlayer-dev-eng] Lots of stuff for NUT

[Michael Niedermayer]

Hi

On Thu, Jan 05, 2006 at 02:11:20PM -0500, Rich Felker wrote:
> On Thu, Jan 05, 2006 at 04:09:52PM +0100, Michael Niedermayer wrote:
> > Hi
> > 
> > On Thu, Jan 05, 2006 at 03:44:28PM +0100, Luca Barbato wrote:
> > > Michael Niedermayer wrote:
> > > >
> > > >wait a second, the goal is 10kb/hr index not 500kb read mpcf.txt
> > > 
> > > 10Kb/h doesn't mean much, I'd rephrase it. (depending on the sample 
> > > reate it isn't feasible or trivial)
> > 
> > IIRC it was within that limit
> 
> I don't think we ever had a _usable_ index that was less than 100k/hr.
> It was just ideas that never worked out in practice because of
> mistaken assumptions, afaik.. :( Certainly an index that gives
> less-precise seeking than binary search or else requires you to still
> do several levels of refinement via binary search is almost useless
> since the bound of usability has already been crossed. (For local files
> and fast media, binary search of the whole file is plenty fast. For
> remote files or slow/non-random-access media, as soon as there's any
> binary searching it's beyond usability.)

ok, one example, 1 video, 1 audio stream
average 100 video frames between keyframes
1 hour 3600*25/100 keyframes = 900 -> 900 points we can seek to ignoring
various dont show the video seek more exactly to the audio stream stuff
which IMHO is not worth the mess and AFAIK most players dont even support it

to stay below 10k we have 11 bytes per syncpoint in the index, thats for
pts + position, so even without any compression thats trivial


> 
> > > >what does the _end_user_ gain from that requirement in practice?
> > > 
> > > If the user is using ad editor, much, if the user wants just to play a 
> > > stream nothing...
> > 
> > please elaborate on the "much" part
> 
> Usable performance. If you seek back to far when doing frameexact
> seeking it will be even more unusably slow.. :(

frameexact seeking will always be slow, why does a _rare_ case where its
2x slower matter so much?


> 
> Also there's the other big thing which is exact audio seeking in files
> with other streams. If you think it's stupid to want to seek to exact
> audio time in a music video, what about a song with a text track for
> lyrics? It would be stupid to only be able to seek to the times when
> new lyrics appear (or when there are no lyrics), imo...

yes, how does pts per stream solve that? displaying incorrect lyrics or
none? thats not a solution IMHO thats a dirty hack

we should either _require_ subtitles to have short keyint (repeat if needed,
subs are small anyway) or store subtitles non interleaved and seperate so they
can be read quicker and independantly or find a way so the player can find the
subtitle and then jump to the video/audio frames
what about back_ptr+pts+num_of_nonkey_frames_since_last_syncpoint per
stream and syncpoint? that would often allow us to do such jumps but not
always, for that we would probably need a few more things per stream and
syncpoint ...

[...]
-- 
Michael