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

[Rich Felker]

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.)

> > >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.. :(

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...

Rich