[Bug 725860] v4l2src: Fix using v4l2src with Hauppauge HDPVR video capture device

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #12 from Will Manley <gnome at williammanley.net> 2014-03-07 15:14:43 UTC ---
(In reply to comment #8)
> Review of attachment 271151 [details]:
> 
> This is a bit obfuscated. Basically you have an encoded format, or in this case
> a container. What I'd prefer is to see a special case for that, rather then
> checking for value set to zero. In GstVideoFormatInfo you get a format type
> ENCODED when this is the case.

Agreed, it's not beautiful, but I'm not certain that checking for an encoded
format would be appropriate either.  For instance I have another V4L2 device -
a logitech C920 webcam - which produces h264 encoded video.  Unlike the HDPVR
which is a video-capture device it can choose what height/width video it will
produce.  In that case you want to be insisting that the camera produces video
with the width/height set in the caps.

So in some cases we care about what resolution video will be produced and in
other cases we don't.  We express this via caps.  With caps
"video/x-h264,height=1280,width=720" we want to produce an error if the camera
won't negotiate the appropriate height/width.  With caps just "video/x-h264" we
shouldn't error no matter what height/width we are given.

This is what this patch does but I admit it does go about it in a bit of a
roundabout way and a solution which removes the mpeg special casing:

  if (pixelformat == GST_MAKE_FOURCC ('M', 'P', 'E', 'G'))
    return gst_caps_new_empty_simple ("video/mpegts");

from gst_v4l2_object_probe_caps_for_format might be better.  What would you
suggest?

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