I have a Hauppauge WinTV-HVR-1600 that I am using to capture ATSC and
clear QAM programming from cable television (Comcast of Chattanooga).
This card uses the cx18 and s5h1409 kernel modules.
There are frequent bursts of bit errors occurring every few seconds in
the incoming transport stream, when I have the card tuned under Linux.
This causes artifacts in the received video as well as skipping in the
received audio, to the point that it is practically unwatchable.
However, under Windows on the same system/capture card, I can tune to
the same programs with nearly perfect reception (no bit errors). Also
these programs appear on my TV with great quality as well. The problem
is happening on all of several different frequencies/programs that I
have tried, although it is more pronounced on some programs
(particularly ATSC) than others.
I have tried the latest v4l-dvb development sources under both kernel
2.6.24 and kernel 2.6.29, and additionally I have tried to use the
unmodified v4l-dvb from kernel 2.6.29. Additionally, I have tried both
the recommended cx23418 firmware from linuxtv.org, as well as the newer
firmware provided by latest the Hauppauge drivers for Windows (which I
am using successfully under Windows). Unfortunately they all produce
the same results.
I primarily use MythTV to capture the programs to a file, and the
resulting file exhibits these problems. However, I can also see the bit
errors when I simply use the 'azap' application to tune the card
directly (and also read the dvr0 device into a file). The BER and UNC
values reported by 'azap' are non-zero approximately one out of every
five samples; then they are usually around 0x200, though this varies.
The BER and UNC values are almost always identical, i.e., no error
correction is taking place, only error detection. Additionally I am not
seeing any TS continuity or TEI flag errors, as detectable in the system
log with the latest changeset.
I have tried to rule out other possible causes such as a weak input
signal (by hooking the capture card directly to the household cable
television input, bypassing all coaxial splitters) and system-specific
issues (by trying this on three different systems). However, to me it
seems that the problem must be originating from an issue in the kernel
modules for this card.
I understand that having some errors in the transport stream is
unavoidable, and I have tried postprocessing with an application such as
Project-X. However, it does not magically take care of this -- the
length of the video is reduced by about 20% and the resulting video
jumps around constantly.
Please let me know how I should proceed in solving this. I would be
happy to provide samples of captured video, results from new tests, etc.
Thanks,
David Ward
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
