§ ¶Audio preview issues with ATI Theater HD 750 USB
I picked up an ATI Theater HD 750 USB capture device recently to add to my arsenal. As it is, I have far too many capture devices as it is, but about half of my collection is PCI, and now that I'm laptop-based that's rather inconvenient. I have two other USB capture devices, a Plextor and a GameBridge. The problem with the Plextor is that it produces a soft image and produces compressed video, so it has significant latency, about 300ms. It's also a bit big. The GameBridge is much smaller and produces straight UYVY -- perfectly fine for what I do -- but as it turns out, it will not sync to an Atari 800XL, whose video signal is too far out of spec. I was pleased to discover that the ATI device also outputs uncompressed data and does sync to the Atari, although the color decoding is kind of crappy... but that's a story for another time.
Unfortunately, I also discovered to my annoyance that the 750 USB has a problem with VirtualDub: it stutters horribly when "enable audio playback" is set. That option allows you to hear the output of capture devices that aren't sound cards in Windows, but the unofficial story is that it's the "emulate a TV set" option. I always hate debugging these issues because they always turn out to be issues where something isn't getting along with the DirectShow capture graph, which means doing all sorts of arcane incantations to try to fix it. After playing around a bit with Microsoft GraphEdit and with the cap_dshow.cpp module, I figured out that it was a problem with the filter graph clock. The filter graph clock is an entity, either in the filter graph or external, whose job is to supply a uniform timebase for all data that moves through the filter graph. This then allows the renderers that are displaying the video and playing the audio to all work off of the same timestamps and to also schedule their output to the same clock. For instance, video players typically have the DirectSound Renderer providing the clock, with the video renderer syncing to audio playback. This is also the configuration that VirtualDub normally chooses when the audio playback option is on. It turns out that the 750 doesn't like that configuration and has oscillation problems with it. The usual way to attack these problems is with the "disable timestamps for preview" option in Capture > Timing in recent versions of VirtualDub; this normally solves the problem by killing the timestamps and causing everything to play immediately as it arrives. Well, that's even worse, as the ATI capture filter doesn't even want to start in that case.
What does work, though, is using the system clock (CLSID_SystemClock). The bad part about this is why VirtualDub has its current behavior. I dug up the P4 revision history for that module, and it turns out the reason I wrote it this way is that I couldn't get the capture driver for the SAA713x to work with audio playback without using the audio renderer's clock. In particular, the system clock specifically did not work with that card. This means that the only way I can make this work across the board is to make the filter graph clock option three-way so the working clock can be manually chosen. Yuck. I hate doing this since it's just throwing the problem to the user. Heck, I wrote the program and I didn't know the answer either -- I just tried all of the options in code until I found one that worked. Unfortunately, this seems par for the course with DirectShow, which I've found to be one of the flakiest parts of Windows. I've described my disdain for this API before, and this is further reinforcement. It's bad enough that the API is complex, but too many of the third-party filters have antisocial behavior or hideous bugs, especially capture drivers.
Anyway, expect a fix for this issue to be available in a future version of VirtualDub. I'm thinking it'll probably be in the next experimental version, as I'm pretty risk averse at the moment to pushing things into the stable branch, and changes to DirectShow graph building code rank pretty high on my risk chart. If you have a device like this and want to try a hacked up test release, though, let me know -- I could always use some testing.
Comments
Comments posted:
Do you have any old rants against the dshow API in your blog history here? The month-by-month archives on the left aren't a very appealing prospect to trawl through, so I'm hoping you can remember some of the better ones :)
nine - 27 04 10 - 19:24
Not sure I've done any comprehensive DirectShow rants -- I think more of just grumbling here and there. Probably the best one I had was for the API function whose return value was documented as "the return value depends upon the implementation."
Phaeron - 27 04 10 - 19:33
Define "a device like this" please. I've got a König CMP-USBVG5 that I would be happy to test :)
Spinal (link) - 28 04 10 - 04:01
I've heard a lot of people who use Dazzle USB capture devices can't get audio to record at all in VDub. Do you have any idea why that is? (I'm only asking now since capture cards are the subject, even though DirectShow probably isn't the problem.)
Also, what capture card do you recommend? I'm currently using a 713x BDA Analog, which is pretty good, but I'm thinking about upgrading to one with Component and HDMI input. Something like this...
http://www.blackmagic-design.com/product..
(There's also some other nice capture gadgets on that website if you're feeling adventurous. ;)
And if this comment has appeared multiple times, sorry. Previewing isn't quite the smooth experience as one would desire.)
Mush Man (link) - 28 04 10 - 20:46
Is this something that a Time Base Corrector could fix?
I picked up one of these about a year ago really cheap, but I haven't really spent any time messing with it...
http://www.datavideo.us/products/tbcs-an..krick (link) - 29 04 10 - 09:28
@Spinal:
A device with similar stuttering problems, only when "enable audio playback" is set.
@Mush Man:
No, the Dazzle audio issue is a different problem. For some strange reason, the Dazzle's audio capture filter isn't under the regular category, so VirtualDub doesn't find it. I put a hack version up on the forums a while back but haven't gotten around to folding in the workaround. (It's kind of messy, as it causes all of the video devices to show up in the audio menu.)
As for which capture card to recommend, I don't have a good recommendation. Capture products tend to be short-lived, and they're fairly expensive so I can't get experience with a lot of them. The GameBridge is good, but discontinued and driver support in Vista/7 is a problem. This HD 750 device seems pretty OK, besides this one issue. I've seen a bunch of people use the BlackMagic Intensity for HD capture, but apparently the drivers have some issues and they killed 10-bit/component capture mode.
@krick:
Not the stuttering. The Atari signal issue, maybe.
Phaeron - 29 04 10 - 16:06
@Phaeron: I don't believe this issue is limited to the 750. I've noticed this issue before with my 650 pci-e based hybrid card as well. I've put up with it simply by disabling audio on capture.
I'm uncertain whether the following relates to this issue, but I've also noticed the following behaviour in Vista/Windows 7 64bit (using VirtualDub x86 or 64bit). I'll start VirtualDub and go into capture mode. The preview/overlay window will be black regardless of how I set the capture preferences. If I play around with the audio capture device settings however, I can occasionally get it to connect to the capture card where I can see video, and then capture from it. It's hit or miss however, and I'm uncertain just what it is that's preventing VirtualDub from connecting to the device.
32bitwonder - 30 04 10 - 07:23
I can confirm 32bitwonder's observations with a HD750 PCIe card as well so this appears to be related to the family of devices. In addition if I can connect with audio enabled there is stuttering in the overlay. Overlay also appears to be not at the expected size (appears to be double the 720x480 that is selected) while preview does render it the right size. I'm experimenting with two Blackmagic devices now as well and see some oddities with their HDMI capture in virtualdub not rendering but it's too early to tell where that issue might be. An AVerTV Combo is still happily working with virtualdub. I'm more than happy to test out a experimental version if you like (email included). I'm currently using Win7 x64 with virtualdub 1.9.9 32bit and 64bit.
Signal (link) - 31 07 10 - 10:56
Any updates on this?
I really wanna buy this card.
Thanks.
Drazick - 07 08 10 - 11:14
I'm having the same problems with the AVerMedia HD DVR PCIe capture card. Turning off audio during capture seems to fix it.... sometimes. Other times I have the sync oscillation problem Avery has, other times the card simply stops capturing video for a few seconds and then starts back up. Oh, and overlay preview is completely broken too. This problem seems to go beyond VirtualDub though. VHCapture, and VirtualVCR suffer from the same stuttering and sync issues.
Of course the card works 100% perfect with AVer's own MediaCenter software... which is a pile of crap. It will only capture AVI as uncompressed, no codec selection possible and it clearly processes the video before capture (tweaks color, de-interlaces, etc.).
Chris - 10 09 10 - 16:45
Comment form
Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
