Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 0e4cfc6b8f5fa42166bb9e05a7e4ed227ec91f79
      
https://github.com/WebKit/WebKit/commit/0e4cfc6b8f5fa42166bb9e05a7e4ed227ec91f79
  Author: Jean-Yves Avenard <j...@apple.com>
  Date:   2025-01-10 (Fri, 10 Jan 2025)

  Changed paths:
    A LayoutTests/media/video-currenttime-monotonic-expected.txt
    A LayoutTests/media/video-currenttime-monotonic.html
    M LayoutTests/platform/mac-wk1/TestExpectations
    M Source/WebCore/WebCore.order
    M Source/WebCore/html/HTMLMediaElement.cpp
    M Source/WebCore/html/HTMLMediaElement.h
    M Source/WebCore/platform/graphics/MediaPlayer.cpp
    M Source/WebCore/platform/graphics/MediaPlayer.h
    M Source/WebCore/platform/graphics/MediaPlayerPrivate.h
    M Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp
    M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp
    M Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h
    M Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerConfiguration.h
    M 
Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerConfiguration.serialization.in

  Log Message:
  -----------
  Playing video in Safari can generate non-monotonic 'timeupdate' events
https://bugs.webkit.org/show_bug.cgi?id=285656
rdar://142275184

Reviewed by Eric Carlson.

When playback is about to start, a rateChanged notification is being sent
by the MediaPlayer running in the GPU process, followed shortly by 
currentTimeChanged
once playback has actually started.
The MediaPlayerPrivateRemote started to estimate the time progress upon
receiving the rateChanged notification only to go back to zero once again
following the currentTimeChanged update ; making the currentTime value go
backward.
We now stop estimating the currentTime progress when we get notified of
a rate change, returning the cached time instead until the next 
currentTimeChanged.

While testing, an additional issue was exposed, where currentTime could 
temporarily
exceed the video's duration, only to go back to be exactly the duration
once playback actually ended.
The HTMLMediaElement was also estimating the currentTime progress in an attempt
to reduce the number of calls to MediaPlayer::currentTime().
This estimation was occurring whenever the 
MediaPlayerPrivate::maximumDurationToCacheMediaTime
returned a value greater than 0, the default value being 0 (so no estimate was 
to occur
and the HTMLMediaElement was to always query the MediaPlayer's currentTime)
The only MediaPlayerPrivate overriding maximumDurationToCacheMediaTime
was the MediaPlayerPrivateRemote which set a value of 0.2s.
The MediaPlayerPrivateRemote is already estimating the currentTime, there's
as such no benefit for the HTMLMediaElement to cache the time and also
estimate the progress.
Due to the above, the time estimation found in the HTMLMediaElement was dead
code until the MediaPlayerPrivateRemote was introduced, only to be revived
unnecessarily.
It could also incorrectly report the time being greater than the video's element
if the currentTime was ever read after 
(duration-maximumDurationToCacheMediaTime).

We can remove the handling of cache time in the HTMLMediaElement as it 
introduced
error and was redundant over the MediaPlayerPrivateRemote's own estimation.

Added a test.

* LayoutTests/media/video-currenttime-monotonic-expected.txt: Added.
* LayoutTests/media/video-currenttime-monotonic.html: Added.
* Source/WebCore/WebCore.order:
* Source/WebCore/html/HTMLMediaElement.cpp: Remove all code related to 
estimating the currentTime from the last time m_cachedTime had been updated.
(WebCore::HTMLMediaElement::prepareForLoad):
(WebCore::HTMLMediaElement::mediaPlayerReloadAndResumePlaybackIfNeeded):
(WebCore::HTMLMediaElement::setReadyState):
(WebCore::HTMLMediaElement::fastSeek):
(WebCore::HTMLMediaElement::seekWithTolerance):
(WebCore::HTMLMediaElement::clearSeeking):
(WebCore::HTMLMediaElement::invalidateOfficialPlaybackPosition):
(WebCore::HTMLMediaElement::currentMediaTime const):
(WebCore::HTMLMediaElement::setPlaybackRate):
(WebCore::HTMLMediaElement::playInternal):
(WebCore::HTMLMediaElement::mediaPlayerTimeChanged):
(WebCore::HTMLMediaElement::mediaPlayerRateChanged):
(WebCore::HTMLMediaElement::updatePlayState):
(WebCore::HTMLMediaElement::refreshCachedTime const): Deleted.
(WebCore::HTMLMediaElement::invalidateCachedTime const): Deleted.
* Source/WebCore/html/HTMLMediaElement.h:
* Source/WebCore/platform/graphics/MediaPlayer.cpp:
(WebCore::MediaPlayer::maximumDurationToCacheMediaTime const): Deleted.
* Source/WebCore/platform/graphics/MediaPlayer.h:
* Source/WebCore/platform/graphics/MediaPlayerPrivate.h:
(WebCore::MediaPlayerPrivateInterface::maximumDurationToCacheMediaTime const): 
Deleted.
* Source/WebKit/GPUProcess/media/RemoteMediaPlayerProxy.cpp:
(WebKit::RemoteMediaPlayerProxy::getConfiguration):
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.cpp:
(WebKit::MediaPlayerPrivateRemote::TimeProgressEstimator::currentTimeWithLockHeld
 const):
Ensure to only return a new time value if it has actually progressed since the 
last call.
Small time drifts can occur between the GPU and WebContent process.
(WebKit::MediaPlayerPrivateRemote::TimeProgressEstimator::setTime):
(WebKit::MediaPlayerPrivateRemote::seeked):
(WebKit::MediaPlayerPrivateRemote::timeChanged):
(WebKit::MediaPlayerPrivateRemote::rateChanged):
(WebKit::MediaPlayerPrivateRemote::playbackStateChanged):
(WebKit::MediaPlayerPrivateRemote::currentTimeChanged):
(WebKit::MediaPlayerPrivateRemote::maximumDurationToCacheMediaTime const): 
Deleted.
* Source/WebKit/WebProcess/GPU/media/MediaPlayerPrivateRemote.h:
* Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerConfiguration.h:
* 
Source/WebKit/WebProcess/GPU/media/RemoteMediaPlayerConfiguration.serialization.in:

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



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to