Frei0r plugins and parallel processing

Help/How To
1

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.

2

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.

1 Like
3

I’m trying to wrap my head around the way parallelism works here. Forgive me for being naive, but would it not be possible to encode the thread id in the ctorname here: https://github.com/mltframework/mlt/blob/95e36b9c3e2f91fd8a03cb683d657149aa4e48df/src/modules/frei0r/frei0r_helper.c#L105

Threads are long-lived (I hope) so that would scope each frei0r instance to a single thread, and get us de-facto MP-safe frei0r?

4

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.

1 Like
5

Thanks!

6

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?

7

Just as an FYI, I use OpenMP inside the frei0r plugin to do multithreaded rendering: https://bitbucket.org/leo_sutic/bigsh0t/src/6a2770cfae126038ec5fb7af151c2b620400b6e5/src/main/cpp/MPFilter.cpp#lines-13

It’s the only way I can think of to use MP and still obey the frei0r interface (due to the restriction of one calling thread per instance): https://github.com/dyne/frei0r/blob/master/include/frei0r.h#L169

8

Everything except below

The next version includes a number of time-based effect filters, but only nervous and vertigo from this list. Some other things in this list are already in Open Other.

If I understand, this adjustment should make those filters perform faster during previewing?

Only when Realtime is turned off in Settings.

9

Filters that depend on previous frames (store one or more frames to be used for a subsequent frame) or generators that automatically change over time.

10

This topic was automatically closed after 90 days. New replies are no longer allowed.