[pvrusb2] New driver snapshot: pvrusb2-mci-20080210

[Mike Isely]

On Mon, 11 Feb 2008, Mark Goldberg wrote:

> On Feb 11, 2008 6:24 AM, Mark Goldberg <marklgoldberg at gmail.com> wrote:
> > Note that I am compiling on a 64 bit system.
> 
> I looked at this a little more and I'm pretty sure that is it. size_t
> on x86_64 is 64bits and int is still 32 bits.

Yes, this all makes sense now.  I've already committed a change in svn 
to deal with this; the next snapshot will have the change.


> 
> > There is a new issue. You see more vertical interval at the top of the
> > screen. You see two lines of white blinking stuff
> > instead of one. I looked at old recordings and I would guess the
> > picture is shifted down maybe 4 or 8 more lines.
> 
> I looked at this too and since I don't know your code at all, I don't
> see it. I don't think you changed pvrusb2-encoder.c
> at all between the snapshots and I see the vertical interval stuff
> there. The problem definitely exists though.

This is going to be more complex than meets the eye, unfortunately.  

The following information is generally true for any kind of wierd 
framing or other future video digitizing strangeness:

The code which sets up details like is not actually in the pvrusb2 
driver.  Rather, the pvrusb2 driver relies on other chip-level drivers 
in V4L to handle these details.  Two chips are involved here: the 
digitizer and the mpeg encoder.  The digitizer generates the digital 
video frames from the analog stream coming out of the demodulator; the 
encoder then converts these raw frames into an mpeg stream.  If there 
are consistent artifacts / strange lines / framing issues in the frame 
then I'd lay odds that the code driving the digitizer may be the thing 
to be examined.  (If there are transient artifacts, obvious random / 
periodic corruption or "blockiness" showing up then I'd be more inclined 
to blame the mpeg encoder.)  Complicating things further is that there 
are two different digitizers in play here: If you have the older 29xxx 
model then the digitizer is an SAA7115; if you have a 24xxx model then 
the digitizer is a CX25843.

The driver which controls the SAA7115 is "saa7115.ko"; the driver which 
handles the cx25843 is "cx25840.ko".  I don't maintain these - they come 
from the environment in which you are running.  So these are highly 
dependant upon the kernel version you are using and if you have overlaid 
a v4l-dvb repository build on top (or if your distribution's maintainer 
has done that).

While it is theoretically possible that the pvrusb2 driver could 
indirectly be a root cause here - by for example feeding incorrect or 
unexpected control inputs to those drivers - it's not very likely. 
(Though I will admit that there was a 24xxx problem about 1.5 years ago 
that in the end was traced to faulty control input to the cx25840 
module.)  I haven't made any changes recently in the driver that could 
affect those areas.  So I'd be looking at the digitizer module in 
question.  Are you sure that module (cx25840.ko or saa7115.ko) hasn't 
changed or been replaced by other changes?  Can you actually show that 
the previous pvrusb2 snapshot (still) isn't triggering the problem?  I 
*have* seen some transient issues with recent v4l-dvb repository 
snapshots where there's video digitizing issues.  (Unfortunately the 
problem is very transient and I haven't been able to chase it.  
Fortunately the problem only happens with the modules in the recently 
less-stable v4l-dvb repo and not with the in-kernel versions of those 
modules.)

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8