Re: Call for Consensus (CfC) on Transferrable MediaStreamTracks (Section 5 of mediacapture-extensions)

I support Transferrable MediaStreamTracks.  However, I do not believe that Section 5 provides covers the subject adequately, since it is missing:


  *   Motivation.  The benefits of transferrable MediaStreamTracks are not enumerated or compared to alternatives.
  *   Pitfalls. The application developer is not informed about issues that they may need to be aware of, particularly in the context of WebRTC.  As an example, are there known inconsistencies in the existing track APIs that are likely to affect the interoperability of transferred MediaStreamTracks?
  *   Code examples. In track processing scenarios, a track may be transferred to a  worker in order to enable manipulation, with the processed track transferred back to the main thread in order to be rendered or provided as an argument to addTrack.  So the transfers tend to come in pairs.

===================================================

This is a Call for Consensus (CfC) on Transferrable MediaStreamTracks, which are described in Section 5 of the Mediacapture-Extensions document (currently an editors draft without WG consensus):
https://w3c.github.io/mediacapture-extensions/#transferable-mediastreamtrack

In response, please state one of the following:

  *   I support Section 5 of mediacapture-extensions
  *   I object to Section 5 of mediacapture-extensions due to issues filed in open bug <#number>

The CfC will end on September 27, 2021

Bernard

For the Chairs

Process explanation

Extensions documents such as WebRTC-Extensions and Mediacapture-Extensions exist to incubate material that may eventually be folded into future iterations of existing documents (WebRTC-PC 1.0 and MediaCapture & Streams, respectively).

However, as these Extension documents have been Editor's Drafts for considerable periods of time without issuance of a Working Group Draft, they cannot be considered to represent the consensus of the WEBRTC WG.

It was pointed out that this situation could result in "late surprises" (e.g. controversy about incorporation of portions of an extension document into the main document at some future date, potentially long after the material was first incorporated into the extension document, by which time the controversial elements may already be in use by applications).

To avoid such a situation, it is desirable to determine WG consensus early on significant aspects of the Extensions documents, so that issues can be raised and potentially addressed prior to implementation.

In this instance, changes to enable Transferrable MediaStreamTracks were included in merged PR 30 which can be found here:
https://github.com/w3c/mediacapture-extensions/pull/30

The entire text (lines 350 - 420) can be viewed here:
https://github.com/youennf/mediacapture-extensions/blob/ffbb6836d4a5fef4abef5d83fb15bec1abc65fbd/index.html

Note that since a CfC has not been run on the entire Mediacapture-extensions document, this CfC only applies to Transferrable MediaStreamTracks and not to other aspects which may be covered by subsequent CfCs. It therefore does not bear on the overall WG consensus for Mediacapture-Extensions.