See also: IRC log
<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
<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
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
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/
<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?
<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
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/Accessbility/Accessibility/ Succeeded: s/thi smorning/this morning/ Succeeded: s/couplf/couple/ Succeeded: s/this handling/this handling, which is out of scope for MSE,/ Succeeded: s/opne/open/ FAILED: s/opne/open/ Succeeded: s/uses cases/use cases/ Succeeded: s/role call/Role Call/ Succeeded: s/this that/think that/ Succeeded: s/gorup/group/ Succeeded: s/adrian,/Adrian,/ Found ScribeNick: joesteele Found Scribe: joesteele Inferring ScribeNick: joesteele Default Present: pladd, paulc, markw, Aaron_Colwell, joesteele, adrianba, ddorwin, BobLund Present: pladd paulc markw Aaron_Colwell joesteele adrianba ddorwin BobLund Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Dec/0029.html Found Date: 17 Dec 2013 Guessing minutes URL: http://www.w3.org/2013/12/17-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]