Skip to content

Conversation

@volodymyr-ogorodnik-red
Copy link

@volodymyr-ogorodnik-red volodymyr-ogorodnik-red commented Oct 8, 2025

[ARRISAPOL-3803][GStreamer] Sometimes progressive playback is not resumed after seek

https://bugs.webkit.org/show_bug.cgi?id=300041

Reviewed by Philippe Normand.

Sometimes, in a downstream multimedia player, regular video playback remains paused after seek instead of resuming automatically. It will play normally when play() or another seek operation are manually triggered.

Log analys shows that in the failing case the browser missed the state transition to 'HaveCurrentData', and application can't resume playback after seek. It was missed because it happened the gstreamer pipeline remains in state transition for too long and can't process buffering events. Normally it goes: seek -> Paused pipeline -> buffering (HaveCurrentData) -> finish_buffering(HaveEnoughData) -> start_playback. However, in the failing case, seek takes too long (~2sec) to set the PAUSED state on the pipeline and we are missing the buffering(HaveCurrentData) stage.

See: WebPlatformForEmbedded#1561

This patch returns the player readyState to HaveCurrentData and the networkState to Loading when a seek is being processed. The states will reach their final values as soon as the async state transition caused by the seek finishes.

Original author: Volodymyr Ogorodnik (https://github.com/volodymyr-ogorodnik-red)

  • Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
    (WebCore::MediaPlayerPrivateGStreamer::updateStates): Reset readyState and networkState to HaveCurrentData and Loading while the player is in an async state transition (in a seek) and buffering.

Canonical link: https://commits.webkit.org/300933@main

https://bugs.webkit.org/show_bug.cgi?id=300041

Reviewed by Philippe Normand.

Sometimes, in a downstream multimedia player, regular video playback
remains paused after seek instead of resuming automatically. It will
play normally when play() or another seek operation are manually
triggered.

Log analys shows that in the failing case the browser missed the state
transition to 'HaveCurrentData', and application can't resume playback
after seek. It was missed because it happened the gstreamer pipeline
remains in state transition for too long and can't process buffering
events. Normally it goes: seek -> Paused pipeline -> buffering
(HaveCurrentData) -> finish_buffering(HaveEnoughData) -> start_playback.
However, in the failing case, seek takes too long (~2sec) to set the
PAUSED state on the pipeline and we are missing the
buffering(HaveCurrentData) stage.

See: WebPlatformForEmbedded#1561

This patch returns the player readyState to HaveCurrentData and the
networkState to Loading when a seek is being processed. The states will
reach their final values as soon as the async state transition caused by
the seek finishes.

Original author: Volodymyr Ogorodnik (https://github.com/volodymyr-ogorodnik-red)

* Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:
(WebCore::MediaPlayerPrivateGStreamer::updateStates): Reset readyState and networkState to HaveCurrentData and Loading while the player is in an async state transition (in a seek) and buffering.

Canonical link: https://commits.webkit.org/300933@main
@volodymyr-ogorodnik-red volodymyr-ogorodnik-red changed the title [GStreamer] Sometimes progressive playback is not resumed after seek [ARRISAPOL-3803][GStreamer] Sometimes progressive playback is not resumed after seek Oct 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants