用于WebRTC流的低延迟和转码的动态CDN


第一部分中,我们以倒数计时器为例部署了一个简单的动态CDN,用于将WebRTC流广播到两个大洲,并确保此类CDN中的延迟确实很低。


但是,除了低延迟之外,为观看者提供良好的广播质量也很重要,因为他们为此付费。 在现实生活中,边缘服务器和订户之间的通道在带宽和质量上可能是不同的。 例如,我们发布了分辨率为720p,比特率为2 Mbps的流,并且用户在信号接收不安全的区域中使用3G连接在Android智能手机上使用3G连接播放该图片,并且图片的平滑度达到了最大分辨率,而比特率为400 Mbps的分辨率仅为360p 。


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


您可能还需要提高原始出版物的质量。 例如,我们将IP摄像机中的流以一定的预留量进行分配,大多数情况下图片是静态的,摄像机以每秒1帧的频率对其进行分配。 同时,我们希望观看者每秒播放24帧。 如果无法更换相机或更改其设置怎么办?


在所有这些情况下,都将需要在服务器上对流进行代码转换,即对每个接收到的帧进行解码,并随后使用新参数进行编码。 此外,通常只有客户端才知道必须更改的参数。 让我们看看如何在CDN中提供转码,并在广播质量和服务器负载之间取得平衡。


转码:如何,在哪里以及为什么?


假设我们知道客户端想要接收的流参数。 例如,观看者开始播放流,并且WebRTC统计信息中的帧丢失数量告诉我们必须降低分辨率和比特率 直到客户切换频道 。 在这种情况下,默认情况下,流将在查看器连接到的边缘服务器上进行转码。



如果客户端不支持发布流时使用的编解码器,则可以将转码分配给Edge和Origin服务器。


前提是选择了源服务器和/或边缘服务器的配置时,这两种方法都只能是一个临时解决方案。 转码始终是逐帧执行的,因此对处理器资源的要求很高。 因此,一个处理器内核能够对很少数量的线程进行转码:


权限比特率,Kbps线程数
360p13005
480p18003
720p30002

即使我们为所有需要相同媒体流参数的订户启动一个转码过程,也可能有几个具有不同参数的查看器将选择服务器的所有资源。


因此,正确的解决方案是在CDN中选择特殊服务器进行代码转换任务,然后根据这些任务选择服务器配置。


将转码器节点添加到CDN


因此,我们将在CDN中部署一台服务器,该服务器在欧美数据中心中具有转码器角色



配置代码转换器服务器:


  • 转码器1欧盟

cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder 

  • 转码器1美国

 cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder 

cdn_profiles.yml码参数必须在cdn_profiles.yml文件中作为特殊配置文件在Edge服务器上描述。 例如,考虑三个默认配置文件:


  • 转码为640x360分辨率,每秒30帧,每90帧发送一个关键帧,使用OpenH264编码器的H264视频编解码器,Opus音频编解码器48 kHz

 -640x360: audio: codec : opus rate : 48000 video: width : 640 height : 360 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264 

  • 使用OpenH264编码器将代码转换为1280x720分辨率,H264视频编解码器,而无需进行音频代码转换

  -720p: video: height : 720 codec : h264 codecImpl : OPENH264 

  • 转码为1280x720的分辨率,每秒30帧,每90帧发送一个关键帧,比特率2 Mbit / s,使用OpenH264编码器的H264视频编解码器,无需音频转码

  -720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264 

我们在o-eu1上发布分辨率为720p的test流,并在e-eu1上播放此流,并在流名称中指定配置文件,例如test-640x360



流已转码!


现在,我们可以描述Edge服务器上的许多配置文件,例如-240p,-360p,-480p,如果在客户端,根据WebRTC统计信息,将诊断出大量丢失的帧,并自动以较低的分辨率重新请求流。


按大陆分组CDN节点


现在我们的代码转换器服务器是平等的。 但是,如果我们想按地理位置对流进行转码:对于美国的美国观众,对于欧洲的欧洲观众,该怎么办? 顺便说一下,这将减少跨大西洋频道的负载,因为在这种情况下,只有源流将从Origin EU服务器流向America(反之亦然),而不是所有经过转码的版本。



在这种情况下,必须在代码转换器节点的设置中指定组


  • 转码器1欧盟

 cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU 

  • 转码器1美国

 cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US 

另外,该组必须添加到边缘服务器设置中


  • 边缘1-2欧盟

 cdn_groups=EU 

  • Edge 1-2美国

 cdn_groups=US 

使用新设置重新启动节点。 我们在o-eu1上发布分辨率为720p的test流, e-eu1通过转码在e-eu1上播放此流



确保将流转换为t-eu ,为此,我们打开统计页面http://t-eu1.flashphoner.com:8081/?action=stat ,然后在“本Native resources部分中查看视频编码器和解码器



同时,统计信息中t-us1上没有视频编码器



更多转码器:负载平衡


假设观看者的数量持续增长,并且该大陆上一台Transcoder服务器的容量已经不够。 好,再添加一台服务器



  • 转码器2欧盟

 cdn_enabled=true cdn_ip=t-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU 

  • 转码器2美国

 cdn_enabled=true cdn_ip=t-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US 

但是,现在我们面临着两个代码转换器之间的负载平衡问题。 为了不允许所有线程通过一台服务器,我们将限制代码转换器节点上的最大允许平均处理器负载


 cdn_node_load_average_threshold=0.95 

当平均处理器负载除以可用内核数达到此值时,服务器将停止接受对新线程进行转码的请求。


您还可以限制同时运行的视频编码器的最大数量


 cdn_transcoder_video_encoders_threshold=10000 

达到此数量后,即使加载处理器仍允许,服务器也将停止接受对转码流的请求。


无论如何,代码转换器服务器都将继续将已在其上进行代码转换的流分发到边缘服务器。


结尾如下


因此,我们已经在CDN中部署了专用服务器来对媒体流进行代码转换,因此,我们可以根据观众的设备功能和频道质量为观众提供广播质量。 但是,我们仍然没有解决限制访问线程的问题。 我们将在最后一部分中考虑它。


参考文献


低延迟WebRTC流CDN是基于 Web呼叫服务器的内容交付网络。

Source: https://habr.com/ru/post/zh-CN477874/


All Articles