14:51:45 RRSAgent has joined #html-media
14:51:45 logging to http://www.w3.org/2013/03/12-html-media-irc
14:51:47 RRSAgent, make logs public
14:51:47 Zakim has joined #html-media
14:51:49 Zakim, this will be 63342
14:51:49 ok, trackbot; I see HTML_WG()11:00AM scheduled to start in 9 minutes
14:51:50 Meeting: HTML Media Task Force Teleconference
14:51:50 Date: 12 March 2013
14:52:41 ddorwin has joined #html-media
14:52:42 trackbot, reload
14:53:41 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0034.html
14:53:44 Chair: Paul Cotton
14:53:48 rrsagent, make minutes
14:53:48 I have made the request to generate http://www.w3.org/2013/03/12-html-media-minutes.html adrianba
14:53:53 rrsagent, make logs public
14:57:03 pal has joined #html-media
14:58:36 markw has joined #html-media
14:58:36 joesteele has joined #html-media
14:59:02 HTML_WG()11:00AM has now started
14:59:08 + +1.408.536.aaaa
14:59:16 Zakim, aaaa is me
14:59:16 +joesteele; got it
15:00:35 +pal
15:00:42 + +1.425.202.aabb
15:00:54 zakim, aabb is me
15:00:54 +ddorwin; got it
15:01:04 paulc has joined #html-media
15:01:11 + +1.417.671.aacc
15:01:12 I am a few minutes late
15:01:38 BobLund has joined #html-media
15:01:43 zakim, who's on the phone?
15:01:43 On the phone I see joesteele, pal, ddorwin, +1.417.671.aacc
15:02:04 +[Microsoft]
15:02:09 +Mark_Watson
15:02:16 zakim, [Microsoft] has paulc
15:02:16 +paulc; got it
15:02:22 zakim, aacc is me
15:02:22 +glenn; got it
15:02:23 +[Microsoft.a]
15:02:26 zakim, who is on the phone?
15:02:26 On the phone I see joesteele, pal, ddorwin, glenn, [Microsoft], Mark_Watson, [Microsoft.a]
15:02:30 [Microsoft] has paulc
15:02:32 zakim, [Microsoft.a] is me
15:02:32 +adrianba; got it
15:02:38 Zakim, Mark_Watson is markw
15:02:38 +markw; got it
15:02:59 ScribeNick: adrianba
15:03:06 Scribe: Adrian Bateman
15:03:24 +[Microsoft.a]
15:03:31 -[Microsoft.a]
15:03:36 Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0034.html
15:03:51 TOPIC: Roll call, introductions and selection of scribe
15:03:59 + +1.303.661.aadd
15:04:02 jdsmith has joined #html-media
15:04:11 zakim, aadd is me
15:04:11 +BobLund; got it
15:04:32 zakim, who is on the call?
15:04:33 +[Microsoft.a]
15:04:33 On the phone I see joesteele, pal, ddorwin, glenn, [Microsoft], markw, adrianba, BobLund, [Microsoft.a]
15:04:34 [Microsoft] has paulc
15:04:51 zakim, [Microsoft.a] is jdsmith
15:04:51 +jdsmith; got it
15:05:05 paulc: completed
15:05:12 TOPIC: Previous meeting minutes
15:05:18 paulc: no comments received
15:05:24 TOPIC: Review of action items
15:05:27 paulc: done
15:05:57 Editor's draft updated on feb 26: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html
15:06:24 TOPIC: Progression to First Public Working Draft
15:06:30 paulc: discussing with the other co-chairs
15:06:40 ... asking for more detail about how we resolved issues
15:06:46 ... hope to have more this week
15:06:55 TOPIC: Discussion of outstanding bugs
15:07:15 [EME] Bugs for discussion this week: key not available behavior and when to fire needkey events
15:07:42 http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0033.html
15:07:57 paulc: David sent this message to the list for discussion
15:08:24 ddorwin: these bugs have been put off - summarised in the bugs and put this mail together
15:08:41 ... break down to what should we do if we need to decrypt a block and there is no key
15:08:49 ... the other is reducing firing some events
15:09:11 ddorwin: first is what to do if there aren't keys - should we keep playing, pause, or something else
15:09:24 q+
15:09:25 Bug 18515 -Provide more details on behavior of the media element when the key for an encrypted block is not available
15:09:26 q+
15:09:32 https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515
15:09:43 ack joe
15:09:44 ... existing mediaelement spec doesn't say what to do if you can't decode a frame in time
15:09:55 joesteele: i'm not clear on why this is different to a network halt
15:10:08 ... in the clients i'm working it gets treated the same way
15:10:24 ... main issue - what is the time period before something else happens
15:10:32 ack markw
15:10:34 ... i see this as a network stall not a decoder stall
15:11:24 markw: if you don't have the key you don't know how long it will take to get the key (could be seconds) so this is more similar to network stall
15:11:32 ... for decoding you know you're going to do this soon
15:11:48 q+
15:11:54 ack joe
15:11:57 ... as a user i probably don't care whether it is network or key blocking
15:12:09 joesteele: trying to think why people would think of this as decoder stall
15:12:20 ... problem might be that it is in the decoder that you detect this issue
15:12:26 q-
15:13:17 ddorwin: i separate it from network stall because we have the data, we've de-muxed it, and we're trying to decrypt
15:13:37 q+
15:13:43 joesteele: what if the container is encrypted?
15:14:11 ddorwin: we've talked about this before - you have to do something different for encrypted containers
15:14:18 ack markw
15:14:29 ... between de-muxing and decoding we know we have a problem with a key
15:14:54 markw: the behaviour on the API surface seem most similar to network stall regardless of how it gets surfaced
15:15:13 ... we could describe it as "just like a network stall" or with more detailed steps but the behaviour should be the same
15:15:15 q?
15:15:55 ddorwin: will need specific text - need suggestions in the bug please
15:16:00 Bug 19788 -What, if any, event should be fired when no key is available to decrypt the block?
15:16:09 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788
15:16:15 ddorwin: this dates to the original version of the spec before implementations
15:16:24 ... there is a needkey event for hitting initdata
15:16:33 ... and another needkey if you need a key to decrypt the current frame
15:16:41 ... second one doesn't make much sense
15:16:46 ... you don't have initdata at the time
15:16:53 ... and not much the app can do - really an error condition
15:17:06 ... we could have an event like stalled but what would an app do with that
15:17:18 David's proposal is in https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788#c8
15:17:22 ... my proposal is to remove the text that fires the needkey if we don't have the key
15:17:32 +1
15:17:35 ... and we should solve this in the previous bug if necessary
15:18:12 q+
15:18:18 ack markw
15:18:42 markw: we're assuming that if you get to this point with no key you will have got something to tell you that you need a key earlier
15:18:53 ... and you're assuming the app is already working on this
15:19:25 ddorwin: potentially encrypted stream and encrypted block encountered are the two states
15:19:40 ... propose replacing the first with encryption data encountered
15:19:54 ... for example finding a PSSH box mid-way in a stream
15:20:19 ... ideally you would have seen key reference encountered first
15:20:34 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788#c1
15:20:51 markw: would this still be needkey?
15:21:06 ddorwin: no, this just redefines needkey
15:21:17 markw: so this could result in two sessions?
15:21:20 ddorwin: yes
15:21:26 paulc: summary?
15:21:50 ddorwin: delete needkey on encrypted block encountered with no key and merge in comment 1
15:21:56 ... linked above
15:22:58 paulc: what is the next step for bug 18515?
15:23:18 ... is it still in the editor's camp to propose something?
15:23:40 ddorwin: i'd like someone to propose text and describe what the behaviour should be like - i'm not familiar with all the detail here
15:23:51 paulc: joe, could you help?
15:23:57 joesteele: i could propose some text
15:24:52 next bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553
15:24:55 paulc: moving on to the next topic in david's mail
15:25:07 Consider not firing a needkey event when a potentially encrypted stream is encountered if the key is already known
15:25:11 Bug 16553 -Consider not firing a needkey event when a potentially encrypted stream is encountered if the key is already known
15:25:23 https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553
15:25:50 ddorwin: if you hit a pssh and send the needkey for the video and then in the audio stream you hit the same pssh or if you're doing adaptive streaming you hit the same pssh again
15:26:07 ... they could be identical or not identical but represent the same keys
15:26:19 ... could be good if UA were smart enough to not refire
15:26:34 ... but this would mean apps wouldn't see the PSSH being hit
15:26:55 ... adds complexity - UA has to do this work
15:27:14 ... including synchronising if two streams hit close together
15:27:36 ... summary https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553#c10
15:27:59 Summay: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553#c10
15:28:06 ddorwin: needkey events are not that important but if an app will respond with createsession that's where the problem may lie
15:28:07 q+
15:28:14 ack adrian
15:29:38 q+
15:29:46 adrianba: i wonder if it is sufficient for the spec to allow this behaviour but not require it
15:30:13 q+
15:30:20 ddorwin: only concern is that if someone implemented that apps might depend on it and may break with
15:30:27 ... inconsistency would be my concern
15:30:37 ack joe
15:30:46 joesteele: was going to echo what david said
15:30:54 ... would be inconsistent - think we should be definitive
15:31:13 ... only case that makes sense is if the initdata is bit for bit identical
15:31:15 q+
15:31:18 ack markw
15:31:32 markw: i agree - this is a question of functional split between the app and the CDM
15:31:40 ... and who is responsible
15:31:52 ... we should keep this in the app if we can
15:31:57 ack adrian
15:31:59 ... i vote for always firing the event
15:33:49 q+
15:34:26 adrianba: perhaps this is a question for the CDM
15:34:30 q+
15:34:59 ... the CDM might eliminate this potential inconsistency by defining it for the content protection system
15:35:12 ... perhaps this is related to a later bug about keymessage not being fired
15:35:43 Later bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208
15:35:59 ... i want to avoid a situation where we make a network request for a license and then never need the result
15:36:25 ack dd
15:36:35 ack markw
15:36:47 markw: on the question of if this is cdm specific
15:36:54 ... you could take the view that this is content specific
15:37:17 ... if the content supports multiple different CDMs then they should all behave the same way
15:37:53 ... the only example when this wouldn't be the case is content with separate keys for audio and video where one system carries the same key for both and another system needs two
15:38:09 ... don't know if this is realistic
15:38:28 Do we avoid sending based on byte-for-byte duplicate or whether the key(s) are in the CDM?
15:38:31 s/the only example/an example/
15:39:05 For duplicate byte-for-byte, the application could compare.
15:39:17 The CDM is not necessarily involved in needkey events. If we try to avoid sending events based on whether the key is available, they must be.
15:39:52 ddorwin: if you don't have a key system selected you could always fire the event
15:40:10 I'm concerned about inconsistency depending on when the two initDatas are encountered. For example, if audio and video streams are demuxed at the same time, two events would be fired because the keys are not available.
15:40:12 ddorwin: but this would add to the inconsistency
15:40:56 ddorwin: you fire two events here because you have no keys but later you would not find the event
15:40:58 q+
15:41:12 ddorwin: could be more confusing
15:41:22 ack adrian
15:43:13 adrianba: agree with the first point - perhaps avoiding keymessage is the solution
15:43:33 ... on the second point, the inconsistency is the point of trying to coalesce the requests
15:43:52 ... i think i'd be happy to say always fire needkey if we can solve this in the next bug
15:44:11 If the goal is just less events, but not necessarily no extra events, the application/server still need to do some work.
15:44:24 q+
15:44:54 ack adrian
15:45:04 the application still has to include the logic
15:45:32 adrianba: my goal is not to reduce events it is to reduce network requests
15:45:53 ddorwin: i agree the end goal is to not send that network traffic - the point is how to avoid it
15:46:14 Should createSession() avoid generating a message? https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208
15:46:22 ddorwin: does the UA not fire the event or does the app see the event and not make the network request
15:46:28 paulc: next bug
15:46:54 ddorwin: in this case the app gets a needkey and creates a session and it is on the CDM to figure out if it needs to fire a keymessage to issue a license request
15:47:17 ... was hoping to close this but sounds like this might be a solution to the previous one
15:47:25 ... does the CDM know if it has all the keys
15:47:46 ... might be legitimate reasons for making a new request
15:47:48 summary: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208#c7
15:47:50 q+
15:47:54 q+
15:47:57 ack adrian
15:48:49 ack joe
15:48:55 adrianba: we have situations where we no we have all the information we need from the initdata
15:49:02 ... don't want the app to have to try to figure this out
15:49:10 ... not sure if the app could even tell
15:49:25 q+
15:49:30 joesteele: i agree - don't want the app to try to handle the information that we have in the CDM
15:50:02 ... henri also raised the question that we're leaking information by not raising this by saying we already have this key
15:50:14 ... i think we can prevent this leaking across domains - is anyone concerned about this?
15:50:26 ack dd
15:50:48 ddorwin: as i understand it CENC PSSH don't necessarily need to include all the keys
15:51:03 s/keys/key ids/
15:51:03 q+
15:51:18 ... if we had all the key ids and this was enforced then this would be easier
15:51:23 ack markw
15:51:40 markw: i think that CENC does have the key ids declared outside of the PSSH
15:51:57 ... they can appear in the fragments now too
15:52:09 ... you may not know until you get to the block that needs them
15:52:15 q+
15:52:18 ack dd
15:52:35 ddorwin: we define ISO CENC initdata as the pssh
15:52:36 q+
15:52:48 markw has joined #html-media
15:52:57 ... we have to link the pssh to the keys
15:53:07 ... the information is outside the pssh
15:53:29 markw: the browser could ask the CDM if it has all the information for these key ids
15:53:30 q-
15:53:42 markw: i still think it would be better for us to always fire the events
15:53:48 q+
15:53:59 ack adrian
15:54:36 adrianba: would like to talk to johnsim about this
15:54:44 ... he is travelling and he filed this bug
15:54:53 paulc: could you take an action to update the bug
15:54:56 adrianba: yes
15:55:15