Multi-threaded FFMPEG accesses crash (Bugfix #1369)


Added by sebastien wybo over 13 years ago. Updated about 12 years ago.


Status:Done Start date:
Priority:Normal Due date:
Assignee:Vadim Pisarevsky % Done:

0%

Category:highgui-video
Target version:2.4.4
Affected version:2.4.2 Operating System:
Difficulty: HW Platform:
Pull request:

Description

Having multiple threads perform simultaneous video files read/writes ends up crashing the program when openCV_ffmpeg.dll is used on windows. Could be insufficient thread protection around key ffmpeg data.
No issue appears when ffmpeg dll is absent from system.


sjbyun-ffmpeg-patch.patch (2.3 kB) Sung-Joo Byun, 2012-07-03 04:02 am


Issue hierarchy

Patch #1352: make videowriter multi-thread compatibleDoneVadim Pisarevsky

Bugfix #1369: Multi-threaded FFMPEG accesses crashDoneVadim Pisarevsky


Related issues

duplicated by Bug #1006: VideoCapture Constructor concurrency bug Cancelled

Associated revisions

Revision 88cc054f
Added by Roman Donchenko over 11 years ago

Merge pull request #1369 from StevenPuttemans:fix_featuretracker

History

Updated by Vadim Pisarevsky over 13 years ago

hello, can you provide a sample code that reproduces the problem?

Updated by sebastien wybo over 13 years ago

don't have a publishable code right now (i'll try to provide one by week's end)
basically having 2 or more threads doing :
lock shared video reader mutex
read video file
unlock mutex

process

lock shared video writer mutex
write video file
unlock mutex

threads access different video files (no conflict on same file) and share video reader and writer mutex

this is done in an almost infinite loop and crash can happen after 10 to thousands of iteration where a new thread is created to replace one that has finished

If no mutexes used crash happens much faster
With mutexes crash happens randomly
with same mutex for read AND write => no crash

So currently the workaround is sharing one mutex over all threads but this is a very restrictive bottleneck

Updated by Vadim Pisarevsky over 13 years ago

since it's easy to insert synchronization calls into user's code, I lower priority of the bug

Updated by Alexander Shishkov almost 13 years ago

  • Target version deleted ()

Updated by Alexander Shishkov almost 13 years ago

  • Priority changed from High to Normal
  • Subproject of set to #1352

Updated by Alexander Shishkov almost 13 years ago

  • Priority changed from Normal to Low

Updated by Alexander Shishkov almost 13 years ago

  • Assignee deleted (Vadim Pisarevsky)

Updated by Alexander Shishkov almost 13 years ago

  • Target version deleted ()

Updated by Sung-Joo Byun over 12 years ago

Have you ever beein tring av_lockmgr_register()?
It is ffmpeg's lock mechanism().

Updated by Sung-Joo Byun over 12 years ago

attach my linux/win32 patch

  • File sjbyun-ffmpeg-patch.patch added

Updated by Andrey Kamaev over 12 years ago

  • Category changed from highgui-images to highgui-video

Updated by Vadim Pisarevsky over 12 years ago

looks like this is the solution for several other similar tickets

  • Target version deleted ()
  • Tracker changed from Bug to Patch

Updated by Ilya Lavrenov over 12 years ago

  • Assignee set to Ilya Lavrenov

Updated by Kirill Kornyakov over 12 years ago

  • Target version set to Next Hackathon

Updated by Jonatan Lindberg over 12 years ago

Is it possible to include this in the final 2.4.3 release?

Updated by Kirill Kornyakov over 12 years ago

Let's consider this for 2.4.4

  • Target version changed from Next Hackathon to 2.4.4
  • Priority changed from Low to Normal
  • Tracker changed from Patch to Bugfix

Updated by Andrey Kamaev about 12 years ago

Vadim, fix for this issue is already pushed, isn't it?

  • Assignee changed from Ilya Lavrenov to Vadim Pisarevsky

Updated by Vadim Pisarevsky about 12 years ago

looks like we fixed the problem, just need to verify

  • Target version deleted (2.4.4)

Updated by Vadim Pisarevsky about 12 years ago

  • Assignee deleted (Vadim Pisarevsky)

Updated by Vadim Pisarevsky about 12 years ago

  • Assignee set to Vadim Pisarevsky

Updated by Vadim Pisarevsky about 12 years ago

the problem should have been solved in 2.4.3. At least 2.4 branch should handle that well.

  • Affected version set to 2.4.2
  • Status changed from Open to Done

Updated by Kirill Kornyakov about 12 years ago

  • Target version set to 2.4.4

Also available in: Atom PDF