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

{minutes} HTML WG Media telcon 2014-01-14 - EME/MSE status and bugs discussion

From: Joe Steele <steele@adobe.com>
Date: Tue, 14 Jan 2014 17:16:38 +0000
To: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <426DA0E2-EE31-43FC-A78F-667CEFF3E064@adobe.com>

Joe Steele

HTML Media Task Force Teleconference

14 Jan 2014


See also: IRC log


paulc, ddorwin, joesteele, johnsim, davide, BobLund, pal, adrianba, [Microsoft]

Role Call
Review Action Items
MSE status
EME status and bugs
New or Reopened EME bugs
Email threads
New bugs
Summary of Action Items
<trackbot> Date: 14 January 2014
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0020.html
<scribe> Scribe: joesteele
<scribe> ScribeNick: joesteele
Role Call

Review Action Items

<trackbot> ACTION-48 -- Adrian Bateman to Draft a proposal for bug 17673 -- due 2014-01-21 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/48
paulc: still pending
<trackbot> ACTION-51 -- Jerry Smith to Write a proposal for bug 18515 -- due 2014-01-14 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/51
paulc: Jerry is not here, reported they were working on it last week
... checking the bug
... no updates
... skipping other actions as no changes
MSE status

<paulc> CR draft was published: http://www.w3.org/TR/2014/CR-media-source-20140109/
paulc: now need to build a test suite for MSE -- looking for volunteers
... either to contribute tests or gther them togethers
... might start an email thread on that
<adrianba> ACTION-48?
<trackbot> ACTION-48 -- Adrian Bateman to Draft a proposal for bug 17673 -- due 2014-01-21 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/48
paulc: Adrian -- ACTION 48 and ACTION 51? still pending
adrianba: long proposal did not make it into bug -- hours away
paulc: keep on the agenda for next week then
EME status and bugs

<adrianba> ACTION-51 due next week
<trackbot> Set ACTION-51 Write a proposal for bug 18515 due date to 2014-01-20.
paulc: 17 bugs outstanding
... sent an email about heartbeat
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0010.html
paulc: David responded, chairs are building a heartbeat plan now
... looks like HTML5.1, polyglot, Ruby spec, HTML5->HTML4 diffs doc
... possibly DOM4 doc as well
... want to publish Canvas docs as well but may be on diff schedule
... like to make progress this week
... next week evaluate how far down the list of heartbeat bugs we are
<paulc> David's proposed bug list to do before a heartbeat: http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0015.html
New or Reopened EME bugs

