查看引用/信息源請點(diǎn)擊：中國AI網(wǎng)

團(tuán)隊(duì)對 MoQ、RoQ 和 WebRTC 協(xié)議進(jìn)行了全面分析，重點(diǎn)研究了它們在集成到用于 Wi-Fi 和 5G 網(wǎng)絡(luò)環(huán)境中專用 XR 應(yīng)用的遠(yuǎn)程渲染服務(wù)時(shí)的延遲性能

（中國AI網(wǎng) 2025年09月23日）XR應(yīng)用的激增推動(dòng)了對高效遠(yuǎn)程渲染解決方案的需求。在一項(xiàng)研究中，西班牙巴斯克研究與技術(shù)聯(lián)盟和巴斯克大學(xué)團(tuán)隊(duì)重點(diǎn)探索了虛擬環(huán)境中的全息會(huì)議及其所需的上行和下行媒體傳輸能力。

通過研究基于 QUIC 的媒體傳輸、基于 QUIC 的實(shí)時(shí)傳輸協(xié)議以及 WebRTC，研究人員評估了它們在 Wi-Fi 和 5G 網(wǎng)絡(luò)上的延遲性能。與 WebRTC 相比，基于 QUIC 的協(xié)議預(yù)計(jì)在延遲方面有約 30% 的改進(jìn)，在連接啟動(dòng)方面有約 60% 的改進(jìn)。實(shí)驗(yàn)設(shè)置使用實(shí)時(shí)視頻流協(xié)議傳輸遠(yuǎn)程渲染的虛擬體驗(yàn)，將內(nèi)容提供給參與者。

研究結(jié)果有助于理解流傳輸協(xié)議的成熟度，特別是在開源框架內(nèi)，并評估它們在支持對延遲敏感的 XR 應(yīng)用方面的適用性。研究強(qiáng)調(diào)了不同遠(yuǎn)程渲染場景下特定協(xié)議的優(yōu)勢，為未來 XR 通信解決方案的設(shè)計(jì)提供了參考。

對遠(yuǎn)程渲染系統(tǒng)的需求正在增長。用于游戲和虛擬化環(huán)境的現(xiàn)代XR應(yīng)用變得要求極高。然而，硬件需求同樣顯著增加。為輔助、教育和娛樂開發(fā)環(huán)境現(xiàn)在需要詳細(xì)的場景并為任何地方的用戶提供遠(yuǎn)程可訪問性。這需要高硬件能力和低延遲流傳輸。因此，遠(yuǎn)程渲染系統(tǒng)至關(guān)重要，它使用戶能夠訪問本地可能無法獲得的高性能硬件。

諸如 WebRTC之類的協(xié)議目前用于 XR 中以實(shí)現(xiàn)低延遲、實(shí)時(shí)通信 。然而，隨著新的HTTP/3的出現(xiàn)，UDP QUIC協(xié)議正在作為一種替代方案。基于 UDP，QUIC 簡化了連接協(xié)商和數(shù)據(jù)傳輸，同時(shí)引入了新穎的功能，如跨網(wǎng)絡(luò)連接遷移、集成的端到端加密、流多路復(fù)用和多路徑傳輸。它同時(shí)具有更高效的擁塞管理特性，使其成為現(xiàn)代互聯(lián)網(wǎng)應(yīng)用的一個(gè)強(qiáng)大選擇。

QUIC 相較于 TCP（和 UDP 等傳統(tǒng)協(xié)議取得了顯著進(jìn)步，使其成為提升 XR 應(yīng)用性能和靈活性的有前景的解決方案。其設(shè)計(jì)目標(biāo)是在容量和影響力方面都超越 WebRTC。XR 應(yīng)用尤其具有挑戰(zhàn)性，因?yàn)樗鼈冊谘舆t、吞吐量使用和對字節(jié)丟失的容忍度方面有嚴(yán)格的性能要求。因此，研究最合適的協(xié)議和通信棧既是必要的，同時(shí)具有高度相關(guān)性。為了測試每種分析選項(xiàng)的影響，團(tuán)隊(duì)在實(shí)驗(yàn)性和私有的 5G 獨(dú)立組網(wǎng)（SA）網(wǎng)絡(luò)的邊緣基礎(chǔ)設(shè)施部署了一個(gè)渲染服務(wù)實(shí)現(xiàn)。所述服務(wù)使用所研究的通信技術(shù)，提供一個(gè)包含用戶作為被動(dòng)元素的個(gè)性化場景的視頻流。

