Pith. sign in

REVIEW 4 major objections 4 minor 35 references

MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming

T0 review · 4 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read A redesigned Media-over-QUIC delivery layer with per-track multi-access switching keeps live 360-degree tile streaming continuous and lifts goodput above DASH and standard MoQ.

desk verdict A solid MoQ delivery redesign with a genuine ablation, but single-run emulation leaves the headline quantitative claims unproven. read the letter →

arxiv 2608.06102 v1 pith:LF5TULBV submitted 2026-08-06 cs.NI cs.MM

Yitong Li , Xinjiao Li , Ruonan Chai , Dirk Kutscher This is my paper · ORCID
classification cs.NIcs.MM
keywords 360-degreevideoimmersivestreamingMediaoverQUICmulti-accessdeliverytile-basednetworkemulationplaybackcontinuityviewport-adaptive
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 tries to establish that Media over QUIC's relay-assisted fan-out, which is attractive for large-scale live streaming but stalls badly under bandwidth constraints, can be made dependable for immersive 360-degree video by changing delivery control rather than bitrate selection. MultiMoQ separates pending groups from the active group inside MoQ-Lite, the transport-facing delivery layer, and lets each client monitor tracks, warm an alternate access path, and switch individual tiles without exposing a discontinuity. In network emulation with 96 clients, the authors report enhancement-tile goodput of 1.20 Mbps in the bad-access condition versus 0.66 Mbps for DASH and 0.72 Mbps for standard MoQ, with p95 end-to-end delay cut from 3930 ms to 1130 ms. A sympathetic reader would care because the result suggests a path to live 360-degree streaming to many concurrent viewers without the repeated backhaul fetches of DASH and without the persistent stalls of current MoQ.

What carries the argument

The carrying mechanism is a two-layer separation of concerns. The lower layer, a redesigned MoQ-Lite group scheduler (the transport-facing delivery layer of Media over QUIC), maintains a FIFO pending queue per track while the active queue holds at most one group; the sender picks the group minimizing $\mathrm{score}(g) = w_{\mathrm{stale}} \cdot \mathrm{stale}(g) + w_{\mathrm{gap}} \cdot \mathrm{gap}(g)$, where the gap term measures the playback time skipped if the chosen group follows the last completed group, and neither queue maintenance nor overflow can modify the active group. The upper layer, client-driven multi-access control, runs one Hang instance (the client's media-consumption layer) per access path feeding a stream multiplexer that enforces make-before-break handover: start the new path before stopping the old one. The secondary access is subscribed and probed during warmup, cutover commits only after the new stream satisfies a timestamp-lead guard and a decoder-safe entry point, and rollback keeps the primary if the alternate fails. The redesign supplies delivery continuity along the server-relay-client path; the controller supplies timeliness by moving a degraded track to a better access before transport delay turns into playback lag.

What would settle it

Re-run the bad-access scenario multiple times with different random seeds or topologies and record enhancement-tile goodput and stall time; if MultiMoQ's 1.20 Mbps versus 0.66 Mbps for DASH and its near-zero stall percentages are not separated by the run-to-run spread, the claimed robustness advantage is not established.

Watch

Extended reading notes

Core claim

The central claim is that two coordinated changes make MoQ robust for concurrent tile streams. First, the MoQ-Lite delivery layer gives each track a FIFO pending queue and allows at most one active group per track on a dedicated QUIC stream, so freshness maintenance and overflow eviction never abort an in-flight group; a score balancing staleness and sequence gap selects the next group. Second, each client runs per-track access control with make-before-break handover: an alternate access is warmed while the primary continues, and cutover happens only when the alternate reaches a decoder-safe entry point and advances beyond the committed timestamp, so the application sees one ordered stream. The authors report that this design raises enhancement-tile goodput above both baselines across bad, stable, and good access conditions, reduces enhancement-tile tail latency relative to DASH to roughly one second, preserves audio continuity, and eliminates the persistent stalls of standard MoQ. Reconstructed viewport playback shows a 1.09% freeze ratio and one 0.50-second freeze event, versus a 51.5% freeze ratio for DASH and a 3.96% ratio with longer maximum freeze for standard MoQ.

Load-bearing premise

The headline numbers come from a single emulation run per system with no repeated trials or error bars, so the comparisons rest on the assumption that those runs are representative of each system's typical behavior.

Editorial extensions

If this is right

  • Enhancement-tile goodput in the bad-access condition rises to 1.20 Mbps with MultiMoQ versus 0.66 Mbps for DASH and 0.72 Mbps for standard MoQ.
  • Enhancement-tile p95 end-to-end latency drops from 3930/3062/2473 ms with DASH to 1130/936/956 ms with MultiMoQ across bad, stable, and good conditions.
  • Transport stall time falls to 0.11%, 1.32%, and 1.03% for MultiMoQ, while standard MoQ stalls 29.1% in the bad condition and above 14% otherwise, and its audio track stalls above 85% in every condition.
  • The MoQ-Lite redesign alone removes most transport stalls, and adding multi-access control cuts the playback freeze ratio from 4.62% to 1.09% and the maximum freeze from 1.03 seconds to 0.50 seconds.
  • Viewport reconstruction keeps the transport gains: MultiMoQ's freeze ratio is 1.09% with mean SSIM 0.990, compared with 51.5% freeze ratio for DASH and 3.96% for standard MoQ.

Reading between the lines

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

  • Editorial extension: the pending-active separation tested on tiled 360-degree video should apply to other live media workloads with several synchronized streams, such as multi-angle sports or spatial audio, where one stalled track can degrade the whole presentation.
  • Editorial extension: because the paper disables adaptive bitrate selection to isolate transport, combining MultiMoQ with a representation controller is a direct next experiment and could show additional quality-of-experience gains when access bandwidth varies.
  • Editorial extension: the paper argues qualitatively that secondary-relay subscriptions can reuse existing relay fan-out instead of adding proportional backhaul load; a direct measurement of backhaul traffic would test whether this scalability benefit holds under many concurrent switches.
  • Editorial extension: the conservative switching trigger suggests a tunable tradeoff between responsiveness and stability; a parameter sweep over the watchdog interval and handover limits could map how much latency improvement is lost when switching is made more aggressive.
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.

Referee Report

4 major / 4 minor

Summary. The paper proposes MultiMoQ, a client-driven multi-access tile streaming framework built on Media over QUIC (MoQ). It modifies MoQ-Lite group delivery with separate pending/active queues and freshness-based scoring, and adds per-track QoE-driven access switching with make-before-break handovers. The evaluation compares MultiMoQ with DASH and standard MoQ in a 96-client Mininet emulation using measured access distributions, reporting goodput, latency, stall times, freeze ratios, and SSIM/VMAF. The authors conclude that MultiMoQ increases enhancement-tile and base-video goodput, reduces tail latency relative to DASH, avoids standard MoQ's persistent stalls, and yields smoother viewport playback, with the ablation showing that the multi-access controller contributes to continuity.

Significance. If the results hold, this is a useful extension of MoQ for live 360-degree streaming. The paper identifies a genuine robustness gap in standard MoQ-Lite and offers a clean architectural separation between transport-layer group continuity and endpoint access adaptation. The prototype is implemented and source code is provided, the ablation is well designed, and the scope is stated candidly. The main weakness is statistical: the headline numbers come from a single emulation run per system with no error bars, and several important switching parameters are unspecified. As it stands, the quantitative comparisons are plausible but not yet firmly established.

major comments (4)
  1. [Section 4.4 / Fig. 13 and Section 4.2] Section 4.4 explicitly states that Fig. 13 reports 96 client observations per system from one shared-topology run, not independent repetitions, and the rest of Section 4 gives no indication of repeated trials or error bars. Since the headline comparisons (e.g., Section 4.2: enhancement-tile goodput 1.20 vs 0.66 Mbps; p95 delay 1130 vs 3930 ms) are point estimates from correlated clients within a single run, the claimed quantitative gains are not yet established. Please add multiple independent runs, report distributions or confidence intervals, and adjust the claims to reflect the statistical uncertainty.
  2. [Section 4.2 vs. Section 4.4 / Fig. 14] Section 4.2 reports that 'DASH also rarely stalled', but Section 4.4 and Fig. 14 report a 51.5% freeze ratio for DASH with 26 freeze events. If transport stall time and viewport freeze ratio are different metrics, the paper must define both clearly and explain how a system with near-zero transport stalls can exhibit 51.5% playback freeze. As written, this contradiction undermines the continuity comparison and needs to be resolved.
  3. [Section 4.1.4 / Fig. 8] All primary links follow the measured distributions (bad: 8–15 Mbps, stable: 15–30, good: 30–40), while every secondary link is fixed at 30 Mbps and only MultiMoQ uses the secondary path. The goodput gains over DASH and standard MoQ may therefore be due partly to a larger total access bandwidth budget rather than to the proposed delivery redesign. Please add a control comparison that provides the baselines with a comparable second path, or discuss explicitly why the asymmetry does not affect the conclusions.
  4. [Sections 3.2–3.3] The quantitative behavior of the system depends on several parameters: w_stale=1, w_gap=0.5, the five-entry pending queue, the watchdog intervals, the per-round handover limit, and the QoE switching thresholds. No values are given for the switching thresholds and no sensitivity analysis is provided. Without this, the reported improvements may be artifacts of a specific parameter tuning and the implementation is not reproducible. Please report the threshold values and add a sensitivity study for the main parameters.
minor comments (4)
  1. [Section 4.4] The definitions of B_i and D_i in Fig. 13 are easy to misread; consider adding a concrete example or a small table to illustrate the weakest-track and worst-latency computation.
  2. [Table 1] The footnote says the measurements were collected across different locations and time periods, but the sampling methodology, number of samples, and date range are not specified; please add these details so the distributions can be reproduced.
  3. [Equation (2)] The notation gap_g in Eq. (2) is inconsistent with gap(g) used in the text; unify the notation.
  4. [General] The paper alternates between '1-s groups' and '1-s GOP'; choose one term for consistency.

Circularity Check

0 steps flagged · score 1.0 of 10

No circular dependency found: MultiMoQ's claims are supported by direct comparison against external DASH and standard-MoQ baselines in emulation, with no self-citation chain or fit-to-outcome reduction.

full rationale

The paper's central claims are empirical comparisons against external baselines (DASH and standard MoQ), not derivations from the claims themselves. The motivation in Section 2.3 uses measurements to identify baseline failure modes, and the later evaluation reuses the same setup as a controlled benchmark; this is not circular because the design is not defined in terms of the reported metrics. The MoQ-Lite scheduling score (Eqs. 1-2) uses hand-set weights (w_stale=1, w_gap=0.5), but this is a design parameter, not a fitted outcome predictor; the goodput, latency, and stall metrics are measured from emulation rather than computed from the score equation. Citations [5] and [17] are external IETF drafts by other authors and are not self-citations carrying the argument. The ablation in Section 4.3 isolates components by comparing redesign-only with full MultiMoQ, which is a standard controlled comparison. The only notable weakness is methodological, not circular: Section 4.4 states that Fig. 13 reports '96 client observations per system from one shared-topology run, not independent repetitions,' and no error bars or statistical tests are reported. This limits confidence in the quantitative point estimates, but it does not make the evaluation equivalent to its inputs. The paper is therefore self-contained against external benchmarks; no load-bearing step reduces to its own assumptions or citations.

Assumptions & free parameters 7 free parameters · 4 assumptions · 0 invented entities

The core evidence is empirical. The central claims rest on the scheduling weights (w_stale, w_gap) and queue size in the MoQ-Lite redesign, on the undisclosed QoE switching thresholds, and on the assumption that a Mininet topology with a single run per system captures realistic behavior. These are domain assumptions rather than mathematical axioms.

free parameters (7)
  • w_stale = 1.0
    Weight on staleness in the group scheduling score (Eq. 1); set by hand, no sensitivity analysis.
  • w_gap = 0.5
    Weight on sequence-gap cost in the group scheduling score (Eq. 1); set by hand, no sensitivity analysis.
  • pending queue size = 5 entries
    Tunable FIFO depth for pending groups; prototype uses five entries, no sensitivity analysis.
  • QoE switching thresholds = not disclosed
    The switching trigger requires relative and absolute increases over the baseline, a sustained upward trend, and confirmation in consecutive windows without concrete values.
  • watchdog intervals = not disclosed
    Transmission and delivery-progress watchdog intervals that decide when a group is abandoned are not specified.
  • per-round handover limit = not disclosed
    The limit on simultaneous handovers per round to avoid mass switching is not specified.
  • secondary access bandwidth = 30 Mbps
    All secondary links use 30 Mbps; the reported gains depend on this capacity, which is a fixed experimental choice.
assumptions (4)
  • domain assumption Mininet emulation with static per-link bandwidth and delay is representative of real-world heterogeneous access conditions.
    The paper uses a campus measurement (Table 1) and an 80 Mbps backhaul, but never validates against real dynamic networks.
  • domain assumption Disabling adaptive bitrate selection in all systems is a fair comparison.
    DASH normally adapts bitrate; the paper disables ABR to isolate transport, but this may handicap DASH and inflate relative gains.
  • domain assumption The standard MoQ baseline is a faithful implementation of the current MoQ-Lite design.
    The authors modified the Rust MoQ stack; the baseline behavior (one active group, replacement on newer arrival) is asserted but not independently verified.
  • domain assumption Single-run measurements are sufficient for comparing systems.
    Fig. 13 explicitly uses one shared-topology run per system, and no variance is reported elsewhere.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming." pith.science (2026). https://pith.science/paper/LF5TULBV

@misc{pith2026260806102,
  author       = {Pith},
  title        = {Pith review of: MultiMoQ: Multi-Access Media-Over-QUIC for Robust Immersive Video Streaming},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LF5TULBV}},
  note         = {Machine review of arXiv:2608.06102}
}
read the original abstract

