[gst-devel] V4lsrc customization (looking for dev for hire)
ensonic at hora-obscura.de
Fri Feb 26 08:21:02 CET 2010
Am 24.02.2010 07:06, schrieb Christopher Brooks:
> 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:
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.
> 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...
> Download Intel® 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.
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel