人們對音視頻體驗的追求是不斷在增長的，當1080P已經逐漸成爲主流分辨率的情況下，追求更高品質的畫面，將會是音視頻工作者需要提前去研究的。
最近對4K視頻（分辨率 4096x2160 / 3840x2160）在WebRTC中的採/編/解/渲染進行了一次嘗試，總的來說還不錯。
在描述我的實驗之前，讓我們來看一篇文章。（請容忍我的英文翻譯水平，你可以直接跳過我的翻譯看原文）
以下是我對此文的翻譯：
很多人都聯繫過我詢問有關使用4K和WebRTC的問題。各種設備/服務供應商已經開始宣揚他們是如何支持4K視頻的。這消息當然是挺好的，但卻沒能讓我瘋狂起來。
WebRTC是否支持4K視頻？回答是肯定的（Chrome桌面版至少支持使用getUserMedia來獲取到4K）。但考慮一下實際中可行嗎？不。
4K視頻的分辨率爲4096x2160（或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 (640x480) 500K - 1Mbps QVGA (320x320) 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上下，峯值更高，這與上面譯文中提到的相符。
下方是發送端的編碼、傳輸碼率圖表：
通過上方圖標看出，發送端的碼率在4096x2160分辨率的情況下，碼率持續在20Mbps 附近。注：端和服務器之間要通過SDP協商信息來放開帶寬限制，否則碼率可能上不去，徘徊在4Mbps以下。實驗中，x-google-max-bitrate 胡亂寫了一個500000。另外googCpuOveruseDetection最好也設爲false，否則碼率可能會不穩定。
再來看看接收端的：
可以看到，在20Mbps的接收碼率情況下，幀率在10-15fps，只能說流暢度方面勉強過得去吧，畢竟碼率這麼大。
最後貼幾張實驗時的實拍圖。下方是作爲4K輸入的MacbookPro屏幕。可以看到屏幕上的文字在4K下已經變得非常小了。圖中是在播放《我不是藥神》的4K版本（分辨率3840x2072，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/下面的例子測試的。所以如果有一天你也遇到一樣的問題，不妨試試看。