Riassunto di uno studio che propone una soluzione per la riduzione di banda nella trasmissione di video a 360°.

1. Un sistema di video streaming per contenuti immersivi
e riduzione della banda richiesta
1. INTRODUZIONE
Lo streaming dei video a 360° è una tecnologia entrata prepotentemente nel mercato e sulla
scena di diverse piattaforme. Le sfide che questi nuovi servizi devono affrontare sono
molteplici, tra cui:
• standardizzazione di un nuovo formato video
• progettazione di algoritmi di controllo per la scelta del bitrate
• progettazione di nuove tecniche di compressione adatte ai video a 360°
In particolare, l’ultima sfida è particolarmente complessa, dato che è stato mostrato che
uno streaming a 360° richiederebbe una banda di circa 400 Mbps per avere una
qualità simile a un video 2D in FullHD.
Sono stati proposti diversi approcci con lo scopo di ridurre il bitrate richiesto: la
caratteristica comune di queste tecniche è che solo una porzione di video viene
scaricata dal client, cioè quella presente nel suo attuale campo visivo e
denominata Region of Interest (ROI).
Per esempio, per consegnare un video la cui porzione visiva abbia una risoluzione di 1080p,
significa che la risoluzione del video, nella sua interezza, debba essere più grande di 6480p,
cioè una risoluzione più grande dell’8K. Codificare una risoluzione così grande richiederebbe
un bitrate elevatissimo e, di conseguenza, l’utilizzo di una banda eccessiva.
Con questo spirito, la tecnica di slicing divide il video in un certo numero di porzioni,
dette slice, che vengono codificate e memorizzate separatamente e in diversi
bitstream. Il problema di questo approccio è che una ROI potrebbe richiedere diversi slice,
ciascuna richiedente un preciso processo di decodifica al client, rendendo questa soluzione
poco adatta ai sistemi mobile. Un’altra problematica è che il client deve scaricare in
parallelo gli slice che compongono la ROI, il che rende l’algoritmo di streaming
adattivo più complesso.
Un altro interessante approccio è la tecnica di tiling; il video viene spazialmente diviso
in porzioni dette tile, ciascuna codificata indipendentemente e possibilmente
memorizzata con un singolo bitstream. In questo modo il client seleziona un

2. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
sottoinsieme di tile e un singolo processo è capace di decodificare il bitstream compresso
precedentemente. Lo svantaggio di questo approccio è che la rappresentazione può solo
variare il bitrate ma la risoluzione di ogni tile resta costante.
L’efficienza (in termini di bitrate richiesto per ottenere la stessa qualità) è inversamente
proporzionale al numero di tile.
Qui viene presentato un sistema DASH che permette la riduzione di banda, è indipendente
dall’encoder ed è compatibile con la maggioranza delle tecnologie già presenti.

3. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
2. IL SISTEMA PROPOSTO
Lo standard oggigiorno utilizzato è MPEG Dynamic Adptive Streaming over HTTP
(MPEG-DASH) che permette al client di adattare dinamicamente il bitrate del
video a seconda della banda di rete disponibile. Il video è memorizzato su un server
http e il client lo richiede avviano una connessione http.
Il video viene codificato a differenti livelli di bitrate, che formano il set di livelli
video 𝐿𝐿 = {𝑙𝑙1 … 𝑙𝑙 𝑀𝑀}. Ogni livello è logicamente, o fisicamente, diviso in segmenti di
durata costante. Sul client, un algoritmo di controllo seleziona il livello di video da
mostrare e ne esegue il download.
La generazione del contenuto nel caso di video omni-direzionali, invece, differisce
significativamente da quella classica adottata per video 2D. In particolare, le camere a
360° catturano un’immagine sferica, che necessita di essere proiettata su un
piano bidimensionale, affinchè possa essere codificata. Questo rende il concetto di
ROI ancora più importante.
L’architettura generale del sistema proposto è molto simile e si compone di:
• un generatore di contenuti video
• un player installato sul client che gestisce la logica di controllo e il rendering del
video ricevuto
• un server HTTP che fornisce il contenuto video
Il significato di ogni componente viene spiegato di seguito.

4. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
VIDEO CONTENT GENERATION
Si considera l’originale scena non compressa prodotta in formato Equirectangular
Projection (ERP)1
.
Il video originale viene manipolato in modo da creare 𝑁𝑁 diverse viste
𝑣𝑣𝑖𝑖, una per ogni ROI considerata e il cui set costituisce il view set
𝑉𝑉 = {𝑣𝑣1 … 𝑣𝑣𝑁𝑁}. Viene assunto che ciascuna ROI sia una lunula
sferica2
con un angolo diedro3
di 120° (cioè il campo visivo di
un uomo) centrati a un particolare angolo 𝛼𝛼𝑖𝑖. Le regioni al di
fuori della ROI, quella sinistra (L)
e quella destra (R), sono divise in
due lunule sferiche con stesso angolo
diedro.
Ciascuna lunula sferica viene, conseguentemente,
mappata in una striscia verticale in formato ERP.
Il video in formato ERP è manipolato in modo che la ROI sia sempre piazzata al centro.
In questo modo, diventa possibile ridurre le porzioni di video fuori dalla ROI (e quindi
fuori dal campo visivo), in modo da ridurre il bitrate di encoding.
Di seguito, un esempio concreto:
1
È la stessa tecnica utilizzata per le carte geografiche, dove i meridiani corrispondono a linee verticali e i paralleli a
linee orizzontali
2
Insieme di punti del piano compresi tra due semicirconferenze aventi gli estremi in comune e situate dalla stessa
parte rispetto alla retta passante per tali estremi
3
Angolo compreso tra due piani

5. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
Si è preferito utilizzare lunule sferiche perché strategie più complesse potrebbe
introdurre inefficienze nelle operazioni, portando a richiedere maggiore banda. Inoltre, si è
scelto di mantenere la ROI al centro del frame per sfruttare al meglio
l’algoritmo di compensazione motoria, mantenendo la continuità tra l’area compressa
e l’area non compressa. Infine, si è scelto il procedimento di downscaling4
perché è
supportato da tecnologia già esistente, può essere facilmente gestito dagli encoder del client
e può essere effettuato con algoritmo già comprovati.
Ora, dunque, ciascuna delle 𝑁𝑁 view 𝑣𝑣𝑖𝑖 ∈ 𝑉𝑉 è codificata in M video a differenti bitrate 𝑙𝑙𝑗𝑗,
costituendo il set di livelli video 𝐿𝐿 = {𝑙𝑙1 … 𝑙𝑙 𝑀𝑀}. Al termine della procedura, si ha un set di
rappresentazioni 𝑅𝑅 = 𝑉𝑉 𝑥𝑥 𝐿𝐿, composto da NM file memorizzati nel server.
IL CLIENT
Il client implementa sia la logica di controllo necessaria a selezionare
dinamicamente quale segmento di video scaricare, sia le funzionalità di decoding
e rendering.
La logica di controllo si compone di due componenti cooperanti:
• un View Selection Algorithm – VSA che sceglie dinamicamente la migliore
rappresentazione 𝑣𝑣(𝑡𝑡) ∈ 𝑉𝑉 in base ai dati ricevuti dall’accelerometro
• un Quality Selection Algorithm – QSA che sceglie dinamicamente il livello
del video 𝑙𝑙(𝑡𝑡) ∈ 𝐿𝐿 in modo da evitare rebuffering e massimizzare l’utilizzo del canale
di rete
Il VSA ha il compito di scegliere la miglior rappresentazione basandosi sulla posizione della
testa dell’utente. In particolare, assumiamo che attualmente l’utente stia guardando
la vista 𝑣𝑣1 ∈ 𝑉𝑉 corrispondente alla ROI centrata nell’angolo 𝛼𝛼1 e che ora giri la testa
di un certo angolo 𝛼𝛼. Per seguire questo movimento e mantenere la qualità della visione,
l’algoritmo attiva uno switch verso una rappresentazione 𝑣𝑣𝑖𝑖 ∈ 𝑉𝑉 la cui ROI è centrata
a un angolo 𝛼𝛼𝑖𝑖 che abbia la minima distanza da 𝛼𝛼.
Il QSA non necessita di scaricare in parallelo diverse view (il che richiederebbe diversi buffer
da gestire): questa peculiarità lo rende, già in partenza, più efficiente di altre strategie
presenti. Si consideri il caso in cui il VSA abbia effettuato lo switch tra la view 𝑣𝑣𝐴𝐴 e la view
𝑣𝑣𝐵𝐵. A questo istante, il buffer contiene un certo numero di segmenti della prima
view 𝑣𝑣𝐴𝐴. Per non intaccare la qualità dell’esperienza, è necessario drenare la coda del
4
Procedimento di riduzione dell’informazione da una ad alta risoluzione ad una a bassa risoluzione

6. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
buffer dai secondi della prima view 𝑣𝑣𝐴𝐴: la funzionalità del QSA è quella di
implementare un algoritmo che calcoli il corretto numero di secondi da scartare dalla coda
del buffer. Da questo punto in poi, lo switch è completo e il downloader provvederà a
scaricare i segmenti di 𝑣𝑣𝐵𝐵 al livello 𝑙𝑙(𝑡𝑡) calcolato dal QSA.

7. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
3. DEMO SETUP
Si è implementata una demo della precedente trattazione utilizzando FFMPEG, in modo
che la soluzione ottenuta possa essere utilizzata sia per video on-demand che per
streaming real-time.
Si è utilizzato un video in 4K (3840 x 2048) a 30 fps; ciascuna striscia verticale (L, ROI,
R) ha una risoluzione iniziale di 1280 x 2048. Il fattore di downscaling è dato dalla
formula:
𝑑𝑑 =
2𝑤𝑤𝑑𝑑 + 𝑤𝑤𝑅𝑅𝑅𝑅𝑅𝑅
𝑤𝑤
dove 𝑤𝑤𝑑𝑑 è la larghezza delle regioni L e R, mentre 𝑤𝑤𝑅𝑅𝑅𝑅𝑅𝑅 è la larghezza della ROI. Con un
valore 𝑤𝑤 = 3840px, si ha 𝑤𝑤𝑅𝑅𝑂𝑂𝐼𝐼 = 𝑤𝑤
3� = 1280px. Si lascia che 𝑤𝑤𝑑𝑑 possa variare nel set
{240px, 480px, 720px, 1080px}. I video downscaled sono stati codificati in FFMPEG H264
con un Constant Rate Factor (CRF)5
pari a 20.
Sono stati considerati due scenari differenti:
• lo scenario CRF, dove i parametri di codifica sono stati mantenuti costanti, allo
scopo di mostrare l’impatto del
meccanismo proposto sulla qualità
generale del video; lo pseudocodice è di
seguito a fianco: sostanzialmente, per
ogni video e considerato un certo
fattore di downscaling, la procedura
produce le versioni downscaled dei
video; SSIM e PSNR sono misure del
bitrate medio e della stima della qualità
video
• lo scenario Average Bitrate (ABR), dove i parametri di codifica sono stati
settati per mantenere costante il bitrate, allo scopo di esplorare la relazione tra il
downscaling e la qualità video; il codice è lo stesso del precedente, cambia soltanto
l’encoder utilizzato
Alla fine del primo scenario, è stato calcolato il fattore medio di riduzione del bitrate:
𝑟𝑟𝑑𝑑� = 𝐸𝐸�𝑟𝑟𝑑𝑑
(𝑖𝑖)
�
5
Parametro di qualità della codifica, per quanto riguarda gli encoder H264 e H265. È un valore che varia tra 0 e 51,
tanto è più basso, tanto è migliore la codifica, in quanto valori più alti indicano un più elevato grado di compressione.

8. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
Nello scenario ABR, sono stati impiegati tali fattori 𝑟𝑟𝑑𝑑� per calcolare, per ogni view 𝑖𝑖, un
bitrate target medio:
𝑏𝑏�
𝑑𝑑
(𝑖𝑖)
= (1 − 𝑟𝑟𝑑𝑑� )𝑏𝑏0
(𝑖𝑖)
RISULTATI
Per quanto riguarda lo scenario CRF, la figura mostra che la qualità del video è
massima al centro e poi decresce man mano che aumenta la distanza angolare
dal centro. Inoltre, come ci si aspettava, la pendenza delle curve della qualità video
è più ripida quando il fattore di downscaling aumenta. Ciò significa che, con un
fattore più alto la qualità video diminuisce più velocemente quando l’utente di sposta dal
centro della ROI.
La tabella riporta, in percentuale, la riduzione media del bitrate 𝑟𝑟𝑑𝑑� misurata per ogni
fattore di downscaling. I risultati mostrano che l’approccio proposto è promettente e
fornisce una riduzione di banda circa lineare con il fattore di downscaling.
Per quanto riguarda lo scenario ABR, la figura mostra che portare l’encoder in
modalità “bitrate medio” produce una transizione più morbida tra la ROI e le
regioni laterali. In particolare, si è misurato una perdita massima della qualità video di
4dB per il PSNR e di 0.005 per il SSIM. Questo risultato indica che questo schema agisce in
modo soddisfacente anche quando l’encoder lavora con questo scenario.

9. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
DASH MANIFEST
Si consideri la seguente porzione di codice:
Gli elementi Viewpoint sono intesi come i diversi punti di vista delle camere puntanti
sulla stessa scena. Gli attributi sono:
• camera_id: identifica la sorgente video
• video_type: distingue video panoramici (adaptive_pano), video non scalati
(panoramic) e video in 2D (regular)
• rotations: una lista ordinata degli angoli di rotazione, espressi in gradi, di tutti i
punti di vista
• viewpoint_id: l’indice del punto di vista delle precedenti rotazioni
• width: larghezza del video scalato
• side_width: larghezza della parte scalata del video
IL PLAYER
Il player è stato sviluppato usando esclusivamente tecnologie web standardizzate in modo
che possa essere supportato dalla maggior parte dei browser moderni. La sessione di
streaming è gestita a una versione modificata di Shaka Player, a cui sono state aggiunte
due funzionalità:

10. Video streaming per contenuti immersivi| Ribezzo, Samela, Palmisano, De Cicco, Mascolo Tandoi Antonio
• analisi del file mpd per estrarre informazioni riguardanti i Viewpoint
• possibilità di eliminare una certa durata di video dal buffer come dichiarato nella
sezione precedente
Inoltre, è stato aggiunto un modulo chiamato abr-manager, che si occupa delle decisioni
prese dall’algoritmo di controllo del video streaming. Questo modulo implementa la
logica del QSA e del VSA.
VIDEO RENDERING
Il rendering del video in formato ERP ricevuto è stato implementato usando WebGL e la
libreria open-source THREE.js.
Per quanto riguarda la grafica 3D, un oggetto 3D si compone di due parti: la maglia,
che modella le proprietà fisiche come i vertici, gli spigoli e le facce, e la texture, che è una
composizione di più immagini che, applicate alle facce, danno la sensazione di realismo. La
fase di rendering, dunque, include la mappatura dei vertici della maglia verso
specifici punti della texture. Dato che l’approccio proposto effettua il downscale delle
aree fuori la ROI, si sfrutta il processo per riportarle poi alla risoluzione originale
(rescaling).
È comunque importante sottolineare che l’operazione di rescaling non comporta un
costo computazionale aggiuntivo, comparato al solito rendering adottato per
rimappare il video ERP.