Live immersive video streaming, particularly 360-degree video, is increasingly adopted in applications such as virtual events, sports broadcasting, and remote education. Existing approaches struggle to support high-bitrate immersive streaming for large numbers of concurrent users, with coarse-grained delivery limiting responsiveness and insufficient support for coordinating concurrent tile streams. Media over QUIC (MoQ) has recently emerged as a promising solution for large-scale media delivery, yet it lacks robustness under bandwidth-constrained conditions, often resulting in playback stalls. To address these challenges, we present MultiMoQ, a multi-access tile streaming framework built on MoQ that redesigns its delivery mechanism for robust high-bitrate streaming across multiple access paths while supporting flexible tile scheduling and seamless access switching. We implement a fully functional prototype of MultiMoQ and evaluate it in network emulation under heterogeneous real-world network conditions, comparing against Dynamic Adaptive Streaming over HTTP (DASH) and standard MoQ. Results show that MultiMoQ increases goodput for enhancement tiles and base video and reduces enhancement-tile tail end-to-end latency relative to DASH, while preserving audio continuity and avoiding the persistent stalls of standard MoQ. These transport gains translate into smoother viewport playback, and the ablation results further confirm the contribution of multi-access control to playback continuity.

Figures

Figures reproduced from arXiv: 2608.06102 by the authors.

