Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ced7f5e2066e77bb308efb5274a69119421cfd81
https://github.com/WebKit/WebKit/commit/ced7f5e2066e77bb308efb5274a69119421cfd81
Author: Jean-Yves Avenard <j...@apple.com>
Date: 2024-11-11 (Mon, 11 Nov 2024)
Changed paths:
A
LayoutTests/imported/w3c/web-platform-tests/mediacapture-record/MediaRecorder-blob-timecode.https-expected.txt
A
LayoutTests/imported/w3c/web-platform-tests/mediacapture-record/MediaRecorder-blob-timecode.https.html
M
LayoutTests/imported/w3c/web-platform-tests/mediacapture-record/w3c-import.log
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp
M Source/WebCore/Modules/mediarecorder/MediaRecorder.h
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateEncoder.cpp
M Source/WebCore/platform/mediarecorder/MediaRecorderPrivateEncoder.h
Log Message:
-----------
[MediaRecorder] timecode provided in BlobEvent is incorrect
https://bugs.webkit.org/show_bug.cgi?id=282320
rdar://138895100
Reviewed by Anne van Kesteren.
The timecode returned was always of the time at which requestData() was called
and not
"For a MediaRecorder instance, the timecode in the first produced BlobEvent
MUST contain 0.
Subsequent BlobEvent's timecode contain the difference of the timestamp of
creation of the
first chunk in said BlobEvent and the timestamp of the first chunk of the first
produced BlobEvent"
imported wpt's MediaRecorder-blob-timecode.https.html to test this
functionality.
The test exposed an issue in our implementation (which the test didn't deal
with).
It sets a timeslice of 0 and assume that we would always get a monotonically
increasing
timecode, but if we attempts to make 0ms long segment that may not always be
the case.
As a workaround, and considering real-life usage, if a timeslice is set and no
data was recorded at the time
the timer occurs, we will not emit `dataavailable` event. We also limit how
small the timeslice can be to 100ms.
On platforms using AVFoundation, we make the minimum segment size to be 1s.
Using a MP4 recorder calling requestData()
will return empty Blobs if called before 1s of data has been accumulated due to
the structure of ISOBMFF (it needs to
write a complete samples table first). An AVFormatWriter will also errors with
"NotReady" if we attempt to generate
too short segments.
With WebM data is written as received, but a new cluster will always be at
least one second long.
We also hold off writing any samples until the AudioSampleBufferCompressor has
started to return audible data to
ensure video and audio frames are already interleaved in monotonically
increasing time order.
*
LayoutTests/imported/w3c/web-platform-tests/mediacapture-record/MediaRecorder-blob-timecode.https-expected.txt:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/mediacapture-record/MediaRecorder-blob-timecode.https.html:
Added.
*
LayoutTests/imported/w3c/web-platform-tests/mediacapture-record/w3c-import.log:
* LayoutTests/platform/glib/TestExpectations:
* Source/WebCore/Modules/mediarecorder/MediaRecorder.cpp:
(WebCore::MediaRecorder::MediaRecorder):
(WebCore::MediaRecorder::startRecording):
(WebCore::MediaRecorder::requestData):
(WebCore::MediaRecorder::requestDataInternal): Split method. Don't emit
dataavailable event unless we actually have new data.
* Source/WebCore/Modules/mediarecorder/MediaRecorder.h: Set a minimum timeslice
of 0.1s.
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateEncoder.cpp:
(WebCore::MediaRecorderPrivateEncoder::takeData):
(WebCore::MediaRecorderPrivateEncoder::enqueueCompressedAudioSampleBuffers):
(WebCore::MediaRecorderPrivateEncoder::flushToEndSegment): Return pair
returnCode/time instead of setting a member variable.
Test exposed a case where we could have not written all available frames.
(WebCore::MediaRecorderPrivateEncoder::muxNextFrame):
(WebCore::MediaRecorderPrivateEncoder::fetchData):
(WebCore::MediaRecorderPrivateEncoder::flushPendingData):
* Source/WebCore/platform/mediarecorder/MediaRecorderPrivateEncoder.h:
Canonical link: https://commits.webkit.org/286442@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
