Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: b085257c068dc4c2281ad00aa3c026353a5bbdde
https://github.com/WebKit/WebKit/commit/b085257c068dc4c2281ad00aa3c026353a5bbdde
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-06-10 (Wed, 10 Jun 2026)
Changed paths:
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/graphics/SourceBufferPrivate.cpp
Log Message:
-----------
[MSE] Make the gap detection logic in SourceBuffer::provideMediaData() less
arbitrary.
https://bugs.webkit.org/show_bug.cgi?id=135867
rdar://179195556
Reviewed by Jer Noble.
The MediaPlayerPrivateMediaSource has been stalling when reaching a gap larger
than
MediaSource::timeFudgeFactor() for a while.
The PlatformTimeRanges also removed gaps lower than 2002/24000 since 266357@main
Yet, TrackBuffer would enqueue samples past a 1s gap. This caused the
AVSampleBufferRenderSynchronizer
and its associated AVSampleBufferAudioRenderer to continue to progress in
time even though the intent was to made it stall at the timeFudgeFactor() gap.
We eliminate this use of an arbitrary value of 1s and instead make the use of
the
MediaSource::timeFudgeFactor() uniform for both stall detection logic and
when to stop enqueuing samples past such gap.
In a future change, we will relax this gap detection to be more aligned
with what Firefox (250ms) and Chrome are doing (500ms) when ignoring gaps.
Our use of 2002/24000 is extremely conservative (even if technically, any gaps
should stall per specs).
Covered by existing tests.
* Source/WebCore/platform/graphics/SourceBufferPrivate.cpp:
(WebCore::SourceBufferPrivate::addTrackBuffer):
Canonical link: https://commits.webkit.org/314997@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
