Remote Rendering for Virtual Reality: performance comparison of multimedia frameworks and protocols

Daniel Mej\'ias; Inhar Yeregui; Mario Montagud; Miguel Fern\'andez; Roberto Viola

REVIEW 3 major objections 5 minor 36 references

Remote Rendering for Virtual Reality: performance comparison of multimedia frameworks and protocols

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A remote-rendering testbed delivers VR video with 82 ms latency over WebRTC, 159 ms over MoQ, and 248 ms over RTP-over-QUIC on Wi-Fi, while DASH-based streaming lags by seconds.

desk verdict A useful engineering testbed with novel QUIC/MoQ latency numbers, but the protocol-comparison framing overreaches because rows are confounded with framework and player changes. read the letter →

arxiv 2507.00623 v1 pith:MXP6UJNY submitted 2025-07-01 cs.NI

Daniel Mejías , Inhar Yeregui , Roberto Viola , Miguel Fernández , Mario Montagud This is my paper · ORCID

classification cs.NI

keywords remoterenderingvirtualrealityWebRTCDASHLL-DASHQUICMediaoverGStreamer

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper's central claim is that a complete remote-rendering pipeline for virtual reality can be built from a rendering engine plus two general-purpose media frameworks, and that this pipeline can stream the rendered 360-degree view to lightweight clients over WebRTC, DASH, LL-DASH, QUIC, and Media over QUIC (MoQ). The authors report end-to-end latencies measured over both Wi-Fi and a 5G testbed, with WebRTC via the engine's native plugin having the lowest latency (82 ms average on Wi-Fi), followed by MoQ (159 ms) and QUIC-transported RTP (248 ms), while DASH-based delivery lands in the multi-second range. The contribution is not just a set of numbers: it is an integrated testbed that exposes the practical cost of taking rendered frames out of the GPU, pushing them through a framework pipeline, and packaging them with each protocol. If the measurements hold, a developer choosing a delivery protocol for cloud-rendered VR is trading interactivity against scalability in the way the protocol designs suggest, but with concrete implementation overheads that vary by framework.

What carries the argument

The load-bearing object is the bridge between the Unity renderer and the media frameworks: a native C++ plugin that feeds raw audio and 360-degree video buffers into GStreamer or FFmpeg pipelines, with the Unity Render Streaming plugin handling the native WebRTC path. Each protocol is realized as a different pipeline end: GStreamer produces WebRTC, DASH, RTP-over-QUIC, and MoQ (fMP4 over QUIC), while FFmpeg produces DASH and LL-DASH. The latency measurement mechanism is a clock object rendered inside the scene: the rendered frame carries a timestamp visible to the player, and both machines synchronize to a public NTP server, so the difference between generation and display becomes the reported end-to-end latency.

What would settle it

Redo the Wi-Fi and 5G latency measurements with both endpoints synchronized to a shared hardware clock, such as a PTP grandmaster, and compare the resulting values; if the WebRTC latency shifts by more than the reported standard deviation of 12 ms, the NTP-based absolute figures are not reliable and the ranking would need re-examination.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that remote rendering with standard streaming protocols is ready to serve as a research platform: a Unity-based renderer with a GPU encoder can output H.264 1080p/60fps video and, depending on the integration path, deliver it with average latencies from 82 ms (native WebRTC plugin) to roughly 9.4 seconds (GStreamer DASH) over Wi-Fi, and from 129 ms to 10.2 seconds over 5G. The ordering is consistent across both networks, and the paper attributes the gaps among WebRTC variants to the cost of copying raw frames out of the GPU and back in for encoding. It reports that the QUIC-based transport option, RTP over QUIC, lands within 29–40 ms of the GStreamer WebRTC implementation, and that the unofficial MoQ implementation already beats that WebRTC path. DASH and LL-DASH provide scalability but at the cost of seconds of latency, with LL-DASH's fragmented MP4 reducing latency by roughly one fifth relative to plain DASH.

Load-bearing premise

The whole comparison rests on the assumption that the NTP-synchronized clock rendered into the scene gives an accurate timestamp of when each frame was produced, and that the player's clock is aligned closely enough that the measured delays are not systematically offset by synchronization error.

Editorial extensions

If this is right

Interactive cloud-rendered VR is feasible over WebRTC at the sub-100 ms level on Wi-Fi, since the native WebRTC path averaged 82 ms and the GStreamer path 219 ms.
MoQ, despite being an unofficial early implementation, is the closest QUIC-based protocol to WebRTC latency, supporting the possibility that QUIC-based application protocols can be competitive for immersive streaming.
DASH and LL-DASH cannot support tight interaction loops in this setup; their multi-second latencies restrict them to rotation-only 360 video or non-interactive viewing.
The framework choice matters as much as the protocol choice: copying frames through native APIs is faster than piping through a CLI, and the GStreamer DASH output needed patching for player compatibility.
The 5G results preserve the protocol ordering but add roughly 36–56 ms to the best WebRTC path and smaller relative increases elsewhere, showing that the delivery network is not the dominant cost in this testbed.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A natural next test is measuring the interaction channel separately: the paper's latency numbers cover video delivery, but end-to-end interactivity also includes the uplink of headset motion, which only the URS WebRTC path currently supports.
Because the QUIC option is raw RTP over QUIC without an application layer, its 248 ms Wi-Fi result likely underestimates what RoQ or MoQ could achieve once receiver buffering and congestion control mature; the paper's own MoQ result suggests the gap is already closing.
The same testbed could be extended to variable bitrate and loss conditions, since all tests appear to run at a fixed 10 Mbps; the protocol ranking may change when congestion control and adaptive bitrate are exercised.
If the NTP synchronization error is a few tens of milliseconds, the absolute latency values are less important than the relative ordering, but sub-100 ms claims like 82 ms should be re-validated under hardware-synchronized clocks.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Readable engineering paper and a genuinely useful testbed. The authors integrated GStreamer and FFmpeg with Unity Render Streaming and report end-to-end latency for WebRTC, DASH, LL-DASH, QUIC-RTP, and MoQ over both Wi-Fi and a 3GPP Release 15 5G testbed. The QUIC and MoQ numbers are new, and the testbed itself is a contribution for the XR streaming community. I also credit the transparency: they openly flag the GStreamer DASH non-compliance, the unofficial MoQ implementation, and the fact that QUIC here is only raw RTP over QUIC with no application layer.

The main soft spot is the one the stress test identifies: Tables I and II are presented as a protocol comparison, but each row changes the sender and/or receiver implementation. URS WebRTC uses Unity's sender and player; GStreamer WebRTC uses a different receiver; DASH rows use GStreamer or FFmpeg senders with Dash.js; QUIC uses a custom receiver; MoQ uses an unofficial player. So the 29–77 ms gaps and the huge DASH differences are attributable to encoder insertion, muxing, player buffering, and implementation maturity as much as to the protocol itself. The paper even acknowledges this for WebRTC, attributing the URS-vs-GStreamer gap to GPU frame extraction, but the abstract and conclusions still frame the results as a protocol analysis. That is a genuine load-bearing weakness, not a minor quibble.

Separately, the measurement methodology is under-specified: no trial count, no confidence intervals, no NTP offset error analysis, and no description of how the rendered timestamp was aligned with the received frame in the player. The numbers are plausible and internally consistent, but we cannot assess their precision. This is fixable with a methods paragraph and ideally by releasing the testbed code and raw data.

Who is this for? Practitioners building cloud/edge VR streaming systems, and researchers benchmarking emerging QUIC-based media transport. It deserves a serious referee: the engineering integration is real, the measurement domain is relevant, and the limitations are mostly correctable. I would accept it for peer review, but the revision needs to reframe the tables as framework-and-protocol combinations rather than pure protocol comparisons, and add the missing methodological detail.

Recommendation: send to review, conditional on fixing the framing and the measurement reporting.

Referee Report

3 major / 5 minor

Summary. The paper describes a remote-rendering testbed that integrates Unity with three multimedia frameworks (Unity Render Streaming, GStreamer, and FFmpeg) and delivers a rendered 360-degree VR scene over WebRTC, DASH, LL-DASH, QUIC-RTP, and MoQ. The authors measure the maximum rendering throughput and the end-to-end latency over Wi-Fi and a 5G testbed, reporting in Tables I and II average latencies from 82 ms (URS WebRTC) to 9399 ms (GStreamer DASH) at 1080p/60fps/10 Mbps. The paper concludes that URS WebRTC has the lowest latency, that MoQ and QUIC are promising near-term alternatives, and that DASH/LL-DASH have the highest latency but offer scalability. The main claimed contributions are a multi-protocol remote-rendering testbed and a comparative performance analysis of frameworks and protocols.

Significance. If the measurements were properly controlled, the testbed would be a useful community resource for XR remote-rendering research, and the comparison of five delivery protocols over both Wi-Fi and a 5G testbed is a valuable data point. The paper is honest in reporting implementation details and in attributing some gaps to framework behavior rather than to protocol properties; the authors also flag a GStreamer DASH compliance issue and submit a merge request, which is a positive community contribution. However, the current presentation does not separate protocol effects from implementation effects, and the latency methodology is too underspecified for the numerical ordering to be taken as a protocol comparison. The engineering contribution is real, but the central quantitative claim needs substantial revision and additional measurement detail before it can be accepted.

major comments (3)

[Section IV, Tables I and II] The central claim that the measured latencies characterize the protocols is undermined by the fact that each protocol row changes the sender framework, the receiver implementation, or both; for example, URS WebRTC uses the URS sender and the URS player, GStreamer WebRTC uses a gstwebrtc-api receiver, the DASH rows use different senders (GStreamer versus FFmpeg) with the same Dash.js receiver, QUIC uses a custom GStreamer pipeline as receiver, and MoQ uses an unofficial MoQ player. The latency gaps in Tables I and II (82 vs 219 ms for WebRTC, 6183 vs 9399 ms for DASH) are therefore attributable to encoder integration, muxing, player buffering, or implementation maturity rather than to the protocol itself, as the paper itself acknowledges when explaining the WebRTC gap by GPU frame extraction. To support the protocol-level conclusion, the authors need either controlled experiments that vary only the protocol while holding the surrounding pipeline fixed, or a reframing of the results as comparisons of complete framework-protocol stacks rather than of protocols.
[Section IV, Figure 4 and Tables I and II] The latency measurement methodology is under-specified; the paper does not report the number of repetitions, the statistical meaning of Latencydev (standard deviation, range, or other), the procedure for extracting the frame timestamp from the rendered clock object, the matching of received frames to rendered timestamps, or the NTP synchronization accuracy and residual clock offset. Without these details, the reader cannot assess whether the reported differences (e.g., 29 ms between QUIC-RTP and GStreamer WebRTC over Wi-Fi) are significant, and a constant offset from imperfect clock synchronization would shift every value in the tables. The authors should describe the measurement procedure precisely and provide confidence intervals or per-repetition distributions.
[Section IV, Table I] The reported DASH and LL-DASH latencies (6183 ms and 4873 ms over Wi-Fi) are not reconciled with the configured segment duration of 2 seconds and fragment duration of 0.5 seconds; the paper does not explain what components contribute the remaining latency (encoder GOP, muxing, buffer, player, etc.) or why LL-DASH with 0.5 second fragments still yields about 4.9 seconds of end-to-end latency. Without a latency budget breakdown, the DASH/LL-DASH comparison is not interpretable, and the claim that these values characterize the protocols is not supported.

minor comments (5)

[References] Reference [24] duplicates reference [2] (Yeregui et al., IEEE BMSB 2024); please remove the duplicate or cite different work.
[Section IV] The GStreamer merge request URL contains a space ('merge requests/7886'); it should likely be 'merge-requests/7886' with a hyphen.
[Section IV] The statement that 'all the protocols show better results over WIFI than 5G, ranging from -36% with URS WebRTC to -4% with LL-DASH' should specify the sign convention and the base of the percentage (e.g., relative reduction of the 5G latency when using Wi-Fi).
[Abstract and Introduction] The abstract and introduction mention MoQ as a 'protocol' comparable to WebRTC and DASH, but MoQ is an application-layer protocol that runs over QUIC; a sentence clarifying the protocol-stack layer would avoid confusion.
[Figure 5] Figure 5 is introduced without a clear description of the measurement procedure (e.g., how many seconds are averaged, how the mean is computed, and whether error bars are shown); please add this information or refer to it in the text.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper reports direct end-to-end latency measurements, with no fitted parameter, self-citation chain, or derivation step that reduces a claimed result to its inputs.

