PDA

View Full Version : Theory: OpenGL for Video Playback!



joda
02-06-2003, 08:42 AM
Im currently designing a video app which is using OpenGL to accelerate the playback. I've found that textures is very fast to switch for frames (normally 24fps/sec)!

Im currently just loading arrays of img data to memory then I call and update a texture to display the animation.

This works fine but I want some more tips on how to increase the performance. Is it possible to increase the speed? Cache textures in OpenGL? Is it possible to take advantage of hardware better?

All kinds of tips are welcome! Anyway, Im basically using a loop and some time variables to control the animation, ideas on playback are also welcome!!!


Thanks!

- Joda

[This message has been edited by joda (edited 02-06-2003).]

reignofchaos
02-06-2003, 09:05 AM
I'm not exactly sure but I think the fastest way to do this would be render to a texture and use TexSubImage2D. I think NeHe has a tutorial on this which you might wanna check

joda
02-06-2003, 09:12 AM
Originally posted by reignofchaos:
I'm not exactly sure but I think the fastest way to do this would be render to a texture and use TexSubImage2D. I think NeHe has a tutorial on this which you might wanna check

Hey, very true thats exactly what Im doing right now, I've tried to use glDrawPixel but thats a little bit slower.

So is that because of texture memory in the hardware? Or what makes using texture so fast?

- Suddenad

bucky
02-06-2003, 11:56 AM
i forget the name of it, but theres a software program out there for film proffessionals that uses gl to flip through fullsize frames at 24fps or whatever you want... if your just sub'ing textures from sysmem to the card then it should be able to play at 24-30fps nicely with no problem... are you loading all the frames into system memory and then doing texsubs? i tried the following but scrapped it....

-load 10 frames into sysmem
-while your displaying frame1do a threaded load of frame11 into frame1's spot and so on

zeckensack
02-06-2003, 01:28 PM
I don't know what you guys have been testing, but I've found glDrawPixels to be faster than texture uploads, as it should be.

You just have to make really sure that you've got the right data format.

OneSadCookie
02-06-2003, 01:38 PM
If you're using NVidia hardware on Linux or Windows, you can probably use NV_pixel_data_range to your benefit.

If you're on Mac OS X, you can use APPLE_client_storage and APPLE_texture_range for good speedups.

Also:
* make sure you're using the right pixel format for your texture uploads. GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV is generally a good pick.

* make sure your memory buffer is page- (or at least cache-line-) aligned.

* make sure each row of your memory buffer is cache-line aligned.

Robo
02-06-2003, 02:55 PM
I am developing software for live interactive video performance, and am currently able to play multiple video files simultaneously directly from harddisk to textures. This allows me to use vertex programs and espesially register combiners to mix, luminance key and apply effects to the video.

I use NV_texture_rectangle to avoid wasting bandwidth, as the videoframes are non power of two sized. I don't have to think about compatibility issues as this is for pure inhouse use.

I tried using NV_pixel_data_range when it first showed up in the extension strings, but never got it to work back then. I might try again now that more documentation is available.

Regards
Lau www.motorsaw.dk (http://www.motorsaw.dk)

joda
02-06-2003, 10:26 PM
Originally posted by bucky:
i forget the name of it, but theres a software program out there for film proffessionals that uses gl to flip through fullsize frames at 24fps or whatever you want... if your just sub'ing textures from sysmem to the card then it should be able to play at 24-30fps nicely with no problem... are you loading all the frames into system memory and then doing texsubs? i tried the following but scrapped it....

-load 10 frames into sysmem
-while your displaying frame1do a threaded load of frame11 into frame1's spot and so on




Actually the system works fine except for the memory it "eats". So what you mean is that you load data while playing back animation? So you load up 10 frames then you start to pre-load the future frames using multi-threading? cool idea! My problem is that Im using my player for flipbook work and that approach wont help me to much, cause what happens if user is viewing fr. 4 and suddenly he switch to view fr. 20? I need to pre-load animation before viewing it. But your idea will certainly speed up this! Be sure to correct me if Im wrong, or explain more about the threads.

I've got some plans implement a "playing" mode which acts more like a regular player and not like a editing flipbook. Perhaps the threads will work better for this!

Thanks for all feedback!

- Joda