Unreal Engine流送方案對比

本文介紹在虛幻引擎上實現像素流送的各種可能方案並給出對比報告。

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 流協議的支持提供了兩個潛在的選擇：

在 Unreal Engine Pixel Streaming 系統中實現這些非 WebRTC 流式傳輸協議，並使用這些協議直接從 Unreal Engine 流式傳輸到接收器。
使用現有 WebRTC 支持的 Pixel Streaming 系統流式傳輸到中間 WebRTC 網關服務器，該服務器通過支持的流式傳輸協議（例如 RTP 或 RTMP）有效地轉發 WebRTC 媒體流。

本報告的目的是調查每個可選項。具體來說，我們將確定這些選項的候選方法，然後根據其優勢、侷限性和一般可行性評估每種方法。我們以我們對這些非 WebRTC 接收器的像素流式傳輸的建議來結束本報告。

2. 背景

在本節中，我們將概述相關的流協議、以及與之相關的各種用戶體驗品質的技術，並回顧一些 WebRTC 網關服務器和轉發器。本概述提供了相關背景信息，爲我們對第 3 節中每種潛在解決方案的優勢、侷限性和可行性的調查提供信息。

2.1 流協議

實時數據流傳輸，例如視頻、音頻和控制輸入，是過去多次嘗試和改進的任務。作爲本報告的一部分，我們對之前的一些工作進行了分析，我們認爲這些工作與我們的目的相關的潛在流協議。下面的概述表提供了有關協議的簡要說明和關鍵細節。

<table style="box-sizing: border-box; border-collapse: collapse; background-color: rgb(255, 255, 255); margin: 0px auto; color: rgb(33, 37, 41); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: center; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><thead style="box-sizing: border-box;"><tr style="box-sizing: border-box;"><th style="box-sizing: border-box; text-align: inherit; border: 1px solid rgb(238, 238, 238); padding: 1rem;">名稱</th><th style="box-sizing: border-box; text-align: inherit; border: 1px solid rgb(238, 238, 238); padding: 1rem;">描述</th><th style="box-sizing: border-box; text-align: inherit; border: 1px solid rgb(238, 238, 238); padding: 1rem;">運輸</th><th style="box-sizing: border-box; text-align: inherit; border: 1px solid rgb(238, 238, 238); padding: 1rem;">典型用途</th><th style="box-sizing: border-box; text-align: inherit; border: 1px solid rgb(238, 238, 238); padding: 1rem;">年</th></tr></thead><tbody style="box-sizing: border-box;"><tr style="box-sizing: border-box;"><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">RTP - 實時傳輸協議</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">一種用於實時數據端到端傳輸的協議。RTP 包括序列號/時序數據，以幫助無序數據重組。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:IETF-RTP" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">4</a></td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">UDP</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">視頻/音頻</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">2003年</td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">RTCP - RTP 控制協議</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">“監控服務質量並……在正在進行的 [RTP] 會話中傳達有關參與者的信息”。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:IETF-RTCP" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">5</a> RTCP 是 RTP 的姊妹協議，用於爲 RTP 會話發送 QoS 控制消息。</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">UDP</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">QoS 控制消息</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">2003年</td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">RTSP - 實時流媒體協議</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">“RTSP 提供了一個可擴展的框架，以實現受控的按需交付實時數據，例如音頻和視頻……[RTSP] 通常不交付連續流本身……換句話說，RTSP 僅充當‘網絡遠程多媒體服務器的控制”。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:IETF-RTSP" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">6</a>通常，RTSP 控制的流將使用 RTP 作爲其底層協議。RTSP 採用客戶端-服務器架構。</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">UDP/TCP</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">創建和控制流的消息。</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">1998</td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">RTMP - 實時消息傳遞協議</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">“RTMP 通過可靠的流傳輸（例如 TCP）提供雙向消息多路複用服務，旨在在一對通信對等點之間傳輸視頻、音頻和數據消息的並行流以及相關的時間信息”。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:ADOBE-RTMP" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">7</a> RTMP 是 Adobe 在 2005 年收購 Macromedia 時獲得的。該規範於 2009 年公開發布。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:BLOG-RTMP" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">8</a>它被媒體服務器廣泛支持；但是，瀏覽器/移動設備支持一直在下降。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:WOWZA-RTMP" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">9</a>它有一些延遲，例如，5s 是典型的。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:WOWZA-RTMP" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">9</a></td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">TCP</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">視頻/音頻</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">2009</td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">SRT - 安全可靠的運輸</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">“SRT 是一種視頻流傳輸協議和技術棧（在概念上類似於可靠的 UDP）。SRT 連接兩個端點，以便通過有損網絡傳輸低延遲視頻和其他媒體流”。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:SRT-ALLIANCE-SRT" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">10</a>除了處理有損網絡，在協議級別 SRT 還支持端到端加密。SRT 主要在直播行業中得到採用，因此在該行業之外的協議支持可能會受到關注；但是，它是開源的。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:GITHUB-SRT" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">11</a></td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">UDP</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">視頻/音頻</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">2013</td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">RIST - 可靠的互聯網流傳輸</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">RIST 與 SRT 類似，因爲它是一個開源<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:GITLAB-RIST" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">12</a>協議，旨在解決有損網絡（如互聯網）中可靠、低延遲的媒體傳輸。然而，與 SRT 不同的是，RIST 建立在 RTP 和 RTSP 之上，以最大限度地提高互操作性，因爲已經有大量資源支持 RTP 和 RTSP。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:VSF-PAPER" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">13</a></td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">UDP</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">視頻/音頻</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgba(246, 248, 250, 0.5);">2018</td></tr><tr style="box-sizing: border-box;"><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">WebRTC - Web 的實時通信</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">WebRTC 是許多現有技術的組合，旨在通過公共互聯網實現低延遲（特別是亞秒級）通信。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:TEXTBOOK-WEBRTC" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">14</a>它對惡劣的網絡條件具有彈性，並且可以優雅地適應數據包丟失。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:TEXTBOOK-WEBRTC" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">14</a>與本報告中討論的所有其他協議不同，WebRTC 本身是實時通信的整體解決方案，可處理：對等網絡、會話管理、數據流以及適應網絡條件的變化。此外，它在所有主要的 Web 瀏覽器中得到廣泛支持。<a href="https://tensorworks.com.au/blog/investigation-custom-unreal-engine-streaming-solutions/#fn:TEXTBOOK-WEBRTC" class="footnote" style="box-sizing: border-box; color: rgb(0, 123, 255); text-decoration: none; background-color: transparent;">14</a></td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">TCP/UDP</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">視頻/音頻/數據</td><td style="box-sizing: border-box; border: 1px solid rgb(238, 238, 238); padding: 1rem; background-color: rgb(255, 255, 255);">2011</td></tr></tbody></table>

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 有兩個主要缺點：