full rationale

The paper's central contribution is an experimental testbed and a set of measured latencies (Tables I and II) obtained by rendering a scene containing a clock, synchronizing sender and receiver to a public NTP server, and reading the displayed time at the receiver. There is no mathematical derivation, no fitted model, and no quantity that is defined in terms of another quantity it is supposed to predict. The protocol comparisons vary sender, receiver, and framework across rows, which is a methodological confound and a threat to the attribution of latency differences to protocols, but this is an experimental-design limitation, not circularity. The self-citations ([2] and [24]) appear in related work and are not load-bearing for the reported measurements. No ansatz is imported as a forced choice, and no known empirical pattern is renamed as a new result. Therefore the circularity score is 0.

Assumptions & free parameters 5 free parameters · 3 assumptions · 0 invented entities

This is an experimental systems paper; no equations or statistical fits are involved. The free parameters listed are hand-chosen test conditions that directly determine the latency numbers in Tables I and II. The axioms are background assumptions about measurement accuracy and implementation representativeness. No theoretical entities are introduced.

free parameters (5)

Video encoding bitrate = 10 Mbps
Chosen by authors for all latency tests; latency values in Tables I and II depend on this setting.
GOP length = 5 frames
Chosen by authors; affects encoder delay and therefore end-to-end latency.
Video resolution and framerate = 1080p/60 fps
Chosen as the only resolution all frameworks sustain at 60 fps; latency scales with resolution.
DASH segment duration = 2 seconds
Set for both DASH and LL-DASH; segment duration directly adds to latency.
LL-DASH fragment duration = 0.5 seconds
fMP4 fragment duration within 2-second segments; shorter fragments lower LL-DASH latency.

assumptions (3)

domain assumption The rendered scene clock and NTP synchronization provide an accurate basis for end-to-end latency measurement.
Section IV: the clock object shows the timestamp of frame generation, and both machines sync to a public NTP server. If NTP offset error is comparable to measured latencies (tens of ms), all latency values are unreliable.
domain assumption The tested software implementations are representative of their respective protocols.
The paper compares protocol performance but some implementations are unofficial (MoQ), patched by the authors (GStreamer DASH), or transport-only (QUIC with RTP). These choices affect the reported numbers.
domain assumption The AMARI Callbox Mini implements a representative 3GPP Release 15 5G network.
The 5G latency results depend on this test equipment being representative of real 5G deployments.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Remote Rendering for Virtual Reality: performance comparison of multimedia frameworks and protocols." pith.science (2026). https://pith.science/paper/MXP6UJNY

@misc{pith2026250700623,
  author       = {Pith},
  title        = {Pith review of: Remote Rendering for Virtual Reality: performance comparison of multimedia frameworks and protocols},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MXP6UJNY}},
  note         = {Machine review of arXiv:2507.00623}
}

read the original abstract

The increasing complexity of Extended Reality (XR) applications demands substantial processing power and high bandwidth communications, often unavailable on lightweight devices. Remote rendering consists of offloading processing tasks to a remote node with a powerful GPU, delivering the rendered content to the end device. The delivery is usually performed through popular streaming protocols such as Web Real-Time Communications (WebRTC), offering a data channel for interactions, or Dynamic Adaptive Streaming over HTTP (DASH), better suitable for scalability. Moreover, new streaming protocols based on QUIC are emerging as potential replacements for WebRTC and DASH and offer benefits like connection migration, stream multiplexing and multipath delivery. This work describes the integration of the two most popular multimedia frameworks, GStreamer and FFmpeg, with a rendering engine acting as a Remote Renderer, and analyzes their performance when offering different protocols for delivering the rendered content to the end device over WIFI or 5G. This solution constitutes a beyond state-of-the-art testbed to conduct cutting-edge research in the XR field.

Figures

Figures reproduced from arXiv: 2507.00623 by the authors.

