{minutes} HTML WG media telcon 2013-12-17 MSE & EME Status

http://www.w3.org/2013/12/17-html-media-minutes.html

Joe Steele




HTML Media Task Force Teleconference

17 Dec 2013

Agenda

See also: IRC log

Attendees

Present
pladd, paulc, markw, Aaron_Colwell, joesteele, adrianba, ddorwin, BobLund
Regrets
Chair
paulc
Scribe
joesteele
Contents

Topics
Role Call
MSE Status and bugs
Bug#23661
EME status and bugs
Bug#18515
Bug#24082
Summary of Action Items
<trackbot> Date: 17 December 2013
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Dec/0029.html
<scribe> ScribeNick: joesteele
<scribe> scribe: joesteele
Role Call

MSE Status and bugs

<paulc> ACTION-60?
<trackbot> ACTION-60 -- Adrian Bateman to Produce a summary of last call comments dispositions -- due 2013-12-10 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/60
<adrianba> http://www.w3.org/html/wg/wiki/MSE_LC_Comments
paulc: Adrian -- status report?
<scribe> ... done?
adrianba: yes
<adrianba> close ACTION-60
<trackbot> Closed ACTION-60.
paulc: ACTION-60 is done then
Bug#23661

paulc: response from Accessibility TF
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Dec/0016.html
paulc: Charles sent a long response overnight
... he is in Spain -- tried to get in before this morning
<paulc> Charles's last response: http://lists.w3.org/Archives/Public/public-html-media/2013Dec/0033.html
paulc: still need for folks to review
... could approach in a couple of ways
... response looks directed at Aaron
... or could open a general discussion
... request is to add a non-normative note talking about support for multiple tracks
<paulc> A11Y TF is here: http://lists.w3.org/Archives/Public/public-html-a11y/2013Dec/0051.html
paulc: most of discussion is centered around whether item should go in MSE or be an HTML5 bug, or whether is supported already
... anyone want a couple of minutes to review?
adrianba: MSE spec has a single goal -- to allow JS to generate the media stream for the element
... anything to do with handling or processing of tracks is out of scope for MSE
... think the discussion boils down to "should there be an information note in MSE that describes this handling, which is out of scope for MSE, or should it go into the HTML5 spec?"
... I supported this not because this is already working but because there is already a dependancy on HTML5
paulc: Adrian - do you believe the bug reflects our response?
adrianba: could add more text to the resolution
paulc: adding pointer to the bug
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661
acolwell: I agree with Adrian, think there is some confusion on what the restriction in the MSE spec is actually restricting
... MediaGroup is not restricted in availablility by the spec
... my assumption about changes to the spec was that a single element be allowed to support multiple videos
... this is what would require a change to the HTML spec
... sign language is already supported
markw: think that this is a misunderstanding that you would want to do this with one media element
... don't know whether there is any interation between MediaController and MediaSource - so not sure about whether a note would help
<paulc> a11Y TF proposed text: "NOTE: This specification directly supports multiple tracks. It explicitly extends the AudioTrack and VideoTrack interfaces to allow programmatic control of track kind to enable ,a href="http://www.w3.org/TR/media-accessibility-reqs/">Alternative Media</a> scenarios, including simultaneous multiple video tracks in support of <a href="http://www.w3.org/TR/media-accessibility-reqs/#sign-translation">Sign Language Translation video tra[CUT]
acolwell: they are not really related that way
... I will send out a response trying to clarify the misunderstanding
paulc: can we speak directly to the proposed text?
... one issue is adding the text, second is the text itself
... text was added above
... want to provide direct feedback
acolwell: I did speak to the programmatic control of the kind attribute, this seems to be conveying information not in the container file
... that was not the intent
... intent was that tracks with a kind that was not specified in the media file could modify the track to expose it to Javascript
... not intended to enable extra use cases or new functionality
... let me look in the log
... in my first response I said that the extensions to the audio/video track were not about enabling additional functionality ...
paulc: that is key, like to emphasize that point
... that content of the proposed text is not correct, regardless of where it should be added
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661
acolwell: seems that many of the media requirements are requirements on the element, not on the data source
<paulc> A11Y TF discussion was added to do the bug via: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23661#c3
acolwell: MediaSource is just a data source, some data sources do not provide accessibility content
... does not mean HTML5 in general is not accessible
<paulc> q1: is the proposed text from the A11Y TF appropriate ie correct?
paulc: 2 questions --
... is proposed text correct?
<paulc> q2: Assuming the text is correct or could be corrected, should it be added to MSE or to somewhere in HTML5?
paulc: assuming text is correct or could be corrected, should it be added to the MSE spec or to somewhere in HTML5?
... answer to Q1 is -- text is not correct
... answer to Q2 is -- should be added to HTML5 -- maybe you can suggest where -- video element?
... anyone disagree with the Media TF position?
... I believe we should take that information and respond on the email thread and the bug
... Media TF would like to retain as WORKS FOR ME
adrianba: I want to be clear I resolved this as a result of the conversation on a conference call
paulc: I heard Aaron will respond to email thread, and editors will respond to the bug
... include in both responses the answers we outlined above
... agreed?
... current schedule for MSE closes at midnight tomorrow
... with these responses we may get an objection - I will deal with it
... in anticipation of CFC passing, have arranged for call with Phillippe and Ralf after the WG meeting Thursday @ 1PM EST, 10AM PST
... minimum required is me, Phillippe and Ralf
... interested in having editors present -- any available?
adrianba: I can do it
acolwell: I can also
paulc: Mark I will make sure you get the logistics as well
markw: I think I can also
paulc: think that closes MSE
EME status and bugs

