Talk:Video capture card
(From Tuner Card) I am thinking we should remove the line of text above the first bullet point and make the bullets into headers. Thoughts? --WhyTey 12:43, 2 February 2006 (UTC)
- You think correctly. :-) --Baylink 00:08, 3 February 2006 (UTC)
I think these three articles carry much common information that users would wish on one article
It seems this article and Capture Card Matrix are swirling around a lot of common information. In my opinion, one single, centralized article citing all the good, bad, and ugly cards is good. Then, someone reading can either venture off into the hardware realm, or into the driver realm from this central location. I'll post this on the Talk:Capture Card Matrix as well. --Gregturn 05:38, 26 January 2006 (UTC)
- It would appear Tuner Card should also be considered in this effort. --Gregturn 03:58, 3 February 2006 (UTC)
- I think it should --jogibear 11:09, 26 Janary 2006 (GMT) (moved from Talk:Capture Card Matrix --Gregturn 20:27, 4 February 2006 (UTC)
- Okay, I just finished merging Tuner Card and Capture Card Matrix into this article. The redirects have been put in place. --Gregturn 21:00, 5 February 2006 (UTC)
Capture Card Matrix
I'm very happy to have found this, as it stands it's the most straight-forward information I've found yet covering what works, what doesn't, where to find drivers, etc. Also good is the fact it's not horribly out of date...
I'm new here, I've not personally made any entries on a wiki, nor have I read on the syntax, furthermore I have zero experience with video capture under Linux or BSD... Otherwise I'd see about editing this myself.
EDIT: idea below is implementend by adding a column and changed the introduction - user: loki 20080509 1615
- What would be nice would be a couple more columns on the Matrix, along the lines of what types of signal the cards will capture. Like TV (NTSC/PAL), Satellite, Cable TV, HDTV air, HDTV (cable), etc... This would make it clear which cards someone might be interested in buying to add to a MythTV box. For example, if I knew that a "Satellite TV tuner card" would also capture Cable TV and over NTSC(USA) broadcast TV, then I'd be interested in in no matter what it's marketed as. Perhaps it's an oversimplification, but if there are multiple types of Cable signal, they can be specified on the page that covers the individual card.
What does the "CC" in "CC Stream" and "CC MPEG2" stand for?
While I do use Linux on my servers (Slackware, no GUI), and am very comfortable with the CLI, I'm no broadcast guru. It seems that most of the information regarding MythTV is written at the level of a sysadmin who is willing to do lots of reading about which signals are which (Multiple versions of DVB, QAM, 8ESV, NTSC/PAL, ATSC, etc, etc) with very little plainly-written information. In other words, instead of referring to something as QAM64 and expecting every person coming here to know what that means, refer to it as Cable TV *1, and then put a footnote saying (QAM64), and page up for CableTV 1 stating that it's QAM64 and a list of places where it's offered, some info on it, whatever...
Perhaps MythTV is simply way too complicated for anyone but the serious hobbyist/admin/tinkerer, but unless some of the documentation is easier for the average person to understand, it will continue to remain this way.
All in Wonder cards..
The ATI All-in-Wonder card cannot (it is said elsewhere on the internet) send video across the PCI bus. It can only show video on the VGA output on the card. It is on this basis that neither the card nor drivers are appropriate for use with mythtv.
Not quite true. The All-in-Wonders (at least through the early Radeon vintages) were quite capable of PCI bus mastering and even interrupt support; the problem being that the capture engine shared elements with the standard 2D and 3D functions of the video card, thus requiring the Xv integration. Tuning is done by bit-banging a GPIO register to send the SPI/I2C signals. The earliest hacks simply reserved the top meg or so of video memory, and hoped they didn't run into contention with the video drivers... except that they did, often enough. Another issue we ran into was color space support; Linus refused to allow colorspace conversion routines into mainline kernel drivers, so all we could expose was the YUV data. Most V4L software was written around the RGB24 format common in Bt8x8 cards. In theory we could've used one of the 3D texture pipelines to do the conversion, but documentation was rather sparse.
I stopped working on the project somewhere in the early Radeon days, so the above may be a bit dated.
R Cicconetti Former GATOS developer
 IIRC, there was hardware I2C support in some chipsets, but it never worked very well.