| Summary: | unmute event never fired on remote WebRTC tracks on packet reception | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | jib |
| Component: | WebRTC | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | eric.carlson, webkit-bug-importer, youennf |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 13 | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
jib
2020-03-18 11:23:50 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. 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. 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 |