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

[Michael Niedermayer]

Hi

On Mon, Apr 09, 2007 at 06:26:44PM +0300, Oded Shimon wrote:
> On Sun, Apr 08, 2007 at 02:26:24AM +0200, Michael Niedermayer wrote:
> > Hi
> > 
> > On Sun, Apr 08, 2007 at 02:20:28AM +0300, Oded Shimon wrote:
> > > On Sat, Apr 07, 2007 at 08:16:28PM +0200, Reimar D?ffinger wrote:
> > > > Hello,
> > > > wanted to do this since a long time.
> > > > It is a demuxer that does almost the same as the normal lavf one, only
> > > > that it only accepts some formats and is tested much earlier.
> > > > Does it look okay?
> > > > I also removed a few entries from extension.c that should not be needed
> > > > anymore.
> > > 
> > > [...]
> > > 
> > > > +static const char *preferred_list[] = {
> > > > +    "dxa",
> > > > +    "wv",
> > > > +    "nuv",
> > > > +    "nut",
> > > 
> > > Does this mean that the lavf NUT demuxer would be preffered over the 
> > > libnut one? Because AFAIK, the libnut demuxer is superior to the lavf nut 
> > > demuxer, so it should have priority...
> > 
> > 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)


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


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


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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20070410/9318a55f/attachment.pgp>