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

[Oded Shimon]

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

Most of the superiority (IMHO) is in the dynamic index and handling of 
damaged files. I've actually yet to test the lavf nut demuxer..

- ods15