ARQ 需要發送方和接收方之間的雙向通信。19
ARQ 引入了等待重傳發生的額外延遲。19

然而，與 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、虛幻引擎中各種流媒體解決方案的可行性

在本節中，我們評估各種流解決方案在虛幻引擎中的實施的可行性、它們的一般優勢和侷限性，然後我們簡要介紹我們對每種解決方案在不可靠網絡中的表現的猜想。

具體來說，我們將通過討論以下每個標準來探索每個協議的可行性：

如何實施。我們簡要描述了使用虛幻引擎的像素流系統實現潛在解決方案的過程。是否有任何與虛幻引擎兼容的 API 可以作爲合適的參考實現加以利用或研究？
優點。與其他選項相比，實施此解決方案有哪些優勢？
限制。實施此解決方案有哪些限制？
不可靠的網絡用例。我們如何期望該解決方案在具有丟包、抖動和不斷變化的網絡條件（例如公共互聯網）的真實網絡中運行？

虛幻引擎中的 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

Unreal Engine流送方案對比

1、簡介

2. 背景

2.1 流協議

2.2 體驗質量技術

2.3 WebRTC轉發技術

3、虛幻引擎中各種流媒體解決方案的可行性

4、總結與建議

【面試準備】又一次失敗的面試經歷，題目離譜～資深軟件測試工程師

dotnet 8 版本與銀河麒麟V10和UOS系統的 glibc 兼容性

南京大學×百度“星河杯”AI 大模型創意校園賽正式起航

實用分享！用Axure RP構建交互的5個小技巧

大模型微調提升AI應用性能

LoRA微調語言大模型的實用技巧

系統整容紀：責任鏈設計模式的應用實戰（爆燈了，研發工期由45天降爲1天）

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結