Re: The role of MP4 pssh boxes in EME

Henri,

This is a good question.

ISO Common Encryption defines a common method for the media data to be
encrypted and to indicate the "KeyID" of the key with which each sample is
encrypted.

However, most existing DRM systems need some kind content-specific
"initialization data" that is used to generate the license challenge
message and that contains more than just the KeyID.

ISO defined the PSSH box to allow this initialization data to be embedded
in files.

In EME we require this initialization data to be provided by the
application in the createSession() call. We also ask the UA to report up
any initialization data we find in the file to the application in the
needkey event (that "one or more" should be a "zero or more").

So, presently, an application designer can decide whether to include this
DRM-specific information in the file or to provide it some other way to the
client. If you choose the former approach then, yes, adding support for a
new DRM involves repackaging all the media files to include the new header
(in practice, we end up doing a re-package once a year or so anyway for
other reasons).

It would be a good question to ask the DRM vendors whether they really
*need* this DRM-specific header, or whether they could also operate in a
mode where the Initialization Data contains only the DRM-independent Common
Encryption information (specifically the KeyID - which is specified in the
Track Encryption Box and cenc sample group descriptions).

...Mark



On Wed, May 8, 2013 at 2:38 AM, Henri Sivonen <hsivonen@iki.fi> wrote:

> I took a look at the sample media from YouTube's DASH/MSE/EME test app
> at http://dash-mse-test.appspot.com/media.html
>
> Looking at
> http://yt-dash-mse-test.commondatastorage.googleapis.com/car_cenc-20120827-85.mp4
> I observed that the file contains PlayReady-specific data as
> UTF-16-encoded XML and also the same data as JSON (for another DRM
> scheme? for Widevine maybe?).
>
> I considered the possibility that the pssh boxes might be there for
> compatibility with legacy (non-EME) players, but the EME spec suggests
> otherwise:
> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#iso-init-data
> says "In addition, one or more protection system specific heder boxes
> ('pssh') will be concatenated after the 'sinf' box." So not only are
> pssh boxes exposed via EME but "one or more" suggests that they have
> to be present.
>
> Having protection system specific header data inside the media files
> themselves seems to contradict the selling point of CENC+EME that the
> media files are independent of the Key System and that there is,
> therefore, an expectation of interop on the media file level even if
> not on the Key System level.
>
> How is the pssh box data be expected to be processed when processing
> initialization data? If a content provider adds support for another
> Key System, do they need to rewrite all their media files with pssh
> boxes for the new Key System? Why is it necessary to have at least one
> pssh box and to expose the pssh boxes via EME?
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>