| Printable Version of Topic
Click here to view this topic in its original format |
| Unofficial VirtualDub Support Forums > Testing / Bug Reports > Capture W/ Dc10+ In 1.6.3 |
| Posted by: Moitah Jan 12 2005, 04:22 AM |
| Pinnacle Studio DC10plus capture card (DirectShow), Turtle Beach Santa Cruz sound card, Windows 2000 SP4, P4 2.4 Ghz, 1 GB RAM When using "Overlay" in 1.6.2, the video used to be 320x240. In 1.6.3 it is now 640x480, but it looks like a pixel resize from 320x240. CPU usage is 100% and frame rate is low (14-27 fps), unless the video area is covered by another window (even if only by a few pixels), then CPU usage is ~25% and the frame rate is 30fps. If VirtualDub is resized to make the video area smaller, it helps, but CPU usage is still at ~20% (this is about the same CPU usage as in 1.6.2). I turned off "Overlay" (selected "No display") to test capture. Capturing works pretty good, low CPU usage, no drops. The only thing I noticed was the audio was a bit off synch during playback, is this supposed to be corrected manually using the "Latency" value displayed during capturing (mine was around 130ms)? Also I see my Santa Cruz listed at the bottom of the Video menu, is this right? I was expecting to see it somewhere in the Audio menu, but it's not in there. |
| Posted by: phaeron Jan 12 2005, 05:09 AM | ||||||
Weird. I'm planning on testing with my DC30+ next, assuming I can find the 2K/XP drivers for it. It could be that somehow the display is being done using GDI -- I can't imagine how but it might.
That does sound a bit high, and no, you're not supposed to have to correct for it in post-editing. I wonder if the first frame from your capture device is not at time zero. That would explain the lag. Is the value mostly stable or does it fluctuate a lot?
Yes, it's supposed to be under Audio. Stupid hardcoded constants. It should still switch sources, though. |
| Posted by: Moitah Jan 12 2005, 05:18 AM | ||
It starts out at 0 for the first few seconds (maybe there is a delay while this value is calculated?), then starts climbing. After 30 seconds, the latency is at ~130 ms and it seems to be pretty stable. |
| Posted by: Incredible Jan 24 2005, 05:03 PM | ||
Just use the DC10 Drivers for the Dc30(+) in Win2000/XP, they work properly. But as known no Audio hardware support in WDM driver environment. Even with the (non free) drivers from Mirosupport.de . btw: When using the provided mjpeg.ax (or similair) decoder from Pinnacles driver install and assign the a prefered merit ALL Directshow mjpeg system decodes by this Dshow decoder will be send to the DC10/DC30's TV out. And if using Graphedit with a special Filtergraph you can let played back ALL video types via the DC10/DC30's TV Out. |
| Posted by: Moitah Feb 14 2005, 09:53 PM |
| @phaeron: I was playing with GraphEdit today. I connected to VirtualDub's graph and saw the preview pin is directly connected to Video Renderer. When I build a graph like that, I get the same problem where it looks like pixel resize, and it gets really slow with larger sizes. But I tried something different. I connected the preview pin to VMR9, and GraphEdit automatically added 2 filters in between (AVI Decompressor and Color Space Converter). Then I replaced VMR9 with Video Renderer, so the graph looks like: Capture preview->AVI Decompressor->Color Space Converter->Video Renderer. This seems to work a lot better, it no longer looks like pixel resize, and I can resize the window large and CPU usage stays low. Leaving VMR9 in there works fine too, but I wanted to make it work with Video Renderer. I'm not really sure how all this works, but I guess the preview pin is in some format (RGB?) that Video Renderer or my graphics card doesn't like. I get the same pixel resize and slowness when I try to play a RGB video through Video Renderer. |
| Posted by: FredK Feb 14 2005, 11:10 PM |
| My setup is showing skewed video after capturing in half horizontal size (DC30 using DC10 WDF driver on XP system with Intel 815 graphics) Only shows skewed in vitualdub, WMP shows raw file good. Same result in 1.6.4 and 1.6.3 http://203.109.252.72/~favou/dc30cap.gif Affects preview and processing, saved file is skewed in WMP Cap and processing in full horizontal size appears to work ok. |
| Posted by: Moitah Feb 14 2005, 11:30 PM |
| @FredK: I can reproduce this by compressing a file with Morgan MJPEG. It happens with VirtualDub's internal MJPEG decoder when the width isn't a multiple of 16. It will decode properly if you have a MJPEG VFW codec such as Morgan MJPEG, or enable MJPEG in ffdshow's VFW configuration. |
| Posted by: FredK Feb 15 2005, 04:04 AM |
| Ah - I have much to learn. I will now look at ffdshow and codec management in general. Thanks for your kind assistance. |
| Posted by: Moitah Feb 16 2005, 03:10 PM |
| I figured out how to fix Overlay (quality resizing, and low CPU usage). If I enable ffdshow's "Raw video" decoder for RGB24 or YUY2, it will automatically connect itself between the Preview pin and Video Renderer (not only in GraphEdit, but in VirtualDub as well). EDIT: IMHO, this is just a workaround. VirtualDub's editing section can display and stretch RGB/YUY2 fine without needing a decoder installed. Is it possible for the capture section to use the same display code, or would it be a big pain? |
| Posted by: phaeron Feb 17 2005, 04:53 AM |
| It already does, if you are in Preview mode and preview acceleration is turned on. However, this only works for the capture pin, so it might not work in your case. |