IVTV project Frequently Asked Questions (FAQ)

Last updated June 27th, 2003

As always, be sure to read the documentation and README's included with the driver source. They may contain more up-to-date information than this faq.

CONTENTS

What is IVTV all about ?

 The primary goal of the IVTV project is to provide a "clean room" Linux Open Source driver implementation for video capture cards based on the iCompression iTVC15 or Conexant CX23415/CX23416 MPEG Codec. Examples of such cards are the Hauppauge PVR 250/350 series of MPEG video capture cards, the Hauppauge "freestyle" and the AVerMedia M179 AVerTV. The M179 uses a Sony SBX1637 audio module which is not supported by the current driver so while you can capture video, you get no audio yet. The freestyle hasn't been tested, but it should work, or at least be easy to get working.

Where is the project home page and where does everybody hang out ?

 The project home page is at http://ivtv.sourceforge.net where you can read the latest news about the project status and follow the links to download development source code from the CVS. You are welcome to SUBSCRIBE to the mailing list and be kept up to date with the latest developments or even contribute to the discussion.

You might also want to pop into the IRC channel #ivtv-dev on irc.freenode.net

For a searchable mailing list archive (please check before emailing the list! your problem has probably already been solved :) head on over to http://www.poptix.net/ivtv/

What are the differences between the iTVC15 and CX23416 chips ?

 Historically speaking, the iTVC15 was originally developed by iCompression, a subsidiary of Globespan Virata however it was quickly acquired by Conexant which some of you industry veterans will remember used to be Rockwell International. Conexant re-released the iTVC15 under the designation CX23415 and at the same time released a cheaper, encode only, version of the chip under the designation CX23416

How do I tell which revision/type card I have ?

 PVR350 - This card has hardware encoding and decoding capabilities. It is based on the iTVC15 / CX23415 chip and has a TV output. There is a heatsink on the cx23415 chip and there are two DRAM chips on the board.
PVR250 rev1 - This card is similar to the PVR350 but it is missing the video decoder chip that drives the TV output. Despite this, it is still based on the same encoder / decoder chip as the PVR350 and has hardware decoding capabilities.
PVR250 rev2 - Unlike the previous cards, this one has no hardware decoding ability and therefore no TV output. This card uses a CX23416 chip which is a cut down encode only version, has no heatsink and there is only one DRAM chip on board.

What are some of the typical components found on the cards?

Are data sheets for the components available ?

 Most of the components on the card have freely available data sheets which can be obtained on the Internet. The only exception is the iTVC codec which Conexant has chosen not to release except through an NDA and the purchase of a $10000 development kit.

Problems with the driver ?

 Please remember that the driver is still in the early stages of the development. As such, problems are inevitable and are constantly being worked on.

The current version does compile and captures a stream to a file but compilation or capture is not guaranteed under all Linux flavors or environments.

The best place to report trouble and get help is our mailing list. Why not sign up?

What environment does the driver compile and work under?

 At this stage you need Linux kernel 2.4.20 or higher. You must have the kernel sources installed and a proper development environment with a recent copy of gcc.

The kernel must have V4L support. Most distributions include this in the default kernel, so no re-compiling is necessary. If you have compilied your own kernel, you may need to recompile and add in v4l.

V4L2 headers are required for ivyTV to compile. You can either patch your kernel with v4l2 headers or copy the included videodev2.h from the utils/ directory to the driver/ directory.

If you wish to compile V4L2 into your kernel, patches are available from http://bytesex.org/patches.

From personal experience, especially if you don't want to recompile the kernel with v4l support, a good platform for both testing and development is Red Hat 9.0 (kernel 2.4.20-9, gcc 3.2.2 and kernel sources installed).

What APIs or common interfaces are supported?

 Curently the card registers with video for linux (API version 2), and i2c.

Video for Linux (v4l2)

