See also: IRC log
<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
ACTIO-48?
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: still pending
ACTION-51?
<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
<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
<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
paulc: 6 items on the list
subtopic: 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
subtopic: bug#24216
https://www.w3.org/Bugs/Public/show_bug.cgi?id=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
subtopic: bug#24270
https://www.w3.org/Bugs/Public/show_bug.cgi?id=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
<paulc> http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0008.html
subtopic: 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
s/intepret/interpret/
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
subtopic: 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?
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?
<crickets>
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
subtopic: bug#24081
https://www.w3.org/Bugs/Public/show_bug.cgi?id=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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24027
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.
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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=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
https://www.w3.org/Bugs/Public/show_bug.cgi?id=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
s/topic\: bug#24027/sub-topic: bug#24027/
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/charis/chairs/ Succeeded: s/Reopned/Reopened/ Succeeded: s/in non-/is non-/ Succeeded: s/fogure/figure/ Succeeded: s/or know/or no/ FAILED: s/intepret/interpret/ Succeeded: s/in to/into/ Succeeded: s/thei are/they are/ Succeeded: s/bug#21555/bug#21155/ Succeeded: s/thinkg/think/ Succeeded: s/reaised/raised/ Succeeded: s/should/does/ Succeeded: s/to th /to the/ Succeeded: s/thinkg/thinking/ Succeeded: s/plaback/playback/ Succeeded: s/???1/17673/ Succeeded: s/thinkg/think/ Succeeded: s/we comes/we come/ Succeeded: s/occuring/occurring/ Succeeded: s/ina /in a / Succeeded: s/subtopic/sub-topic/ FAILED: s/topic\: bug#24027/sub-topic: bug#24027/ Succeeded: s/ACTIION-48/ACTION-48/ Succeeded: s/no the/on the/ Succeeded: s/interpet/interpret/ Succeeded: s/have an identifier/have an identifier?/ Succeeded: s/subtopic:/Sub-Topic:/ Succeeded: s/quection/question/ Succeeded: s/theREADY/the READY/ Succeeded: s/giv ethe/give the/ Succeeded: s/discuss 18515 and 24081 together/REMINDER: discuss 18515 and 24081 together/ Succeeded: s/comments says/comment says/ Found Scribe: joesteele Inferring ScribeNick: joesteele Found ScribeNick: joesteele Default Present: paulc, ddorwin, joesteele, johnsim, davide, BobLund, pal, adrianba, [Microsoft] Present: paulc ddorwin joesteele johnsim davide BobLund pal adrianba [Microsoft] Agenda: http://lists.w3.org/Archives/Public/public-html-media/2014Jan/0020.html Found Date: 14 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/14-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]