CPU Throttling While Writing WMV File

[markr]

I need some help recording a multi-stream WMV file.

I am using the DirectShow and Windows Media Libraries in C#.  I am using GraphEditPlus for helping create the code for the graph as well.  I created a WM Profile to handle two USB Logitech Webcam streams, one PCM Audio stream, and a stream using the Generic Sample Source Filter that came with the DirectShow .NET Library.  With the GSS Filter, I have a solid white bitmap background image where I overlay text and images.  All video streams are running at 30FPS at 24 bit ARGB.  The WM Profile is using the Windows Media Video 9 Codec for compression on all three video streams.  This is producing small enough file sizes with good quality output.

My computer is a Pentium Dual-Core 2.4GHz with 3 GB of RAM.  The WMV file is created successfully most of the time, but now and again, the WMV file records for less than the time the graph is running and the Performance tab of the Windows Task Manager has BOTH cores of the CPU pegged 100% when this failure occurs.  I can stop everything and run the graph again and it will record fine, but the Performance shows both cores usage at around 90-95%.

My question is this:  Is there a way to throttle the ASF Writer filter's hunger for grabbing up all the available processing from both cores of the CPU?

The WMV file format is SUPPOSED to handle up to something like 60+ streams and I'm just trying to get 4 or 5 streams to be synchronized! 

Any suggestions, alternative approaches, etc. are greatly appreciated.

Mark

[Dee Mon]

File format support has nothing to do with this. Video encoding is the beast that eats up CPU. You encode several streams to WMV9 (close to MPEG4) at 30 FPS, that's already an achievement. If you want to do it faster (with less CPU load) you need either a simpler (less CPU consuming) codec, lower bitrate (hence less work for entropy coder inside WMV) or lower input data rate (lower FPS or resolution - less overall work for the codec).

One more trick to reduce the load a bit - work not in ARGB but in YV12 or YUY2. It's harder, but the datarate is lower and the codec converts to this colorspace anyway, so you save some time by avoiding the conversion. Most webcams can provide video in these formats.

[markr]

Thank you again for your wisdom and prompt reply.