Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: e3f4c5f3c2385953a9def894af1c41276c6f4fee
https://github.com/WebKit/WebKit/commit/e3f4c5f3c2385953a9def894af1c41276c6f4fee
Author: Youenn Fablet <[email protected]>
Date: 2026-04-20 (Mon, 20 Apr 2026)
Changed paths:
A LayoutTests/webrtc/h264-encoder-race-expected.txt
A LayoutTests/webrtc/h264-encoder-race.html
M Source/WebCore/platform/mediastream/libwebrtc/LibWebRTCProvider.h
M Source/WebCore/testing/Internals.cpp
M Source/WebCore/testing/Internals.h
M Source/WebCore/testing/Internals.idl
M Source/WebKit/WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp
M Source/WebKit/WebProcess/GPU/webrtc/LibWebRTCCodecs.h
M Source/WebKit/WebProcess/Network/webrtc/LibWebRTCProvider.cpp
M Source/WebKit/WebProcess/Network/webrtc/LibWebRTCProvider.h
Log Message:
-----------
LibWebRTCCodecs webrtc encoder may fail encoding if a frame is submitted
before its connection is initialized
rdar://174786491
https://bugs.webkit.org/show_bug.cgi?id=312551
Reviewed by Eric Carlson.
There is a race for WebRTC encoder between setting up the encoder (get its IPC
connection in particular) and receving the first frame to encode from the
libwebrtc backend.
If the frame is received before we finished setting up the encoder, we were
sending an encoder error.
The webrtc backend was then trying to switch of encoder which is unexpected.
To prevent that issue, we block the webrtc thread until the setup (done in work
queue mostly) is done with a BinarySemaphore.
As a a way to speed things up, whenever LibWebRTCCodecs::initializeIfNeeded()
is used to ensure that we know whether there is AV1/VP9 HW support,
we set up LibWebRTCCodecs::m_connection. This allows to no longer hop to main
thread for the first encoder of LibWebRTCCodecs.
Covered by a test which ensures that only H264 is used and not VP8 (fallback
encoder).
Canonical link: https://commits.webkit.org/311603@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications