We made changes back in 2015 to fix threading issues with the osg ffmpeg plugin. I don't think these changes ever made it into OSG.
Source repo: https://bitbucket.org/digitalis/osg-ffmpeg-plugin/ On Monday, August 10, 2020 at 3:46:32 AM UTC-7 [email protected] wrote: > Hi Robert, > > Thanks for your response. > > If FFmpegImageStream::publishNewFrame is invoked from a separate thread. > Is it then somehow guaranteed that (for example) Texture2D::apply is not > using/reading from the image object, while > FFmpegImageStream::publishNewFrame is modifying it ? > > Cheers, > > Ben > > Op vr 31 jul. 2020 om 21:24 schreef Robert Osfield <[email protected]>: > >> Hi Ben, >> >> I'm away from my dev computer so just commenting off the top of my. >> FFmpegImageStream should be double buffered so that the ffmpeg thread >> writing to the image will be writing to one part of the data, while the >> other half is available to be read by the graphics thread. This should >> avoid threading issues. >> >> The threading used by the ffmpeg plugin is separate from the viewer >> threading so settings related to the viewer won't be important, nor will >> general settings of the scene graph. >> >> You should be able to just add the ffmpeg genearted imagestream to a >> texture, start the steam going and then largely forget about it. >> >> Robert. >> >> On Friday, 31 July 2020 at 20:15:45 UTC+1 [email protected] wrote: >> >>> Hi, >>> >>> I was just looking at FFmpegImageStream, I am not very familiar with >>> this code, but I have some questions. >>> >>> It is not immediately clear to me how FFmpegImageStream::publishNewFrame >>> is thread safe. >>> It seems like the image data is set (setImage) from the video decoder >>> thread. >>> The image then uses a pointer to one of the buffers of the video decoder >>> (of which the contents might also change ?). >>> >>> FFmpegImageStream also doesn't seem to override requiresUpdateCall, >>> which I believe will result in the texture not being dynamic >>> (Texture2D::setImage). >>> Which could be used, for example in StateSet::computeDataVariance(), to >>> determine whether the StateSet should be dynamic (which is needed for >>> multithreaded rendering). >>> >>> If anyone could shed more light on this subject, it would be very much >>> appreciated. >>> >>> Thank you. >>> >>> Cheers, >>> >>> Ben >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "OpenSceneGraph Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/osg-users/386b2bdb-9924-4d01-bc42-98565c685ac0n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/osg-users/386b2bdb-9924-4d01-bc42-98565c685ac0n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/89d17cce-a8a9-4c8a-a347-c5a47fc7e8c5n%40googlegroups.com.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
