[webkit-changes] [WebKit/WebKit] 5023d7: [MSE][GStreamer] Deadlock while flushing on paused...

[Enrique Ocaña González]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 5023d703877c9e6026b3406fa6d97f74f0dea356
      https://github.com/WebKit/WebKit/commit/5023d703877c9e6026b3406fa6d97f74f0dea356
  Author: Enrique Ocaña González <eocanha at igalia.com>
  Date:   2023-08-25 (Fri, 25 Aug 2023)

  Changed paths:
    M Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp

  Log Message:
  -----------
  [MSE][GStreamer] Deadlock while flushing on paused when there's a non in-place transform element
https://bugs.webkit.org/show_bug.cgi?id=260067

Reviewed by Alicia Boya Garcia.

There is a deadlock possible inside WebKit media src (MSE) between streaming thread handling
CAPS event and pipeline flush in the main thread. This happens in case where there is a
transform element in the pipeline that does transition NOT in place. Basetransform elem
expects that it will allocate buffers so on CAPS change it triggers allocation negotiations
(ALLOCATION query). In such case CAPS event becomes fully synchronous as basetransform does
ALLOCATION query that is synchronous (serialized with data) and may block the streaming
thread. If the pipeline is paused and the sink thread doesn't accept any data, this will
block CAPS event until pipeline is unpaused or flushed. But flush requires a lock that
streaming thread is holding (DataMutexLocker streamingMembers {
stream->streamingMembersDataMutex };)

See: https://github.com/WebPlatformForEmbedded/WPEWebKit/issues/1135

A way to fix this is to make webKitMediaSrcLoop() release the lock before pushing the caps
event (which may take a long time to get processed) to let the main thread start the flush.
Such a flush would cause the sink element to release the streaming thread and the caps event
processing to finish. After the caps event has been pushed, the lock would be retaken. But
streamingMembers might have changed under our feet (and it certainly will, because of the
flush). We should reevaluate if the flush condition is present, and in that case abort the
execution of webKitMediaSrcLoop() after having paused the streaming task of the
corresponding pad.

* Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
(webKitMediaSrcLoop): Run the caps pushing code with the lock released and reevaluate the flush condition after the lock is reacquired.

Canonical link: https://commits.webkit.org/267276@main