4K视频在WebRTC中的实时传输

  • Post author:
  • Post category:其他


人们对音视频体验的追求是不断在增长的,当1080P已经逐渐成为主流分辨率的情况下,追求更高品质的画面,将会是音视频工作者需要提前去研究的。

最近对4K视频(分辨率 4096×2160 / 3840×2160)在WebRTC中的采/编/解/渲染进行了一次尝试,总的来说还不错。

在描述我的实验之前,让我们来看一篇文章。(请容忍我的英文翻译水平,你可以直接跳过我的翻译看

原文

以下是我对此文的翻译:

很多人都联系过我询问有关使用4K和WebRTC的问题。各种设备/服务供应商已经开始宣扬他们是如何支持4K视频的。这消息当然是挺好的,但却没能让我疯狂起来。

WebRTC是否支持4K视频?回答是肯定的(Chrome桌面版至少支持使用getUserMedia来获取到4K)。但考虑一下实际中可行吗?不。

4K视频的分辨率为4096×2160(或3840×2160)。要传输4K视频,您需要至少15 Mbps、最好是20 Mbps的码率来支持30 fps的帧率。对于视频会议,您需要以此速度长时间地进行双向互联网连接。当连接方数多的时候,将会变得非常糟糕。所以,你真的拥有这样一个理想的高速互联网连接吗?

在我看来你根本没有。

实际上我们很少有人具备这种网络条件。对于最后一英里的互联网连接,下行链接通常速度快连通性好,但您的上行链路速度通常较低。互联网服务供应商通常也会虚标带宽能力,这意味着你的速度怎样还要看他们的心情。

我自己的Google互联网服务有100 Mbps的服务,实际上,它在任何时间段内都很少超过10 Mbps。当然它可以冲到40 Mbps但不会持续很长时间。Netflix正在尝试传输4K视频,但这显然需要20 Mbps的下行链路,不像实时视频那样,Netflix可以缓冲一些数据来平滑边缘,并且也只需要发送1路即可。实时视频不会有这种奢侈。

另一个障碍是您的以太网NIC或WiFi。当你试图使用30-40Mbps的恒定码率时,你的网络带宽资源可能很快就饱和了。记住你是在一种基于廉价规则的消费级设备上来做个事情的。


你能通过WebRTC运行4K视频吗?是的,

维吉尼亚

,它可以。事实上,许多人已经对此进行了实验,确实有效。然后他们只是实验,每个人都连在同一个局域网上。考虑将4K WebRTC视频用于公网上作为产品是否切合实际?不。

随着时间的推移,互联网访问速度将会提高,毫无疑问,我们将能够更快地运行某些东西,也许4K会议将成为现实。但不是今天。

如果你正在看WebRTC视频,下面是每个流需要多少的带宽近似值:

模式 码率
4K 15-20Mbps
1080p 4-8Mbps
720p 1-4Mbps
VGA (640×480) 500K – 1Mbps
QVGA (320×320) 300-500K


你可以将QVGA放大到全屏,但它看起来不会很好。同样你可以将1080p缩减到一个小盒子那么大,这种情况下,你使用了较多的带宽而且它看起来也不好。


总而言之,WebRTC的4K至少在目前是营销炒作。更高的质量最终会一统天下吗?也许吧。但更快并不总是更好,100年后我们仍然在使用55英里/小时的速度来开车。

这篇文章主要对WebRTC上使用4K进行视频传输的担忧就是在现实中,在公网上很难找到能够长时间稳定满足传输要求的带宽资源。确实,就目前中国的网络状况来看,4K传输所需的带宽消耗是非常巨大的。也许在2020年5G时代真正到来的时候,现在我们担心的问题便会自动消失。好吧,姑且胡乱臆想一下,这不是我这篇文章要描述的。

下面来说说我做的这个实验的具体内容。


实验软硬件环境


编码端:

i7 7700 3.6G,128G SSD,8G,NVIDIA GeForce GTX 1060,Windows 10家庭版,一块国产的4K采集卡(插在PCI插槽上)。视频输入源使用了2种:一种是通过HDMI线直接连接了一台MacbookPro到4K采集卡上,MacbookPro的屏幕作为视频输入,另外一种就是使用一台4K摄像机作为视频输入。视频编码:VP8。


解码/渲染端:

Windows笔记本电脑。实验中使用的是购于2018年初的小米笔记本15.6寸顶配机型。


服务器/网络:

Licode服务器



公司WiFi,上下行对称,正常办公时间,使用speedtest.net测速如下:


实验结果

调整了前端和服务器的参数配置,主要是要放开带宽限制,因为实验中发现码率会持续在20Mbps上下,峰值更高,这与上面译文中提到的相符。

下方是发送端的编码、传输码率图表:

通过上方图标看出,发送端的码率在4096×2160分辨率的情况下,码率持续在20Mbps 附近。注:端和服务器之间要通过SDP协商信息来放开带宽限制,否则码率可能上不去,徘徊在4Mbps以下。实验中,x-google-max-bitrate 胡乱写了一个500000。另外googCpuOveruseDetection最好也设为false,否则码率可能会不稳定。

再来看看接收端的:

可以看到,在20Mbps的接收码率情况下,帧率在10-15fps,只能说流畅度方面勉强过得去吧,毕竟码率这么大。

最后贴几张实验时的实拍图。下方是作为4K输入的MacbookPro屏幕。可以看到屏幕上的文字在4K下已经变得非常小了。图中是在播放《我不是药神》的4K版本(分辨率3840×2072,24fps):

解码端如上面所述,是一个小米笔记本,但因为笔记本屏幕太小,不足以看出4K的效果,因此我使用HDMI线将内容投射到一个4K电视上:

将部分屏幕内容放大看细节:

可以看到,在如此巨大的显示屏下,编码端界面上的细小文字也是相当清晰的,这就是4K的魅力。

最后说明的是关于资源占用和延时,实验中的结果比我预期的要好。在上面提到的编码端机器配置下,整机的CPU占用率只有30%不到,单向延时在本次实验中大约在350~400ms的样子(测试方法可以参考这片文章:

https://blog.csdn.net/xiejiashu/article/details/77601187

)。

综上,在WebRTC中进行实时传输4K视频,超大的带宽消耗是最主要的问题,也是最大的瓶颈,其他方面其实不用太担心。这也是本文一开始翻译的那篇文章中作者的担忧,确实如此。

另外就是在测试过程中,发现一个问题,不知道是否是Chrome的bug,我使用的是Chrome 70 3538.102 64位版本,首次在页面中是可以正常显示从4K采集卡过来的视频的,但当我把Chrome浏览器关掉再打开,会发现getUserMedia来获取4K视频会提示OverconstrainedError。当我卸载Chrome重装,或者手动删除Chome的User Data目录,一切就都正常了,不知道是什么原因。这个问题是使用https://webrtc.github.io/samples/下面的例子测试的。所以如果有一天你也遇到一样的问题,不妨试试看。



版权声明:本文为epubcn原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。