Closed jacek-skiba-red closed 6 months ago
I've noticed that the Broadcom audio sink is not asynchronous, so this piece of code would be the one manually triggering didPreroll().
Would it make sense to update the cached position before that specific call to didPreroll() and to propagateReadyStateToPlayer() and invalidateCachedPosition() after the call to didPreroll()? That would be only in the case of !m_isWaitingForPreroll && m_isSeeking
. If we do it like this, the workaround would be more contained to the specific case of Broadcom.
I was able to write a simple test case that reproduces the issue on Broadcom (but not on upstream webkit on desktop) and proved that the change I proposed fixes the issue. I'm going to upstream that one.
Patch submitted upstream for review as https://bugs.webkit.org/show_bug.cgi?id=269587 / https://github.com/WebKit/WebKit/pull/24628
Patch landed upstream as https://github.com/WebKit/WebKit/commit/1791f0d769bbbad7317d9f8ac7f89b1957d9a217 and backported to wpe-2.38 as https://github.com/WebPlatformForEmbedded/WPEWebKit/commit/ee188e833ac7d57ddf8b40e7e9404fdcb3b5bf61 and to https://github.com/WebPlatformForEmbedded/WPEWebKit/commits/calvaris/wpe-2.42/upstream/ as https://github.com/WebPlatformForEmbedded/WPEWebKit/commit/90b0b762b4ce0689dbfbb7af9d1402af3b95e948. Closing PR.
Issue reproduced on BBC Sounds application on Broadcom platform
Reproduction flow:
Solution: during preroll state we still remember seek position as a cached value