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

[Rich Felker]

On Thu, May 11, 2006 at 10:05:06PM +0200, Enrico Weigelt wrote:
> * 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.

No, bloat is a property of the codebase, not the binary only. Code
that is wasteful should not even exist in the repository.

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

For mplayer the question is not how much. At all is not acceptable.

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

Not only then, although it's the most noticable then. There are other
cases too where it matters.

> > The relocation process also takes time (at the very least, the page faults
> > for copy-on-write).
> 
> Is this really noticable (in our case) ?

Add up 1000 "is it really noticable"s and you have slow crapware. This
is why you avoid adding them in the first place.

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

More bloat and complexity. Now we need a variable cache file on disk
in order to startup efficiently.

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

No.

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

The problem is that the party circumventing the GPL is not touching
the GPL code and thus not bound by the GPL. If they distribute the GPL
program while doing this they are infringing, but you cannot infringe
copyright if you never copy/modify the program.

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

No, you just see your own failure at logic 101. :)

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

Download all the test clips and test them against both native and lavf
demuxers. Test seeking, -alang/-slang, .... Perhaps also compare
performance, etc. Apply random damage to files and compare how it's
handled. Etc.

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

I think the archive is up on mphq2 but I'm not sure.

Rich