[MPlayer-dev-eng] [PATCH] make Matroska demuxer compilation unconditional

[Enrico Weigelt]

* Rich Felker <dalias at aerifal.cx> schrieb:
> On Thu, May 11, 2006 at 12:54:09PM +0200, Enrico Weigelt wrote:
> > > And if so, do you realize that this means:
> > > - major portability problems
> > 
> > Which ones exactly ?
> 
> How do you portably dynamic-load modules? On XSI systems you have
> dlopen and on windows you have LoadLibrary or whatever, but all the
> code to support dynamic loading on many systems is just additional
> bloat.

Therefore, if you don't like this, you can simply build in your
modules statically.

<snip>

> > > - one of either:
> > >   - decreased performance OR
> > >   - significantly increased memory usage
> > 
> > More exactly ?
> 
> Dynamic loaded modules can be position-independent (PIC) or not. PIC
> hurts performance a bit and lowers (but does not eliminate) the memory
> penalties of dynamic loading. 

How much ? Any concrete value ?

> Non-PIC shared libraries must be relocated at load time, meaning that 
> all the program text is modified and takes physical memory (as opposed 
> to only virtual memory). 

Okay, this gets interesting if more than one instance is running. 
Child processes shouldn't be such a problem as long as they don't load
their own modules. (text stays the same).

> The relocation process also takes time (at the very least, the page faults
> for copy-on-write).

Is this really noticable (in our case) ?

<snip>
 
> Also there's the issue of significant disk io to scan all the
> available modules and potentially load them. 

No, this shouldn't happen on every start. Some simple configfile or at 
least an module name cache could do the job. 

<snip>

> > Well, I personally don't need them as shared objects, but disabling
> > them could save resources.
> 
> Agree. Compiletime choice is a much better idea, but IMO it's a waste
> if we'll eventually be switching to lavf-only anyway (since lavf has
> its own compiletime selection).

hmm, when will this happen ? in the near future ?

<snip>
 
> BTW one other disadvantage: supporting dynamic-loaded modules
> encourages people to circumvent the GPL by writing proprietary modules
> that use the module API.

Does it really ? 
And is this really an circumvention or not an legal usage of GPL code ?

At least I see an conflict of your argumentation with the one in
the rp-codec thread ;-o

<snip>

> > Okay, then we should put this work there. 
> > Is there already any timeline for this (obsoleting libmpdemux) ?
> 
> If you want to help with it you could perform extensive
> testing/research and let us know the cases where the mplayer native
> demuxers work better than the lavf ones.

How can I help exactly (by not just watching movies ;-)) ?
Any test plan ? 

<snip>

> In particular we need to support stream selection/languages/subtitles
> from lavf. I know some of the lavf demuxers are less robust than the
> mplayer ones (and vice versa) with regard to broken files too, but I
> don't know the status or relative extent of their quality.

hmm, do we have an test file archive ?

I probably could set up automatic tests if I had enough material.


cu
-- 
"*Who am I*? I am Susan Ivanova, Commander, daughter of Andrei and Sophie
  Ivanova. I am the right hand of vengeance, and the boot that is going 
  to kick your sorry ass all the way back to Earth... I am Death Incarnate, 
  and the last living thing that you are ever going to see. God sent me."
                                                       -- Cmdr. Ivanova