W3C home > Mailing lists > Public > public-html@w3.org > February 2012

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 22 Feb 2012 17:07:16 +1100
Message-ID: <CAHp8n2kyoOwXTk3Rd99ZQ+_A-C99PF2rdvvVsvrg8rxCrN7ZUQ@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Mark Watson <watsonm@netflix.com>, Adrian Bateman <adrianba@microsoft.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, David Dorwin <ddorwin@google.com>
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

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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:48 UTC