hdpvr driver and VIDIOC_G_FMT

David Röthlisberger david at rothlis.net
Thu Nov 15 10:04:43 PST 2012


On 1 Oct 2012, at 10:09, Hans Verkuil wrote:
> On Sun September 30 2012 14:51:36 David Röthlisberger wrote:
>> I am using the Hauppauge HD PVR video-capture device with a GStreamer
>> "v4l2src". The HD PVR has an upstream driver called "hdpvr":
>> http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=tree;f=drivers/media/video/hdpvr
>> 
>> When the HD PVR device does not have any video on its capture input, the
>> VIDIOC_G_FMT ioctl fails. GStreamer ignores the error (and doesn't
>> report it to my application); the HD PVR fails to start up so even if
>> video is later established on the HD PVR's input, the GStreamer pipeline
>> never receives video. (Bear with me, linuxtv folks; I have plenty of
>> non-GStreamer questions for you.) :-)
>> 
>> It seems to me that the only reason the hdpvr's vidioc_g_fmt_vid_cap [1]
>> fails, is because it doesn't know the video width & height until it
>> has video on its input:
>> 
>>    vid_info = get_video_info(dev);
>>    if (!vid_info)
>>    	return -EFAULT;
>> 
>>    f->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>    f->fmt.pix.pixelformat	= V4L2_PIX_FMT_MPEG;
>>    f->fmt.pix.width	= vid_info->width;
>>    f->fmt.pix.height	= vid_info->height;
>>    f->fmt.pix.sizeimage	= dev->bulk_in_size;
>>    f->fmt.pix.colorspace	= 0;
>>    f->fmt.pix.bytesperline	= 0;
>>    f->fmt.pix.field	= V4L2_FIELD_ANY;
>> 
>> Note that the v4l2 documentation for VIDIOC_G_FMT [2] says:
>> 
>>    Drivers should not return an error code unless the type field is
>>    invalid, this is a mechanism to fathom device capabilities and to
>>    approach parameters acceptable for both the application and driver.
>> 
>> The above discusses "device capabilities" whereas what the hdpvr driver
>> does in this case describes properties of the input data. The difficulty
>> is that the capabilities of the hardware include a whole bunch of
>> different resolutions and frame-rates but these modes seem only
>> available if they match the incoming signal.
>> 
>> Question 1: Is this [return -EFAULT] a bug in the hdpvr driver?
> 
> Yes.
> 
>> If the
>> format is mpeg, why do we need to fill in width & height -- isn't this
>> something the container or codec will tell you?
> 
> For devices with a hardware scaler width and height represent the scaler
> output size. For devices without a scaler width and height are set based
> on the selected standard.
> 
>> It seems to me that all
>> the other fields can be determined even without video on the device's
>> capture input, so this function doesn't need to fail.
> 
> Agreed.
> 
>> Now looking at v4l2_fd_open: [3]
>> 
>>    /* Get current cam format */
>>    fmt.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>>    if (dev_ops->ioctl(dev_ops_priv, fd, VIDIOC_G_FMT, &fmt)) {
>>            int saved_err = errno;
>>            V4L2_LOG_ERR("getting pixformat: %s\n", strerror(errno));
>>            v4l2_plugin_cleanup(plugin_library, dev_ops_priv, dev_ops);
>>            errno = saved_err;
>>            return -1;
>>    }
>> 
>> Question 2: Is v4l2 mostly designed towards webcams (as the comment in
>> the above code implies)?
> 
> libv4l2 is generic, although webcams are the primary use-case. It was initially
> developed with a focus on webcams, which is the reason you see them mentioned.
> But it works just as well with non-webcams.
> 
>> What about capturing a continuous video stream
>> from a video-capture device, where I want to continue capturing even
>> when the capture device loses video input? (Say, it's connected to a
>> set-top box that reboots, and I want to capture the video from the
>> set-top box before it reboots and after it reboots, with a blank image
>> during the time the video was lost.)
> 
> Whether that's possible will depend on the hardware. Some hardware will stop
> streaming if sync is lost, although for analog sources (especially composite
> and S-Video inputs) this is generally not a problem. You usually receive
> static, though, not a blank image.
> 
>> Now to GStreamer: gst_v4l2_open [4] ignores the error from v4l2_fd_open:
>> 
>>    libv4l2_fd = v4l2_fd_open (v4l2object->video_fd,
>>        V4L2_ENABLE_ENUM_FMT_EMULATION);
>>    /* Note the v4l2_xxx functions are designed so that if they get passed an
>>       unknown fd, the will behave exactly as their regular xxx counterparts, so
>>       if v4l2_fd_open fails, we continue as normal (missing the libv4l2 custom
>>       cam format to normal formats conversion). Chances are big we will still
>>       fail then though, as normally v4l2_fd_open only fails if the device is not
>>       a v4l2 device. */
>>    if (libv4l2_fd != -1)
>>      v4l2object->video_fd = libv4l2_fd;
>> 
>> Again a comment mentioning "cams".
>> 
>> Question 3: If "chances are big we will still fail" anyway, could we
>> instead report the error up to the GStreamer pipeline/application?
> 
> The problem is that there are still drivers like hdpvr that do not conform to
> the V4L2 API. While the error really should be reported, the consequence today
> might be that it will stop working for drivers like this.
> 
>> Thanks for your help, and I hope my ignorance doesn't show through too
>> much in my questions. :-) What we haven't tried yet is just removing the
>> call to get_video_info from VIDIOC_G_FMT and related calls in the kernel
>> to avoid the failure condition, and see what happens; but in parallel
>> with that task I thought I'd write to you for some guidance.
> 
> The whole driver needs to be seriously cleaned up. There is a v4l2 compliance
> tools in the v4l2-utils git repository (http://git.linuxtv.org/v4l-utils.git,
> use the master branch) which this driver will fail completely.
> 
> Regards,
> 
> 	Hans


