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 |
History
Updated by Vadim Pisarevsky over 1 year ago
hello, can you provide a sample code that reproduces the problem?
Updated by sebastien wybo over 1 year 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 1 year ago
since it's easy to insert synchronization calls into user's code, I lower priority of the bug
Updated by Alexander Shishkov about 1 year ago
- Target version deleted ()
Updated by Alexander Shishkov about 1 year ago
- Subproject of set to #1352
- Priority changed from High to Normal
Updated by Alexander Shishkov about 1 year ago
- Priority changed from Normal to Low
Updated by Alexander Shishkov about 1 year ago
- Assignee deleted (
Vadim Pisarevsky)
Updated by Alexander Shishkov about 1 year ago
- Target version deleted ()
Updated by Sung-Joo Byun 12 months ago
Have you ever beein tring av_lockmgr_register()?
It is ffmpeg's lock mechanism().
Updated by Sung-Joo Byun 12 months ago
attach my linux/win32 patch
- File sjbyun-ffmpeg-patch.patch added
Updated by Andrey Kamaev 10 months ago
- Category changed from highgui-images to highgui-video
Updated by Vadim Pisarevsky 9 months 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 8 months ago
- Assignee set to Ilya Lavrenov
Updated by Kirill Kornyakov 8 months ago
- Target version set to Next Hackathon
Updated by Jonatan Lindberg 8 months ago
Is it possible to include this in the final 2.4.3 release?
Updated by Kirill Kornyakov 7 months ago
Let's consider this for 2.4.4
- Priority changed from Low to Normal
- Target version changed from Next Hackathon to 2.4.4
- Tracker changed from Patch to Bugfix
Updated by Andrey Kamaev 6 months ago
Vadim, fix for this issue is already pushed, isn't it?
- Assignee changed from Ilya Lavrenov to Vadim Pisarevsky
Updated by Vadim Pisarevsky 5 months ago
looks like we fixed the problem, just need to verify
- Target version deleted (
2.4.4)
Updated by Vadim Pisarevsky 5 months ago
- Assignee deleted (
Vadim Pisarevsky)
Updated by Vadim Pisarevsky 5 months ago
- Assignee set to Vadim Pisarevsky
Updated by Vadim Pisarevsky 5 months 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 4 months ago
- Target version set to 2.4.4