Displaying video raw data from memory in OpenGL mode

SDL Development
1

HI,

I’m wondering what the best way would be to display streaming image data
from memory to an OpenGL quad or texture?

I have images raw in memory and would like to do the equivent of blitting
the video steams as overlay over a 3d view.

If you have any pointers how best to achive this with SDL I would love to
hear them.

regands,
Freyr

2

I’m wondering what the best way would be to display streaming image
data from memory to an OpenGL quad or texture?

I have images raw in memory and would like to do the equivent of
blitting the video steams as overlay over a 3d view.

If you have any pointers how best to achive this with SDL I would
love to hear them.

There’s always the option of uploading the images as textures to
OpenGL and using another quad (with admittedly a different viewport
setup) to render them. I’m semi-working on a video player-hopefully-
to-become-editor in SDL with OpenGL, and that’s how I display the
video frames, and it’s not too shabby. (The real slowdown is not
from uploading the texture as it is from decompressing the video
frames.)

That’s just my $.02 of the matter. I’m not an expert on SDL or any
of this, however.

–Scott

3

HI Scott, thanks for the response.

How do you manage the frames?
Do you dump the old frame/texture when you load the next frame or does
OpenGL do that for you?
Or can you recycle the textures somehow?On 8/25/06, Scott Harper wrote:

There’s always the option of uploading the images as textures to
OpenGL and using another quad (with admittedly a different viewport
setup) to render them. I’m semi-working on a video player-hopefully-
to-become-editor in SDL with OpenGL, and that’s how I display the
video frames, and it’s not too shabby. (The real slowdown is not
from uploading the texture as it is from decompressing the video
frames.)

That’s just my $.02 of the matter. I’m not an expert on SDL or any
of this, however.

–Scott

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

4

Actually, (and this may be the wrong way, but I don’t think so) I
simply change the array of bytes each frame (retrieved from ffmpeg),
and then using the same texture number retrieved from glGenTextures
( 1, &number ); for the one texture, I simply call glTexImage2D(…)
with the same data argument. This keeps the same texture address,
but changes the image data. I don’t THINK this allocates new texture
memory on the video card, but if it does, the old stuff should be
forgotten anyway, so you’re not wasting too much space.

It occurs to me that there MAY be some slowdown in this as the
glTexImage2D(…) call probably has subroutines to determine the
amount of memory needed on the video card for the texture, as it has
no way of knowing the sizes are the same in this one instance. So
you (and I both) may want to look at using glTexSubImage2D(…), as
this more directly replaces the pixels in the texture rather than re-
creating a new texture. Here’s the link:

http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/
gl/texsubimage2d.html

And here’s glTexImage2D,

http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/
gl/teximage2d.html

wherein I found this interesting passage:

  "In GL	version	1.1 or greater,	pixels may be a	null pointer.
  In this case texture memory is allocated to accommodate a
  texture of width width and height height.  You can then
  download subtextures to initialize this texture memory. The
  image	is undefined if	the user tries to apply	an
  uninitialized	portion	of the texture image to	a primitive."

Seems like this may be one way to go, though I’m not entirely sure
why it would be necessary to initialize an empty texture rather than
just initializing it with the first frame of the video… Well,
unless the video is loaded after initializing the the texture stuff
in the program. Sorry, I’m thinking out loud.

Anyway, I think this is the best way to go about it, with
glTexSubImage2D(…). Hope this helps. :slight_smile:

–ScottOn Aug 25, 2006, at 10:38 AM, Freyr Magn?sson wrote:

HI Scott, thanks for the response.

How do you manage the frames?
Do you dump the old frame/texture when you load the next frame or
does OpenGL do that for you?
Or can you recycle the textures somehow?

On 8/25/06, Scott Harper wrote:

There’s always the option of uploading the images as textures to
OpenGL and using another quad (with admittedly a different viewport
setup) to render them. I’m semi-working on a video player-hopefully-
to-become-editor in SDL with OpenGL, and that’s how I display the
video frames, and it’s not too shabby. (The real slowdown is not
from uploading the texture as it is from decompressing the video
frames.)

That’s just my $.02 of the matter. I’m not an expert on SDL or any
of this, however.

–Scott

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

5

thanks for the info? This clarifies alot for me :slight_smile:

FreyrOn 8/26/06, Scott Harper wrote:

Actually, (and this may be the wrong way, but I don’t think so) I
simply change the array of bytes each frame (retrieved from ffmpeg),
and then using the same texture number retrieved from glGenTextures
( 1, &number ); for the one texture, I simply call glTexImage2D(…)
with the same data argument. This keeps the same texture address,
but changes the image data. I don’t THINK this allocates new texture
memory on the video card, but if it does, the old stuff should be
forgotten anyway, so you’re not wasting too much space.

It occurs to me that there MAY be some slowdown in this as the
glTexImage2D(…) call probably has subroutines to determine the
amount of memory needed on the video card for the texture, as it has
no way of knowing the sizes are the same in this one instance. So
you (and I both) may want to look at using glTexSubImage2D(…), as
this more directly replaces the pixels in the texture rather than re-
creating a new texture. Here’s the link:

http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/
gl/texsubimage2d.html

And here’s glTexImage2D,

http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/
gl/teximage2d.html

wherein I found this interesting passage:

      "In GL        version 1.1 or greater, pixels may be a null

pointer.
In this case texture memory is allocated to accommodate a
texture of width width and height height. You can then
download subtextures to initialize this texture memory. The
image is undefined if the user tries to apply an
uninitialized portion of the texture image to a primitive."

Seems like this may be one way to go, though I’m not entirely sure
why it would be necessary to initialize an empty texture rather than
just initializing it with the first frame of the video… Well,
unless the video is loaded after initializing the the texture stuff
in the program. Sorry, I’m thinking out loud.

Anyway, I think this is the best way to go about it, with
glTexSubImage2D(…). Hope this helps. :slight_smile:

–Scott