**Figure 2.** Integration of GStreamer with the Remote Renderer. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 4.** Testbed for WIFI and 5G latency measurement. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

36 extracted references · 36 canonical work pages

[1]

Cloud rendering scheme for standalone virtual reality headset,

G. Xiao, H. Li, C. Han, Y . Liu, Y . Li, and J. Liu, “Cloud rendering scheme for standalone virtual reality headset,” in 2020 International Conference on Virtual Reality and Visualization (ICVRV). IEEE, 2020, pp. 316–319

work page 2020
[2]

Edge rendering architecture for multiuser xr experiences and e2e performance assessment,

I. Yeregui, D. Mej ´ıas, G. Pacho, R. Viola, J. Astorga, and M. Montagud, “Edge rendering architecture for multiuser xr experiences and e2e performance assessment,” in 2024 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB). IEEE, 2024, pp. 1–7

work page 2024
[3]

Real-time communication for the web,

“Real-time communication for the web,” [Online] Available: https: //webrtc.org/, Accessed: 2024-10-10

work page 2024
[4]

Experimental evaluation of interactive edge/cloud virtual reality gaming over wi-fi using unity render streaming,

M. Casasnovas Bielsa, C. Michaelides, M. Carrascosa, and B. Bellalta, “Experimental evaluation of interactive edge/cloud virtual reality gaming over wi-fi using unity render streaming,” Cloud Virtual Reality Gaming Over Wi-Fi Using Unity Render Streaming , 2024

work page 2024
[5]

Application and research of high quality pixel streaming architecture based on unreal engine,

H. Feng, H. Lu, F. Zhang, and Z. Li, “Application and research of high quality pixel streaming architecture based on unreal engine,” in Proceedings of the 3rd International Conference on Computer, Artificial Intelligence and Control Engineering , 2024, pp. 17–21

work page 2024
[6]

ISO/IEC 23 009-1:2022, 2022

Information technology — Dynamic adaptive streaming over HTTP (DASH), International Organization for Standardization Std. ISO/IEC 23 009-1:2022, 2022

work page 2022
[7]

Virtual reality and dash,

D. Podborski, E. Thomas, M. Hannuksela, S. Oh, T. Stockhammer, and S. Pham, “Virtual reality and dash,” Proc. Int. Broadcast. Conv.(IBC) , pp. 1–11, 2017

work page 2017
[8]

QUIC: A UDP-Based Multiplexed and Secure Transport,

J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” RFC 9000, May 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9000

work page 2021

Show all 36 references

[9]

Measuring http/3: Adoption and performance,

M. Trevisan, D. Giordano, I. Drago, and A. S. Khatouni, “Measuring http/3: Adoption and performance,” in 2021 19th Mediterranean Communication and Computer Networking Conference (MedComNet) . IEEE, 2021, pp. 1–8

2021
[10]

RTP over QUIC (RoQ),

M. Engelbart, J. Ott, and S. Dawkins, “RTP over QUIC (RoQ),” Internet Engineering Task Force, Internet-Draft draft-ietf-avtcore- rtp-over-quic-11, Jul. 2024, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-over-quic/11/

2024
[11]

Media over QUIC Transport,

L. Curley, K. Pugin, S. Nandakumar, V . Vasiliev, and I. Swett, “Media over QUIC Transport,” Internet Engineering Task Force, Internet-Draft draft-ietf-moq-transport-06, Sep. 2024, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-moq-transport/06/

2024
[12]

Congestion control for real-time media over quic,

M. Engelbart and J. Ott, “Congestion control for real-time media over quic,” in Proceedings of the 2021 Workshop on Evolution, Performance and Interoperability of QUIC , 2021, pp. 1–7

2021
[13]

Media over quic: Initial testing, findings and results,

Z. Gurel, T. Erkilic Civelek, A. Bodur, S. Bilgin, D. Yeniceri, and A. C. Begen, “Media over quic: Initial testing, findings and results,” in Proceedings of the 14th Conference on ACM Multimedia Systems , 2023, pp. 301–306

2023
[14]

GStreamer,

“GStreamer,” [Online] Available: https://gstreamer.freedesktop.org/, Accessed: 2024-10-10

