Data Race in Time Remap around mlt_frame_get_image
#729
Comments
|
Pushed my hack to draft PR #730 for reference. |
fabianschuiki
added a commit
to fabianschuiki/mlt
that referenced
this issue
Aug 22, 2021
Fix an issue in `link_timeremap.c`, where multiple concurrent threads calling `mlt_frame_get_image` would cause the returned image data to be corrupted, or to be consumed incorrectly. As a result, the produced frames would be seemingly arbitrarily corrupted, more so in "blend" mode than in "nearest" mode, due to the increased number of frames fetched. Add a `mlt_service_lock` and `mlt_service_unlock` call around the critical function calls to ensure data returned is intact. Fixes mltframework#729.
bmatherly
pushed a commit
that referenced
this issue
Aug 22, 2021
* Fix data race in time remapping Fix an issue in `link_timeremap.c`, where multiple concurrent threads calling `mlt_frame_get_image` would cause the returned image data to be corrupted, or to be consumed incorrectly. As a result, the produced frames would be seemingly arbitrarily corrupted, more so in "blend" mode than in "nearest" mode, due to the increased number of frames fetched. Add a `mlt_service_lock` and `mlt_service_unlock` call around the critical function calls to ensure data returned is intact. Fixes #729.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I ran into a problem where output frames would be corrupted when using time remapping on some 4K footage. Specifically, the source was a MP4 file, 3840x2160 at 29.8471 Hz, and the rendered output being 30 Hz. The
*.mltI was running came out of akdenliveproject. What I observed was the following:This made me think that it's probably a problem of the data flowing into the time remapping getting corrupted, rather than anything after the remapping. Also, the problem with nearest seemed to mainly appear at the boundary from a sped-up section to a 100% section, and never within the sped-up section. With blend mode the corruption would appear in many more places.
Digging through the code and running a debug build of
meltand speciallylibmltcorewith my own tweaks/hacks, I realized the following: Locking and unlocking apthread_mutexinlink_timeremap.cbeforelink_get_image_blend/link_get_image_nearestwould callmlt_frame_get_imageuntil after the image data has been copied/processed would completely get rid of the problem. This suggests that there might be a data race on the calls tomlt_frame_get_image, where the returned image buffer might be corrupted by a second call to the function in a concurrent thread.I'm not familiar enough with the code base and how it uses threading to know where to look to fix this more properly than my ugly static mutex in the critical parts of the code. Are there any considerations related to this in the design of MLT, or does the time remapping hit a new corner case because it requires more random access to input frames? Would this require adding the ability to lock/unlock the returned image data somehow?
The text was updated successfully, but these errors were encountered: