GNOME Bugzilla – Bug 604434
v4l2src: errors when trying to set an unsupported pixelsize while it knows what the device supports
Last modified: 2014-12-09 21:13:52 UTC
Sorry for the contorted bug title :P The issue, if it issue it really is, happens when you have a device that doesn't support framesize enumeration. v4l2src tries to get maximum and minimum supported framesize and sets int range caps. But it can happen that the device doesn't actually support a continuous range of framesizes and when you set an unsupported one v4l2src errors with something like: 0:00:01.954511990 23359 0xa25ff70 WARN v4l2 gstv4l2object.c:1928:gst_v4l2_object_set_format:<video_source> error: Device '/dev/video1' cannot capture at 642x480 0:00:01.954548657 23359 0xa25ff70 WARN v4l2 gstv4l2object.c:1928:gst_v4l2_object_set_format:<video_source> error: Tried to capture at 642x480, but device returned size 640x480 So, my question is, given that the device correctly reports the nearest supported framesize isn't there a way for v4l2src to update its caps and continue playing with that framesize instead of error out? If you want to manually test this behaviour just "modprobe vivi" and try to set an unsupported cap like the 642x480.
v4l2src could check if downstream supports the suggested width/height too and then switch to that instead of erroring out. Want to provide a patch?
Do you mean that if you set a caps filter it will override it ? Because if the user set 642x480 because gstv4l2src declared it supports 642x480 whereas it actually does not support it. Then I think it's correct to fail. Here I think we want that gstv4l2src does not announce 642x480. But is it reasonable to test each possible size (when going from ready to paused. Maybe probing and cache it ? ) ? But I think it makes senses when we do not force a very exact frame size, i.e. in gstv4l2src::fixate(), we set a size but it should maybe try another one if it fails because of bad announcement. On kernel 3.11, gst-launch-1.0 v4l2src device=/dev/video1 ! videoconvert ! ximagesink works (it selected 1920x500 because in caps it declares only precise framesizes). But on kernel 3.4, it fails because only a framesize range is set in caps so fixate only try 320x200. So it seems they fixed vivi in recent kernel so it confirms it was actually more a problem from the driver side. About checking downstream, maybe it has been added since date of comment #1, see around "gst_pad_peer_query_caps" http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/sys/v4l2/gstv4l2src.c#n320 If there is anything left to do here, could you explain how to do that ? Thx
Indeed, stepwise was introduced to represent ranges with steps. Though, from discussion with v4l2 kernel maintainers, it is likely that HW should always round up, rather then round nearest. By rounding up, we could simply crop the output to fit the negotiated size, without having to care about the HW restriction. We could also deal with stepwise without having to create large caps, since we could expose them as range, remembering the steps ranges, and doing the rounding up ourself. Steps are usually between 2 and 16. Would that be an acceptable solution ?
The new work partially support this now. If the v4l2 driver round up, it works, if it rounds down there is nothing we can do about it. I'm going to propose a kernel fix for that, let's see what they think of doing a round up, always, which seems more useful.
Re-reading this give me an impression of being off from the origin report. Filippo, would it be possbile to provide a gst-launch like pipeline representing what you are doing ?
I'm thinking this isn't really our bug. The driver should better report what it support, and then we would not be in the situation. If driver can report the correct size on S_FMT, it can most likely report it through the FRAME enumeration mechanism.