Video for linux provides a standard interface for most common configuration tasks, (eg. tuning, switching inputs, setting resolution, etc) but since there are no other hardware mpeg2 encoders supported under linux, some of the controls are custom. We'll do our best to conform to current conventions, and where necessary, propose additions to v4l2. The utils/ directory in the source will have tools for setting card options using v4l2.

I2C bus

The I2C bus is also registered, enabling the user to connect and control devices directly, however in most cases this is not advisable.

What about the IR remote? FM tuner?

Most versions of the Hauppauge cards come with remotes. They are supported under ivtv, but you'll need to checkout the latest LIRC sources from their CVS repository to get it working. It is worthwhile to note that hauppauge cards only respond to IR codes from rc-5 protocol remotes (philips/marantz/others?)

There have been no reports of the FM tuner working or not. Let us know if you have information.

How do I compile the driver ?

 The following instructions were suggested by Nick Poolos for Red Hat 9.0 users. If you have a different distro (Debian, Gentoo, etc) and you get the driver to compile you are welcome to email to the list your step-by-step for inclusion into this FAQ

Driver compilation problems ?

 There may be any number of reasons why the driver or tools may fail to compile for you. Below are some suggestions and things to look for.

I compiled the driver, now what ?

 The result of the compilation is a number of LKMs (Loadable Kernel Modules) which must be loaded in a certain order.
Compile the driver with make and install it with make install

IvyTV also relies on several other modules to function. Here's a list: If you want to manually load each module, the recommended procedure is as follows:
[root@host]# modprobe i2c-core
[root@host]# modprobe i2c-algo-bit
[root@host]# modprobe tuner type=2
[root@host]# modprobe msp3400
[root@host]# modprobe videodev
[root@host]# insmod saa7115.o
[root@host]# insmod ivtv.o
Alternatively, if you want things to just happen automagically, edit /etc/modules.conf and add the following lines:
alias char-major-81 videodev
alias char-major-81-0 ivtv
options ivtv debug=1
options tuner type=2
options msp3400 once=1 simple=1
add below ivtv msp3400 saa7115 tuner
With the above changes to modules.conf, all the required modules will be automatically loaded when accessing /dev/video0 or when doing a modprobe ivtv. Thanks to Jake Page for suggesting the above changes to modules.conf

Next go into the .../utils directory and type make to create the test_ioctl utility. Before you can capture you must set the video resolution and possibly the video standard and video input. Pick and choose from the following commands as appropriate or change the values to suit:

Set PAL video standard
[root@host]# ./test_ioctl -u 0xff
Set NTSC video standard
[root@host]# ./test_ioctl -u 0x3000
Select tuner input
[root@host]# ./test_ioctl -p 0
Select composite video input
[root@host]# ./test_ioctl -p 5
Set full PAL resolution
[root@host]# ./test_ioctl -f width=720,height=576
Set full NTSC resolution
[root@host]# ./test_ioctl -f width=720,height=480
Finally, try to capture some video: 
[root@host]# cat /dev/video0 > first_capture.mpg
Press ctrl-c to stop the capture.

Why is the module failing to load ?

 Most often the module will fail to load because:


I'm in a PAL/SECAM country, how do I capture ?

Bear in mind that driver PAL/SECAM support is still being worked on. What you need to do is to use ioctl controls to tell the driver to switch to the desired standard. To do that use the test_ioctl utility in the driver's /util directory. For example:

Set the input (optional):
[root@host]# ./test_ioctl -p 5
Set PAL video standard:
[root@host]# ./test_ioctl -u 0xff
Set full PAL resolution
[root@host]# ./test_ioctl -f width=720,height=576
If using 5 above just gives you a black screen or static, try different numbers in the range 0-9.

Why is my captured MPEG just a black screen ?

 A black screen is invariably an indication that you are capturing from either the composite input or the SVideo input but no valid video signal is present on that input. Another possibility is that the card is programmed to an input which has no equivalent physical connector on the board that you can apply your signal to. The fix in all cases is to try setting the card to another input via the ioctl utility and try another capture.

Why is my captured MPEG just static or noise ?

A capture of just static or noise is an indication that you are capturing from the tuner but the tuner is not tuned to any particular channel. Use one of the utilities in the driver source /utils directory to set the tuner to a valid channel.

Why is it capturing video but no sound ?

The MSP34xx chip is not initialized to the correct audio input or audio standard. Experiment with different values in:

[root@host]# ./test_ioctl -v input=?,output=?
Also be absolutely sure you're loading the msp3400.o in the driver directory and not the system one under /lib/modules/...

Why do I get "tuner unset" in /var/log/messages ?

At some point the driver will autodetect the tuner type and set it accordingly but for now you need to set it manually. Either change /etc/modules.conf and add or modify the line 

options tuner type=X
or if you prefer to load the tuner manually every time, then load it with 
[root@host]# modprobe tuner type=X
where X is a number that corresponds to your tuner type, eg:
2 Philips NTSC (FI1236,FM1236 and compatibles)
5 Philips PAL_BG (FI1216 and compatibles)

Why do I get "I/O error" when I try to read/copy from the card ?

This is usually caused by incorrect driver settings or it indicates that the encoder did not detect a valid video signal to encode. The encoder may be set for NTSC and you are attempting to capture a PAL signal, or the video signal resolution is set incorrectly.

It is also possible that the card has become locked (known issue). A simple unload/reload of the driver will fix this

Why does xawtv not play the stream captured by the driver ?

The stream capured by the driver is an MPEG stream, xawtv only understands raw formats such as YUV and will choke on an MPEG. While the driver can be made to output raw YUV data, the format conforms to NV12 specification which xawtv does not understand either. In other words, xawtv and ivtv just don't get along! Use a player that understands mpeg, such as mplayer or xine.

Why is my captured video choppy ?

Check /var/logs/messages for "no free buffers" and try loading with 

[root@host]# insmod ivtv.o debug=1
to cut down on the amount of traffic to the hard disk which will reduce delays. The driver currently allocates about 1 second worth of buffering.

Also try playing the stream on a different computer or operating system. Sometimes the choppiness is because the computer playing the stream is not powerful enough to decode the MPEG stream without dropping frames, or the player may not be 100% standards compliant.

Ensure that DMA is enabled on the hard drive you are writing data to:

hdparm  /dev/hda to view settings
hdparm -d1 /dev/hda to enable DMA mode.
(to check/set /dev/hdb or /dev/hdc just substitute it for /dev/hda above)

Why am I getting unresolved symbols when inserting the module ?

The ivtv driver depends on other modules which must be loaded prior to it. Most likely you forgot to load one of these required modules. See the question above titled "I compiled the driver, now what ?" for the recommended loading procedure.

Why do I sometimes see "unknown ioctl 0x00005401" in the logs ?

This seems to be a common occurence with the Perl scripts. The error message can be safely ignored and does not affect the driver functionality in any way. The following text relates to TCL scripts but may shed some light into the Perl behaviour.

"Digging a bit in the Tcl sources, it appears that Tcl (open proc) issues a isatty() call on a file descriptor it has obtained on the specified file (e.g. /dev/rtf0). This ends up invoking ioctl(fd,TCGETS,...), which actually seems to be the ioctl() case triggered in the RTAI-fifos driver. This can be confirmed by a brief look into /usr/include/asm/ioctls.h: TCGETS code is 0x5401, i.e. 21505 decimal."

This issue is believed to be fixed. Please let the developers know if you are still experiencing it.

Help! My box is freezing/locking/hanging/unhappy. I think it's IvyTV's fault!

Please report your situation to the ivtv-dev mailing list. You'll need to sign up if you haven't already.

Some chipsets seem to have a problem with the large amount of DMA traffic that IvyTV generates combined with the large amount of DMA traffic of the data being written to disk. From what I understand these are known issues in linux for these chipsets. Currently the list is just via chipsets; the kx133, kt133, kt266, and the kt400.

Disclaimer

Information subject to change without notice. All trademarks acknowledged. All trademarks, brands, and product names mentioned herein are the property of their respective owners.