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

On Tue, Feb 21, 2012 at 11:01 PM, Mark Watson <watsonm@netflix.com> wrote:

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

Would you agree that different codecs and media protocols employ distinct,
though sometimes overlapping parameters that are not necessarily covered by
existing attributes on video/audio/track?

Would you agree that the set of codecs and media protocols supported by a
given UA is not determined by HTML5 nor necessarily determined by any
external specification (e.g., DLNA)?

Would you agree that this set is not closed and will change over time?

If you agree with any of these statements, then you will recognize that
there will in all likelihood need to be a mechanism to interchange such
parameters. If so, there are a number of options:

   1. use a non-standard, adhoc, vendor specific approach such as advocated
   by Sylvia, e.g., add x-acme-codec-*, x-waterworks-protocol-*, etc.
   attributes willy-nilly
   2. or, create a new version of HTML5 every time a new attribute is
   required
   3. or, use a generic extensibility mechanism such as <param>

In case #1, you end up with non-interoperable attribute soup, and you end
up running into problems like the CSS property prefixing problem currently
bogging down the CSS WG.

In case #2, you have to obtain consensus for every parameter attribute and
then rev HTML5.

In case #3, you publish external (or other W3C) specifications defining one
or more param name/value pairs for use with specific codecs and/or
protocols. The UA simply passes the set of specified name/value pairs to
the internal media component (whether or not it is native to the UA or a UA
plugin -- this difference is irrelevant).

To me, the choice is very simple: case #3 is already a tried and true
solution, demonstrated by existing implementations of object. Many (most?)
UAs will probably use existing plugin interfaces to support video/audio
elements. Case #3 wins on solution reuse. Case #3 wins on extensibility and
ease of processing.

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

The application developer already has the quandary of not knowing what
media codecs/protocols are supported by a UA. The application developer
already has the quandary of not knowing what capabilities and parameters
are available on those media codecs/protocols. There is no capability
discovery mechanism to discover the latter in either case. And,
notwithstanding canPlayType(), there is no reliabile capability discovery
mechanism to determine the nature of codec support. [At best, a UA may say
that it "probably" supports a MIME type.]

To date, the definition of parameter support on built-in media codecs (via
object) has been defined by UA manufacturers. However, other external
specifications, such as CEA-2014 CE-HTML, have defined specific parameters
to be supported in a standards compliance fashion.

I would expect other, future external specifications or standards to fill
this gap, but it they should not be forced to introduce x-cea-* or x-dlna-*
attributes or define another adhoc syntactic mechanism when the generic
mechanism supported by <param> is readily available, tested, and deployed.

I can't understand the recent trend of jettisoning extensibility mechanisms
in HTML5. This (not supporting param on audio/vide) seems like one more
example of a false over-confidence to get it right the first time. Perhaps
its my age, but I have little confidence in any organization's ability to
get standards right the first time. There are good architectural reasons
for extensibility, the most obvious being: we didn't think of it at the
time...

Not supporting param means reducing extensibility and architectural
flexibility. It means reducing interoperability with existing and past
practices that used object, and for which audio/video/track are now
expected to provide at least functional parity, but also introduce newer
and greater features.

The zero-change counter proposal is a step backwards in functionality,
utility, and extensibility.

G.