[Bug 24323] New: Rename "First Time a Key Reference is Encountered" algorithm and remove key ID checks from Container Guidelines subsections

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24323

            Bug ID: 24323
           Summary: Rename "First Time a Key Reference is Encountered"
                    algorithm and remove key ID checks from Container
                    Guidelines subsections
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org
        Depends on: 16553, 19788, 21855

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 18 January 2014 01:48:05 UTC