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

On Wed, Feb 22, 2012 at 2:32 PM, Glenn Adams <glenn@skynav.com> wrote:
>
> 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.


On the contrary: I would not like to see introduction of <param> where
data-* or x-vendor-* attributes suffice. These already exist and I
have not seen a single use case where <param> was necessary. This
proposals shows exactly how extensions are made without a need for
<param>.

Regards,
Silvia.

Received on Wednesday, 22 February 2012 06:08:06 UTC