webrtc cdn_动态CDN用于具有转码功能的低延迟WebRTC流

webrtc cdn

In the first part we have deployed a simple dynamic CDN for broadcasting WebRTC streams to two continents and have proved on the example of a countdown timer that the latency in this kind of CDN is actually low.

在第一部分中，我们部署了一个简单的动态CDN，用于将WebRTC流广播到两个大洲，并在倒计时计时器的示例中证明，这种CDN的延迟实际上很低。

However, besides low latency, it is important to provide good broadcast quality to users. After all, this is what they are paying for. In real life the channels between Edge servers and users can differ in bandwidth capacity and quality. For example, we are publishing a 720p stream at 2 Mbps, the user is playing it on an Android phone using 3G connection in an unstable signal reception area and the 360p maximum resolution that provides smooth picture at 400 Mbps is 360p.

但是，除了低延迟外，为用户提供良好的广播质量也很重要。 毕竟，这就是他们所支付的。 在现实生活中，边缘服务器和用户之间的通道带宽容量和质量可能会有所不同。 例如，我们以2 Mbps的速度发布720p的流，用户在不稳定的信号接收区域中使用3G连接在Android手机上播放该流，而以400 Mbps的速度提供流畅图像的360p最大分辨率为360p。

The devices and browsers the viewers are using may differ a lot. For example, we are publishing a WebRTC stream using VP8 codec in Chrome on PC and the viewer is playing the stream in Safari on an iPhone, which supports only H264 codec. Or vice versa, we are publishing an RTMP stream from OBS Studio, coding the video in H264 and the sound in AAC, and the client is using a Chromium-based browser which supports only VP8 or VP9 for the video and Opus for the sound.

观众所使用的设备和浏览器可能会有很大差异。 例如，我们正在PC上的Chrome中使用VP8编解码器发布WebRTC流，而查看器正在仅支持H264编解码器的iPhone上的Safari中播放流。 反之亦然，我们正在从OBS Studio发布RTMP流，以H264编码视频，并以AAC编码声音，并且客户端使用基于Chromium的浏览器，该浏览器仅支持VP8或VP9的视频和Opus的声音。

We may need as well to enhance the quality of the initial publishing. For example, we are sharing a stream from an IP-camera in a natural park, most of the time the picture is static, and the camera is delivering it at 1 frame per second. However, we want to provide to viewers 24 frames per second. What is to be done, if there is no possibility to replace the camera or modify its settings?

我们可能还需要提高初始发布的质量。 例如，我们在自然公园中共享来自自然公园中IP摄像机的流，大多数情况下图片是静态的，并且摄像机以每秒1帧的速度传送。 但是，我们希望每秒向观众提供24帧。 如果无法更换相机或修改其设置怎么办？

In all these cases we will need to transcode the stream on the server, that is decode each received frame and then encode it with new parameters. Besides, the parameters to be modified are often only known on the client’s side. Let’s have a look at how to achieve transcoding in CDN while keeping a balance between broadcast quality and server load.

在所有这些情况下，我们将需要在服务器上对流进行转码，即解码每个接收到的帧，然后使用新参数对其进行编码。 此外，要修改的参数通常仅在客户端知道。 让我们看一下如何在CDN中实现转码，同时保持广播质量和服务器负载之间的平衡。

转码：如何，在哪里以及为什么？ (Transcoding: how, where and why?)

Assume we are aware of the stre