在一個(gè)有兩個(gè)或更多參與者的全息會(huì)議系統(tǒng)中，實(shí)時(shí)通信至關(guān)重要。一個(gè)潛在用例是現(xiàn)場活動(dòng)，如音樂會(huì)或表演，參與者作為觀眾或被動(dòng)客戶端。系統(tǒng)包括一個(gè)部署在分布式容器化環(huán)境中的遠(yuǎn)程渲染器和一個(gè)播放器。在此場景中，沉浸式 XR 體驗(yàn)要求盡可能低的通信延遲。圖 1 說明了針對每種分析的協(xié)議，遠(yuǎn)程渲染器與播放器之間提議的通信方式。遠(yuǎn)程渲染器由兩個(gè)主要軟件組件組成：用 C# 開發(fā)的 Unity 應(yīng)用程序，以及使用 Gstreamer 庫開發(fā)并用 C++ 編寫并動(dòng)態(tài)鏈接到主應(yīng)用程序的本機(jī)渲染插件。

主 Unity 應(yīng)用程序作為骨干，協(xié)調(diào)不同組件之間的交互。它基于 Unity 渲染引擎，并利用 NVIDIA GPU 的能力來處理嵌入在 VR 場景中的異構(gòu)內(nèi)容（包括音頻和體積視頻），并生成渲染后的原始音頻和 360度 視頻流。本機(jī)渲染插件是一個(gè)自定義的 Unity 插件，充當(dāng)主 Unity 應(yīng)用程序與負(fù)責(zé)創(chuàng)建特定于協(xié)議的多媒體管線的多媒體框架之間的橋梁。在開發(fā)中，團(tuán)隊(duì)實(shí)現(xiàn)了 GStreamer 框架，而所述框架通過其庫為多種協(xié)議提供編碼和通信功能。

通過調(diào)用 GStreamer 的本機(jī)應(yīng)用程序接口來構(gòu)建和管理媒體處理管道以集成 GStreamer。GStreamer element appsrc 能夠?qū)秩竞蟮囊曨l緩沖區(qū)注入 GStreamer 管道，隨后使用 NVIDIA 硬件編碼器進(jìn)行編碼。視頻始終使用 H.264 編解碼器進(jìn)行編碼。管道內(nèi)的最終操作因協(xié)議而異。在這項(xiàng)研究中，團(tuán)隊(duì)探索了當(dāng)前支持的協(xié)議及其相應(yīng)的操作。

基于 RTP 的 WebRTC 首先通過信令服務(wù)器進(jìn)行點(diǎn)對點(diǎn)通信的初始協(xié)商。信令服務(wù)器使用 RUST 開發(fā)，是 Gstreamer 中 WebRTC 元素的官方實(shí)現(xiàn)。一旦建立，它會(huì)創(chuàng)建一個(gè)通信通道，將編碼后的流封裝在 WebRTC 流中。播放器使用 RUST 開發(fā)，負(fù)責(zé)接收封裝的 RTP 流并解碼數(shù)據(jù)。使用 NVIDIA 硬件解碼進(jìn)行解碼。

在 RoQ 中，通信協(xié)商以點(diǎn)對點(diǎn)模式建立，之后編碼后的視頻被封裝到經(jīng)過 QUIC 協(xié)議適配的 RTP 流中。GStreamer 官方支持此開發(fā)；然而，它仍處于早期階段，缺乏完全穩(wěn)定性。與 WebRTC 類似，播放器使用 RUST 開發(fā)，負(fù)責(zé)接收流、解封裝 RTP 數(shù)據(jù)包并使用 NVIDIA 硬件解碼來解碼數(shù)據(jù)。

對于 MoQ，使用fMP4復(fù)用器來封裝編碼后的流。然后，一個(gè)非官方的 GStreamer element實(shí)現(xiàn) MoQ 來傳輸 fMP4 流。在這種情況下，采用基于中繼的通信模型，服務(wù)器推送數(shù)據(jù)，客戶端請求數(shù)據(jù)。中繼服務(wù)器使用 RUST 開發(fā)。由于相關(guān)element未包含在官方維護(hù)的版本中，它們不如其他替代方案成熟，并且目前不支持音頻。與遠(yuǎn)程渲染器類似，播放器使用非官方的 GStreamer 元素來接收 fMP4 流，然后使用 GStreamer element和 NVIDIA 硬件解碼進(jìn)行解碼。

