[pvrusb2] MPEG PTSs drifting away
isely at isely.net
Sat Jul 19 13:51:57 CDT 2008
[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
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
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.
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
More information about the pvrusb2