Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: fd129dbc23d11f0970707dddbbd0576c8d2b83a1
https://github.com/WebKit/WebKit/commit/fd129dbc23d11f0970707dddbbd0576c8d2b83a1
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-06-19 (Fri, 19 Jun 2026)
Changed paths:
A
LayoutTests/media/media-source/media-source-audio-priming-no-spurious-gap-expected.txt
A
LayoutTests/media/media-source/media-source-audio-priming-no-spurious-gap.html
M Source/WebCore/platform/graphics/TrackBuffer.cpp
Log Message:
-----------
[314997@main] facebook.com: Audio plays on reels for less than a second
https://bugs.webkit.org/show_bug.cgi?id=317485
rdar://180020210
Reviewed by Youenn Fablet.
After 314997@main tightened TrackBuffer's enqueue discontinuity tolerance
from a hardcoded 1s down to MediaSource::timeFudgeFactor() (≈83ms),
playback of HE-AAC content carrying encoder priming died after the first
audio sample reached the renderer.
The bug was upstream of the tolerance change; tightening the tolerance
just exposed it.
A primed AAC sample is exposed to the engine with `dts < pts`: the
decode timeline is shifted earlier by the priming duration so the decoder
can run-up to the first displayable PCM frame at pts=0. The sample's
reported `duration` is the post-trim presentation span — only the audible
portion — so `dts + duration` lands `priming` seconds short of the
sample's true decode-end. The next contiguous sample's DTS, which is
authored at the previous sample's true decode-end (= presentationEndTime
under the AAC priming convention), then looked like it sat past a gap.
`TrackBuffer::nextSample` had been anchoring its discontinuity boundary
on `dts + duration + tolerance`, which is correct only when `dts == pts`.
For primed audio it underestimated the boundary by the priming amount.
The 1s tolerance happened to absorb that error; 83ms didn't. Once the
check rejected the next sample, recovery was impossible: the rejected
sample sat at the front of the decode queue and only `nextSample`'s
success path advanced the boundary, so every subsequent
`reenqueueMediaIfNeeded` re-tested the same sample against the same
stale boundary and bailed again. Audio was dead until a seek.
Anchor the boundary on whichever endpoint is later — `dts + duration` or
`presentationEndTime` — so primed samples report their true decode-end.
For unprimed samples the two are equal and behavior is unchanged. No
other site that consumes `MediaSample::duration()` is touched, so
buffered-range, append-window, and coded-frame-processing semantics
remain in their presentation-domain meaning.
* Source/WebCore/platform/graphics/TrackBuffer.cpp:
(WebCore::TrackBuffer::nextSample):
*
LayoutTests/media/media-source/media-source-audio-priming-no-spurious-gap.html:
Added.
*
LayoutTests/media/media-source/media-source-audio-priming-no-spurious-gap-expected.txt:
Added.
Canonical link: https://commits.webkit.org/315532@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
