Re: [QUARTZ] Add FFMpeg video wrapper filter (take 3)
Message du 14/06/05 15:43 De : "Marcus Meissner" A : "Christian Costa" Copie à : "Marcus Meissner" , "Alexandre Julliard" , "Brian Vincent" , wine-devel(a)winehq.com 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" , wine-devel(a)winehq.com 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.
So just 1 add-on RPM to install additionaly.
Since this can be provided by external contributors a distributor would not have to worry about libavcoded related problems.
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. This way if I want one day to break all the video (and soon audio) wrapper, noone will have to update the lib. The update will be done from time to time when syncing with ffmpeg sources. And finally, when the time comes when ffmpeg people provide and maintain a shared lib with a stable API, we will have just to drop ours and take theirs. :-) The problem is to find a place to host it and find a victim to do the package and maintain it. (You? :-)) Bye, Christian
Christian Costa wrote:
Message du 14/06/05 15:43 De : "Marcus Meissner" A : "Christian Costa" Copie à : "Marcus Meissner" , "Alexandre Julliard" , "Brian Vincent" , wine-devel(a)winehq.com 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" , wine-devel(a)winehq.com 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
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.
How would you benefit from ffmpeg update in a seamlessly manner? Note that some months ago, I did a version of the wrapper that directly uses source files in the makefile but I realized that taking benefit of acceleration (i386, mmx, sse, etc...) would require merging a lot of things from ffmpeg build to Wine's one. No to mention that I was not sure that ffmpeg sources would be accepted again in Wine tree. That's why I switched back to use the library.
That way, apps that specifically ask for CLSID_CMpegAudioCodec, for example, will get exactly what they want.
I was planning to redirect all these standard DirectShow filters to the wrapper. Bye, Christian
participants (2)
-
Christian Costa -
Rob Shearman