[gst-devel] Is gstreamer what I need?

[Ken Seehart]

Sayamindu Dasgupta wrote:
> Hi,
> I am a bit busy this week (I have a project deadline on the 1st of
> May) - however, I have some experience with at least a part of what
> you are trying. See inline for the rest of my mails:
>
Well, I can wait till around March 7.  I really want to find someone who 
is completely confident that all of these requirements are trivial 
(including multi-platform) and can be done in a week.  Obviously this is 
impossible unless there is an easy to use library that already has 
everything, or a person who already has 90% of the job done already.  
Unfortunately, I don't have time for research.
>
> On 4/26/07, Ken Seehart <ken at seehart.com> wrote:
>>
>>  BTW, if it would help, I can post a $2000 bounty on a wxPython 
>> application
>> that demonstrates the functionality listed below by May 1, 2007.  The 
>> result
>> would be open source.  If you are interested, I can provide you with a
>> simple wxPython demo application that displays video from a frame buffer
>> connected to VideoCapture (a Windows-only webcam capture library).  My
>> wxPython demo app could easily be made to display any flat RGB frame 
>> buffer,
>> so you don't need to worry about GUI development.  If that schedule 
>> is a bit
>> tight, we can negotiate a little.
>>
>>  Anyone interested?
>>
>>  - Ken Seehart
>>
>>  Ken Seehart wrote:
>>  What I need :
>>
>>  - multi-platform (Linux, Windows, Mac OSX)
>
> I would recommend GTK+, basically for the reason, you'll get tons of
> code out there in the web - showing how to bind together Gstreamer and
> GTK+. I could find only one wxWidgets based Gstreamer application.
> GTK+ is cross platform, and has a pretty large developer community 
> behind it.
>
For various reasons not related to video, we've already committed to 
wxPython (wxWidgets).  Video/streaming is only one small part of our 
application.  Also, I don't think there will be much complexity in the 
interaction between GUI and video streaming (even at first glance it 
would seem otherwise).  Basically, I already have the ability to display 
video if something puts video data in a frame buffer.  So really GUI 
implementation is trivial.
>
>>  - python bindings
>
> Bindings for (your application/framework - or for the libraries) ?
Python bindings for the audio/video streaming library.
>
>>  - streaming download from our server to our client (I need to 
>> develop both
>> the client and the server)
>
> I would recommend that you take advantage of already existing Open
> Source Software to do this - use Icecast (version 2 is capable of
> streaming Theora video), along with a custom made Icecast "source"
> (the program which actually captures and encodes the video).
> Any client capable of playing Theora streams would be able to handle
> the Icecast stream - if you want a custom developed client - that can
> also be easily done.
> For a icecast source, take a look at a hobby project of mine
> (developed in C) at
> http://sayamindu.randomink.org/ramblings/hippopotamus/
Thanks, I will take a look.
>
>>  - simple audio/video conferencing (one source to many viewers)
>
> Do you mean broadcast ? Or to be clear - will the viewers be also
> participating (ie, speaking to the main speaker) in the conference ?
All viewers will be speaking.  Alternatively, the main speaker can pass 
a mike around so only one viewer can speak at a time.
>
>>  - ability to play videos (only need one format, and it doesn't 
>> matter which
>> one)
>
> Easily done.
>
>
>>  - ability to go to a specified time index during video playback (to 
>> within
>> a 500ms)
>
> In a streaming video ?
>
There are two use cases that pertain to streaming:

1. Streaming download of a video from a library.  The user should be 
able to queue to a time index in either an already downloaded video or a 
video that is in the process of being downloaded.  It would be very nice 
if these cases were not handled separately by the library.  A streaming 
video is really just a video that is in the process of being downloaded.

2. Video conferencing.  In this case, jumping to a time index is not 
relevant.

It would be a nice extra bonus if the video conference could be recorded 
by the client.  If so, cases 1 and 2 conceptually merge a little.

>
>>  - ability to know the current time index during video playback (to 
>> within a
>> 500ms)
>
> In a streaming video ?
>
>>  - interface to webcam devices on all target platforms (Linux, 
>> Windows, Mac
>> OSX)
>
> In Linux - it is easily done - however, in Windows and Mac OS X, it
> might be a problem. You may want to look at VLC as an alternative
> (http://wiki.videolan.org/PythonBinding).
>
bummer.  Windows and Mac OSX are a requirement for me.
> The Windows binaries for Gstreamer is actively being developed and
> maintained by the Songbird developers (IIRC) - the URL is
> http://perso.orange.es/moutte983/gstreamer/
>
Thanks.   I will take a look.
> Thank you,
> Sayamindu
>
>