Hi Mike, Well I have had my WinTV-PVR-USB2 since the very first versions of your driver and it just works well. Thanks a lot. Nothing to add :)
The only small problem is that I'm still missing a good *small* tv app like xawtv4 (but xawtv4 is alomost dead). However, I have a small python/qt script to write in /sys and mplayer to play the mpeg flux. It does the job :) An old happy user, Xavier > 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... > > 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.) > > 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 > > > _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
