See also: IRC log
<trackbot> Date: 08 July 2014
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 08 July 2014
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Jul/0001.html
<scribe> scribenick: ddorwin
<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
<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 input
jdsmith: I created this bug per the discussion on the last call before the holidays.
… 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 orthogonal.
jdsmith: I would focus on the robustness aspect for our task force.
<paulc> Please respond to https://www.w3.org/Bugs/Public/show_bug.cgi?id=26207#c1
paulc: Glenn and BobLund, please reply to the bug.
<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: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25896#c7
… 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 string?
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 formats.
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.
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
<paulc> See Jerry's comment: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c34
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: http://www.w3.org/2014/06/17-html-media-minutes.html#item06
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 those.
… 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.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673
<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.
<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: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25920#c7
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 file
<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 acquisition
<adrianba> ... in EME the application needs the URL and we're providing it back
<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 be.
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.
<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>.
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268
<paulc> See also: http://lists.w3.org/Archives/Public/public-html-media/2014Jun/0053.html
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 proposals.
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.
<paulc> See Joe's ACTION: http://www.w3.org/2014/06/24-html-media-minutes.html#item03
<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.
s/"" //
s/s/"" ///" "
s/s\/"" \/\//" "
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/20 open bugs/paulc: 20 open bugs/ Succeeded: s/Any comments on "encryptedmedia"./Any comments on "encryptedmedia"?/ Succeeded: s/help with tests/help with MSE tests/ Succeeded: s/list attendees// FAILED: s/zakim, list attendees// Succeeded: s/list attendees/ / Succeeded: s/list attendees/ / Succeeded: s/zakim, /""/ WARNING: Bad s/// command: s/s/"" ///" " WARNING: Bad s/// command: s/s\/"" \/\//" " Found ScribeNick: ddorwin Inferring Scribes: ddorwin Default Present: +1.415.832.aaaa, +1.720.897.aabb, pal, +1.425.936.aacc, ReimundoGarcia, davide, paulc, jdsmith, glenn, ddorwin, adrianba, BobLund, markw Present: +1.415.832.aaaa +1.720.897.aabb pal +1.425.936.aacc ReimundoGarcia davide paulc jdsmith glenn ddorwin adrianba BobLund markw Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Jul/0001.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 08 Jul 2014 Guessing minutes URL: http://www.w3.org/2014/07/08-html-media-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]