文 / Philipp Hancke

译 / 元宝

审校 / Ant

原文：

https://webrtchacks.com/a-playground-for-simulcast-without-an-sfu/

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

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

Playground

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

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

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

原始的Chrome SDP

More...

webrtc自带了Simulcast功能，可以将一个分辨率的流编码成多个分辨率并发送，观看端可以根据带宽去动态的选择某个分辨率，也可以自己选择某个分辨率，据说在webrtc M70版本提供了对外的接口开启Simulcast，并 vp8，vp9，h264三种编码器都支持Simulcast功能，但是在M70版本以下并不支持h264编码器的Simulcast功能，如果在M70版本以下使用Simulcast功能，需要通过修改SDP来开启，话不多说，直接上代码：

More...

There’s new functionality with the new API and the Unified Plan SDP format:

• Early media: after an offer is sent, the calling side can receive media before receiving the answer

• Support for multiple or no media streams for a given track

• With sender objects you can control media with sender.setParameters()

• With transceiver objects, you can more directly control certain aspects of SDP generation.

More...

RTP重传是一种有效的丢包恢复技术，适用于具有宽松延迟界限的实时应用。该文档描述了用于
执行重传的RTP有效载荷格式。重传的RTP分组在与原始RTP流分开的流中发送。假设从接收器
到发送器的反馈是可用的。特别是，本备忘录中假设提供了实时传输控制协议（RTCP）反馈，
该RTCP反馈在基于RTCP的反馈（表示为RTP/AVPF）的扩展RTP配置文件中定义。

More...

作为实时音视频领域最火的开源技术，WebRTC 点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。5月20日，即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享，以下是对他演讲内容的整理。

大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：

● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？

● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。

● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。

● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。

为什么需要WebRTC网关

More...

作为实时音视频领域最火的开源技术，WebRTC 点对点的架构模式，无法支持大规模并发。如何在架构中引入服务端，一直是开发者关注的热点。5月20日，即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享，以下是对他演讲内容的整理。

大家好，我是黄开宁，来自即构科技，从事音视频开发已经超过10年了，虽然如此，在技术迅速更新迭代的时代，我们还是需要时刻保持学习的状态。今天，我主要跟大家介绍以下四个方面的内容：

● 为什么需要WebRTC网关？对于即构来说，目前所使用的系统已经较为成熟且经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？

● WebRTC通信模型的对比，分析不同的模型对应的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。

● 开源VS自研，主要介绍市面上的开源系统及其特点，另外还会分析即构自行研发系统的目的和出发点。

● Zego-Gateway架构的实践，分享即构在开发过程中遇到的一些难题和解决方法。

为什么需要WebRTC网关

More...

我们对他的演讲内容做了整理,整理后的文章分为上下两篇，本文为第二篇，欢迎阅读。

前面我给大家分享了：

第一，为什么需要WebRTC网关。对于即构来说，目前所使用的系统已经较为成熟，也经过了市场的检验，为什么还要在如此成熟的商用系统中加入WebRTC？

第二，WebRTC通信模型对比。分析了目前的WebRTC通信模型以及不同模型的适用场景，以便大家在选型时能结合自己的需求匹配对应的场景。

第三，开源VS自研。分享了目前市面上的一些开源系统及其特点以及即构自研WebRTC网关的目的和出发点。

下面，我将结合即构自研的WebRTC网关服务器方案，分享在开发过程中遇到的难点和解决办法。

More...

• Mesh 方案，即多个终端之间两两进行连接，形成一个网状结构。比如 A、B、C 三个终端进行多对多通信，当 A 想要共享媒体（比如音频、视频）时，它需要分别向 B 和 C 发送数据。同样的道理，B 想要共享媒体，就需要分别向 A、C 发送数据，依次类推。这种方案对各终端的带宽要求比较高。
• MCU（Multipoint Conferencing Unit）方案，该方案由一个服务器和多个终端组成一个星形结构。各终端将自己要共享的音视频流发送给服务器，服务器端会将在同一个房间中的所有终端的音视频流进行混合，最终生成一个混合后的音视频流再发给各个终端，这样各终端就可以看到 / 听到其他终端的音视频了。实际上服务器端就是一个音视频混合器，这种方案服务器的压力会非常大。
• SFU（Selective Forwarding Unit）方案，该方案也是由一个服务器和多个终端组成，但与 MCU 不同的是，SFU 不对音视频进行混流，收到某个终端共享的音视频流后，就直接将该音视频流转发给房间内的其他终端。它实际上就是一个音视频路由转发器。

