[gst-devel] Problem Trying To Use v4l2src
t.i.m at zen.co.uk
Wed Aug 19 20:09:20 CEST 2009
On Wed, 2009-08-19 at 11:40 -0500, Kulecz, Walter wrote:
> It could make for a much easier to maintain project if I simply have a
> gstreamer application instead of a gstreamer application and plugin.
Keep in mind that you can have 'static' plugins local to the application
and part of the application binary. You don't need to create and install
a plugin .so.
> But if the documentation or sample programs were better I can clearly
> see the advantage of using a plugin.
That didn't quite parse. In any case, what sample programs and which
parts of the documentation did you find lacking in particular? If
there's something specific you would like us to add or fix, please file
a bug in bugzilla.
> The devil is in the details of exactly how I put a "capsfilter with
> suitable filter caps after the v4l2src element". I'd prefer to avoid
> format conversions if possible beyond what it takes for ximagesink to
> display on a 16-bit or 24-bit or 32-bit X server.
> Playing around with this pipeline:
> v4l2src ! video/x-raw-yuv, framerate=\(fraction\)30000/1001 ! gamma ! wally ! xvimagesink
> where wally is my gst-template made gstfilter toy plugin, it seems I'm
> getting I420 video. I've not had a lot of luck Googling for for the
> details of the data layouts for the various formats, but poking around
> the SMTPE plugin, I420 seems to be something I can use as the buffer
> seems to consist of width*height bytes of intensity (essentially
> grayscale) data followed by width*height/2 arrays of half resolution
> color channel data which I could ignore.
has some information and links to fourcc.org, which has information
about most of the YUV pixel formats. To specify width/height you
add ,width=640,height=480 to the capsfilter. If the camera doesn't
support that you'll get an appropriate error.
There are various gray formats, such as video/x-raw-gray and
video/x-raw-yuv,format=(fourcc)Y800, but if you are adding other
elements to the pipeline or want to output them to an imagesink, they're
of limited use really, since only few elements support them. Not sure
how many cams can output data in any of those formats either.
> I'm finding the details of specifying a colorspace in ffmpegcolorspace
> or videoscale lacking. I'd rather set the capture to be width=640
> height=480 from the start instead of cropping something line 704x480
> to 640x480. I'm all in favor of having things auto-negotiate formats,
> but how to I tell them my choices are when it matters?
You put a capsfilter with your desired format and width=640,height=480
in the right place. See gst-inspect-0.10 ffmpegcolorspace for what
formats are supported.
> >NTSC/PAL selection is done using the GstTuner interface (see
> >gst-plugins-base libraries docs), I believe. The device might need to be
> There seems to be a lot of poorly if at all documented "common knowledge" about the gstreamer structure and conventions.
Yes. There is a lot of common knowledge and conventions assumed. In
particular, we expect people to have a firm grasp of GLib/Gtk
conventions and some basic knowledge and understanding of GObject and
the GType/GValue system (at least when coding in C).
> I don't see any gstTuner or tuner anywhere in the list of base
> Elements or base Plugins.
It's an interface, not an element or plugin. I did say '-base libraries
docs' for a reason.
> I did find this:
> but the "Details" leaves out the actual strings that sets the norm and
> what "property" I'd be setting or method to invoke to change it, since
> gst-inspect tuner or gsttuner returns "No such element". I'm not
> clairvoyant. I'm left without a clue as to how I'd have "gst-launch
> v4l2src" set the norm to NTSC, short of perhaps grepping the gstreamer
> tree in hopes of finding NTSC or ntsc somewhere.
I don't think there is a way to do this via gst-launch, you'll have to
> Automatically generated documentation I find generally (snip bla).
> A big factor in my evaluation is the fact that retirement is on the
> horizon, and its very unlikely I'll be here past three more years, so
> choosing a methodology for the next version of my application (which I
> inherited and ported from the Mac in 2005) that has an enormous
> learning curve would be a disservice to (snip more bla)
GStreamer does have a bit of a learning curve. However, I think there's
plenty of documentation and good source code around to get you started,
and people in the #gstreamer IRC channel on Freenode will be happy to
fill in the blanks where our docs are not as good as one would hope for,
or at least point you in the right direction.
More information about the gstreamer-devel