HTML Media Task Force Teleconference -- 12 Mar 2013

<trackbot> Date: 12 March 2013

trackbot, reload

<paulc> I am a few minutes late

<scribe> ScribeNick: adrianba

<scribe> Scribe: Adrian Bateman

<scribe> Agenda: http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0034.html

Roll call, introductions and selection of scribe

paulc: completed

Previous meeting minutes

paulc: no comments received

Review of action items

paulc: done

<paulc> Editor's draft updated on feb 26: https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html

Progression to First Public Working Draft

paulc: discussing with the other co-chairs
... asking for more detail about how we resolved issues
... hope to have more this week

Discussion of outstanding bugs

<paulc> [EME] Bugs for discussion this week: key not available behavior and when to fire needkey events

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0033.html

paulc: David sent this message to the list for discussion

ddorwin: these bugs have been put off - summarised in the bugs and put this mail together
... break down to what should we do if we need to decrypt a block and there is no key
... the other is reducing firing some events
... first is what to do if there aren't keys - should we keep playing, pause, or something else

<paulc> Bug 18515 -Provide more details on behavior of the media element when the key for an encrypted block is not available

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515

ddorwin: existing mediaelement spec doesn't say what to do if you can't decode a frame in time

joesteele: i'm not clear on why this is different to a network halt
... in the clients i'm working it gets treated the same way
... main issue - what is the time period before something else happens
... i see this as a network stall not a decoder stall

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
... for decoding you know you're going to do this soon
... as a user i probably don't care whether it is network or key blocking

joesteele: trying to think why people would think of this as decoder stall
... problem might be that it is in the decoder that you detect this issue

ddorwin: i separate it from network stall because we have the data, we've de-muxed it, and we're trying to decrypt

joesteele: what if the container is encrypted?

ddorwin: we've talked about this before - you have to do something different for encrypted containers
... between de-muxing and decoding we know we have a problem with a key

markw: the behaviour on the API surface seem most similar to network stall regardless of how it gets surfaced
... we could describe it as "just like a network stall" or with more detailed steps but the behaviour should be the same

ddorwin: will need specific text - need suggestions in the bug please

<paulc> Bug 19788 -What, if any, event should be fired when no key is available to decrypt the block?

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788

ddorwin: this dates to the original version of the spec before implementations
... there is a needkey event for hitting initdata
... and another needkey if you need a key to decrypt the current frame
... second one doesn't make much sense
... you don't have initdata at the time
... and not much the app can do - really an error condition
... we could have an event like stalled but what would an app do with that

<paulc> David's proposal is in https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788#c8

ddorwin: my proposal is to remove the text that fires the needkey if we don't have the key

<joesteele> +1

ddorwin: and we should solve this in the previous bug if necessary

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
... and you're assuming the app is already working on this

ddorwin: potentially encrypted stream and encrypted block encountered are the two states
... propose replacing the first with encryption data encountered
... for example finding a PSSH box mid-way in a stream
... ideally you would have seen key reference encountered first

<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788#c1

markw: would this still be needkey?

ddorwin: no, this just redefines needkey

markw: so this could result in two sessions?

ddorwin: yes

paulc: summary?

ddorwin: delete needkey on encrypted block encountered with no key and merge in comment 1
... linked above

paulc: what is the next step for bug 18515?
... is it still in the editor's camp to propose something?

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

paulc: joe, could you help?

joesteele: i could propose some text

<ddorwin> next bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553

paulc: moving on to the next topic in david's mail

Consider not firing a needkey event when a potentially encrypted stream is encountered if the key is already known

<paulc> Bug 16553 -Consider not firing a needkey event when a potentially encrypted stream is encountered if the key is already known

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553

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
... they could be identical or not identical but represent the same keys
... could be good if UA were smart enough to not refire
... but this would mean apps wouldn't see the PSSH being hit
... adds complexity - UA has to do this work
... including synchronising if two streams hit close together
... summary https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553#c10

<ddorwin> Summay: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553#c10

ddorwin: needkey events are not that important but if an app will respond with createsession that's where the problem may lie

adrianba: i wonder if it is sufficient for the spec to allow this behaviour but not require it

