- From: <bugzilla@jessica.w3.org>
- Date: Tue, 08 Jul 2014 00:57:34 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26207 --- Comment #1 from Jerry Smith <jdsmith@microsoft.com> --- IsTypeSupported currently has an optional DOMString capability attribute that might be used to abstract some set of requirements for HD or UHD playback. This could be a proprietary label per CDM or a label that represents some industry agreement among providers and content owners on a standard for playback. These don't currently exist. I see three options for dealing with this: 1. Limit EME to the DOMString capability attribute we currently have. a. This MAY be sufficient, but could depend on proprietary labels. 2. Provide some way to pre-check a license without the delay of downloading content, attempting playback and failing. a. This MIGHT be possible without a lot of EME change, but is TBD. 3. Provide a way to check against a set of criteria relevant to UHD playback. a. This seems like the most direct approach, but has some negatives listed below. A capabilities query has the advantage of letting content owners tune their playback bar when there isn't yet a consensus bar to meet. A list of capabilities should include: 1. Hardware DRM 2. Hardware media pipeline 3. Display link protection 4. Media parameters needed to take advantage of UHD content Returning capabilities data has at least a couple of negatives: 1. Returned data and even pass/fail verification on a specific set of capabilities might be used for fingerprinting. This could require limiting the capabilities returned or adding a way for users to approve disclosing the data. 2. Any specific set of criteria could omit one that eventually becomes important to content owners. The criteria needs to be reasonably specific to insure it is evaluated consistently on different browser/CDM implementations. I propose modifying IsTypeSupported to return either the capability DOMString OR a specific mediaCapabilities dictionary that attempts to answer key playback questions without returning a large amount of fingerprinting data. It would be queried as a set and return our equivalent of a pass/fail response ("maybe", "probably"). A draft WebIDL for discussion is included below: static IsTypeSupportedResult isTypeSupported(DOMstring keySystem, optional DOMString initDataType, optional DOMString contentType, optional mediaCapabilities capability); typedef (capabilities or DOMString) mediaCapabilities; dictionary capabilities { bool hardwareMediaDecrypt; bool hardwareMediaPipeline; DOMString displayLinkProtection; bool timeBasedRestrictions short minDisplayLines short audioChannels; short colorBitDepth; }; -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 8 July 2014 00:57:37 UTC