測試臺(tái)的配置包括用于遠(yuǎn)程渲染器和播放器之間通信的 5G 和 Wi-Fi。服務(wù)器包括遠(yuǎn)程渲染器、WebRTC 信令服務(wù)器和 MoQ 中繼服務(wù)器。部署在 Kubernetes集群中進(jìn)行，每個(gè)服務(wù)被分配到單獨(dú)的 Pod 中。Kubernetes 部署使用 Helm chart 完成。Kubernetes 集群托管在一臺(tái)配備 8 個(gè)中央處理單元核心、32 GB RAM和具有 8 GB 專用內(nèi)存的 NVIDIA L4 虛擬圖形處理單元的虛擬機(jī)上。

實(shí)驗(yàn)室網(wǎng)絡(luò)是一個(gè)內(nèi)部網(wǎng)絡(luò)，部署了 OpenStack 服務(wù)器，專為測試和互聯(lián)網(wǎng)訪問而設(shè)計(jì)。使用一個(gè)在 5 GHz 頻段上運(yùn)行的 Wi-Fi 6 兼容路由器，以促進(jìn)遠(yuǎn)程渲染服務(wù)器和視頻播放設(shè)備之間的通信。或者，它可以將流量重定向到 5G 網(wǎng)絡(luò)而不是 Wi-Fi。Wi-Fi 配置為接入點(diǎn)。

對于 5G 網(wǎng)絡(luò)，使用了 AMARI Callbox Mini。它配置為使用 N78 頻段、20 MHz 帶寬、30 MHz 子載波間隔、最大調(diào)制為 256 正交幅度調(diào)制、下行鏈路 2 天線和上行鏈路 1 天線。作為 5G 調(diào)制解調(diào)器，使用 Quectel RM500Q，它實(shí)現(xiàn)了 3GPP 第 15 版，并通過 USB 連接到視頻播放器。

為了同步，路由器授予互聯(lián)網(wǎng)訪問權(quán)限，允許遠(yuǎn)程渲染服務(wù)器和視頻播放設(shè)備都充當(dāng) NTP 客戶端并與公共網(wǎng)絡(luò)時(shí)間協(xié)議服務(wù)器同步，確保準(zhǔn)確的延遲測量。在測試期間，使用 tshark 工具捕獲和分析網(wǎng)絡(luò)流量，服務(wù)器作為發(fā)送方，播放器作為接收方。雙方產(chǎn)生的流量存儲(chǔ)在數(shù)據(jù)包捕獲文件中，用于后續(xù)的比較和分析。

為了比較 WebRTC、MoQ 和 RoQ 協(xié)議，設(shè)計(jì)了兩項(xiàng)測試，涉及網(wǎng)絡(luò)數(shù)據(jù)包捕獲和圖像捕獲以測量傳輸和接收時(shí)間。

第一項(xiàng)測試測量在 Wi-Fi 6 和 5G 網(wǎng)絡(luò)上建立客戶端與服務(wù)器通信所需的平均時(shí)間（啟動(dòng)時(shí)間）以及端到端延遲。渲染的視頻使用 H.264 編解碼器編碼，比較三種配置：1080p 15 Mbps、720p 10 Mbps 和 480p 5 Mbps。在所有配置中，視頻以 30 FPS 渲染，編碼時(shí)使用圖像組（GOP）大小為 5 和主配置文件。另外，測量遠(yuǎn)程渲染器中編碼期間的 CPU 和 GPU 使用率的資源使用情況，而在播放器中，則分析了解碼期間的 CPU 和 GPU 使用情況。

表 I 展示了這第一項(xiàng)測試的結(jié)果，突出了以下關(guān)鍵觀察結(jié)果：

