W3C home > Mailing lists > Public > public-html-media@w3.org > July 2014

{minutes} HTML WG media telecon 2014-07-08 - EME status and bug discussion

From: David Dorwin <ddorwin@google.com>
Date: Tue, 8 Jul 2014 14:30:25 -0700
Message-ID: <CAHD2rsggnB5pokiF=X=TSD7p==u0zExMoomWT5bV=_jp6ZQuEQ@mail.gmail.com>
To: "public-html-media@w3.org" <public-html-media@w3.org>

Next meeting is *July 15th* and will cover EME (and possibly MSE testing).

[image: W3C] <http://www.w3.org/>
HTML Media Task Force Teleconference
08 Jul 2014


See also: IRC log <http://www.w3.org/2014/07/08-html-media-irc>
Present+1.415.832.aaaa, +1.720.897.aabb, pal, +1.425.936.aacc,
ReimundoGarcia, davide, paulc, jdsmith, glenn, ddorwin, adrianba, BobLund,
markw RegretsChairpaulcScribeddorwin

   - Topics <http://www.w3.org/2014/07/08-html-media-minutes.html#agenda>
      1. EME bugs
      2. New Bugs
      3. Bug 25896 - Why is EME creating new DOMException subclasses?
      4. Bug 18515 - Provide more details on behavior of the media element
      when the key for an encrypted block is not available
      5. Bug 17673 - Define Initialization Data for implementations that
      choose to support the ISO Base Media File Format
      6. Bug 25920 - Remove extraction of default URL from createSession()
      7. Bug 25866 - "needkey" event name is misleading
      8. Bug 25268 - Reduce the burden on applications to deduplicate
      initData from many needkey events
      9. EME Use Cases Wiki
   - Summary of Action Items


<trackbot> Date: 08 July 2014

<paulc> trackbot, start meeting

<trackbot> Meeting: HTML Media Task Force Teleconference

<trackbot> Date: 08 July 2014

<paulc> Agenda:

<scribe> scribenick: ddorwin
EME bugs

<paulc> http://tinyurl.com/7tfambo

paulc: 20 open bugs

pualc: we have closed 7 bugs since June 23rd

… That's pretty good progress.

paulc: Suggested bugs from editors in 5 and 6
New Bugs

<paulc> Bug 26207 - Provide a way to check system capabilities required for
UHD playback

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26207

pualc: This bug was opened up from the bottom of another bug.

<paulc> History: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24873#c15

… from 24873

<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=26207#c1 for new

jdsmith: I created this bug per the discussion on the last call before the

… We believe there is a need to identify capabilities of systems to some
degree so there can be a smooth experience with UHD content.

… Specific requirements like offloading of decryption and media pipeline.

… Typical scenario would be to try to play UHD content and fall back. Would
like a way to check UHD capabilities on the device.

… There is the |capabilities| string today, but it would require agreement
on strings

… Other options include pre-checking license or checking capabilities -
this is the one that is covered in the first comment.

… Check system capabilities and media parameters. Proposed a dictionary at
the bottom.

… Really there for discussion.

glenn: 1. This feels very orthogonal to EME. 2. We have something called
Media Queries - both CSS and <inaudible> API.

jdsmith: I agree that some of these are orthogonal - not all of them are.

BobLund: Jerry, are you concerned about the case where platform supports
UHD but will not support playback of encrypted UHD?

jdsmith: That is considered.

BobLund: I tend to agree with Glenn that capable of playing UHD is

jdsmith: I would focus on the robustness aspect for our task force.

<paulc> Please respond to

paulc: Glenn and BobLund, please reply to the bug.
Bug 25896 - Why is EME creating new DOMException subclasses?

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25896

<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=25896#c6

paulc: A couple of comments from Jerry & Anne that I think are at the heart.

jdsmith: The current MediaKeyError contains a numeric error code that is
key system specific and our preference is to keep it.

… The comment back is that we should be using exception message.

<paulc> See Anne's reply:

… I did not see an option in DOMException that supports numeric error code.

… I had proposed adding a numeric field on MediaKeySession.

paulc: Is Anne saying don't have a separate numeric code - put it in the

jdsmith: That's my interpretation.

adrianba: I think there are two parts to this. The first is the use case
for the system code. One use case is for logging where you want to make
sure that when some type of exception gets thrown, there is some type of
information you can return to the service so you can know what kind of
issues your customers are running into. If that was the only use case, then
including something in the message and saying you should send the message
back would be one [CUT]

… The problem with that is if you want to have that information sent back
to a service, presumably stored in a database, then extracted from the
message, that's difficult if different implementations have different

The second case, which may be less important with the goal of
interoperability of EME, is that an application may know that there is a
way of retrying or something for a specific key system.

… The use case is being able to know what part is the system code so you
can do analysis.

… If you believe the use case, how do you expose it. I think Jerry's
proposal to expose the value on the appropriate object is reasonable.

… You would get the DOMException with the value in the message then check
the value on the object.

paulc: Anyone else want to comment, especially on the two use cases?

jdsmith: Adrian nailed my concerns exactly…. Overhead of parsing it out.

