Closed asurdej-comcast closed 8 months ago
I couldn't reproduce the issue with a video (video only, no audio) on wpe-2.38 on RPI3 (video.seeking
is true when onSeeking is called). Reproduced the issue with an audio-only video (video.seeking
is false). I couldn't reproduce the issue upstream (video.seeking
is true), so this patch is only relevant downstream and the fix upstream is part of the code to support GPUprocess (doesn't make sense to backport it to wpe-2.38). I could reproduce the issue in wpe-2.42, but branch https://github.com/WebPlatformForEmbedded/WPEWebKit/tree/calvaris/wpe-2.42/upstream, from https://github.com/WebPlatformForEmbedded/WPEWebKit/pull/1266, has the upstream code that would fix the issue, so better not to port the commit there. Only if that code isn't finally merged we would need to port the patch of this PR #1232 there.
Approving and merging this PR.
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'
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"