On Fri, 2010-01-22 at 05:35 -0500, Devin Heitmueller wrote: > On Fri, Jan 22, 2010 at 2:26 AM, Tony Ross <[email protected]> > wrote: > > Hello Andy, it's been 7 weeks since your response, and I've used that time > > to acquire and test an HVR-1600 and PVR-150 in addition to the PVR-500,
All three use the same analog video decoder core (the one used in the CX2584x chips). All three cards have it setup almost identically. > with > > the same "noisy" results from my old analog VHS tapes, both on Linux and > > Microsoft XP. That's not surprising. The CX2584x data sheet makes recommendations on chips settings and both drivers likely follow them. > > It's curious that a USB capture device on the XP machine doesn't display the > > same "noise" in the recorded file as do the Hauppauge cards. A > > low-resolution comparison of the two different captures can be seen at > > http://tony.ross.mystarband.net/videos/ivtv_noise.mpeg (~38 MB). > > > > In the Hauppauge capture, notice the dark random bands immediately upon > > exiting the aircraft, in freefall (behind the dmesg output) and especially > > as my parachute opens (after the dmesg listing) -- apparently the result of > > inertial tape flutter and air entering the camera housing. This kind of > > noise isn't seen however on the television screen or in the USB-captured > > output in the second half of the video, so apparently those two devices > > share some kind of signal conditioning that the Hauppage card doesn't > > perform by default. I have to agree. It really boils down to what the CX2584x can handle and how it is set up. There are some algorithms within the CX2584x that are not tunable, but many are. > Ah, Looking at the video, I've seen this sort of distortion before. A > user reported it a couple of weeks ago on one of my em28xx cards. I > helped him trace it down to a tvp5150 register related to the way > hsync detection is configured. See the thread "em28xx: New device > request and tvp5150 distortion issues when capturing from vcr" over on > linux-media for more info. > > What it boiled down to was the decoder was forced into "tv mode" > instead of "auto mode" or "vcr mode". And because it was in "tv mode" > instead of "auto mode", the chip was not properly handling the sort of > crappy hsync signal you can get with a VCR. > > I would look at the cx25840 docs and see if there is something comparable. For vsync crappiness look at register 0x402 bit 0: FAST_LOCK_MD to turn off the vsync detection filter window. This might get you sync'ed up correctly vertically if the vsync is the problem. You may find register 0x40e bit 6 SPECIAL_PLAY_MODE_N interesting, but it is read only as the chip internal algorithms decide when special play mode (VCR FF, Rewind, etc.) is active on the input. For hsync related problems there are a slew of things to try in registers 0x104, 0x106, and 0x488-0x49a and maybe others. Some of these are manual settings, but many tweak how automatic algorithms are operating on the chip. Since there are so many variables, it is likely one will not readily blindly find the magic combination of register settings to make the problem go away without analysis of the problem video signal. If one has a storage oscilloscope and can capture the lines with the vsyncs and problem hsyncs, then a set of settings may be more easily attainable. Regards, Andy > Devin _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
