Hello!
We have an odd (or maybe not) case when receiver video track is associated with same transceiver that holds outbound video track.
This results in “stable” black video on receiver track (any mutes/unmutes don’t help). Also in webrtc-internals all stats for track look fine, packets receiving, frames decoding. At the same time third participant sees same track, all OK.
Compared local and remote SDP’s, all seem OK (mids, directions, ssrc) and match with SDP from “correct” sessions. No errors… Track fires “onmute” event 5 seconds after initial “onunmute” and never unmutes back.
I am stuck and don’t know where I can dig further. Any points or directions would be life-savers.
Never had luck to reproduce it, but might happen occasionally (rare).
We use lib-jitsi-meet (1532) and jvb (6173). SourceNameSignalling and MultiStream are disabled, Simulcast is enabled.
Made some assumptions (that could be wrong) and questions I didn’t find answers for yet:
- Can bidirectional transceiver cause a problem like this? Should all transceivers be unidirectional? I’ve seen discussions where bidirectional transceiver with bundles is not advised - https://groups.google.com/g/discuss-webrtc/c/EgMmxXHidA0/m/N85RIce9BgAJ
- Maybe somehow Codec parameter x-google-bitrate on transceiver’s outbound track messes up inbound track?
- What could possibly cause receiver track go to already used transceiver? (it should be used by mixedlabel)
This particular case was “caught” when sender was from Android Chrome and receiver on MacOS Chrome, but had at least one case with Desktop Chromium - Chromium.
Ready to provide any additional information.
