Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: aaf48ddc8e5c2f8b6d28b2554803830a3231353b
https://github.com/WebKit/WebKit/commit/aaf48ddc8e5c2f8b6d28b2554803830a3231353b
Author: Jean-Yves Avenard <[email protected]>
Date: 2026-02-27 (Fri, 27 Feb 2026)
Changed paths:
M LayoutTests/platform/ios/TestExpectations
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateEncoder.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateEncoder.h
Log Message:
-----------
NEW TEST(289843@main): [macOS iOS Debug]: ASSERTION FAILED:
frame->presentationTime() >= m_lastMuxedSampleStartTime
https://bugs.webkit.org/show_bug.cgi?id=288036
rdar://145182916
Reviewed by Eric Carlson.
When fetchData() was called we would capture the audio time in the task
dispatched
on the recorder's WorkQueue. This current time is calculated for recordings
with audio by looking at instantaneous audio time (atomic access) which is
the time of the latest audio frame received on the audio thread.
At this stage, the code assumed that all video frames prior that time
would have been enqueued for encoding and we would wait for all those
already enqueued frame to finish encoding and write the webm segment.
However, due to when the audio's time was read, some raw video frames
could have still be in-flight between the capture thread and the recorder's
queue.
They wouldn't have been encoded by the time we would have written the webm
media segment.
When fetchData was called again, those in-flight frames would have now
been properly enqueued for encoding but would have an earlier time than
the end time of the previously created segment.
WebM requires monotonically increasing timestamps. If we attempted to
use those earlier frames it would enter an error mode and would no longer
mux any further frames, resulting in truncated webm recordings.
In a debug build, this error was caught with the `frame->presentationTime() >=
m_lastMuxedSampleStartTime`
assertion.
The fix is to capture the current time when fetchData is called on the main
thread. With the following recorder's workqueue dispatch, this guarantees that
there are no in-flight video frames and that we can guarantee monotonically
increasing timestamps with all frames provided to the WebM muxer.
Covered by existing and re-activated tests
* LayoutTests/platform/ios/TestExpectations:
* LayoutTests/platform/mac-wk2/TestExpectations:
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateEncoder.cpp:
(WebCore::MediaRecorderPrivateEncoder::appendVideoFrame):
(WebCore::MediaRecorderPrivateEncoder::fetchData):
(WebCore::MediaRecorderPrivateEncoder::currentTime const):
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateEncoder.h:
Canonical link: https://commits.webkit.org/308349@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
