Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: a3dfc3da7f4d706fb9511f5f205d7d5f07acf9e6
https://github.com/WebKit/WebKit/commit/a3dfc3da7f4d706fb9511f5f205d7d5f07acf9e6
Author: Vivienne Watermeier <[email protected]>
Date: 2026-05-05 (Tue, 05 May 2026)
Changed paths:
A
LayoutTests/media/media-source/content/test-h264-bframes-lowfps-manifest.json
A LayoutTests/media/media-source/content/test-h264-bframes-lowfps.mp4
A
LayoutTests/media/media-source/media-source-h264-bframes-lowfps-expected.txt
A LayoutTests/media/media-source/media-source-h264-bframes-lowfps.html
M LayoutTests/platform/mac-wk2/TestExpectations
M Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp
Log Message:
-----------
[GStreamer][MSE] Some Youtube videos don't play
https://bugs.webkit.org/show_bug.cgi?id=309824
Reviewed by Philippe Normand.
We currently don't apply MP4 edit lists, so in the case of b-frames,
we may not have a starting presentation time of 0.
This would break playback, so to work around this we try to
extend the first sample to fill this gap, if necessary.
However, if such a gap is present, we can never know for sure which
sample is truly the first one in presentation order, since appends
may happen out-of-order - so we may always see an earlier sample in
the next append. This means we need to make a best-effort guess
how much of a gap we reasonably expect to see before the first sample,
which is a bit of a tightrope act:
- set the threshold too high, and we might fall for an out-of-order append,
and end up extending the wrong sample,
- set it too low, and we might not recognize larger gaps.
Currently, this threshold is at 100ms, the idea being that this
fits 2 frames at 24 FPS, which you may consider the lowest "commonly"
used framerate.
The video in question here [1] is a podcast, and is thus only encoded
at 6 FPS, i.e. about 167ms per frame.
To fix this, I've increased the threshold to 1 second, based on the
assumption that segments will usually not have a duration lower than that.
In return, this should fix playback for media with lower framerates,
down to 1-2 FPS.
[1]: https://youtu.be/fr5na1EZbtk?si=OKyfxUm2J_YbO44K
Test: media/media-source/media-source-h264-bframes-lowfps.html
*
LayoutTests/media/media-source/content/test-h264-bframes-lowfps-manifest.json:
Added.
* LayoutTests/media/media-source/content/test-h264-bframes-lowfps.mp4: Added,
short file at 6 FPS, using bframes.
* LayoutTests/media/media-source/media-source-h264-bframes-lowfps-expected.txt:
Added.
* LayoutTests/media/media-source/media-source-h264-bframes-lowfps.html: Added,
just tests playback.
* LayoutTests/platform/mac-wk2/TestExpectations: Flag the new test for
mac-intel-wk2.
* Source/WebCore/platform/graphics/gstreamer/mse/AppendPipeline.cpp:
(WebCore::AppendPipeline::appsinkNewSample): Increase threshold.
Canonical link: https://commits.webkit.org/312603@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
