RE: [EME] Specification Question, do we really need canPlayType("codecs","Key System")?

Hello Eric,

Your example seems to include two assumptions. Please correct me if I am mistaken.

1. You said "the UA got the initialization data(using Key System A)" Do you assume the Key System extracts the initialization data from the media file?

Generally today, DRM initialization data is provided to the key system. This can happen from an application or from the media stack.

--

2. You said "the app will use other type media file format + key system (B,C) to test the UA ability". Do you mean that key systems B and C cannot be used with the same media file format?

This is not always true. For example, the Common Encryption standard enables multiple key systems to be used on the same media file, same format. This is done with the "Protection System Specific Header box" ('pssh'), one for each key system.

The 'pssh' contain the key system identifier and initialization data. They can be in multiple locations. For example, multiple 'pssh' could be in the media itself, or stored together in an Initialization Segment in the cloud, or provided in a DASH Media Presentation Description file, each in a separate ContentProtection element, parsed by the JavaScript application.

So the same media file can be protected by multiple key systems, and the initialization data might not be in the media at all.

This is important to understand the need for canPlayType(, keySystem).

-----

For EME I believe there are six scenarios that matter, the cross-product of two conditions:

1. Whether the initialization data is in the media or elsewhere (application or cloud, effectively the same from the API perspective).

2. how many of the key systems supported for the media are supportable by the UA - i.e. it has a CDM for that key system. The answer is either 0, 1, or more then 1.

Call these scenarios media-0, media-1, media-N, app-0, app-1, app-N.

-----

Returning to your example. It appears to be "media-0". That is, the initialization data for Key System A is in the media file and the UA has no support for Key System A.

The difference between the media- and the app- scenarios is whether needkey firing or canPlayType() initiates the generateKeyRequest() action.

Media-
Playback generates a needkey event, passing the initialization data to the JA. The JA does canPlayType() with the Key System GUID or GUIDs from the initialization data.

App-
Before playback attempt, JA has initialization data, including Key System GUID or GUIDs.

---
A more interesting scenario is app-N. In this case the JA has the initialization data before the media stack has become involved, and it is for multiple key systems, all of which can be used with the same media, and more than one of them is supported by the UA. The JA needed to interrogate the UA to find out which are supported, and then decide which one to use.

In both cases, JA calls CanPlayType() to determine what to do.

App-0/Media-0 ... no key system supported by the UA works
App-1/Media-1 ... one key system works. generateKeyRequest()
App-N/Media-N ... more than one key system would work. JA decides which one and then does generateKeyRequest()

Make sense?

John

John C. Simmons | Media Platform Architect | Microsoft Corporation | direct 425-707-2911 | mobile 425-269-5759


From: sunyang (eric) [mailto:sun.yang.nj@gmail.com]
Sent: Tuesday, July 10, 2012 5:45 AM
To: John Simmons
Cc: Sunyang (Eric); public-html-media@w3.org
Subject: Re: [EME] Specification Question, do we really need canPlayType("codecs","Key System")?

Thanks John for your detailed analysis, but I still has some questions, see below description:

before the UA fire needKey,

the UA got the initialization data(using Key System A), so when UA can not support key system A from the initData or other meta data of the media file, the app will use other type media file format+key system(B, C) to test the UA's ablility?

In short the UA can not recognize the initData's key system A, so app will use other key system(B,C) to test the UA whether can support other key system or not, right?

So canPlayType is used to test other key system(B,C not A) with the UA.

If app still use key system A and canPlayType to test the UA, it will make no sense, because the UA does not support key system A.

If the canPlayType find the UA support key system B, the app will change a new media source supporting key system B for the UA (feasible?)?

On Tue, Jul 10, 2012 at 2:45 PM, John Simmons <johnsim@microsoft.com<mailto:johnsim@microsoft.com>> wrote:
The initialization data may not be in the media content. For example, a DASH MPD - live or on-demand - with an initialization segment in the cloud. In addition, there may be more than one CDM available to the UA.

This raises the more general question regarding the scenarios that must be supported by EME.

Where the initialization data resides:

1.  in the media content

2.  in an initialization segment in the cloud

3.  all or in part conveyed with the application (e.g. DASH MPD parsed by the JavaScript which includes ContentProtection elements associated with a Key System)

How many key systems are supported by the media
a. one key system
b. multiple key systems (e.g. common encryption)

How many key systems are on the device support the media
x. none that match the media key system(s)
y. one that matches the media key system(s)
z. multiple that match the media key system(s)

I believe all of these (1-3) x (a-b) x (x-z) = 18 scenarios may occur. And at least some of them require canPlayType() extension. Does this make sense?

John
________________________________
John C. Simmons | Media Platform Architect | Microsoft Corporation | direct 425-707-2911  | mobile 425-269-5759

From: Sunyang (Eric) [mailto:eric.sun@huawei.com<mailto:eric.sun@huawei.com>]
Sent: Monday, July 09, 2012 8:18 PM
To: public-html-media@w3.org<mailto:public-html-media@w3.org>
Subject: [EME] Specification Question, do we really need canPlayType("codecs","Key System")?

Does the UA decide Key System based on initialization data of media content?

If the needKey event have not reported Key System to app, it means UA cannot recognize the initData's encrypted mechanism, this may mean that the UA does not support this Key System.

When we touch the UA with canPlayType("codecs" , "key system"), I think we are just trying to find what key systems are supported for certain media formats or containers, but if the UA does not recognize the content's key system, how can it support the key system we embedded in canPlayType.

If we choose a different key system to test the UA, and the UA support, does it mean we need to abort the media resource fetch algorithm and change to a different content format encrypted by supported key system?

So I doubt the real sense of canPlayType extension for key system detection, why not let needKey event report the codesc+key system pairs list to app when the UA cannot recognize the key system from the initialization data? Even if we report this information, the app will change to anther encrypted media source supported by the UA?



Yang
Huawei




--
Yang
Huawei