Re: [osg-users] FFmpegImageStream thread safety

[OpenSceneGraph Users]

Hi Rob,

Ok, thanks for your responses.

Cheers,

Ben

Op di 11 aug. 2020 om 17:21 schreef Robert Spearman <
r...@digitaliseducation.com>:

>
> 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 <
> r...@digitaliseducation.com>:
>
>> 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 bjs.me...@gmail.com 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 >> >:
>>>
 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 bjs.me...@gmail.com 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 osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/6e750bea-6962-0f6c-b161-7e98cbd5c0ce%40digitaliseducation.com
> 
> .
>

-- 
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 osg-users+unsubscr...@googlegroups.com.
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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FFmpegImageStream thread safety

[OpenSceneGraph Users]

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 
mailto:r...@digitaliseducation.com>>:


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 bjs.me...@gmail.com
 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
:

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
bjs.me...@gmail.com 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 osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/6e750bea-6962-0f6c-b161-7e98cbd5c0ce%40digitaliseducation.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FFmpegImageStream thread safety

[OpenSceneGraph Users]

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 :

> 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 bjs.me...@gmail.com 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 > >:
>>
>>> 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 bjs.me...@gmail.com 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 osg-users+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/osg-users/386b2bdb-9924-4d01-bc42-98565c685ac0n%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenSceneGraph Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/osg-users/lQrji5HiDtM/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/89d17cce-a8a9-4c8a-a347-c5a47fc7e8c5n%40googlegroups.com
> 
> .
>

-- 
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 osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAAb_kVYyH5zD25bjX4FzANwc9CkgbysLhRtGTmGzVR0_vGPKmg%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FFmpegImageStream thread safety

[OpenSceneGraph Users]

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 bjs.me...@gmail.com 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 :
>
>> 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 bjs.me...@gmail.com 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 osg-users+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osg-users/386b2bdb-9924-4d01-bc42-98565c685ac0n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 osg-users+unsubscr...@googlegroups.com.
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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FFmpegImageStream thread safety

[OpenSceneGraph Users]

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 :

> 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 bjs.me...@gmail.com 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 osg-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/osg-users/386b2bdb-9924-4d01-bc42-98565c685ac0n%40googlegroups.com
> 
> .
>

-- 
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 osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAAb_kVbvYb1_YyMkt55%2BeTFCCRkzMW_BQuTpTohPA21%2B81E7EA%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] FFmpegImageStream thread safety

[OpenSceneGraph Users]

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 bjs.me...@gmail.com 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 osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/386b2bdb-9924-4d01-bc42-98565c685ac0n%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org