[MPlayer-dev-eng] [PATCH] make Matroska demuxer compilation unconditional
weigelt at metux.de
Thu May 11 22:05:06 CEST 2006
* 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
Therefore, if you don't like this, you can simply build in your
> > > - 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) ?
> 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.
> > 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 ?
> 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
> > 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 ?
> 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.
"*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
More information about the MPlayer-dev-eng