ITTO20120901A1 - Procedimento di codifica e decodifica di un video digitale e relativi dispositivi di codifica e decodifica - Google Patents

Description

“PROCEDIMENTO DI CODIFICA E DECODIFICA DI UN VIDEO DIGITALE E RELATIVI DISPOSITIVI DI CODIFICA E DECODIFICAâ€

DESCRIZIONE

La presente invenzione si riferisce ad un procedimento di codifica e decodifica di un video digitale, in particolare ad un procedimento di codifica in partizioni indipendenti di un flusso video e al relativo procedimento di decodifica indipendente di una o più delle partizioni che compongono il flusso video. La presente invenzione, inoltre, si riferisce ad un dispositivo per la codifica di un flusso video in partizioni indipendenti e a un dispositivo per la decodifica indipendente di una o più di dette partizioni.

È noto da tempo l’uso della codifica e distribuzione di flussi video indipendenti che rappresentano viste differenti di uno stesso evento o di un mosaico di servizi multimediali (Video multivista – Free-to-View Video). La distribuzione agli utenti di tali video multivista richiede tipicamente la codifica di un numero di flussi video indipendenti corrispondente al numero delle viste generate. Un procedimento di codifica e decodifica di questo tipo viene descritto, ad esempio, nel documento “ISO/IEC 13818-1 : 2000 (E) - Information technology — Generic coding of moving pictures and associated audio information: Systems†oppure dal documento “ISO/IEC 14496-10 Information technology — Coding of audio-visual objects Part 10: Advanced Video Coding†e nel corrispondente documento “ITU-T H.264 - Advanced video coding for generic audiovisual services†, nel seguito indicati come specifica H.264/AVC.

I procedimenti di codifica attualmente in uso presentano diversi svantaggi quali: necessità di utilizzare un numero di codificatori video pari al numero di componenti video da distribuire; difficoltà nella mutua sincronizzazione dei flussi video distribuiti e dei flussi video con i relativi flussi audio; aumento nella banda necessaria al trasporto dei flussi video dovuto alla necessità di replicare elementi di segnalazione simili necessari alla decodifica di ciascuno dei flussi indipendenti.

I corrispondenti procedimenti di decodifica, invece, richiedono l’uso di una moltitudine di decodificatori per la decodifica e visualizzazione di due o più delle viste trasmesse, aumentando la complessità, e quindi il costo, dell’architettura dei terminali utilizzati dagli utenti.

Sono anche noti l’uso di un singolo flusso video per la distribuzione di molteplici viste indipendenti, come accade, ad esempio, nei cosiddetti servizi “mosaico†, in cui il singolo quadro à ̈ costituito dalla composizione in una sola immagine di n quadri estratti da video indipendenti, oppure la composizione in un singolo quadro dei due video componenti una coppia stereoscopica 3D (i cosiddetti “Frame Packing Arrangement†o “frame compatible format†). Tali video compositi vengono tipicamente compressi utilizzando una qualsiasi delle tecniche di compressione disponibili, quali, ad esempio, MPEG-2, H.264/AVC, HEVC. Tali tecniche di compressione non forniscono strumenti che permettano ad un decoder conforme alle specifiche la decodifica indipendente di uno o più dei flussi video componenti. Sono stati sviluppati metodi che permettono ad un decodificatore 2D di estrarre dal video decodificato solo una delle due viste componenti la coppia stereoscopica, ma questi metodi si basano sull’uso di opportuna segnalazione che permette al decoder, una volta decodificato l’intero quadro contenitore, di ritagliare e visualizzare l’area del quadro che contiene solo una delle due viste.

Non à ̈ attualmente possibile codificare il video in modo tale da abilitare un decodificatore (per scelta dell’utente o per limitazioni delle sue risorse computazionali o di memoria) a decodificare solo un sottoinsieme prescelto dell’intero quadro. Ad esempio, non à ̈ possibile codificare un video contenente uno dei sopra citati Frame Packing Arrangement in modo tale che un decodificatore 2D, non interessato alle due immagini componenti la coppia stereoscopica, possa decodificare e visualizzare solo la regione corrispondente a una delle due viste (ad esempio, la sinistra).

