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> 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]
> *Sent:* Monday, July 09, 2012 8:18 PM
> *To:* 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