2024
[15]

“FFmpeg,” [Online] Available: https://www.ffmpeg.org/, Accessed: 2024-10-10

2024
[16]

DASH-IF publishes Low-Latency DASH extensions and 2nd Community Review for DASH-IF Ad Insertion,

“DASH-IF publishes Low-Latency DASH extensions and 2nd Community Review for DASH-IF Ad Insertion,” [Online] Available: https://dashif.org/news/low-latency-dash/, Accessed: 2024-10-10

2024
[17]

A streaming-based solution for remote visualization of 3d graphics on mobile devices,

F. Lamberti and A. Sanna, “A streaming-based solution for remote visualization of 3d graphics on mobile devices,” IEEE Transactions on Visualization and Computer Graphics, vol. 13, no. 2, pp. 247–260, 2007

2007
[18]

Renderfusion: Balancing local and remote rendering for interactive 3d scenes,

E. Lu, S. Bharadwaj, M. Dasari, C. Smith, S. Seshan, and A. Rowe, “Renderfusion: Balancing local and remote rendering for interactive 3d scenes,” in 2023 IEEE International Symposium on Mixed and Augmented Reality (ISMAR) , 2023, pp. 312–321

2023
[19]

Metaverse remote rendering testbed,

L. Bassbouss, A. Neparidze, K. Kieslich, S. Steglich, S. Arbanowski, and P. Pogrzeba, “Metaverse remote rendering testbed,” in 2023 IEEE International Conference on Metaverse Computing, Networking and Applications (MetaCom), 2023, pp. 578–584

2023
[20]

Seamless cross-edge service migration for real-time rendering applications,

Y . Li, S. Wang, Y . Li, A. Zhou, M. Xu, X. Ma, and Y . Liu, “Seamless cross-edge service migration for real-time rendering applications,” IEEE Transactions on Mobile Computing, vol. 23, no. 6, pp. 7084–7098, 2024

2024
[21]

A high-quality low-delay remote rendering system for 3d video,

S. Shi, M. Kamali, K. Nahrstedt, J. C. Hart, and R. H. Campbell, “A high-quality low-delay remote rendering system for 3d video,” in Proceedings of the 18th ACM international conference on Multimedia , 2010, pp. 601–610

2010
[22]

A real-time remote rendering system for interactive mobile graphics,

S. Shi, K. Nahrstedt, and R. Campbell, “A real-time remote rendering system for interactive mobile graphics,” ACM Transactions on Multimedia Computing, Communications, and Applications (TOMM), vol. 8, no. 3s, pp. 1–20, 2012

2012
[23]

A novel approach for remote rendering and streaming in xr,

A. Zoubarev, L. Bassbouss, D. L. Tran, S. Steglich, and S. Arbanowski, “A novel approach for remote rendering and streaming in xr,” in 201031477824 2nd International Conference on Intelligent Metaverse Technologies & Applications (iMETA) , 2024, pp. 198–205

2024
[24]

Edge rendering architecture for multiuser xr experiences and e2e performance assessment,

I. Yeregui, D. Mej ´ıas, G. Pacho, R. Viola, J. Astorga, and M. Montagud, “Edge rendering architecture for multiuser xr experiences and e2e performance assessment,” in 2024 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB) , 2024, pp. 1–7

2024
[25]

Unity Renderer Streaming,

“Unity Renderer Streaming,” [Online] Available: https://docs.unity3d. com/Packages/com.unity.renderstreaming@3.1/\\manual/index.html, Accessed: 2024-10-10

2024
[26]

libwebrtc,

“libwebrtc,” [Online] Available: https://github.com/webrtc-sdk/ libwebrtc, Accessed: 2024-10-10

2024
[27]

Unity Native plug-ins,

“Unity Native plug-ins,” [Online] Available: https://docs.unity3d.com/ Manual/NativePlugins.html, Accessed: 2024-10-10

2024
[28]

GStreamer: appsrc,

“GStreamer: appsrc,” [Online] Available: https://gstreamer.freedesktop. org/documentation/app/appsrc.html?gi-language=c, Accessed: 2024-10- 10

2024
[29]

RTP: A Transport Protocol for Real-Time Applications,

