[Bug 13333] New: audio, video (and source) elements require param children or equivalent

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

           Summary: audio, video (and source) elements require param
                    children or equivalent
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: glenn@skynav.com
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


In order to configure playback by means of audio and video element types, it is
frequently necessary to specify author supplied parameters intended to be
interpreted by the playback component (or plugin). Such parameters are
frequently required in order to configure the playback component (or plugin)
for purposes of server setup, transport setup, playback setup, rendering setup,
etc.

In pre-HTML5 content, the param child of an object element is often used for
this purpose. However, HTML5 fails to define param as a child element for
either audio or video element types. In order to correct this deficiency, the
content models for these elements should be changed to read as follows:

<quote>
If the element has a src attribute: zero or more param elements,  zero or more
track elements, then transparent, but with no media element descendants.
If the element does not have a src attribute: zero or more source elements,
zero or more param elements,  then zero or more track elements, then
transparent, but with no media element descendants.
</quote>

In addition, the content model of the source element type should be changed to
read as follows:

<quote>
Zero or more param elements.
</quote>

The purpose of allowing param element children on a source element is to permit
specifying parameters on both the media element and the chosen source element
such that the two sets of parameters are merged (with union operator) as the
effective parameters for the media component (plugin). In this fashion,
parameters that are dependent upon a particular source (among alternates) may
be specified distinctly and merged with parameters that are not source
specific.

Example #1 - Configure Flash Playback

<video src="video.swf">
  <param name="quality" value="high">
  <param name="allowfullscreen" value="true">
</video>

Example #2 - Configure Sliverlight Video with DRM

<video src="example.xap" type="application/x-silverlight-2">
  <param name="initParams" value="drmKey=0123456789abcdef0123456789abcdef">
  <param name="windowless" value="true">
</video>

Example #3 - Configure DLNA A/V Connection Manager for Audio Playback with RTP
preference over HTTP

<audio>
  <source src="audio.mp3">
    <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
  </source>
  <source src="audio.mp3">
    <param name="dlna-res-protocolInfo"
value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
  </source>
</audio>

Note that in the absence of the above mechanism, a UA implementer or external
specification that references HTML5 will be forced to define some
elsewhere-standardized, alternative solution that provides an interoperable
means to specify such parameters. Three such alternative being considered are:

(1) an elsewhere-standardized use of data-* attributes (in willful violation of
the HTML5 prohibition of such usage), e.g., data-param-foo="bar";
(2) use object instead of video or audio, in which case the new functionality
defined around video and audio elements are not available;

Finally, in addition to adding param to audio, video, and source elements as
described above, a case can be made that param should be added to the track
element as well, since architecturally, a timed track may need or use parameter
information to configure the UA for transport, playback, rendering, etc.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 22 July 2011 21:36:16 UTC