RE: {minutes} HTML WG media telecon 2013-03-12 - EME bugs discussion

Minutes -> http://www.w3.org/2013/03/12-html-media-minutes.html



                               - DRAFT -

                  HTML Media Task Force Teleconference

12 Mar 2013

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0034.html


   See also: [3]IRC log

      [3] http://www.w3.org/2013/03/12-html-media-irc


Attendees

   Present
          +1.408.536.aaaa, joesteele, pal, +1.425.202.aabb,
          ddorwin, +1.417.671.aacc, paulc, glenn, [Microsoft],
          adrianba, markw, +1.303.661.aadd, BobLund, jdsmith

   Regrets
   Chair
          Paul Cotton

   Scribe
          Adrian Bateman

Contents

     * [4]Topics
         1. [5]Roll call, introductions and selection of scribe
         2. [6]Previous meeting minutes
         3. [7]Review of action items
         4. [8]Progression to First Public Working Draft
         5. [9]Discussion of outstanding bugs
         6. [10]Discussion of EME at next PING call
         7. [11]Adjournment
     * [12]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 12 March 2013

   trackbot, reload

   <paulc> I am a few minutes late

   <scribe> ScribeNick: adrianba

   <scribe> Scribe: Adrian Bateman

   <scribe> Agenda:
   [13]http://lists.w3.org/Archives/Public/public-html-media/2013M

   ar/0034.html

     [13] 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:
   [14]https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-me

   dia/encrypted-media.html

     [14] 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>
   [15]http://lists.w3.org/Archives/Public/public-html-media/2013M

   ar/0033.html

     [15] 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>
   [16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=18515


     [16] 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>
   [17]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788


     [17] 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
   [18]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788#c8


     [18] 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>
   [19]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19788#c1


     [19] 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:
   [20]https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553


     [20] 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>
   [21]https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553


     [21] 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
   [22]https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553#c10


     [22] https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553#c10


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


     [23] 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:
   [24]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208


     [24] 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?
   [25]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208


     [25] 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:
   [26]https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208#c7


     [26] 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
   [27]http://www.w3.org/2013/03/12-html-media-minutes.html#action

   01]

   <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

Summary of Action Items

   [NEW] ACTION: adrianba to discuss bug 19208 with johnsim
   [recorded in
   [28]http://www.w3.org/2013/03/12-html-media-minutes.html#action

   01]

   [End of minutes]

From: Paul Cotton 
Sent: Monday, March 11, 2013 4:03 PM
To: public-html-media@w3.org
Cc: David Dorwin <ddorwin@google.com> (ddorwin@google.com); Adrian Bateman; Mark Watson
Subject: {agenda} HTML WG media telecon 2013-03-12 - EME bugs discussion

The HTML WG media teleconference meeting will occur on 2013-03-14 for up to 60 minutes from 15:00Z to 16:00Z.

http://timeanddate.com/s/2cad

Tokyo midnight, Amsterdam/Oslo 16:00, London/Dublin 15:00, New Jersey/York 11:00, Kansas City 10:00, Seattle/San Francisco 08:00.
NOTE: North America is now on Daylight Savings Time.

Chair of the meeting: Paul Cotton
Scribe: TBD

(See the end of this email for dial-in and IRC info.)

== Agenda ==

1. Roll call, introductions and selection of scribe

2. Previous meeting minutes
http://www.w3.org/2013/02/19-html-media-minutes.html 

3. Review of action items
https://www.w3.org/html/wg/media/track/

None.

4. Baseline documents 

a) Encrypted Media Extensions editor's draft
http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html 
Last updated on Feb 26.  

b) Candidate FPWD
https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media-fpwd.html


5. Progression to First Public Working Draft

a) CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD) 
http://lists.w3.org/Archives/Public/public-html-admin/2013Jan/0102.html

Team's statement about scope:
http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0122.html

Chair's CfC decision:
http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0123.html

Status: Paul is working with the WG Chairs on the next steps.

6. Discussion of outstanding bugs

a) Encrypted Media Extensions bugs: 
http://tinyurl.com/7tfambo

Status as of Mar 11: 39 bugs (see list at end of agenda)

b) [EME] Bugs for discussion this week: key not available behavior and when to fire needkey events
http://lists.w3.org/Archives/Public/public-html-media/2013Mar/0033.html 

i) What behavior and event should occur when the key for an encrypted block is not available?

ii) Should the user agent automatically avoid firing events, creating sessions, or generating key request messages when the key(s) are already known or the Initialization Data has already been encountered?

7. Other Business

a) Discussion of EME at next PING call
http://lists.w3.org/Archives/Public/public-html-media/2013Feb/0081.html 

8. Chair and Scribe for next meeting

9. Adjournment

== Dial-in and IRC Details ==

Zakim teleconference bridge:
   +1.617.761.6200, conference 63342 ("media")
https://www.w3.org/Guide/1998/08/teleconference-calendar#s_5366


Supplementary IRC chat (logged):
   #html-media on irc.w3.org port 6665 or port 80


Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329

