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
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
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,
>
>
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
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
6 matches
Mail list logo
