This sort of reverts 096da45036959e57ae3aa5b0de0c06f69c651788. The deadlock mentioned there is not spelled out in detail, but likely results from the streaming thread trying to acquire the filter lock while a main thread which is holding the filter lock waits for the streaming thread to finish. However, DirectShow documentation (and manual testing) suggests that the correct way to avoid this problem is simply to never take the filter lock from the streaming thread. Since we currently don't do this anymore, it should be safe to reinstate this lock.
Signed-off-by: Zebediah Figura z.figura12@gmail.com --- dlls/winegstreamer/gsttffilter.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/dlls/winegstreamer/gsttffilter.c b/dlls/winegstreamer/gsttffilter.c index 9ff5f8741d..ee1851dfdc 100644 --- a/dlls/winegstreamer/gsttffilter.c +++ b/dlls/winegstreamer/gsttffilter.c @@ -272,9 +272,7 @@ static HRESULT WINAPI Gstreamer_transform_ProcessEnd(TransformFilter *iface)
mark_wine_thread();
- LeaveCriticalSection(&This->tf.csReceive); ret = gst_element_set_state(This->filter, GST_STATE_READY); - EnterCriticalSection(&This->tf.csReceive); TRACE("Returned: %i\n", ret); return S_OK; }