[gst-devel] V4lsrc customization (looking for dev for hire)

[Stefan Kost]

Am 24.02.2010 07:06, schrieb Christopher Brooks:
> Hi,
> 
> I'm a developer/manager involved with an open source project
> (www.opencastproject.org) that relies on gstreamer for some of our base
> functionality.  We're using a vga capture device with the v4lsrc element to
> record the desktop of faculty, and send this along with other video for
> processing for the web.  The device we have, the Epiphan VGA2USB, doesn't
> have a driver that pads frames when there is no signal.  Instead, the v4lsrc
> fails when reading from the frame buffer and disrupts the filter chain.
> This is a pretty big problem, as it causes recording of all streams (we bin
> a bunch together) grinds to a halt.  Turns out that our domain (academic
> lectures) often has this kind of issue (picture faculty unplugging vga from
> one laptop into another).  To this end, we've been encouraging users of our
> system to use it with a DA scaler to ensure there is always a vga signal
> being sent to our capture hardware.

I wonder if this is a problem with v4lsrc. At first can you file a bug and post
an error log there:
 GST_DEBUG="*:5" GST_DEBUG_NO_COLOR <your-app> 2>debug.log

Then could you please also try:
  LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so <yout-app>
and use v4l2src instead of v4lsrc. There is also a
/usr/lib/libv4l/v4l2convert.so that can be preloaded to supply software format
conversion needed for some capture devices.

Basically what I wonder is that as v4lsrc and v4l2src are live sources they
anyway don't capture frames at equidistant timestamps. SO this should just work.

Stefan


> 
> Our system lives in the java/flex/html/css world, so developers with lower
> level C skills are rare, and gstreamer is a big toolkit.  As we're an OSS
> project, I thought I would see if there was anyone who would be willing to
> help out adding a "pad frame" feature to the v4lsrc element to handle this
> kind of issue.  We have no interest in owning the IP for this customization;
> ideally it would be contributed upstream and into the gstreamer core.  We
> may have some limited financial resources depending on the amount of effort
> this would take.
> 
> Any takers?  We have some ideas of where it should be solved in the code,
> but the build process seems quite daunting...
> 
> Chris
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel