[MPlayer-dev-eng] [PATCH] add lavfpref demuxer for formats where lavf is preferred over native demuxers

[Rich Felker]

On Tue, Apr 10, 2007 at 02:31:05PM +0200, Michael Niedermayer wrote:
> > > in what way is it supperior? IIRC it has O(n) seeking while lavf-nut has
> > > O(log n)
> > 
> > It has O(log n) seeking or even O(1) seeking in lucky cases, unless you 
> > mean in purely memory operations (dealing with syncpoint cache), though 
> 
> if theres any single operation O(n) then the whole is O(n) or worse, thats
> how O() works, having mostly O(log n) and just one n byte memcpy() somewhere
> is not O(log n)

It depends on what you're talking about. Technically, seeking with an
index is O(n) (or at best O(log n) if you binary search the index),
but people call it O(1) because the number of _media_ operations (as
opposed to memory operations) is independent of the file size. It's a
matter of _which quantity_ you're asking for a big-O for..

> > iirc that part was optimized too. I fail to see where it has O(n) seeking, 
> > the seeking code has been almost since the very begginning by binary 
> > search...
> 
> hmm doesnt the dynamic index building do a memcpy() per frame demuxed?
> that is if i seek to the middle play till the end and then seek back to 0
> and watch the first half doesnt the several MB sized index need to be
> memcpied() once per demuxered 100byte vorbis packet :) it definitly was
> that way a long time ago but maybe it has been changed i dont know i didnt
> follow development, so sorry if iam flaming about old bugs ...

I thought he fixed that..

> > Most of the superiority (IMHO) is in the dynamic index and handling of 
> > damaged files. 
> 
> lavf also supports dynamic index building (in true O(log n) time) and
> should work fine with damaged files,

Excellent!

> > I've actually yet to test the lavf nut demuxer..
> 
> if you do please dont forget to report bugs and every cases which isnt
> optimally handled! (there surely are some and id like to improve the code)

:)

~Rich