[gst-devel] gsoc 2008

Farkas Levente lfarkas at bppiac.hu
Thu Mar 27 18:57:28 CET 2008


Edward Hervey wrote:
> Farkas,
> 
> On Sat, 2008-03-22 at 21:49 +0200, Stefan Kost wrote:
>> hi,
>>
>> Farkas Levente schrieb:
>>> hi,
>>> we found gstreamer is a very promising project for linux. unfortunately 
>>> is far from complete and robust. i've got a few student who would like 
>>> to take part in gsoc in this year and one of the most interesting 
>>> project would be to further develop and fix gstreamer. we think about 
>>> one or two student (but it can be even 4) to make the video part better.
>>> - write more source filter for different hardware component like 
>>> multichannel grabber card and tv card,
> 
>   Can you give some examples of what tv cards ? Don't they already have
> v4l or v4l2 support ?
> 
>>> - decoder and encoder card support,
> 
>   What cards ?


currently there are many grabber card and encoder/decoder mpeg 4, h.264
etc. card manufacturer. most of the grabber card has more analog (bnc)
input. some of them use bttv chips which is supported by the kernel by
default and one can use as v4l or v4l2 source. but only for one channel.
you can select the source but you can't change it (4x25/sec). there are
grabber cards which has not v4l(2) driver but it's own kernel driver.
and same true for decoder/encoder cards and such grabber card which
gives encoded (eg h.264 or mp4 streams). so generally need such video
source elements which has more output pads which is the grabbed (and
ecoded) stream. or such video source elements which has one output but
they use a common kernel module and/or video device card.

>>> - ip camera support native or trough rtp,
> 
>   Can you give examples of what cameras you have in mind ? The rtp stack
> has been tested quite a lot with rtp cameras (including by one of the
> biggest ip-camera manufacturer).

we've got vivotek, arecont, hikvison ip cameras. in 10 run of the
following commands:
gst-launch rtspsrc location='rtsp://192.168.2.97/live2.sdp' latency=500
! decodebin ! xvimagesink
about once we've got the image and other times we just got something
similar:
----------------------------------------------
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /pipeline0/rtspsrc0/udpsrc2: Internal data flow error.
Additional debug info:
gstbasesrc.c(2165): gst_base_src_loop (): /pipeline0/rtspsrc0/udpsrc2:
streaming task paused, reason not-linked (-1)
Execution ended after 541261989 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
FREEING pipeline ...
----------------------------------------------
with the latest gstreamer:
gstreamer-0.10.18-0.fc8
gstreamer-devel-0.10.18-0.fc8
gstreamer-ffmpeg-0.10.3-1.lvn8
gstreamer-plugins-bad-0.10.6-3.fc8
gstreamer-plugins-bad-devel-0.10.6-3.fc8
gstreamer-plugins-bad-extras-0.10.6-3.fc8
gstreamer-plugins-base-0.10.18-0.fc8
gstreamer-plugins-base-devel-0.10.18-0.fc8
gstreamer-plugins-good-0.10.7-1.fc8
gstreamer-plugins-good-devel-0.10.7-1.fc8
gstreamer-plugins-schroedinger-0.9.0-1.fc8
gstreamer-plugins-ugly-0.10.7-1.fc8
gstreamer-python-0.10.11-0.fc8
gstreamer-tools-0.10.18-0.fc8

while at the same time mplayer, xine, vlc always gives the correct video:-(
so we assume something is wrong.


>>> - fix the current rtp code. as we test it currently gstreamer crash with 
>>> real rtp source like ip camera while mplayer, vlc and xine works fine. 
>>> or even do a clean rtp implementation since the current code depends on 
>>>  ffmpeg.
> 
>   what do you mean by "real rtp source" ? What crashes are you
> experiencing ? What operatin system are you running ? What version of
> gstreamer and plugins are you using ? Furthermore the gstreamer rtp
> implementation does *NOT* depend on ffmpeg. I don't know how you came to
> that conclusion.

the "real rtp source" means from real cameras. if we use gstreamer to
read a file and feed it's content through rtp (ie. as a server) and also
use gstreamer as a client then it's working.
fedora 8 with the above packages.

>>> - and the most important to do a lots of fixes to make gstreamer more 
>>> robust.
> 
>   What kind of fixes do you have in mind ?

we'd like to do the video part of the gstreamer production ready. move
as many code to good as possible. made amny valgrind test both for
memory leak and other types of errors to fix.

and the other most important is the windows and mac port of gstreamer.
we'd like to use gstreamer on all of the 3 main os. afais currently
there is not too much effort given into the windows port. we'd like to
do as much windows porting as possible. and at the same time make a
mingw cross-compile build environment to be able to build windows
gstreamer binaries on linux.

>>> - any any other basic not gstreamer coding which would be useful for 
>>> gstreamer.
>>> all of these student in his last year of his M.s.C as programmer 2 of 
>>> them already write a few filter for gstreamer and has a few month of 
>>> knowledge about gstreamer.
>>> what do you think about it?
>>> thank you for your help in advance.
>>> yours.
>>>
>> I've put the developer list in CC. GStreamer is quite a big and fast moving 
>> project and I work more on the audio side and don't want to tell anything wrong. 
>>   Regardless your students are very welcome to apply for SoC project within 
>> GStremaer. We have already listed a few projects under:
>> http://gstreamer.freedesktop.org/wiki/SocProjects
>> but these are just poposals from our side. Regarding your sugestions:
>> * the multichannel grabber card and tv card sounds good
>> * decoder and encoder card support sounds good too
>> * regarding the rtp code, its imho quite good already, there are some real 
>> specific elements in plugins-ugly and -plugins-bad. Be sure to have them in use.
>> * regarding the robustness, we have a unit.test framework in use. Contributions 
>> of further tests (e.g. for rtp) are very welcome.
>>
>> I recommend your students to come to the gstreamer irc channel on freenode, 
>> introduce themself and work on a project proposal, taking the feedback from the 
>> developers into account.
>>
>> Thanks for your offer
>>
>> Stefan
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 

-- 
   Levente                               "Si vis pacem para bellum!"




More information about the gstreamer-devel mailing list