- From: Hans Schmucker <hansschmucker@gmail.com>
- Date: Sat, 18 Jan 2014 12:57:38 +0100
- To: public-html@w3.org
- Message-ID: <CAMtPrS92+e5Z8fFJxbDHi6F4zkKnQiU6nd-DeAC=eOZ+G0oTgQ@mail.gmail.com>
Hello, there's a slight problem with how Encrypted Media is handled by other web standards, if the user agent is unable to access the content, because the CDM is an external application/library. The easiest case is the case of the Canvas 2D context trying to draw a protected video, so I'm trying to solve this issue first and extrapolate from there. On the Canvas2DContext mailing list, I've asked about it and they think that it would probably be best if media elements in general would include attributes indicating protected content, that the 2D context and other standards could reference, instead of defining "if the element is a video element and the element is protected with EME and the CDM is indicating that the content can not be drawn to canvas" over and over again. There really aren't a lot of requirements for these attributes... about the only thing that would have to be decided is how many... do we need one for audio? A separate for subtitles or meta data? Or is it reasonable to assume that if any one channel is protected, then an unprotected second channel wouldn't be much use anyway? 4.8.10 Media elements readonly attribute boolean videoProtected = false; readonly attribute boolean audioProtected = false; The videoProtected may be set by any implementation indicating to other APIs and script access that the content of the frame, including visual information such as subtitles will not be available for anything but direct drawing to the screen. The attribute may change value at any given time, depending on the result of video decoding process. The description of the audioProtectes attribute is mostly identical, but deals with audio processing. Seems like a useful set of attributes, but since video would also limit access to subtitles, there might be unintended and unnecessary accessibility issues. Does anybody see any other issues? --hans
Received on Saturday, 18 January 2014 11:58:06 UTC