displaying RGB video from memory.
-
I wanted to display a compressed movie using Visual C++ at 25fps. I have the decompression working properly and display is also fine. But the movie is not smooth and not fast enough to be 25fps. I am using CDC structure to paint the processed pixels. What should be done to display efficiently. Should i go to kernel level calls. If so how can i do it. Or is there any ready-made techniques available in Visual C++ to do it. Hoping for a reply from graphics experts at the earliest
-
I wanted to display a compressed movie using Visual C++ at 25fps. I have the decompression working properly and display is also fine. But the movie is not smooth and not fast enough to be 25fps. I am using CDC structure to paint the processed pixels. What should be done to display efficiently. Should i go to kernel level calls. If so how can i do it. Or is there any ready-made techniques available in Visual C++ to do it. Hoping for a reply from graphics experts at the earliest
DirectX is really the way to go if you want to do animation that smooth. of course, DirectShow will already do it for you, if it's a known codec/format.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
-
DirectX is really the way to go if you want to do animation that smooth. of course, DirectShow will already do it for you, if it's a known codec/format.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
Its not any format. Its just RGB pixel values available as an array of 352X288(CIF) size. I would like this display to occur without being much disturbed by the decompression algorithm which is computatinally intensive. can i do something like dispatching a command and getting it done by an AGP or some solution similar to that.
-
Its not any format. Its just RGB pixel values available as an array of 352X288(CIF) size. I would like this display to occur without being much disturbed by the decompression algorithm which is computatinally intensive. can i do something like dispatching a command and getting it done by an AGP or some solution similar to that.
jossion wrote:
Its just RGB pixel values
OK, then it's not compressed, right ? I'd create a DIBSection of this size, use memcpy to copy the rows into place, and then display the bitmap from there, but probably using DirectDraw. Writing direct to AGP is outside of my experience.
Christian Graus - C++ MVP 'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
-
Its not any format. Its just RGB pixel values available as an array of 352X288(CIF) size. I would like this display to occur without being much disturbed by the decompression algorithm which is computatinally intensive. can i do something like dispatching a command and getting it done by an AGP or some solution similar to that.
If you can't decompress the frames fast enough then no rendering system is going to help. Using GDI it's possible to render many many 352X288 videos at 30fps using very little CPU - I do it all the time. You have to have the data ready (uncompressed) to be rendered though. I think Christian mentioned a DIBSection, which will allow you to have a buffer to jam your uncompressed frame data into and quickly blt to the screen. You can go the DirectX route but I would bet you won't notice a performance increase since 25fps is easily doable by either GDI or DirectX. Mark
-
If you can't decompress the frames fast enough then no rendering system is going to help. Using GDI it's possible to render many many 352X288 videos at 30fps using very little CPU - I do it all the time. You have to have the data ready (uncompressed) to be rendered though. I think Christian mentioned a DIBSection, which will allow you to have a buffer to jam your uncompressed frame data into and quickly blt to the screen. You can go the DirectX route but I would bet you won't notice a performance increase since 25fps is easily doable by either GDI or DirectX. Mark
First of all let me thank Christian and Mark for the valuable suggestions shared. I feel that I will have to do some homework before I could understand what you have suggested since I am new to this area. For the same reason I would like to get some links to resources which may help me to start with in this field (like programming DirectX or GDI). My decompression is fast enough for a frame rate of 50fps. The problem is with display only. Moreover I have written the display and decompression in a serial manner. First I think i will have to multithread it and then go for GDI or DirectX. I would like to get more help from Mark regarding GDI if the problem mentioned above could easily be done with GDI. Thanking in advance.
-
First of all let me thank Christian and Mark for the valuable suggestions shared. I feel that I will have to do some homework before I could understand what you have suggested since I am new to this area. For the same reason I would like to get some links to resources which may help me to start with in this field (like programming DirectX or GDI). My decompression is fast enough for a frame rate of 50fps. The problem is with display only. Moreover I have written the display and decompression in a serial manner. First I think i will have to multithread it and then go for GDI or DirectX. I would like to get more help from Mark regarding GDI if the problem mentioned above could easily be done with GDI. Thanking in advance.
The DirectShow SDK and the Windows Media Format SDK may be helpful resources. Even though you have your own codec and you don't need to use those SDKs there may be some helpful hints on how Microsoft does it. Typically... There's two areas that can be dealt with separately - I/O/Uncompress and rendering. I/O and uncompress is reading the source data and uncompressing into individual video frames. Using some kind of buffer allocator scheme, the decompressor allocates a frame buffer, writes the uncompressed frame data to the buffer, and queues it for rendering. The renderer checks the frame buffer queue. If there is a buffer available it checks the time stamp. If it's not time to display the frame yet then it waits. If the time for the frame has passed then the frame is either rendered immediately or discarded. That's the typical scenario using the SDKs I mentioned above. To implement it, there's all kinds of possibilities. For human-viewed video, frame rates don't need to be beyond 30fps so you don't have to get too crazy with timing issues. It's possible to do both steps on one thread but the performance can be bad. You decompress a frame and then wait until it's time to render it. This relatively large gap in time of doing nothing could be used to decompress another frame and have it ready. A more elegant solution would be to use two threads. One thread reads and uncompresses frames. It does so until enough frames are queued (some pre-defined read-ahead value) then pauses. On another thread you could render the frames. This thread could wait on an event like a multimedia timer event set to the frame rate or be triggerred by an event from the decompressor thread (set every time it adds a frame to the queue perhaps). There's some things that can make the process more efficient... 1)Pre allocate a pool of buffers so they don't have to be allocated every time you need one. Typically you'd want enough buffers to hold the read-ahead amount of frames mentioned above. You could actually use this to control the uncompress thread - when the thread tries to obtain a buffer from the pool and there's none available then it waits. 2)Design the buffers to be in a format ready for rendering. If the buffers are alread DIB sections for instance, then as soon as the frame data is uncompressed to the buffer then it's ready to render. No second copy is necessary. For Direct3D (formerly DirectDraw) the buffers could be Direct3D surfaces. 3) Don't do any of this on
-
The DirectShow SDK and the Windows Media Format SDK may be helpful resources. Even though you have your own codec and you don't need to use those SDKs there may be some helpful hints on how Microsoft does it. Typically... There's two areas that can be dealt with separately - I/O/Uncompress and rendering. I/O and uncompress is reading the source data and uncompressing into individual video frames. Using some kind of buffer allocator scheme, the decompressor allocates a frame buffer, writes the uncompressed frame data to the buffer, and queues it for rendering. The renderer checks the frame buffer queue. If there is a buffer available it checks the time stamp. If it's not time to display the frame yet then it waits. If the time for the frame has passed then the frame is either rendered immediately or discarded. That's the typical scenario using the SDKs I mentioned above. To implement it, there's all kinds of possibilities. For human-viewed video, frame rates don't need to be beyond 30fps so you don't have to get too crazy with timing issues. It's possible to do both steps on one thread but the performance can be bad. You decompress a frame and then wait until it's time to render it. This relatively large gap in time of doing nothing could be used to decompress another frame and have it ready. A more elegant solution would be to use two threads. One thread reads and uncompresses frames. It does so until enough frames are queued (some pre-defined read-ahead value) then pauses. On another thread you could render the frames. This thread could wait on an event like a multimedia timer event set to the frame rate or be triggerred by an event from the decompressor thread (set every time it adds a frame to the queue perhaps). There's some things that can make the process more efficient... 1)Pre allocate a pool of buffers so they don't have to be allocated every time you need one. Typically you'd want enough buffers to hold the read-ahead amount of frames mentioned above. You could actually use this to control the uncompress thread - when the thread tries to obtain a buffer from the pool and there's none available then it waits. 2)Design the buffers to be in a format ready for rendering. If the buffers are alread DIB sections for instance, then as soon as the frame data is uncompressed to the buffer then it's ready to render. No second copy is necessary. For Direct3D (formerly DirectDraw) the buffers could be Direct3D surfaces. 3) Don't do any of this on