PSA: replaceTrack() shipping in M65

[hb...@webrtc.org]

RTCRtpSender.replaceTrack() is shipping in M65.

This allows you to seamlessly change which track is being sent without having to renegotiate at the expense of another offer/answer cycle.

For example, you might want to switch which video to send or to temporarily not send video, without any disruption in audio or at the cost of an RTT delay.

Please try it out and file bugs :)

[Iñaki Baz Castillo]

eeee how you shipped it with this unresolved bug? 

https://bugs.chromium.org/p/chromium/issues/detail?id=803004

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/53477ef4-bdb8-4cfc-a076-fbb8dfe11198%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[hb...@webrtc.org]

Because you should not stop the original track before you replace it. If that bug still triggers after you've replaced it we have a problem. I will investigate in that bug thread.

On Thursday, January 25, 2018 at 12:23:44 PM UTC+1, Iñaki Baz Castillo wrote:

eeee how you shipped it with this unresolved bug? 

https://bugs.chromium.org/p/chromium/issues/detail?id=803004

El 25 ene. 2018 12:17, <hb...@webrtc.org> escribió:

RTCRtpSender.replaceTrack() is shipping in M65.

This allows you to seamlessly change which track is being sent without having to renegotiate at the expense of another offer/answer cycle.

For example, you might want to switch which video to send or to temporarily not send video, without any disruption in audio or at the cost of an RTT delay.

Please try it out and file bugs :)

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Iñaki Baz Castillo]

On 25 January 2018 at 12:27, <hb...@webrtc.org> wrote:
> Because you should not stop the original track before you replace it.

Why not?

I want to stop the original track to stop the webcam light and then,
when the user "switches on" again the webcam, do a transparent
getUserMedia, use replaceTrack() with the new video track and signal
"camera on again" to the remote via custom signaling.

Also, AFAIK in Android and/or iOS you cannot have the tracks of both,
the front and back cameras, open at the same time, so replaceTrack is
useless.

Anyway, why do you state that "you should not stop the original track
before you replace it"? Where is the spec is that told?



--
Iñaki Baz Castillo
<i...@aliax.net>

[Philipp Hancke]

its called "chicken".

I will not update code that works in Firefox+Edge and relies on 'replaceTrack' in RTCRtpSender to use native replaceTrack instead of gruelsome alternatives just because Chrome decides to unflag a very useful feature in a state where the functionality does not match other browsers.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfnFaZ--w9v3axj2KLCc9W6Uh-mLpzRusGx5uNk%3D%3DJrerg%40mail.gmail.com.

[Iñaki Baz Castillo]

On 25 January 2018 at 12:31, Iñaki Baz Castillo <i...@aliax.net> wrote:
> On 25 January 2018 at 12:27, <hb...@webrtc.org> wrote:
>> Because you should not stop the original track before you replace it.

https://www.w3.org/TR/webrtc/#dom-rtcrtpsender-replacetrack

"Determine if negotiation is needed to transmit withTrack in place of
the sender's existing track. Negotiation is not needed if withTrack is
null or if the sender's existing track is ended (which appears as
though the track was muted)"

Where in the spec is told that replaceTrack() cannot be called if the
original track was ended before?

hbos, may be you would like to move the Chrome issue back to P1?

[hb...@webrtc.org]

I meant it makes more sense to stop the track after you've stopped using it rather than before, not that it's not allowed. To be clear, this is a bug regardless, and it makes sense that apps might try to do what you're describing.

Please keep discussions about the bug in the bug thread. There we can discuss merging a fix or updating the status of the shipping.

[Iñaki Baz Castillo]

On 25 January 2018 at 13:53, <hb...@webrtc.org> wrote:
> I meant it makes more sense to stop the track after you've stopped using it
> rather than before,

There are many use cases for replaceTrack, and many of them do not fit
in that assumption.

> To be clear, this is a bug
> regardless, and it makes sense that apps might try to do what you're
> describing.
> Please keep discussions about the bug in the bug thread. There we can
> discuss merging a fix or updating the status of the shipping.

Sure, thanks.

[hb...@webrtc.org]

The alleged bug is not reproducible on latest cut of 65. Intended behavior is observed. Proceeding with shipping as planned.

[Iñaki Baz Castillo]

Philipp, your turn.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to discuss-webrt...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/discuss-webrtc/4b463cb3-cbd3-4bd2-b95b-7a9eb752cbdc%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

[Philipp Hancke]

replaceTrack looks good, yay hbos! And yet I have a 

    Labels: M-65 ReleaseBlock-Stable

for an autoplay webrtc video freeze which caused the confusion. Thanks guido!

Philipp, your turn.

> email to discuss-webrtc+unsubscribe@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/discuss-webrtc/4b463cb3-cbd3-4bd2-b95b-7a9eb752cbdc%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

--
Iñaki Baz Castillo
<i...@aliax.net>

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfkus_Gw4MZAWY1W0QHdoKJ_GLuRc12CH%3DoA6-YLmCGWLg%40mail.gmail.com.

[Chen Cong]

Is there a way  I can know  the sender call replaceTrack in the receiver side?

在 2018年1月25日星期四 UTC+8下午7:17:48，hb...@webrtc.org写道：

[Harald Alvestrand]

No, the intent of replacetrack is that it should be invisible to the receiver. The sender can always use a data channel to inform the receiver if appropriate, but this is not part of the standard.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6eee6978-47cd-46fa-8aee-2348af15d802%40googlegroups.com.

[Chen Cong]

Got it.

在 2018年4月4日星期三 UTC+8下午4:03:36，Harald Alvestrand写道：