Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 53326d17a29d2d854bf256f3a5cfe7cf58278a53
https://github.com/WebKit/WebKit/commit/53326d17a29d2d854bf256f3a5cfe7cf58278a53
Author: Vivienne Watermeier <[email protected]>
Date: 2026-10-05 (Mon, 05 Oct 2026)
Changed paths:
A LayoutTests/media/media-source/media-source-shortmediastall-expected.txt
A LayoutTests/media/media-source/media-source-shortmediastall.html
M LayoutTests/platform/glib/TestExpectations
M Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp
M
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp
Log Message:
-----------
[GStreamer][MSE] Support playing videos of less than 1 sec with libav decoders
https://bugs.webkit.org/show_bug.cgi?id=293239
Reviewed by Xabier Rodriguez-Calvar.
GStreamer video decoders based on libav are currently implemented in a
way that hoard one video frame per decoding thread. This not only means
more latency during continuous playback, but also on stalls (when no
more frames are supplied at the video decoder input). While the problem has
been mitigated by reducing the max-threads to 2 [1], the behaviour still
causes problems in some tests with very short videos.
A previous approach [2] would look for a stall in the player by checking if
playbackPosition() had progressed, relying on periodic calls from
HTMLMediaElement. We would then emit a still-frame event in the playback
pipeline, which forces the decoder to emit its remaining samples.
However, this only works while playing:
See for example media-source-seek-to-zero-then-play.html, which will
attempt seeks that fail since the pipeline is never to preroll.
Instead, with this commit WebKitMediaSrc will send still-frame events on its
video pad after no buffers have been pushed for about 100ms.
This happens regardless of which video decoder we are using,
for unrelated decoders we add a probe that drops these events.
Unconditionally sending events like this is an ugly hack,
and the other option would have been to wait for playbin's element-setup signal
for the video decoder, to inform WebKitMediaSrc if the workaround would be
needed or not.
However, this introduced a race condition which was cumbersome
to fix, and doesn't work with changeType().
This keeps the LayoutTest introduced by the previous commit, which tests
that all the frames have been emitted after a stall.
[1]
https://github.com/WebKit/WebKit/commit/128e962baa61f49c78087a622eaecd08dc692ef6#diff-4376b854280205494dc9de0f08f985afd4d6584a7487c0a136adac2954c003cdR2831
[2] https://github.com/WebKit/WebKit/pull/45600
Co-authored-by: Enrique Ocaña González <[email protected]>
Test: media/media-source/media-source-shortmediastall.html
* LayoutTests/media/media-source/media-source-shortmediastall-expected.txt:
Added.
* LayoutTests/media/media-source/media-source-shortmediastall.html: Added.
* LayoutTests/platform/glib/TestExpectations:
media-source-seek-to-zero-then-play.html no longer times out.
* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::configureVideoDecoder): Attach probe to
any non-libav video decoder to drop still-frame events.
*
Source/WebCore/platform/graphics/gstreamer/mse/WebKitMediaSourceGStreamer.cpp:
Add stillFrameWorkaroundTime, which is set to 100ms in the future each time a
buffer is pushed.
(webKitMediaSrcLoop):
For video streams, waiting for objects is now bounded by
stillFrameWorkaroundTime.
If that time is reached and we have no new object, a still-frame event is
sent and we resume waiting without timeout.
Canonical link: https://commits.webkit.org/322677@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
