Christian Costa wrote:
Message du 14/06/05 15:43
De : "Marcus Meissner"
A : "Christian Costa"
Copie à : "Marcus Meissner" , "Alexandre Julliard" , "Brian Vincent" , [email protected]
Objet : Re: [QUARTZ] Add FFMpeg video wrapper filter (take 3)
On Tue, Jun 14, 2005 at 01:49:59PM +0200, Christian Costa wrote:
Message du 14/06/05 13:24
De : "Marcus Meissner"
A : "Christian Costa"
Copie à : "Marcus Meissner" , "Alexandre Julliard" , "Brian Vincent" , [email protected]
Objet : Re: [QUARTZ] Add FFMpeg video wrapper filter (take 3)
On Tue, Jun 14, 2005 at 01:05:37PM +0200, Christian Costa wrote:
What do you mean by dlls?
A shared version of libavcodec or a quartz.dll with libavcodec linked
statically?
I meant seperate DLLs (dll.so files for WINE actually).
Is all needed to be in quartz.dll directly?
Or can you split off parts into quartz_codec1.dll , q_codec2.dll or
similar?
Since filters are COM objects, we can embed them in separate dlls but this
would kill the concept of a generic libavcodec wrapper.
And anyway this will not help us that much because the libavcodec is a big
one peace of code and this would require to rewrite the building system to
split codecs.
What I think of is putting all codecs that can benefit from libavcodec
into a wine-quartz-avcoded.rpm which contains one (1) q_avcodec.dll which can
register all these filters.
At the moment, most of the filters depend on a set of files that are
implementation of base types like pins and media format enumerators. I
think the long term goal is to move these into a libwinestrmbase, but at
the moment it is not easy to take a filter from quartz and put it into
another dll / library.
This sounds rather complicated to me.
Indeed, if we have to play with libavcodec files and build, why not just take a
version of this
library, hack it to generate a libwineavcodec.so which contains all the typical
codecs
we want to be supported in wine and finally generate an rpm which contain the
shared lib + the headers.
Ideally, I don't think we want to link to libavcodec at all. We should
import code for as many filters as native implements, without stepping
on patented territory. That way, apps that specifically ask for
CLSID_CMpegAudioCodec, for example, will get exactly what they want.
Rob
