W3C home > Mailing lists > Public > public-media-capture@w3.org > December 2015

issue 244: new proposal for Media Capture and Streams extensibility text

From: Dan Burnett <dburnett@voxeo.com>
Date: Thu, 3 Dec 2015 09:40:07 -0500
Message-Id: <06C059F3-5652-4CD2-928F-23179968DDEF@voxeo.com>
To: public-media-capture@w3.org
Group,

Based on the contents of issue #244 [1] and our discussion at TPAC [2,3], I have written an almost completely new proposal for text on extensibility to go into the Media Capture and Streams spec. Please review and comment.

-- dan

[1] https://github.com/w3c/mediacapture-main/issues/244
[2] http://www.w3.org/2015/10/28-webrtc-minutes#item09
[3] my own notes

===============================  PROPOSED TEXT ===============================
This section is informative.
Although new versions of this specification may be produced in the future, it is also expected that other standards will need to define new capabilities that build upon those in this specification.  The purpose of this section is to provide guidance to creators of such extensions.

Any WebIDL-defined interfaces, methods, or attributes in the specification may be extended.  Two likely extension points are defining a new media type and defining a new constrainable property.


= Defining a new media type (beyond the existing Audio and Video types) =

At a minimum, defining a new media type would require
 * adding a new getXXXXTracks() method for the type to the MediaStream interface,
 * describing what a muted or disabled track of that type will render (sec 4.3.1),
 * adding the new type as an additional legal value for the kind atttribute on the MediaStreamTrack interface,
 * updating the description of the readonly attribute of the MediaStreamTrack interface,
 * adding at least one track source type (SourceTypeEnum),
 * defining any constrainable properties that are applicable to the media type,
 * updating how the HTMLMediaElement works with a MediaStream containing a track of the new media type,
 * updating MediaDeviceKind,
 * updating the getCapabilities and getUserMedia descriptions,
 * adding the new type to the MediaStreamConstraints dictionary, and
 * describing any new security and/or privacy considerations introduced by the new type. 

Additionally, it should include updating
 * the source definition,
 * the list of media stream consumers,
 * the description of the label attribute on the MediaStreamTrack interface,
 * the list of sinks (section 5), and
 * the best practice statements referring to video and audio.

It might also include
 * explaining how the media is expected to be used by elements to which one might assign it (<video> as example for audio and video), and
 * giving examples in sec 4.3.3 of how such a track might become ended.


= Defining a new constrainable property =

This will require thinking through and defining how Constraints, Capabilities, and Settings for the property will work.  The relevant text in sections 4.3 and 10.3 are the model to use.

Creators of extension specifications are strongly encouraged to notify the Media Capture Task Force of their extension by emailing the list at public-media-capture@w3.org.
Future versions of this specification and others created by the Media Capture Task Force will take into consideration all extensions they are aware of in an attempt to reduce potential usage conflicts.

=============================================================================
Received on Thursday, 3 December 2015 14:40:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 December 2015 14:40:38 UTC