tvtime logo

tvtime: tv worth watching

[ tvtime homepage ] [ download tvtime ] [ development page ] [ report bugs ] [ help and faq ] [ using tvtime ] [ hardware and driver support ] [ fancy screenshot page ] [ related websites ]

Hardware and driver support page

Contents

1. Support resources
2. Summary of tested hardware by release
3. Tuner problems with ATI TV Wonder (and other!) cards
4. No "canada-cable" frequency table?
5. Information for users of the bttv driver
  5.1. Optimal driver configuration: The gbuffers setting
  5.2. Special bttv luma correction mode
  5.3. bttv takes a long time to load!
6. Known SAA7134 driver issues
  6.1. Frames all green
  6.2. Window setup failures
  6.3. Field parity swapped (jerky motion)
  6.4. Timeouts/invalid argument errors
7. ATI All-In-Wonder video/capture cards: The GATOS driver
8. Cards which use the Zoran driver (including the DC10)
9. Matrox Marvel capture cards
10. Information for users of the rivatv capture driver
11. Unusable drivers for the Voodoo 3500 TV card
12. Poor performance with SiS driver in XFree86 4.2.1 and earlier
13. XVideo always-on-top with some Radeon cards
14. Corrupted image borders on nVidia cards in overscan modes
15. No XVideo support in open-source nVidia driver for older cards
16. Problems with nVidia TNT and TNT2 cards
17. Audio problems with Prolink PixelView cards
18. Driver problems with SAA7146/linux-dvb supported cards
19. XVideo initialization problem with the savage driver
20. Using 'overlay' mode in xawtv/zapping causes system instabilities

1. Support resources

Interested in tvtime? Having trouble? Have suggestions? Why not hang out with us on IRC at irc.freenode.net, channel #livid. Hope to see you there!

There is also a tvtime development mailing list that you may want to subscribe to.


2. Summary of tested hardware by release

The following is a list of capture card and driver combinations which users have reported to be successful with tvtime. If you're using a card and driver combination not on this list, please email vektor@dumbterm.net so I can add it to the list.

tvtime 0.9.7
  1. Hauppauge WinTV Go [bttv / debian sid 2.4.20-686 2.4.20-5]
  2. ATI TV Wonder [bttv / debian sid 2.4.20-686 2.4.20-5]
  3. ATI TV Wonder VE [bttv / Gentoo linux-2.4.20-gentoo-r1]
  4. Haupage WinTV Primio [bttv / mandrake 9.0 2.4.19-24]
  5. Terratec Cinergy 600 [saa7134 / 2.5.65 - http://bytesex.org/patches/2.5/patch-2.5.65-kraxel.gz]
  6. Winfast TV2000 Deluxe [bttv / kernel.org 2.4.19]
  7. AVerMedia AVer TV Studio [bttv / ALT Linux 2.4.18]
  8. Pinnacle PCTV Pro [bttv - 2.4.20 + bttv 0.9.6]
  9. Prolink PixelView PlayTV Pro 9D [bttv - 2.4.20-custom + bttv 0.9.2]
  10. Miro PCTV [bttv - debian 2.4.20-custom]

3. Tuner problems with ATI TV Wonder (and other!) cards

The tuner driver incorrectly detects the tuner on (some? all?) ATI TV Wonder cards. This causes all of the cable frequencies to be out of alignment, channel numbers are off-by-one and slightly detuned. To fix this, the tuner module must be told explicitly the tuner type when it is loaded by doing the following:

    modprobe tuner type=2

You may have to first remove the bttv module if it is already loaded. To make this change automatic, in your modules.conf file, add the following line:

    options tuner type=2

This will ensure that whenever the tuner module is loaded, it will use the correct tuner for this card. If this does not fix the problem, or if you have an ATI TV Wonder that does NOT exhibit this problem, please post a bug report on the tvtime bugs page.

To attack this problem, we believe that the tuner module must be fixed to correctly detect the difference in tuner, as so many users are affected by this problem. To help with this, please follow up on bug 711428.


4. No "canada-cable" frequency table?

If you do not have an ATI TV Wonder card, and you were one of the users of the "canada-cable" frequency table, then you're likely suffering from the same problem as above for the ATI TV Wonder card: an incorrectly identified tuner. Please post a bug report on the tvtime bugs page indicating which type of card you have, and whether explicitly setting the tuner type helped.


5. information for users of the bttv driver

This section contains information about specific features and dependancies in tv for the popular bttv driver.

5.1. Optimal driver configuration: The gbuffers setting

Most of the advanced deinterlacing algorithms require a history of past input frames in order to predict motion in the video stream. For best performance, tvtime requires that these history buffers be provided by the driver itself. While new versions of the bttv driver provide four buffers by default, most versions only provide two.

Ensuring that your driver provides four buffers will give you access to all of the available deinterlacing methods. To do this you must provide the following option when installing the bttv driver:

    modprobe bttv gbuffers=4

To make this change automatic, in your modules.conf file, add the following line:

    options bttv gbuffers=4

This will ensure that whenever the bttv module is loaded, it will provide four frames to applications.

5.2. Special bttv luma correction mode

The popular Bt8x8 chip outputs non-standard colour values. While most video overlays are calibrated for input in the range of 16-235 for the luma component, and 16-240 for the chroma components, the Bt8x8 chip has two operating modes, both of which output values in a non-standard way. tvtime has as a special feature of the luma correction filter the ability to correct for this, ensuring slightly-more-correct colour for these cards. This correction is enabled automatically if you have a Bt8x8-based capture card and turn on the luma correction filter.

To turn on luma correction, just hit the 'c' key. A value of 1.0 will do nothing but apply the bttv luma correction if you have an appropriate card.

5.3. bttv takes a long time to load!

On some cards without a tuner, bttv can take a long time to load (on the order of minutes). To fix this, try using this option for the i2c-algo-bit module:

    options i2c-algo-bit bit_test=1

If that does not help, please post a bug report.


6. Known SAA7134 driver issues

All of the following issues are fixed in linux SAA7134 driver version 0.2.7. Please upgrade to that version before using tvtime.

6.1. Frames all green

Problems have been investigated where users see all-green frames when the driver has not allocated enough memory to handle the high resolutions used by tvtime. This has been resolved in tvtime 0.9.7 and the SAA7134 0.2.6 driver. Please post a new bug report if this is still a problem.

6.2. Window setup failed: run v4l-conf before tvtime

At least with snapshots before March 13th, tvtime would not run until the video4linux framebuffer must be setup with valid information. This means you have to run the v4l-conf command as root first before running tvtime. If this is still an issue with the latest saa7134 driver, please post a new bug report.

6.3. Field parity swapped (jerky motion)

We have had reports about field parity being swapped in frames captured. This is fixed in driver version 0.2.7. If you're still having trouble, please post a new bug in our bugtracker.

6.4. Timeouts/invalid argument errors

Some users still see alot of errors when running tvtime, but it seems that this has been solved with version 0.2.7 of the driver. If not, please post a new bug.


7. ATI All-In-Wonder video/capture cards: The GATOS driver

ATI has a line of video cards with video capture capabilities, and the GATOS project develops drivers for these cards which includes km, a kernel driver providing a Video4Linux interface to the capture components on these cards.

Note that this is just for video cards with capture capabilities, not for the ATI TV Wonder line of capture cards which use the Bt878 chip and are supported by the bttv driver.

The Video4Linux interface provided by GATOS is currently not working with tvtime, and at this point it seems unlikely that they ever will. The problems are:

  1. Rumor has it that the All-In-Wonder cards cannot both capture and allow an application to use the hardware overlay scaler of the card. If this is true, then tvtime would be unable to do any processing on the video.
  2. The Video4Linux interface provided by the km driver is nonstandard. It provides at field rate instead of frame rate, and does not seem to provide a way of detecting this. This may require additional support in tvtime.
  3. The km driver only supports read() mode, which is currently untested in the tvtime code. If someone could test this out, I'd appreciate it.

Assistance in investigating this for conclusive information would be appreciated. Please contact the tvtime developers if you can help out.


8. Cards which use the Zoran driver (including the DC10)

Recently someone tried to use tvtime with the zoran driver for the DC10plus and related cards that is part of a larger project called 'mjpegtools'. This is an older card, and depending on your PCI configuration, many users with seemingly high powered machines experience extremely poor performance. To quote an email with one of the driver authors:

From: Serguei Miridonov <mirsev@cicese.mx>

>   A user of your driver and I were trying to figure out why tvtime
> wasn't working.  tvtime operates by grabbing interlaced frames at full 
> rate (29.97/25fps), 4:2:2 Y'CbCr sampling, and deinterlacing them to
> give an output at field rate (but increased to frame size) of 59.94fps/
> 50fps progressive.  The zoran driver, when capturing at 640x480 4:2:2, 
> was providing nasty green frames/colourbars instead of providing any 
> reasonable video content.
>
>   The user determined that this is because of some memory limitations
> of the card, it can't handle this data rate,

It depends on the Zoran PCI controller (new versions work better than
the old one), and on the motherboard. Intel is much better than VIA, for
example...

> and so only lower resolutions like 320x240 or something can be provided
> when asking for raw 4:2:2 images, and that some sort of bigphysmem
> thing is required to get it to work, if at all.
>
>   This restriction seems pretty reasonable given the hardware involved,
> so that is not my concern.  My concern is simply that the driver did not
> fail or anything, but fooled tvtime into thinking everything was 'ok'.
> I would very much appreciate it if the driver could return some error
> when it is set in a mode that will not work.  Is this at all possible?

It's not so simple. I can only guess which hardware combination will
work and which will not (see above). And the hardware provides no means
to detect any buffer overflow for uncompressed video capture. Perhaps,
this is because the card was primarily designed for MJPEG capture (low
bandwidth) and to provide video monitoring on the computer display (no
RAM access,  just the PCI-PCI transfer from Zoran to any graphics
adapter. It can capture uncompressed video into memory even at full
frame rate but not on every system. My old system with Pentium MMX
266MHz with Intel 430TX works better than newer Athlon XP 1800+ at VIA
KT266A and DDR memory. Pentium MMX system can capture uncompressed video
to memory but can do nothing with it due to CPU and disk I/O
limitations. Athlon system can do anything (even encode into MPEG-4 in
real time) but some uncompressed frames are dropped due to PCI
limitations on VIA chipset...

Marcel Birthelmer wrote:

> Sorry for the misunderstanding, i wasn't complaining about a bug. I
> looked through zoran.c and i realized that the reason for grabdisplay
> not working was the 128 limit,

This is a limit from Linux kernel: it will not give you contiguous
memory  
longer than 128Kbytes without some special tricks: bigphysmem patch or
reserving memory at system boot using mem=XXX line in LILO or GRUB
configs.

> so i tested it, and grabdisplay does work with very small picture
> sizes. So my question is, what are my options for increasing this
> memory amount?

Bigphysmem patch or reserving memory at boot time. I suggest you to read  
README file: it has notes about this.

> just changing 128 to 1024 doesn't seem to work, but also i don't
> really want to patch my kernel unless i have to.  Any suggestions?

If you need help, please, describe your system: motherboard chipset,
processor, memory size and type, etc. Also please note that older
ZR36057 chip may not work properly on some motherboards. Newer ZR36067
is better but it also may have problems with VIA chipsets.


9. Matrox Marvel capture cards

A user has reported an unsuccessful attempt to use tvtime with a G400 marvel card supported by Matrox Marvel driver project. To quote:

  Its taking 38ms to grab a frame, but the marvel does
  all its own scaling in hardware (ie not via Xv, well I
  dont think it does) the anoying thing is that if the
  hardware scaling is in use Xv cant be used.

  It would be nice if tvtime supported overlay mode so
  that us marvel users can at least use the 16:9 mode in
  fullscreen.

I think we may be able to get this card working, but it will take someone with a bit of know-how to figure out what the card expects, and I guess the ability to shut off whatever hardware scaling prevents us from using XVideo.


10. Information for users of the rivatv capture driver

Like the bttv driver, the rivatv capture driver defaults to only 2 buffers for frames.

Ensuring that your driver provides four buffers will give you access to all of the available deinterlacing methods. To do this you must provide the following option when installing the rivatv driver:

    modprobe rivatv capbuffers=4

To make this change automatic, in your modules.conf file, add the following line:

    options rivatv capbuffers=4

There have been reports of performance problems with the rivatv driver. There are two reasons for this.

  1. The driver does format conversion as it gives the frames. It does not support YUY2 capture, only a variant called UYVY. It will not be difficult for tvtime to support this directly, but it is annoying that the driver claims to support YUY2 when really it is being slowed down by this conversion process.
  2. By default the driver copies frames from video memory into system memory. Performance can be improved by using DMA to transfer the frames, however, this option only works when using the open-source "nv" driver in X, not with the nVidia binary drivers.

You can turn on dma support as follows in your modules.conf file:

    options rivatv capbuffers=4 dma=1

11. Unusable drivers for the Voodoo 3500 TV card

An unmaintained TV card driver for the Voodoo 3500 card is located here:

  http://sourceforge.net/projects/v3tv/

However, this driver does not support capturing, and therefore cannot be used with tvtime.


12. Poor performance with SiS driver in X 4.2.1 and earlier

The XVideo drivers in XFree86 versions up to 4.2.1 exhibit extremely poor performance. This is fixed in later versions of the driver. If you own a SiS card, please upgrade to the latest driver by Thomas Winischhofer, or upgrade to X 4.3 which includes a recent version of his driver. The web page for the SiS X driver is here:

  http://www.winischhofer.net/linuxsis630.shtml

The tvtime bug report to on this is bug 636338.


13. XVideo always-on-top with some Radeon cards

Around the end of 2002, it was noted that with the ATI Radeon 7000 card and the XFree86 4.2.1 packages in debian, XVideo windows are "always on top" and cannot be minimized. This was also seen in RH8.0's XFree86 4.2 with a Radeon 32MB DDR, R100 QD (a 7200 card?). We have not researched this issue enough to know the extent of what cards are affected, or what versions will fix this. More information on this would be appreciated.


14. Corrupted image borders on nVidia cards in overscan modes

There is a bug in versions of the nVidia driver before 1.0-4349 and the nv driver in 4.3.0 and earlier for cards which support wide filter kernels for high quality XVideo surfaces. If the overscan value is larger than 0, then the card uses memory outside of the image for interpolating around the edges, causing corruption all around the outside of the tvtime window.

nVidia was made aware of the problem and fixed it for driver release 1.0-4349 and in the nv driver in CVS XFree86. For reference, the tvtime bug on this was bug 694144.


15. No XVideo support in open-source nVidia driver for older cards

The open source nVidia driver for X ("nv" not "nvidia") does not support XVideo surfaces for pre-GeForce cards like the TNT2. To use tvtime with these cards, you must use the binary drivers.

That said, the binary drivers should give better performance for XVideo than the open-source driver, since it can use the kernel module component to negotiate DMA transfers for video frames. If possible, stick to the binary drivers when using tvtime on nVidia hardware.


16. Problems with nVidia TNT and TNT2 cards

5.1 Corrupted frames

The TNT and TNT2 cards are very limited in their bandwidth, and this problem will appear as horizontal lines in the video output unless you're running at a fairly low resolution. Smaller output window sizes will make the problem worse, as the DAC will have to read out more data in the same amount of time. This problem should not occur with any of the Geforce series cards.

5.2 Card can't downscale

A user of a NV5: RIVA TNT2 Ultra (rev 11) noted that the card cannot downscale video, it only crops it. This user was using version 1.0-4191 of the NVIDIA X drivers.

5.3 Poor performance at high frame size and refresh rate

A user of a TNT2 Vanta card reported that blit performance was absolutely terrible until they went down to a resolution of 800x600, at which point speed quadrupled. We believe this is due to bandwidth problems on these cards.


17. Audio problems with Prolink PixelView cards

The bttv driver seems to misdetect Prolink Pixelview cards pretty badly. There are five Prolink cards listed in CARDLIST for the bttv driver:

  card=16 - Prolink Pixelview PlayTV (bt878)
  card=37 - Prolink PixelView PlayTV pro
  card=50 - Prolink PV-BT878P+4E / PixelView PlayTV PAK / Lenco MXTV-9578 CP
  card=70 - Prolink Pixelview PV-BT878P+ (Rev.4C)
  card=72 - Prolink Pixelview PV-BT878P+9B (PlayTV Pro rev.9B FM+NICAM)

The bttv driver cannot seem to autodetect these cards correctly. We've found that cards which should use card=70 but are instead loaded using card=72 are causing audio mute/unmute to fail randomly, or even be inverted, resulting in no audio or just snippets of audio. To avoid this, please make sure you are using the correct variant of this card. Specifically, the rev 9D of the newer Pixelview cards should use card=70 and not card=72.


18. Driver problems with SAA7146/linux-dvb supported cards

We have had a bug report about the linux-dvb driver found on the linuxtv.org page. This supports, among other things, the Hauppauge Nexus-S cards.

The 0.9.7 release of tvtime fails on the current released stable driver, as it does not properly indicate what it supports. As well, there are performance difficulties. From Michael Hunold, the driver author:

to make a long story short: "linuxtv-dvb-1.0.0-pre1" and the so-called
DVB "head" or "newstruct" drivers are v4l1 drivers.

The CVS "dvb-kernel" driver is the new *v4l2* driver, which does not
have the problems you mentioned. YUYV byteorder is completely disabled,
capture performance problems should be gone, because I use Gerd Knorr's
"video-buf" capture buffer abstraction. Because of that, the performance
should be equal to the bttv / saa7134 driver.

For technical reasons relating to V4L1 and V4L2, it is impossible to provide a driver under the V4L1 API for this card, and so in order to get everything working, tvtime will have to support the new V4L2 API, and also support the UYUV byte ordering of the card. These features are planned, but not complete.

For reference, the original project page for this driver is at http://www.gdv.uni-hannover.de/~hunold1/linux/saa7146/index.html and and an explanation of the current DVB driver situation is at http://linuxtv.org/dvb/drivers.xml. As well, the thread on this issue on the linux-dvb mailing list can be found here: http://www.linuxtv.org/mailinglists/linux-dvb/2003/03-2003/msg00020.html and the tvtime bug report is bug 694544.


19. XVideo initialization problem with the savage driver

We've investigated a bug where the savage X driver does not initialize its XVideo subsystem unless it starts on a modeline where the resolution equals the virtual resolution. That is, if you have a virtual resolution of 1600x1200, make sure you start on a 1600x1200 mode, otherwise XVideo won't initialize.

This bug was noted on the XFree86 devel list here: http://www.mail-archive.com/devel%40xfree86.org/msg01248.html


20. Using 'overlay' mode in xawtv/zapping causes system instabilities

Overlay mode, as can be used in xawtv or zapping, causes system instabilities. This is because their 'overlay' mode allows the capture card to write directly to video memory without locking it first, which is unsafe for many video cards, specifically those which do not use a linear framebuffer (such as nVidia cards with the binary drivers).

Use of the xawtv/overlay mode has caused system crashes, and specifically, can cause tvtime to crash if it tries to use XVideo features after the framebuffer area has been destroyed by the capture card (see tvtime bug 702539).

A workaround for having a no-CPU-access mode is to use the XFree86 "v4l" extension, which allows safe use of the framebuffer by capture cards. tvtime does not support using this mode, nor do we have plans to, as we would not be able to composite our OSD on top of the video signal or provide any processing features on the video.


Bugs in this page?
vektor@dumbterm.net
SourceForge Logo libpng Logo Valid HTML 4.01! Valid CSS!