Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 5ea7a3e8bb2642b63db04940f99093c73997f9cf
https://github.com/WebKit/WebKit/commit/5ea7a3e8bb2642b63db04940f99093c73997f9cf
Author: Jean-Yves Avenard <[email protected]>
Date: 2025-04-25 (Fri, 25 Apr 2025)
Changed paths:
M Source/WebCore/PAL/pal/cf/CoreMediaSoftLink.cpp
M Source/WebCore/PAL/pal/cf/CoreMediaSoftLink.h
M Source/WebCore/platform/graphics/cocoa/VideoMediaSampleRenderer.h
M Source/WebCore/platform/graphics/cocoa/VideoMediaSampleRenderer.mm
Log Message:
-----------
Decoding should continue until we have set time ahead.
https://bugs.webkit.org/show_bug.cgi?id=291894
rdar://149756577
Reviewed by Jer Noble.
In 293860@main we decoded 3 or 10 frames ahead of currentTime depending on the
video decoder being hardware accelerated.
We now use a time (133ms) base instead, similar to what CoreMedia does but with
a minimum of 3 frames.
Additionally, we immediately enqueue the decoded video frame in the
AVSampleBufferDisplayLayer or AVSampleBufferVideoRenderer as soon as
it is available, letting it handle frame re-ordering as needed.
The time accuracy required for requestVideoFrameCallback and readbacks
is now only approximated so that we can preserve smoother video delivery
under heavy load.
The requirement for accurate timers as such is reduced and when the purge
task is enqueued become less important as it is no longer responsible for
ensuring that the next frame is displayed on time.
In order to ensure that frames are re-ordered accurately, the decode ahead
limit is ignored if B-frame are found in the incoming compressed samples queue.
Dropped frame calculation continues to be based on our own internal timers
rather than what the AVSampleBufferDisplayLayer did or did not drop due to:
1- We don't have an accurate way to properly determine if it did.
2- Dropped frames report is used by web sites to determine if the user
machine is under heavy load and reduce or increase the content resolution
accordingly. This goal is achieved as scheduling our purge tasks are more
likely to be impacted by heavy usage.
Covered by existing tests.
* Source/WebCore/PAL/pal/cf/CoreMediaSoftLink.cpp:
* Source/WebCore/PAL/pal/cf/CoreMediaSoftLink.h:
* Source/WebCore/platform/graphics/cocoa/VideoMediaSampleRenderer.h:
* Source/WebCore/platform/graphics/cocoa/VideoMediaSampleRenderer.mm:
(WebCore::VideoMediaSampleRenderer::lastDecodedSampleTime const):
(WebCore::VideoMediaSampleRenderer::hasIncomingOutOfOrderFrame const):
(WebCore::VideoMediaSampleRenderer::setTimebase):
(WebCore::VideoMediaSampleRenderer::decodeNextSampleIfNeeded):
(WebCore::VideoMediaSampleRenderer::decodedFrameAvailable):
(WebCore::VideoMediaSampleRenderer::maybeQueueFrameForDisplay):
(WebCore::VideoMediaSampleRenderer::cancelTimer):
(WebCore::VideoMediaSampleRenderer::purgeDecodedSampleQueue):
(WebCore::VideoMediaSampleRenderer::purgeDecodedSampleQueueUntilTime):
(WebCore::VideoMediaSampleRenderer::schedulePurgeAtTime):
(WebCore::VideoMediaSampleRenderer::maybeReschedulePurge):
(WebCore::VideoMediaSampleRenderer::copyDisplayedPixelBuffer):
(WebCore::VideoMediaSampleRenderer::maximumDecodedSampleCount const): Deleted.
(WebCore::VideoMediaSampleRenderer::purgeDecodedSampleQueueAndDisplay): Deleted.
(WebCore::VideoMediaSampleRenderer::schedulePurgeAndDisplayAtTime): Deleted.
(WebCore::VideoMediaSampleRenderer::maybeReschedulePurgeAndDisplay): Deleted.
Canonical link: https://commits.webkit.org/294144@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
