multithreading - Texture Buffer for OpenGL Video Player -

i using opengl, ffmpeg , sdl play videos , optimizing process of getting frames, decoding them, converting them yuv rgb, uploading them texture , displaying texture on quad. each of these stages performed seperate thread , written shared buffers controlled sdl mutexes , conditions (except upload , display of textures need in same context).

i have player working fine decode, convert , opengl context on seperate threads realised because video 25 frames per second, converted frame buffer, upload opengl , bind it/display every 40 milliseconds in opengl thread. render loop goes round 6-10 times not showing next frame every frame shows, due 40ms gap.

therefore decided might idea have buffer textures , set array of textures created , initialised glgentextures() , glparameters needed etc.

when hasn't been 40ms since last frame refresh, method ran grabs next converted frame convert buffer , uploads next free texture in texture buffer binding calling gltexsubimage2d(). when has been 40ms since last frame refresh, seperate method ran grabs next gluint texture texture buffer , binds glbindtexture(). effectively, splitting being done before (grab convert buffer, upload, display) seperate methods (grab convert buffer, upload texture buffer | , | grab texture buffer, display) make use of wasted time between 40ms refreshes.

does sound reasonable? because when ran, video halts time in sporadic manner, 4 frames played when supposed (every 40ms) there 2 second gap, 1 frame shown, 3 second gap , video totally unwatchable.

the code near identical how manage convert thread grabbing decoded frames decode buffer, converting them yuv rgb , putting them convert buffer can't see massive bottlenecking be.

could bottlenecking on opengl side of things? fact storing new image data 10 different textures problem when new texture grabbed texture buffer, raw data million miles away last 1 in terms of memory location on video memory? that's attempt @ answer, don't know how opengl works internally that's why posting here.

anybody have ideas?

i'm no opengl expert, guess of bottleneck textures intialized in system memory sent video memory @ 'wrong' time (like @ once instead of possible), stalling pipeline. when using gltexsubimage2d have no guarantees when texture arrives in video memory until bind it.

googling around seems pixelbuffer objects give more control when in video memory: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&number=262523