question about how v4l2src gets supported capture device formats
Tim-Philipp Müller
t.i.m at zen.co.uk
Mon Feb 4 13:24:55 PST 2013
On Mon, 2013-02-04 at 16:09 -0500, Chuck Crisler wrote:
> I am working with a Sensoray hardware capture device and encoder. I am
> trying to extend v4l2src to allow me to specify some of the hardware
> modes. I am working with plugins-good v. 0.10.25. The version of the
> libgstvideo4linux2 that was pre-built (I think I got it from
> RPM_FUSION) gets 15 formats, which includes the 12 that the
> VIDIOC_ENUM_FMT ioctl call returns plus 3 others. The version of code
> that I built (and v4l2-ctl --list-formats) only gets the base 12
> formats. The source code breaks out of the 'get' loop when the
> v4l2_ioctl call returns < 0. It simply increments the format index for
> each iteration. I am not changing the driver between runs when I
> change the v4l2src library from the pre-built to my version. How can
> the pre-built library version get the additional formats? In my
> version of the source code there aren't any '#ifdef...' in this area
> and the line numbers for the pre-built library match the line numbers
> of the source, which I got here. The additional formats include: RGB3,
> YU12, YV12.
>
> I thank you if you can restore my sanity! (I appreciate all help
> anyway.)
There's a little helper library called libv4l2/libv4lconvert that does
conversions for more (or less) 'exotic' formats under the hood. The
GStreamer video4linux2 plugin can be built against that lib (then all
ioctls are replaced with function calls into that lib) or not. I suspect
when you build you don't link against it, while the prebuilt version
does.
Cheers
-Tim
More information about the gstreamer-devel
mailing list