On 7/6/17 6:10 AM, prerak jain wrote:
On Thursday, 6 July 2017 04:43:01 UTC+5:30, Nils Ohlmeier  wrote:
On Jul 5, 2017, at 05:28, [email protected] wrote:

We are testing FF/Simulcast with our SFU, expecting FF to send RTP of all three 
streams as advertised in SDP.

simulcast  parameters
{
                        encodings: [{
                            rid: "720",
                        }, {
                            rid: "360",
                            scaleResolutionDownBy: 2,
                        }, {
                            rid: "180",
                            scaleResolutionDownBy: 4,
                        }, ]
};
Not sure if it makes a difference, but have you tried to add the maxBitrate 
parameter to the encodings?
Like here: 
http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62
 
<http://searchfox.org/mozilla-central/source/dom/media/tests/mochitest/test_peerConnection_simulcastOffer.html#62>

Offer:

a=simulcast: send rid=720;360;180
a=extmap:3/sendonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rid:720 send
a=rid:360 send
a=rid:180 send

Answer:

a=simulcast: recv rid=720;360;180
a=extmap:3/recvonly urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rid:720 recv
a=rid:360 recv
a=rid:180 recv

But when we check the outgoing rtp packet header extension, we can see that it 
is sending packets for resolution 180p (because the extension is corresponding 
to rid 180)

As per the simulcast, we expect it to send all three streams(720, 360 & 180). 
Any idea  what are we doing wrong here?
Have you looked at all RTP packets?
I’m asking because I noticed that in Firefox 56 we only include the RID in the 
very first packet for each frame. So you need to carefully search for the 
beginning of the next frame to find the 2nd and 3rd RID.

Best regards
   Nils Ohlmeier
We are able to see all the simulcast streams after using the maxBitrate 
parameter as you suggested. But I think it's a bug in Firefox that it doesn't 
start the simulcast stream without the maxBitrate being set to the encodings.
Yeah, this is an unfortunate property of the webrtc.org simulcast implementation; if you do not set a max-bitrate, it allocates all available bandwidth to the smallest simulcast encoding, leaving none for the remaining encodings. We would need to implicitly set a max-bitrate based on the resolution of the encoding for this to work.

Best regards,
Byron Campen
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media

Reply via email to