rendering multiple video streams

I'm developing an application which displays 4 (or even more, if possible) video streams simultaneously in real-time (30 fps per stream). I need a renderer that will take the raw YUV frames and display them to a Win32 window, scaling as required. Each stream is independent of the others, including running in separate threads. Currently, my app has an independent DirectDraw-based renderer for each stream (written by someone else), but performance degrades dramatically (much more than it should) as streams 2-4 start.

I'd like to know how DirectX experts would approach this problem.

Thanks for any advice you have,
Scott

Answer this question

rendering multiple video streams

Sachin1Sharma

It's a problem of compression of the video data...

DirectShow would be the best solution for this, several Graph will run in seperate thread

You can mix DirectX and DirectShow (who is in the Plateform SDK not DX SDK)

The best you can play in DirectX is AVI file that render in texture
Anything else that use compression or filter would need DirectShow

The size of the window stream is important, a 240x240 video is much faster
then a full size 800x600

YUV is for TV low resolution...you expect TV to be better then a screen but it's not
Actually TV is low resolution 420x420 of some low resolution like this

YUV is imperfect bits that use the fact that your eyes cannot make the difference
between many small color change, so you can generate more pixel for less data

Movie allways use Compression MPG will run much faster then AVI
MPG are actually a type of JPG...Loading the AVI Frame is very coslty

Save a BMP file and save it to JPG you will see that the JPG is much smaller
and easier to load

When you render without any compression its jerky at best
No real time feed would not use compression...

Your render speed problem is not cause by the number of stream or by the scale or the size because at worst it will only be in full sreen

The number one problem of video speed is bad compression or none at all...

It's much faster to read small video MPG on disk and to uncompress it
Then to load an uncompress BMP and to copy all it's huge bits array

Basicly it's the reading of your disk data that make this slow...

The CPU and your graphic card are both waiting for this load time...

So you need a better compression of your video

And by the way thank you for your question...I just realize that all my texture
are in BMP...I will convert them to jpg to accelerate the load...

Hope this help and there is a separate forum for DirectShow expert
that would help you with compression
Ray5468
Thanks for you response, but it's not what I need. You're assuming a much higher level than what I'm talking about. I don't need DirectShow - I'm not reading data from AVI's or files and the disk is not involved at all. The rest of my program obtains compressed video data and decodes each frame into a YUV bitmap. I need to display 29.97 * 4 of these bitmaps every second. My decoding time is very low; rendering is my bottleneck. Displaying 1 stream uses less than 10% CPU on a 1.8GHz Celeron; 4 streams use 97%.

As I continue to research and investigation this problem, I'm starting to think that the culprit is locking the surfaces. When a thread waits on a call to IDirectDrawSurface::Lock, is that wait a busy wait Currently the code waits to return from Lock; I'm going to try changing it to use DDLOCK_DONOTWAIT (and add appropriate handling code) and see if that improves things at all.

I guess my main question is should I be able to have separate threads writing to different surfaces independently from one another without any problems - performance or otherwise Or should I focus on writing a new rendering system that has all DirectDraw calls in one dedicated rendering thread

Thanks,
Scott
rendering multiple video streams

Answer this question