What is the point of gst_element_link_filtered() ?
Wim Taymans
wim.taymans at gmail.com
Thu Jun 16 22:17:54 PDT 2011
You can set v4l2src to READY and then query the caps, this should give
you all caps supported by the device.
If you link elements in the READY state, it will check the real
supported formats of the device and linking will fail when no format is
possible. Linking in the NULL state will just do some basic checks but
since the device is not opened, it will not be able to check the device
capabilities.
If you want to get a gray format from the sink you would do:
v4l2src ! ffmpegcolorspace ! video/x-raw-gray ! appsink
it is important to specify at little as possible in the filter to let
the device choose what it can do. In this case, we change the format so
we need an ffmpegcolorspace to make convert in case v4l2src doesn't
support gray.
If you add dimensions to the capsfilter you need to add a videoscale:
v4l2src ! ffmpegcolorspace ! videoscale !
video/x-raw-gray,width=640,height=400 ! appsink
If you want to add a framerate you need to add a videorate.
Wim
On 06/16/2011 11:57 PM, wally bkg wrote:
> I'm coming to the conclusion that v4l2 and gstreamer is fatally flawed.
> Every time I get a new v4l2 capture device something breaks.
>
> I've a new device (Sensoray 2255S) and it was simple to get it to work,
> but not with code that doesn't break when using some other v4l2 device!
>
> At the end of the day I need a 640x480 grayscale buffer coming out of my
> appsink. The problem is how do I define a pipeline to work around the
> various conversions I need when I don't get a error until the pipeline
> tries to play?
>
> I was expecting link_ok = gst_element_link_filtered (source,
> capsfilter, caps_gray) to fail on a card that doesn't support
> grayscale, when the caps filter is set to caps_gray, but it doesn't. I
> don't know anything is wrong until I set the pipeline to playing but
> then its too late!
>
> Perhaps I can best illustrate the problem with a few gst-launch
> examples, although without the same hardware you likely can't duplicate
> the problems.
>
>
> For the device that can't do gray scale directly, this pipeline works:
> gst-launch -v v4l2src device=/dev/video6 ! ffmpegcolorspace !
> video/x-raw-gray, framerate=\(fraction\)30000/1001, width=640,
> height=480 ! ffmpegcolorspace ! xvimagesink
>
> It negotiates:
> ffmpegcsp0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)I420,
> framerate=(fraction)30000/1001, width=(int)640, height=(int)480
>
> ffmpegcsp0.GstPad:src: caps = video/x-raw-gray, width=(int)640,
> height=(int)480, framerate=(fraction)30000/1001, bpp=(int)8, depth=(int)8
>
> The second ffmpegcolor space just fixes the fact that xvimagesink can't
> do grayscale, but is not relevant to my programmatic appsink pipeline.
>
>
>
> For the Sensoray device:
> gst-launch -v v4l2src device=/dev/video2 ! ffmpegcolorspace !
> video/x-raw-gray, framerate=\(fraction\)30000/1001, width=640,
> height=480 ! ffmpegcolorspace ! xvimagesink
>
> negotiates:
> ffmpegcsp0.GstPad:sink: caps = video/x-raw-yuv, format=(fourcc)I420,
> framerate=(fraction)30000/1001, width=(int)640, height=(int)480 and all
> would seem well, except the video has a black bar in the middle because
> of a bug in either the Sensoray drive, v4l2, or gstreamer the
> negotiation is incorrect because I420 is not supported in the driver
> according to v4l-info:
>
> inputs
> VIDIOC_ENUMINPUT(0)
> index : 0
> name : "Composite"
> type : CAMERA
> audioset : 0
> tuner : 0
> std : 0xb0ff
> [PAL_B,PAL_B1,PAL_G,PAL_H,PAL_I,PAL_D,PAL_D1,PAL_K,NTSC_M,NTSC_M_JP,?]
> status : 0x0 []
>
> video capture
> VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE)
> index : 0
> type : VIDEO_CAPTURE
> flags : 0
> description : "4:2:2, planar, YUV422P"
> pixelformat : 0x50323234 [422P]
> VIDIOC_ENUM_FMT(1,VIDEO_CAPTURE)
> index : 1
> type : VIDEO_CAPTURE
> flags : 0
> description : "4:2:2, packed, YUYV"
> pixelformat : 0x56595559 [YUYV]
> VIDIOC_ENUM_FMT(2,VIDEO_CAPTURE)
> index : 2
> type : VIDEO_CAPTURE
> flags : 0
> description : "4:2:2, packed, UYVY"
> pixelformat : 0x59565955 [UYVY]
> VIDIOC_ENUM_FMT(3,VIDEO_CAPTURE)
> index : 3
> type : VIDEO_CAPTURE
> flags : 0
> description : "8bpp GREY"
> pixelformat : 0x59455247 [GREY]
> VIDIOC_ENUM_FMT(4,VIDEO_CAPTURE)
> index : 4
> type : VIDEO_CAPTURE
> flags : 0
> description : "JPG"
> pixelformat : 0x4745504a [JPEG]
> VIDIOC_ENUM_FMT(5,VIDEO_CAPTURE)
> index : 5
> type : VIDEO_CAPTURE
> flags : 0
> description : "MJPG"
> pixelformat : 0x47504a4d [MJPG]
> VIDIOC_G_FMT(VIDEO_CAPTURE)
> type : VIDEO_CAPTURE
> fmt.pix.width : 640
> fmt.pix.height : 480
> fmt.pix.pixelformat : 0x4745504a [JPEG]
> fmt.pix.field : INTERLACED
> fmt.pix.bytesperline : 1920
> fmt.pix.sizeimage : 921600
> fmt.pix.colorspace : unknown
> fmt.pix.priv : 0
>
>
>
> Now if I simply do:
>
> gst-launch -v v4l2src device=/dev/video2 ! xvimagesink
>
> it correctly negotiates a 4:2:2 yuv format and works correctly. Other
> of my capture devices don't support support any 4:2:2 formats, so this
> is not a "common" format I could force the captures to.
>
> So how can I detect this problem before I run the pipeline and adjust
> the pipeline around it?
> Or how do I recover from the "can't negotiate" error when setting the
> pipeline to playing?
>
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list