SoC: DirectShow/Gstreamer

[Trevor Davenport]

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 (http://wiki.winehq.org/SummerOfCode).  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

[Roderick Colenbrander]

> 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 (http://wiki.winehq.org/SummerOfCode).  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.

Roderick
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01

[Wojciech 'arab' Arabczyk]

Hi
> ... mpeg or divx for movie playback (Warcraft III uses another codec).

That's actually not true. The movie files have been hacked to supply a 
false codec id (so the game would pull in a proper decoding backend) but 
it's actually fully DivX 5.0 compatible.

Warcraft had suplied a binary decoding-only library crafted by the
people at DivX.com just for the purpose of the game.

[Trevor Davenport]

Hi Roderick,
> 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 ;)

Yeah, will definitely need to start with the basics, something simple
for audio and video, such as mp3 or ogg for audio and theora or mpeg
for video.  I think time and the current quartz status would be the
factors that would allow more to be done or not.  If its possible, i
think long term the best solution would be to have something that can
dynamically create the gstreamer pipeline based on the the type of
elements needed and the type of data and the gstreamer elements
currently installed.  GStreamer has a few elements that do this
currently (decodebin/playbin).  I need to look into the current
directshow filters to see how difficult it has been for gstreamer to
use current directshow filters on windows.  My current feeling is that
the hard part won't be getting the data in/out of gstreamer, but
rather making it fit well into wine's quartz (and the work needed
there to accomplish this, bugs, un-implemented, etc).
> 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.

Yeah, I'd start with the simplest directshow program i can find,
likely whatever simple app I can make that uses a few small elements
and get that working.  Then start adding tests or/and testing larger
apps.  Media Player Classic looks like a good candidate for a more
complex programs.  Thanks for mentioning it, I wasn't sure what i
would use for this yet, but having that source would definitely help.


Cheers,

Trevor Davenport