- From: Francois Daoust <fd@w3.org>
- Date: Wed, 09 Sep 2020 12:22:37 +0000
- To: public-media-wg@w3.org
Hi all,
The minutes of yesterday's Media WG call are available at:
https://www.w3.org/2020/09/08-mediawg-minutes.html
... 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.
Thanks,
Francois.
-----
Media WG call
08 September 2020
[2]Agenda. [3]IRC log.
[2]
https://github.com/w3c/media-wg/blob/master/meetings/2020-09-08-Media_Working_Group_Teleconference-agenda.md
[3] https://www.w3.org/2020/09/08-mediawg-irc
Attendees
Present
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
Regrets
-
Chair
Jer, Mounir
Scribe
tidoust
Contents
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
status
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
implementations.
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
keys?
Xiaohan_Wang: Only the JS can re-negotiate the keys currently.
… While the license is there, the media element can resume the
playback.
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
JavaScript.
… 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
JS.
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
doing.
… 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
[26]
https://github.com/w3c/encrypted-media/issues?q=is:open+is:issue+no:milestone
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
time
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
backlog
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
on
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