This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24323 - Rename "First Time a Key Reference is Encountered" algorithm and remove key ID checks from Container Guidelines subsections
Summary: Rename "First Time a Key Reference is Encountered" algorithm and remove key I...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on: 16553 19788 21855
Blocks:
  Show dependency tree / graph
 
Reported: 2014-01-18 01:48 UTC by David Dorwin
Modified: 2014-04-29 00:40 UTC (History)
5 users (show)

See Also:

Attachments

Description David Dorwin 2014-01-18 01:48:03 UTC 
I believe the current intent is that a needkey event is always fired when Initialization Data is encountered.

This decision came out of the discussion of bug 21855 and bug 16553 and the decision to essentially not fix them.

I believe one outcome was that we do not want UAs to track encountered Initialization Data or key IDs or to depend on a CDM when determining whether to fire a needkey event.

Thus, there are two separate but related changes we need to make:
1) Rename the "First Time a Key Reference is Encountered" algorithm since it does not matter whether a key reference (key ID, PSSH, etc.) has been seen before.
2) Remove key ID checks from both Container Guidelines subsections.


#1:
The name "First Time a Key Reference is Encountered" came from bug 19788, but I believe that decision is superseded by bug 21855 and bug 16553. The algorithm does not check if this is first time a key is referenced, so we need a new title. 

The algorithm currently says to run its steps "when the media element encounters a source that may contain encrypted blocks or streams" and includes a step (2) that says "If Initialization Data was encountered..." This allows something other than Initialization Data to trigger this algorithm.

I don't believe this is possible with WebM or BMFF/MP4, but a container could in theory have a single bit that indicates encryption and have Initialization Data later (or not at all). Should we require Initialization Data and that encountering it be the first indication that the stream may be encrypted? That is more limiting but simpler to specify and covers all known use cases. If so, I think "Initialization Data Encountered" is an appropriate algorithm name and we can remove at least one step. Otherwise, we may want to revert to the original "Potentially Encrypted Stream Encountered" name.

#2:
This just removes some obsolete and confusing text that should have been removed as part of https://dvcs.w3.org/hg/html-media/rev/84be32b27d5d for bug 16553.

WebM:
"An event will be fired for each new key ID (in ContentEncKeyID) encountered for which a key is not already known."
==> "An event will be fired for each new key ID (in ContentEncKeyID) encountered."

ISO BMFF:
"Note that if there is already an active Key System CDM and the key storage for that Key System already contains the key associated with the Key ID, there is no need to generate a needkey event."
==> TBD text. I updated bug 17673.
Comment 1 Joe Steele 2014-02-18 23:07:38 UTC 
Re: #1
The name change to "Initialization Data Encountered" sounds fine. 

However the Initialization Data for CENC (array of PSSHs) is not required to be in the content stream per my copy of ISO/IEC FDIS 23001-7 section 8.1.1. Check me on this, I am trying to dig up the latest version. It can be provided instead directly by the web application, for example by deriving it from data in the MPD. 

I agree that you should setup a MediaKeySession prior to decryption (you could even skip that in some cases, but possibly not useful) but that may be driven directly by the web application, not by a needkey event sent from the UA. 

So I am not sure what step you are proposing to skip. 

Re: #2
WebM text sounds fine.
Comment 2 David Dorwin 2014-02-19 02:23:50 UTC 
(In reply to Joe Steele from comment #1)
> However the Initialization Data for CENC (array of PSSHs) is not required to
> be in the content stream per my copy of ISO/IEC FDIS 23001-7 section 8.1.1.
> Check me on this, I am trying to dig up the latest version. It can be
> provided instead directly by the web application, for example by deriving it
> from data in the MPD. 

needkey is optional to the EME flow. If the Initialization Data is not present, this algorithm will never run. Initialization Data specified in the MPD can still be provided to createSession().

Is the 'sinf' box still required even if 'pssh' boxes are not? Otherwise, I'm not sure how user agents would know that the stream may contain encrypted content so that they might alter their initialization path if necessary. Do we need to place any restrictions on the CENC content that is supported by EME?
Comment 3 Joe Steele 2014-02-19 19:06:45 UTC 
'sinf' boxes are required even though 'pssh' boxes are not. I don't know that we need to place any additional restrictions on CENC content. 

User agents could also tell that encryption is present when they run into 'tenc' boxes in the content, or the SampleGroupDescriptionBox 'sgpd' could contain this information as well.
Comment 4 Adrian Bateman [MSFT] 2014-02-21 22:59:15 UTC 
I have updated the spec to change the name of the section and amended the WebM text. We can update the ISO BMFF text as part of bug 17673.
https://dvcs.w3.org/hg/html-media/rev/afb43229b0a9
Comment 5 David Dorwin 2014-03-04 16:06:17 UTC 
The section is now named "Initialization Data Encountered", but the algorithm is to be "run when the media element encounters a source that may contain encrypted blocks or streams".

We should probably make that sentence consistent:
"The following steps are run when the media element encounters Initialization Data in the source during the resource fetch algorithm:"

Then drop "If Initialization Data was encountered and " from step 2.
Comment 6 David Dorwin 2014-03-25 00:55:46 UTC 
Reopened per comments above.
Comment 7 David Dorwin 2014-04-29 00:40:14 UTC 
https://dvcs.w3.org/hg/html-media/rev/de0a073d6c16 addresses comment #5.