- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 8 May 2013 12:38:45 +0300
- To: "<public-html-media@w3.org>" <public-html-media@w3.org>
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/
Received on Wednesday, 8 May 2013 09:39:17 UTC