W3C home > Mailing lists > Public > public-html-media@w3.org > October 2015

EME Initialization Data Correlation

From: Greg Rutz <G.Rutz@cablelabs.com>
Date: Fri, 9 Oct 2015 16:31:44 +0000
To: "public-html-media@w3.org" <public-html-media@w3.org>
Message-ID: <D23D4811.42063%g.rutz@cablelabs.com>
I’m the maintainer for the DRM support system in the dash.js<https://github.com/Dash-Industry-Forum/dash.js> open source, MSE/EME-based, MPEG-DASH player library.  A DRM-related bug<https://github.com/Dash-Industry-Forum/dash.js/issues/709> was filed recently against the player and I have some doubts about how to solve the problem.  The behavior of EME is somewhat responsible for the symptoms behind the problem and so I’m looking to this community to provide some guidance.

Initialization Data (PSSH) may be carried in both the DASH manifest and in the media stream, and for certain DRM systems, they may not be byte-for-byte copies of each other even though they represent the exact same keys/rights.  If the application can not discern the difference between two instances of Initialization Data, it can not prevent redundant requests to the license server.

Since the PSSH is almost always an opaque blob of data recognizable only by the CDM and license sever, should the EME spec mandate that the CDM only send ‘encrypted’ events when the CDM actually needs the application to take action?  Or is this something that the InitializationData-specific format specs need to provide? (how to exactly correlate Initialization data so the app knows when to discard ‘encrypted’ events)

Also, should the EME spec call out that CDMs should not produce an error if they are updated with key information that they already have?  I mention this because one of the major browsers does send such an error (which leads to the bug report described above).

Greg Rutz
Lead Architect
303-931-6769 (m)
303-661-3796 (o)
Received on Friday, 9 October 2015 16:32:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:06 UTC