[gstreamer-bugs] [Bug 604434] New: v4l2src errors when trying to set an unsupported pixelsize while it knows what the device supports

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=604434
  GStreamer | gst-plugins-good | unspecified

           Summary: v4l2src errors when trying to set an unsupported
                    pixelsize while it knows what the device supports
    Classification: Desktop
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: fargiolas at gnome.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.