[Webkit-unassigned] [Bug 210965] New: [EME] clearkey-mp4-playback-temporary-multikey-sequential-readyState.https.html is inherently flakey

[bugzilla-daemon at webkit.org]

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

            Bug ID: 210965
           Summary: [EME]
                    clearkey-mp4-playback-temporary-multikey-sequential-re
                    adyState.https.html is inherently flakey
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cturner at igalia.com
                CC: bugs-noreply at webkitgtk.org

The failure reason is,

FAIL org.w3.clearkey, successful playback, temporary, mp4, multiple keys, sequential, readyState assert_equals: Should have only received exactly one timeupdate while waiting for key expected 1 but got 0

This is testing key changes happening sequentially in the file. After
about 5 seconds samples will need a new key.

The test sets up the video and adds some event listeners. It calls
startNewSession (generateRequest) immediately, providing a license
before the media starts playing, hence waitingforkey will only happen
when transitioning between keys. The test registers an ontimeupdate
handler that tries to count the number of times this event is fired
during the time we are waiting for a key.

There are two main issues with this idea in our implementation,

1/ timeupdate event frequency is highly variable, it typically would
range between 4 and 66 Hz. In my environment I'm getting a 4Hz
tick.  Our waitiing for key dance takes just a few milliseconds
and so no timeupdates are counted, explaining the failure reason.

2/ The test relies on the ordering waitingforkey -> timeupdate ->
message. This isn't what happens in WebKit and we don't violate any
spec. When calling the
HTMLMediaElement::mediaPlayerWaitingForKeyChanged() from our player,
the media element checks if the current playback position is
available, and based on that will update the readyState and hence fire
the timeupdate as per the "If the previous ready state was
HAVE_FUTURE_DATA or more, and the new ready state is HAVE_CURRENT_DATA
or less" rule in the readyState algorithms. *Then* the media element
will fire the waiting for key message. Due to the mismatched event
frequencies I mentioned above, you may or may not get a subsequent
timeupdate after this waiting for key event and the next message
event. That is made even more variable by the optimization in WebKit's
scheduleTimeupdateEvent method, that will avoid sending timeupdate if
the movie time has not gone forward since we last fired a timeupdate,
this is a (compliant) difference against other browsers.

For these reasons, I consider this test inherently flakey and will
skip it.

-- 
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/20200424/a1ee4a9b/attachment-0001.htm>