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

[Rich Felker]

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.

> > - 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. 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). The
relocation process also takes time (at the very least, the page faults
for copy-on-write).

Also there's the issue of significant disk io to scan all the
available modules and potentially load them. Since they are separate
files it behaves like disk fragmentation only it's impossible to
defrag. Why do you think gimp takes forever to load? :)

> > - no practical benefits whatsoever
> 
> 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).

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

> > Also, keep in mind that the intent is for libmpdemux to eventually be
> > deprecated, with libavformat as the only demuxer.
> 
> 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.

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.

Rich