Poor HVR 1600 Video Quality

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear Linux Media Community:
I am struggling with what has changed in recent {past 6-9 months} of
kernel releases as related to the HVR-1600 Tuner Card and Analog Signal processing. I spent the bulk of today going through my video chain feeding into the HVR-1600 and tried multiple sources all of which provide good video and sound when fed into a Sanyo TV bought in the 1990s. They all produce recordings similar to the attached file. It almost looks like noise on the system and I am beginning to suspect my card may be hosed on the analog side. Just looking for any thing I may have missed while RTFM and Google. I'd share a 1 minute sample capture but 30.5 mb is too large to attach to a google email and I'm not sure where to drop a sample file for others to download and check out. It should be noted analog video was fine, but sound was intermittent with the kernels and drivers in use back in May. Now the sound it rock solid, but the video has gone noisy.

The particulars of my system are as follows:

HP Pavillion Elite M9040n - Purchased 2010 with an HVR-1600

uname -a :

lspci -vvv :

lsmod | grep cx18 :

Sincerely,
Bob Lightfoot

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQsQR7AAoJEKqgpLIhfz3XnuAH/AuO5z4Lz2hJD+ItBztf5uUE UEvPEvOkacQxDHJr7yMNdNd8XfHQiyahKS8brnATlUJLSllQ7L4QfyFJdL+X2o0z 0QXln/M6jdx+o86Yd284fKtWBQBPMAnpWRDH4TVMeitHsJyFgNAZgSlkSXlg+Slv qET4vDLnmLRZ32n+bZop+2gr3KySgg/K6wepo38rreiUneF4aQdYJoslKV7PjrXE Z87KjEp+iB2p4kTdRR4cO0bCIMtInzpdxfS5vJi33T2XHFvTqD7u3TfTDIQ31A4b ey9gC1ahAXrFOYp2rxFYZK17733Py2MicLU+vE8tIkt62kKvfwQB3RZHwVxNFjY= =HYnR
-----END PGP SIGNATURE-----

A few questions,

Which version of the HVR-1600 do you have? Could you provide the exact PCI ID, vendor ID, and subsystem ID?

Can you post the 1-minute video to a website where it can be downloaded?

Are you using the coax input? Composite? S-video? If you're using the coax input, it would be good just as a test for you to try the s-video input, as that would help rule out various problems that could be introduced by the tuner and demodulation phases.

Are you capturing MPEG compressed video or raw? The HVR-1600 supports both.

Are you familiar enough with compiling kernels that you could bisect this down to a specific commit which introduces the problem?

What application(s) are you testing with?

Devin

Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Devin :
Let me see if I can answer some of your questions.

1. lspci -nn -vvv returns the following for the HVR-1600 Card

2. Links on Google to files related to this issue :
A. The Main Can on the Tuner Card -
https://docs.google.com/open?id=0B95B_9punKEmeHBUNHprMnVNV00
B. First of the Conextant Chips on Card -
https://docs.google.com/open?id=0B95B_9punKEmT2wwbmltSzFWb2c
C. Second of the Conextant Chips on Card -
https://docs.google.com/open?id=0B95B_9punKEmNTdVMENHUFllNzA
D. A Final ESMT Chip on Card -
https://docs.google.com/open?id=0B95B_9punKEmYUd5eWNrWEhudWc
E. The v4l2-ctl and cat /dev/video2 file made from Svideo1

       https://docs.google.com/open?id=0B95B_9punKEmUGdJNTI3ZnR2T1k

F. The v4l2-ctl and cat /dev/video2 file made from Tuner1
https://docs.google.com/open?id=0B95B_9punKEmOUhLWjNyRG02NDA

3. I tested with both the SVideo and Coax Inputs for Analog. As you'll see from the 10 second videos the SVideo works fine but the Coax Tuner is a problem.

4. I don't know if I am capturing raw for MPEG compressed for certain but I'll go over the test method used to make to two videos and that should also answer this question.

