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

> On 28 Sep 2021, at 08:16, Bernard Aboba <Bernard.Aboba@microsoft.com <mailto:Bernard.Aboba@microsoft.com>> wrote:
> 
> 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.
Do you suggest to add wording about why this might be useful in the beginning of the section?
That seems reasonable to me.
I filed https://github.com/w3c/mediacapture-extensions/issues/37 <https://github.com/w3c/mediacapture-extensions/issues/37> to follow up on this.

> 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? 
I am not sure what inconsistencies you are referring to.
By the transferring algorithm definition, we keep the same source, same settings…
I would hope interop will not be an issue but we need implementations to validate this.
> 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.
It really depends what you will end up doing in the worker.
If the goal is to transform the track, I agree there will be a transferred-back track.
If the goal is track -> WebCodecs -> WebSocket, everything can be done in the worker.

Given lack of APIs in worker to make use of tracks, I am not sure we can add worker examples.
We can however add some examples with cross-origin iframe, say a ‘communication iframe’ transferring a track to a ‘UI iframe’ and conversely the ‘UI frame’ transferring
one of its canvas capture track to the ‘communication’ iframe.

I think https://github.com/w3c/mediacapture-extensions/issues/37 <https://github.com/w3c/mediacapture-extensions/issues/37> can be used to follow up on this as well.

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