General Overview（OLD）

In several months of testing, we worked out a solution that allows multiple people to broadcast live in different places. It's a scheme aimed to make Planetside2's OUTFIT WAR live broadcast more interesting and exciting. We have only experimented with technical equipment now, and we have not yet developed methods for how different commentators, directors, cameras, and OUTFIT communicators operate.

在几个月的测试中，我们摸索出一套能够多人异地直播的方案。这样的方案可以让Planetside2的OUTFIT WAR直播变得更有趣，更激动人心。我们现在只进行了技术方面的探索，关于不同解说、导播、摄像头机位、OUTFIT沟通人如何运作我们还未有成熟的方法。

![](/media/202208/直播方案_English-导出_1660773406.png)

Download PDF：
[【附件】直播方案_English-导出.pdf](/media/attachment/2022/08/%E7%9B%B4%E6%92%AD%E6%96%B9%E6%A1%88_English-%E5%AF%BC%E5%87%BA.pdf)

**Noted that this is the solution we have implemented based on the network situation in China. Some policies in China make the bandwidth of the server very expensive. If you practice multi-person live broadcast in different places, you can use the SRS server with high configuration and large bandwidth to complete it directly. Instead of use the cloud live broadcast service from the cloud service provider.**

需要注意的是，这是我们根据中国的网络情况所实现的方案。中国的一些政策导致服务器的带宽变得很昂贵，如果你们需要做异地多人完全可以使用高配置大带宽的SRS服务器直接完成。而不需要使用云服务商的云直播服务。

We use SRT protocol and SRS live server and Mumble (Mumble is not the most suitable solution, but other solutions need to be developed combined with providers) to complete the whole process.

我们使用SRT协议和SRS直播服务器以及Mumble（Mumble不是最合适的方案，但其他方案需要根据直播服务商的SDK进行二次开发才可用）来完成整个流程。

When we first tried to implement multiplayer remote live broadcast, we found these problems:
1. If you use virtual LAN + NDi to push streaming, the network bandwidth usage will be unacceptably high. (NDi usually requires close to 150Mbps for picture transmission, so it is usually only used in the intranet).

2. The commentary needs to see the screen of the director. Of course, this is the most obvious problem. If the commentator can't see the director's picture, he can't explain it.

3. The delay is too high. It takes more than 10 seconds of delay for the streaming user → Tencent's cloud live broadcast service → the director → the commentator's computer. If the director needs to pull in several live streams at the same time, then the timing will be a nightmare (of course, we have not solved this problem at the moment, but we have low latency and can avoid this problem).

4. Mixed flow. This is the last small problem, there is a delay in the director's screen → commentary → Mumble capture, so this is also a small problem.

我们一开始试图实现多人异地直播时，发现有这些问题：
1.如果使用虚拟局域网+NDi推流，网络带宽占用将高得无法接受。（NDi通常需要接近150Mbps进行画面传输，因此通常只在内网中使用）。

2.解说需要看到导播的画面。当然，这是最显而易见的问题，如果解说看不到导播的画面就无法解说。

3.延时太高。推流用户→腾讯的云直播服务→导播→解说员的电脑需要花费10秒以上的延迟。如果导播需要同时拉入好几条直播串流，那么对时将会是噩梦（当然，目前我们也没有解决这个问题，但我们现在延迟很低，可以逃避这个问题）。

4.混流。这是最后一个小问题，导播的画面→解说→Mumble捕获是有延迟的，因此这也是一个小问题。

Our solutions are:
1. We use the cloud live broadcast service of the cloud service provider and the privately deployed live broadcast server.
2. We use the SRT protocol for streaming in all processes outside the local area network (LAN), and use the privately deployed SRS server for streaming.
3. Use the privately deployed SRS live server. Explain the use of ffplay to pull streams to ensure ultra-low latency. This can transmit the picture to any corner of the earth without more than 2s delay.
4. Use OBS to capture Mumble's audio on the second computer and add appropriate delay, then mix it with the picture provided by NDi, and finally push it to the live broadcast website.

我们的解决方案是：
1.我们使用云服务商的云直播服务和私有化部署的直播服务器。
2.我们在所有局域网（LAN）以外的流程都使用SRT协议进行推流，并使用私有化部署的SRS服务器推流。
3.使用私有化部署的SRS直播服务器。解说使用ffplay拉流保障超低延迟。这样可以将画面传输到地球的任何一个角落但延迟不会超过2s。
4.在第二台电脑使用OBS捕获Mumble的音频并加上适当的延迟，然后混入NDi提供的画面，最终推流到直播网站。