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

On 03/12/2015 15:40, Dan Burnett wrote:
> 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.

Looks great!

In your list of "how to add a new media type", I noted the requirement 
of updating "MediaDeviceKind", but it is an enum which as far I know 
can't be extended (in WebIDL syntax at least). I'm not sure if that 
needs to be addressed and how.

Anssi, since Media Capture Depth is probably the most advanced extension 
to Media Capture and Streams, I think you review of the proposed text 
would be particularly valuable.

Regarding my specific point above, from what I can see in the current 
draft of depth stream, there is no attempt at extending MediaDeviceKind 
— was that on purpose?

Thanks,

Dom

> [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 Friday, 4 December 2015 13:57:39 UTC