Questo comporta uno spreco di risorse computazionali ed energetiche. Si noti che questo problema à ̈ sentito in modo sempre più acuto nel campo dei terminali mobili, dove l’uso indebito di risorse computazionali può ridurre drasticamente la durata della carica delle batterie.

Inoltre, può accadere che un decoder possa essere utilizzato in un dispositivo quale un set top box o uno smart gateway al quale possono essere collegati uno o più display, non necessariamente omogenei per caratteristiche. Si consideri, ad esempio, il caso di uno smart gateway, che riceve un flusso video codificato da una rete di distribuzione (ad esempio, una rete IP o una rete di broadcasting) o che legge il flusso da un dispositivo di memorizzazione. A tale smart gateway potrebbe essere connessa, per mezzo di cavi e/o di connessioni wireless, una moltitudine di display che possono avere caratteristiche differenti (ad esempio display HD o tablet). In tale caso, il decoder dovrebbe poter adattare il video decodificato alle caratteristiche del o dei display da servire: nel caso in cui al decoder venga connesso solamente un display avente risoluzione inferiore a quella del video decodificato, il decoder dovrebbe poter decodificare solamente la parte di video più rilevante per il terminale in oggetto.

Inoltre, con le tecniche attuali à ̈ possibile identificare automaticamente solamente uno dei flussi video componenti (come nell’esempio della coppia stereoscopica di cui sopra) e non à ̈ possibile indicare esplicitamente al decodificatore la presenza degli ulteriori uno o più flussi video componenti. Al decodificatore dotato di minori risorse, quindi, viene imposta una scelta per “default†e non à ̈ possibile indicare la presenza di contenuti alternativi.

Infine, la possibilità di codificare un singolo flusso video, oltre a permettere di scalare l’uso delle risorse computazionali durante il procedimento di decodifica, permette di codificare un singolo flusso video per servire, con modelli di servizio differenti, terminali caratterizzati da disponibilità di risorse computazionali e di memoria differenti. Ad esempio, à ̈ possibile pensare di codificare in forma di singolo flusso video 4k (3840x2160 pixel) la composizione di 4 video HD (1920x1080 pixel): di tale video un decodificatore dotato di risorse computazionali limitate potrebbe decodificare un sottoinsieme contenente una sola delle componenti HD; alternativamente, un decodificatore capace di prestazioni più elevate potrebbe decodificare l’intero video 4K e, ad esempio, visualizzare l’intero mosaico di contenuti.

Scopo della presente invenzione à ̈ definire un metodo di codifica che permetta di codificare in un singolo flusso video contenitore uno o più flussi video componenti differenti, in modo che almeno uno tra questi ultimi risulti decodificabile in modo indipendente rispetto agli altri.

È altresì uno scopo della presente invenzione specificare un procedimento di decodifica che permetta di decodificare in modo indipendente uno o più flussi video componenti da un singolo flusso video contenitore utilizzando un singolo decodificatore.

È inoltre scopo della presente invenzione fornire un codificatore che codifica un flusso video contenitore composto di più flussi video componenti in modo tale da rendere possibile la decodifica indipendente di uno più flussi video componenti.

È anche scopo della presente invenzione fornire un decodificatore che decodifica in modo indipendente almeno uno di una moltitudine di flussi video componenti codificati come un singolo flusso video contenitore.

Questi e ulteriori aspetti della presente invenzione risulteranno più chiari leggendo la seguente descrizione che illustra alcune forme di attuazione con riferimento alle figure allegate, in cui:

- la Figura 1 illustra un partizionamento di un’immagine da codificare in gruppi di macroblocchi (“slice†) secondo la specifica H.264/AVC;

- la Figura 2 illustra un partizionamento di un’immagine da codificare in “tile†secondo quanto previsto dalla specifica HEVC;

- la Figura 3 illustra un esempio di composizione di quattro flussi video 2D indipendenti in un singolo flusso video;

- la Figura 4 illustra la composizione di due flussi video stereoscopici indipendenti, in forma di coppie di video 2D, in un singolo flusso video;

- la Figura 5 illustra un processo di decodifica selettiva di una delle due immagini costituenti la coppia stereoscopica codificate come singolo flusso video;

