Skip to content

Conversation

@eocanha
Copy link
Contributor

@eocanha eocanha commented Oct 2, 2025

293dfbd

[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/WPEWebKit#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

eedebcf

Misc iOS, visionOS, tvOS & watchOS macOS Linux Windows
✅ 🧪 style ✅ 🛠 ios ✅ 🛠 mac ✅ 🛠 wpe ✅ 🛠 win
✅ 🧪 bindings ✅ 🛠 ios-sim ✅ 🛠 mac-AS-debug ✅ 🧪 wpe-wk2 ✅ 🧪 win-tests
✅ 🧪 webkitperl ✅ 🧪 ios-wk2 ✅ 🧪 api-mac ✅ 🧪 api-wpe
✅ 🧪 ios-wk2-wpt ✅ 🧪 mac-wk1 ✅ 🛠 wpe-cairo
✅ 🧪 api-ios ✅ 🧪 mac-wk2 ✅ 🛠 gtk
✅ 🛠 vision ✅ 🧪 mac-AS-debug-wk2 ✅ 🧪 gtk-wk2
✅ 🛠 vision-sim ✅ 🧪 mac-wk2-stress ✅ 🧪 api-gtk
✅ 🛠 🧪 merge loading 🧪 vision-wk2 ✅ 🧪 mac-intel-wk2 ✅ 🛠 playstation
✅ 🛠 tv ✅ 🛠 mac-safer-cpp
✅ 🛠 tv-sim
✅ 🛠 watch
✅ 🛠 watch-sim

@eocanha eocanha requested a review from philn as a code owner October 2, 2025 21:11
@eocanha eocanha self-assigned this Oct 2, 2025
@eocanha eocanha added the New Bugs Unclassified bugs are placed in this component until the correct component can be determined. label Oct 2, 2025
@eocanha eocanha added the merge-queue Applied to send a pull request to merge-queue label Oct 3, 2025
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/WPEWebKit#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
@webkit-commit-queue
Copy link
Collaborator

Committed 300933@main (293dfbd): https://commits.webkit.org/300933@main

Reviewed commits have been landed. Closing PR #51698 and removing active labels.

@webkit-commit-queue webkit-commit-queue merged commit 293dfbd into WebKit:main Oct 3, 2025
@webkit-commit-queue webkit-commit-queue removed the merge-queue Applied to send a pull request to merge-queue label Oct 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

New Bugs Unclassified bugs are placed in this component until the correct component can be determined.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants