W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2014

replaceTrack proposal

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Wed, 03 Sep 2014 10:55:13 -0400
Message-ID: <54072BD1.9020504@mozilla.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
People want to switch seamlessly between the front and back camera on a 
mobile device in mid-call.

This requires somehow switching out the source of a video being sent 
over a peerConnection without renegotiation.

We're trying out a solution to this that recently landed in Firefox 
Nightly, and we'd like to propose the API for it.

It consists of a replaceTrack method to the recently discussed 
RtpSender: [1]

interface RTCRtpSender {
   readonly attribute MediaStreamTrack track;

   void replaceTrack(MediaStreamTrack withTrack,
                     VoidFunction successCallback,
                     RTCPeerConnectionErrorCallback failureCallback);
};

The withTrack argument SHOULD be a track in the same mediaStream as 
RtpSender.track, though we've had to relax this requirement until 
Firefox supports more than one track of the same type per mediaSteam, 
and the restriction may turn out to be unnecessary. [2]

The method is asynchronous (though so far we've not needed it to be).

If the method succeeds then withTrack is now being transmitted over the 
peerConnection in place of the previous RtpSender.track, and 
RtpSender.track now points to withTrack. No changes are made to the 
mediaStream.

If the method fails then the existing RtpSender.track has not been replaced.

Example:

function switchToSendingBackCamera(sender) {
mediaDevices.getUserMedia({video:{facingMode:{exact:"environment"}}}, 
function(stream) {
     sender.replaceTrack(stream.getVideoTracks()[0], function() {
       console.log("switched to back camera");
     }, failed);
   }, failed);
});

Real test page: 
http://mozilla.github.io/webrtc-landing/pc_test_swap.html [3][4]

.: Jan-Ivar :.

[1] 
https://www.w3.org/2011/04/webrtc/wiki/images/6/63/WebRTC_RTCSender-Receiver.pdf

[2] This works because sync happens receiver-side and timestamps are 
tied to capture.
     While streams == synchronization contexts, by replacing a track at 
the sender,
     we're making it part of the context at the receiver, so should we 
require it on
     thethe sender end for symmetry?

[3] The real test page contains antics to work on systems that are 
limited to one
open camera at a time. It calls replaceTrack twice, first to an interim 
black
     fake video.

[4] Last night's Nightly is needed to flip between front and back on 
android.
Received on Wednesday, 3 September 2014 14:55:43 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:41 UTC