[Webkit-unassigned] [Bug 210113] New: [EME][GStreamer] onencrypted should be dispatched iff readyState >= HAVE_METADATA

[bugzilla-daemon at webkit.org]

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

            Bug ID: 210113
           Summary: [EME][GStreamer] onencrypted should be dispatched iff
                    readyState >= HAVE_METADATA
           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

Currently it's dispatched as soon as GStreamer notifies us about discovering the relevant CENC boxes in the demuxer, which happens very early. In MSE, this event races with onupdateend and breaks tests like this,
https://github.com/web-platform-tests/wpt/blob/master/encrypted-media/util/testmediasource.js#L37
which is used like so,
https://github.com/web-platform-tests/wpt/blob/master/encrypted-media/scripts/reset-src-after-setmediakeys.js#L28

The high-level goal of this test is to set video.src to a new blob, receive the two expected encrypted events, reset the video src using the same blob (like a heavy restart) and check the two events are received again.

The problem is, the test assumes that updateend's must complete before the onencrypted events. It's not that easy finding out if this is correct using paragraph and verse from the specs... But, I noticed a bug in EME. The spec does say onencrypted should only be dispatched if readyState >= HAVE_METADATA, which would be a completed preroll for GStreamer and hence the appends would have completed, so fixing this seems like it will fix the entire issue.

However... The state machine for MSE as been copied from the base player, and then grown in different ways over the years. This has resulted in a complicated web of side-effects updating the readyState. So, this task is now a bit larger: to refactor the state machines in the base player, and the MSE player (ideally, if possible, unify them) and have a single place where the readyState is updated so that we can fire various cached data at the appropriate positions of readyState.

-- 
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/20200407/56b41f5e/attachment-0001.htm>