啟動(dòng)時(shí)間測量表明，基于 QUIC 的協(xié)議優(yōu)于 WebRTC，主要是因?yàn)?WebRTC 需要協(xié)商過程來建立通信路徑，而 QUIC 協(xié)議只需要執(zhí)行 UDP 握手。類似地，MoQ 的啟動(dòng)性能優(yōu)于 RoQ。這是因?yàn)樵谕瓿晌帐趾螅琑oQ 必須等待傳輸開始，而 MoQ 已經(jīng)向中繼器生成流量，只需要請求重定向中繼服務(wù)器的流量。最后，編碼參數(shù)不影響啟動(dòng)時(shí)間，因?yàn)闇y量只考慮到第一幀接收完畢所經(jīng)過的時(shí)間。

關(guān)于網(wǎng)絡(luò)差異，Wi-Fi 網(wǎng)絡(luò)表現(xiàn)出比 5G 更好的啟動(dòng)時(shí)間，大約有 200 毫秒的改進(jìn)。這種差異可能源于 5G 需要經(jīng)過核心網(wǎng)路由，而 Wi-Fi 作為直接接入點(diǎn)運(yùn)行。

在延遲比較中，RoQ 在三種協(xié)議中實(shí)現(xiàn)了最佳性能，比 WebRTC 提高了 90 毫秒。然而，由于 MoQ 使用中繼進(jìn)行服務(wù)器和播放器之間的通信，其延遲值也最高，這使延遲增加了約 100%。在編碼參數(shù)方面，觀察到具有最低比特率和分辨率的配置導(dǎo)致最低延遲，而隨著編碼參數(shù)（比特率和分辨率）的增加，延遲也會(huì)增加。

關(guān)于網(wǎng)絡(luò)差異，5G 網(wǎng)絡(luò)的表現(xiàn)優(yōu)于 Wi-Fi，延遲減少范圍在 30 到 100 毫秒之間可變。在這種情況下，由于通信已經(jīng)建立，路由不會(huì)影響延遲，從而改善了延遲值。此外，由于沒有競爭流量，兩種網(wǎng)絡(luò)都表現(xiàn)出良好的性能。

關(guān)于遠(yuǎn)程渲染器和播放器的 CPU 和 GPU 使用情況，結(jié)果可見表 II。

編碼期間的 CPU 消耗超過 100%，因?yàn)榉?wù)器使用多個(gè)核心進(jìn)行處理。CPU 測量值代表了協(xié)議進(jìn)行渲染、處理和傳輸?shù)目偸褂冒俜直取Ｗ罡叩?CPU 消耗在渲染方面。另一個(gè)重要的觀察是，CPU 使用率隨著視頻參數(shù)（比特率和分辨率）的增加而增加。這是因?yàn)楦叩匿秩竞吞幚韰?shù)會(huì)產(chǎn)生更多數(shù)據(jù)，需要額外的計(jì)算資源進(jìn)行處理。最后，在比較協(xié)議時(shí)，WebRTC 表現(xiàn)出最低的 CPU 消耗。這可以歸因于它們的成熟度以及現(xiàn)有庫對高效資源利用的優(yōu)化，相比之下，MoQ 和 RoQ 仍處于開發(fā)的早期階段。

編碼期間的 GPU 消耗隨著編碼參數(shù)的提高而增加。這是由于隨著比特率和分辨率的增加，處理的數(shù)據(jù)量更高。值得注意的是，在 480p/5Mbps 配置中，GPU 使用率報(bào)告為 0%。這是因?yàn)閷?shí)際使用率低于 1%，并且測量系統(tǒng)缺乏顯示更精確值的粒度。

關(guān)于協(xié)議之間的差異，所有協(xié)議都表現(xiàn)出相同的 GPU 消耗。由于編碼參數(shù)在所有協(xié)議中保持相同，預(yù)期的 GPU 使用率保持一致。

關(guān)于播放器上解碼期間的資源消耗，觀察到更高的編碼參數(shù)（比特率和分辨率）會(huì)導(dǎo)致資源使用增加。在 GPU 利用率方面，所有協(xié)議都表現(xiàn)出相似的消耗，因?yàn)橐曨l流在它們之間保持不變。然而，在 CPU 使用方面，WebRTC 消耗的資源最多，這是因?yàn)槠浣邮账璧?GStreamer element更復(fù)雜、更多。另一方面，RoQ 的資源密集度最低，因?yàn)槠洳シ牌鲗?shí)現(xiàn)更簡單。然而，它也更容易出錯(cuò)，因?yàn)樗狈μ幚韨鬏斿e(cuò)誤的機(jī)制，表明其實(shí)現(xiàn)尚不成熟。

