Hi Garret, Thanks for reporting this issue, I'm afraid I can't add anything to the mix as I'm not too familiar with ffmpeg. However, it does sounds like we'll also need to protect some or all of ffmpeg calls. I'll have a look through the ffmpeg and have a think about how to tackle this is a manageable way.
Cheers, Robert. On Thu, Dec 31, 2009 at 3:03 PM, Garrett Potts <[email protected]> wrote: > Hello All: > > Just recently I have been testing ffmpeg library (Not OSG's ffmpeg plugin) > use within some tools we are doing. Over the past couple of days we have > been hammering video in a multi threaded environment and it has come to our > attention that ffmpeg is not thread safe. I have not locked down where in > ffmpeg it uses global structures besides the registerall calls. In our code > we had to do a shared mutex lock on all calls to the ffmpeg library. So for > instance a call to avcodec_open could fail if you are doing a code decode at > the same time. > > Example: > > When we were grabbing a frame from one file and opening another file the > open could fail which gave strong indication of shared global data within > ffmpeg. After lock down with a comon critical section mutex we were able to > use the ffmpeg in a multi threaded environment. > > > I wanted to pass this along because I have seen the ffmpeg plugin added to > OSG. > > > If anyone knows the exact API calls or found docs specifying the exact calls > in ffmpeg library that is not thread safe please pass it along. For now, I > have just wrapped all calls as critical and everything works robustly in a > multi threaded environment. > > > Take care > > Garrett > > _______________________________________________ > 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
