[Bug 604434] 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

--- Comment #2 from Julien Isorce <julien.isorce at gmail.com> 2013-12-31 10:50:46 UTC ---
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

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