12.5. Video Telephony or Streaming with FUs and Forward Error Correction (Telefonia video o streaming con FU e FEC)

12.5. Video Telephony or Streaming with FUs and Forward Error Correction (Telefonia video o streaming con FU e correzione d'errore in avanti (Forward Error Correction, FEC))

Questo schema è stato implementato ed è stato dimostrato che fornisce buone prestazioni, soprattutto a tassi di perdita di pacchetti più elevati [19].

Il mezzo più efficiente per combattere le perdite di pacchetti negli scenari in cui le ritrasmissioni non sono applicabili è la correzione d'errore in avanti (FEC). Sebbene l'uso end-to-end a livello applicazione della FEC sia spesso meno efficiente di una protezione basata su FEC dei singoli collegamenti (soprattutto quando nel percorso di trasmissione vi sono collegamenti con caratteristiche diverse), la FEC end-to-end a livello applicazione è inevitabile in alcuni scenari. La RFC 5109 [18] fornisce mezzi per usare FEC generica end-to-end a livello applicazione in ambienti con perdita di pacchetti. Un codice correttore d'errore binario è generato applicando l'operazione XOR ai bit nella stessa posizione bit in pacchetti diversi. Il codice binario può essere specificato dai parametri (n,k), in cui k è il numero di pacchetti di informazione usati nella connessione e n è il numero totale di pacchetti generati per k pacchetti di informazione; cioè vengono generati n-k pacchetti di parità per k pacchetti di informazione.

Quando un codice è usato con parametri (n,k) nell'ambito della RFC 5109, le seguenti proprietà sono ben note:

a) Se applicato su un solo pacchetto RTP, la RFC 5109 fornisce solo ripetizione di pacchetti.

b) La RFC 5109 è più efficiente in bitrate se i pacchetti collegati da XOR hanno uguale lunghezza.

c) Alla stessa probabilità di perdita di pacchetti p e per un k fisso, maggiore è n, minore diventa la probabilità d'errore residua. Ad esempio, per una probabilità di perdita del 10%, k=1 e n=2, la probabilità d'errore residua è circa l'1%, mentre per n=3 è circa lo 0,1%.

d) Alla stessa probabilità di perdita p e per un tasso di codice fisso k/n, maggiore è n, minore diventa la probabilità d'errore residua. Ad esempio, a probabilità di perdita p=10%, k=1 e n=2, il tasso d'errore residuo è circa l'1%, mentre per un codice di Golay esteso con k=12 e n=24 è circa lo 0,01%.

Per applicare la RFC 5109 in combinazione con video codificato in baseline H.264 senza usare le FU (Fragmentation Units), si possono considerare diverse opzioni:

1. L'encoder video produce unità NAL per cui ogni fotogramma video è codificato in un singolo slice. Applicando la FEC, si potrebbe usare un codice semplice, ad es. (n=2, k=1). Cioè ogni unità NAL sarebbe sostanzialmente solo ripetuta. Lo svantaggio è ovviamente la scarsa prestazione del codice secondo d) sopra e la bassa flessibilità, poiché si possono usare solo codici (n, k=1).

2. L'encoder video produce unità NAL per cui ogni fotogramma è codificato in uno o più slice consecutivi. Applicando la FEC, si potrebbe usare un codice migliore, ad es. (n=24, k=12), su una sequenza di unità NAL. A seconda del numero di pacchetti RTP per fotogramma, una perdita può introdurre un ritardo significativo, ridotto quando si usano più pacchetti RTP per fotogramma. Anche pacchetti di lunghezze completamente diverse possono essere collegati, il che diminuisce l'efficienza in bitrate secondo b) sopra. Tuttavia, con attenzione e per slice di 1 kB o più, si può produrre lunghezza simile (differenza 100-200 byte), che non abbassa catastroficamente l'efficienza in bit.

3. L'encoder video produce unità NAL per cui un certo fotogramma contiene k slice di lunghezza quasi uguale. Allora, applicando la FEC, si può usare un codice migliore, ad es. (n=24, k=12), sulla sequenza di unità NAL per ogni fotogramma. Il ritardo rispetto a 2) sopra può ridursi, ma diversi svantaggi sono evidenti. Primo, l'efficienza di codifica del video codificato è ridotta sensibilmente, poiché la codifica strutturata in slice riduce la predizione intra-fotogramma e serve overhead di slice aggiuntivo. Secondo, il contenuto pre-codificato o, operando tramite gateway, il video di solito non è codificato appropriatamente con k slice affinché la FEC sia applicabile. Infine, la codifica di video che produce k slice di uguale lunghezza non è immediata e può richiedere più di una passata di codifica.

Molti degli svantaggi menzionati possono essere evitati applicando le FU in combinazione con la FEC. Ogni unità NAL può essere suddivisa in un numero qualsiasi di FU di lunghezza sostanzialmente uguale; pertanto la FEC, con k e n ragionevoli, può essere applicata anche se l'encoder non ha cercato di produrre slice di uguale lunghezza. Ad esempio, un'unità NAL di slice codificato contenente un intero fotogramma può essere suddivisa in k FU, e si può applicare un codice di controllo di parità (n=k+1, k). Tuttavia, ciò ha lo svantaggio che, a meno che tutti i frammenti creati non possano essere recuperati, l'intero slice sarà perso. Quindi si perde una sezione maggiore che se il fotogramma fosse stato suddiviso in più slice.

La tecnica presentata rende possibile ottenere buona tolleranza agli errori di trasmissione anche in assenza di ridondanza aggiuntiva a livello di codifica sorgente (come fotogrammi intra periodici). Di conseguenza, la stessa sequenza video codificata può essere usata per raggiungere la massima efficienza di compressione e qualità su trasmissione priva d'errore e su reti soggette a errori. Inoltre, la tecnica consente l'applicazione della FEC a sequenze pre-codificate senza aggiungere ritardo. In questo caso, sequenze pre-codificate non codificate per reti soggette a errori possono ancora essere trasmesse quasi in modo affidabile senza ritardi estensivi. Inoltre, FU di uguale lunghezza comportano un uso efficiente in bitrate della RFC 5109.

Se la probabilità d'errore dipende dalla lunghezza del pacchetto trasmesso (ad es. in caso di trasmissione mobile [15]), i benefici dell'applicazione di FU con FEC sono ancora più evidenti. In sostanza, la flessibilità della dimensione delle FU consente di applicare FEC appropriata per ogni unità NAL e protezione d'errore disuguale delle unità NAL.

Quando si usano FU e FEC, l'overhead sostenuto è sostanziale ma è dello stesso ordine di grandezza del numero di bit che devono essere spesi per macroblocchi codificati in intra se non si applica FEC. In [19] è stato mostrato che le prestazioni complessive dell'approccio basato su FEC miglioravano la qualità usando lo stesso tasso d'errore e lo stesso bitrate complessivo, incluso l'overhead.