人们对音视频体验的追求是不断在增长的，当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/下面的例子测试的。所以如果有一天你也遇到一样的问题，不妨试试看。