What is the point of gst_element_link_filtered() ?

[wally bkg]

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.
>

Thanks for the tip, all the sample code I've seen shows changing the
pipeline state happens after the elements have been added and linked.
Changing the state to READY after the gst_bin_add_many() function and then
linking the elements individually lets the gst_element_link_filtered() fail
so I can go to "plan B" for building the pipeline.  This makes the
work-around I was attempting work now.

 Pehaps  section 8.3.2." Creating capabilities for filtering"  of the manual
should be updated to point out that

link_ok = gst_element_link_filtered()

will only fail if the pipeline is in the READY state and will always succeed
in the NULL state.




> 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.
>

I'm afraid you've misunderstood my problem.  The v4l2src is accepting a caps
that the Sensory device doesn't actually support.  Up to getting this device
I could just link the source un-filtered and all the capture devices worked
fine with ffmpegcolorspace doing the conversion.  Ideal situation, in
theory, until you get a driver-v4l2-gstreamer bug (don't much matter who's
bug it is!) that accepts an invalid caps.

But now I need to try to set gray caps first and if it works I'm done.  If
not fall back and try the unfiltered caps as before.
I'm not sure if this will be robust against the next v4l2 capture device I
try or not.

I think this whole "query and figure out if it can do what I need" is
bass-ackward, what should be happening is I say "set mode whatever" and I
get either no error and proceed or trap the error and try "plan B" if one is
possible.

All the other stuff you mention was basically being done, as my caps filter
has the 680x480 frame size and frame rate stuff in it and there is a
videoscale in the pipeline (that I left out for clarity) as one of my
capture devices can only do 720x480 or higher and videoscale seems smart
enough to be a noop if scaling is not required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110617/4b20d58d/attachment.htm>