Poor HVR 1600 Video Quality - Feedback for Andy Walls 2012-11-26
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/25/2012 07:54 PM, Andy Walls wrote: 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. 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 0x3001, value 0x3001 tuner 5-0061: Tuner mode: analog TV tuner 5-0061: Frequency: 67.25 MHz tuner 5-0061: Standard:0xb000 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 0x3001, value 0x3001 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, 440, Peak 660 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: 0x0021 cx18-0: Stream encoder MPEG: status 0x, 0% of 2048 KiB (64 buffers) in use cx18-0: Stream encoder YUV: status 0x, 0% of 2025 KiB (20 buffers) in use cx18-0: Stream encoder VBI: status 0x, 0% of 1015 KiB (20 buffers) in use cx18-0: Stream encoder PCM audio: status 0x, 0% of 1024 KiB (256 buffers) in use cx18-0: Read MPEG/VBI: 0/0 bytes cx18-0: == END STATUS CARD #0 == 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. 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. 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. 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. 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
Re: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24
On Sat, 2012-11-24 at 23:08 -0500, Bob Lightfoot wrote:
Devin :
Let me see if I can answer some of your questions.
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
Alright, this is one of the older card models. They have been working
for quite a long while.
E. The v4l2-ctl and cat /dev/video2 file made from Svideo1
https://docs.google.com/open?id=0B95B_9punKEmUGdJNTI3ZnR2T1k
Looks good.
F. The v4l2-ctl and cat /dev/video2 file made from Tuner1
https://docs.google.com/open?id=0B95B_9punKEmOUhLWjNyRG02NDA
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.
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.
It doesn't matter. It looks like MPEG and not raw YUV, BTW.
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
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 :
Linux mythbox.ladodomain 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov
6 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
lspci -vvv :
01:00.0 Multimedia video controller: Conexant Systems, Inc. CX23418
Single-Chip MPEG-2 Encoder with Integrated Analog Video/Broadcast
Audio Decoder Subsystem: Hauppauge computer works Inc. WinTV
HVR-1600 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+
VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+
66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort-
MAbort- SERR- PERR- INTx- Latency: 64 (500ns min, 5ns max),
Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 17 Region
0: Memory at f400 (32-bit, non-prefetchable) [size=64M]
Capabilities: [44] Vital Product Data Not readable Capabilities:
[4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2-
AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0
NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use:
cx18 Kernel modules: cx18
lsmod | grep cx18 :
cx18_alsa 7420 1 cx18 125338 59
cx18_alsa i2c_algo_bit5762 1 cx18 cx2341x 19763 2
cx18,cx23885 v4l2_common10670 6
cs5345,cx18,tuner,cx25840,cx23885,cx2341x videodev 76310 7
cs5345,cx18,tuner,cx25840,cx23885,cx2341x,v4l2_common dvb_core
104074 3 cx18,cx23885,videobuf_dvb tveeprom 14044 2 cx18,cx23885
snd_pcm85828 3
cx18_alsa,snd_hda_intel,snd_hda_codec snd71339
15
cx18_alsa,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
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-
--
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
Re: Poor HVR 1600 Video Quality
On Sat, Nov 24, 2012 at 12:31 PM, Bob Lightfoot boblf...@gmail.com wrote:
-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.
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
--
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
Re: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24
-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
01:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog
Video/Broadcast Audio Decoder [14f1:5b7a] Subsystem: Hauppauge
computer works Inc. WinTV HVR-1600 [0070:7444] Control: I/O- Mem+
BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR-
FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx-
Latency: 64 (500ns min, 5ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 17 Region 0: Memory at f400
(32-bit, non-prefetchable) [size=64M] Capabilities: [44] Vital
Product Data Not readable Capabilities: [4c] Power Management
version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable-
DSel=0 DScale=0 PME- Kernel driver in use: cx18 Kernel modules:
cx18
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-
--
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
Re: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24
On Sat, Nov 24, 2012 at 11:08 PM, Bob Lightfoot boblf...@gmail.com wrote:
-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
01:00.0 Multimedia video controller [0400]: Conexant Systems, Inc.
CX23418 Single-Chip MPEG-2 Encoder with Integrated Analog
Video/Broadcast Audio Decoder [14f1:5b7a] Subsystem: Hauppauge
computer works Inc. WinTV HVR-1600 [0070:7444] Control: I/O- Mem+
BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR-
FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr-
DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx-
Latency: 64 (500ns min, 5ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 17 Region 0: Memory at f400
(32-bit, non-prefetchable) [size=64M] Capabilities: [44] Vital
Product Data Not readable Capabilities: [4c] Power Management
version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable-
DSel=0 DScale=0 PME- Kernel driver in use: cx18 Kernel modules:
cx18
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.
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
--
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
Re: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24
On Sat, Nov 24, 2012 at 11:08 PM, Bob Lightfoot boblf...@gmail.com wrote: Hope you can shed an idea or three. My end goal it to again record analog video in MythTV. 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 -- 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
