[pvrusb2] pvrusb2 Digest, Vol 11, Issue 9

[Rick Immel]

pvrusb2-request at isely.net wrote:
> Send pvrusb2 mailing list submissions to
>     pvrusb2 at isely.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>     http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> or, via email, send a message with subject or body 'help' to
>     pvrusb2-request at isely.net
>
> You can reach the person managing the list at
>     pvrusb2-owner at isely.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of pvrusb2 digest..."
>
>
> Today's Topics:
>
>    1. changing capture resolution bug (Mike Isely)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 12 Jul 2006 00:14:33 -0500 (CDT)
> From: Mike Isely <isely at isely.net>
> Subject: [pvrusb2] changing capture resolution bug
> To: pvrusb2 at isely.net
> Message-ID: <Pine.LNX.4.63.0607112359250.10412 at cnc.isely.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
>
> There appears to be a problem in the pvrusb2 driver involving setting the 
> capture resolution and it is specific to 24xxx devices.  I looked into 
> this a bit tonight.  First, the VIDIOC_S_FMT cleanup I did is not at fault 
> - that code appears to be working as intended.
>
> The problem right now is that setting any horizontal capture resolution 
> other than 720 results in trashed video (green bars, "screen door" effect, 
> among other things).
>
> The problem only seems to happen on 24xxx devices; 29xxx devices are not 
> affected.
>
> I chased through the pvrusb2 driver; it doesn't really care about 
> resolution choices but instead just passes that information to the 
> appropriate modules.  Best I can tell is that the info is indeed making it 
> to the cx25840 module (which is used for 24xxx devices but not 29xxx 
> devices).  At this point I'm suspecting a problem in the cx25840 module 
> but it's too early to really be sure.
>
> In the mean time if you have a 24xxx device, make SURE you are using a 
> horizontal capture resolution of 720 (using whatever method is appropriate 
> for the app in question).  If for example you have MythTV configured to 
> capture at 640x480 and you are using a 24xxx device, then you are going to 
> have problems.  (And if you don't, then I definitely want to hear about 
> it.)
>
> I strongly believe now that Renan got past this problem in MythTV because 
> by moving to the earlier pvrusb2 snapshot he reverted to logic which had 
> the broken VIDIOC_S_FMT implementation - which means that the pvrusb2 
> driver was going to capture at 720x480 regardless of what MythTV might 
> have asked for.  An alternative and less drastic workaround is just to 
> change the MythTV capture resolution to 720 horizontal.  So what Renan has 
> is a workaround, while the root cause still hasn't been solved.
>
> If anyone sees any behavior that looks related to this issue and conflicts 
> with what I'm saying here, please speak up so I can add more pieces to 
> this puzzle...
>
>    -Mike
>
>
>   
Mike:

I experienced the same problem with MythTV and the 20060702 pvrusb2 
build described by Renan.  The MythTV vertical and horizontal capture 
resolution default to 480x480 with the latest driver.   I fixed the 
problem with the less drastic workaround you have described.  One 
interesting phenomena.  Before the fix if you boot the box and use Xine 
to view the video stream it looks OK.  However, after MythTV has run 
once, the stream displayed by Xine shows the same vertical purple bars 
and distortion as MythTV until the next reboot.

Rick Immel