ddorwin: only concern is that if someone implemented that apps might depend on it and may break with
... inconsistency would be my concern

joesteele: was going to echo what david said
... would be inconsistent - think we should be definitive
... only case that makes sense is if the initdata is bit for bit identical

markw: i agree - this is a question of functional split between the app and the CDM
... and who is responsible
... we should keep this in the app if we can
... i vote for always firing the event

adrianba: perhaps this is a question for the CDM
... the CDM might eliminate this potential inconsistency by defining it for the content protection system
... perhaps this is related to a later bug about keymessage not being fired

<paulc> Later bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208

adrianba: i want to avoid a situation where we make a network request for a license and then never need the result

markw: on the question of if this is cdm specific
... you could take the view that this is content specific
... if the content supports multiple different CDMs then they should all behave the same way
... an 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
... don't know if this is realistic

<ddorwin> Do we avoid sending based on byte-for-byte duplicate or whether the key(s) are in the CDM?

<ddorwin> For duplicate byte-for-byte, the application could compare.

<ddorwin> 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.

ddorwin: if you don't have a key system selected you could always fire the event

<ddorwin> 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.

ddorwin: but this would add to the inconsistency
... you fire two events here because you have no keys but later you would not find the event
... could be more confusing

adrianba: agree with the first point - perhaps avoiding keymessage is the solution
... on the second point, the inconsistency is the point of trying to coalesce the requests
... i think i'd be happy to say always fire needkey if we can solve this in the next bug

<ddorwin> If the goal is just less events, but not necessarily no extra events, the application/server still need to do some work.

<ddorwin> the application still has to include the logic

adrianba: my goal is not to reduce events it is to reduce network requests

ddorwin: i agree the end goal is to not send that network traffic - the point is how to avoid it

<paulc> Should createSession() avoid generating a message? https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208

ddorwin: does the UA not fire the event or does the app see the event and not make the network request

paulc: next bug

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
... was hoping to close this but sounds like this might be a solution to the previous one
... does the CDM know if it has all the keys
... might be legitimate reasons for making a new request

<ddorwin> summary: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208#c7

adrianba: we have situations where we no we have all the information we need from the initdata
... don't want the app to have to try to figure this out
... not sure if the app could even tell

joesteele: i agree - don't want the app to try to handle the information that we have in the CDM
... henri also raised the question that we're leaking information by not raising this by saying we already have this key
... i think we can prevent this leaking across domains - is anyone concerned about this?

ddorwin: as i understand it CENC PSSH don't necessarily need to include all the key ids
... if we had all the key ids and this was enforced then this would be easier

markw: i think that CENC does have the key ids declared outside of the PSSH
... they can appear in the fragments now too
... you may not know until you get to the block that needs them

ddorwin: we define ISO CENC initdata as the pssh
... we have to link the pssh to the keys
... the information is outside the pssh

markw: the browser could ask the CDM if it has all the information for these key ids
... i still think it would be better for us to always fire the events

adrianba: would like to talk to johnsim about this
... he is travelling and he filed this bug

paulc: could you take an action to update the bug

adrianba: yes

<scribe> ACTION: adrianba to discuss bug 19208 with johnsim [recorded in http://www.w3.org/2013/03/12-html-media-minutes.html#action01]

<trackbot> Created ACTION-10 - Discuss bug 19208 with johnsim [on Adrian Bateman - due 2013-03-19].

Discussion of EME at next PING call

paulc: did anyone attend and can give a summary?

markw: i attended and presented our work
... not much of a conclusion - happy to be briefed and keen to be involved in the privacy discussion

ddorwin: we emphasised that this is the start of the process

<markw> .me Noise was probably me

paulc: we will meet in two weeks and will have something to report on the CfC by then
... David, thanks for helping to build the agenda
... hope we made some progress today

ddorwin: complex bugs with no clear solution - please update the bugs

paulc: perhaps we could go broad next time to cover items at a higher level

Adjournment

paulc: adjourned

trackbot, end telcon

- DRAFT -

HTML Media Task Force Teleconference

12 Mar 2013

Attendees

Contents