paulc: Why don't you make a proposal?

jdsmith: OK.

ddorwin: Should we have a separate bug with the proposal?

glenn: Note that DOM4 just went back to LC.

… so it will be hard to get changes there.
Bug 18515 - Provide more details on behavior of the media element when the
key for an encrypted block is not available

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515

<paulc> See Jerry's comment:

jdsmith: I think where we left this is that there was an option to use
promises as a way to track states.

… I believe Mark gave a preference for using the waiting event.

… Unless there is a concern about using the waiting event. My view is that
it is a positive because it's a logical indicator that the media element is
waiting for something - in this case a key.

<paulc> Previous discussion on Jun 17:

ddorwin: I need to reread, but I think that's fine. Let's go with waiting.
I think there might be some existing issues. If so, we'll need to address

… most of it is already implemented. There might be some minor issues. I
will reread and update the bug.

paulc: Is it clear what's outstanding on this bug?

jdsmith: I think David wants to go back through and find any dangling
issues before the bug is closed.
Bug 17673 - Define Initialization Data for implementations that choose to
support the ISO Base Media File Format


<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c65

paulc: Jerry's reply followed by David's.

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c66

jdsmith: I think there is some text that I added… We did a review of the
document internally and surfaced some aspects of where PSSH boxes might be
encountered and added that. I think it's a point of disagreement on whether
that should have been added.

… I was talking to Adrian, and I think it's clear that these are not key
integration points with EME and CENC. I'm still having discussions, but we
might be able to review them.

… I haven't seen David's comments.
Bug 25920 - Remove extraction of default URL from createSession() algorithm

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920#c6

paulc: We'll look at comment 6 followed by comment 7.

<paulc> See David's reply:

jdsmith: I thought interop was the main issue, but it seems security is.
I'm having trouble seeing the issues.

<adrianba> ddorwin: i think it is not a good web practice to take random
media from the web

<adrianba> ... and extract instructions from them

<adrianba> ... that's essentially what we're doing by extracting the URL

<adrianba> ... that seems wrong to me

<adrianba> ... i don't think this is responsible

<adrianba> ... i understand that URLs can be embedded in PSSH but I think
this is for a different model where the media engine does the license

<adrianba> ... in EME the application needs the URL and we're providing it

<adrianba> ... most people don't need this - the app knows the service

<adrianba> ... content federation seems like the use case and seems to be
the most at risk

<adrianba> ... not a good practice and we don't have any good use cases

<adrianba> ... this is removing one step from the algorithm

<adrianba> ... think we should remove it and someone can file a bug to add
it back if they want to

markw: If we remove this one step from the specification, is there anything
left in the specification that would prevent a key system from populating
the destinationURL field with data from initData.

ddorwin: It would be out of spec from the step that says pass null.

… I originally thought this was an option, but a single CDM doing so would
cause problems for all applications.

markw: It seems like if you trust the CDM, then you trust the CDM to get
this information.

ddorwin: It's not really a UA trust of CDM. The application has to trust
the UA. Really, it's the media data that needs to be trusted, and it can't

pal: I don't see how a statement "don't do this" can be tested.

<pal> pal: in this particular case

markw: I don't have a problem removing this line. I think we should add a
line to the security considerations section addressing this.

ddorwin: We don't need a negative statement. The step would say to pass
NULL as the URL.

… Yes, that is hard to test.

jdsmith: I'll check with the DRM team here. It sounds like we're converging
on removing.
Bug 25866 - "needkey" event name is misleading

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25866#c3

paulc: Any comments on "encryptedmedia"?

<paulc> What about "Thing 1" or "Thing 2" in the spirit of Dr Seuss

<paulc> http://en.wikipedia.org/wiki/The_Cat_in_the_Hat

ddorwin: Hoping for a more ideal name before changing. Not making the
change yet to avoid churn. As we drive the bugs down, we'll pick the best
option and implement it.

paulc: This bug is waiting for action <per above>.
Bug 25268 - Reduce the burden on applications to deduplicate initData from
many needkey events

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268

<paulc> See also:

paulc: I wasn't quite sure how we were supposed to be dealing with this.

ddorwin: I implemented this bug per my suggestion. In the thread, there is
disagreement whether it's useful.

… I later realized it doesn't solve the most common case.

… My proposal is to revert.

… The issue of reducing the burden still exists, but there were no other

paulc: Does anyone think we should not remove the solution based on the
rational David provided in the bug.

… I don't here any objections.

… David, maybe you should make the change and leave the bug to say we're
still waiting for a better solution.
EME Use Cases Wiki

<paulc> See Joe's *ACTION:*

<paulc> Carry over to next meeting.

paulc: Joe said he would send us an email when he's done that.
... markw, you took an action to see if there is someone that can help with
MSE tests. Have you made any progress?

markw: The person has been out of the office.

paulc: Please let me know by Friday so I can maybe put it on the agenda.
... Next meeting is next week.
Summary of Action Items[End of minutes]
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm> version
1.138 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2014-07-08 16:10:08 $
Received on Tuesday, 8 July 2014 21:31:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:33:04 UTC