UE4流送方案对比
本文介紹在虛幻引擎上實現像素流送的各種可能方案并給出對比報告。
1、簡介
自 2018 年底以來1，虛幻引擎包含了一個稱為像素流送（Pixel Streaming）的系統，通過該系統，來自遠程虛幻引擎實例的音頻和視覺圖像被流式傳輸到 WebRTC 對端（通常是網絡瀏覽器），而鍵盤、鼠標和觸屏輸入則可以從 WebRTC 對端傳回，以促進與此 Pixel Streaming Unreal Engine 實例的交互。2
Unreal Engine 的 Pixel Streaming 系統是建立在 WebRTC 之上的，現代 Web 瀏覽器很好地支持它。3 WebRTC 專門設計為通過公共互聯網進行雙向、低延遲實時通信的整體解決方案。然而，有許多流媒體場景要么是單向的、非實時的，要么在不受數據包丟失或公共互聯網變化的網絡條件影響的受控網絡環境中運行。此類流式傳輸場景的示例包括：直播、模擬軟件、遺留硬件，或在完全受控的專用網絡中運行的簡單流式傳輸場景。這些場景不一定需要也不支持 WebRTC 的技術組合。
如果上述這些場景無法支持 WebRTC 連接，則意味著無法直接使用 Unreal Engine Pixel Streaming 系統。這是不幸的，因為我們認為在這些用例中虛幻引擎的音頻、視覺和輸入的流式傳輸是非常可取的。幸運的是，許多這些流式傳輸用例，尤其是黑盒硬件和仿真軟件，已經支持使用現有的流式傳輸協議（例如 RTP 或 RTMP）接收流式傳輸數據。在這些用例中對非 WebRTC 流協議的支持提供了兩個潛在的選擇：
本報告的目的是調查每個可選項。具體來說，我們將確定這些選項的候選方法，然后根據其優勢、局限性和一般可行性評估每種方法。我們以我們對這些非 WebRTC 接收器的像素流式傳輸的建議來結束本報告。
2. 背景
在本節中，我們將概述相關的流協議、以及與之相關的各種用戶體驗品質的技術，并回顧一些 WebRTC 網關服務器和轉發器。本概述提供了相關背景信息，為我們對第 3 節中每種潛在解決方案的優勢、局限性和可行性的調查提供信息。
2.1 流協議
實時數據流傳輸，例如視頻、音頻和控制輸入，是過去多次嘗試和改進的任務。作為本報告的一部分，我們對之前的一些工作進行了分析，我們認為這些工作與我們的目的相關的潛在流協議。下面的概述表提供了有關協議的簡要說明和關鍵細節。
| RTP?- 實時傳輸協議 | 一種用于實時數據端到端傳輸的協議。RTP 包括序列號/時序數據，以幫助無序數據重組。4 | UDP | 視頻/音頻 | 2003年 |
| RTCP?- RTP 控制協議 | “監控服務質量并……在正在進行的 [RTP] 會話中傳達有關參與者的信息”。5?RTCP 是 RTP 的姊妹協議，用于為 RTP 會話發送 QoS 控制消息。 | UDP | QoS 控制消息 | 2003年 |
| RTSP?- 實時流媒體協議 | “RTSP 提供了一個可擴展的框架，以實現受控的按需交付實時數據，例如音頻和視頻……[RTSP] 通常不交付連續流本身……換句話說，RTSP 僅充當‘網絡遠程多媒體服務器的控制”。6通常，RTSP 控制的流將使用 RTP 作為其底層協議。RTSP 采用客戶端-服務器架構。 | UDP/TCP | 創建和控制流的消息。 | 1998 |
| RTMP?- 實時消息傳遞協議 | “RTMP 通過可靠的流傳輸（例如 TCP）提供雙向消息多路復用服務，旨在在一對通信對等點之間傳輸視頻、音頻和數據消息的并行流以及相關的時間信息”。7?RTMP 是 Adob??e 在 2005 年收購 Macromedia 時獲得的。該規范于 2009 年公開發布。8它被媒體服務器廣泛支持；但是，瀏覽器/移動設備支持一直在下降。9它有一些延遲，例如，5s 是典型的。9 | TCP | 視頻/音頻 | 2009 |
| SRT?- 安全可靠的運輸 | “SRT 是一種視頻流傳輸協議和技術棧（在概念上類似于可靠的 UDP）。SRT 連接兩個端點，以便通過有損網絡傳輸低延遲視頻和其他媒體流”。10除了處理有損網絡，在協議級別 SRT 還支持端到端加密。SRT 主要在直播行業中得到采用，因此在該行業之外的協議支持可能會受到關注；但是，它是開源的。11 | UDP | 視頻/音頻 | 2013 |
| RIST?- 可靠的互聯網流傳輸 | RIST 與 SRT 類似，因為它是一個開源12協議，旨在解決有損網絡（如互聯網）中可靠、低延遲的媒體傳輸。然而，與 SRT 不同的是，RIST 建立在 RTP 和 RTSP 之上，以最大限度地提高互操作性，因為已經有大量資源支持 RTP 和 RTSP。13 | UDP | 視頻/音頻 | 2018 |
| WebRTC?- Web 的實時通信 | WebRTC 是許多現有技術的組合，旨在通過公共互聯網實現低延遲（特別是亞秒級）通信。14它對惡劣的網絡條件具有彈性，并且可以優雅地適應數據包丟失。14與本報告中討論的所有其他協議不同，WebRTC 本身是實時通信的整體解決方案，可處理：對等網絡、會話管理、數據流以及適應網絡條件的變化。此外，它在所有主要的 Web 瀏覽器中得到廣泛支持。14 | TCP/UDP | 視頻/音頻/數據 | 2011 |
2.2 體驗質量技術
我們認為 RTP 可能是表 1 中列出的任何協議中實現最簡單的協議。但是，與 SRT、RIST、RTMP 和 WebRTC 不同，RTP 協議沒有內置機制來處理數據包丟失或網絡抖動——這些挑戰被推遲了給應用程序開發者。因此，如果要在虛幻引擎內部實施純 RTP 流解決方案，討論如何解決這些挑戰似乎是明智的。
對于開發人員來說幸運的是，存在許多眾所周知的有效技術來解決流數據的丟包和網絡抖動問題。我們將這種方法稱為“體驗質量”（QoE）技術。一些已知的 QoE 技術包括前向糾錯 (FEC)、自動重復請求 (ARQ)、抖動緩沖和數據包丟失隱藏。我們在下面簡要介紹和解釋這些 QoE 技術。此外，我們強調所有適當的 WebRTC 實現都將隱含地包括 FEC 和抖動緩沖 QoE 技術。15此外，Google 的 WebRTC（虛幻引擎的像素流系統使用的實現）還包括許多自定義丟包隱藏技術。16
前向糾錯 (FEC)
前向糾錯 (FEC) 是將冗余信息與流數據一起傳輸的過程，以便當數據包丟失時，此冗余信息可用作糾錯碼以恢復丟失的信息。17在實踐中，這需要保留接收數據包的緩沖區，以便在檢測到丟失數據包時，可以使用未來數據包來重建丟失的信息，而無需重新傳輸舊數據。18權衡是這些冗余糾錯碼增加了總傳輸大小。但是，應該注意的是，添加的冗余越多，FEC 在實踐中的效果就越好。18可接受的冗余量很大程度上取決于底層網絡的帶寬能力。作為人們可以預期的那種丟失恢復的指標，一項真實世界的研究18表明，在 50% 的帶寬開銷下，基于 RTP 的 FEC 實施可以在丟包率約為 5-10% 的情況下恢復流數據。
自動重復請求 (ARQ)
自動重復請求 (ARQ) 是一種技術，其中接收方請求發送方在數據包丟失時重新傳輸數據包。19 ARQ 需要在接收端引入一個緩沖區來確定數據包是真的丟失還是只是亂序。19與 FEC 相比，ARQ 有兩個主要缺點：
然而，與 FEC 不同，ARQ 不需要大量的額外傳輸帶寬。此外，ARQ 能夠從大量、連續的丟失數據包中恢復，這是 FEC 難以應對的情況。20我們強調，SRT 的創建者 Haivision 在其流式傳輸協議中使用 ARQ，因為“與其他糾錯方法相比，它需要的帶寬更少……并且僅在傳輸中引入了很小程度的延遲”。21
抖動緩沖
抖動緩沖只是在接收端維護一個緩沖區以存儲傳入數據包的過程。22用于在數據包亂序到達時對數據包進行重新排序，并提供接收端的恒定播放流。22抖動緩沖的缺點是延遲會直接增加緩沖區的大小。雖然固定大小的緩沖區更易于實現，但也可以（并且希望）根據最近的網絡狀況動態調整抖動緩沖區的大小。動態抖動緩沖區可以使用來自 RTCP 等協議的流統計信息來決定何時調整緩沖區大小。我們強調 FEC 和 ARQ 都包含抖動緩沖作為其實際實現的一部分。
丟包隱藏
數據包丟失隱藏實際上是一系列技術，其目的是決定在存在丟失數據包的情況下如何進行。與 FEC、ARQ 和抖動緩沖（它們是任何流數據的通用 QoE 技術）不同，數據包隱藏技術通常旨在通過利用音頻和視頻數據的屬性來專門處理丟失的音頻或視頻數據包。例如，在一些音頻流中，當數據包丟失時，使用了一種稱為波形替換的技術，其中一些已經接收到的音頻數據包被仔細地重復使用并拼接到接收到的音頻中，以擴展當前的語音聲音，直到接收到新的數據。23另一個例子是 Google Duo，它使用 WaveNetEQ 生成模型來插入由于數據包丟失而丟失的部分語音。24
2.3 WebRTC轉發技術
正如我們在第 1 節中提到的，除了在虛幻引擎內部實現替代流傳輸協議之外，另一個選項是使用虛幻引擎現有的基于 WebRTC 的像素流傳輸到 WebRTC 網關/轉發服務器。然后，該網關/轉發服務器將 WebRTC 流轉換為接收端可以理解的協議，例如 RTP，最后，網關/轉發服務器將流傳輸到接收端。幸運的是，由于 WebRTC 的廣泛采用，現有的網關/轉發服務器可能適合此目的。我們在下面介紹了一些相關選項。
Janus
Janus 是一個用 C 語言編寫的通用 WebRTC 服務器。它的設計使得基本的 Janus 應用程序占用空間小，并且大多數額外的功能是通過插件實現的。25為了通過其他協議轉發 WebRTC 媒體，Janus 提供了一個“NoSIP”插件，充當“RTP 橋”，將媒體從 WebRTC 對等體中繼到使用 RTP/RTCP 的接收器。26還有 Janus 插件“Videoroom” 27和“Janus-RTP-Forward-Plugin” 28由社區編寫，這似乎也是可行的選擇。我們強調 Janus 是開源的，并在 GPL 3.0 下獲得許可。雖然 GPL 3.0 不兼容鏈接到虛幻引擎，但這可能不是問題，因為 Janus WebRTC 轉發服務器將完全位于虛幻引擎之外。
Pion
Pion 是用 Go 編寫的 WebRTC 實現，與 Google 的 WebRTC 不同，Pion 專門設計用于快速構建和定制。29雖然 Pion 并不是專門的 WebRTC 網關或服務器，但它確實包含一個“RTP-Forwarder”示例，說明如何將其用作將 RTP 數據包轉發到其他地方的 WebRTC 對等體。30在實現方面，我們認識到 Go 不是可以從 Unreal Engine C++ 輕松調用的；但是，這應該不是問題，因為 Pion 將部署在 Unreal Engine 之外，并作為標準 WebRTC 對等體與 Pixel Streaming 進行通信。
其他選項
我們還研究了 GStreamer WebRTC 31和 Kurento WebRTC server 32，兩者似乎都很合適，但在 WebRTC 到非 WebRTC 流轉發方面的文檔記錄不如 Janus 或 Pion 少。此外，使用 Google 的 WebRTC 實現 WebRTC 轉發服務器似乎也是可能的；但是，我們不建議采取這種做法，因為根據我們的經驗，Google 的 WebRTC 很復雜，構建起來很耗時，而且更新也很重要。
3、虛幻引擎中各種流媒體解決方案的可行性
在本節中，我們評估各種流解決方案在虛幻引擎中的實施的可行性、它們的一般優勢和局限性，然后我們簡要介紹我們對每種解決方案在不可靠網絡中的表現的猜想。
具體來說，我們將通過討論以下每個標準來探索每個協議的可行性：
虛幻引擎中的 UDP
UDP 流式傳輸可能是在虛幻引擎內部實現的最簡單的選項；然而，它有幾個限制，我們認為，這使它成為一個站不住腳的選擇。使用 UDP 在虛幻引擎中實現視頻和音頻流不需要實現任何特定的協議或庫，因為虛幻引擎已經支持 UDP 數據包的傳輸。33此外，使用 UDP 傳輸數據將缺乏其他傳輸協議所需的數據包開銷。但是，純UDP，是非常有限的；它不支持丟包、亂序交付或抖動。例如，即使在私有的、可靠的網絡中，UDP 也可能會丟棄數據包或出現一些亂序傳送。34例如，當我們考慮 H.264 編碼視頻在不可靠網絡中的 UDP 傳輸時，丟包很可能導致視頻流變得不可恢復。35我們認為，這些限制使純 UDP 成為站不住腳的選擇。然而，還有一些額外的技術可以在 UDP 流解決方案之上實現，例如 FEC 和抖動緩沖，這將在一定程度上緩解這些限制。但是，我們認為，如果使用緩解技術來克服 UDP 的內在屬性，那么其他協議（例如 RTP）已經存在，并且由于它們的廣泛采用，應該是首選。
虛幻引擎中的 RTP
RTP 是一種輕量級協議，可以使用內置的 UDP 傳輸 API 在虛幻引擎中實現。如果需要參考實現，我們建議學習 uvgRTP 36 37和Live555 38. 與純 UDP 相比，RTP 的主要特點是 RTP 在其數據包中傳輸序列信息，以在發生亂序交付時幫助重建。但是，RTP 本身沒有內置的 QoE 技術來實際解決亂序交付，這意味著如果需要諸如抖動緩沖或 FEC 之類的 QoE 技術，則必須由開發人員實施這些 QoE 技術。在沒有實施額外 QoE 技術的可靠網絡中，我們預計 RTP 的有效性與 UDP 大致相似。然而，隨著 QoE 技術的實施，我們希望 RTP 在可靠的網絡中有效運行。此外，在可靠的網絡中，抖動緩沖區可以保持相對較小，從而最大限度地減少延遲。但是，在不可靠的網絡中，RTP 需要 QoE 技術來提供功能性的實時流媒體體驗。然而，我們強調，當在不可靠的網絡中運行時，通常與 RTP、FEC 和抖動緩沖區配對的 QoE 技術將分別引入帶寬和延遲的權衡。
虛幻引擎中的 RTP + RTCP
RTCP 旨在監控實時流并計算統計數據，然后用于動態修改 QoE 技術或動態調整源流。如果要在虛幻引擎中實現 RTCP，我們建議研究 Live555 中現有的 RTCP 庫。38 39我們強調，要充分利用 RTCP，它也必須在接收端實現，這在某些黑盒系統中可能是不可能的。然而，假設 RTCP 在兩端都實現并且 RTP 使用抖動緩沖，我們預計 RTCP 將通過允許抖動緩沖區根據網絡條件動態調整大小來極大地提高不可靠網絡的體驗質量。與必須假定固定大小的純 RTP 抖動緩沖區相比，我們希望 RTP + RTCP 解決方案隨著網絡條件的恢復而減少延遲。此外，即使不使用抖動緩沖，我們仍然希望 RTP + RTCP 在不可靠網絡中產生比純 RTP 更好的體驗，因為可以使用來自 RTCP 的信息動態調整流的源質量。
虛幻引擎中的 RTSP
RTSP 是一種用于控制流媒體服務器的協議。6在實踐中，它通常是一種瘦協議，將 RTP 和 RTCP 用于底層媒體流和控制消息。因此，我們認為在虛幻引擎中實現 RTSP 的實際優缺點與 RTP + RTCP 解決方案大致相同。因此，我們向讀者推薦我們上面關于 RTP + RTCP 的評論。此外，在尋求 RTSP 的參考實現時，我們建議研究 Live555 38。
虛幻引擎中的 RTMP
RTMP 是廣泛支持的基于 TCP 的協議，由 Macromedia/Adobe 7開發。就在虛幻引擎中實現 RTMP 而言，來自虛幻引擎的像素流系統的音頻和視頻流必須使用虛幻引擎的 TCP API 33以 RTMP 數據包格式進行分塊和傳輸。我們建議研究 iReader 的媒體服務器以了解現有的 RTMP 實施。40 RTMP 的主要缺點是它使用 TCP 作為其底層傳輸，在不可靠的網絡中，當重新傳遞嘗試發生時，它會導致延遲膨脹。41
虛幻引擎中的 SRT
SRT 是由 Haivision 創建的基于 UDP 的低延遲流協議。10 SRT 是開源的，Haivision 為開發人員提供了一個生產就緒的 SRT 庫。11要在虛幻引擎的像素流送系統中實現 SRT，我們建議將 Haivision 的 SRT 庫合并到它自己的插件中，或者修改現有的像素流送插件以包含 SRT 庫。SRT 的優勢在于它專為跨不可靠網絡的低延遲流式傳輸而設計，與其他基于 UDP 的協議（例如 RTP）不同，SRT 本身包含一種通過 ARQ 處理數據包丟失的機制。我們預見到使用 SRT 的解決方案的主要缺點是 SRT 相對較新，接收端的許多設備不太可能支持。
虛幻引擎中的 RIST
RIST 與 SRT 非常相似，它也是一個基于 UDP 的低延遲流協議。13與由私營公司創建的 SRT 不同，RIST 由視頻服務集團創建，這是一個非營利組織，“由致力于媒體網絡技術的互操作性、質量指標和教育的服務提供商、用戶和制造商組成”。42要實施 RIST，我們建議將官方 RIST 庫librist 12合并到其自己的插件中，或將其包含在現有的 Pixel Streaming 插件中。與 SRT 非常相似，實施使用 RIST 的解決方案的主要缺點是它相對較新，不太可能被接收端的許多設備支持。
虛幻引擎 → WebRTC 橋 → 非 WebRTC 接收器
此解決方案涉及利用虛幻引擎中現有的像素流式傳輸系統流式傳輸到自定義 WebRTC 橋接器，然后使用廣泛支持的流式傳輸協議（例如 RTP、RTSP）將從虛幻引擎接收到的視頻和音頻轉發到某個任意非 WebRTC 接收器, 或 RTMP。現有的 WebRTC 流媒體服務器包括 Janus 25和 Wowza 流引擎43；但是，如果除了簡單地轉發流之外還有特定要求，基于 Go 的 WebRTC 庫 Pion 29也是一種選擇。
該解決方案的優勢在于它不需要對虛幻引擎或像素流式處理插件進行修改，并將流式傳輸的需求轉移到虛幻引擎之外的其他協議。此外，WebRTC 橋接器的部署，尤其是在其自己的硬件上，比直接從虛幻引擎流式傳輸更具可擴展性，同時還消除了與虛幻引擎像素流式傳輸應用程序進行資源競爭的可能性。此外，由于 WebRTC 是底層流技術，如果配置正確，這種方法繼承了 WebRTC 的所有低延遲、高彈性和屬性。
相反，此解決方案的缺點是它需要另一個組件，可能在其自己的硬件上運行。此外，當流通過 WebRTC 橋轉發時，這種方法可能會引入一些延遲。此外，如果 WebRTC 橋接器與接收器不在同一個本地網絡中，則此方法將繼承與選擇從 WebRTC 橋接器流式傳輸到非 WebRTC 接收器的任何協議相同的質量。
4、總結與建議
根據第 3 節，有一些解決方案可以忽略我們的建議，因為它們不能滿足我們確保與舊版和/或黑盒流客戶端兼容的目標。具體來說，應該忽略 SRT 和 RIST，因為它們可能與大多數傳統流接收器不兼容。此外，還不清楚 RTSP 是否比在 Unreal Engine Pixel Streaming 場景中簡單地實現 RTP 和 RTCP 有任何好處；因此，它也可以忽略不計。最后，純 UDP 流解決方案可能會出現丟包問題，即使在專用網絡中也是如此，因此我們也將忽略它。
因此，我們認為 RTP、RTP + RTCP、RTMP 或 WebRTC 轉發橋是支持從虛幻引擎的像素流系統到非 WebRTC 接收器的流式傳輸的最可行的解決方案。然而，在這四個選項中，WebRTC 轉發橋是我們推薦的解決方案。
我們認為，與 WebRTC 轉發橋相比，RTP、RTP + RTCP 和 RTMP 解決方案都有一個主要缺點。也就是說，如果需要在較差或變化的網絡條件下保持穩定性，那么這些協議本身并不能提供解決方案。RTP和RTP+RTCP可以通過FEC、丟包隱藏、抖動緩沖來解決這些問題；但是，這在某種程度上必須在兩端實現，這是一項不平凡的任務，如果接收端是黑盒或不可修改的遺留系統，這可能是一項不可行的任務。然而，WebRTC 轉發橋獲得了 WebRTC 固有的所有低延遲和較差的網絡彈性。我們強調，為了最大限度地利用 WebRTC 的這些優勢，我們建議在與非 WebRTC 接收器相同的本地網絡中安裝 WebRTC 轉發橋。如果 WebRTC 轉發橋與非 WebRTC 接收器不在同一個網絡中，那么該解決方案將面臨與底層轉發協議（例如 RTP、RTMP）相同的缺點。
此外，即使在不關心網絡條件差或變化的穩定性的情況下，我們仍然建議使用 WebRTC 轉發橋。WebRTC 轉發橋是唯一不需要對虛幻引擎進行任何修改的解決方案。這緩解了幾個問題，包括：隨著虛幻引擎源代碼發生變化而更新解決方案的維護成本、與虛幻引擎的許可沖突以及在虛幻引擎中集成第三方庫的復雜性。此外，它是唯一完全在虛幻引擎之外運行的解決方案，因此更具可擴展性。
為了證明該解決方案的可行性，我們提供了一個概念驗證，使用 Pion WebRTC 將 RTP 流從虛幻引擎的像素流系統轉發到非 WebRTC 接收器（在本例中為 FFplay）。此概念證明可在這個網址找到。
原文鏈接：虛幻引擎流送方案調查報告 — BimAnt
總結
- 上一篇： 《疯狂的简洁》书摘
- 下一篇： File,FileInfo,Direct