不需要SFU而实现WebRTC联播，appear.in的WebRTC工程师Philipp Hancke实现了在Chrome和Firefox之间的联播。LiveVideoStack对原文进行了摘译。

文 / Philipp Hancke

译 / 元宝

审校 / Ant

同步联播是WebRTC用于多方会议的一个很有趣的方面。简而言之，它意味着可以同时发送三种不同的分辨率（空间可伸缩性）和不同的帧速率（时间可伸缩性）。

通常，需要一个SFU才能利用联播。但是有一个方法可以使在两个浏览器之间或在单个页面内效果可见。这对于做单页测试或使用联播功能是非常有用的，特别是能够只启用某些空间层或控制特定流的目标比特率。

Playground

Playground有两种变体，一种用于Chrome，另一种用于Firefox。Chrome版本使用了我们在2014年夏天的谷歌环聊中首次看到的旧的SDP munging hack 。Firefox使用‘RTCRtpSender.setParameters’来启用同步联播。两者都没有遵守最新的规范，但这并不会影响任何人对它的使用。

两种变体都可以显示视频图像，首先是发送者图像和总体比特率/帧速率图，其后是三个不同的空间流，每个空间流具有用于比特率和帧率的对应图。

由于我们不想涉及到服务器的内容，所以我们需要破解一些东西。幸运的是，有一个Chrome的测试验证了这个想法。Chrome和Firefox都使用一个数据包的RTP SSRC将其路由到某一个特定的媒体流。这些SSRC可以在SDP提供中找到：

原始的Chrome SDP

和2014年一样，重要的是多个‘a=ssrc：’的行以及‘a=ssrc-group：SIM’的行。

原始的Firefox SDP

在Firefox中，重要的联播比特数是‘a = rid’的行和‘a = simulcast’的行（从底部开始的第4行）。注意：这是来自规范的旧版本，可能会有所变化。

WebRTC hack

我们需要让我们的同行相信，它实际上正在接收三种不同的视频流——低、中、高的比特率——而不仅仅是其中一种。为实现这一目标，我们需要创建自己的SDP，其中包含从SSRC到跟踪的不同映射。这是有点苛刻的，但这个网站被称为webrtchacks是有原因的！

我们最终将Firefox产品转换为：

这显示了三个不同的媒体部分（按照统一计划的规定），它将在接收器处触发“跟踪”事件三次，为我们提供三个不同的 MediaStream对象以附加到视频元素，并且还允许使用getStats API来为各个比特率制作图表。

请参阅SDP的源代码，了解如何创建它。

调整各个层的比特率

Chrome长期以来一直使用硬编码表来表示各个空间层的同步比特率。

该表显示了分辨率（例如1920×1080），空间层数（3）以及最大，最佳和最小比特率。

感谢‘setParameters’让我们现在可以偏离这个表中定义的比特率并获得一些创意。如果你运行该示例而不进行任何修改，你可以看到联播以大约3.2mbps的比特率在发送。它分为三个不同的空间流，大约是150kbps，500kbps和2500kbps，与表中的设置相匹配。

让我们通过将这个JavaScript粘贴到控制台来修改它：

这将中分辨率（640×360）空间层的目标比特率设置为300kbps，将720p流的目标比特率设置为400kbps。编码器可以很好地匹配这些比特率，它们的质量非常好，即使将720p流的比特率设置为400kbps也是如此。

如果我们将720p的目标比特率降低到200 kbps，那么我们可以看到由于帧率下降而导致的视觉退化，因为只有基本的时间层被发送。对于720p的流，你可以用像200kbps一样低的比特率来使用...

此图表（以及下面的图表）中均是左侧为比特率，右侧为帧率。

这对于在SFU中成功实现同步联播的任何人来说都不是新闻，但是在没有任何服务器的情况下，在单个页面中展示这个效果还是很惊人的。

到处都是Bug

最初构建页面的主要动机之一是探索Firefox中对联播的支持。它没有预期的那么好，最大的问题是因为Firefox以及我在SFU实现中的错误。在playground的页面上，我可以证明它不在SFU中，但在Firefox中出现了问题。

中分辨率图层的比特率仅以300kbps，而不是Chrome发送的500kbps。尽管请求超过2000kbps，我们只能为高分辨率层获得500kbps的速率。部分原因是SDP munging中的一个非常巧妙的错误，它影响了低分辨率层的设置。这很容易在JavaScript中修复。

接下来，有一个问题是高分辨率层的配置被修改了，这将很快在Firefox中登陆，并将被提升到Beta和ESR。有了修复，比特率就会高得多：

中等分辨率层的目标比特率也根据我的要求更改为500kbps。把我当成一个非常满意的客户！

Jitsi的Brian Baldino发现了另外一个有趣的问题。当禁用高中空间层时，Chrome将以每秒超过一兆比特的比特率继续发送。这是为了保持比特率估计值高而填充数据。

这实际上是对旧版Chrome问题非常好的再现，希望在一个更具体的用例中出现的不良行为，以及在单个页面测试中进行复制，使这更容易修复。

最后但并非最不重要的是，您可能已经注意到Chrome中本地视频的高帧率，接近90帧。Chrome似乎将所有发送流的比特率和帧率都加了起来。这（可能）不太正确，所以这里有另一个bug报告。

同步联播对于构建高级WebRTC应用程序非常重要。希望这个playground让Web开发人员更容易访问它。特别感谢Florent Castelli在Chrome中实现‘setParameters’，并允许更多的修补以及Byron Campen在Firefox问题上的快速支持。