{"id":310,"date":"2017-09-30T03:48:42","date_gmt":"2017-09-30T03:48:42","guid":{"rendered":"https:\/\/blog.mozilla.org\/webrtc\/?p=310"},"modified":"2017-09-30T22:59:20","modified_gmt":"2017-09-30T22:59:20","slug":"when-your-video-freezes","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/webrtc\/when-your-video-freezes\/","title":{"rendered":"When your video freezes"},"content":{"rendered":"

We recently fixed a regression<\/a> in Firefox 57 that the max-fs<\/code> parameter in fmtp<\/code> lines had stopped working in Firefox 56. Because it got reported to us while Firefox 56 was still in it\u2019s Beta cycle we uplifted the patch for Firefox 56 as well.<\/p>\n

It got diagnosed a short time ago that this patch had unforeseen consequences: it can result in Firefox stopping to send video in the middle of a call.
\n<\/p>\n

What causes the video to freeze<\/h4>\n

By default Firefox adds fmtp<\/code> lines like this to it\u2019s SDP offers:<\/p>\n

  a=fmtp:120 max-fs=12288;max-fr=60\r\n  a=fmtp:121 max-fs=12288;max-fr=60<\/pre>\n
If Firefox 56 and later receive this the max-fs<\/code> value will be respected. But in Firefox 56 and 57 the problem arises when the max-fs<\/code> parameter is not present in the remote SDP.<\/p>\n
So if the remote SDP contains fmtp<\/code> lines like this:<\/p>\n
  a=fmtp:120<\/pre>\n
Firefox 56 and later will interpret the missing max-fs<\/code> parameter literally as a zero. Also the absence of an fmtp<\/code> attribute for the chosen video codec will be interpreted as a zero max-fs<\/code> value.<\/p>\n
The result is that calls will get established as normal. But if:<\/p>\n