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
My proposal for 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.
Pull request: https://github.com/WebKit/WebKit/pull/16603
Committed 267276@main (5023d703877c): <https://commits.webkit.org/267276@main> Reviewed commits have been landed. Closing PR #16603 and removing active labels.
<rdar://problem/114447153>