[MPlayer-dev-eng] Re: help on libmpdemux usage (Modifié par Jérôme Cornet)

[D Richard Felker III]

On Sat, Jan 17, 2004 at 01:02:53AM +0100, Tobias Diedrich wrote:
> Billy Biggs wrote:
> 
> >   The GPL itself was written before plug-ins became a standard part of
> > software distribution, and before operating systems became the all-
> > encompasing systems that we see today.  Merging these two concepts
> > further complicates the problem, but we can try to decompose it.
> 
> In this context I think the following part of the GPL FAQ is also very
> interesting:
> 
> |What constitutes combining two parts into one program? This is a legal
> |question, which ultimately judges will decide. We believe that a proper
> |criterion depends both on the mechanism of communication (exec, pipes,
> |rpc, function calls within a shared address space, etc.) and the
> |semantics of the communication (what kinds of information are
> |interchanged).
> |
> |If the modules are included in the same executable file, they are
> |definitely combined in one program. If modules are designed to run
> |linked together in a shared address space, that almost surely means
> |combining them into one program.
> |
> |By contrast, pipes, sockets and command-line arguments are communication
> |mechanisms normally used between two separate programs. So when they are
> |used for communication, the modules normally are separate programs. But
> |if the semantics of the communication are intimate enough, exchanging
> |complex internal data structures, that too could be a basis to consider
> |the two parts as combined into a larger program.
> 
> So in the case of a codec, where I can easyly make a GPL-Wrapper which
> takes arguments (input stream parameters) and an input stream
> (compressed input data), prints status messages (output stream parameters)
> and writes to a file (uncompressed output data), then this can be
> considered two seperate programs and would be ok.
> 
> So it may really be more a question of how tightly the two works are
> integrated into each other and less a question of whether we link or
> not, which is only a technical measure to implement the coupling.

Note the comment about sharing a common address space: "If modules are
designed to run linked together in a shared address space, that almost
surely means combining them into one program." If you make a demuxer
communicate back and forth with QuickTime without a common address
space, using pipes, it will be quite slow. :) Increase that 100-fold
for codecs...

Also note the comment about complex data structures. IMO demuxer
packets are a rather complex data structure, at least the way they're
implemented in libmpdemux. I sure find it complex, and I've been
working with the code for 2 years now.

Rich