Re: Signaling and out of band content, was: Re: Encrypted Media proposal: Summary of the discussion so far

Jumping back a little to address this question from Charles ...


On Mar 4, 2012, at 11:03 AM, Charles Pritchard wrote:

> On 3/4/2012 12:41 AM, Andreas Kuckartz wrote:
>> On 04.03.2012 02:54, Christian Kaiser wrote:
>>> To illustrate, let's assume
>>> - browser/device B1 supports CDMs A and B,
>>> - browser/device B2 supports CDM A,
>>> - browser/device B3 supports CDMs C and D
>>> and
>>> - content distributor CD1 supports CDM A and C
>>> - content distributor CD2 supports CDM A, B and D
>>> In this example, *all* browsers/devices can play content
>>> from *all* content distributors even though none of the
>>> content distributors support all CDMs, and the
>>> browsers/devices do not support a common set of CDMs.
>> It is noteworthy that this scenario does not include *any* browser which
>> does not support *any* of these CDMs but still makes a statement about
>> *all" browsers. This scenario is only thinkable in a world in which Open
>> Source has been eliminated. Wishful thinking?
> 
> Back to some wishful thinking: Is there a means of generalizing this proposal? As someone on the list pointed out, this proposal works to send out of band data to be processed by the video system. Seems like that kind of functionality could be helpful.
> 
> One tactic of the Hixie is to unify what are seemingly separate use cases into one more-elegant system.
> 
> Where this proposal tries to jam key systems into the media framework:
>  DOMString canPlayType(in DOMString type, in DOMstring? keySystem);
> We could generalize:
>  DOMString canPlayType(in DOMString type, in DOMstring? signalSystem);
> 
> The authors of the Encrypted Media proposal may find some good feedback from WebRTC peoples:
> https://sites.google.com/site/webrtc/running-the-demos
> http://dev.w3.org/2011/webrtc/editor/webrtc.html
> 
> While WebRTC has very different mechanisms and goals, the goals of streaming media and signaling are shared.
> 
> These are not the same as the Encrypted Media addKey system, but I urge the editors to review them anyway:
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-processSignalingMessage-void-DOMString-message
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#the-data-stream
> 
> While the industry and editors can just move ahead with key-specific extensions to HTML Media, they may find less push-back with a more broadly applicable proposal. Out of band signaling seems like a concept that may have long term uses outside of DRM.
> 
> By and large, replace "key" with "signal".

We considered this kind of generalization and decided in the end to go with the more explicit messages.

The issue is that with a generalized mechanism, the functionality of the "signal system" is completely undefined. For a particular 'signal system', what it does and what message flow it expects needs to be known by the application code. Application code written for one signal system can't be used with another, not least because they might have completely different purposes, but also if they fulfill the same purpose. Some arguments against having such a generic way to interact with components in the media pipeline are given in the no-change proposal to Issue 179.

The approach we propose defines exactly what the CDM does (as a 'black box'): it's inputs are encrypted media and opaque (outside the box) messages. It's outputs are decrypted media (in one form or another) and opaque (outside the box) messages. Although the messages are opaque, their purpose and the way they are used is defined. Application code at both client and application server can be written in a keysystem-independent manner.

One reason for this is that in moving this black-box functionality from plugins to part of the <video> element, we want to constrain the black-box as much as possible. That we know exactly what it does - if not exactly how it does it - should be an improvement from the current situation where we know neither (or even whether it is there). Ordinary functions such as authentication and authorization are moved out of the black-box to the application, where they belong. If we wish we could also specify the encryption algorithms for each container format, as there is no need for this to be keysystem-specific either and some advantages if it is not.

...Mark

> 
> For a simple use case, consider a video stream that is accompanied by a drawing overlay, such as used on the TV with sports replays.
> It may be helpful to pump in an Array Buffer of x/y offsets (from the announcer) as well as timing information, so that the <video> synthesizes with an overlay.
> 
> 
> -Charles
> 
>

Received on Monday, 5 March 2012 23:45:46 UTC