SoC: DirectShow/Gstreamer

paulo lesgaz jeremielapuree at
Tue Mar 17 06:29:45 CDT 2009


--- En date de : Mar 17.3.09, Roderick Colenbrander <thunderbird2k at> a écrit :

De: Roderick Colenbrander <thunderbird2k at>
Objet: Re: SoC: DirectShow/Gstreamer
À: "Trevor Davenport" <trevor.davenport at>, wine-devel at
Date: Mardi 17 Mars 2009, 11h43

> Hi,
> I'm interested in applying for a GSoC project related to wine.  I am
> looking at doing the DirectShow/Gstreamer idea that is listed in the
> wiki (  From the idea description
> there are a number of factors that would make this an ideal solution.
> The description mentions the availability of legal codecs (from
> fluendo) plus the ability to use the codecs already exposed to
> gstreamer (ie. install a codec and native/wine applications instantly
> get support).
> Recently GStreamer has added some pipeline elements targeted at
> integrating with other frameworks (appsrc/appsink) which allow sending
> data down a gstreamer pipeline and/or recieving it.  Prior to these
> you had to write your own element (this wasn't too much work either
> depending on your needs and may still be preferred for more
> compatibility).
> I am quite familiar with both C and GStreamer.  I have never looked at
> DirectShow though from what i know they are similar in concept.
> GStreamer does have some DirectShow filters that allow it to use
> directshow elements inside GStreamer (on windows anyway).
> My experience with wine has been limited to my own experiments.  I've
> played around with audio drivers for wine.  I wrote one that used
> GStreamer and later adjusted this to use pulseaudio instead.  I never
> got time to clean them up to the point of submitting them.
> I have a few questions in regard to this idea.  Do you think this
> project would provide adequate work to occupy the SoC timeframe?  I
> would have to learn DirectShow which I don't believe would be too
> difficult.  I've worked with DirectSound/DirectX and would expect it
> to require a similiar amount of work.  I've also spent a fair amount
> of time inside wine's source code looking into various bugs.
> I welcome any comments, suggestions or idea related to this.  I'd love
> any feedback so I know this is an idea that is wanted (i would like
> it...i use wine quite often) and so my application is as good as it
> can be.
> Cheers,
> Trevor Davenport

Hi Trevor,

I was the one who put this project suggestion on the wiki. Personally I think it should be a fine soc project. The project would be quite flexible. I expect that the project is too broad and initially should be confined to some widely used audio / video codecs and some widely used rendering methods (rgb / yuv). There will likely be bugs enough to fix ;)

Further I would define one or more apps you want to get working. If I remember correctly some games want to use mpeg or divx for movie playback (Warcraft III uses another codec). The ultimate app to get working using wine's quartz + gstreamer would of course be Windows Media Player ;) Though an open source media player like Media player classic which can use the same codecs is likely easier because you have the source.

Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen:

It would be great if the winemp3.acm decoder could be removed and that Wine can decode mpeg1 (tons of game uses this codec)

Now, for the SoC application:

In the past years, some SoC did not lead any patches in the Wine git tree: applicants gave up before the end, or they did not clean their patches to be put in the tree.

To avoid this, the last year, it was requested for the applicants to have a few patches committed before applying. That showed that thy knew how Wine work. I think that it was a good idea.
Maybe it was a consequence of that, but almost the SoC gave quite a lot of patches in the tree.

Could this be done again for this year.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wine-devel mailing list