Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 4d9d9d1b5628b25af82d57f5b38fc0c82360f534
https://github.com/WebKit/WebKit/commit/4d9d9d1b5628b25af82d57f5b38fc0c82360f534
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-04-02 (Thu, 02 Apr 2026)
Changed paths:
M Source/WebCore/platform/MediaStrategy.h
M Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm
M Source/WebKit/WebProcess/GPU/GPUProcessConnection.h
M Source/WebKit/WebProcess/GPU/media/WebMediaStrategy.cpp
M Source/WebKit/WebProcess/GPU/media/WebMediaStrategy.h
M Source/WebKit/WebProcess/GPU/webrtc/LibWebRTCCodecs.cpp
Log Message:
-----------
REGRESSION (307242@main): YouTube takes longer to load a page
https://bugs.webkit.org/show_bug.cgi?id=311304
rdar://172104196
Reviewed by Youenn Fablet.
A race condition in VP9 codec capability reporting caused a ~60% YouTube page
load regression when
MediaContainmentEnabled was on.
Root cause: When a new WebContent process was created, YouTube's JS called
MediaSource.isTypeSupported("video/webm;
codecs=vp9") before the GPU process had delivered its VP9 hardware decoder
capability via
GPUProcessConnection::didInitialize. The WebContent process checked
VTIsHardwareDecodeSupported(VP9) locally, which
returned false (VP9 hardware decoding is only available in the GPU process
after supplemental decoder registration).
VP9 was incorrectly reported as unsupported, the result was cached, and YouTube
fell back to H.264.
With MediaContainmentEnabled off, this didn't happen because the MSE pipeline
ran in the GPU process where VP9 was
directly available.
The benchmark tools had content cached for mp4/h264 but didn't for webm/vp9 so
we ended up comparing
two different things: one where the page had no video content of any kind, and
one where the videos were loaded.
* Source/WebCore/platform/MediaStrategy.h: Added virtual void
ensureCodecsSupportChecksInitialized()
* Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.h: Added
isVP9HardwareDecoderAvailabilityKnown()
* Source/WebCore/platform/graphics/cocoa/VP9UtilitiesCocoa.mm:
(WebCore::vp9HardwareDecoderAvailable): Added fallback when VP9 availability is
unknown, waiting for the GPU process initialisation as needed.
(WebCore::VP9TestingOverrides::setVP9HardwareDecoderEnabledOverride): rename
argument, it was misnamed as disabled, when it meant the opposite.
* Source/WebKit/WebProcess/GPU/GPUProcessConnection.h: Make waitForDidInitialize
* Source/WebKit/WebProcess/GPU/media/WebMediaStrategy.cpp:
(WebKit::WebMediaStrategy::ensureCodecsSupportChecksInitialized): we ensure the
GPU connection
has been created and initialised. We follow the same pattern as
LibWebRTCCodecs::initializeIfNeeded().
(WebKit::WebMediaStrategy::canDecodeExtendedType): Fly-By, if the method was
called prior the GPU connection being available,
we would have exited early before signaling the semaphore, causing a deadlock
* Source/WebKit/WebProcess/GPU/media/WebMediaStrategy.h:
(WebKit::LibWebRTCCodecs::initializeIfNeeded): Make use of
waitForDidInitialize, auditToken() was used as a workaround to access
waitForDidInitialize.
Canonical link: https://commits.webkit.org/310474@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
