Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: f7c5638cc68fa2ff34fb9d34e0b416aee1672ddb
https://github.com/WebKit/WebKit/commit/f7c5638cc68fa2ff34fb9d34e0b416aee1672ddb
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-09-21 (Mon, 21 Sep 2026)
Changed paths:
A
LayoutTests/http/tests/media/fairplay/fps-mse-clear-then-encrypted-known-key-expected.txt
A
LayoutTests/http/tests/media/fairplay/fps-mse-clear-then-encrypted-known-key.html
M
Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h
M
Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm
Log Message:
-----------
[MSE/FairPlay] play() promise is never resolved if the content key is already
known
https://bugs.webkit.org/show_bug.cgi?id=324614
rdar://187850389
Reviewed by Youenn Fablet.
Before 301921@main, a source buffer that found an existing CDM session for the
key
IDs of an encrypted initialisation segment set m_waitingForKey to false and
returned
without calling MediaPlayer::waitingForKeyChanged(), so HTMLMediaElement never
ran
the wait for key algorithm and never read MediaPlayer::waitingForKey().
301921@main
made that case notify the player as well.
MediaSourcePrivateAVFObjC::waitingForKey()
is true when any of its source buffers is waiting, and since 205011@main
SourceBufferPrivateAVFObjC::m_waitingForKey was initialised to true, so a source
buffer that never receives protected initialisation data, such as one holding
clear
content, reported waiting for a key for its whole life. When the licence was
acquired
before the encrypted initialisation segment was parsed, the notification
reached an
element that was not blocked on a key: it ran the wait for key algorithm,
lowered its
readyState to HAVE_CURRENT_DATA and stayed there, since the resume branch
requires
waitingForKey() to be false and MediaSourcePrivate's own readyState never
changed.
Playback continued and currentTime advanced, but the playing event never fired
and
play()'s promise was never resolved.
m_waitingForKey now starts false, so it is true only between the renderer
reporting
that a key is needed and that key being provided, which are both already
followed by
a call to MediaPlayer::waitingForKeyChanged().
The test appends clear audio and video and from 1s appends encrypted audio.
Once currentTime reaches encrypted data, we pause and play again. Without the
fix
the readyState after 1s was stuck at HAVE_CURRENT_DATA and when calling play()
the promise wasn't resolved and the playing event wasn't fired: yet playback
would
have progressed.
*
LayoutTests/http/tests/media/fairplay/fps-mse-clear-then-encrypted-known-key-expected.txt:
Added.
*
LayoutTests/http/tests/media/fairplay/fps-mse-clear-then-encrypted-known-key.html:
Added.
*
Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.h:
*
Source/WebCore/platform/graphics/avfoundation/objc/SourceBufferPrivateAVFObjC.mm:
(WebCore::SourceBufferPrivateAVFObjC::didProvideContentKeyRequestInitializationDataForTrackID):
(WebCore::SourceBufferPrivateAVFObjC::setWaitingForKey): Add convenience method.
Canonical link: https://commits.webkit.org/321495@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