- la Figura 6 illustra una composizione di un flusso video stereoscopico e delle relative mappe di profondità in un singolo flusso video contenitore;

- la Figura 7 illustra una composizione di un flusso video 2D e di un flusso video stereoscopico in un singolo flusso video contenitore;

- la Figura 8 illustra uno schema a blocchi del processo di composizione e codifica del flusso video generato dalla composizione di n flussi video indipendenti;

- la Figura 9 illustra un esempio di procedimento di decodifica di un flusso video generato dall’apparato di codifica descritto in Figura 8;

- la Figura 10 illustra un ulteriore procedimento di decodifica di un flusso video generato da un apparato di codifica secondo la Figura 8;

- le Figure 11 e 11bis illustrano la composizione di due viste di un flusso video stereoscopico in un singolo flusso video contenitore;

- la Figura 12 illustra una tabella che descrive una struttura di una segnalazione da inserire in un flusso video codificato;

- la Figura 13 illustra una tabella con possibili valori di un parametro della struttura di Figura 12;

- le Figure 14a-14d illustrano una tabella con le modifiche necessarie alla sintassi del PPS dello standard HEVC per inserire la segnalazione di Figura 12; - le Figure 15a-15f illustrano una tabella con le modifiche necessarie alla sintassi dell’SPS dello standard HEVC per inserire la segnalazione di Figura 12.

Gli standard di codifica video già esistenti, così come quelli in via di definizione, offrono la possibilità di partizionare le immagini costituenti flussi video digitali al fine di ottimizzare i processi di codifica e decodifica. Come illustrato in Figura 1, la specifica H.264/AVC permette di raggruppare i macroblocchi nei quali vengono suddivise le immagini da codificare in differenti tipi di gruppi, chiamati slice, che vengono codificati in modo indipendente gli uni rispetto agli altri. Ad esempio, come illustrato in Figura 1 per la suddivisione chiamata “Type 2†, à ̈ possibile raggruppare i macroblocchi in slice di forma arbitraria, così da permettere di variare in modo selettivo la qualità del video codificato in funzione della posizione di eventuali “regioni di interesse†.

Nella Figura 2, invece, viene illustrato un nuovo tipo di suddivisione dell’immagine, chiamato “tile†, che viene introdotto nella specifica del nuovo standard ITU/ISO/IEC HEVC (High Efficiency Video Coding). Questo tipo di ripartizione, costruito sulla struttura delle slice già esistenti nella specifica H.264/AVC, à ̈ stato introdotto per consentire la parallelizzazione del processo di codifica e decodifica del flusso video: la vasta diffusione e l’abbassamento dei costi dei processori grafici paralleli (le cosiddette GPU, Graphics Processing Unit), disponibili ormai anche su terminali mobili quali telefoni e tablet PC, ha reso conveniente l’introduzione di strumenti di supporto alla parallelizzazione che consentono di portare formati di immagine a risoluzioni molto elevate anche su terminali con capacità computazionali tipicamente ridotte.

La specifica HEVC ha definito le tile in modo da permettere la segmentazione in regioni delle immagini costituenti il flusso video e renderne mutuamente indipendente la decodifica. Il processo di decodifica, però, anche se parallelizzato, viene realizzato sempre e solo per l’intera immagine, e non à ̈ possibile utilizzare i segmenti in modo indipendente l’uno dall’altro.

Come già anticipato nei paragrafi precedenti, sarebbe invece utile poter partizionare il flusso video in modo tale che terminali di tipo differente possano decidere, in modo automatico o in funzione di istruzioni ricevute dall’utente, quali parti del video decodificare e inviarle al display per la visualizzazione.

Le Figure 3, 4, 6 e 7 illustrano differenti scenari d’uso in cui questo tipo di partizionamento potrebbe essere utile.

La Figura 3 illustra un flusso video contenitore che, ad esempio, potrebbe avere il formato 4K (3840x2160 pixel) e contenere quattro video HD (1920x1080 pixel) indipendenti tra loro. Un utente dotato di un decoder 4K potrebbe decodificare e visualizzare l’intero video mentre, invece, un utente dotato di un decoder dalle capacità computazionali più ridotte, potrebbe limitarsi alla decodifica di un singolo flusso HD per volta.

La Figura 4 illustra il trasporto in un singolo flusso video contenitore di due flussi video stereoscopici (in forma di due coppie indipendenti di video Left e Right), ad esempio, rappresentanti due viste stereoscopiche differenti di uno stesso evento tra le quali l’utente può scegliere la visualizzazione preferita senza dover necessariamente decodificare l’intero quadro (con le ovvie implicazioni in termini di risparmio energetico).

La Figura 5 illustra la composizione di un video stereoscopico e delle relative mappe di profondità in un singolo flusso video. In questo caso, un decoder di un televisore stereoscopico potrebbe decodificare solamente la parte relativa alle due immagini della coppia stereoscopica, sita nella metà superiore dell’immagine; la parte inferiore non verrebbe decodificata. Invece, un decoder di un televisore autostereoscopico utilizzante la ben nota tecnica 2D+Z (costruzione delle viste sintetiche da una singola immagine più la relativa mappa di profondità) potrebbe, ad esempio, decodificare solo la metà di sinistra dell’immagine, mentre il decoder di un televisore autostereoscopico più sofisticato potrebbe utilizzare le due viste e le due mappe di profondità per la sintesi delle viste intermedie.

La Figura 7 illustra la composizione di un video 2D a risoluzione doppia (destinato, ad esempio, ad un display in formato 21:9) situato nella metà superiore dell’immagine e della corrispondente vista stereoscopica in formato side by side nella regione inferiore.

La struttura delle tile descritta nella specifica HEVC non à ̈ sufficiente per permettere a un decoder di riconoscere e decodificare in modo proprio il contenuto trasportato dal video contenitore. Tale problema può essere risolto inserendo un opportuno livello di segnalazione che descrive quale contenuto viene trasportato in ciascuna delle regioni decodificabili in modo indipendente e come procedere per la decodifica e visualizzazione corrette.

Si possono prevedere almeno due scenari differenti. Nel primo, à ̈ necessario indicare l’associazione di almeno una delle tile nelle quali l’immagine à ̈ stata scomposta con i singoli contenuti e la relativa eventuale ricomposizione in un flusso video coerente (ad esempio, come illustrato in Figura 11, un flusso video stereoscopico potrebbe essere suddiviso in due tile e, mentre un decoder 2D deve essere informato della possibilità di decodificare una tile singola, un decoder 3D potrebbe non adottare alcuna strategia specifica e decodificare l’intero flusso). Nel secondo, invece, si indica l’associazione di ciascuna delle tile nelle quali l’immagine à ̈ stata scomposta con i singoli contenuti e la relativa eventuale ricomposizione in un flusso video coerente (ad esempio, un flusso video stereoscopico potrebbe essere suddiviso in due tile e, mentre un decoder 2D deve essere informato della possibilità di decodificare una tile singola, un decoder 3D deve essere informato della necessità di decodificare l’intero flusso). La soluzione proposta prevede l’inserimento di un descrittore che indichi, per almeno una delle tile, una o più caratteristiche specifiche: ad esempio, dev’essere possibile segnalare se il contenuto à ̈ 2D o, nel caso sia stereoscopico, il tipo di frame packing arrangement. Inoltre, à ̈ desiderabile indicare eventuali “relazioni†(decodifica e/o visualizzazione congiunta) tra le tiles; l’identificativo della vista (da usare, ad esempio, nel caso di contenuto multiview) e un messaggio che identifichi se la vista in oggetto à ̈ la vista destra o sinistra di una coppia stereoscopica oppure una mappa di profondità.

A solo titolo di esempio, la soluzione viene illustrata nella tabella di Figura 12 in forma di pseudocodice, che descrive la struttura della segnalazione da inserire nel flusso video codificato utilizzando le strutture dati già impiegate nelle specifiche H.264/AVC e HEVC. È comunque possibile adottare analoghe strutture di segnalazione, che permettano di descrivere il contenuto di una o più tile in modo tale da permettere a un decoder di decodificarle in modo opportuno.

Frame_packing_arrangement_type à ̈ un indice che potrebbe corrispondere, ad esempio, ai valori comunemente utilizzati nelle specifiche MPEG2, H.264/AVC, o SMPTE e che catalogano i formati attualmente noti e usati dei formati video stereoscopici.

