I will take a look.

With two video tracks - original stopped and the other switched to with replaceTrack - I would expect the promise to be resolved and the remote view to resume.

I'm not sure what is expected when both video tracks are on the same stream (as opposed to two streams, one video track each). If stopping one track stops the entire stream is a bug I think this is a separate bug from being able to replaceTrack after original has stopped().

What does the spec say about stop(), that should not trigger any renegotiation, just mute the stream? I'll have to take a look.

I misread something, this bug describes two different streams, this should definitely work.

updating samples to make this easily testable: https://github.com/webrtc/samples/pull/996

P-1 until I've figured out if this bug is triggered when you stop the track *after* it has been replaced. If so we should fix and merge if possible.

Please, don't assume that it's mandatory to stop the old track *after* doing replaceTrack.

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)"

hbos, I think the spec is *clear* and does allow using replaceTrack() after the original track was ended, agree?

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

"The track attribute is the track that is associated with this RTCRtpSender object. If track is ended, or if track.muted is set to true, the RTCRtpSender sends silence (audio) or a black frame (video)."

No where it's told that a RtpSender cannot hold an ended track. In fact, you can even create a RtpSender with an already ended track.

Yes, to be clear this is a bug regardless, and should be fixed and merged into M65 if possible regardless, but the severity of the bug is impacted by this.

I created this to repro:
https://codepen.io/anon/pen/QaXara

It's working as intended in tip of tree, both local and remote video are playing regardless if replaceTrack() is called before or after stop().

Is your case different from what I'm doing or was this fixed after the cut?

Unable to repro with or without adapter-latest.js.

Also unable to repro on https://webrtc.github.io/samples/src/content/peerconnection/pc1/

On tip of tree.

Also tested on 65.0.3325.9 (with and without adapter.js).
This has already been fixed.

Closing as WontFix (not reproducible).

Please verify, fippo.

A likely explanation for this bug being reported is that the second gUM failed for unrelated reasons so that replaceTrack never happened. This would have made the left video black and the right video frozen and a rejected promise being console.log'ed.

(Which is a good reason to stop your tracks after you are sure they are no longer used, unless you want to stop using the initial track regardless of if replaceTrack() succeeded or failed.)

Also not reproducible on Mac.

Yes hbos, the use case you describe is valid. The opposite one as well.

Agreed, this would have been nasty if it was reproducible regardless.

note that I said "video is still frozen". I did not say "the left video frame is black".

How is this:
1. follow the steps from https://bugs.chromium.org/p/chromium/issues/detail?id=804091 to get a frozen video
2. open https://webrtc.github.io/samples/src/content/peerconnection/pc1/ and make a call
3. ensure things are still moving
4. open dev tools
5. video freeze???
6. close devtools. videos unfreeze
7. pretend not to have noticed 5 and skipped 6 therefore
8. scroll up, call localStream.getVideoTracks()[0].stop()
9. observe that both local and remote video show a frozen image. Assume this is ok
10. execute replaceTrack. Things are still frozen. Go pester hbos.
11. close devtools. videos start moving again.

What is going on?

interesting. While I can reproduce 804091 on windows in 66.0.3331.1 (asan), I can not reproduce the behaviour from comment #19

screenshot of webrtc-internals while executing the steps from #19 (which is not perfectly reproducible but I have a good ratio now). This shows its not replaceTrack but #804091 in disguise.

Deleted: renderbug.png 61.9 KB

	renderbug.png 61.9 KB View Download

easier repro instructions than #19:
1. open https://webrtc.github.io/samples/src/content/peerconnection/pc1/ and make a call
2. ensure things are still moving
3. open dev tools
4. if video freezes continue. else close devtools and go to (3)
5. pretend not to have noticed video freeze and call localStream.getVideoTracks()[0].stop()
6. observe that both local and remote video show a frozen image. Assume this is ok
7. execute replaceTrack, determine its broken when its not.

So we should file a new bug, something like "Sometimes when dev tools is openened, video stops rendering properly for existing and future tracks"?

Let's continue that discussion in  https://crbug.com/804091 .
Thanks everyone.