Hi,
On 09/03/2009 11:17 AM, Simon Farnsworth wrote:
Hans de Goede wrote:
Hi,
On 09/02/2009 06:32 PM, Simon Farnsworth wrote:
I have a Hauppauge HVR1600 for NTSC and ATSC support, and it appears to
simply not work with libv4l2, due to lack of mmap support. My code works
adequately (modulo a nice pile of bugs) with a HVR1110r3, so it appears
to be driver level.
Which is the better route to handling this; adding code to input_v4l to
use libv4lconvert when mmap isn't available, or converting the cx18
driver to use mmap?
Or modify libv4l2 to also handle devices which can only do read. There have
been some changes to libv4l2 recently which would make doing that feasible.
Roughly what would I need to do to libv4l2?
I can see four new cases to handle:
1) driver supports read(), client wants read(), format supported by
both. Just pass read() through to the driver.
3) As 1, but needs conversion. read() into a temporary buffer, convert
with libv4lconvert (I think this needs a secondary buffer), and supply
data from the secondary buffer to read()
Ok,
That was even easier then I thought it would be. Attached is a patch
(against libv4l-0.6.1), which implements 1) and 3) from above.
Please give this a try.
Regards,
Hans
If it's a case of converting the cx18 driver, how would I go about doing
that? I have no experience of the driver, so I'm not sure what I'd have
to do - noting that if I break the existing read() support, other users
will get upset.
I don't believe that modifying the driver is the answer, we need to either
fix this at the libv4l or xine level.
I wonder though, doesn't the cx18 offer any format that xine can handle
directly?
Not sensibly; it offers HM12 only, and Xine needs an RGB format, YV12,
or YUYV. With a lot of rework, I could have the cx18 encode video to
MPEG-2, then have Xine decode the resulting MPEG-2 stream, but this
seems like overkill for uncompressed video. I could also teach Xine to
handle HM12 natively, but that would duplicate effort already done in
libv4l2 and libv4lconvert, which seems a bit silly to me.
diff -r 88a9c2ed612e v4l2-apps/libv4l/libv4l2/libv4l2.c
--- a/v4l2-apps/libv4l/libv4l2/libv4l2.c Wed Sep 02 11:25:10 2009 +0200
+++ b/v4l2-apps/libv4l/libv4l2/libv4l2.c Thu Sep 03 11:43:15 2009 +0200
@@ -526,10 +526,9 @@
return -1;
}
- /* we only add functionality for video capture devices, and we do not
- handle devices which don't do mmap */
+ /* we only add functionality for video capture devices */
if (!(cap.capabilities & V4L2_CAP_VIDEO_CAPTURE) ||
- !(cap.capabilities & V4L2_CAP_STREAMING))
+ !(cap.capabilities & (V4L2_CAP_STREAMING|V4L2_CAP_READWRITE))
return fd;
/* Get current cam format */
@@ -564,6 +563,8 @@
devices[index].flags = v4l2_flags;
if (cap.capabilities & V4L2_CAP_READWRITE)
devices[index].flags |= V4L2_SUPPORTS_READ;
+ if (!(cap.capabilities & V4L2_CAP_STREAMING))
+ devices[index].flags |= V4L2_USE_READ_FOR_READ;
if (!strcmp((char *)cap.driver, "uvcvideo"))
devices[index].flags |= V4L2_IS_UVC;
devices[index].open_count = 1;
@@ -571,7 +572,7 @@
devices[index].dest_fmt = fmt;
/* When a user does a try_fmt with the current dest_fmt and the dest_fmt
- is a supported one we will align the resulution (see try_fmt for why).
+ is a supported one we will align the resolution (see try_fmt for why).
Do the same here now, so that a try_fmt on the result of a get_fmt done
immediately after open leaves the fmt unchanged. */
if (v4lconvert_supported_dst_format(
