W3C home > Mailing lists > Public > public-media-wg@w3.org > September 2020

[minutes] Media WG Call - 2020-09-08

From: Francois Daoust <fd@w3.org>
Date: Wed, 09 Sep 2020 12:22:37 +0000
To: public-media-wg@w3.org
Message-Id: <em2b431fc8-d308-4417-a35e-0665c5db66f3@tipc>
Hi all,

The minutes of yesterday's Media WG call are available at:

... and copied as raw text below.

The call focused on getting consensus around the treatment of two 
clarifying EME issues (#451 on "usable-in-future" status and #473 on 
handling hardware context reset), and on triaging other issues with a 
"v2" milestone to clarify issues that the group intends to address. 
Similar triaging for MSE will start offline among MSE editors.


Media WG call
08 September 2020

    [2]Agenda. [3]IRC log.

       [3] https://www.w3.org/2020/09/08-mediawg-irc


           Becca Hughes, Chris Needham, Francois Daoust, Gary
           Katsevman, Greg Freedman, Theresa O'Connor, Jean-Yves
           Avenard, Jer Noble, Joey Parrish, Mark Watson, Matt
           Wolenetz, Mounir Lamouri, Peng Liu, Xiaohan Wang


           Jer, Mounir



     1. [4]Add "usable-in-future" to MediaKeyStatus (#451)
     2. [5]Handling hardware context reset (#473)
     3. [6]Triage MSE/EME issues
          1. [7]EME issue #468
          2. [8]EME issue #466
          3. [9]EME issue #464
          4. [10]EME issue #461
          5. [11]EME issue #460
          6. [12]EME issues #453, #452
          7. [13]EME issue #450
          8. [14]EME issues #449
          9. [15]EME issues #448 and #447
         10. [16]EME issue #443
         11. [17]EME issue #442
         12. [18]EME issue #440
         13. [19]EME issue #438
         14. [20]EME issue #433
         15. [21]MSE issues
     4. [22]Next calls

Meeting minutes

   Add "usable-in-future" to MediaKeyStatus (#451)

    [23]Issue #451

      [23] https://github.com/w3c/encrypted-media/issues/451

    jernoble: A couple of "OK" in comments. Anything to discuss?

    Xiaohan_Wang: Originally filed the issue.
    … I see Greg and Joey agree. We just brought it to see if there
    is consensus, then we can work on actual text

    jernoble: Additional status field that represents a "future"
    state, right?

    Xiaohan_Wang: Correct.
    … Only "usable" or "expired" could be used and don't apply this

    jernoble: No objection heard. I think we can go ahead

   Handling hardware context reset (#473)

    [24]Issue #473

      [24] https://github.com/w3c/encrypted-media/issues/473

    Xiaohan_Wang: For certain hardware based CDM systems, if the
    device enters suspend/resume, or if the user switches monitors,
    e.g. from one graphics card to another, the hardware context
    for the session would be lost.
    … In some cases, media playback will fail.
    … In Windows, the system will throw a special HResult status.
    … The current spec does not explain how to expose this.
    Application rely on workarounds.
    … These kind of errors are not real errors, just "normal"
    workflow for users.
    … If we retry, it should work.
    … No standard way to detect this case though.
    … I'm proposing to specify this process.
    … One aspect is MediaElement, firing a waitingForKey event
    while playback stalls.
    … Another aspect is on the EME side, to change the closed
    attribute. The closed promise does not return any parameter, so
    no way to know why the session got closed.
    … Idea is to return a reason.
    … Equipped with that, the application would know what happened
    and would be able to deal with it.
    … Same thing, looking to achieve consensus here.

    jernoble: How is this different to having all the key statuses
    set to expired?

    Xiaohan_Wang: expiration is misleading. The whole CDM set has
    been reset. In this case, the CDM will lose all its state, so
    it won't even know which keys it had.
    … The EME stack of the browser would have to remember all the
    key IDs that the EME session had before the hardware context
    reset happened.
    … That doesn't fit this case very well, and more work for

    jernoble: For context, Webkit already keeps a cache of key ids

    jernoble: From an ecosystem point of view, introducing a new
    status won't get a lot of adoption, especially if it
    essentially just happens on Windows.

    Xiaohan_Wang: I think the special media foundation error is
    Windows specific, but the hardware scenario is common to
    multiple platforms.
    … If I'm new to this and implement a JS player, why should I
    know that if all key IDs are expired, then we're in the
    hardware context reset case?
    … Session closed vs. all session keys expired. In both cases,
    we need to update the EME spec to explain what needs to happen
    in such a scenario.
    … My point of adding a status is that it would make things
    super clear.
    … I talked with people who did not realize that the session
    could be closed in such ways.

    jya_: Adding to what Jer said, the error is transparent. Why
    can't you resume playback once you have re-negotiated your

    Xiaohan_Wang: Only the JS can re-negotiate the keys currently.
    … While the license is there, the media element can resume the

    jya_: You should be able to totally hide that this error
    happened, and have the user agent do things under the hoods and
    resume playback later on.

    Xiaohan_Wang: For normal video playback, all the playback is
    happening on the client. User or JS won't see anything.
    … In this case, there must be network traffic going to
    … On the media element, the current proposal is to add a
    "waitingForKey" event. Other than that, there is no error.
    Then, if the JS re-negotiates some license, then then media
    element can resume the playback automatically.
    … Some JS players can also tear down everything and restart
    everything, but that will add some latency.
    … JS can also add a play button. Multiple ways to do it, the
    goal is to have a clear way to signal that this happens to the

    JoeyParrish: Jean-Yves, the source of confusion may be that all
    network communications need to go through the application.
    There is no way to re-negotiate the licenses without involving
    the application.
    … To Jer's point about re-using expired, I can see the desire
    not to introduce new things to solve this problem.
    … But if the CDM can close itself, it can't hurt to have an
    enum to say why it closed itself. Certainly in Shaka Player, we
    would change behavior when we see expired statuses.
    … Also "expired" is confusing for developers.

    jernoble: Clarifying question, do we have a list of reasons why
    a CDM can close itself?

    JoeyParrish: That doesn't exist today. Right now, the spec says
    that the CDM can close itself, it doesn't say why.
    … There's a Promise<void> for now.
    … This proposal would return a Promise<Reason>

    gregfreedman: Joey clarified what I wanted to say. Nothing
    added to EME on top of the reason why the closed happens. More
    information about whether things got closed by the application
    or by the CDM. And if by the CDM, why?

    Xiaohan_Wang: We kind of talked about possible enum values last
    time as well. HARDWARE_CONTEXT_RESET. Also one for application
    reason when the session is closed by the application.
    … And a third one for the CDM.

    jernoble: I don't hear any objection to this idea, so it seems
    reasonable to prepare a PR for this, so that we can discuss
    with concrete text in front of us.
    … Does that sound reasonable?

    [Plenty of silence heard]

   Triage MSE/EME issues

    <mounir> [25]https://github.com/w3c/encrypted-media/issues

      [25] https://github.com/w3c/encrypted-media/issues

    mounir: We could either start with MSE/EME. EME should go fast
    because the charter is very specific about what we may be
    … I see some already marked as v2.

    JoeyParrish: These are all relatively new, probably in the last
    month or so. 17 issues without milestones, the rest qualified
    as "backlog"

    mounir: Where backlog means not taken care of, right?

    JoeyParrish: Correct.

    mounir: I'm happy with that. I suggest we review [26]issues
    without milestones


     EME issue #468

    [27]Issue #468

      [27] https://github.com/w3c/encrypted-media/issues/468

    JoeyParrish: Issue #468 seems to be more a broken TV than an
    issue with the spec.
    … This seems more to be a question, hence the "question" tag

     EME issue #466

    [28]Issue #466

      [28] https://github.com/w3c/encrypted-media/issues/466

    mounir: Issue #466 seems to be more an issue about the spec

    JoeyParrish: Not sure I understand and what would need to be
    done to clarify this in the spec.
    … Should this go to v2 or backlog?

    mounir: Seems either a bug or a clarification
    … I wonder whether other specs mention behavior after unload

    Xiaohan_Wang: I know that we're already handling this in
    Chromium. We'll just reject the promise.

     EME issue #464

    [29]Issue #464

      [29] https://github.com/w3c/encrypted-media/issues/464

    mounir: Any input on that one?

    JoeyParrish: Do we know for Widevine and Fairplay?

    Xiaohan_Wang: I'll have to check.

    jernoble: It's... complicated. Even within the system CDM
    family, you have a wide range of keys available.

    JoeyParrish: Perhaps we need some type of editorial note that
    there is some variation on the length of acceptable keys.
    … Should we keep questions/bugs together, flagged as v2?

    mounir: I expect that the critical matter is new features that
    have to match the charter.

    JoeyParrish: Then I would suggest that such issues that should
    have us add some text to the spec, we put a v2 milestone to
    them, and then see later on whether we want to put them to the

     EME issue #461

    [30]Issue #461

      [30] https://github.com/w3c/encrypted-media/issues/461

    mounir: Issue #461 seems to be editorial in nature.

    jernoble: I would make a generic recommendation to add a bug
    label, so that we can look at them offline afterwards. And then
    use a "v2bugs" milestone for instance.

     EME issue #460

    [31]Issue #460

      [31] https://github.com/w3c/encrypted-media/issues/460

    Xiaohan_Wang: Issue #460 seems to be clarification

    mounir: OK, I'll use the "bug" label too

     EME issues #453, #452

    [32]Issue #453

      [32] https://github.com/w3c/encrypted-media/issues/453

    [33]Issue #452

      [33] https://github.com/w3c/encrypted-media/issues/452

    mounir: Just a WebIDL update
    … Same for #452

     EME issue #450

    [34]Issue #450

      [34] https://github.com/w3c/encrypted-media/issues/450

    JoeyParrish: Actually matches an issue against Shaka Player. In
    short, there is no good way to figure that out. I suggest
    putting it to the backlog, but will look into it.

     EME issues #449

    [35]Issue #449

      [35] https://github.com/w3c/encrypted-media/issues/449

    JoeyParrish: #449 is a feature request, but in the backlog, not
    something we're planning to work on. It involves multiple CDMs
    working simultaneously, which seems a bit exotic.

     EME issues #448 and #447

    [36]Issue #448

      [36] https://github.com/w3c/encrypted-media/issues/448

    [37]Issue #447

      [37] https://github.com/w3c/encrypted-media/issues/447

    mounir: #448 and #447 are spec comments / IDL. I will add the
    bug labels. Right now, v2, but this can be adjusted as needed.

    Xiaohan_Wang: Right, not familiar with strings and enums.

     EME issue #443

    [38]Issue #443

      [38] https://github.com/w3c/encrypted-media/issues/443

    JoeyParrish: #443 is more a question

     EME issue #442

    [39]Issue #442

      [39] https://github.com/w3c/encrypted-media/issues/442

    mounir: #442 seems to be a new feature request.

    JoeyParrish: Right, if it were v2, we should discuss.

    jernoble: Isn't that a case where update will fail?

    JoeyParrish: Potentially, you might have one key that is usable
    and another one that is not.

    Xiaohan_Wang: Similar to scenarios we discussed. When update is
    called, maybe the key is usable but then becomes unusable later

    mounir: should we move that to backlog?

    JoeyParrish: Sounds good

     EME issue #440

    [40]Issue #440

      [40] https://github.com/w3c/encrypted-media/issues/440

    JoeyParrish: Recurring conversation. We probably want to tweak
    the spec.

     EME issue #438

    [41]Issue #438

      [41] https://github.com/w3c/encrypted-media/issues/438

    JoeyParrish: I think #438 is "bug" and v2.

     EME issue #433

    [42]Issue #433

      [42] https://github.com/w3c/encrypted-media/issues/433

    mounir: bug and v2

     MSE issues

    mounir: Moving on to MSE.

    mattwolenetz_: There is a v2BugFixes milestone already

    mounir: 76 issues without milestone

    mattwolenetz_: I want to make sure that I have the input from
    my co-editor.
    … I see Mark dropped from the call.
    … I expect the bulk of triaging to happen offline.
    … MSE in workers feature is the main priority for now, because
    we expect that to be the bulk of v2. That should soon land.
    … We can look at other issues later on.

    mounir: Some of the other issues are rather old and could be
    closed rather quickly.
    … We may want to do MSE triaging at the end of next call.

    mattwolenetz_: I would support doing triaging of MSE issues in
    next call

    mounir: Yes, we need to get down to ~20 issues. 76 is too much
    to go over them in a call.

   Next calls

    mounir: The day after our next call, there will be a joint
    meeting with Timed Text and the Media & Entertainment IG. I
    recommend everyone to attend that call. I would like to get
    feedback on the API for TextTrack enhancements.

    [meeting adjourned]
Received on Wednesday, 9 September 2020 12:22:43 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 9 September 2020 12:22:44 UTC