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

I feel we are re-hashing the same material. We also appear to have
different mental models. For example,

1. <object> and plug-ins

I do not assume that the use of <object> involves the use of an author
supplied plugin (code). I would suggest that most uses of object involve
either 3rd party plugins or UA native plugins. Flash and Silverlight are
examples of the former, while the many uses of <object> defined in CEA-2014
are examples of the latter. In general, all of these example uses define
specific sets of parameters that can be specified by the author via the
param element.

2. author specified versus media embedded parameters

I do not assume that parameters are embedded in the media or in a media
manifest (or metadata). For example, whether playback of video is to start
in full screen mode or not is a presentation parameter unrelated to a
specific media instance or a codec. Other parameters include the content of
the 4th (additionalInfo) field of the protocolInfo specification defined by
UPnP ConnectionManager service [1].

[1]
http://www.upnp.org/specs/av/UPnP-av-ConnectionManager-v3-Service-20101231.pdf

3. x-* attributes

The introduction and use of x-* attributes has historically been viewed as
anathema by a majority of W3C participants. Recently, the use of vendor
specific prefixes by early implementations of not-yet-CR CSS features has
produced a great deal of smoke and fire [2][3]. I wish to avoid another
conflagration of this sort.

[2] http://lists.w3.org/Archives/Public/www-style/2012Feb/0998.html
[3] http://lists.w3.org/Archives/Public/www-style/2012Feb/0678.html

I do not wish to continue repeating the arguments and explanations I
provided in the original CP, so I will end this thread (on my part) at this
point.

It merely remains to see which position is more persuasive to the WG to
resolve this matter.

Regards,
Glenn

On Wed, Feb 22, 2012 at 10:08 AM, Mark Watson <watsonm@netflix.com> wrote:

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