Mailing List Archive

> I have been running some tests on capturing video using the scrolling
> marquee on CNN. When I view this with xawtv, it is of course quite
> smooth. However any time I capture that video to a file, it becomes
> choppy. While the text scrolls by it sticks for a fraction of a second
> after about a second interval.

Do you have de-interlace switched on in your mythsettings?

OK, it's not DMA. And if it happens with mencoder as well as MythTV, it's
not lack of xVideo support in the X driver. So ... so much for rounding up
the usual suspects.

Might it be high CPU load causing frame drops? What does "top" report about
total CPU use when you are recording?

How good is your TV signal? If it is noisy, the encoder may be spending too
much time on encoding the noise to keep up with frame captures. I've seen
this when digitizing low-quality videotapes (using vcr/avifile) ... it
drops frames even though CPU use stays around 50%.

If you have access to an editor like VirtualDub (a freeware Windows app;
alas, I know of nothing free on Linux that is comprarable, though I've been
told that VirtualDub will work under wine), what does it tell you about the
capture (in the File->File Information display)? You can use this to look
at the video frame by frame, offering definitive verification of your
(probably correct) belief that the problem is in the encoding, not the
playback.

Are you providing enough video-buffer space? The link you provided says ...

bttv: using 4 buffers with 2080k (8320k total) for capture

There is some disagreement on this list about optimal buffering, but if you
are dropping frames, I doubt anyone would dispute the merits of *trying* a
higher value to see if it helps. The lowest value I recall seeing anyone
actually recommend here is 8, and some of us (with a lot of RAM) use 16 or
32 (the maximum possible).

I note from the link that you are using your vidcap card with an external,
satellite receiver connected to the Composite1 port. This should reduce the
oddities that might be card specific ... but just to be sure, could you be
explicit (if you post again) about *which* Hauppauge card you are using
("Hauppage WinTV PCI" might be any of several cards)?

Finally, I note that you are using OSS, not ALSA, for sound. This might
cause a problem for MythTV, but I would not expect one using mencoder (at
least given the SB Live card you say you use).

At 01:11 PM 5/11/2003 -0400, Jason Tackaberry wrote:
>Hi everyone. I have a general "encoding from tv card" issue, and while
>it's not exactly MythTV specific, I figure you guys are the most
>qualified to help.
>
>Details on my system can be found here:
>
> http://lists.snowman.net/pipermail/mythtv-dev/2003-April/008653.html
>
>I have been running some tests on capturing video using the scrolling
>marquee on CNN. When I view this with xawtv, it is of course quite
>smooth. However any time I capture that video to a file, it becomes
>choppy. While the text scrolls by it sticks for a fraction of a second
>after about a second interval.
>
>This does sound to me very much like an I/O issue. For testing
>purposes, and to rule out harddisk slowness, I've disabled swap and am
>writing to a RAM disk.
>
>I've tried both mythtv and mencoder with various codecs and settings.
>With mencoder, I've tried raw copy for both audio and video. I have
>also tried disabling audio in the capture to rule out A/V sync issues.
>I have tried both stock Red Hat Linux 9 kernel, as well as 2.4.20-ck6,
>which has both preemptive kernel and O(1) patches.
>
>I have tried playing back the captured video on 3 different systems, all
>of which yield the same jerkiness at the same times, so based on that it
>seems to me the stuttering is in the capturing, not in the playback.
>
>Perhaps this sort of thing just demands very precise timings and it
>requires a hardware solution. Has anyone worked through this problem
>and solved it? Can anyone with a PVR-250/350 or some other capture card
>with hardware encoding comment on their experiences with this sort of
>test?