Mailing List Archive

On Fri, Nov 20, 2009 at 2:22 PM, Tony Ross <tross.technical@starband.net> wrote:
> The PVR-500 card that I'm using apparently introduces two features that
> don't exist in the original recordings, as evidenced by viewing on a regular
> TV screen the VHS tapes that I'm capturing.
>
> A thick black vertical band is on the entire left side of the video image,
> and a thin band of distortion exists along the entire bottom.
>
> What might be causing these features? Have I got a bad card?

Are you using the correct video standard (PAL/NTSC/SECAM)?

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, 2009-11-20 at 11:22 -0800, Tony Ross wrote:
> The PVR-500 card that I'm using apparently introduces two features that
> don't exist in the original recordings, as evidenced by viewing on a regular
> TV screen the VHS tapes that I'm capturing.

Well, likely the case is your TV is more tolerant of marginal video
signals - see below...


> A thick black vertical band is on the entire left side of the video image,
> and a thin band of distortion exists along the entire bottom.

How many pixels wide is the vertical band? There should be 720 pixels
total across the whole line.

How many lines at the bottom of thre screen are affected? An NTSC
screen will be 480 lines tall when digitized.


> What might be causing these features? Have I got a bad card?

Not likely.

Most likely your VCR is putting out crappy horizontal sync and/or
vertical sync. Tweaking various registers in the CX2584x chip may have
positive results for you- but it's not easy for the general user.

I wanted to added some advanced controls for twiddling the CX2584x
parameters, and at the LPC in Portland we somewhat decided that
v4l2_subdev specific device nodes would be used for "technician" type
controls. I'm waiting for those v4l2_subdev specific device node
changes to go into the v4l-dvb repository before added specialized
"tweaker" controls to the cx25840 module.


Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Devin Heitmueller wrote:

...
>> A thick black vertical band is on the entire left side of the video
>> image, and a thin band of distortion exists along the entire bottom.
>>
>> What might be causing these features? Have I got a bad card?
>
> Are you using the correct video standard (PAL/NTSC/SECAM)?

The "dmesg" output indicates:
...
tveeprom 0-0050: TV standards NTSC(M) (eeprom 0x08)
...

and:

$ v4l2-ctl -S
Video standard = 0x00001000
NTSC-M

$ v4l2-ctl -V
Format:
Type : Video Capture
Width/Height : 720/480
Pixel Format : MPEG
Field : Interlaced
Bytes per Line: 0
Size Image : 131072
Colorspace : Broadcast NTSC/PAL (SMPTE170M/ITU601)



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Andy Walls wrote:

> How many pixels wide is the vertical band? There should be 720 pixels
> total across the whole line.

After more experimentation, I find that the wide, vertical black band on the
left side is a feature of the original VHS tape, which was recorded from a
PBS master 1/2" reel tape. I'm not sure why it doesn't show when the VHS is
displayed on a televion, but perhaps there're more than 720 pixels width?

How would I determine the pixel resolution of the captured mpeg2 image, and
the width of the black band?

> How many lines at the bottom of thre screen are affected? An NTSC
> screen will be 480 lines tall when digitized.

How would I determine how many lines at the bottm are affected, please? The
distortion can be removed by cropping 9 pixels withVLC.

It's curious that when I "snap" a still image using either Xine or VLC, the
resolution is 720x540

>> What might be causing these features? Have I got a bad card?
>
> Not likely.
>
> Most likely your VCR is putting out crappy horizontal sync and/or
> vertical sync. Tweaking various registers in the CX2584x chip may
> have positive results for you- but it's not easy for the general user.
...

I'm not clear on the usage of:
--set-crop-video=top=<x>,left=<y>,width=<w>,height=<h>
set the video capture crop window [VIDIOC_S_CROP]


Would the following crop 11 pixels off the left, and 9 pixels off the
bottom?
--set-crop-video=top=0,left=11,width=709,height=471

and how would I undo that if it's incorrect? "--get-crop-video" returns a
null string. so I assume "--set-crop-video=" would reset it to its current
state?

I'm getting errors when attempting it:
$ v4l2-ctl -d
/dev/video0 --set-crop-video=top=0,left=11,width=709,height=471
ioctl: VIDIOC_S_CROP
ioctl: VIDIOC_G_CROP failed


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

> Date: Mon, 23 Nov 2009 18:53:45 -0800
> From: "Tony Ross" <tross.technical@starband.net>

> After more experimentation, I find that the wide, vertical black band on the
> left side is a feature of the original VHS tape, which was recorded from a
> PBS master 1/2" reel tape. I'm not sure why it doesn't show when the VHS is
> displayed on a televion, but perhaps there're more than 720 pixels width?

Maybe something went wrong with the front porch, causing sync issues?

http://www.kolumbus.fi/pami1/video/pal_ntsc.html or
http://www.ntsc-tv.com/ntsc-main-03.htm may be helpful
(or a search for ``ntsc "front porch"''). Just a guess,
but a tape-to-tape from 1/2" (U-matic, by any chance?)
seems fraught...

(Really, weirdness in any portion of the sync might lead to strange
issues, and I'll bet that a capture card, a VCR, or a TV might display
different symptoms. You may need a timebase corrector, or perhaps
something that claims to de-Macrovision may help by restoring your
sync to something more reasonable. Any chance you can look at the
signal on an oscilloscope?)

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

