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

[Mike Isely]

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.

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.

  -Mike


-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |