DRM
July 6, 2021, 6:58pm
21
Try again but make sure the Image Mode is set to Blend. Then export it once with Parallel Processing on and once with it off. What are your results?
DRM
August 1, 2021, 3:12pm
22
@brian , did you get to try the above? I’m bringing it up again to see if it can get fixed in time for this month’s release.
brian
August 1, 2021, 5:41pm
23
I have not successfully reproduced the issue. Can you privately provide me a package that reproduces the problem?
MLT project
Referenced media
Export job XML
DRM
August 13, 2021, 12:54am
24
@shotcut , I want to ask you if this is the kind of bug that could be fixed for the upcoming release. I haven’t supplied Brian what he’s asking for yet but I want to know first if I do it soon and he could fix it then if that fix could be included in the release that’s coming up. It is an export bug so I imagine so but I want to just confirm.
brian
August 13, 2021, 1:45am
25
It would depend on the nature of the fix. If the fix is simple and low risk, then it can be included. If the fix is complex and risky, then it would wait for the next release and more testing since we already have a work-around.
brian
August 21, 2021, 1:18pm
26
@DRM have you had a chance to provide a test project? It would be great if I could reproduce this to fix it. Thanks!
brian
August 22, 2021, 9:22pm
27
Good news. Another users has reproduced this issue and submitted a fix for the 21.08 release:
opened 06:02PM - 22 Aug 21 UTC
closed 09:14PM - 22 Aug 21 UTC
resolved
I ran into a problem where output frames would be corrupted when using time rema… pping on some 4K footage. Specifically, the source was a MP4 file, 3840x2160 at 29.8471 Hz, and the rendered output being 30 Hz. The `*.mlt` I was running came out of a `kdenlive` project. What I observed was the following:
- *Nearest* mode: Single frames would be corrupted (mostly greenish, arbitrary patterns, looked like something partially decoded)
- *Blend* mode: Looked like corrupted frames would be interpolated/blended with non-corrupted frames
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 `melt` and specially `libmltcore` with my own tweaks/hacks, I realized the following: Locking and unlocking a `pthread_mutex` in `link_timeremap.c` before `link_get_image_blend`/`link_get_image_nearest` would call `mlt_frame_get_image` until 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 to `mlt_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?