I have implemented video playback in a dynamic 3D scene and it works alright, but being new to Opengl I would like confirmation that this is a good way to implement - or information about a better way.
What I do is simply to sequentially read in every frame of the video and create a texture for each frame. There may be several GB of texture data this way. The system is win7 64 bit with plenty of system memory and a geforce 9800 with just one GB memory and in a pci-e bus. The textures are ARGB up to 1920x1080 in size.
Every time I render a new scene frame, I switch to the next frame texture and render the textured object. The render speed matches the playback speed of the video which is 50 FPS.
Since the textures can not all be on the graphics card, they are swapped in and out from system memory to the graphics card as needed. It seems to work fine without ever lagging behind.
But… it is a very simple method and I do not know the details behind how opengl prioritizes swapping the textures, so currently I can just note that it seems to work for now during testing, but I cannot feel much confidence in the method since I don’t really know the details.
Is my method sound or is there a better alternative?
I would use PBOs for streaming the texture data up to OpenGL, but other than that, this all seems entirely reasonable.
After rendering a frame, I do use PBO to move the rendered data to another hardware unit, which then generates a SDI video signal, but I am not sure how you would use a PBO for the textures.
Note that I have all the time in the world (almost) to load the texture data and create the textures. The time critical part is just to move a new texture to the card and render a frame using it before I am required to render the next frame.
If I initially simply create for example 1024 textures which are each 3MB in size then that is 3GB texture data with a card capable of no more than 1GB of texture data, then what?
I assume the textures are stored in system memory and that opengl will swap textures in and out of the card when they are being used. I select a texture simply by binding its texture id and then render.
How would I do this using a PBO? Would I not have to manually do what opengl does for me in the background now? As I mentioned, I am not an advanced opengl user, so I may be missing your point entirely. Please elaborate 
If I initially simply create for example 1024 textures which are each 3MB in size then that is 3GB texture data with a card capable of no more than 1GB of texture data, then what?
That’s really more than you need. You should be decompressing in chunks, as the movie plays.
You only need at most 3 OpenGL texture objects. One texture would be for the frame currently being displayed; call it frame 0. One texture would be for the next frame, frame 1. This is here to allow PBOs time to asynchronously transfer the data. The last texture would be what you are about to do a PBO transfer on for frame 2.
Then, on the next frame, swap them. The frame 1 texture becomes the frame 0, the frame 2 becomes frame 1, and the original frame 0 becomes frame 2.
I agree. I do not need to store this much in memory. It is only to make it as fast as possible, given that I have a lot of system memory. Initially, with the DX version, I did as you describe, but then it was a 32 bit system with a lack of memory.
I see your point with using PBO to write data into a specific texture, rather than create a new one with the new frames data, but given that I have plenty of system memory, is there any problem with creating a texture for every frame and then letting opengl swap them in and out?
The next step will be to implement the small buffer method for movies which are very long.
but given that I have plenty of system memory, is there any problem with creating a texture for every frame and then letting opengl swap them in and out?
Eventually, OpenGL will give you an out-of-memory error when you try to create a texture. Just because a system has a “lot” of memory doesn’t mean that you should treat it as an inexhaustible resource.