5. As far as test tools I have used v4l2-ctl, mplayer, vlc and cat commands for testing.

6. Commands issued in order were as follows for the SVideo Capture:

    A. v4l2-ctl --list-devices
    B. v4l2-ctl -d /dev/video2 --list-inputs
    C. v4l2-ctl -d /dev/video2 --set-input=1  {Note this is SVideo1}
    D. v4l2-ctl -d /dev/video2 --list-standards | less
    E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
    F. mplayer /dev/video2 -cache 8192
    G. close mplayer after successfully watching video
    H. cat /dev/video2 > hvr1600-svideo1.mpg

7. Commands issued in order were as follows for the Tuner1 Capture:

    A. v4l2-ctl --list-devices
    B. v4l2-ctl -d /dev/video2 --list-inputs
    C. v4l2-ctl -d /dev/video2 --set-input=0 {Note this is Tuner1}
    D. v4l2-ctl -d /dev/video2 --list-standards | less
    E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
    F. v4l2-ctl -d /dev/video2 -f 67.250  {Note this is us-bdcst chan 4}
    G. mplayer /dev/video2 -cache 8192
    H. close mplayer after successfully watching video
    I. cat /dev/video2 > hvr1600-Tuner1.mpg

8. It should be obvious by this point, but I am too much of a neophyte to be compiling kernels. I am running Centos 6 and yum for updates for anything I have applied has come through their packaging and distribution system.

NOTES : This SVideo looks good but the Tuner1 is garbage. I also tested the coax input thru my HVR-1850 using xawtv and while it had no audio the video was good although slightly greenish. So I don't suspect the coax cable, especially since when connected to a standard TV it produces a good picture.

Hope you can shed an idea or three.

My end goal it to again record analog video in MythTV.

Sincerely,
Bob Lightfoot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQsZmpAAoJEKqgpLIhfz3XpXwIAKTIcmca98k3rbTU/T6Vz8LC LCRI2J/ocFltV53QdPUOVmjmq/x3FTXZ1B1sSHcS6Av0fdDgU/GpDwp5aWv2apsv lhUF6OtPFxylL8T9q23zPbZ3Io0p/PNzUTi/50LRYFXA+ATCn+AARoIiTHEOa1zW ZEgvjETiCEKu5XxoRV8EUjITAR5F8KiiFeB+qdJkrpC0yee+R5rEL3Hvj3E5M+Cy JbNRe7Su3SxcyaOVMaloxgIvreYaPmTlizBUKdKDphT9QnMIXQ8p55XiFNLX6jvo ntaNaba0cm6sXzUjrSszgOUX4vj91hC/w5My6zkurLj19a9qog+iEFdHZoB3N6g= =B7La
-----END PGP SIGNATURE-----

Ok, so this narrows it down quite a bit. The fact that the s-video is working but the tuner isn't suggests either the tuner is off tune, or the analog demod isn't setup properly. After running the "v4l2-ctl -s 1" command, do you see the standard set to NTSC-M if you then run "v4l2-ctl --all" ? Also, do you hear audio properly despite the video being corrupt?

My guess is that some recent subtle change to the subdev framework is probably resulting in the commands not actually being delivered to the demod. I ran into similar problems a few months ago when doing some work on the cx18 driver for WSS configuration, although I didn't get a chance to push any patches upstream.

Devin

Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Two other questions:

Have you tried dropping the card into a Windows box to make sure your hardware isn't just dead? I know you said you thought it worked 6-9 months ago, but it's possible that it is just dumb luck that part of the hardware died and it has nothing to do with the kernel revision.

Also, what kernel did it work last on? If you could determine a specific revision, it would help narrow down where the problem was introduced (assuming it really is a regression in the kernel).

Devin

Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

Alright, this is one of the older card models. They have been working for quite a long while.

Looks good.

Blech. Obviously an almost total loss of Horizontal Synchronization. Vertical Synchronization appears to be OK, under the circumstances.

FYI, I normally associate the following conditions with signal level going into the CX23418's integrated CX25843 A/V decoder:

