See also: IRC log
<trackbot> Date: 30 July 2013
<paulc> trackbot, start meeting
<trackbot> Meeting: HTML Media Task Force Teleconference
<trackbot> Date: 30 July 2013
<paulc> Looking for a scribe!
<scribe> Scribe: joesteele
<paulc> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0020.html
<paulc> http://www.w3.org/2013/07/16-html-media-minutes.html
paulc: don't believe anything specific -- actions have been carried forward
<paulc> ISSUE-1?
<trackbot> ISSUE-1 -- Consider moving the Clear Key definition into a separate specification -- raised
<trackbot> http://www.w3.org/html/wg/media/track/issues/1
paulc: standing issue we plan on dealing with later
<paulc> Editor's draft: http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
paulc: editors draft has not been updated since July 16th
<paulc> Outstanding bugs: http://tinyurl.com/7tfambo
paulc: as of yesterday - 15 bugs
paulc: david replied this morning
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21854#c16
ddorwin: a few minor tweaks about
error state , ready state
... discussion of keyadded versus keyready -- don't think
keyadded needed
... seems to me that every transition has an event so attribute
would be a duplicate
<adrianba> i think it is common to have such a state
<adrianba> look at XHR or FileReader
<adrianba> but can easily live without it
joesteele: agree with adrian - can generate from events if needed
paulc: enough information to generate the proposal?
<adrianba> it's a useful debugging tool and not much effort to implement
ddorwin: this is adrians
proposal, responding to adrians comments about XHR
... believe that is the ready state event? thought this meant
it was a duplicate
paulc: since folks can live without it - does Adrian have enough information?
rrsagent: generate minutes
paulc: Adrian
?
<adrianba> i think so
<adrianba> at least to make progress
<ddorwin> adrianba: re: XHR example, are you referring to readystate? readystatechange reflects a change in this event. This seems to be different from the proposal, which has a separate event for the transition into each state.
paulc: note in the minutes that Adrian will implement as ammended by conversation this week and last week
paulc: dependent on 21854 - have a current comment
<paulc> Latest: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21855#c6
<adrianba> well, XHR has a readystate variable as well as events - sure the model is slightly different, but it is arguably the same duplication
<adrianba> FileReader is the same
<adrianba> I think WebSocket is the same
ddorwin: not opposing, asking
questions
... some concerns I have are if you call createSession every
time, you will have extrat session objects in memory that serve
no purpose
... also this is CDM specific behavior
<adrianba> image element fires load event and also has a status to say if it is loaded
ddorwin: apps might need to have
to deal with this
... we are sharing underlying sessions or keys
... so we need to describe how they translate to actual key and
session objects
paulc: lets split out the diff questions
<paulc> Are all such objects treated as identical? If not, what is the expected behavior?
pauc: do you have an answer?
ddorwin: no -- posing the question
<paulc> We are assuming: Sharing underlying session/keys among MediaKeySession objects raises some interesting questions.
joesteele: think it would be very lightweight -- is that your thinking
ddorwin: still a memory
leak
... for TV playing and playing -- might never go away
joesteele: makes sense
paulc: any answer? or can we move on?
<paulc> Can update() & close() be called on any of them?
<adrianba> you can only call update with a response to a keymessage on a given session
<adrianba> there has to be a correlation
ddorwin: I assume it would impact
all of them
... you should call update on whoever called keymessage
<adrianba> you may not get a keymessage if you go straight to READY
ddorwin: may be other times when the app calls update
<ddorwin> is a keymessage is fired after READY (i.e. for renewal), one of the sessions should get the keymessage
<ddorwin> also, as joesteele says, update() can be called not in response to a keymessage
joesteele: we could use this as a channel for providing info from app to CDM so update could be called at anytime -- assuming this is allowed
<paulc> - Which MediaKeySession objects will receive keymessage events (i.e. for renewal)? What about keyerror events?
joesteele: assume that ALL of the objects would get them
ddorwin: probably only fire at
one object
... this would make N requests to the server
<adrianba> you should not get keymessage events to all the sessions
<adrianba> that's the problem we're trying to solve
<adrianba> you only need one keymessage event
<adrianba> because you're only going to perform one network interaction
<adrianba> if you fire against all sessions then you don't eliminate the network connections
ddorwin: may be talking about
diff things -- I am assuming a single application
... those would all be session objects for the same MediaKeys
on the same MediaElement
... yours seems to be re-using offline or saved keys
joesteele: good example - I was thinking of the domain key model where a domain key is shared between two applications
ddorwin: not a key?
joesteele: I am talking about an actual key -- acquired by both applications
ddorwin: close on that might be
different
... concern that you would be getting two types of keys in the
same session
paulc: what do you think happens on close?
joesteele: think the keys are ref-counted -- would close as session is closed
ddorwin: question -- would domain key be saved only for the lifetime of the session?
<paulc> Who just joined as +[IPcaller]?
joesteele: could be stored or
could stay around only as long as a session is using it
... concern with keeping multiple instances of keys around in
memory if needed
paulc: need answers in the bug to further resolve this
ACTION-25?
<trackbot> ACTION-25 -- David Dorwin to and John S to work on corner cases for bug 17673 -- due 2013-07-19 -- OPEN
<trackbot> http://www.w3.org/html/wg/media/track/actions/25
paulc: related to action above
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17673#c14
paulc: David, added lots of comments, are these implementation comments - would they allow someone to support this?
ddorwin: someone will have to
deepdive into ISOBMFF
... some of this is specific changes to proposed text
... rest is more general issues
paulc: we expect John SImmons to be engaged here right?
ddorwin: yes
paulc: maybe we should wait until John comes back from leave
ddorwin: yes - need Johns feedback
paulc: leave action item
open
... move date forward?
<paulc> ACTION-25 is due Aug 13
action-25 due 08-13-2013
<trackbot> Set ACTION-25 And John S to work on corner cases for bug 17673 due date to 2013-07-19.
action-27?
<trackbot> ACTION-27 -- Adrian Bateman to add comments to bug 17750 summarising the recent discussion of close -- due 2013-07-09 -- CLOSED
<trackbot> http://www.w3.org/html/wg/media/track/actions/27
paulc: don't believe any responses to Adrian yet
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750#c5
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17750
paulc: any responses? looks like no
ddorwin: might have been looking
for Marks input as well
... don't have any comments other than that
paulc: discussed on July 2nd
<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
paulc: is this worth spending time on now?
ddorwin: responding to Joe's
comment
... behavior would be the same - not planning to change the
state
... just need to figure out how to implement
paulc: so you need to make a
proposal or the change -- do you need more information?
... see Joe's last question
<paulc> But I am not sure that fully answers the questions I raised. Does this mean the media element remains in the HAVE_FUTURE_DATA state forever? Or can the CDM signal that it has determined that the proper key will never be acquired and therefore playback should be stopped and an error reported?
ddorwin: not really in that state -- just behaving like that
joesteele: that makes sense - but would like to know how to determine this
ddorwin: not sure we can track
this
... media element starts playing when it has keys and pauses
when it does not have them
... if we want an indication -- need to add something to the
spec
... some text that says media element is waiting for a
key
... follows some other non-identifiable states in the media
element spec
... don't actually have a state or event for this
... this would be a media element state
... not clear what you would do with it?
... please bring forward a proposal on what you would use it
for
joesteele: I will propose something in the bug after some more thought
paulc: no more bugs today -- discuss scheduling
rrsagent: generate minutes
paulc: CFC out right now for
taking MSE to Last Call -- ends next week
... nominally MSE would meet next week on the 6th, but only two
LC bugs to deal with and I am not available
... could stay with same schedule -- MSE call occurs or not
next week
... or could do more work on EME right now -- I will prep
agenda and we can make more progress on the bugs
... concerned that we are not making progress outside the
meetings other than David
... need to decide what the right mtg schedule is
... any holidays coming in August?
ddorwin: not anything major
paulc: Aaron is away this
week
... does it make sense for EME to meet next week?
joesteele: I would prefer to meet next week
glenn: should stay on EME and get the bugs down
joesteele: I meant EME
jdsmith: agree -- it would be good to focus on EME
ddorwin: most of the work is offline I think at this point - hard to discuss on a telecon
paulc: before mtg, sent a note to
the editors on asking for help on bugs to process but never
heard back from Mark or Adrian
... are you saying these are outstanding because they are
hard?
... can you live with trying to meet next week? and editors
could pick one or two to close?
ddorwin: yes
<paulc> Schedule: EME will meet on Aug 6 and Aug 13
paulc: I will propose we meet on both 8/16 and 8/13
<paulc> That means MSE misses one meeting on Aug 6
<paulc> And we will decide later who meets on Aug 20.
s/8\/16/8\/6
s/8\/16/8\/6/
paulc: will resend the editors
msg -- but anyone can propose bugs to discuss at next
meeting
... or make a comment on a bug -- this will push to the top
rrsagent: generate minutes
glenn: may be some bugs that have been pushed off because they are not getting a lot of attention but could be dispatched quickly
paulc: not assuming that, hoping
for editors to tell me that
... so unless someone nominates something specific we do them
in reverse order?
glenn: yes
paulc: will work with the editors to determine the order
ddorwin: let me know if one is trivial
paulc: will do an agenda but
won't be here next week
... thanks all!
... we are adjourned
s/8[/]16/8//6/
trackbot, bye
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/m ethat/me that/ Succeeded: s/senses/sense/ Succeeded: s/more though/more thought/ WARNING: Bad s/// command: s/8\/16/8\/6 WARNING: Bad s/// command: s/8\/16/8\/6/ Succeeded: s/respding/responding/ WARNING: Bad s/// command: s/8[/]16/8//6/ Succeeded: s/ends this week/ends next week/ Succeeded: s/does is/does it/ Succeeded: s/N request/N requests/ Succeeded: s/concern that you/ddorwin: concern that you/ Found Scribe: joesteele Inferring ScribeNick: joesteele Default Present: glenn, davide, paulc, pladd, joesteele, ddorwin, BobLund, +1.310.210.aaaa, jdsmith, [IPcaller] Present: glenn davide paulc pladd joesteele ddorwin BobLund +1.310.210.aaaa jdsmith [IPcaller] Regrets: John Simmons Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Jul/0020.html Found Date: 30 Jul 2013 Guessing minutes URL: http://www.w3.org/2013/07/30-html-media-minutes.html People with action items:[End of scribe.perl diagnostic output]