Hans, thank you very much for your reply, it was very helpful.

For what it's worth, the output of the v4l2-compliance tool against the
hdpvr driver is pasted below. (I'm not expecting anybody on this list to
do anything about it -- it's just for the record. I haven't had time to
do any work on the hdpvr driver myself.)

A few things I've learned since my previous email:

+ Hauppauge didn't write the hdpvr Linux driver; it was written by
  someone in the open-source community.

+ Hauppauge are now producing an "HD PVR 2" model[1] with a different
  H.264 encoder chip, different firmware, different USB protocol...
  The hdpvr Linux driver does not work at all with the HD PVR 2.

--Dave.

[1] http://www.hauppauge.com/site/products/data_hdpvr2-gaming.html

--

v4l2-compliance tool output:

Driver Info:
	Driver name   : hdpvr
	Card type     : Hauppauge HD PVR
	Bus info      : usb-0000:00:1d.7-1.4.1
	Driver version: 3.6.6
	Capabilities  : 0x01020001
		Video Capture
		Audio
		Read/Write

Compliance test for device /dev/video1 (not using libv4l2):

Required ioctls:
		fail: v4l2-compliance.cpp(293): !(caps & V4L2_CAP_DEVICE_CAPS)
	test VIDIOC_QUERYCAP: FAIL

Allow for multiple opens:
	test second video open: OK
		fail: v4l2-compliance.cpp(293): !(caps & V4L2_CAP_DEVICE_CAPS)
	test VIDIOC_QUERYCAP: FAIL
		fail: v4l2-compliance.cpp(334): doioctl(node, VIDIOC_G_PRIORITY, &prio)
	test VIDIOC_G/S_PRIORITY: FAIL

Debug ioctls:
	test VIDIOC_DBG_G_CHIP_IDENT: OK (Not Supported)
	test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
	test VIDIOC_LOG_STATUS: OK (Not Supported)

Input ioctls:
	test VIDIOC_G/S_TUNER: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK
	Inputs: 3 Audio Inputs: 3 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Control ioctls:
		fail: v4l2-test-controls.cpp(145): can do querymenu on a non-menu control
		fail: v4l2-test-controls.cpp(201): invalid control 00980900
	test VIDIOC_QUERYCTRL/MENU: FAIL
	test VIDIOC_G/S_CTRL: OK
		fail: v4l2-test-controls.cpp(511): g_ext_ctrls does not support count == 0
	test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL
	test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
	test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
	Standard Controls: 0 Private Controls: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK
	test VIDIOC_ENUM/G/S/QUERY_DV_PRESETS: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
	test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)

Format ioctls:
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK
	test VIDIOC_G_FBUF: OK (Not Supported)
		fail: v4l2-test-formats.cpp(382): !pix.colorspace
	test VIDIOC_G_FMT: FAIL
	test VIDIOC_TRY_FMT: OK (Not Supported)
	test VIDIOC_S_FMT: OK (Not Supported)
	test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)

Codec ioctls:
	test VIDIOC_(TRY_)ENCODER_CMD: OK
	test VIDIOC_G_ENC_INDEX: OK (Not Supported)
	test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

Buffer ioctls:
	test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported)

Total: 38, Succeeded: 32, Failed: 6, Warnings: 0



More information about the gstreamer-devel mailing list