Tile_content_relationship_bitmask à ̈ una bitmask che descrive in modo univoco per ciascuna delle tile la relativa associazione alle altre tile nelle quali il flusso video codificato à ̈ stato suddiviso.

Content_interpretation_type fornisce le informazioni necessarie per interpretare il contenuto di ogni tile. Un esempio à ̈ specificato nella tabella di Figura 13. Con riferimento al caso precedente, in cui un video stereoscopico viene codificato in forma di due tiles, al fine di garantire la decodifica di una sola delle viste da parte di un decoder 2D, alla tile 0 verrebbero associate le seguenti informazioni

o frame_packing_arrangement_type[0] = 3

o tile_content_relationship_bitmask[0] = 11

o view_id[0] = 0

o content_interpretation_type[0] = 2

Si noti che questo tipo di segnalazione potrebbe essere utilizzata insieme o in sostituzione di altri strumenti, quali, ad esempio, il cropping rectangle. La tecnica del cropping rectangle, che prevede il cropping obbligatorio della parte del quadro decodificato interna ad un rettangolo segnalato per mezzo di opportuni metadati, viene già comunemente utilizzata per rendere “3D compatible†un flusso video stereoscopico avente la forma di uno dei frame packing arrangement che prevedono l’inserimento della coppia stereoscopica all’interno di un singolo quadro. La Figura 11bis, illustra, ad esempio, un quadro contenente il codiddetto frame packing arrangement “side-by-side†, in cui la sola vista sinistra (quella grigia in figura) à ̈ contenuta nel cropping rectangle. Senza il partizionamento in tiles, un decoder 2D dovrebbe decodificare l’intero quadro e poi applicare il cropping, scartando la vista destra (in bianco in Figura 11bis). Utilizzando il metodo dell’invenzione, invece, à ̈ possibile codificare e segnalare le due viste come tile separate, permettendo ad un decoder 2D di decodificare la sola area contenuta all’interno del cropping rectangle.

Supposto, ad esempio, che il flusso video sia stato diviso in quattro tile, come illustrato in Figura 4, la reazione tra le tile verrebbe descritta dai seguenti valori:

o frame_packing_arrangement_type[0] = 3

o frame_packing_arrangement_type[1] = 3

o frame_packing_arrangement_type[2] = 3

o frame_packing_arrangement_type[3] = 3

o tile_content_relationship_bitmask[0] = 1100

o tile_content_relationship_bitmask[1] = 1100

o tile_content_relationship_bitmask[2] = 0011

o tile_content_relationship_bitmask[3] = 0011

o view_id[0] = 0

o view_id[1] = 0

o view_id[2] = 1

o view_id[3] = 1

o content_interpretation_type[0] = 2

o content_interpretation_type[1] = 1

o content_interpretation_type[2] = 2

o content_interpretation_type[3] = 1

Con questa segnalazione si sta indicando al decoder che le tile 0 e 1 fanno parte dello stesso contenuto video 3D (tile_content_relationship_bitmask = 1100) in side by side (frame_packing_arrangement_type = 3). Il valore di tile_content_relationship_bitmask permette al decoder di sapere che le due viste (che fanno parte della stessa coppia stereoscopica in quanto per entrambe le tile view_id = 0) sono contenute in tile differenti (e quindi, in questo caso, a piena risoluzione). Content_interpretation_type permette di capire che la tile 0 corrisponde alla vista sinistra mentre la tile 1 corrisponde alla vista destra.

Le stesse considerazioni valgono per le tile 1 e 2.

La disposizione di Figura 6, invece, viene descritta dalla seguente segnalazione: o frame_packing_arrangement_type[0] = 3

o frame_packing_arrangement_type[1] = 3

o frame_packing_arrangement_type[2] = 6

o frame_packing_arrangement_type[3] = 6

o tile_content_relationship_bitmask[0] = 1111

o tile_content_relationship_bitmask[1] = 1111

o tile_content_relationship_bitmask[2] = 1010

o tile_content_relationship_bitmask[3] = 0101

o view_id[0] = 1

o view_id[1] = 1

o content_interpretation_type[0] = 2

o content_interpretation_type[1] = 1