More...

在Janus的众多插件中，大家最感兴趣的恐怕就是VideoRoom插件了。因为它实现的是一个音视频会议的场景，这正是大多数同学所需要的。而且在Janus众多的插件中VideoRoom应该也是最复杂的一个，如果你们撑握了它，再去看其它插件的实现就容易多了。

在VideoRoom中，包括了很多API，这些API是我们打开VideoRoom的一把钥匙，所以本文的重点就是讲解这些API。我相信当你把这些API都撑握之后，再去看VideoRoom插件的代码时就会更加游刃有余了。

VideoRoom插件

VideoRoom是Janus的一个插件，实现了一个SFU（Selective Forwarding Unit）型的音视频会议。如果你从数据转发的角度看，也可以把它认为是一个音视频路由器。

VideoRoom实现的音视频会议是基于发布/订阅模式。每个参与方都可以发布自己的实时音视频流，因此它可以实现几种不同的场景，比如泛娱乐化直播或多人的实时互动产品(如音视频会议、在线教育小班课等）。

考虑到此插件允许一个参与方可以打开多个WebRTC PeerConnection（如每个参与方可以有1个用于推流的PeerConnection和N个拉流的PeerConnection），所以每个参与方需要为订阅不同的流attach到VideoRoom插件几次(每attach一次就会生成一个Handle，每个Handle就是一个上下文)。

因此，对于每个参与方至少要有一个Handle用于管理与插件的关系（如加入一个房间，离开一个房间，静音/取消静音，发布，接收事件）。

每当参与方需要订阅另一个参与方发布的音视频流时，它需要创建一个新的Handle。新创建的Handle在逻辑上属于“从”Handle，它不能像“主”Handle一样可以做取消房间静音这样的操作。因此，从Handle唯一目的是提供一个上下文，在该上下文中创建一个recvonly类型的PeerConnection来订阅发布者的音视频流。

通过上面的描述我们可以知道，主Handle用于管理，而从Handle用于订阅音视频流。

More...

客户端SDK集成了WebRTC和libwebsockets，服务端使用了Janus，需要支持拉流秒开。

关于WebSocket
      Janus作为SFU，使用WebSocket协议与客户端通信。客户端在挑选开源库时其实没有太多选择，C层主要是libwebsockets库，这个也是Janus使用的库，还有Boost的Beast库，不过比较新，不敢踩坑，IOS上有RocketSocket，但不是跨平台，因此最后采用了libwebsockets库。
      libwebsockets库主要的问题是IO接口不太友好，需要自己启动一个线程轮询获取IO事件，在其回调中处理所有事件。

秒开要考虑的问题
libwebsockets IO的优化
      主要是写数据的处理。
      libwebsockets需要调用者自己维护发送队列，调用者调用lws_callback_on_writable来告知libwebsockets有数据要写，然后数据放入发送队列，libwebsockets会通过LWS_CALLBACK_CLIENT_WRITEABLE事件通知可写，这个时候调用者才可以从发送队列取出数据发送，这个是一个异步的过程。
      在libwebsockets的IO事件循环中，lws_service用于阻塞等待IO事件，但是lws_callback_on_writable并不会让lws_service退出阻塞状态，lws_service有一个最大等待时间，如果等待lws_service超时才处理待发送的数据无疑会增加整体接续时间。这里可以通过在调用线程中调用lws_cancel_service方法强制lws_service退出阻塞来立刻处理发送队列中的数据。这里需要用互斥锁对发送队列做一个同步。

More...