Well this is my first post here but I wanted to ask hopefully a straightforward question.

I'm trying to take a video of the screen frame by frame and I want to do it as close to real time as possible. I've heard there's ways to do it using Win32 GDI, OpenGL, DirectX, but I know that OpenGL is platform-independent so I want to use that.

I've seen things for games like recording Counterstrike games and stuff but I wasn't sure how these worked. Basically if I can get something in a format where I can work with the individual pixels for each frame, that would work out.

I want to capture the output. Mainly at the OS level. Like what someone would see on a monitor.

Each time you render: Grab the frame from OGL with glReadPixels(), dump it to a tmp file (possibly use fast Zlib compression to save disk space), and once done recording, encode tmp file frame-by-frame using libogg/libvorbis.

Quote:Original post by thefrost
Each time you render: Grab the frame from OGL with glReadPixels(), dump it to a tmp file (possibly use fast Zlib compression to save disk space), and once done recording, encode tmp file frame-by-frame using libogg/libvorbis.

Quote:Original post by mhagain
Reading from the backbuffer into system memory is going to incur a pipeline stall though, so you'll never get it really "real-time".

Yes to both. However, the second one is not true if you use a pixel buffer object and properly overlap frames. This is a tiny bit more organisational work, but still pretty straightforward.

When a frame is to be recorded, issue a read into a pixel buffer object and push the PBO's identifier as well as any additional information that you might want, such as the current frame's number into a queue. Forget about the PBO for now, let it do its work.
Each frame, the queue is checked for frames that are at least 2 frames old. You can use the previous frame as well, this works exactly the same. However, I prefer being 100% on the safe side, and it doesn't really matter to wait a fraction of a second longer, so I'm waiting two frames.
If there are any candidate frames on the queue, their PBOs are mapped (GL_STREAM_READ) and handed to GDI+ for compression, and are written to disk (need to do one copy to flip them upside down, but that's a simple fast loop).

In my measurements, the overhead of this is exactly zero (meaning there is no measurable difference whatsoever in frame rates with or without screenshots, and the additional CPU load is under threshold).
Note, however, that supplying wrong flags when creating or mapping your PBO may cut your frame rate in half (due to stalls)!

There is no reason why the same could not be done for recording a video as well, which basically is no more than screenshotting every frame.

Wow lots of responses so far! So it sounds like a solution like this is definitely possible. I'm not really concerned about any stalls as long as they're not cumulative. As long as frames enter a program and exit to video at a fixed rate, it's no problem.

Decrius: I agree with the open source libraries solution. I'm not looking for a currently finished application.

Samoth: Sounds like you have a pretty good understanding about this. How much code do you think this would take? Is it something I can run in the background easily, maybe as some kind of DLL?