paulc: 6 items on the list
Sub-Topic: bug#24227
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24227
<adrianba> sounds like a good idea
ddorwin: when we added closed, realized it existed on other elements, don't expect objections
paulc: any other comments?
... no dissent
Sub-Topic: bug#24216
paulc: not seen any responses to this one
<adrianba> jerry said he was going to take a look - still in our queue i think
paulc: David started an email thread -- no resposnes yet
Sub-Topic: bug#24270
ddorwin: entire section is non-normative
adrianba: from memory the intention is that table itself and desc. is not normative because the description of where they are used is normative.
... any difference means algorithm should win out
ddorwin: please add your comments
paulc: do we have any statements to that effect in the doc we can borrow?
adrianba: I will look and find an example
paulc: so Adrian is on point for that
Email threads

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0008.html
Sub-Topic: Are codecs allowed?
paulc: question from David -- does this require more discussion?
ddorwin: no definitive answer yet, some pushback on using simple string
... trying to figure out how to specify that this should be type and subtype - like video/mp4
... was going for simple string matching
... one option to always use video
... David Singer had a comment on that
... need to figure out what the regex looks like
adrianba: not sure what we are simplifying here
... either an implementation can be lax and say yeah that is supported
... don't actually know till you try to play it
... not sure whether you can say yes or no based on codecs
... not sure what we gain by trying to simplify
ddorwin: not related to type supported -- related to how to interpret the initData
... which of the container guidelines to follow -- essentially an enum
adrianba: don't you just pass from needKey?
ddorwin: that is one option, pass from applications, in theory you should know whether you can handle the initData
ddorwin: maybe can just go with simple type/subtype
pal: heard the mime-type is intended to flag the specific init type that was parsed from container
ddorwin: yes
pal: specification tells you how to create the initData based on the underlying content
ddorwin: tells you what it is like for the container
pal: that list could grow, could have multiple items per container, shouldn't that list have an identifier?
ddorwin: that was in my initial proposal
adrianba: I think I am making the same point as pal
... the type information we get in needKey and pass into createSession is a description of the initData format
... the way you interpret the data is based on the container format
... from scanning the thread was not obvious what we were talking about
pal: to confirm - today based on the spec the only two types of initData you can get back are those described in section 1 and 2?
... so then not tied to the container rather tied to 8.1 and 8.2
... if we defined other mappings in the future we can define more mappings
ddorwin: this could potentially solve the ISOMFF versus CENC issue
... we could define as common mime-type
adrianba: true that the spec contains just those two sections, but in some ways they are not quite examples, but more meaningful
... but we are not enumerating all allowed formats
... don't want a normative dependency
... may want to move those definitions out of the core spec and have a registry like for MSE
... might make sense that the registry defines the string as David says
pal: sounds good to me
paulc: may need to update the descriptions in the email thread -- carry forward there
... will include on the agenda next week
Sub-Topic: EME rendering behavior undefined
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0012.html
paulc: included in the agenda not realizing there would be more messages
... not sure who has responded on the thread
... what does the group want to do about this thread?
<adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#media-element-restictions
paulc: Mark asked which material Hans was referring to -- it was section 2.3
... questioning whether material should be there at all or replaced with something more normative
... any comments or suggestions?
paulc: was added in response to bug#21155
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21155
adrianba: don't think section should go away, this is a quality of implementation issue for how restrictive playback is
... on example is playing back in rectangular regions
... possbile to tweek the text
... don't know what the state of implementation is going to go here
paulc: so you are saying that even with this thread we want to hold off making changes until we get to CR?
adrianba: threads suggests two possibile outcomes - very restrictive or no restrictions
boblund: agree with Adrian, to foster interop we should specify requirements somewhere
pal: in general - the issue of whether a UA supports a set of capabilities is outside the scope of EME correct?
BobLund: I think this is outside the scope of EME, debatable about whether outside the scope of HTML
pal: think that perhaps not all UAs support transparency or transformation, so should be a mechanism to discover whether UA supports those capabilities
BobLund: goes beyond CSS transform example, also covers what kind of layering the application can expect, broader than the points raised in the thread
paulc: do those points apply to video in general and does EME make any changes?
pal: commenter suggests that it is not clear that all UAs support capabilities mentioned by the commenter
adrianba: not a question of whether feature is supported at all, question is whether those features support the element (video element)
... since rendering might be performed outside the UA then might not be able to do all the operations that UA might perform
... question for whether supported with video and then whether supported for video with EME
... i.e. can I do a 3D transform of the video in EME -- app may want to ask that
... thinking about Internet Explorer, not sure where we will land in our ability to layer and transform the video
... think we should wait and see how implementations go to see what restrictions we will have
... may be that we will need APIs may be implicit, not sure we know yet
pal: think you answered my question
... today no generic API to discover capabilities for a specific object correct?
adrianba: correct
pal: then commenter should be encouraged to think about that
paulc: please add to the thread
Sub-Topic: bug#24081
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24081#c2
paulc: Mark asked a question after last meeting about what you were asking for
<paulc> mark's question: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24081#c3
ddorwin: this was reopened after last weeks mtg
... looked at his response, ran out of time
... those are two issues, not sure they are the only two issues, trying to word it
... thinking you can be in or go to the READY state and be working
... but not clear that there is an advantage to how we have separated READY and PENDING
<adrianba> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c16
adrianba: Jerry posted his proposal -- possible that this solves for one of these cases
<paulc> See https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515#c16
adrianba: doesn't necessariily give the same information, but need more time to think about the implications
... proposed that when you begin playback, you may want to display something to the user that a key exchange is occurring
... want some way to know when the current exchange was in a READY state so you can remove the indicator
... that was one of the goals
... in Jerrys proposal - we have a state indication that media playback is blocked waiting for a key
... difference is that you would not get the indication till playback was blocked when you were not expecting to be blocked
... maybe that is sufficient
paulc: so items are connected and people should look at proposal for 18515 as well
... this would close action 51
<adrianba> close ACTION-51
<trackbot> Closed ACTION-51.
close ACTION-51
<trackbot> Closed ACTION-51.
paulc: we should tag these two items together so we discuss them together
REMINDER: discuss 18515 and 24081 together
New bugs


paulc: adrians comment says we need to wait for bug 17673 to be completed before continuing
... don't think there is anything we can do with
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673
<paulc> Which is ACTION-48.
<trackbot> ACTION-48 -- Adrian Bateman to Draft a proposal for bug 17673 -- due 2014-01-21 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/48
ddorwin: technically blocked on what we come up with for ISOBMFF -- possible to think about whether we want to put in there -- list of key ids etc
... think about this for next week
Sub-Topic: bug#24082
paulc: adrian -- what is next step on this bug?
adrianba: need people to write use cases
paulc: need to action someone to do it then
... otherwise won't happen
... don't think we have anyone who has pushed this since the F2F
Sub-Topic: bug#24025
paulc: summary email from David prior to the break
<paulc> See David's summary: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24025#c6
paulc: no responses from anyone yet
ddorwin: that was one question out of a big section
... that is a spec detail -- the larger question is one of extension points in the previous bugs
paulc: how should we attack bugs like this?
... they are long outstanding -- seem to carry over between mtgs and discussions
adrianba: don't think they are that longstanding compare to some things we are trying to resolve
... this is not at the top of the priorities
... this is one way we might amend the API for extensibility
... identifying waiting, READY state, error codes, definition of initData are higher in priority list
... we have been applying more attention to those
... my takeaway is that we need to move forward, but it is understandable that they have not been addressed yet
paulc: ok -- we are out of time.
... will build an agenda based on Davids list
... any objections to order let me know
... adjourned
Summary of Action Items

[End of minutes]
Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2014-01-14 17:10:46 $

Received on Tuesday, 14 January 2014 17:17:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:44 UTC