wpe2.38 [GSTMediaPlayer] Make fake preroll asynchronous #1232
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
1) Call didPreroll() also for <video> elements that are audio-only 2) Make didPreroll() call async and put in onto HTML media element task queue to make sure it is executed after dispatching 'seeking' event to JS so app has a chance to note HTMLmedia.seeking attribute is 'true'
Scony
approved these changes
Nov 14, 2023
|
I couldn't reproduce the issue with a video (video only, no audio) on wpe-2.38 on RPI3 ( Approving and merging this PR. |
emutavchi
pushed a commit
to emutavchi/WebKitForWayland
that referenced
this pull request
Jun 27, 2025
…ed#1232) 1) Call didPreroll() also for <video> elements that are audio-only 2) Make didPreroll() call async and put in onto HTML media element task queue to make sure it is executed after dispatching 'seeking' event to JS so app has a chance to note HTMLmedia.seeking attribute is 'true'
eocanha
added a commit
to eocanha/WebKit
that referenced
this pull request
Jul 1, 2025
https://bugs.webkit.org/show_bug.cgi?id=295289 Reviewed by NOBODY (OOPS!). With the current implementation the whole seek flow as executed in a single main loop cycle. As a result, the JS app had no chance to spot that video.seeking attribute is ever set to true. Also some apps listen to video.onseeking and expects that video.seeking attribute to be true in such case. That wasn't a valid assumption. Also, the behaviour isn't the same in <video> elements that are audio-only as in <audio> elements. This happens on the Amlogic platform, that doesn't have asynchronous state changes on its audio sink. Spotify is broken there because of this problem. See: WebPlatformForEmbedded/WPEWebKit#1232 WebPlatformForEmbedded/WPEWebKit#1527 This patch calls didPreroll() also for <video> elements that are audio-only. Also makes that call async by putting it on the HTML media element task queue to make sure it is executed after dispatching 'seeking' event to JS so the app has a chance to notice that HTMLmedia.seeking attribute is 'true'. Original author: Andrzej Surdej <[email protected]> * Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp: (WebCore::MediaPlayerPrivateGStreamerMSE::doSeek): Call didPreroll() asynchronously for any media element having only audio.
eocanha
added a commit
to eocanha/WebKit
that referenced
this pull request
Jul 3, 2025
https://bugs.webkit.org/show_bug.cgi?id=295289 Reviewed by NOBODY (OOPS!). With the current implementation the whole seek flow as executed in a single main loop cycle. As a result, the JS app had no chance to spot that video.seeking attribute is ever set to true. Also some apps listen to video.onseeking and expects that video.seeking attribute to be true in such case. That wasn't a valid assumption. Also, the behaviour isn't the same in <video> elements that are audio-only as in <audio> elements. This happens on the Amlogic platform, that doesn't have asynchronous state changes on its audio sink. Spotify is broken there because of this problem. See: WebPlatformForEmbedded/WPEWebKit#1232 WebPlatformForEmbedded/WPEWebKit#1527 This patch calls didPreroll() also for <video> elements that are audio-only. Also makes that call async by putting it on the HTML media element task queue to make sure it is executed after dispatching 'seeking' event to JS so the app has a chance to notice that HTMLmedia.seeking attribute is 'true'. Original author: Andrzej Surdej <[email protected]> * Source/WebCore/platform/graphics/gstreamer/mse/MediaPlayerPrivateGStreamerMSE.cpp: (WebCore::MediaPlayerPrivateGStreamerMSE::doSeek): Find the actual final audio sink. Call didPreroll() asynchronously for any media element having only audio.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
task queue to make sure it is executed after dispatching
'seeking' event to JS so app has a chance to note HTMLmedia.seeking
attribute is 'true'
With previous implementation the whole seek flow as executed in a single main loop cycle. As a result JS app had no chance to spot that video.seeking attribute is ever set to true. Also some apps listen to video.onseeking and expects that video.seeking attr will be true in such case that was not valid assumption.
This change fixes Spotify audio only playback seeking to buffered range on Amlogic platform that doesn't have async state changes in audio sync
The test case is to simply seek MSE audio only plaback to buffered range on proper platform and check if video.seeking attribute is ever "true"