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. On Mon, Mar 2, 2009 at 4:44 PM, Tanguy Fautre <[email protected]> wrote: > Hi, > > > > From what I understand, an ImageStream indicates that the image as been > changed by calling the dirty() method. From there, a texture will update its > content with the new image when the scenegraph is traversed. > > > > The problem is that I’ve not found any way to synchronize the point where > the ImageStream updates its current image and where a texture update its > content with the current image, which leads to visual tearing (very similar > to vsync off) if the ImageStream and the texture update their content at the > same time. > > > > This is quite visible on some videos when using the FFmpeg plugin. > > > > Any ideas? > > > > > > Cheers, > > > > Tanguy > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
