Skip to content

[GSTMediaPlayer] Make fake preroll asynchronous (#1232) #1527

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: wpe-2.46
Choose a base branch
from

Conversation

emutavchi
Copy link
Collaborator

  1. Call didPreroll() also for

cherry-pick from wpe-2.38 branch: f7120b4

…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'
@emutavchi emutavchi requested a review from philn as a code owner June 27, 2025 18:53
@emutavchi emutavchi requested review from eocanha and removed request for philn June 27, 2025 18:53
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
Copy link
Member

eocanha commented Jul 1, 2025

Submitted the patch for upstream review as https://bugs.webkit.org/show_bug.cgi?id=295289 / WebKit/WebKit#47446

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.
@eocanha eocanha added the upstream Related to an upstream bug (or should be at some point) label Jul 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
upstream Related to an upstream bug (or should be at some point) wpe-2.46
Development

Successfully merging this pull request may close these issues.

4 participants