Re: Open Source implementations Re: Encrypted Media proposal (was RE: ISSUE-179: av_param - Chairs Solicit Alternate Proposals or Counter-Proposals)

On Tue, Feb 28, 2012 at 9:07 AM, Glenn Adams <glenn@skynav.com> wrote:
> 2012/2/28 Tab Atkins Jr. <jackalmage@gmail.com>
>> In your other case (server is untrusted), DRM is unnecessary baggage;
>> you only need JS encryption/decryption that can be inserted between
>> the server and a <video> element of the user.  This can be specified
>> and implemented without many of the concerns that people have been
>> raising about this proposal.
>
> A solution that requires decryption of the actual media content in JS would
> be unacceptable from a performance perspective, particularly on resource
> constrained devices. The solution must be readily implemented with
> reasonable performance on devices at different ends of the spectrum,
> including TV/STBs (resource constrained).

emscriptem has apparently broken the order-of-magnitude barrier in
C-like speeds, so performance is likely much less of an issue than you
believe.

However, "decryption in JS" doesn't necessarily mean "written in JS
code", any more than "random numbers in JS" does.  Handing authors an
encryption/decryption module written in C++ with a JS API satisfies
the use-case, and still avoids the difficulties people have with DRM.

~TJ

Received on Tuesday, 28 February 2012 18:36:30 UTC