I’ve seen some odd behavior in my frei0r plugins when exporting video using parallel processing. In short, it seems like Shotcut is rendering multiple frames in parallel but only using one frei0r filter instance across all threads, because when the filter parameters are driven by keyframes they change mid-frame, resulting in tearing. I say “seems” because I can’t prove it - but the evidence so far points that way and I thought I’d tell you sooner rather than later.
Due to the way the frei0r interface works it’s not possible to fix this using mutexes inside the filter. While it’s possible to disallow parameter updates while rendering render, the filter itself can’t guarantee that all parameter updates already received are for the same frame. (Imagine two threads setting filter parameters concurrently - the filter could end up with half the parameters set by one thread, half by another, and no way to figure out what the proper values are.)
Turning off parallel processing fixes the issue, but it would of course be nice to have my filters working irrespective of the parallel processing setting.
Yes, I should try to make a change to block threads when any property is animated. This is a big set back for parallelism, unfortunately. MLT does have support for slice-based threading over frei0r, but it is limited to vertical resolutions that are a strict multiple of the slice height due to the frei0r interface. Also, many plugins are simply incompatible leaving artifacts.
Yes, that is a good idea! Thank you for the tip. Of course, some time-based effects are still not safe and will continue to be blacklisted against frame threading. I will have a beta out in a few days with this change for you to test.
I don’t understand exactly what “time-based effects” means. What kinds of filters will now have frame threading and which ones won’t? If I understand, this adjustment should make those filters perform faster during previewing?