>> What might be causing these features? Have I got a bad card?
>
> Not likely.
>
> Most likely your VCR is putting out crappy horizontal sync and/or
> vertical sync. Tweaking various registers in the CX2584x chip may have
> positive results for you- but it's not easy for the general user.

Is there any documentation about the various CX2584x registers and the
effect that changing their values might accomplish? Although I'm new to ivtv
and video manipulations in general, I'm willing to try.

I've used 2 different VCR machines from different manufacturers with the
same results, and so am inclined to think the "syncs" are acceptable. I'm
using the PVR-500 to capture VHS tapes for transcription onto DVDs. From the
VCR I have S-Video and audio to the PVR-500, and am using a composite cable
from the VCR to a regular television set. This allows me to compare the
mpeg2 stream with the ordinary tv in real-time, with only a slight delay on
the computer.

The tv doesn't have the "features" that are observed in the mpeg2 that
results from the Hauppauge card. In addition, some sections of the VHS tapes
are entirely visible on the tv while the mpeg2 stream from /dev/video0 is
remarkably distorted in both imagery and color, with wildly oscillating
diagonal black bands making the resultant mpeg2 file most undesirable.

Looking at the tv shows the VHS tapes to be in great shape considering their
age. Looking at the mpeg2 files captured from the card leaves much to be
desired, as the image quality in the mpeg2 files is very badly affected,
sometimes adequate but often distorted in ways that the same tv image
doesn't show.

Here is some information:
$ v4l2-ctl -ISD
Driver info:
Driver name : ivtv
Card type : WinTV PVR 500 (unit #1)
Bus info : PCI:0000:04:08.0
Driver version: 66561
Capabilities : 0x01070051
Video Capture
VBI Capture
Sliced VBI Capture
Tuner
Audio
Radio
Read/Write
Video input : 1 (S-Video 1)
Video standard = 0x00001000
NTSC-M

I'm wondering if there is some "over-sampling" or some such thing in the
mpeg2 output from the card, which introduces noise into the image that isn't
seen in the tv display, e.g. the "stream 0 codec frame rate differs from
container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001)" and the
warnings and errors in the following output:

$cat /dev/video0 > test.mpg # ... <Ctrl-C>
$ ffmpeg -i test.mpg -target ntsc-dvd -y test_new.mpg
...
Seems stream 0 codec frame rate differs from container frame rate: 59.94
(60000/1001) -> 29.97 (30000/1001)
Input #0, mpeg, from 'test.mpg':
Duration: 00:00:14.92, start: 0.189200, bitrate: 6263 kb/s
Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR
4:3], 8000 kb/s, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
Output #0, dvd, to 'test_new.mpg':
Stream #0.0: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR 4:3],
q=2-31, 6000 kb/s, 90k tbn, 29.97 tbc
Stream #0.1: Audio: ac3, 48000 Hz, stereo, s16, 448 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Stream #0.1 -> #0.1
Press [q] to stop encoding
[mpeg2video @ 0x95a17c0]ac-tex damaged at 10 25=14.40 bitrate=6214.5kbits/s
[mpeg2video @ 0x95a17c0]Warning MVs not available
[mpeg2video @ 0x95a17c0]concealing 225 DC, 225 AC, 225 MV errors
frame= 626 fps= 10 q=17.9 Lsize= 16694kB time=14.59 bitrate=9372.1kbits/s
video:15563kB audio:798kB global headers:0kB muxing overhead 2.037058%
----------------------------

I'm really having a serious problem with the mpeg2 output of the Hauppauge
card and would be grateful for any help in solving the issue within a Linux
environment.



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Tue, Dec 1, 2009 at 3:17 PM, Tony Ross <tross.technical@starband.net> wrote:
>>> What might be causing these features? Have I got a bad card?
>>
>> Not likely.
>>
>> Most likely your VCR is putting out crappy horizontal sync and/or
>> vertical sync.  Tweaking various registers in the CX2584x chip may have
>> positive results for you- but it's not easy for the general user.
>
> Is there any documentation about the various CX2584x registers and the
> effect that changing their values might accomplish? Although I'm new to ivtv
> and video manipulations in general, I'm willing to try.

http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf

Cheers,

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

For the sake of comparison, try capturing using Windows and Hauppauge WinTV
software. WinTV is a free download from Hauppauge.
Peter

On Tue, Dec 1, 2009 at 12:25 PM, Devin Heitmueller <
dheitmueller@kernellabs.com> wrote:

> On Tue, Dec 1, 2009 at 3:17 PM, Tony Ross <tross.technical@starband.net>
> wrote:
> >>> What might be causing these features? Have I got a bad card?
> >>
> >> Not likely.
> >>
> >> Most likely your VCR is putting out crappy horizontal sync and/or
> >> vertical sync. Tweaking various registers in the CX2584x chip may have
> >> positive results for you- but it's not easy for the general user.
> >
> > Is there any documentation about the various CX2584x registers and the
> > effect that changing their values might accomplish? Although I'm new to
> ivtv
> > and video manipulations in general, I'm willing to try.
>
> http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf
>
> Cheers,
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>

On Tue, 2009-12-01 at 12:17 -0800, Tony Ross wrote:
> >> What might be causing these features? Have I got a bad card?
> >
> > Not likely.
> >
> > Most likely your VCR is putting out crappy horizontal sync and/or
> > vertical sync. Tweaking various registers in the CX2584x chip may have
> > positive results for you- but it's not easy for the general user.
>
> Is there any documentation about the various CX2584x registers and the
> effect that changing their values might accomplish? Although I'm new to ivtv
> and video manipulations in general, I'm willing to try.

The CX25840/1/2/3 data sheet is on

http://dl.ivtvdriver.org

somewhere. It's not hard to find. If you find a copy of the old
Rockwell-Collins BT878 or BT879 datasheet on the 'Net, it also gives
more insight into how *portions* of the CX2584x chips work. (It's easy
to tell parts of the documentation were copied, and the BT878 sheet was
more instructive on some concepts.)

You'll want to build the latest v4l-dvb drivers:

http://linuxtv.org/hg/v4l-dvb

Grab the tar archive and:

$ tar -xvzf tip.tar.gz
$ cd v4l-dvb-blahblahblah
$ make
$ make apps (it'll bomb; don't worry v4l2-dbg gets made)
$ su root
# (back up /lib/modules/`uname -r` now if you care about them)
# make install
# make unload
# make unload
# modprobe ivtv

That builds the ivtv and cx25840 drivers with advanced debugging turned
on and installs the modules. That allows root to use v4l-dbg to
manipulate registers:

# v4l2-apps/util/v4l2-dbg --help

# v4l2-apps/util/v4l2-dbg -d /dev/video0 -S
host0: cx23416 revision 0x00000000
i2c 0x1b: wm8775 revision 0x00000000
i2c 0x44: cx25843 revision 0x00008433

# v4l2-apps/util/v4l2-dbg -d /dev/video0 -c 0x44 --list-registers=min=0x100,max=0x1ff
ioctl: VIDIOC_DBG_G_REGISTER

00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000100: 33 84 02 76 80 dd 04 07 0f 04 0a 10 fe e2 2b 00
00000110: e5 d6 98 00 00 8c 07 00 02 00 00 00 00 00 00 00
00000120: 00 00 01 10 87 b6 b0 50 f8 93 11 a0 ff 5f 20 11
00000130: 00 00 00 00 02 18 0a 00 00 00 00 00 00 00 36 00
[...]

# v4l2-apps/util/v4l2-dbg -d /dev/video0 -c 0x44 -g 0x100
ioctl: VIDIOC_DBG_G_REGISTER
Register 0x00000100 = 33h (51d 00110011b)


You can use -s to set registers too.

Be careful some registers have "auto-configuration side effects. If you
change them, they change other registers (Fun!).



> I've used 2 different VCR machines from different manufacturers with the
> same results, and so am inclined to think the "syncs" are acceptable. I'm
> using the PVR-500 to capture VHS tapes for transcription onto DVDs. From the
> VCR I have S-Video and audio to the PVR-500, and am using a composite cable
> from the VCR to a regular television set. This allows me to compare the
> mpeg2 stream with the ordinary tv in real-time, with only a slight delay on
> the computer.

Some VCR's don't output all 9 sync pulses at vsync, but a few less.
The CX25843 likely isn't set up for this by default. I do believe there
is a VCR flag in one of the registers.



> The tv doesn't have the "features" that are observed in the mpeg2 that
> results from the Hauppauge card. In addition, some sections of the VHS tapes
> are entirely visible on the tv while the mpeg2 stream from /dev/video0 is
> remarkably distorted in both imagery and color, with wildly oscillating
> diagonal black bands making the resultant mpeg2 file most undesirable.

Hmmm. Herring bone patterns on a video signal are usually from FM
interferers. Color distortion is caused by problems locking on to the
color burst.

You should probably try the +12 dB gain setting on the analog inputs of
the CX25843. You'll have to find the one that corresponds to the
composite in - look in ivtv-cards.c. The +12 dB gain setting may be in
one of those registers that forces the autoconfig, which may make manual
manipulation infeasible. :( (If that is the case, hack the CX25840
driver instead.)



> Looking at the tv shows the VHS tapes to be in great shape considering their
> age.

Your TV is probably doing a lot of signal conditioning.

> Looking at the mpeg2 files captured from the card leaves much to be
> desired, as the image quality in the mpeg2 files is very badly affected,
> sometimes adequate but often distorted in ways that the same tv image
> doesn't show.

The image quality probably belies the actual quality of the signal
recorded on the tape. It's probably good you're trying to move them to
DVD.


> Here is some information:
> $ v4l2-ctl -ISD
> Driver info:
> Driver name : ivtv
> Card type : WinTV PVR 500 (unit #1)
> Bus info : PCI:0000:04:08.0
> Driver version: 66561
> Capabilities : 0x01070051
> Video Capture
> VBI Capture
> Sliced VBI Capture
> Tuner
> Audio
> Radio
> Read/Write
> Video input : 1 (S-Video 1)
> Video standard = 0x00001000
> NTSC-M
>
> I'm wondering if there is some "over-sampling" or some such thing in the
> mpeg2 output from the card, which introduces noise into the image that isn't
> seen in the tv display, e.g. the "stream 0 codec frame rate differs from
> container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001)" and the
> warnings and errors in the following output:
>
> $cat /dev/video0 > test.mpg # ... <Ctrl-C>
> $ ffmpeg -i test.mpg -target ntsc-dvd -y test_new.mpg
> ...
> Seems stream 0 codec frame rate differs from container frame rate: 59.94
> (60000/1001) -> 29.97 (30000/1001)
> Input #0, mpeg, from 'test.mpg':
> Duration: 00:00:14.92, start: 0.189200, bitrate: 6263 kb/s
> Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR
> 4:3], 8000 kb/s, 29.97 tbr, 90k tbn, 59.94 tbc
> Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
> Output #0, dvd, to 'test_new.mpg':
> Stream #0.0: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR 4:3],
> q=2-31, 6000 kb/s, 90k tbn, 29.97 tbc
> Stream #0.1: Audio: ac3, 48000 Hz, stereo, s16, 448 kb/s
> Stream mapping:
> Stream #0.0 -> #0.0
> Stream #0.1 -> #0.1
> Press [q] to stop encoding
> [mpeg2video @ 0x95a17c0]ac-tex damaged at 10 25=14.40 bitrate=6214.5kbits/s
> [mpeg2video @ 0x95a17c0]Warning MVs not available
> [mpeg2video @ 0x95a17c0]concealing 225 DC, 225 AC, 225 MV errors
>
> frame= 626 fps= 10 q=17.9 Lsize= 16694kB time=14.59 bitrate=9372.1kbits/s
> video:15563kB audio:798kB global headers:0kB muxing overhead 2.037058%
> ----------------------------
>
> I'm really having a serious problem with the mpeg2 output of the Hauppauge
> card and would be grateful for any help in solving the issue within a Linux
> environment.