paulc: two action items pending
<paulc> ACTION-61?
<trackbot> ACTION-61 -- Paul Cotton to Work with wendy to make sure we get a security review of eme -- due 2013-12-10 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/61
ACTION-61?
<trackbot> ACTION-61 -- Paul Cotton to Work with wendy to make sure we get a security review of eme -- due 2013-12-10 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/61
paulc: you have seen my attempt to remind Wendy of the discussion at the F2F
<paulc> Paul's execution: http://lists.w3.org/Archives/Public/public-html-media/2013Dec/0028.html
<paulc> -61 is open
<paulc> ACTION-62?
<trackbot> ACTION-62 -- Paul Cotton to Report back about the plan for 20944 due 2013-12-15 -- due 2013-12-10 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/62
s/opne/open/
Bug#18515

<paulc> Bug 18515 - Provide more details on behavior of the media element when the key for an encrypted block is not available
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
<adrianba> ACTION-51?
<trackbot> ACTION-51 -- Adrian Bateman to Remind jdsmith to write a proposal for bug 18515 -- due 2013-11-05 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/51
paulc: action 51 is still pending here
adrianba: think Jerry is on vacation, had a brief discussion on Friday about this bug, not sure if he has the proposal yet
... bug is about how to indicate to an app that playback is blocked waiting for a key
... previously discussion that we should not change the ready state of the media element as could impact other use cases
... e.g. fooling app into making a bit rate change
... so pending question is how to convey?
... at TPAC outlined some of the discussion we had about extending the WAITING event
... today it is purely network, could extend it with a reason e.g. network, keys
... had a discussion about adding this to the media element
... discussion is happening -- need to write up the results
... I can take a stab at recording that in the bug
... when Jerry comes back he can review
paulc: any comments?
Bug#24082

<paulc> Bug 24082 - Several issues discussed in the TF point to the need for defined extensibility points in EME
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24082
<adrianba> ACTION-54?
<trackbot> ACTION-54 -- Adrian Bateman to Revive bug 17660 -- due 2013-11-05 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/54
<paulc> ACTION-54?
<trackbot> ACTION-54 -- Adrian Bateman to Revive bug 17660 -- due 2013-11-05 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/54
paulc: that action is closed
adrianba: this is a topic that need more discussion
... my action was about 17660 about the shape of the API
... Joe added some comments that changed the intent slightly
... proposed a mechanism for a local conversation between the app and the CDM
... Microsoft had some information they would like conveyed during the license acquisition
... David added a bug about providing additional constructor data for the CDM
... all of these issues relate to some people having requirements for extending beyond the core interop EME API
... a need for an extension point for some scenarios
... think we agree we want multiple CDMs to be able to playback the same content without major changes in behavior
... it seems like there are other requirements as well -- not just that goal
... question I pose it "should we do something active to describe extension points, so it occurs within the framework in the spec?"
... upside is everyone will extend the same way
... Joe had proposed passing information via the URL attribute
... would prefer to have an explicit place to put the data
... downside is that folks would perceive this as less interoperable
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17660 is the old bug
joesteele: I agree that this should be discussed
... my proposal is a good indication of my intent
adrianba: would like to hear whether the group agrees that this i something that should be discussed
ddorwin: I am concerned about what this does for interop
... see boxing different extensions into a different uniform model as an advantage
... concerned that folks will be lazy and not implement in an interoperabl way
paulc: can you explain more?
... does this mean folks will use an an argument against interop?
ddorwin: yes
adrianba: I recognize the disadvantages, but since this is going to happen anyway to some extent
... if we do not tackle this it could make things more difficult in the future
... folks might extend the spec in ways that will make future extensions harder
... recognize what David is saying
... will make the discussion around interop harder
... could wait and see what will happen - but that may make it harder
ddorwin: not opposed to having separate control messages that are common
... not a way for an app to do things that are not requesting a license
... will add comments in the bug
paulc: Adrian, would you proposing that CDMs would publish their parameters for folks to use?
adrianba: not proposing but I imagine that would happen
... no proposal for what this would look like
paulc: does anyone else want to respond to this?
markw: don't have a comment right now, but think we need a proposal
joesteele: we have at least one proposal now -- would like to see others
adrianba: problem is broader that that proposal addresses, another proposal is adding data to the createSession and CDM constructor
... could also add to the update call
... should we tackle this directly, or say that we should not handle this and allow folks to make the extensions they want.
ddorwin: it would help if we had real use cases, we have Adobes case and Microsofts case, do we have others?
... that would help us shape the discussion
<markw> My comment about a concrete proposal was to ask whether there are use-cases that should be supported in an interoperable way with first-class extensions to the specification
BobLund: think I agree with Adrian about other uses cases
paulc: that might not be a proposal, but a list of use cases would be a good next step
<markw> Would also like to understand the advantage of standardizing new EME-specific extensibility points vs using the existing extensibility point of prefixed methods
paulc: please get the MSE items done ASAP - before the Thursday meeting
... Happy Holidays to everyone on the call
... break for two weeks -- next meeting is on the 7th I believe
... MSE is progressing
... like hints after Jan 1 for EME items to tackle
... meeting is adjourned
Summary of Action Items

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2013-12-17 17:06:50 $