User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce: Tested simulcast for Firefox with jitsi Actual results: Output video framerate from firefox is very low. Attached a wireshark trace with firefox encoding 2 simulcast streams (180p and 360p), can see large gaps between the packet number 132 and 216, for example. They represent subsequent packets of stream 4244151133, and they are about half a second apart. 3 streams (720p, 360p, 180p) gave similar results. This was on the official nightly build, version 56.0a1 (2017-06-29) (64-bit) (Applying the following wireshark filter will help reduce the noise: "(((rtp && udp.dstport == 10000 && rtp.p_type == 100)))" Expected results: Should output 30fps for all simulcast streams.

Byron do you have an idea why the simulcast from Firefox appears to be so bursty?

That would be a question for an expert on webrtc.org, I think.

Seeing what appear to be better results in 56.0a1 (2017-07-14) (64-bit), framerate on the receive side looks pretty consistent and frame output in wireshark looks pretty good. We don't have the full rid layer parsing on the bridge yet, so I think our layer selection isn't the best at the moment, but at least the stream being forwarded has good framerate.

This is a P1 bug without an assignee. P1 are bugs which are being worked on for the current release cycle/iteration/sprint. If the bug is not assigned by Monday, 28 August, the bug's priority will be reset to '--'.

Mass change P1->P2 to align with new Mozilla triage process

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information