Bug 209242 - unmute event never fired on remote WebRTC tracks on packet reception
Summary: unmute event never fired on remote WebRTC tracks on packet reception
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari 13
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-03-18 11:23 PDT by jib
Modified: 2020-03-26 06:39 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jib 2020-03-18 11:23:50 PDT
According to the spec example https://w3c.github.io/webrtc-pc/#simple-peer-to-peer-example the following should work, but does not work in Safari:

  pc.ontrack = ({track, streams}) => {
    // once media for a remote track arrives, show it in the remote video element
    track.onunmute = () => {
      // don't set srcObject again if it is already set.
      if (remoteView.srcObject) return;
      remoteView.srcObject = streams[0];
    };
  };

STRs:
 1. Open https://blog.mozilla.org/webrtc/rtcrtptransceiver-explored/ and scroll down and click the "Result" button in the first jsfiddle
    (or use direct link: https://jsfiddle.net/jib1/z0desL8x/89/show )
 2. Share camera and microphone
 3. Click the first Remote control button to add a transceiver.

Expected result (like Chrome, Firefox & Edge):

  pc.ontrack with transceiver and streams
  transceiver.receiver.track.onunmute

Actual result (like Chrome, Firefox & Edge):

  pc.ontrack with transceiver and streams


In the other browsers, tracks surfaced in pc.ontrack are in muted state, and the unmute event fires on them when their packets first arrive.
In Safari, tracks surfaced in pc.ontrack are instead in unmuted state, and no unmute event ever fires when their packets first arrive.

This is a web compat issue.

https://wpt.fyi/results/webrtc/RTCPeerConnection-remote-track-mute.https.html?label=experimental&label=master&aligned
Comment 1 jib 2020-03-18 11:34:41 PDT
When observing Chrome behavior, beware of https://bugs.chromium.org/p/chromium/issues/detail?id=941740

I recommend looking at Firefox's behavior which is to spec.
Comment 2 Radar WebKit Bug Importer 2020-03-18 17:42:39 PDT
<rdar://problem/60610991>
Comment 3 youenn fablet 2020-03-23 04:55:46 PDT
Testing on WebKit ToT, we are passing the first two tests of https://wpt.fyi/results/webrtc/RTCPeerConnection-remote-track-mute.https.html?label=experimental&label=master&aligned so are mostly aligned with Chrome.
Current implementation unmutes track at setRemoteDescription resolution time.

It is actually hard to currently get the tome of first packet dedicated to audio/video. And I am not even sure this makes sense if the packet is not decodable.
I guess we could try to go a bit further and wait for first audio/video frame.
Comment 4 jib 2020-03-26 06:39:25 PDT
Ah hopefully that will show up in Safari soon then.

I was testing with Safari Tech Preview Release 102 (Safari 13.2, WebKit 15610.1.5.2) where it didn't work: https://fiddle.jshell.net/jib1/x7v32o0j/show

> It is actually hard to currently get the tome of first packet dedicated to audio/video. And I am not even sure this makes sense if the packet is not decodable.

Firefox implements it here in case it helps: https://searchfox.org/mozilla-central/rev/4d9cd186767978a99dafe77eb536a9525980e118/media/webrtc/signaling/src/mediapipeline/MediaPipeline.cpp#559