Real-time OpenGL screen capture

Started by
20 comments, last by luckyyyyyy 12 years, 6 months ago
So what I am hearing is that BitBlt is not going to be as efficient of a solution as using this PBO readback method. I was reading a little about it and saw that using the PBO method basically involves fast pixel data transfer to and from the graphics card using DMA, and not hogging a bunch of CPU cycles.

To me, this seems like the option I would want to pursue, since I am planning on running this program in the background while normal computer operation is going on. I don't want to look in the task manager and see my cpu usage pegging.

I don't have this real-time video thing planned so much for games at this moment, but it might come up in the future and it would be good to be prepared with an efficient design.
Advertisement
I think you do not understand the difference, because you keep talking of two different things which are not easily exchangeable.

1. Capturing an OpenGL window (or several OpenGL windows, it does not matter). There is a context and a buffer that is drawn to (usually two, front and back), and you can read out that buffer asynchronously in an easy and efficient way using a pixel buffer object.

2. Caputring "what goes to the monitor". This is a totally different thing. For example, under MacOS X Quartz, or Metacity, or the respective Microsoft rip-off Aero, the image that goes to the monitor does not need to be much correlated to what you draw in a window.
Anything drawn inside windows goes to a non-visible buffer and is then transformed and composited in some way (3D transform, wiggly windows, transparency and fade effects, color grading, blur, ... whatever). There is no easy and obvious way (and probably no way at all!) to get to this buffer using OpenGL, as it isn't managed by OpenGL.
BitBlt on the other hand may not be nice and super efficient, but it can read from that buffer.

So, it really depends which of the two you want, but you need to understand that these are different things, and you can't just "mix" them.
I think I see what you are saying samoth. I can't really use OpenGL here since the video that is shown on the monitor normally isn't created using OpenGL. For example, when I'm using Firefox or something, that's not OpenGL. It's the operation system basically right?

If I want to capture the screen when normally using a PC, I have to use the operating system. If I am in a game where the graphics are created using OpenGL, I could technically use the PBO readback method?

One question I have now, do you think it would be possible to do this whole screen-capture thing by interacting directly with the video driver? Don't video drivers have APIs written for them?
The driver APIs that I'm familiar with let you query and change display settings, but to my knowledge have no documented way of accessing the raw framebuffer. Which of course doesn't mean that there might not be such a thing.
However, I'm not optimistic for you to find such a way, even less so one that works for three different vendors.
Quote:Original post by Decrius
Personally I like http://sourceforge.net/projects/taksi/, it's a free capturer, no limitations etc. (unlike FRAPS). You can also capture a part of the screen, pretty neat.

Taksi is nice and you can use third party codecs, so you can capture to lossless and then use maxed out x264 encoder settings to get high quality recordings in small size (I use Lagarith codec in Taksi and then MeGui for conversion to mp4 with ludicrous settings). However, Taksi has a big disadvantage: no audio capture, which may or may not be an issue for you. In my case, if a client wants a complete preview with audio, I record and mux in the audio track separately, but if you need audio all the time, this is too much trouble and you should look at other solutions.
"But who prays for Satan? Who, in eighteen centuries, has had the common humanity to pray for the one sinner that needed it most?" --Mark Twain

~~~~~~~~~~~~~~~Looking for a high-performance, easy to use, and lightweight math library? http://www.cmldev.net/ (note: I'm not associated with that project; just a user)
Here's my idea :)

1.) Draw one pixel in the left top corner which changes it's color every frame.

2.) Record your video with lags and whatever.

3.) Iterate through all generated frames and check if the pixel color changed. Remove subsequent frames where the pixel color didn't change, so that each frame is unique.

4.) Now play each frame for 1/60th of a second or whatever framerate you like.

5.) :)

Edit: Yo, nevermind, this wouldn't work! But maybe measuring the length of each frame and correcting it by that in a post process step? Sorry for disturbing this thread :)
Don't worry scope. Got all that I wanted out of this anyways. I decided to go with a Win32 GDI solution.

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.




Hello Stevus...

Actually, I think this topic is little bit complicated and difficult . i have studied many thing and tried to implement but couldn't get success. I just want to capture the some images and capturing can be after some delay. I don't want to make real-time video, so did you get the answer how can we capture the images in Display() function (real-time rendering).
kindly visit my this post you will know what i have done and what is wrong with my code. Thanks.

Capture OpenGL window screen in Real-time ?

This topic is closed to new replies.

Advertisement