在第二項(xiàng)測試中，使用 tshark 工具獲得的 PCAP 文件，分析每個(gè)協(xié)議，評估播放器的吞吐量使用、抖動(dòng)和字節(jié)丟失。網(wǎng)絡(luò)流量捕獲兩分鐘，測試在 5G 和 Wi-Fi 網(wǎng)絡(luò)上進(jìn)行。在這種情況下，遠(yuǎn)程渲染器渲染的視頻使用 H.264 編碼，分辨率為 1080p，幀率為 30 FPS，比特率為 15 Mbps。

表 III 展示了第二項(xiàng)測試的結(jié)果。其中一些結(jié)果表明，QUIC 庫和實(shí)現(xiàn)仍處于開發(fā)的早期階段，成熟度有限。

吞吐量測量旨在評估協(xié)議的開銷效率。結(jié)果表明，RoQ 實(shí)現(xiàn)了最低的數(shù)據(jù)傳輸值，其次是 WebRTC，表明這些協(xié)議的開銷較低。相比之下，MoQ 表現(xiàn)出最高的數(shù)據(jù)傳輸值，可能是由于固有的協(xié)議開銷。關(guān)于 5G 和 Wi-Fi 網(wǎng)絡(luò)之間的差異，未觀察到吞吐量的顯著變化。

在抖動(dòng)方面，WebRTC 在兩種網(wǎng)絡(luò)上都表現(xiàn)出最穩(wěn)定的性能，表明它具有更穩(wěn)健的數(shù)據(jù)包到達(dá)處理和更好的延遲抖動(dòng)補(bǔ)償。相比之下，RoQ 和 MoQ 在 Wi-Fi 上表現(xiàn)出更高的抖動(dòng)，盡管它們在 5G 網(wǎng)絡(luò)上的性能有所改善。這表明這些協(xié)議在數(shù)據(jù)包處理方面可能仍缺乏成熟度。

最后，關(guān)于字節(jié)丟失，WebRTC 表現(xiàn)出與 MoQ 和 RoQ 相當(dāng)或更好的性能。在使用兩種基于 QUIC 的協(xié)議進(jìn)行的測試中，在 Wi-Fi 環(huán)境中觀察到更高的字節(jié)丟失。相比之下，5G 網(wǎng)絡(luò)顯示出改進(jìn)的性能，其值與 WebRTC 相似。

相關(guān)論文：Streaming Remote rendering services: Comparison of QUIC-based and WebRTC Protocols

https://arxiv.org/pdf/2505.22132

總的來說，團(tuán)隊(duì)對 MoQ、RoQ 和 WebRTC 協(xié)議進(jìn)行了全面分析，重點(diǎn)研究了它們在集成到用于 Wi-Fi 和 5G 網(wǎng)絡(luò)環(huán)境中專用 XR 應(yīng)用的遠(yuǎn)程渲染服務(wù)時(shí)的延遲性能。該分析強(qiáng)調(diào)了高質(zhì)量、低延遲傳輸?shù)闹匾裕貏e是對于需要交互式視聽內(nèi)容和體積數(shù)據(jù)的應(yīng)用。另外，所提出的解決方案部署在分布式 Kubernetes 環(huán)境中，便于未來基于云的基礎(chǔ)設(shè)施的開發(fā)和實(shí)驗(yàn)。

結(jié)果表明，基于 QUIC 的協(xié)議（如 RoQ）有潛力在低延遲傳輸方面超越 WebRTC，RoQ 實(shí)現(xiàn)了最快的連接啟動(dòng)，但由于其通信機(jī)制，總體延遲較高。另外，他們對 QUIC 框架和庫的開源框架成熟度進(jìn)行了評估，強(qiáng)調(diào)盡管 WebRTC 高度優(yōu)化，但 QUIC 仍處于發(fā)展和標(biāo)準(zhǔn)化的早期階段。

對于未來的研究，團(tuán)隊(duì)建議擴(kuò)展研究范圍，探索 QUIC 多路徑在處理多個(gè)并發(fā)流（包括視頻、音頻和數(shù)據(jù)）時(shí)的性能。同時(shí)，研究雙向通信的可行性和影響，將為增強(qiáng)交互式遠(yuǎn)程渲染應(yīng)用提供寶貴的見解。