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.
This is already handled
2) driver supports read(), client wants mmap(), format supported by
both. Allocate buffers when REQBUFs happens, handle QBUF and DQBUF by
read()ing frame size chunks into the buffer at the head of the internal
queue when a DQBUF happens, and passing it back out.
This is going to be a case of though luck for the client.
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()
This is already handled, the problem why we currently do not support
read() only devices, is that we used to use mmap under the hood while
emulating read() like this (faster). This turns out to even be a problem
with certain mmap() capable devices, so recently I added the capability
to fall back to using read() to get data from the driver when doing
conversion and the client is doing read.
4) As 2, but needs conversion. Change DQBUF handling to read() frame
size chunks into a temporary buffer, then use libv4lconvert to copy
those chunks from the temporary buffer into the buffer you're about to
pass out.
As 2: this is going to be a case of though luck for the client.
Have I missed anything?
Nope, actually most if the code is already there. I will take a shot at
implementing libv4l2 support for devices which only support read() and
not mmap() mode and send you a patch to test.
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.
Ah, I already thought it might be that device, but I wasn't sure.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
