Qustion about OpenGL + SDL + muti-threading + theora

Started by
3 comments, last by swiftcoder 16 years, 7 months ago
Hi, every one I am working on an application that can play theora ogg file using OpenGL and SDL, and I looked at the Nebula Device 2 nOggTheoraplayer class at this link: http://nebuladevice.cubik.org/documentation/nebula2/classnOggTheoraPlayer.shtml and build my class the same way they build it, but the problem is that I don't know how to play the video with such heirarcy. so I decide to create a thread that decode the video frames and render the decoded frames to a texture, and in the main thread I will render this texture to the screen for every frame. the problem is that I created the texture in the main thread and then I created the thread that will render to this texture, and when I want to render to this texture I call the following code to be sure that the texture has been created: assert(glIsTexture(texture_id)); when the application run the assertion will cut the program indecating that the texture isn't valid, so why does that happend?!! I am sure that I create the texture in the main thread with the same id, so what I can do to solve this?
Advertisement
you have to do the texture upload when your ogl context is active. this means you have to switch context (activate) in your "decode" thread.
you could also create two ogl contexts and share resources between them.
AFAIK there can be one OpenGL context that is current for each thread. Either you use two OpenGL contexts and use wglShareLists or something named like that so that the two contexts share the resources or you must call something like wglMakeCurrent to make the OpenGL context created in the main thread current to the second thread, so that the second thread can use it.
I think the 2 contexts approachs is saver because you use multithreading.
Using wglShareLists to load resources while rendering

SDL doesn't support multiple contexts AFAIK, so you will have to do a little more legwork. You will need to do the decoding on the second thread, then signal the main thread (or use polling, whatever) which will grab a buffer containing the frame data, and render it.

Oh, and be careful about where you malloc/new the buffer, as allocation is not usually multi-threaded, and if called from the worker thread will cause synchronisation.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement