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

On Tue, Feb 21, 2012 at 7:04 PM, Mark Watson <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>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?).


> 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.

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.

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 would not like to see the use of data-* or x-vendor-* attributes to
support use cases where <param> would suffice.

G.