Open Bug 1558580 Opened 6 years ago Updated 3 years ago

Firefox 68.0b8 - WebRTC not sending video after block and unblock video

Categories

(Core :: WebRTC: Audio/Video, defect, P3)

Product:
Core
Component:
WebRTC: Audio/Video
Version:
68 Branch
Type:
defect

Tracking

()

People

(Reporter: ychoo, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Scenario:

  1. User A performs video call (sendrecv direction) to User B
  2. User A blocks video (recvonly direction)
  3. User A unblocks video (sendrecv direction)

Actual results:

After User A unblocks video in step (3), User B is not receiving remote video from user A. We confirm user A is not sending video via User A call statistics and Wireshark dump.

Expected results:

After User A unblocks video in step (3), user B should be able to receive remote video from user A.

Note: The same flow works for Firefox 67 or older.

Add'l notes.

The unblock problem happens if User A temporarily disable local video mediastream track in step (2), and re-enable the local video mediastream track in step (3). It works if we DO NOT temporarily disable and re-enable the local video track.

Moving to hopefully a better component.

Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core

Thank you for the report. In the test gUM page [1], I do a temporary disable of video track and then re-enable and I cannot reproduce it. Can you please try in the latest Nightly? Can you please provide a link that reproduces the issue?

[1] https://mozilla.github.io/webrtc-landing/gum_test.html

Flags: needinfo?(ychoo)

I just tried with the latest nightly build and it is not working. It only fails iff video track is enabled/disabled and SDP offer/answer negotiation are performed. I'm not able to provide a test link due to the use of non public media server usage.

Note: If I replace the video mediastream track enable/disable with transceiver direction then the video works fine. Also the existing code is using addTrack instead of addTransceiver.

Flags: needinfo?(ychoo)

Byron, do you mind helping to triage this one? Thanks!

Flags: needinfo?(docfaraday)

This works fine in our tests, so we're going to need a link to a test-case that reproduces this bug.

Flags: needinfo?(docfaraday) → needinfo?(ychoo)

Ychoo, I'm also unable to reproduce. I'm using the following steps. Are you able to repro with these steps?

  1. Open https://blog.mozilla.org/webrtc/rtcrtptransceiver-explored/
  2. Scroll down to the text "You can try out this remote-control below in Firefox (59): "
  3. Click the Result button immediately below it, and allow camera
  4. Click the transceiver = pc.addTransceiver(trackA, {streams}) button
  5. (Optionally, how I interpret comment 1) click the transceiver.sender.track.enabled = false button
  6. Click the button labeled transceiver.direction = "recvonly" button
  7. Click the buttonlabeled transceiver.direction = "sendrecv" button
  8. (Optionally, how I interpret comment 1) click the transceiver.sender.track.enabled = true button

When I do this, I see remote video appear, pause, and resume respectively from steps 4-8, with or without the optional steps. Does it work for you?

I'm not sure I got the exact steps right based on comment 1 and comment 4, so feel free to rearrange the steps any way needed to reproduce the problem. Thanks!

Flags: needinfo?(ychoo)
Flags: needinfo?(ychoo)

(In reply to ychoo from comment #4)

Note: If I replace the video mediastream track enable/disable with transceiver direction then the video works fine. Also the existing code is using addTrack instead of addTransceiver.

So my steps in comment 7 do not use addTrack. Can you elaborate on exactly what steps are needed on the API?

addTrack has very different semantics: it always adds a new m-line, which fires a new track event with a different track. So if you do:

  1. const senderA = pc.addTrack(trackA), then later
  2. pc.removeTrack(senderA), then later
  3. const senderA2 = pc.addTrack(trackA)

...then video won't resume automatically on the other end's existing track. IOW senderA and senderA2 are different. Makes sense?

The original flow is

  1. senderVideoA = pc.addTrack(videoTrackA, mediaStream);
  2. senderVideoA.track.enable = false; // block
  3. senderVideoA.track.enable = true; // unblock
Flags: needinfo?(ychoo)

More details

  1. senderVideoA = pc.addTrack(videoTrackA, mediaStream);
  2. senderVideoA.track.enable = false; // block
    Renegotiate media with recvonly video with media server
  3. senderVideoA.track.enable = true; // unblock
    Renegotiate media with sendrecv video with media server

Ychoo, here's a modified version of the fiddle in comment 7 that uses addTrack. Are you able to reproduce the issue by clicking the various buttons in the order that matches your steps?

Flags: needinfo?(ychoo)

Do we understand what the reporter is seeing here? jib, do you believe it is a bug, or a misunderstanding of the APIs? I'm not sure, but I think that's what you imply in comment 8?

Flags: needinfo?(jib)

Based on the statement that it worked in 67 but not 68, and similar 68 regressions like bug 1576771 comment 7 in this area, I don't think it's a misunderstanding.

That said, I can't repro it. Here's a fiddle https://jsfiddle.net/jib1/209ankft/ based on comment 10.

It's possible there are timing differences with a media server involved. I say that because my local-loop fiddle is clearly too quick to be practical, renegotiating "recvonly" before the black frame from track.enabled = false even makes it to playback on the other end, so I see a freeze-frame rather than the clearly intended black. If I add some delays I get black, but still can't repro the symptom.

Byron, have you discovered anything new that looks like it could explain this one?

Flags: needinfo?(jib) → needinfo?(docfaraday)

I might think this was related to bug 1606875, except reporter said they verified no network media flow with wireshark in the initial report, which is not part of bug 1606875.

Flags: needinfo?(docfaraday)

My understanding from the comments above is that it looks like a real error. I am gonna confirm it but give it a small priority because the reported hasn't responded for a long time and the error does not reproduce locally (according to the reports). Feel free to upgrade when you know more.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

For now, our workaround is to change the transceiver direction. The original problem was due to enabling/disabling the video track via RTCRtpSender from rtcPeerConnection.addTrack(). I think the problem will not happen with the newer transceiver flow.

rtpSender.track.enable = false; // temporarily disable local video track
// Perform video renegotiation (RECV_ONLY) with media server
rtpSenderTrack.enable = true; // re-enable local video track
// Perform video renegotiation (SEND_RECV) with media server

Flags: needinfo?(ychoo)

(In reply to ychoo from comment #16)

For now, our workaround is to change the transceiver direction. The original problem was due to enabling/disabling the video track via RTCRtpSender from rtcPeerConnection.addTrack(). I think the problem will not happen with the newer transceiver flow.

rtpSender.track.enable = false; // temporarily disable local video track
// Perform video renegotiation (RECV_ONLY) with media server
rtpSenderTrack.enable = true; // re-enable local video track
// Perform video renegotiation (SEND_RECV) with media server

So, MediaStreamTrack.enable doesn't have any effect on transceiver direction. It would be interesting to know whether this works for you, however, since we have some problems around MediaStreamTrack.enable (see bug 1606875).

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.