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.

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/

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

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.

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.

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.

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

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.

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

install both the kernel and the kernel source rpm and boot that kernel

cd to /usr/src/linux

with root privledges run "make mrproper"

copy the config that matches your kernel from /usr/src/linux-2.4/configs to /usr/src/linux-2.4/.config

make sure /usr/src/linux is a sym link to /usr/src/linux-2.4

with root privledges run "make oldconfig ; make dep"

edit /usr/src/linux/include/linux/version.h and remove "custom" from the end of the UTS_RELEASE version number

also edit /usr/src/linux/Makefile and remove "custom" from the end of the EXTRAVERSION version number

go to where you have the ivtv driver source (driver directory under the ivtv cvs module)

copy the videodev2.h here "cp ../utils/videodev2.h ./"

run make

load the modules as per the faq, order is important

check dmesg for any wierd errors, the dirver is quite verbose ATM so don't be alarmed

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:

i2c-core, i2c-algo-bit - doesn't need to be a module, though it will help in debugging. Select the appropriate options in the i2c section of the kernel configuration to enable these. Most distros have i2c support enabled.

videodev - This is the Video 4 Linux module. Can be compiled-in or modularized.

tuner - This controls the tuning of the FM tuner (if supported) and TV tuner. Is produced as part of the bttv driver, it is recommended to compile it as a module. Most distros have bttv support enbaled.

If you want to manually load each module, the recommended procedure is as follows:

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:

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.

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.

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.

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

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.

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.

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.

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.

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.