cx18, s5h1409: chronic bit errors, only under Linux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux