Premiere & multi-threading

[Guest]

Q: (copied here from an email exchange I had with Zac)

I’m trying to use an old plug-in that’s an AEX from 2003. It works on Prem Pro but I want to use it in CS3 (coz I have HD footage and Prem Pro can’t do HD). Anyhow it doesn’t work in CS3.

I was stepping through it in the debugger and it looks like it gets called by multiple threads concurrently and it then Stack Overflows and causes an Access Violation.

So, I guess my question is – is CS3 multi-threaded accessing the plugin and did Prem Pro not do that?

My assumption is that the AEX isn’t thread safe or is single core thread safe and can’t handle threads running in parallel on multi-core pcs. (I’ll test setting the affinity of Premiere to one core to see if that fixes parallel-thread execution potential bugs).

If so, what would happen if I make a skeleton AEX that opens this AEX from somewhere out of the Premiere tree, forwards all the calls but only lets one thread in at once?

A: (from Zac via email)

Here’s a good description of what changed in CS3, from the AE SDK Guide:

“Starting with Premiere Pro CS3, Premiere uses multithreaded rendering for AE effects. For AE effects, there is a critical section which is used for all commands, except those relating to arbitrary data. The critical section prevents two threads from calling the same instance of the effect at the same time. However, Premiere creates multiple instances of the effect, which can be called concurrently from separate threads. Effects should not depend on static, non-constant variables.

New in Premiere Pro CS4.1, we have added a new flag to the AE API, PF_OutFlag2_PPRO_DO_NOT_CLONE_SEQUENCE_DATA_FOR_RENDER, to allow a plug-in to opt out of Premiere Pro's multithreaded rendering of AE effects. When the flag is set, we don't clone the sequence data across all the threads and we only call into the plug-in on one thread at a time. Premiere Pro will still render using multiple threads, but the effect will only render on one thread at a time, and the same sequence data will be used. This flag is useful for plug-ins that provide their own internal multithreading, or plug-ins that render frames based on previous frames, such as image stabilizers.”

So for CS3, since we don’t support that new flag in 4.1, your suggested workaround using a shim plug-in just might work.  But it’s hard to say for certain, since we don’t really know what is happening…

Zac

So, I guess the answer is that this old plugin is using statics or globals and is thus not multi-thread capable.

Solution: Get CS4!! 

One for the too-hard basket right now.....

[Zac Lam]

Yep, 4.1 or later could work, but only if the plug-in itself were updated to set the PF_OutFlag2_PPRO_DO_NOT_CLONE_SEQUENCE_DATA_FOR_RENDER flag (as you mentioned in your email).

[david van brink]

Saaay, Zac... I'm wrestling with some reentrancy bugs in my AE Plug-ins just now.

Assuming I set the PF_OutFlag2_PPRO_DO_NOT_CLONE_SEQUENCE_DATA_FOR_RENDER flag, can I depend on a plugin being invoked ONLY from one thread?

Because I have some static members, which are (of course) not reentrant friendly. IF running in a single thread, should the following be safe:

static MyBadGlobals g;

mainproc(in_data & pals)

{

     MyBadGlobals oldGlobals = g;

     ...

     g.this, g.that

     ... all done with my bad globals, restore them

     g = oldGlobals;

}

This appears to now let my plug-in successfully check out a layer that uses the same plug-in... but (apart from globals being bad, which is true) do we think this is actually safe & reliable? Thanks for any insights!

[Steve_Hoeg]

Yes, this flag will cause your plugin to only be called from one thread at a time. We strongly advise against using this flag as it will cause numerous performance issues.

[david van brink]

Thanks for the confirmation.

We strongly advise against using this flag as it will cause numerous performance issues.

Understood.