[Webkit-unassigned] [Bug 195454] New: [MSE][GStreamer] Increase currentTime accuracy on pause/play and remove superfluous timeUpdate events

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=195454

            Bug ID: 195454
           Summary: [MSE][GStreamer] Increase currentTime accuracy on
                    pause/play and remove superfluous timeUpdate events
           Product: WebKit
           Version: Other
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: eocanha at igalia.com

MSE 2019[1] tests "26. SFRPausedAccuracy" and "27. HFRPausedAccuracy" fail on WPE on Raspberry Pi. Those tests measure the time drift (real time vs. media time) on playback and start counting since the first timeUpdate event. In WebKit, that event happens at play(), before the pipeline has completed the transition to playing. Therefore, the real time inherits this startup delay and the test thinks that the player has drifted.

I tried to convince the YouTube MSE Conformance Tests authors to ignore that initial timeUpdate event which reports no time change and actually start measuring the time drift after the first timeUpdate greater than zero[2]. However, their response quoting the spec[3] and stating that a timeupdate event is fired if "The current playback position changed as part of normal playback or in an especially interesting way, for example discontinuously." makes sense. I'm going to submit a patch to change this behaviour in WebKit, the 3 tests that depend on the old behaviour and to improve currentTime accuracy in the GStreamer media player private implementation by forcing a currentTime update on play() and pause().

[1] https://ytlr-cert.appspot.com/2019/main.html
[2] https://github.com/youtube/js_mse_eme/pull/37
[3] https://www.w3.org/TR/html52/semantics-embedded-content.html#eventdef-media-timeupdate

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190308/31170302/attachment-0001.html>