My personal opinion: if the content on the tapes is valuable to you, get
a professional archiving service to make your DVD archives. It may be
the case that the PVR's capture distortions belie that your tapes are in
marginal condition.

BTW, Have you tried this VCR signal with this capture card in a Windows
machine?

Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

I must be the luckiest SOB alive, my Hauppauge PVR-150 works flawlessly I use ivtv-tune utils and v4l2 along with vlc and the pvr option, the darn thing works better than the Hauppauge software and way better than Windows Media Center, no assembly involved.

Thanks,





-Mark




________________________________
From: Peter Hollenbeck <pwhbeck@gmail.com>
To: User discussion about IVTV <ivtv-users@ivtvdriver.org>
Sent: Tue, December 1, 2009 6:14:50 PM
Subject: Re: [ivtv-users] video "features" - how to remove?

For the sake of comparison, try capturing using Windows and Hauppauge WinTV software. WinTV is a free download from Hauppauge.
Peter


On Tue, Dec 1, 2009 at 12:25 PM, Devin Heitmueller <dheitmueller@kernellabs.com> wrote:

On Tue, Dec 1, 2009 at 3:17 PM, Tony Ross <tross.technical@starband.net> wrote:
>>
>>>> What might be causing these features? Have I got a bad card?
>>>>
>>>> Not likely.
>>>>
>>>> Most likely your VCR is putting out crappy horizontal sync and/or
>>>> vertical sync. Tweaking various registers in the CX2584x chip may have
>>>> positive results for you- but it's not easy for the general user.
>>>
>>> Is there any documentation about the various CX2584x registers and the
>>> effect that changing their values might accomplish? Although I'm new to ivtv
>>> and video manipulations in general, I'm willing to try.
>
>http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf
>
>>Cheers,
>
>
>>Devin
>
>>--
>>Devin J. Heitmueller - Kernel Labs
>http://www.kernellabs.com
>
>>_______________________________________________
>
>ivtv-users mailing list
>ivtv-users@ivtvdriver.org
>http://ivtvdriver.org/mailman/listinfo/ivtv-users
>

On Wed, 2009-12-02 at 05:42 -0800, Mark Kaufman wrote:
> I must be the luckiest SOB alive, my Hauppauge PVR-150 works
> flawlessly I use ivtv-tune utils and v4l2 along with vlc and the pvr
> option, the darn thing works better than the Hauppauge software and
> way better than Windows Media Center, no assembly involved.

May I ask what kernel and ivtv version you're using, please? I'm feeling
a bit constrained by CentOS 5.4 and its most recent builds:

$ uname -r; rpm -qa | grep ivtv | sort
2.6.18-164.6.1.el5
dkms-ivtv-0.10.6-1.nodist.rf
ivtv-0.10.6-132.el5
ivtv-devel-0.10.6-132.el5
ivtv-firmware-20080701-18
ivtv-kmdl-2.6.18-164.6.1.el5xen-0.10.6-132.el5
perl-Video-ivtv-0.13-8.0.el5
xf86-video-ivtv-1.0.2-12.el5




_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

2009. 12. 2, szerda keltezéssel 05.42-kor Mark Kaufman ezt írta:
> I must be the luckiest SOB alive, my Hauppauge PVR-150 works
> flawlessly I use ivtv-tune utils and v4l2 along with vlc and the pvr
> option, the darn thing works better than the Hauppauge software and
> way better than Windows Media Center, no assembly involved.

Mine also works well (cat/mplayer/vlc/MythTV/etc.).

Levente




_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

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, with
the same "noisy" results from my old analog VHS tapes, both on Linux and
Microsoft XP.

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.

The "features" around the edges can be dealt with, I've found, by cropping
the images. Of course v4l2-ctl can do that, but it suits my needs better to
use ffmpeg when producing the finished result after all editing is finished,
as the video comes from several different sources.

I'll start to investigate the register settings to see if that may help.

Again, thanks for your excellent work.

----- Original Message -----
From: "Andy Walls" <awalls@radix.net>

