Multi-threaded FFMPEG accesses crash (Bugfix #1369)
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.
Issue hierarchy
Related issues
duplicated by Bug #1006: VideoCapture Constructor concurrency bug | Cancelled |
Associated revisions
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