[I've removed ivtv-devel from the cc, because anyone responding from there to this thread will be bounced on pvrusb2-list, due to its subscriber-only filter. Read on...]
On Fri, 18 Jul 2008, Boris Dores wrote: [...] > Using this demuxer, I saw that video PTSs (and audio ones too but > that's a bit less obvious to detect in the current implementation) > are slowly drifting away in the streams that are recorded with the > WinTV-PVR-USB2: there is a gap of 300 units (often positive but > sometimes negative) approximately every 3rd GOP. [...] Well first of all the pvrusb2 driver in the Debian stock 2.6.18 kernel is quite old by today's standards. You probably should be trying a later pvrusb2 driver. Certainly if there are to be any fixes in the driver you'll have to update to it anyway. Probably the easiest way to do this is just to build and install the latest standalone pvrusb2 driver. As for what the driver could be doing here to cause this? Not really sure. The mechanics of combining the streams is totally contained within the cx2341x chip level driver, which both pvrusb2 and ivtv share. The pvrusb2 driver has an ability to work without that chip-level driver, BUT it's only used if the build environment doesn't have a cx2341x module and for the 2.6.18 kernel the module should be there. The ability is only present for really old kernels and is inferior to using the cx2341x module. If you're already running the in-kernel pvrusb2 driver in 2.6.18 then you're definitely using the cx2341x module. Given that the same chip-level driver is being used, then the only possibility would be a mis-configuration of the chip. But there have been changes in that area since 2.6.18, so before we start chasing that it's probably best that you move up to the latest pvrusb2 driver first. -Mike -- Mike Isely isely @ pobox (dot) com PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