39 bugs found. 
IDâ–²
Product
Comp
Assignee
Status
Resolution
Summary
Changed
16540
HTML WG 
Encrypte 
ddorwin@google.com 
ASSI 
--- 
Provide guidelines on Key System string format 
Thu 20:27 
16541
HTML WG 
Encrypte 
adrianba@microsoft.com 
ASSI 
--- 
Update examples to use async XHR 
2012-08-28 
16553
HTML WG 
Encrypte 
ddorwin@google.com 
ASSI 
--- 
Consider not firing a needkey event when a potentially encrypted stream is encountered if the key is already known 
Sun 05:28 
16616
HTML WG 
Encrypte 
ddorwin@google.com 
ASSI 
--- 
Support change of key during playback 
Sat 03:49 
16617
HTML WG 
Encrypte 
adrianba@microsoft.com 
ASSI 
--- 
Consider more granular error reporting 
2012-08-28 
16737
HTML WG 
Encrypte 
adrianba@microsoft.com 
ASSI 
--- 
Should MEDIA_KEYERR_CLIENT be two separate errors? 
2012-09-04 
16738
HTML WG 
Encrypte 
ddorwin@google.com 
ASSI 
--- 
Provide more guidance on heartbeat implementation 
2012-12-11 
16857
HTML WG 
Encrypte 
adrianba@microsoft.com 
ASSI 
--- 
MEDIA_ERR_ENCRYPTED should exclude decrypt failure 
2012-09-04 
17199
HTML WG 
Encrypte 
watsonm@netflix.com 
ASSI 
--- 
Provide examples for and get feedback on Key Release 
2013-02-15 
17203
HTML WG 
Encrypte 
adrianba@microsoft.com 
ASSI 
--- 
Should session ID be required? 
2012-12-11 
17660
HTML WG 
Encrypte 
adrianba@microsoft.com 
REOP 
--- 
need token relative with user identity for a new generateKeyRequest parameter 
2012-10-31 
17673
HTML WG 
Encrypte 
adrianba@microsoft.com 
REOP 
--- 
Define Initialization Data for implementations that choose to support the ISO Base Media File Format 
2013-01-27 
17750
HTML WG 
Encrypte 
ddorwin@google.com 
ASSI 
--- 
Define the behavior MediaKeySession close() and clearing the keys attribute 
2012-10-31 
18515
HTML WG 
Encrypte 
ddorwin@google.com 
ASSI 
--- 
Provide more details on behavior of the media element when the key for an encrypted block is not available 
15:23:20 
18928
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
MediaKeySession IDL should list EventHandler attributes for onkeyadded, onkeymessage, and onkeyerror 
2012-12-04 
19009
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
A MediaKeys should belong to a single HTMLMediaElement. 
2013-02-11 
19096
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Add 'type' attribute to MediaKeyNeededEvent 
2012-12-04 
19156
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Switching decoders when the key system is specified 
2013-03-02 
19208
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Keymessage event not needed when Key System already has Key 
Sun 05:16 
19788
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
What, if any, event should be fired when no key is available to decrypt the block? 
Sun 04:58 
19805
HTML WG 
Encrypte 
ddorwin@google.com 
ASSI 
--- 
Restriction to only use initData in createSession is too restrictive 
2012-11-01 
19809
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Specify which portion of addKey() algorithm to run when updating license for a key 
2012-11-01 
19810
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Should key IDs be required in content and addKey()'s parameter? 
2012-12-11 
20335
HTML WG 
Encrypte 
adrianba@microsoft.com 
ASSI 
--- 
Replace canPlayType() with static bool isTypeSupported() on MediaKeys 
2013-01-12 
20336
HTML WG 
Encrypte 
ddorwin@google.com 
NEW 
--- 
Revert addition of keySystem attribute to HTMLSourceElement 
2013-01-08 
20338
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Explicitly specify whether initData is required for Clear Key 
2012-12-11 
20552
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Encrypted Block Encountered algorithm should not reference Initialization Data 
2013-01-02 
20622
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
SessionID may be assigned asynchronously in MediaKeys.createSession 
2013-01-09 
20688
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Provide more details on when keyadded should be fired 
2013-01-16 
20689
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Specify how CDM should indicate successful completion with no message for server 
2013-01-16 
20691
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
Should createSession()'s type parameter be required? 
2013-01-16 
20798
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
keySystem strings should be compared case-sensitively 
Thu 20:27 
20944
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
EME should do more to encourage/ensure CDM-level interop 
2013-02-26 
20963
HTML WG 
Encrypte 
adrianba@microsoft.com 
REOP 
--- 
EME is technically incomplete 
2013-02-26 
20965
HTML WG 
Encrypte 
adrianba@microsoft.com 
REOP 
--- 
EME results in a loss of control over security and privacy. 
2013-02-26 
20966
HTML WG 
Encrypte 
adrianba@microsoft.com 
REOP 
--- 
EME design trivializes the demanded loss of control of security and privacy demanded. 
2013-02-26 
20991
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
MediaKeys constructor failure case refers to unknown "new object". 
2013-02-14 
21155
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
EME should be explicit about its relationship with Web Platform APIs that allow video frames and audio samples to be extracted from an HTMLMediaElement 
2013-02-28 
21203
HTML WG 
Encrypte 
adrianba@microsoft.com 
NEW 
--- 
EME leaks information cross-origin 
15:23:50

Received on Tuesday, 12 March 2013 16:08:21 UTC