[pvrusb2] In-kernel-2.6.18 video stutter & video size?

[Julio Arruda]

Mike Isely wrote:
> On Sat, 14 Oct 2006, roger wrote:
> 
>> On Sat, 2006-10-14 at 19:38 -0700, roger wrote:
>>
>>> I'm seeing a vertical black bar along the right side of my recordings.
>>> (This hints to improper recording resolution size while recording? --
>>> I've tried using "cat" & "mplayer" & "xine".)
>>>
>>> Also seeing a severe stutter on recordings as if there's high cpu usage
>>> or other throughput bottle neck.
>>>
>>> Odd.  All previous snapshots never seemed to distribute these problems.
>>> (I'm going to try disabling the new kernel-2.6.18 DMA engine support but
>>> I doubt this is the source of the problem.)
>>>
>>
>> Wonder if I should try the 2.6.19-rc3 when/if released?
> 
> There's nothing pvrusb2-specific currently planned yet for 2.6.19-rc3.  
> Some fixes went into 2.6.19-rc2, but this had to do with config issues 
> (see earlier threads here about that) not otherwise caused by anything in 
> the pvrusb2 driver itself.  There are additional features / fixes in 
> 2.6.19-rc1, but that's just due to stuff that has accumulated since 2.6.18 
> was snapped.  (Note: 24xxx IR support however is still only in the 
> standalone driver.)
> 
> The pvrusb2 driver itself requires very little CPU to operate.  This is 
> because all the heavy lifting is going on in the device's own mpeg2 
> encoder hardware (which is after all the reason for this device in the 
> first place).  The data stream coming from the device has bandwidth needs 
> that are low enough that in many cases you can get away with running it 
> under USB 1.1.  Worst case (with the bit rate maxed) the driver might have 
> to push 3MB/sec, but more typically you're dealing with less than 1MB/sec.  
> None of that should cause a CPU to saturate.

Humm...There is any cases where the pvrusb2 would have problems 
"recording" the stream in USB1.1, and causing stutter in the recording ?

> 
> A far bigger CPU-sucking thing is mpeg2 playback.  If you don't have any 
> hardware assist (e.g. XvMC enabled in MythTV), then you have to decode and 
> scale mpeg2 in software and that is somewhat computationally expensive.  
> You can see this for yourself.  Rather then running mplayer directly on 
> /dev/video, just cat /dev/video to a file for a while.  Note the CPU 
> utilization.  Now take that same file and play it with mplayer.  Note the 
> (much higher) CPU utilization.  That's where your CPU will be going.
> 
> If there is video stutter and/or messed up video, the cause in the pvrusb2 
> driver could really only be a misconfiguration of either the cx23416 
> encoder or the video capture chip (saa7115 or cx25840 depending on 
> device).  And none of that has to do with CPU utilization.  All of that is 
> the same whether you're using the in-kernel, the in-V4L or the standalone 
> pvrusb2 driver.

One thing I usually try to check, is if the stutter is on the same place 
every single time, if is not, is for sure the playback the culprit :-)
I've used with success for the last year or so, the mediamvp as the 
frontend, is cheap enough, and while the features are not all there, for 
playing recordings and etc, is quite easy to use.
(mvpmc.sf.net)
T