Issue in Simulcast implementation for Firefox - Unified Plan

In Simulcast implementation for Firefox - Unified Plan, I am able to view multiple streams and their resolutions in about:webrtc to confirm that simulcast is working fine , like we do in chrome://webrtc-internals.
I am getting 3 ssrc-group: FID in createAnswer() from JVB. Is that correct ?

I don’t understand what is the issue here. If RTX is enabled, there will be 3 FID groups and a SIM group in the answer generated by the browser for the offer received from Jicofo.

1 Like

In Simulcast implementation for Firefox - Unified Plan, I am not able to view multiple streams and their resolutions in about:webrtc to confirm that simulcast is working fine , like we do in chrome://webrtc-internals.
Even though I am getting simulcast lines

about:webrtc for Firefox doesn’t show as much information as chrome webrtc-internals. You may want to file a bug for this on https://www.bugzilla.org/ but as long as you see the simulcast line in the SDP, it is guaranteed that the client is sending the simulcast streams. Also, the fact that one endpoint can view the FF endpoint in HD whereas another endpoint views the same FF endpoint in LD also confirms that simulcast is being used.

1 Like

In case of Chrome for SDP Munging in simulcast,
If i have the highest network , i am able to send the 3 streams (which is absolutely correct) and the 1 receiver is at the lowest end and 2nd receiver is at the highest bandwidth and maxFrameHeight sent to JVB via Collibri "ReceiverVideoConstraint " is same , then they both reeceive the same resolution.
But as per the simulcast understanding, there must be different resolutions at receiver side (with different networks ) but the result is depending on receiver maxFrameHeight not on the receiver’s bandwidth…
Can you please confirm the usecase what might be the expected result.

The resolution received from the SFU depends on what is being requested via ReceiverVideoConstraint (user preferred) and also based on what is available b/w. If the receiver is requesting HD but the available downlink can only support SD stream, that is what the SFU will choose to send.