[pvrusb2] driver status / update

[Hans Verkuil]

On Monday 12 January 2009 05:00:42 Mike Isely wrote:
> Well I've spent a chunk of time on the driver today, and I'm not
> nearly as far along as I'd wanted.  But I'd thought I'd offer a
> summary here since I know several people are waiting around to hear
> about it.
>
> It's been quite a while since I had released a snapshot, and as such,
> there's been some divergence between the standalone driver and the
> v4l-dvb (and kernel) versions.  I had to pull that back together, and
> I hit a few issues along the way.  Nothing really earth-shattering,
> but it took time to sort out.  Note: the current latest standalone
> snapshot probably won't compile in 2.6.28 - until this afternoon I
> hadn't even tried 2.6.28 yet.  I already have fixes for this, but
> read on...
>
> I looked at the bus_info question, and I've been convinced.  I've
> made a change now that puts the driver serial number into the
> bus_info V4L capability field.  Actually, what I did was to push the
> logic that generated the sysfs-interface string for this into the
> driver core, then exported that back out to the interfaces.  So now
> the sysfs interface (as the "abcdef" in "/sys/class/pvrusb2/abcdef")
> and the V4L interface (via the bus_info capability field) exactly
> match each other.
>
> I haven't dug out the cx25840 problem yet.  I think this is a line of
> investigation that once chased, is going to reveal other issues.  I
> am working on this however.
>
> The raw video support looks very interesting.  To do this right, I
> have to advertise a different "format" in V4L.  Not a surprise; I
> knew this all along and I've had hooks in the driver since the
> beginning to make this feasible.  I should also now do the work to
> support the other I/O methods in V4L (mmap and async).  Those methods
> weren't really useful for mpeg, but for raw uncompressed output they
> make more sense.  Again, the foundation is already there to support
> the other methods; I just need to finish it.  Also, I *might* have to
> support isochronous USB transfers for this.  Well I'm not sure, but
> for data like this uncompressed video where the timing is not
> actually in the stream itself (I assume) you need a transfer method
> that is less sensitive to jitter / latency.  USB bulk transfers don't
> really satify either constraint. Also, I have reason to suspect that
> the video format being sent by the device probably does not match
> what V4L expects.  So the driver is going to have to swizzle the
> pixel data.  No more direct pass-through to the app...

Hi Mike,

I'm pretty sure the format is HM12 (see the 
linux/Documentation/video4linux/cx2341x/README.hm12 file). Note that 
drivers should just pass the data on to the application. Any format 
conversions should take place in libv4l (the conversion library from 
Hans de Goede).

>
> Another even more interesting issue is the audio side of this.  In
> raw mode, there's no means to encapsulate the audio inside the same
> stream as the video - after all V4L was originally a video spec not
> an audio one.  We've been able to ignore this with mpeg since the
> mpeg format allows for embedded audio and the hardware encoder does
> all the heavy lifting here.  But not with raw mode.  In this case
> another means must be found, and I am thinking that what needs to
> happen is that the pvrusb2 driver will have to export an ALSA
> interface now.  So now the driver will actually have to parse the
> stream and send the video to the video app, and (hopefully) PCM audio
> to the ALSA interface.  This change will in fact make the device walk
> and talk pretty much exactly like an old-school V4L device with
> "external" audio - tvtime should then work. Let's hope.  (Might have
> an issue here maintaining audio/video sync, due to split buffers in
> the two paths, but I'm not going to sweat that yet.)

It would be interesting to see if this new alsa module can be written in 
such a way that ivtv and cx18 can use it as well. Currently these 
drivers create a videoX device that outputs the PCM data. A proper alsa 
driver has been on the TODO list for ages but I never got around to it.

Regards,

	Hans

> One other interesting thing about raw support: radio mode.  Right now
> when in radio mode, you get the audio stream as MP3 data inside a
> normal mpeg container, complete with its own useless blank video
> channel as well.  And by "blank" I mean blank as in
> wasting-bandwidth-blank.  If the pvrusb2 driver can act like an ALSA
> device and if we can get the audio in raw mode as PCM data, then,
> well now we can run the radio such that it looks like a normal V4L
> radio device...
>
> Now, with all that said, it should be obvious that full raw mode
> support isn't going to happen immediately.  This is still going to
> take a little while.  But I'm not stuck on this, and I'll let you all
> know how it's going.  I do plan an incremental approach, i.e. the
> audio fun will probably show up after the video is working.
>
> For the immediate future however I need to figure out what is going
> on with the cx25840 module.  Only after dealing with that will I
> seriously look at raw mode.
>
> I can release another snapshot now with the bus_info change.  But
> it's not that big of a change, and with the cx25840 breakage, the
> value of that snapshot will be somewhat less than it should be. 
> (Running such a standalone driver against any kernel at least up to
> 2.6.27 should still be OK, but after that the cx25840 issue is
> probably going to nail everyone except those whose [older] devices
> use the saa7115 instead - then again maybe it's broken too - I need
> to test further.)
>
>   -Mike



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG