Thanks to Hodgey from Norway.
The ATI eHome card is confirmed to have the Theater 200 chip on it.
Using Graphedit on Windows XP I was able to capture audio and video in uncompressed 720x480 YUV and compressed MPEG2 formats to separate files.
The video is pretty much what you would expect, crystal clear and stable with no frame drops.
The audio is PCM.
The data rate is what you would expect for uncompressed and the bit rate is selectable from the hardware encoder device driver properties sheet.
Generic capture software like
VirtualDub recognizes the card, but cannot capture audio or video.
VLC recognizes the card, and can record, but cannot manipulate its crossbars.
So there are problems with it.
Perhaps with time these cards will be better understood.
Since there are very few true PCI cards with the ATI Theater 200 chip on them, I thought this would be of interest.
There are probably a lot more modern motherboards with legacy PCI support than AGP.
I'd also like to see how far up the Windows version tree this 32 bit driver will go.. I believe Windows 7x32 worked at one time with the ATI TV Wonder USB2.0 perhaps it will work with this PCI driver as well.
-- merged --
Upon further review of cards and pics.
It seems the eHome has been redesigned several times, always with the Theater 200 chip, but sometimes without Input jacks for Composite or S-Video.
There also appears to be an eHome TV Wonder VE edition.
And a number of OEM only cards that did or did not require the Barney dock.
I would not recommend people rush out and try finding this specific card at this time. There are too many unknowns about the TV Wonder line. Some have Connexant decoders, some have the earlier Brooktree decoders which Connexant bought out from a University. But there are definitely some OEM cards that have the Theater 200 chip and behave and use the eHome device driver under windows.
-- merged --
First an apology to msgohan and hodgey from Norway.
I got their names mixed up when referring to the person who put me on to this card.
It was msgohan from Vancouver Canada that put me on to the card.
I've had quite a lot of good progress on this card.
Graphedit and VLC seem to work with it properly.. the VLC crossbar thing was a long standing problem I've had understanding how crossbars work in the default Microsoft User Interface called the "Properties page".
I started suspecting there was a method to their madness.. and it finally clicked into focus. A user had a problem with this way back on a Pinnacle 510 usb capture device.. I may revisit that later.
Anyhoo..
It does capture audio and video as you can see from the short uncompressed test avi I uploaded. Sync drift does not appear to be a problem in that brief clip and longer sessions I've tried.
The device driver appears some what deliberately "hobbled" for what reason I do not know.. but I plan to tweak it and see if its actually much more robust.. or had its wings clipped for a reason.
A person reported elsewhere and elsewhen that they got
Virtualdub to work with it but couldn't get audio capture to work.. I now think that is a broader misunderstanding of how to use the Microsoft User Interface for setting the audio capture source, independent of VirtualDub. That is its not VirtualDubs fault.. its the way Microsoft presents the control choices.
I really haven't tried to understand the TV Wonder branding.. it seemed to be their test field of cards before they turned them into all-in-wonders. The use of the AGP bus seemed to be a cherry on top to enable combining the Theater 200 (or whatever encoder chip that was used with the Radeon chip to be used). Or perhaps it was the other way around, the TV Wonders were Theater 200 test beds before adding them to existing Radeon cards to make them all-in-wonders.
In any event the legacy PCI bus seems to have more than adequate bandwidth for SD video capture.. and a much longer life cycle than USB 2.0 at that time. USB was still new back then, and had design limitations, PCI was in version 2.0 and its still appearing on some motherboards with PCI express buses today.
The really nice thing is this card (is) a universal PCI card, meaning its both 5 volt and 3.3 volt compatible. That's the two forward and rearward notches in the card edge connector that inserts into the PCI slot. Modern legacy PCI slots aren't suppose to support the 5 volt variant these days due to modern CPU voltages.. of course bridge chips caught up with that.. but its the "norm" to only support 3.3 volt cards these days. Its very good this card is a Universal.
I'll add the cabling and dongle situation is "much" simplified with this card.
1. you can use it with virtually any other video card, or in a server "headless"
2. the video connectors are standard, large DIN, RCA and 3.5 mm and could be easily replaced
3. the device driver is literally a single file and inf file, its very simple
4. if it matters (it does) have a Connexant hardware MPEG2 compression chip and compressed capture pin on the driver
You don't have to capture "compressed" you can capture "uncompressed" all options are on the table. The device driver gives you direct access to the Theater 200 chip output.
Also there doesn't appear to be any kind of "binary blob" that gets uploaded to program any chips.. as happens frequently with things on the other side of a USB bridge chip. Its straight "register" programming.
I don't know of any ATI or AMD internal documentation for the Theater 200 chip.. but the linux community could have probably written a driver many years ago by reverse engineering it.. its pretty straight forward.
But the focus in "those days" was really on the video chip and not the video capture chip.
This card does have an NTSC tuner, so it is Microsoft BDA compatible and was intended to be used by Window Media Center 2004 (XP Edition). I simply put it into a Windows XP + SP3 situation and its been working fine.
I guess Windows Media Center for capture might be the logical choice, but then there is the MS-DVR and the DRM variant to contend with. And since Microsoft has end of life'd that platform it will be problematic to support going forward. -- The VirtualDub community and standard file formats for all their logistical problems have open source and can live on and be recovered by many people after the originators have long since ceased to be available.
-- merged --
More progress last night.
I upgraded the test system through Vista x32 and now Win 7 x32
The device driver from XP works flawlessly on Vista.. and while tweaking the driver did not restore VirtualDub functionality.
I think I know why.
On Vista it appears the VirtualDub graph attempts to pull video frames from the MPEG2 pin of the device driver model. VirtualDub can't handle compressed video.. it doesn't crash.. but it doesn't decode it either.
I seem to recall M402 support for compressed frames in VirtualDub 1.6 and beyond.. but that was very specific to that capture platform.. it probably doesn't extend to this card.
So..
Somehow VirtualDub is using the ksproxy to "discover" pins.. and its auto selecting the "wrong" one. I think Directshow works by "hinting" which pins are what.. or the Interface of the pins is tied to a "Class" in the registry which hints to the application which pin to use for video. It could be either an ordering problem (since there are two video pins, one compressed MPEG2, one uncompressed.. or something else).
My thoughts are if I tweaked the device driver to "remove" the registration of the MPEG2 video pin as the video Class.. then VirtualDub will "see" the uncompressed video pin and just work like normal.
I've had similar problems with Stoik and a number of other video capture applications with this card. In those cases.. weirdly.. they find the preview pin and display video perfectly fine.. but can't capture video.. so its the sum of all these events that make me think its the MPEG2 video pin that is getting in the way of using this card with many other video capture applications. Many video applications from that era expected uncompressed video frames since hardware compressed frames were too expensive to produce for most users.. the hardware compression cards were too expensive.. so they instead captured the uncompressed frames and "expected" to software compress them "after" they were pulled into the application.
Its kind of odd that this cheap hardware compression video card, with the unique feature that plain uncompressed video was available might be tripping us up because its "over achieving"..
I have no problems capturing and writing multiplexed AVI audio and video using Microsoft GraphEdit "uncompressed video".. but that's not what most people expect and its rather klunky. VLC capture works too.. but it does the same thing.. it defaults to finding the MPEG2 compressed video stream and automatically uses that as its input and writes that stream to a file.. as an MPEG2 stream even when captured through VLC raw... so thats a third confirmation of whats going on.
Sort of related.. also confirmed that the Turtle Beach Santa Cruz sound card works under Vista x32.. but you do have to uninstall and reinstall with the last device driver installer package Turtle Beach made available for the Santa Cruz. The Equalizer doesn't work but otherwise the main mixer and all the important functions work just fine.
I can't say that of Windows 7 x32 yet however.. the Santa Cruz card is silent after that upgrade, device drivers seems to install and start up.. but just no sound. Anyway that's a distraction.. its not the problem I was working on. In theory the sound capture for VirtualDub would pull from the card itself and doesn't need a sound card for audio capture. Some other sound solution could be used for playback.
update:
I just had another thought !
ATI MMC installs a software video decoder for MPEG2 which it used for DVD playback and viewing ATI VCR files.
These are virgin installs of the operating system sans any MPEG2 decoder. Win7 x32 came with an MPEG2 decoder.. but its not working right now because my video card is an old Intel Extreme 2 XPDM device (865G).. so I have to install a card with XDDM support before it will be totally functional.
Its "remotely" a very slim chance.. that VirtualDub isn't working because the frames aren't being decoded.. because there is "no decoder" installed. That's not an ideal scenario.. decode MPEG2 frames only to save them as AVI.. its sort of "fake" uncompressed capture.. but it would be conclusive evidence.
I'd still like to "knock out" the MPEG2 video class registration for the pin and see if everything starts working for all the old capture software.