Hi Robert, It's then probably a good idea to update the ffmpeg plugin to also use a pointer swap.
The current implementation of the ffmpeg plugin is not optimal. Internally there are already two buffers (a private and a public one), because of the colour conversion routines, synch issues, and also because of the vertical orientation (see void FFmpegDecoderVideo::swapBuffers()). FFmpegDecoderVideo::publishFrame() and FFmpegDecoderVideo::swapBuffers() could be improved to feature a real double buffering (and remove the then-useless copy) so that FFmpegImageStream could implement a pointer swap. I think I could tackle this and submit the modifications during this week. Tanguy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Monday 02 March 2009 17:07 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] ImageStream and texture updates synch HI Tanguy, You don't want a synchronization point in the image stream as it'd cause the rendering thread to stall waiting for the movie reading thread. Rather than add such a sync operation, it's best to double buffer the image data and then just do a pointer swap on the image to tell it which buffer is current, this is what I implemented in the xine-lib plugin. Something else I have been wondering about is the possibility of having two ImageStream that are managed so that they are one frame apart, then in the graphics thread you'd have a geometry with two textures applied, and a mixing of the two textures based on the time for the rendering frame vs the time of each of the texture. This way one might be able to provide a smoother video experience. I must admit, I don't know how effective this would be on movies, but it might be an interesting thing to try out further down the line. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
