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

On Feb 21, 2012, at 7:32 PM, Glenn Adams wrote:


On Tue, Feb 21, 2012 at 7:04 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
On Feb 21, 2012, at 5:51 PM, Glenn Adams wrote
On Tue, Feb 21, 2012 at 6:35 PM, Adrian Bateman <adrianba@microsoft.com<mailto:adrianba@microsoft.com>> wrote:
On Tuesday, February 21, 2012 4:00 PM, Glenn Adams wrote:
> This a lengthy proposal that is not directly related to the general issue of
> interchanging decoding and/or protocol parameters between author and user
> agent for the purpose of performing audio and/or video playback.
>
> Could you point out the specific elements of the proposal that deals with
> such parameter interchange? If this proposal offers an alternative mechanism
> to perform such interchange, then is that mechanism suitable for purposes not
> related to encrypted media playback?

Hi Glenn,

Rather than introducing a mechanism that supports generic parameter exchange,
this proposal shows how it is possible to write an extension specification
to add specific functionality to the existing media elements. User Agents
supporting this proposal would be interoperable if they implement the
extension according to the spec.

Having a generic mechanism doesn't guarantee interoperability because you still
need to specify what happens for each potential value. I argue that you don't
need <param> to do that, you just write the specification that defines
the new capabilities you want the media element to support. You can do that with
an extension at the time you define the values.

Of course that is true, but it is also besides the point. Furthermore, your suggestion would lead to the idea that for every extension specification ES(0) ... ES(n), one would define an independent mechanism for interchanging parameters.

The point of having a generic mechanism is that it is useful in may circumstances, in this case a general syntactic mechanism that has been successfully implemented and used without requiring changes to the originating spec (HTML4 in this case).

I continue to maintain that if there is such a generic parameter interchange mechanism defined and included for <object>, then there should be such a generic mechanism for <audio> and <video> which seek to define specific flavors of <object>.

As has been pointed out in the earlier discussion on ISSUE 179, this not not correct. <object> embeds *arbitrary* functionality into a page. This functionality is constrained only by browser plugin APIs and so can literally be almost anything. Hence it makes sense to enable the passing of arbitrary parameters.

<video> and <audio>, by contrast, provide the very specific functions of media playback. If they were "flavours" of <object> they would provide for embedding of arbitrary media playback plugins. They do not. They provide access to specific native User Agent media playback functions.

I don't agree that <video> or <audio> narrow the functionality of <object> sufficiently to make <param> unnecessary or undesirable.

If they did in fact narrow it to this extent then only specific audio, video, and timed text tracks would have been supported (ogg? webm?), only specific content protection solutions would have been supported (none?).

One of us is missing something here: <object> enables the web page to embed completely arbitrary functionality (plugin) that is chosen by and known to the web page author. <audio> and <video> enable the web page to embed a well-defined media playback function, implemented by the UA, not chosen by the page author. Yes, there are variations in the capabilities of those media playback functions implemented by different browsers in terms of protocols and codecs, so there needs to be capability discovery, but no, you cannot choose to pull in arbitrary media capabilities of your choosing that might need to be configured through <param>: you get what the UA supports.

So I am still failing to understand the parallel you are drawing between <object> and <video>/<audio>.


It makes sense in this context to provide specific methods related to this functionality. Our proposal introduces specific methods for accessing content protection functionality - one of the use-cases that was proposed for <param>.

Even the proposed content functionality proposal is adopted, it represents but one use case, and does not invalidate the utility of having a more generic solution.

It may not invalidate the other use-cases, but what you call a "generic solution" doesn't appear to me to be a solution at all. It just punts definition of the functionality into some black hole. Where is an application developer to look for definition of what parameters to set on <param> ?


Supporting the use of a generic mechanism recognizes the fact that we do not at present have perfect or complete knowledge of the set of essential or useful decoding and/or protocol parameters that will be desired, not only for today's but also tomorrow's set of fielded audio, video, and timed track media types and delivery protocols.

I suggest that as we gain knowledge of these we define them explicitly in specifications such as the one are proposing for Content Protection.


In contrast, failure to define such a mechanism imposes an arbitrary impedance mismatch between present and past usage (object) and future usage (audio, video, track), and will likely result in multiple, vendor specific, adhoc solutions as need is found for interchanging parameters not represented by presently defined audio, video, and track definitions.

I don't see how <param> helps with that - the "vendor-specific, ad hoc solutions" are equally bad whether they are x-vendor-* attributes or  <param> name/value pairs. Indeed <param> sends the message that the HTML group encourages such an approach, whereas x-vendor-* at least accurately describes such solutions for what they are.

...Mark


I would not like to see the use of data-* or x-vendor-* attributes to support use cases where <param> would suffice.

G.