I understand that adding more locks increases the mental burden, but I think this is worse—sure, we're "reusing" a lock that was going to be created anyway, but it's still effectively introducing another lock, plus now this requires us to understand when GStreamer is going to implicitly take that lock.
Regarding the lock, it's not really about the mental burden but about actual deadlock situations. It's happening already in many cases in winegstreamer and I don't want to make it worse.
Adding a new lock to the wg_transform is just calling for trouble. It may be fine for this very case, to guard the output_wg_sample pointer updates, and as long as it stays used for this only, but having a lock in the wg_transform makes it appealing to use it for guarding more things in the future. I don't want to introduce that opportunity.
The interlocked pointer exchange is guaranteeing the same thing as an explicit lock, except that it cannot cause any deadlock. I've made an update to the MR, keeping it as I think it's the best solution, but moving the sample size check to the allocator, to also simplify the wg_transform callback.
Retrospectively, I agree that using the GStreamer object lock for the allocator locking is a bit risky as well, so I'll leave this aside too.