- Good sound, bad video: signal strength too low
- Bad/no sound, good video: signal strength too high

Low video signal strength could explain why H-sync is lost. However, it also could be a DC voltage level building up on the CVBS signal trace between the tuner and the CX23418 causing the CVBS signal (and the H-sync pulse) to be floated upwards, such that the H-Sync pulse ins't detected.

So here's what you need to do:

1. provide the output of v4l2-ctl -d /dev/video2 --log-status, so I can see the analog tuner assembly that your unit has.

2. Test the unit under the previous Linux kernel version with which you were *sure* the unit worked properly. Or test with Windows as Devin suggested. We're trying to eliminate a bad HVR-1600 card here, so if you can test it in that very same machine, all the better.

Also, if you can provide us with the two kernel versions, working and non-working, we can narrow down if a kernel change caused the problem for you.

3. Test with as few cards in the PC chassis as possible. This will eliminate some EMI and power supply problems. It's a shot in the dark, but easy enough for you to try.

4. If you do decide to much around in the PC, pull out all the PCI cards, blow the dust out of all the slots, reseat the cards, and retest. I am amazed at how often that actually helps with various problems.

I would point you to an email where I added all sorts of extra controls to the cx18 driver in a patchset, for the express purpose of debugging sync problems:

http://www.gossamer-threads.com/lists/ivtv/users/40227?do=post_view_threaded#40227

and ask you to fiddle around with them.

Unfortunately the patches, which are still here:

http://linuxtv.org/hg/~awalls/v4l-dvb-ctls/

are very old and don't apply cleanly to newer versions of the cx18 driver. :(

My suspicion is either

a. you have a marginal CX23418 chip and something on you card or in your chassis is allowing a DC charge to build up on the CVBS line between the tuner and the CX23418

or

b. a recent kernel change broke the ananlog tuner configuration for the tuner on your board.

It doesn't matter. It looks like MPEG and not raw YUV, BTW.

Centos and other enterprise distros and clone usually run pretty old kernels. You may be running into a bug which was found and fixed years ago.

Have you tried with a modern LiveCD of Fedora or Ubuntu or Knoppix or something? (I don't know which one has HVR-1600 support built into a live CD.)

Regards,
Andy

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here is the output with the S-Video Input in use. If I need to snapshot with the coax input in use that will take a little more time. Status Log:

cx18-0: ================= START STATUS CARD #0 =================
cx18-0: Version: 1.4.0 Card: Hauppauge HVR-1600 tveeprom 4-0050: Hauppauge model 74041, rev C6B2, serial# 5267091 tveeprom 4-0050: MAC address is 00:0d:fe:50:5e:93 tveeprom 4-0050: tuner model is TCL M2523_5N_E (idx 112, type 50) tveeprom 4-0050: TV standards NTSC(M) (eeprom 0x08) tveeprom 4-0050: audio processor is CX23418 (idx 38) tveeprom 4-0050: decoder processor is CX23418 (idx 31) tveeprom 4-0050: has no radio, has IR receiver, has IR transmitter

   cx18-0 843: Video signal:              present
   cx18-0 843: Detected format:           NTSC-M
   cx18-0 843: Specified standard:        NTSC-M
   cx18-0 843: Specified video input:     S-Video (Luma In1, Chroma In5)
   cx18-0 843: Specified audioclock freq: 48000 Hz
   cx18-0 843: Detected audio mode:       mono
   cx18-0 843: Detected audio standard:   BTSC
   cx18-0 843: Audio muted:               no
   cx18-0 843: Audio microcontroller:     stopped
   cx18-0 843: Configured audio standard: automatic detection
   cx18-0 843: Configured audio system:   BTSC
   cx18-0 843: Specified audio input:     External
   cx18-0 843: Preferred audio mode:      stereo
   cx18-0 gpio-reset-ctrl: GPIO:  direction 0x00003001, value 0x00003001
   tuner 5-0061: Tuner mode:      analog TV
   tuner 5-0061: Frequency:       67.25 MHz
   tuner 5-0061: Standard:        0x0000b000
   cs5345 4-004c: Input:  2
   cs5345 4-004c: Volume: 0 dB
   cx18-0: Video Input: S-Video 1
   cx18-0: Audio Input: Line In 1
   cx18-0: GPIO:  direction 0x00003001, value 0x00003001
   cx18-0: Tuner: TV
   cx18-0: Stream: MPEG-2 Program Stream
   cx18-0: VBI Format: Private packet, IVTV format
   cx18-0: Video:  720x480, 30 fps
   cx18-0: Video:  MPEG-2, 4x3, Variable Bitrate, 4400000, Peak 6600000
   cx18-0: Video:  GOP Size 15, 2 B-Frames, GOP Closure
   cx18-0: Audio:  48 kHz, MPEG-1/2 Layer II, 224 kbps, Stereo, No

Emphasis, No CRC
cx18-0: Spatial Filter: Manual, Luma 1D Horizontal, Chroma 1D
Horizontal, 0
cx18-0: Temporal Filter: Manual, 8
cx18-0: Median Filter: Off, Luma [0, 255], Chroma [0, 255]
cx18-0: Status flags: 0x00200001
cx18-0: Stream encoder MPEG: status 0x0000, 0% of 2048 KiB (64
buffers) in use
cx18-0: Stream encoder YUV: status 0x0000, 0% of 2025 KiB (20
buffers) in use
cx18-0: Stream encoder VBI: status 0x0000, 0% of 1015 KiB (20
buffers) in use
cx18-0: Stream encoder PCM audio: status 0x0000, 0% of 1024 KiB
(256 buffers) in use
cx18-0: Read MPEG/VBI: 0/0 bytes
cx18-0: ================== END STATUS CARD #0 ==================

I do not have the ability to revert to a known working state without potentially messing thigns up in a serious way. I know the last known good working state was prior to 2012-08-10. I've tried reverting to kernels that were current at that time and the problem still persist.
It also is worth noting that the "good" video at that time still had
the occaisional artifact along the edges which does not happen using the SVideo portion of the card now.

I just finished a weeks vacation and after the honey-do list had Friday, Saturday and Sunday to play on the video tower. Pulled everything apart and cleaned it all. The pictures I took involved removing and reseating all the cards so this did not help. It will be December before I have time to pull cards and try this as you suggest. Must earn a paycheck.

I can agree that your theories are correct. For now SVideo is working so much better than coax ever did with mythtv that I an hesitant to disturb things until my next vacation week in December.

That sounds like a great idea. I may just try and download a mythbuntu live cd/dvd and boot it. Should have the necessary drivers since even my old Centos Kernels support the HVR-1600 natively {allegely} :)

Thanks to you and Devin for the time to respond. Sorry I don't have more time to dedicate to this at this moment. Suffice to say the video quality from SVideo looks tons better than I've ever seen from coax with this card. So for time being thats going to be the solution.

Thanks again.

Bob Lightfoot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQs4YYAAoJEKqgpLIhfz3XARYH/2WdS+62TeWiIJIcUyQOUyO5 IhBgodbCBSs8KNSBVKzKGXOgbimcwbHmkixMV0lse6d47o2itSBWc+H2UMMnqCTr nuUXrjJ17+0+yeceePXUyk7OqQxGGjr7I0VBxiLB3saTr65n3DxwDu2A6TijBZuM 13WlVRASmTj37VzfZdZDfWgsAOcgV+GpKvqszvjm1JF0XXpiRVfOPO2/AtcDr921 MAiBCXFN7T9yToMWySgLf8+ZL9/SRgI+iUhdxV2KYAhd9kZ0r9nKGs7CPxrEeK8h wSM1FO9i15agNXrp6oAcNJM9IHRlLXV3VtmSd0KfKVBL7wp25XJzFKVCura3hgw= =YwZm
-----END PGP SIGNATURE-----