EME registry: Add entry for MPEG-2 TS CENC

[ddorwin]

Originally filed by @boblund as bug 26738. This specifically refers to ISO/IEC 23001-9:2014: Common encryption of MPEG-2 transport streams.

This should use the existing cenc Initialization Data Type and will be simpler to implement after issue #105 is resolved. It would also be good to have some experts in this spec volunteer to review the changes.

[ghost]

Agree.
In ISO/IEC 23001-7 Common Encryption, 2nd Edition; initialization data is specified as an XML element cenc:pssh that applies to any media format, such as an ISO Base Media file, MPEG-2 Transport Stream, or Matroska. In the case where a 'pssh' box also occurs in the ISO Media file header, the element in the manifest takes precedence (as well a preceding in time). DASH application specifications usually recommend storing the initialization information in the cenc:pssh element in the MPD to allow licensing flexibility with multiple or dynamic manifests, without creating and storing multiple copies of the media files (e.g. multiple entities providing different licenses for the same content, switching from test to deployment, load balancing, geo fencing, etc.).

The cenc:pssh element contains a base64 encoded 'pssh' box for character representation in XML that is binary equivalent to a 'pssh' box stored in an ISO Media file, but the box header is irrelevant to M2TS, etc., except that it allows the same initialization data parser for all media formats described by an XML manifest, like DASH MPD. The 'pssh' box header provides the DRM SystemID and payload size, which are independent of the Common Encrypted container and elementary stream format being played.
We need a better way to indicate when a 'pssh' box is license acquisition information or keys; so a player will know whether to fetch a license or let the CDM access the embedded key(s). The V1 'pssh' box includes a KID index that could distinguish both functions if used for that purpose.

[ddorwin]

Before we publish an entry for MPEG-2 TS (e.g. "video/mp2t"), we should be careful to avoid repeating the issues in #149 (comment).

[ddorwin]

Triaging per https://lists.w3.org/Archives/Public/public-html-media/2016Mar/0003.html.

[paulbrucecotton]

@ddorwin : In Bug 26738 https://www.w3.org/Bugs/Public/show_bug.cgi?id=26738 @boblund proposed an entry for MPEG-2 TS (e.g. "video/mp2t" ). Will this entry be published as part of resolving ISSUE-105 and ISSUE-106 or will a subsequent change be required to resolve this issue? If so who is on point to make the subsequent change?

[ddorwin]

#105 restructured the registry and its pages. Resolving this issue would involve adding a new entry and corresponding page to the stream format registry at https://w3c.github.io/encrypted-media/format-registry/stream/. It should be able to reference the "cenc" definition like the mp4 entry does.

I expect that those interested in this additional format will discuss, generate, and work on a pull request. The issues I referenced in my first comment above should also be considered.

Note that this is not tied to the progress or maturity of V1. It is assigned to V1NonBlocking only as an indication that we expect it to happen in parallel and not be part of VNext.

[boblund]

The original use case that drove bug 26738 no longer applies. Are there content producers, service providers or browser vendors who want EME support for cenc in mpeg2 transport streams?

[paulbrucecotton]

I propose that we close this issue if no one responds to @boblund's above request for input by Tue May 17. If anyone objects to closure then I proposed we mark this issue as VNext.

[paulbrucecotton]

@ddorwin: Since no one has objected to closing this issue, please close this issue and remove the "help wanted" and "needs author input" labels.

[ddorwin]

Closing per the discussion above.