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

On Feb 22, 2012, at 12:41 AM, Glenn Adams wrote:


On Tue, Feb 21, 2012 at 11:01 PM, Mark Watson <watsonm@netflix.com<mailto: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?

I am not sure what codec-specific or prototcol-specific parameters need to be controlled by the web page vs being embedded in the media.


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

Yes


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

Yes


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.

Possibly, though not necessarily. The alternative is that the functionality being controlled is abstracted such that the parameters are no longer codec or media protocol specific. These, generic, controls are then what is exposed on the Media Element.

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>

4. Create extension specifications in the HTML working group for the additional capabilities which need to be exposed - preferably abstracting them so that they are not codec or protocol-specific. This is exactly what we propose to do for encrypted media.

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.

I don't see any significant difference between #1 and #3 - either way I have a "soup" of external specifications to wade through to find out how to achieve some function or other. How is a non-interoperable attribute soup worse than a non-interoperable <param> soup ?

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

A plugin is something that the web page has explicitly chosen to embed, so the page author can be expected to know what functionality that plugin provides.

AFAIK, though, there is no provision for browser plugins to enhance the capabilities of the <audio> and <video> elements - unless you mean some new kind of browser plugin ?


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

I would agree that it would be good to enhance canPlayType with a "yes" response: MIME types are in many cases sufficient for this - using RFC6381 I can specify a container, container profile, codecs, codec level and profile. Perhaps some display capabilities - such as support for de-interlacing - are missing.


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.

It would be better if they would make proposals to W3C.


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

There are plenty of extensibility mechanism, as have been described.

The trend is to move from using plugins to having functionality defined as part of the web platform and the point is that to have functionality defined as part of the platform you actually have to define it. It's fundamentally different from the plugin situation where you are explicitly delegating the functionality to arbitrary code running within the plugin. In that case, of course you want to pass arbitrary parameters to this arbitrary code. But if the functionality is part of the platform itself, you want to *define* what parameters are passed.


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.