H. Schulzrinne, S. L. Casner, R. Frederick, and V . Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” RFC 3550, Jul. 2003. [Online]. Available: https://www.rfc-editor.org/info/rfc3550

2003
[30]

Media over QUIC,

L. Curley, “Media over QUIC,” [Online] Available: https://quic.video, Accessed: 2024-10-10

2024
[31]

pipe - overview of pipes and FIFOs,

“pipe - overview of pipes and FIFOs,” [Online] Available: https://manpages.ubuntu.com/manpages/jammy/en/man7/pipe.7.html, Accessed: 2024-10-10

2024
[32]

AMARI Callbox Mini,

“AMARI Callbox Mini,” [Online] Available: https://www. amarisoft.com/test-and-measurement/device-testing/device-products/ amari-callbox-mini, Accessed: 2024-10-10

2024
[33]

3GPP Release 15,

“3GPP Release 15,” [Online] Available: https://www.3gpp.org/ specifications-technologies/releases/release-15, Accessed: 2024-10-10

2024
[34]

gstwebrtc-api,

“gstwebrtc-api,” [Online] Available: https://gitlab.freedesktop.org/ \\gstreamer/gst-plugins-rs/-/tree/main/net/webrtc/gstwebrtc-api, Accessed: 2024-10-10

2024
[35]

Dash.js,

“Dash.js,” [Online] Available: https://dashjs.org/, Accessed: 2024-10-10

2024
[36]

Balancing performance and comfort in virtual reality: A study of fps, latency, and batch values,

A. Geris, B. Cukurbasi, M. Kilinc, and O. Teke, “Balancing performance and comfort in virtual reality: A study of fps, latency, and batch values,” Software: Practice and Experience , 2024

2024

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

Cloud rendering scheme for standalone virtual reality headset,

G. Xiao, H. Li, C. Han, Y . Liu, Y . Li, and J. Liu, “Cloud rendering scheme for standalone virtual reality headset,” in 2020 International Conference on Virtual Reality and Visualization (ICVRV). IEEE, 2020, pp. 316–319

work page 2020

[2] [2]

Edge rendering architecture for multiuser xr experiences and e2e performance assessment,

I. Yeregui, D. Mej ´ıas, G. Pacho, R. Viola, J. Astorga, and M. Montagud, “Edge rendering architecture for multiuser xr experiences and e2e performance assessment,” in 2024 IEEE International Symposium on Broadband Multimedia Systems and Broadcasting (BMSB). IEEE, 2024, pp. 1–7

work page 2024

[3] [3]

Real-time communication for the web,

“Real-time communication for the web,” [Online] Available: https: //webrtc.org/, Accessed: 2024-10-10

work page 2024

[4] [4]

Experimental evaluation of interactive edge/cloud virtual reality gaming over wi-fi using unity render streaming,

M. Casasnovas Bielsa, C. Michaelides, M. Carrascosa, and B. Bellalta, “Experimental evaluation of interactive edge/cloud virtual reality gaming over wi-fi using unity render streaming,” Cloud Virtual Reality Gaming Over Wi-Fi Using Unity Render Streaming , 2024

work page 2024

[5] [5]

Application and research of high quality pixel streaming architecture based on unreal engine,

H. Feng, H. Lu, F. Zhang, and Z. Li, “Application and research of high quality pixel streaming architecture based on unreal engine,” in Proceedings of the 3rd International Conference on Computer, Artificial Intelligence and Control Engineering , 2024, pp. 17–21

work page 2024

[6] [6]

ISO/IEC 23 009-1:2022, 2022

Information technology — Dynamic adaptive streaming over HTTP (DASH), International Organization for Standardization Std. ISO/IEC 23 009-1:2022, 2022

work page 2022

[7] [7]

Virtual reality and dash,

D. Podborski, E. Thomas, M. Hannuksela, S. Oh, T. Stockhammer, and S. Pham, “Virtual reality and dash,” Proc. Int. Broadcast. Conv.(IBC) , pp. 1–11, 2017

work page 2017

[8] [8]

QUIC: A UDP-Based Multiplexed and Secure Transport,

J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” RFC 9000, May 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9000

work page 2021