I was playing with GraphEdit on XP and happened to have the
Audigy 2 ZS Video Editor plugged in and started the VideoStudio 8 SE editor in capture mode.
GraphEdit on 'XP' will let you attach to the 'Running Object Table' or ROT of other applications. This is nearly impossible to do on Windows 7 or above due to silo and sandboxing in the name of security. It is possible, just very hard.
So snatching a look at the Graph that VideoStudio is running revealed something very interesting. The "
Audigy 2 ZS Video Editor" is running a DirectShow graph of filters. The primary capture device has two output pins, one for the DV codec and one for the MPEG-1/2 codec and they can be configured when not connected or running to anything downstream.. within limits.
When you snatch a look-see at a running Graph from another app.. you can also save it to a file. Then close the running application and re-open the saved graph file and run it. It throws a normal windows capture render window open and you can see the output just as if you were looking at the window embedded in the application.
The driver is very cranky and unstable, it can lock up if not configured in precisely the way it expects.
I also took a look at the Graphs for Stoik and
VirtualDub.. Stoik will almost work with the "
Audigy 2 ZS Video Editor" it assumes all audio capture must come through the windows audio mixer. If it does not then its not selectable to include as part of the capture.
VirtualDub searches for a "raw" video output pin, which this device does not have. So VirtualDub can't work with it.
It seems a common pattern for many vintage and modern capture device + software capture bundles to either support hardware compression as a codec inside the device, or only support raw capture followed by an application graph that performs optional software compression. In general you don't use a third party capture app with with device because its unlikely it will understand the pins the hardware device driver will expose. Stoik assuming "all" capture devices expose an audio source through the windows mixer is an example... in the most general case you could route an audio mini-jack from the video capture device and into the sound card, which will have a line input to the windows audio mixer.. then it will be selectable in Stoik. But if like VirtualDub it "assumes" you will have a raw capture pin and it does not, it will throw up a fail dialog saying "Not compatible with this device".
The downside of the "
Audigy 2 ZS Video Editor" is of course that it has no "raw" output pin.. only DV or MPEG-1/2 pins.. so when capturing your getting hardware compression.. whether you like it or not.. and you have no choice but to optimize it as best you can. -- Its not like you could capture output in "AVI" to a file and then run an MPEG-4/h.264 compression process over it later.. you have no choice. This device does have other interesting features however.. like Dolby and SPIF sound support, or video Output as well as Input capture processes through the same driver. And IEEE1394 firewire support.. so its still an interesting puzzle box full of tricks.
I guess the big take away lesson is that of the many capture devices and software, there are those that are hardware "based" and those that are "software" based when it comes to compression. The hardware based sets may or may not have a "raw" output pin, like some of the Pinnacle or Avid capture boxes.
Due to the bandwidth and thoughput required to capture "raw".. its only been relatively recently that its been championed over that smaller trickle pre-chewed output of the hardware compression capture devices.. ATI and Pinnacle/AVID being notable exceptions. Since ATI started full bandwidth on the AGP bus.. carried that over to the PCI and then PCIe bus.. dabbled at USB 2.0 they covered pretty much every scenario.. and had the most experience with "raw" video capture.. only offering full on hardware based video capture in their last generation products. The Elite was their "PVR" card capitualating to the Windows MCE 2005 crowd with MPEG2.. and never going near MPEG4/h.264
Back in the day.. DV capture and output were favored with the IEEE1394 firewire bus.. and ATI had a couple All In Wonder offerings there too.. they seemed to cover everything.. but quickly abandonned firewire and stuck with AGP until PCIe came along and literally forced them off the AGP bandwagon.
Its fascinating to look back
