Repository navigation
[wpe-2.38] Premature "finishSeek" call on "seek" operation with progressive playback #1456
Description
When performing a seek operation, the HTMLMediaElement::finishSeek() call may be triggered too early, with a "seeked" event being raised to the app at a wrong time.
The attached app reproduces the issue: test.zip
Below are logs captured using the test app (logs starting with XXX are app specific logs):
[Log] XXX: Pause video at 3.833333 (test.html, line 19)
[Log] HTMLMediaElement::pause(DC6B46A3)
[Log] HTMLMediaElement::pauseInternal(DC6B46A3)
[Log] MediaElementSession::clientWillPausePlayback(DC6B46A3)
[Log] MediaElementSession::processClientWillPausePlayback(DC6B46A3) state = Playing
[Log] MediaElementSession::setState(DC6B46A3) Paused
[Log] PlatformMediaSessionManager::sessionWillEndPlayback(0) (DC6B46A3)
[Log] HTMLMediaElement::setAutoplayEventPlaybackState(DC6B46A3) None
[Log] HTMLMediaElement::updatePlayState(DC6B46A3) shouldBePlaying = false, playerPaused = false
[Log] HTMLMediaElement::updateMediaPlayer(DC6B46A3)
[Log] PlatformMediaSessionManager::sessionCanProduceAudioChanged(0)
[Log] HTMLMediaElement::updateMediaPlayer(DC6B46A3)
[Log] HTMLMediaElement::updateMediaPlayer(DC6B46A3)
[Log] HTMLMediaElement::updateMediaPlayer(DC6B46A3)
[Log] XXX: Seek video from 3.833333 to 303.833333 (test.html, line 35)
[Log] HTMLMediaElement::seek(DC6B46A3) – {value: 303.833333}
[Log] HTMLMediaElement::setNetworkState(DC6B46A3) new state = Loading, current state = NETWORK_IDLE
[Log] HTMLMediaElement::setReadyState(DC6B46A3) new state = HaveFutureData, current state = HAVE_ENOUGH_DATA
[Log] HTMLMediaElement::finishSeek(DC6B46A3) current time = – {value: 3.875, numerator: 3875000000, denominator: 1000000000, …}
[Log] XXX: onSeekedEvent - SEEKED. Current time: 3.875, duration: 596.473333333 (test.html, line 59)
The code sequence that causes this is as follows:
The seek triggers a call to MediaPlayerPrivateGStreamer::doSeek(), which calls updateBufferingStatus() before performing the seek at the gst pipeline level. The updateBufferingStatus() will call updateStates() just before exiting, which in turn notifies the player of a ready state change via the call to m_player->readyStateChanged(). HTMLMediaElement::setReadyState() will be called, which will evaluate the expression below:
if (m_seekRequested && !m_player->seeking() && m_readyState >= HAVE_CURRENT_DATA)
finishSeek();
The finishSeek() will be called, because the m_player->seeking() is still returning false, because the seeking state was not yet changed at the player level (m_isSeeking). It will be changed only after the doSeek() call returns, which has not happened yet
This seems to have been introduced with commit de3425a ("[GStreamer] Buffering hysteresis and buffering improvements for Broadcom")
Activity
[-]Premature "finishSeek" call on "seek" operation with progressive playback[/-][+][wpe-2.38] Premature "finishSeek" call on "seek" operation with progressive playback[/+]filipe-norte commentedon Feb 6, 2025
Hello @eocanha
Would you mind having a look at this issue and share your thoughts when you have some time?
Thank you
suresh-khurdiya-infosys commentedon Feb 10, 2025
We are also facing a similar an issue and as per my finding also on same condition.
if (m_seekRequested && !m_player->seeking() && m_readyState >= HAVE_CURRENT_DATA)
finishSeek();
When I changes the condition as below then my an issue was not happening.
if (m_seekRequested && !m_player->seeking() && m_readyState > HAVE_CURRENT_DATA)
finishSeek();
My an issue with progress bar:
Progress bar is fluctuating while performing seek in Deezer app
eocanha commentedon Feb 11, 2025
I can try to have a look at this, as I authored the commit that caused the regression.
eocanha commentedon Feb 11, 2025
I've been able to reproduce the issue on wpe-2.38 but not upstream (where I was planning to keep debugging, to fix the problem in two places at the same time). So, from now on, I'll keep debugging directly on wpe-2.38, keeping an eye on the differences between both versions.
[GStreamer] Premature finishSeek in progressive video
[GStreamer] Premature finishSeek in progressive video
eocanha commentedon Feb 13, 2025
A fix for this issue has landed as https://bugs.webkit.org/show_bug.cgi?id=287568 / WebKit/WebKit#40501 / WebKit/WebKit@1ba3cb1, has been backported to wpe-2.38 as 9b71229 and marked as GLib Suggested Backport - 2.46 upstream.
Closing issue.
eocanha commentedon Feb 13, 2025
@suresh-khurdiya-infosys, can you check if your problem also disappears with this fix? If not, open an independent bug and we can analyze it on its own.
suresh-khurdiya-infosys commentedon Feb 14, 2025
yes, it seems to be working fine my issue as well with your change in my local build.
we will plan to take this change and do some regression testing on our platform.
filipe-norte commentedon Feb 20, 2025
Thank you, @eocanha . It seems to work on our end as well in preliminary tests performed.
Cherry-pick 290339@main (1ba3cb1). https://bugs.webkit.org/show_bug.c…
RDK-54304: wpe-webkit 2.38.8 recipe