> On Tue, 2009-12-01 at 12:17 -0800, Tony Ross wrote:
>>>> What might be causing these features? Have I got a bad card?
>>>
>>> Not likely.
>>>
>>> Most likely your VCR is putting out crappy horizontal sync and/or
>>> vertical sync. Tweaking various registers in the CX2584x chip may have
>>> positive results for you- but it's not easy for the general user.
...
>> I've used 2 different VCR machines from different manufacturers with the
>> same results, and so am inclined to think the "syncs" are acceptable. I'm
>> using the PVR-500 to capture VHS tapes for transcription onto DVDs. From
the
>> VCR I have S-Video and audio to the PVR-500, and am using a composite
cable
>> from the VCR to a regular television set. This allows me to compare the
>> mpeg2 stream with the ordinary tv in real-time, with only a slight delay
on
>> the computer.
>
> Some VCR's don't output all 9 sync pulses at vsync, but a few less.
> The CX25843 likely isn't set up for this by default. I do believe there
> is a VCR flag in one of the registers.

Thanks Andy, I'll start investigating the register settings to see if they
have any affect on the output.

> > The tv doesn't have the "features" that are observed in the mpeg2 that
> > results from the Hauppauge card. In addition, some sections of the VHS
tapes
> > are entirely visible on the tv while the mpeg2 stream from /dev/video0
is
> > remarkably distorted in both imagery and color, with wildly oscillating
> > diagonal black bands making the resultant mpeg2 file most undesirable.
>
> Hmmm. Herring bone patterns on a video signal are usually from FM
> interferers. Color distortion is caused by problems locking on to the
> color burst.
>
> You should probably try the +12 dB gain setting on the analog inputs of
> the CX25843. You'll have to find the one that corresponds to the
> composite in - look in ivtv-cards.c. The +12 dB gain setting may be in
> one of those registers that forces the autoconfig, which may make manual
> manipulation infeasible. :( (If that is the case, hack the CX25840
> driver instead.)
>
>
>
> > Looking at the tv shows the VHS tapes to be in great shape considering
their
> > age.
>
> Your TV is probably doing a lot of signal conditioning.
>
> > Looking at the mpeg2 files captured from the card leaves much to be
> > desired, as the image quality in the mpeg2 files is very badly affected,
> > sometimes adequate but often distorted in ways that the same tv image
> > doesn't show.
>
> The image quality probably belies the actual quality of the signal
> recorded on the tape. It's probably good you're trying to move them to
> DVD.
>
>
> > Here is some information:
> > $ v4l2-ctl -ISD
> > Driver info:
> > Driver name : ivtv
> > Card type : WinTV PVR 500 (unit #1)
> > Bus info : PCI:0000:04:08.0
> > Driver version: 66561
> > Capabilities : 0x01070051
> > Video Capture
> > VBI Capture
> > Sliced VBI Capture
> > Tuner
> > Audio
> > Radio
> > Read/Write
> > Video input : 1 (S-Video 1)
> > Video standard = 0x00001000
> > NTSC-M
> >
> > I'm wondering if there is some "over-sampling" or some such thing in the
> > mpeg2 output from the card, which introduces noise into the image that
isn't
> > seen in the tv display, e.g. the "stream 0 codec frame rate differs from
> > container frame rate: 59.94 (60000/1001) -> 29.97 (30000/1001)" and the
> > warnings and errors in the following output:
> >
> > $cat /dev/video0 > test.mpg # ... <Ctrl-C>
> > $ ffmpeg -i test.mpg -target ntsc-dvd -y test_new.mpg
> > ...
> > Seems stream 0 codec frame rate differs from container frame rate: 59.94
> > (60000/1001) -> 29.97 (30000/1001)
> > Input #0, mpeg, from 'test.mpg':
> > Duration: 00:00:14.92, start: 0.189200, bitrate: 6263 kb/s
> > Stream #0.0[0x1e0]: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR
> > 4:3], 8000 kb/s, 29.97 tbr, 90k tbn, 59.94 tbc
> > Stream #0.1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
> > Output #0, dvd, to 'test_new.mpg':
> > Stream #0.0: Video: mpeg2video, yuv420p, 720x480 [PAR 8:9 DAR 4:3],
> > q=2-31, 6000 kb/s, 90k tbn, 29.97 tbc
> > Stream #0.1: Audio: ac3, 48000 Hz, stereo, s16, 448 kb/s
> > Stream mapping:
> > Stream #0.0 -> #0.0
> > Stream #0.1 -> #0.1
> > Press [q] to stop encoding
> > [mpeg2video @ 0x95a17c0]ac-tex damaged at 10 25=14.40
bitrate=6214.5kbits/s
> > [mpeg2video @ 0x95a17c0]Warning MVs not available
> > [mpeg2video @ 0x95a17c0]concealing 225 DC, 225 AC, 225 MV errors
> >
> > frame= 626 fps= 10 q=17.9 Lsize= 16694kB time=14.59
bitrate=9372.1kbits/s
> > video:15563kB audio:798kB global headers:0kB muxing overhead 2.037058%
> > ----------------------------
> >
> > I'm really having a serious problem with the mpeg2 output of the
Hauppauge
> > card and would be grateful for any help in solving the issue within a
Linux
> > environment.
>
> My personal opinion: if the content on the tapes is valuable to you, get
> a professional archiving service to make your DVD archives. It may be
> the case that the PVR's capture distortions belie that your tapes are in
> marginal condition.
>
> BTW, Have you tried this VCR signal with this capture card in a Windows
> machine?
>
> Regards,
> Andy
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, Jan 22, 2010 at 2:26 AM, Tony Ross <tross.technical@starband.net> 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, with
> the same "noisy" results from my old analog VHS tapes, both on Linux and
> Microsoft XP.
>
> 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.

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.

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, 2010-01-22 at 05:35 -0500, Devin Heitmueller wrote:
> On Fri, Jan 22, 2010 at 2:26 AM, Tony Ross <tross.technical@starband.net> 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
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, Jan 22, 2010 at 12:20 PM, Andy Walls <awalls@radix.net> wrote:
> 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.

Or Tony can just mail you a copy of the VHS tape. :-)

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, 2010-01-22 at 12:50 -0500, Devin Heitmueller wrote:
> On Fri, Jan 22, 2010 at 12:20 PM, Andy Walls <awalls@radix.net> wrote:
> > 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.
>
> Or Tony can just mail you a copy of the VHS tape. :-)

:)

1. No guarantees that my VCR won't somehow correct the signal.

2. It's been a long time (too long) since I worked anywhere with an
oscilliscope available to me. :( So I would be fumbling in the dark as
well.

(Coincidentially, I just happen to be updating my resume right now. It
looks like about 1998 when I last used an oscilliscope at work.)

Regards,
Andy

> Devin



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, 2010-01-22 at 12:50 -0500, Devin Heitmueller wrote:
> On Fri, Jan 22, 2010 at 12:20 PM, Andy Walls <awalls@radix.net> wrote:
> > 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.
>
> Or Tony can just mail you a copy of the VHS tape. :-)

:)

1. No guarantees that my VCR won't somehow correct the signal.

2. It's been a long time (too long) since I worked anywhere with an
oscilliscope available to me. :( So I would be fumbling in the dark as
well.

(Coincidentially, I just happen to be updating my resume right now. It
looks like about 1998 when I last used an oscilliscope at work.)

Regards,
Andy

> Devin



_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, Jan 22, 2010 at 1:36 PM, Andy Walls <awalls@radix.net> wrote:
> 1. No guarantees that my VCR won't somehow correct the signal.

True, but it's definitely a cheap solution to test and if it allows
you to reproduce the issue then it eliminates the need for anything
more complicated.

> 2. It's been a long time (too long) since I worked anywhere with an
> oscilliscope available to me. :(  So I would be fumbling in the dark as
> well.

Are you suggesting you are going to go out and buy a storage
oscilloscope? Because unless you have the ability to play back the
captured data I'm not sure what good it's going to do you.

> (Coincidentially, I just happen to be updating my resume right now.  It
> looks like about 1998 when I last used an oscilliscope at work.)

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

Andy Walls quoted and wrote:

...
>> 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.

May I ask please how one "looks" at, or sets the register settings? I see
that "v4l2-ctl --set-ctrl=<ctrl>=<val>[,<ctrl>=<val>...]" allows one to
alter the value of various controls returned by the "-l" (ell) option, but I
don't see any obvious way to list or set the values of the various registers
on the chip.

Of course I'd like to be able to somehow return to the current settings if
something gets mucked up. <g>


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, 2010-01-22 at 14:00 -0500, Devin Heitmueller wrote:
> On Fri, Jan 22, 2010 at 1:36 PM, Andy Walls <awalls@radix.net> wrote:
> > 1. No guarantees that my VCR won't somehow correct the signal.
>
> True, but it's definitely a cheap solution to test and if it allows
> you to reproduce the issue then it eliminates the need for anything
> more complicated.
>
> > 2. It's been a long time (too long) since I worked anywhere with an
> > oscilliscope available to me. :( So I would be fumbling in the dark as
> > well.
>
> Are you suggesting you are going to go out and buy a storage
> oscilloscope? Because unless you have the ability to play back the
> captured data I'm not sure what good it's going to do you.

No. I'm implying that without being able to visualize the signal defect
(due to no storage o-scope), I have a low probably of finding the right
settings even with VHS tape in hand.

IMO, of course.

Regards,
Andy


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

On Fri, Jan 22, 2010 at 5:20 PM, Andy Walls <awalls@radix.net> wrote:
> No. I'm implying that without being able to visualize the signal defect
> (due to no storage o-scope), I have a low probably of finding the right
> settings even with VHS tape in hand.

Has Tony tried the that tape with the Hauppauge card under Windows? I
believe he was comparing the Hauppauge card under Linux to a USB
capture card under Windows. It would be good to know if the Hauppauge
card works properly under Windows (and if it does, we have some ways
of finding out how the registers got programmed there).

Devin

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

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

I wrote:

...
> May I ask please how one "looks" at, or sets the register settings?

I beg your pardon please; I re-read the thread and see that I need
"v4l2-dbg" which isn't in my installed rpm, so I'll find some source code
and compile it.


_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users

I wrote:
...
> May I ask please how one "looks" at, or sets the register settings?

In order to get the "v4l2-dbg" functionality, new troubles exist when
installing the most recent drivers after a "make apps" etc. as outlined in
http://ivtvdriver.org/pipermail/ivtv-users/2009-December/009710.html :

...
[root@centos54 v4l-dvb-e4429a1b736c]# make install
make -C /home/me/src/v4l-dvb-e4429a1b736c/v4l install
make[1]: Entering directory `/home/me/src/v4l-dvb-e4429a1b736c/v4l'

Removing obsolete files from
/lib/modules/2.6.18-164.9.1.el5/kernel/drivers/media/video:
Removing obsolete files from
/lib/modules/2.6.18-164.9.1.el5/kernel/drivers/media/dvb/cinergyT2:
Removing obsolete files from
/lib/modules/2.6.18-164.9.1.el5/kernel/drivers/media/common:
Removing obsolete files from
/lib/modules/2.6.18-164.9.1.el5/kernel/drivers/media/dvb/frontends:

Installing kernel modules under
/lib/modules/2.6.18-164.9.1.el5/kernel/drivers/media/:
video/gspca/m5602/: gspca_m5602.ko
dvb/dvb-usb/: dvb-usb-dtv5100.ko dvb-usb-opera.ko dvb-usb-cxusb.ko
dvb-usb-vp7045.ko dvb-usb-af9005-remote.ko dvb-usb-ttusb2.ko
dvb-usb-af9015.ko dvb-usb-dib0700.ko dvb-usb-a800.ko
dvb-usb-gp8psk.ko dvb-usb-dibusb-common.ko dvb-usb-au6610.ko
dvb-usb-digitv.ko dvb-usb.ko dvb-usb-dibusb-mc.ko
dvb-usb-af9005.ko dvb-usb-nova-t-usb2.ko dvb-usb-friio.ko
dvb-usb-ce6230.ko dvb-usb-dtt200u.ko dvb-usb-cinergyT2.ko
dvb-usb-vp702x.ko dvb-usb-umt-010.ko dvb-usb-anysee.ko
dvb-usb-dibusb-mb.ko dvb-usb-dw2102.ko dvb-usb-gl861.ko
dvb-usb-ec168.ko dvb-usb-m920x.ko
video/zoran/: videocodec.ko zr36050.ko zr36016.ko
zr36060.ko zr36067.ko
video/cx18/: cx18.ko
video/cpia2/: cpia2.ko
dvb/b2c2/: b2c2-flexcop-pci.ko b2c2-flexcop.ko b2c2-flexcop-usb.ko
video/ivtv/: ivtvfb.ko ivtv.ko
common/tuners/: tuner-xc2028.ko mt2060.ko tda9887.ko
mt2131.ko mc44s803.ko qt1010.ko
max2165.ko mt20xx.ko tda827x.ko
tda18271.ko xc5000.ko mxl5007t.ko
tea5761.ko tuner-types.ko tda8290.ko
tuner-simple.ko mt2266.ko tea5767.ko
mxl5005s.ko
dvb/dvb-core/: dvb-core.ko
video/: vpx3220.ko videobuf-dma-sg.ko bt856.ko
upd64083.ko stradis.ko videobuf-core.ko
tda9840.ko saa7191.ko cx2341x.ko
wm8775.ko w9968cf.ko saa7185.ko
tuner.ko ks0127.ko videobuf-dvb.ko
tvaudio.ko tea6420.ko bt866.ko
mt9v011.ko saa5246a.ko msp3400.ko
wm8739.ko saa5249.ko tda7432.ko
w9966.ko ir-kbd-i2c.ko upd64031a.ko
tea6415c.ko dabusb.ko bt819.ko
videodev.ko mxb.ko tda9875.ko
adv7175.ko vivi.ko cs53l32a.ko
btcx-risc.ko se401.ko saa7110.ko
saa7115.ko saa6588.ko v4l2-common.ko
hexium_gemini.ko hexium_orion.ko tvp5150.ko
vp27smpx.ko adv7170.ko ov7670.ko
saa7127.ko m52790.ko v4l1-compat.ko
videobuf-vmalloc.ko v4l2-int-device.ko c-qcam.ko
tveeprom.ko cs5345.ko saa717x.ko
tlv320aic23b.ko bw-qcam.ko
video/cx23885/: cx23885.ko
dvb/bt8xx/: dst_ca.ko dvb-bt8xx.ko bt878.ko
dst.ko
dvb/siano/: smsdvb.ko smsusb.ko smsmdtv.ko
video/cx25840/: cx25840.ko
dvb/ttusb-dec/: ttusbdecfe.ko ttusb_dec.ko
video/saa7134/: saa6752hs.ko saa7134-empress.ko saa7134-alsa.ko
saa7134-dvb.ko saa7134.ko
dvb/ttpci/: ttpci-eeprom.ko budget-av.ko budget.ko
budget-core.ko budget-ci.ko
video/gspca/gl860/: gspca_gl860.ko
IR/: ir-core.ko ir-common.ko
dvb/frontends/: nxt6000.ko dib7000m.ko dib0090.ko
s5h1411.ko tda665x.ko dib8000.ko
nxt200x.ko s921.ko s5h1409.ko
atbm8830.ko dib3000mb.ko ec100.ko
lgs8gl5.ko dib3000mc.ko stv0900.ko
sp8870.ko tda8083.ko stv0297.ko
tda10086.ko zl10353.ko mb86a16.ko
lgs8gxx.ko stv0299.ko dvb-pll.ko
cx22702.ko lgdt3304.ko tda8261.ko
tua6100.ko bcm3510.ko stb0899.ko
or51211.ko cx24113.ko tda826x.ko
af9013.ko au8522.ko si21xx.ko
s5h1420.ko stv090x.ko stv0288.ko
mt352.ko zl10039.ko isl6405.ko
sp887x.ko dibx000_common.ko isl6421.ko
mt312.ko or51132.ko tda1004x.ko
stv6110.ko itd1000.ko stv6110x.ko
zl10036.ko lgdt3305.ko dib7000p.ko
l64781.ko ves1x93.ko stb6100.ko
ves1820.ko dib0070.ko cx22700.ko
cx24110.ko dvb_dummy_fe.ko lgdt330x.ko
cx24123.ko lnbp21.ko stb6000.ko
isl6423.ko tda10023.ko cx24116.ko
tda10021.ko tda10048.ko ds3000.ko
video/bt8xx/: bttv.ko
video/gspca/: gspca_stk014.ko gspca_spca501.ko gspca_spca500.ko
gspca_mars.ko gspca_stv0680.ko gspca_sunplus.ko
gspca_vc032x.ko gspca_benq.ko gspca_spca505.ko
gspca_sn9c20x.ko gspca_zc3xx.ko gspca_sonixb.ko
gspca_etoms.ko gspca_pac7302.ko gspca_pac207.ko
gspca_ov534_9.ko gspca_spca508.ko gspca_sn9c2028.ko
gspca_t613.ko gspca_spca561.ko gspca_ov534.ko
gspca_tv8532.ko gspca_spca506.ko gspca_sonixj.ko
gspca_main.ko gspca_cpia1.ko gspca_conex.ko
gspca_mr97310a.ko gspca_pac7311.ko gspca_ov519.ko
dvb/pluto2/: pluto2.ko
video/usbvideo/: ibmcam.ko usbvideo.ko vicam.ko
ultracam.ko konicawc.ko quickcam_messenger.ko
common/: saa7146_vv.ko saa7146.ko
video/gspca/stv06xx/: gspca_stv06xx.ko
video/em28xx/: em28xx-dvb.ko em28xx-alsa.ko em28xx.ko
radio/: radio-maestro.ko radio-maxiradio.ko radio-gemtek-pci.ko
video/uvc/: uvcvideo.ko
dvb/ttusb-budget/: dvb-ttusb-budget.ko
video/ovcamchip/: ovcamchip.ko
video/zc0301/: zc0301.ko
video/au0828/: au0828.ko
/sbin/depmod -a 2.6.18-164.9.1.el5
make -C firmware install
make[2]: Entering directory `/home/me/src/v4l-dvb-e4429a1b736c/v4l/firmware'
Installing firmwares at /lib/firmware: vicam/firmware.fw dabusb/firmware.fw
dabusb/bitstream.bin ttusb-budget/dspbootcode.bin cpia2/stv0672_vp4.bin
av7110/bootcode.bin
make[2]: Leaving directory `/home/me/src/v4l-dvb-e4429a1b736c/v4l/firmware'
make[1]: Leaving directory `/home/me/src/v4l-dvb-e4429a1b736c/v4l'

[root@centos54 v4l-dvb-e4429a1b736c]# make unload
make -C /home/me/src/v4l-dvb-e4429a1b736c/v4l unload
make[1]: Entering directory `/home/me/src/v4l-dvb-e4429a1b736c/v4l'
scripts/rmmod.pl unload
found 271 modules
/sbin/rmmod cx2341x
/sbin/rmmod v4l2_common
/sbin/rmmod videodev
/sbin/rmmod v4l1_compat
/sbin/rmmod tveeprom
make[1]: Leaving directory `/home/me/src/v4l-dvb-e4429a1b736c/v4l'
[root@centos54 v4l-dvb-e4429a1b736c]# make unload
make -C /home/me/src/v4l-dvb-e4429a1b736c/v4l unload
make[1]: Entering directory `/home/me/src/v4l-dvb-e4429a1b736c/v4l'
scripts/rmmod.pl unload
found 271 modules
make[1]: Leaving directory `/home/me/src/v4l-dvb-e4429a1b736c/v4l'
[root@centos54 v4l-dvb-e4429a1b736c]# modprobe ivtv
FATAL: Error inserting ivtv (/lib/modules/2.6.18-164.9.1.el5/extra/ivtv.ko):
Unknown symbol in module, or unknown parameter (see dmesg)

[root@centos54 v4l-dvb-e4429a1b736c]# dmesg
...
ivtv: disagrees about version of symbol cx2341x_ext_ctrls
ivtv: Unknown symbol cx2341x_ext_ctrls
ivtv: disagrees about version of symbol v4l_compat_translate_ioctl
ivtv: Unknown symbol v4l_compat_translate_ioctl
ivtv: disagrees about version of symbol cx2341x_ctrl_query
ivtv: Unknown symbol cx2341x_ctrl_query
ivtv: disagrees about version of symbol tveeprom_read
ivtv: Unknown symbol tveeprom_read
ivtv: disagrees about version of symbol v4l2_ctrl_query_menu
ivtv: Unknown symbol v4l2_ctrl_query_menu
ivtv: disagrees about version of symbol video_unregister_device
ivtv: Unknown symbol video_unregister_device
ivtv: disagrees about version of symbol cx2341x_update
ivtv: Unknown symbol cx2341x_update
ivtv: disagrees about version of symbol video_device_alloc
ivtv: Unknown symbol video_device_alloc
ivtv: disagrees about version of symbol video_register_device
ivtv: Unknown symbol video_register_device
ivtv: disagrees about version of symbol cx2341x_ctrl_get_menu
ivtv: Unknown symbol cx2341x_ctrl_get_menu
ivtv: disagrees about version of symbol cx2341x_log_status
ivtv: Unknown symbol cx2341x_log_status
ivtv: disagrees about version of symbol cx2341x_fill_defaults
ivtv: Unknown symbol cx2341x_fill_defaults
ivtv: disagrees about version of symbol video_usercopy
ivtv: Unknown symbol video_usercopy
ivtv: disagrees about version of symbol tveeprom_hauppauge_analog
ivtv: Unknown symbol tveeprom_hauppauge_analog
ivtv: disagrees about version of symbol video_device_release
ivtv: Unknown symbol video_device_release





_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users