Hi Rob, Ok, thanks for your responses.
Cheers, Ben Op di 11 aug. 2020 om 17:21 schreef Robert Spearman < [email protected]>: > > Sorry, I don't know off hand. I didn't work much on the code myself. > > Rob > On 8/10/20 11:38 PM, Ben Meijering wrote: > > Hi Rob, > > Thanks for the link. > In this version I also see that m_pImgStream->setImage is invoked > in FFmpegRenderThread::run(), another thread. > 2015 is a long time ago, but do you perhaps remember why this is safe ? > > Thanks in advance. > > Cheers, > > Ben > > Op ma 10 aug. 2020 om 23:03 schreef Rob Spearman < > [email protected]>: > >> 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/6e750bea-6962-0f6c-b161-7e98cbd5c0ce%40digitaliseducation.com > <https://groups.google.com/d/msgid/osg-users/6e750bea-6962-0f6c-b161-7e98cbd5c0ce%40digitaliseducation.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/CAAb_kVY7pJ1iuF0SrE5udD6CN-9xYHYjCAs%2Bh%3DwYDnUqAW0ibg%40mail.gmail.com.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