o content_interpretation_type[2] = 5

o content_interpretation_type[3] = 5

A differenza di Figura 4, tile_content_relationship_bitmask à ̈ 1111 per le tile 0 e 1. Questo significa che esiste una relazione tra tutte le tiles. In particolare le tile 2 e 3 sono dei contenuti 2D (frame_packing_arrangement_type = 6) che contegono una mappa di profondità (content_interpretation_type = 5) associata rispettivamente alla tile 0 (tile_content_relationship_bitmask = 1010) e alla tile 1 (tile_content_relationship_bitmask = 0101)

Nella sintassi della specifica HEVC questo tipo di segnalazione potrebbe facilmente essere codificato come messaggio di tipo SEI (Supplemental Enhancement Information): informazione di tipo applicativo che, senza alterare i meccanismi di base di codifica e decodifica, permette la costruzione di funzioni aggiuntive e relative non solo alla decodifica ma anche al successivo processo di visualizzazione. In alternativa, la stessa segnalazione potrebbe essere inserita all'interno del Picture Parameter Set (PPS), un elemento di sintassi che contiene le informazioni necessarie per la decodifica di un insieme di dati corrispondenti ad un quadro. Evidenziate in neretto, all'interno della tabella di Figure 14a-14d si possono vedere in forma di pseudocodice le modifiche necessarie alla sintassi del PPS dello standard HEVC per inserire la segnalazione citata in precedenza.

Una ulteriore generalizzazione potrebbe prevedere l'inserimento della segnalazione all'interno del Sequence Parameter Set (SPS): un elemento di sintassi che contiene le informazioni necessarie per la decodifica di un insieme di dati corrispondenti ad una sequenza consecutiva di quadri.

Evidenziate in neretto, all'interno della tabella di Figure 15a-15f si possono vedere in forma di pseudocodice le modifiche necessarie alla sintassi del SPS di HEVC per inserire la segnalazione citata in precedenza, in cui multiservice_flag à ̈ una variabile che informa sulla presenza di più servizi all'interno di ogni tile e num_tile à ̈ il numero di tiles all'interno di un quadro.

In Figura 5, viene illustrato il procedimento di decodifica selettiva delle tiles. Il flusso video contiene una coppia di viste stereoscopiche, codificate in due tile separate.

Queste sono descritte dalla stessa segnalazione che si usa per rappresentare il contenuto di Figura 4 (in questo caso però il numero totale di tile à ̈ 2).

La Figura 8 illustra un diagramma a blocchi di un apparato o un gruppo di apparati che possono realizzare la tecnica di codifica della presente invenzione. N contributi video S1– SNvengono inviati in ingresso a un “source composer†. Il “source composer†potrebbe essere un componente a sé stante oppure essere integrato come stadio di ingresso di un opportuno encoder. Il source composer compone il flusso video contenitore che trasporta gli N flussi video componenti e lo invia in uscita verso un encoder. Il source composer può, opzionalmente, aggiungere la segnalazione necessaria a descrivere all’encoder il formato dei flussi video componenti e la relativa posizione all’interno del flusso video contenitore.

Un encoder riceve il flusso video contenitore, costruisce le tile in modo da mapparle sulla struttura dei singoli flussi video componenti, genera la segnalazione descrittiva delle tiles, della struttura dei flussi video componenti e delle relative relazioni e comprime il flusso video contenitore. Nel caso in cui il “source composer †non generi in modo automatico la segnalazione descrittiva dei flussi video componenti, l’encoder può essere programmato in modo manuale dall’operatore. Il flusso video compresso in uscita dall’encoder può quindi essere decodificato in modi differenti, cioà ̈ selezionando parti indipendenti in funzione delle caratteristiche funzionali e/o di risorse computazionali del decoder e/o del display a cui questo à ̈ collegato. L’audio relativo ad ogni flusso video componente può essere trasportato in accordo a quanto specificato dalla parte System Layer adottata per il trasporto.

Un decoder 2D analizza il bitstream, trova la segnalazione delle due tile contenenti le due viste e decide di decodificare una singola tile, visualizzando solo un’immagine compatibile con un display 2D. Un decoder 3D, invece, decodifica le due tile e procede alla visualizzazione stereoscopica su un display 3D.

Analogamente, la Figura 9 illustra un decoder che, quando collegato al display, negozia le caratteristiche (ad esempio la risoluzione) del video da visualizzare e decide autonomamente in modo conseguente quale parte del flusso video decodificare. Tale decisione potrebbe anche essere dettata dall’intervento manuale di un utente: ad esempio, nel caso in cui il video trasmesso sia un video stereoscopico codificato in due tile, supponendo che l’utente, pur dotato di un televisore 3D, abbia deciso di fruire ugualmente del contenuto in 2D (tale decisione potrebbe manifestarsi come pressione di un opportuno pulsante del telecomando), il decoder potrebbe adottare una strategia di decodifica differente da quella che avrebbe adottato per pura scelta automatica basata sulla negoziazione del formato di visualizzazione migliore con il televisore. La Figura 10, invece, illustra il caso in cui il decoder sia situato all’interno di un gateway che riceve il flusso codificato e debba servire terminali eterogenei, caratterizzati dalla possibilità di supportare formati differenti del contenuto video (ad esempio, alcuni dispositivi potrebbero avere la capacità di visualizzare contenuti stereoscopici mentre, allo stesso tempo, altri potrebbero avere il solo display 2D). Il gateway negozia in modo automatico o riceve istruzioni di configurazione da ciascuno dei dispositivi e decodifica una o più parti del contenuto in ingresso così da adattarle alle caratteristiche di ciascuno dei dispositivi richiedenti.

Quindi la presente invenzione riguarda un metodo per generare un flusso video a partire da una pluralità di sequenze di frame video 2D e/o 3D, in cui un generatore di flusso video compone in un frame video contenitore frame video provenienti da N sorgenti diverse S1, S2, S3, SN. Successivamente un codificatore codifica l’unico flusso video in uscita di frame video contenitori inserendo in esso una segnalazione atta ad indicare la struttura dei frame video contenitori. L’invenzione riguarda anche un metodo per rigenerare un flusso video comprendente una sequenza di frame contenitori, ciascuno di essi comprendendo una pluralità di frame video 2D e/o 3D provenienti da N sorgenti diverse S1, S2, S3, SN. Un decodificatore legge una segnalazione atta ad indicare la struttura dei frame video contenitori, e rigenera una pluralità di flussi video estraendo almeno uno o un sottoinsieme della pluralità di frame video decodificando esclusivamente le porzioni dei frame video contenitori comprendenti i frame video della pluralità di frame video 2D e/o 3D dei flussi video che sono stati selezionati per la visualizzazione.

Claims (22)

