RE: replaceTrack proposal

Agree with Peter that "setTrack" seems more compatible with existing usage.   

With respect to the success/failure callbacks, I am wondering whether most of the potential errors wouldn't be handled via an Exception, rather than requiring a failure callback.  Also, I'd expect that setTrack would return quickly so that async behavior isn't an absolute requirement.   Or am I missing something that requires async behavior? 


-----Original Message-----
From: Peter Thatcher [mailto:pthatcher@google.com] 
Sent: Wednesday, September 3, 2014 11:31 AM
To: Jan-Ivar Bruaroey
Cc: public-webrtc@w3.org
Subject: Re: replaceTrack proposal

I like the idea of being able to change the track that feeds into the RtpSender.  Overall, I like the proposal.  But a few questions:

1.  Why not just setTrack instead of replaceTrack?  I don't mean to bikeshed, but we have lots of setters in the code, and no "replacers"
in the API.

2.  Why would it matter at all what MediaStream the track is in?  I don't see why it would matter.  And for that matter, when would you have two video tracks in a MediaStream in the first place?  What does that even mean?


On Wed, Sep 3, 2014 at 7:55 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
> 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-Re

> ceiver.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 20:04:15 UTC