Figure 1
Figure 1. High-level comparison of DASH-, QUIC-, and MoQ [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Overview of Media over QUIC. Media over QUIC (MoQ) is a publish–subscribe framework for real-time media over QUIC or WebTransport [9, 17]. As [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. MoQ/DASH goodput [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (10 more)
Figure 5
Figure 5. Figure 5: MultiMoQ overview. 3.1 Overview of MultiMoQ [PITH_FULL_IMAGE:figures/full_fig_p003_5.png]
Figure 6
Figure 6. Figure 6: MoQ-Lite delivery redesign. expiration, and overflow handling never modify the active queue. A new group can therefore update the sender’s candidates without immediately aborting an in-flight group. Active transmission control. The sender scores each pending group to b…
Figure 7
Figure 7. Figure 7: Client-driven multi-access control. Stream multiplexing. Each access has its own Hang instance, but MultiMoQ exposes one logical output per media track. The stream multiplexer applies make-before-break switching: the current access continues to deliver while the altern…
Figure 8
Figure 8. Figure 8: Common four-layer topology for the MoQ and [PITH_FULL_IMAGE:figures/full_fig_p006_8.png]
Figure 9
Figure 9. Figure 9: MultiMoQ improves enhancement-tile goodput and tail delay while keeping stalls near zero. [PITH_FULL_IMAGE:figures/full_fig_p007_9.png]
Figure 10
Figure 10. Figure 10: MultiMoQ preserves audio and base-track continuity across network conditions. [PITH_FULL_IMAGE:figures/full_fig_p007_10.png]
Figure 11
Figure 11. Figure 11: Transport ablation: stall time and runtime delay. [PITH_FULL_IMAGE:figures/full_fig_p007_11.png]
Figure 13
Figure 13. Figure 13: Per-client delivery across eight tracks: minimum source-normalized mean goodput versus maximum mean latency. [PITH_FULL_IMAGE:figures/full_fig_p007_13.png]
Figure 14
Figure 14. Figure 14: MultiMoQ has the lowest freeze ratio and shortest [PITH_FULL_IMAGE:figures/full_fig_p007_14.png]
Figure 15
Figure 15. Figure 15: Access assignment and quality for 21 viewports: MultiMoQ shifts SSIM and VMAF toward higher scores. [PITH_FULL_IMAGE:figures/full_fig_p008_15.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

35 extracted references · 28 canonical work pages

  1. [1]

    Lemonia Argyriou, Daphne Economou, and Vassiliki Bouki. 2017. 360-degree interactive video application for cultural heritage education. IniLRN 2017 Coimbra!Verlag der Technischen Universität Graz, Graz, Austria, 297–304. doi:10.3217/978-3-85125-530-0-44

    work page doi:10.3217/978-3-85125-530-0-44 2017

  2. [2]

    Yanan Bao, Tianxiao Zhang, Amit Pande, Huasen Wu, and Xin Liu. 2017. Motion- Prediction-Based Multicast for 360-Degree Video Transmissions. In2017 14th Annual IEEE International Conference on Sensing, Communication, and Networking (SECON). IEEE, Piscataway, NJ, USA, 1–9. doi:10.1109/SAHCN.2017.7964928

    work page arXiv 2017

  3. [3]

    Mike Belshe, Roberto Peon, and Martin Thomson. 2015. Hypertext Transfer Protocol Version 2 (HTTP/2). RFC 7540. doi:10.17487/RFC7540

    doi:10.17487/rfc7540 2015

  4. [4]

    Xavier Corbillon, Gwendal Simon, Alisa Devlic, and Jacob Chakareski. 2017. Viewport-adaptive navigable 360-degree video delivery. In2017 IEEE International Conference on Communications (ICC). IEEE, Piscataway, NJ, USA, 1–7. doi:10. 1109/ICC.2017.7996611

    work page arXiv 2017

  5. [5]

    2026.Media over QUIC - Lite

    Luke Curley. 2026.Media over QUIC - Lite. Internet-Draft draft-lcurley-moq-lite-

    work page 2026

  6. [6]

    Work in Progress

    Internet Engineering Task Force. Work in Progress. https://datatracker.ietf. org/doc/draft-lcurley-moq-lite/03/

    work page

  7. [7]

    Yago Sanchez de la Fuente, Gurdeep Singh Bhullar, Robert Skupin, Cornelius Hellge, and Thomas Schierl. 2019. Delay impact on MPEG OMAF’s tile-based viewport-dependent 360 video streaming.IEEE Journal on Emerging and Selected Topics in Circuits and Systems9, 1 (2019), 18–28

    work page 2019

  8. [8]

    Made Harta Dwijaksara, Muhammad Hafizhuddin Hilman, Chankyun Lee, and Wonhyuk Lee. 2024. Rate adaptation technique for media streaming over quic with limited backhaul.IEEE Access12 (2024), 139028–139041

    work page 2024

Show all 35 references
  1. [9]

    Omar Eltobgy, Omar Arafa, and Mohamed Hefeeda. 2020. Mobile streaming of live 360-degree videos.IEEE Transactions on Multimedia22, 12 (2020), 3139–3152

    2020

  2. [10]

    2023.Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design

    James Gruessing and Spencer Dawkins. 2023.Media Over QUIC - Use Cases and Requirements for Media Transport Protocol Design. Internet-Draft draft- ietf-moq-requirements-02. Internet Engineering Task Force. Work in Progress. https://datatracker.ietf.org/doc/draft-ietf-moq-requir...

    2023

  3. [11]

    Miska M Hannuksela and Ye-Kui Wang. 2021. An overview of omnidirectional media format (OMAF).Proc. IEEE109, 9 (2021), 1590–1606

    2021

  4. [12]

    Liekun Hu and Changlong Li. 2025. STORM: a Multipath QUIC Scheduler for Quick Streaming Media Transport under Unstable Mobile Networks. In2025 USENIX Annual Technical Conference (USENIX ATC 25). USENIX Association, Boston, MA, 851–866. https://www.usenix.org/conference/atc25/p...

    2025

  5. [13]

    Aden Kittel, Michael Spittle, Paul Larkin, and Sharna Spittle. 2023. 360 VR: Application for exercise and sport science education.Frontiers in Sports and Active Living5 (2023), 977075

    2023

  6. [14]

    Bob Lantz, Brandon Heller, and Nick McKeown. 2010. A Network in a Laptop: Rapid Prototyping for Software-Defined Networks. InProceedings of the 9th ACM SIGCOMM Workshop on Hot Topics in Networks(Monterey, California) (HotNets-IX). Association for Computing Machinery, New York,...

    2010

  7. [15]

    Chen Li, Tingwei Ye, Tongyu Zong, Liyang Sun, Houwei Cao, and Yong Liu

  8. [16]

    Pantelis Maniotis and Nikolaos Thomos. 2021. Tile-based edge caching for 360°live video streaming.IEEE Transactions on Circuits and Systems for Video Technology31, 12 (2021), 4938–4950

    2021

  9. [17]

    Anahita Mahzari, Afshin Taghavi Nasrabadi, Aliehsan Samiei, and Ravi Prakash

  10. [18]

    Sohee Park and Samir R Das. 2024. Cross-Layer Scheduling in QUIC and Mul- tipath QUIC for 360-Degree Video Streaming. In2024 IEEE Wireless Commu- nications and Networking Conference (WCNC). IEEE, Piscataway, NJ, USA, 1–6. doi:10.1109/WCNC57260.2024.10571146

    2024

  11. [19]

    Feng Qian, Bo Han, Qingyang Xiao, and Vijay Gopalakrishnan. 2018. Flare: Practical Viewport-Adaptive 360-Degree Video Streaming for Mobile Devices. InProceedings of the 24th Annual International Conference on Mobile Computing and Networking(New Delhi, India)(MobiCom ’18). Asso...

    2018

  12. [20]

    2026.Media over QUIC Transport

    Suhas Nandakumar, Victor Vasiliev, Ian Swett, and Alan Frindell. 2026.Media over QUIC Transport. Internet-Draft draft-ietf-moq-transport-17. Internet Engineering Task Force. Work in Progress. https://datatracker.ietf.org/doc/draft-ietf-moq- transport/17/

    2026

  13. [21]

    Felipe Rosa, Simone Ferlin, Anna Brunstrom, and Bruno Kimura. 2025. End-to- End 360 Video Streaming over HTTP/3: Architecture and Implementation. In Proceedings of the 2025 Applied Networking Research Workshop. Association for Computing Machinery, New York, NY, USA, 9–16. doi:...

    2025

  14. [22]

    Rabia Shafi, Wan Shuai, and Muhammad Usman Younus. 2020. 360-Degree Video Streaming: A Survey of the State of the Art.Symmetry12, 9 (2020), 1491. doi:10.3390/sym12091491

    2020 doi

  15. [23]

    Giuseppe Ribezzo, Giuseppe Samela, Vittorio Palmisano, Luca De Cicco, and Saverio Mascolo. 2018. A DASH Video Streaming System for Immersive Contents. InProceedings of the 9th ACM Multimedia Systems Conference. Association for Computing Machinery, New York, NY, USA, 525–528. d...

    2018 doi

  16. [24]

    Thomas Stockhammer. 2011. Dynamic Adaptive Streaming over HTTP: Stan- dards and Design Principles. InProceedings of the second annual ACM conference on Multimedia systems. Association for Computing Machinery, New York, NY, USA, 133–144. doi:10.1145/1943552.1943572

    2011

  17. [25]

    Liyang Sun, Yixiang Mao, Tongyu Zong, Yong Liu, and Yao Wang. 2020. Flocking- Based Live Streaming of 360-Degree Video. InProceedings of the 11th ACM Multimedia Systems Conference. Association for Computing Machinery, New York, NY, USA, 26–37. doi:10.1145/3339825.3391856

    2020

  18. [26]

    Cong-Xi Song, Biao Han, and Jin-Shu Su. 2024. 4d-map: Multipath adaptive packet scheduling for live streaming over quic.Journal of Computer Science and Technology39, 1 (2024), 159–176

    2024

  19. [27]

    Mengbai Xiao, Chao Zhou, Viswanathan Swaminathan, Yao Liu, and Songqing Chen. 2018. BAS-360: Exploring Spatial and Temporal Adaptability in 360-degree Videos over HTTP/2. InIEEE INFOCOM 2018 - IEEE Conference on Computer Communications. IEEE, Piscataway, NJ, USA, 953–961. doi:...

    2018

  20. [28]

    Xiufeng Xie and Xinyu Zhang. 2017. POI360: Panoramic Mobile Video Telephony over LTE Cellular Networks. InProceedings of the 13th International Conference on emerging Networking EXperiments and Technologies. Association for Computing Machinery, New York, NY, USA, 336–349. doi:...

    2017

  21. [29]

    Mikko Uitto and Antti Heikkinen. 2020. Exploiting and Evaluating Live 360 Low Latency Video Streaming Using CMAF. In2020 European Conference on Networks and Communications (EuCNC). IEEE, Piscataway, NJ, USA, 276–280. doi:10.1109/EUCNC48522.2020.9200954

    2020

  22. [30]

    Shou-Cheng Yen, Ching-Ling Fan, and Cheng-Hsin Hsu. 2019. Streaming 360 Videos to Head-Mounted Virtual Reality Using DASH over QUIC Transport Protocol. InProceedings of the 24th ACM Workshop on Packet Video. Association for Computing Machinery, New York, NY, USA, 7–12. doi:10....

    2019

  23. [31]

    Xinjing Yuan, Lingjun Pu, Jianxin Shi, Qianyun Gong, and Jingdong Xu. 2022. Muster: Multi-source streaming for tile-based 360 videos within cloud native 5g networks.IEEE Transactions on Mobile Computing22, 11 (2022), 6616–6632

    2022

  24. [32]

    Abid Yaqoob, Ting Bi, and Gabriel-Miro Muntean. 2020. A survey on adaptive 360 video streaming: Solutions, challenges and opportunities.IEEE Communications Surveys & Tutorials22, 4 (2020), 2801–2838

    2020

  25. [35]

    Chao Zhou, Mengbai Xiao, and Yao Liu. 2018. ClusTile: Toward Minimiz- ing Bandwidth in 360-degree Video Streaming. InIEEE INFOCOM 2018 - IEEE Conference on Computer Communications. IEEE, Piscataway, NJ, USA, 962–970. doi:10.1109/INFOCOM.2018.8486282

    2018

  26. [2018]

    InProceedings of the 26th ACM international conference on Multimedia

    FoV-Aware Edge Caching for Adaptive 360 Video Streaming. InProceedings of the 26th ACM international conference on Multimedia. Association for Comput- ing Machinery, New York, NY, USA, 173–181. doi:10.1145/3240508.3240680

  27. [2025]

    Computer Networks269 (2025), 111461

    Coffee: Cost-effective edge caching for live 360 degree video streaming. Computer Networks269 (2025), 111461

    2025

Pith tools

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