1. RIVENDICAZIONI 1. Procedimento di codifica di un flusso video digitale costituito da una o più regioni componenti indipendenti, comprendente il passo di inserire una segnalazione indicante la presenza di una o più regioni decodificabili in modo indipendente, caratterizzato dal fatto che il procedimento di codifica comprende l’ulteriore passo di inserire una segnalazione indicante l’associazione tra le una o più regioni componenti e le una o più regioni decodificabili in modo indipendente.
2. 2. Procedimento di codifica di un flusso video digitale secondo la rivendicazione 1, comprendente inoltre il passo di inserire un descrittore indicante il tipo di contenuto di dette una o più regioni componenti.
3. 3. Procedimento di codifica secondo la rivendicazione 1 o 2, in cui ciascuna delle regioni decodificabili in modo indipendente viene codificata in forma di tile.
4. 4. Procedimento di codifica secondo una delle rivendicazioni 1 e 2, in cui la tecnica di codifica utilizzata à ̈ H.264/AVC o HEVC.
5. 5. Procedimento di codifica secondo una qualsiasi delle rivendicazioni precedenti, in cui la segnalazione dell’associazione tra le una o più regioni componenti e le una o più regioni decodificabili in modo indipendente e il descrittore indicante il tipo di contenuto delle una o più regioni componenti à ̈ un messaggio SEI.
6. 6. Procedimento di codifica secondo una qualsiasi delle rivendicazioni 1 a 3, in cui il segnale indicante l’associazione tra le una o più regioni componenti e le una o più regioni decodificabili in modo indipendente e il descrittore indicante il tipo di contenuto delle una o più regioni componenti à ̈ inserito nella segnalazione SPS o nella segnalazione PPS.
7. 7. Procedimento di codifica secondo una qualsiasi delle rivendicazioni precedenti, in cui il segnale indicante l’associazione tra le una o più regioni componenti e le una o più regioni decodificabili in modo indipendente à ̈ costituito da una bitmask.
8. 8. Procedimento di codifica secondo una qualsiasi delle rivendicazioni precedenti, in cui le una o più regioni componenti il flusso video digitale rappresentano uno o più flussi video indipendenti.
9. 9. Procedimento di codifica secondo la rivendicazione 8 in cui i flussi video indipendenti comprendono uno o più dei seguenti formati: − una o più coppie video stereoscopiche; − flussi video e mappe di profondità; − uno o più flussi video in formato di frame packing arrangement; − mosaico di video indipendenti.
10. 10. Procedimento di codifica secondo la rivendicazione 2, in cui il descrittore comprende uno o più metadati che descrivono − Frame packing arrangement; − Content interpretation type; − View ID.
11. 11. Procedimento di decodifica di un flusso video digitale costituito da una o più regioni componenti indipendenti, comprendente il passo di leggere un segnale indicante la presenza di una o più regioni decodificabili in modo indipendente, comprendente inoltre almeno uno tra i seguenti passi: − leggere una segnalazione indicante l’associazione tra le una o più regioni componenti e le una o più regioni decodificabili in modo indipendente − leggere un descrittore indicante il tipo di contenuto di ciascuna delle una o più regioni decodificabili in modo indipendente e comprendente l’ulteriore passo di − selezionare per la decodifica una o più delle regioni decodificabili in modo indipendente indicate da detta segnalazione o detto descrittore.
12. 12. Procedimento di decodifica secondo la rivendicazione 11, in cui il decodificatore seleziona una o più delle regioni decodificabili in modo indipendente in base a una valutazione delle proprie risorse computazionali.
13. 13. Procedimento di decodifica secondo la rivendicazione 11, in cui le una o più regioni decodificate vengono rese disponibili per la visualizzazione su un singolo display.
14. 14. Procedimento di decodifica secondo la rivendicazione 11, in cui le una o più regioni decodificate vengono rese disponibili per la visualizzazione su una moltitudine di dispositivi eterogenei.
15. 15. Procedimento di decodifica secondo una qualsiasi delle rivendicazioni da 11 a 14, in cui la selezione per la decodifica delle una o più delle regioni decodificabili in modo indipendente viene determinata da un segnale di controllo esterno.
16. 16. Procedimento per la decodifica secondo la rivendicazione 15, in cui il segnale di controllo viene generato automaticamente come risultato del processo di negoziazione del formato di visualizzazione con uno o più display.
17. 17. Procedimento per la decodifica secondo la rivendicazione 15, in cui il segnale di controllo viene generato come risultato del processo di selezione manuale del formato di visualizzazione da parte di un utente.
18. 18. Dispositivo generatore di flusso video digitale costituito da una o più regioni componenti indipendenti comprendente un source composer per la composizione in un singolo flusso video di una moltitudine di flussi video componenti e un codificatore video che implementa il procedimento di codifica di una qualsiasi delle rivendicazioni 1 a 10.
19. 19. Dispositivo generatore secondo la rivendicazione 18, in cui il source composer e/o il codificatore video sono realizzati in forma di componenti di programmazione.
20. 20. Dispositivo decodificatore comprendente mezzi di lettura e di selezione atti a effettuare un procedimento di decodifica secondo una qualsiasi delle rivendicazioni da 11 a 14.
21. 21. Dispositivo elaboratore di flussi video che comprende un dispositivo decodificatore secondo la rivendicazione 20, caratterizzato dal fatto che comprende ulteriori mezzi atti a selezionare in modo automatico o manuale per la visualizzazione una o più delle regioni decodificate in modo indipendente.
22. 22. Smart gateway che comprende un decoder secondo la rivendicazione 21, caratterizzato dal fatto che comprende ulteriori mezzi di selezione atti a selezionare per mezzo di un opportuno procedimento di negoziazione il formato di visualizzazione di una o più delle regioni decodificate in modo indipendente.