ITTO20090485A1 - "procedimento e sistema per la distribuzione di contenuti informativi, relativo prodotto informatico" - Google Patents

Description

DESCRIZIONE dell’invenzione industriale dal titolo:

“Procedimento e sistema per la distribuzione di contenuti informativi, relativo prodotto informaticoâ€

TESTO DELLA DESCRIZIONE

Campo dell’invenzione

La presente descrizione si riferisce alle tecniche per la distribuzione di contenuti informativi o “mediali†.

Il lavoro che ha condotto alla presente descrizione à ̈ stato finanziato nell’ambito del programma comunitario European Community’s Seventh Framework Programme FP7/2007-2013 in accordo al Grant Agreement n. 216217.

La descrizione à ̈ stata messa a punto prestando attenzione alla possibile applicazione ai sistemi per la distribuzione di contenuti mediali quali contenuti video in un contesto Peer-to-Peer (P2P).

Descrizione della tecnica relativa

I sistemi P2P sono diventati molto popolari anche grazie ai programmi di file sharing: Napster, BitTorrent, Gnutella, Kazaa e diversi altri. In particolare la soluzione Kazaa si basa sul criterio di sfruttare la potenza computazionale e la disponibilità di risorse in sistemi P2P per sviluppare uno dei client di maggior successo per i sistemi VoIP (Voice over IP: Skype). Skype à ̈ liberamente scaricabile ed ha cambiato le modalità di comunicazione fra le persone, conseguendo un notevole successo commerciale proprio perché il client di Skype non richiede alcuna infrastruttura dedicata e fa invece affidamento su un insieme di supernodi che sono comuni Peer disponibili on line con una buona larghezza di banda ed un indirizzo IP pubblico. L’ipotesi di creare qualcosa di simile per quanto riguarda i contenuti video à ̈ attraente, ma richiede di tenere in conto il fatto che il traffico vocale non richiede una larghezza di banda così ampia come lo streaming video: in pratica la larghezza di banda del traffico vocale à ̈ di almeno due ordini di grandezza inferiore rispetto a quella del traffico video, se si disattiva la webcam durante la chiamata.

Qualunque applicazione P2P, tanto di tipo file sharing quanto di tipo streaming, si basa sulla infrastruttura sviluppata da diversi utilizzatori organizzati in sovrapposizione (overlay). I sistemi P2P creano la rete e gestiscono la distribuzione dei contenuti a livello applicativo. La sovrapposizione può essere creata e gestita in modi che dipendono dalla natura dell’applicazione.

In generale, i contenuti sono suddivisi in spezzoni (correntemente denominati chunk) e poi ri-assemblati sul lato cliente nell’ordine giusto. Nel caso di file sharing l’intero file à ̈ scaricato e riprodotto off-line, senza alcuna limitazione in termini di larghezza di banda o ritardo temporale. Al contrario, le applicazioni di streaming del tipo “Video On Demand†richiedono di avviare la riproduzione mentre il file à ̈ ancora in corso di scaricamento, con la necessità di soddisfare vincoli in termini di larghezza di banda e di tempo. Le stesse considerazioni valgono anche per lo streaming dal vivo (“live streaming†), dove tuttavia i Peer non condividono l’intero contenuto ma soltanto un piccolo buffer di dati.

Il settore del video streaming P2P à ̈ al momento oggetto di notevole attività di ricerca, con l’obiettivo di ottimizzare tre fattori importanti, ossia:

- i) il tempo che trascorre da quando l’utilizzatore si “sintonizza†sul canale ed il momento in cui il contenuto video à ̈ disponibile (cosiddetto start-up delay), - ii) il ritardo fra la sorgente del contenuto e il ricevitore (noto anche come playback delay o end-to-end delay), e

- iii) il conteggio dei frame resi nell’ordine giusto dal riproduttore (cosiddetto “playback continuity index†).

La maggior parte dei sistemi considerati in questo contesto possono essere classificati sulla base del grafo di distribuzione che implementano e possono essere grossolanamente classificati come sistemi ad albero (tree) e come sistemi a maglie (mesh), mentre esiste anche un certo numero di soluzioni ibride.

Nei sistemi di distribuzioni ad albero possiamo immaginare un vero e proprio albero i cui nodi e foglie rappresentano i peer destinatari della distribuzione del contenuto, a partire dalla sorgente dei contenuti. Se i Peer non cambiano in modo troppo frequente, la configurazione dell’albero non subira’ modifiche. Un tale sistema non richiede un grosso overhead, in quanto i pacchetti possono essere distribuiti gerarchicamente da nodo a nodo senza necessità di messaggi addizionali.

Le sovrapposizioni di tipo mesh implementano un grafo di distribuzione a maglie (di cui la denominazione “mesh†), dove ciascun nodo contatta un sottoinsieme di Peer per ottenere un certo numero di chunk. Ciascun nodo ha necessità di sapere quali chunk sono disponibili presso i suoi Peer e richiede in modo esplicito i chunk di cui ha bisogno. Questo modo di operare genera di necessità dell’overhead, in parte per lo scambio delle mappe di buffer fra i vari nodi (in pratica i nodi rendono noto l’insieme di chunk disponibile presso di loro) e in parte per il processo di richiesta o “pull†(ciascun nodo invia una richiesta al fine di ricevere i chunk che gli servono). Grazie al fatto che, per ritrovare i contenuti che gli servono, ciascun nodo può fare affidamento su Peer multipli, i sistemi di tipo mesh offrono una notevole resistenza nei confronti dei guasti (failure) dei nodi. Come aspetto negativo, i sistemi mesh richiedono buffer piuttosto grandi per supportare il processo di richiesta (pull). L’esigenza di buffer grandi à ̈ dettata dalla volontà di migliorare la possibilità di trovare i chunk mancanti nella sequenza di riproduzione.

Fra questi schemi si può inoltre citare CoopNet (descritto da V. Padmanabhan et al. in “Supporting Heterogenity and Congestion Control in P2P Multicast Streaming†, IPTPS 2004), oppure ChunkySpread (descritto da V. Venkataraman et al. in “ChunkySpread: Heterogeneous Unstructured Tree-based Peer-to-Peer Multicast†, in IEEE ICNP, 2006) che mirano a mitigare la forte dipendenza di un Peer rispetto ai suoi antenati nelle architetture basate su un singolo albero. Questi schemi sono, per l’appunto, progettati in modo da operare con tecniche avanzate di codifica video. Ad esempio, CoopNet utilizza una codifica a descrizioni multiple (Multiple Description Coding o MDC) che codifica uno stream mediale in più descrizioni indipendenti multiple. Costruisce alberi multicast indipendenti multipli, uno per ciascun sotto-stream. Un Peer può migliorare la sua qualità in termini di ricezione di media entrando a far parte di più alberi multicast con il limite rappresentato dalla sua capacità di collegamento in downlink.

Questi schemi ibridi (che mescolano in certo modo la filosofia ad albero o tree con quella a maglie o mash) mirano ad ottenere le migliori prestazioni di due approcci: robustezza nei confronti di un elevato “churn rate†(tipica delle reti mesh) ed una migliore efficienza in termini di overhead di traffico (tipica delle reti ad albero) tramite una distribuzione più ordinata delle richieste.

Queste famiglie di protocolli di streaming P2P si adattano concettualmente al concetto di ordinare il video in più strati o livelli (layer) o descrizioni. L’impiego all’interno di uno stesso client di entrambi gli approcci, cioà ̈ di schemi ad alberi multipli a livello di rete e della codifica a video stratificata a livelli (Layered Video Coding) a livello di applicazione, à ̈ in grado di produrre una notevole ottimizzazione di tipo cross-layer con risultati migliori rispetto a tutti gli altri approcci.

Secondo il paradigma della codifica video stratificata o a livelli (Layered Video Coding, o in breve LVC), un bitstream compresso contiene diverse rappresentazioni di un segnale video di ingresso. Le rappresentazioni normalmente differiscono fra loro in termini di risoluzione spaziale e/o temporale e/o di qualità (ad es. rapporto segnale/rumore) e sono ottenute tramite filtraggio spaziale e/o temporale della sequenza a video di ingresso e tramite una diversa modulazione dei passi di quantizzazione durante il processo di codifica.

Le rappresentazioni possono essere codificate separatamente (secondo l’approccio correntemente definito codifica a descrizioni multiple o Multiple Description Coding-MDC) oppure essere codificate in modo congiunto (secondo l’approccio denominato codifica video gerarchica o Hierarchical Video Coding ovvero HVC). Adottando l’approccio MDC, diverse rappresentazioni della sequenza video di ingresso, ottenute normalmente tramite filtraggio temporale e/o spaziale del segnale video di ingresso, sono codificate separatamente, multiplexate e poi trasmesse o memorizzate così come illustrato nella figura 1a.

In tale figura il riferimento OV indica il segnale video originale, il riferimento MDF indica l’operazione di filtraggio che dà origine alle diverse rappresentazioni MD1, MD2,… che, almeno in linea di principio, possono essere in numero qualsiasi. Le diverse rappresentazioni MD1, MD2, … sono destinate ad essere codificate separatamente in rispettivi moduli di codifica COD1, COD2, … per poi dare origine al bitstream d’uscita per effetto di un’operazione di multiplazione effettuata in un modulo MUX.

Per quanto riguarda la decodifica, le rappresentazioni ricevute possono essere combinate in modo da ottenere una singola rappresentazione con un livello di fedeltà, riferito al segnale originale, che dipende dal numero di rappresentazioni ricevute decodificate. Il vantaggio di questo approccio sta nella robustezza nei confronti degli errori di trasmissione: se uno dei livelli (layer) va perduto parzialmente o completamente, tutti gli altri livelli continuano ad essere decodificabili.

Nell’approccio HVC, rappresentazioni diverse della sequenza video di ingresso, ottenute ad esempio tramite filtraggio temporale e/o spaziale del segnale video di ingresso, sono codificate in modo congiunto come gerarchia di livelli multiplexati e poi trasmessi o memorizzati così come illustrato nella figura 1b.

In tale figura, OV indica ancora una volta il segnale video originale mentre DS indica un filtro ad esempio di sottocampionamento (downsampling) che permette di originare un livello di base (livello zero) BL destinato ad essere codificato in un codificatore. I livelli e rappresentazioni superiori sono anch’essi codificati da un rispettivo codificatore. Oltre che al segnale originale OV, tali codificatori attingono anche ai livelli inferiori tramite un meccanismo di predizione genericamente rappresentato da un blocco PRED. Anche in questo caso le varie rappresentazioni codificate nei codificatori COD1, COD2, … sono poi sottoposte ad un’operazione di multiplexaggio MUX per generare il bitstream di uscita.

Così come nel caso dell’approccio MDC rappresentato nella figura 1a, anche l’approccio HVC rappresentato nella figura 1b si presta ad essere attuato ricorrendo ad un numero in linea di principio qualsiasi di rappresentazioni concatenate fra loro da un meccanismo gerarchico.

La rappresentazione di due soli livelli fornita nelle due parti della figura 1 ha quindi carattere di rappresentazione semplificata di base.

Nell’approccio HVC, la gerarchia dei livelli à ̈ organizzata in modo tale per cui ciascun livello richiede, per essere decodificato, i livelli inferiori ma non quelli superiori. Rispetto all’approccio MDC, l’approccio HVC fornisce una maggiore efficienza di compressione in quanto ciascun livello superiore viene codificato utilizzando la ridondanza intrinseca esistente fra le diverse rappresentazioni. Come inconveniente, l’approccio HVC à ̈ meno resistente nei confronti di errori di trasmissione, in quanto, se un livello della gerarchia va perduto, tutti i livelli superiori che dipendono dal livello perduto non sono più decodificabili.

Tanto l’approccio MDC quanto l’approccio HVC permettono di conseguire una generale scalabilità del bitstream d’uscita, una caratteristica desiderata in diverse applicazioni di codifica video.

Con riferimento alla figura 2, un bitstream video SBS ottenuto da un segnale originario OV à ̈ detto scalabile in quanto presenta la caratteristica di poter essere decodificato in modo parziale così da ottenere, ad esempio, un segnale SS presentante una risoluzione spaziale ridotta, un segnale TS presentante una risoluzione temporale ridotta e/o un segnale QS presentante una qualità ridotta rispetto al segnale originario. Per risoluzione spaziale, qualità, ovvero risoluzione temporale “ridotta†si intendono livelli di risoluzione e qualità inferiori rispetto a quelli ottenibili decodificando l’intero bitstream.

La caratteristica di scalabilità consente di realizzare una manipolazione di bassa complessità di un bitstream che può così essere adattato a specifiche condizioni di rete (ad esempio limitazioni in termini di banda passante di canale complessiva, oppure variazioni istantanee di tale larghezza di banda) e/o alle specifiche caratteristiche di un terminale (ad esempio in termini di capacità computazionale, di esigenze di assorbimento di potenza e/o caratteristiche dello schermo di visualizzazione).

Un paradigma di codifica tradizionale a singolo livello, in cui un bitstream contiene una singola rappresentazione, così come rappresentato nella figura 3a, prevede che un segnale video di ingresso OV sia sottoposto a codifica in un codificatore COD per dare origine ad un bitstream BS contenente una singola rappresentazione del segnale OV con una risoluzione spaziale data, una risoluzione temporale data ed una qualità data – tutte definite nel processo di codifica – destinate ad essere riprodotte nel modo più fedele possibile con il processo di decodifica attuato in un decodificare DEC per dare origine a una sequenza di uscita OS.

Un codificatore video LCOD di tipo stratificato, a livelli, ossia layered, così come rappresentato nella figura 3b produce invece, a partire dal segnale video originario OV, un bitstream scalabile SBS da cui, tramite un modulo estrattore EXT operante in funzione di parametri di configurazione CP à ̈ possibile dare origine a più sottoflussi o sub-stream, SS1 …., SSN diversi fra loro, decodificabili in un decodificatore di tipo layered LDEC così da dare origine ad una corrispondente pluralità di sequenze d’uscita OS1, …., OSN ciascuna corrispondente ad una delle rappresentazioni disponibili nel bistream scalabile SBS.

Entrambi gli approcci MDC e HVC sono praticabili in base allo standard ITU-T/MPEG scalable video coding (SVC), che estende lo standard di codifica H.264/AVC con strumenti di codifica video progettati per supportare la scalabilità con buone prestazioni di efficienza di compressione. L’approccio MDC può essere anche implementato multiplexando diversi bitstream singolarmente conformi a standard di codifica a livello singolo (single-layer) quali MPEG-2, MPEG-4, VC-1 e H.264/AVC.

La figura 4 Ã ̈ uno schema a blocchi rappresentativo di una possibile struttura di codificatore SVC.

Nel caso specifico rappresentato si fa riferimento ad una codifica che prevede la generazione di un livello base (o livello 0) BL e di due livelli superiori EL1 e EL2 costituenti livelli di “miglioramento†(enhancement layer). Ancora una volta, la struttura rappresentata nella figura 4 à ̈ estendibile ad un numero K qualsiasi di livelli superiori EL1, …, ELK.

Nel caso dell’esempio rappresentato della figura 4, il livello di base BL à ̈ ottenuto dal segnale video di ingresso OV, sottoposto a due operazioni di decimazione 2D in cascata per poi essere sottoposto a decomposizione temporale TD, a codifica del movimento e della tessitura (motion/texture coding) MTC e ad una codifica entropica ECOD.

Il livello EL1 Ã ̈ ottenuto partendo dal risultato della prima operazione di decimazione 2D e sottoposto alle stesse operazioni di trattamento TD, MTC ed ECOD viste in precedenza.

Il tutto con la differenza data dal fatto che l’operazione di codifica MTC del livello EL1 tiene in conto i risultati di un’operazione di predizione PRED a partire dai risultati della elaborazione MTC del livello BL.

Il livello EL2 à ̈ ottenuto direttamente dal segnale video originale OV e anch’esso sottoposto alle operazioni di trattamento TD, MTC ed ECOD viste in precedenza.

Nel caso del livello EL2 l’operazione di codifica MTC tiene in conto i risultati di un’operazione di predizione PRED a partire dai risultati della omologa operazione di codifica MTC attuata per il livello EL1.

Nello schema della figura 4, il livello base BL può essere completamente conforme alle specifiche H.264/AVC. Gli strati superiori EL1, EL2 (ed eventualmente altri) possono seguire il paradigma HVC sfruttando appunto strumenti di codifica predittiva fra i livelli (interlayer) per migliorare l’efficienza di codifica.

Lo stesso schema della figura 4 può però essere attuato anche senza utilizzare la predizione fra livelli (ossia eliminando i blocchi PRED), seguendo l’approccio MDC.

Alla fine del processo di codifica entropica ECOD, ciascuna immagine di ciascun livello risulta codificata in uno o più pacchetti dati, denominati NALU (Network Abstraction Layer Unit) sottoposti ad un’operazione di multiplexaggio in un modulo MUX così da dare origine al bitstream finale scalabile SBS la cui struttura à ̈ rappresentata schematicamente nella figura 5.

Ciascun NALU comprende una fetta o slice, corrispondente ad un insieme di macroblocchi (ad esempio quadrati di 16x16 pixel) appartenenti alla stessa immagine.

Nella figura 5 il campo SEI rappresenta un campo dove à ̈ presente un messaggio che convoglia informazioni sulla scalabilità del bistream SBS. Vari campi SPS (uno per ciascun livello o layer) contengono poi informazioni. Sono poi presenti dei campi PPS, almeno uno per ciascun campo SPS in cui sono presenti informazioni.

I pacchetti di dati SPS (Sequence Parameter Set) e PPS (Picture Parameter Set) contengono alcuni parametri necessari per decodificare il bistream, come ad esempio le dimensioni delle immagini (larghezza e altezza in pixel) o il tipo di codifica entropica utilizzata, o altro ancora. Tali parametri vengono raccolti in pacchetti di dati appositi anziche’ essere trasmessi immagine per immagine, al fine di ottenere una maggiore efficienza di codifica.

Ciascun NALU comprende a sua volta un header H con campi SI che specificano il livello temporale, spaziale e di qualità dei dati di immagine contenuti nel carico utile o payload corrispondente. In particolare, il payload à ̈ configurato come Raw Byte Sequence Payload con un header della slice SH ed i relativi dati di slice SD riferiti ai singoli macroblocchi MB. L’azione di scalamento del bitstream SBS può quindi essere attuata semplicemente tralasciando dal bitstream SBS tutti i NALU corrispondenti a rappresentazioni che non sono utilizzate mantenendo invece tutti i NALU utili.

La figura 6 si riferisce ad un esempio in cui sono presenti diverse rappresentazioni video codificate in modo gerarchico in livelli, in cui ciascun livello fornisce un miglioramento in termini di risoluzione spaziale, risoluzione temporale o qualità rispetto al livello precedente o inferiore. Nello specifico esempio rappresentato à ̈ previsto un livello di base o Layer 0 e quattro livelli di miglioramento da Layer 1 a Layer 4. Accanto alla designazione di ciascun livello sono specificati i corrispondenti parametri di risoluzione e di qualità. Le frecce verticali nella figura 6 rappresentano la dipendenza fra livelli. Ad esempio, per decodificare il livello 2 (ossia considerando il livello 2 come livello obiettivo o “target layer†) à ̈ possibile tralasciare dallo stream tutti i NALU dei livelli 3 e 4. I livelli 1 e 2 devono essere invece tenuti intatti: il livello obiettivo (che nell’esempio considerato à ̈ il livello 2) dipende dal livello 1, a sua volta dipendente dal livello 0.

Si può poi ancora distinguere fra immagini che forniscono punti ad accesso casuale (Random-Access Points RAP) al Bitstream ed immagini che non hanno questa capacità. Si definisce come immagine RAP una immagine che, insieme a tutte le immagini successive, può essere decodificata in modo indipendente da qualunque altra immagine precedente. La decodifica video può quindi cominciare in qualunque punto corrispondente a un’immagine RAP: questo à ̈ un fatto da tenere in conto nel caso di browsing video oppure di uno streaming video in tempo reale, ad esempio per passare da un canale all’altro.

Nel caso di un video scalabile, le immagini RAP sono anche utili per fornire punti di commutazione fra un livello ed un altro, così come rappresentato nella figura 7. Qui, i blocchi rappresentati a tratti corrispondono ad immagini che non sono visualizzate, mentre i blocchi in linea piena rappresentano immagini completamente decodificate e visualizzate. Le frecce curve a tratto sottile rappresentano la predizione moto-compensata da un’immagine all’altra mentre le frecce più grandi rappresentano la commutazione fra un livello e un altro livello.

Le immagini RAP si possono quindi usare per commutare la decodifica video e la visualizzazione da un livello base BL ad un livello superiore o Enhancement Layer EL (così rappresentato nella figura 7a) oppure, in modo equivalente, per commutare in verso opposto da un livello EL al livello base BL (vedere la figura 7b).

Negli standard H.264/AVC e SVC, i punti di accesso casuale sono forniti da immagini IDR (Intra Decoder Refresh).

Un altro standard di codifica video a più livelli in grado di fornire rappresentazioni multiple à ̈ la estensione Multi-View Coding (MVC) dello standard H.264/AVC, che permette di codificare congiuntamente diverse “viste†degli stessi soggetti ottenuti tramite una schiera di camere diverse, in modo che ciascuna vista rappresenti la stessa scena osservata però secondo una visuale diversa. L’estensione MVC permette di codificare le viste diverse come un insieme di livelli di un bitstream globale, con un concetto quindi simile a quello dello standard SVC. Le applicazioni dell’estensione MVC sono la televisione a 3D e la televisione a punto di vista libero (Free View-Point television o FTV).

Gli inventori hanno notato l’evidente vantaggio commerciale suscettibile di derivare dall’offrire all’utilizzatore finale la possibilità di scegliere la qualità dei contenuti multimediali ricevuti sulla base delle sue preferenze ed esigenze. Questo in particolare in un contesto di tipo P2P, quale un ambiente P2P ad alberi multipli eterogeneo che ospita una piattaforma streaming scalabile e considerando il fatto che un approccio tradizionale di tipo simulcast (vedere ad esempio US-A-4 255 814) offre all’utente la possibilità di commutare da un livello qualitativo ad un altro, ma prevedendo la diffusione simultanea dello stesso contenuto video con livelli di qualità diversi.

Al riguardo, gli inventori hanno notato che le tecniche di codifica a più livelli presentano vantaggi in termini di larghezza di banda e di efficienza complessiva di sistema e che un documento come il documento US 2007/0112811 A1 descrive un generico sistema di codifica video P2P progettato per trasmettere contenuti mediali di tipo scalabile.

Questo documento suggerisce di assemblare unità di codifica minima in pacchetti per trasmetterli, senza però fornire ad esempio, una descrizione compiuta di un’interfaccia effettiva fra il motore P2P e il codificatore/decodificatore video. Gli inventori hanno altresì notato l’importanza del meccanismo di trasposizione dei contenuti mediali codificati in chunk P2P. Questo per evitare rilevanti inefficienze, suscettibili di portare a sprechi della larghezza di banda complessiva di rete, tali da impedire di fatto a più clienti di accedere in modo efficiente alle rappresentazioni desiderate contenute negli stream video e/o di commutare in modo adattativo da una rappresentazione all’altra. In particolare gli Inventori hanno notato che il documento sopra citato non descrive criteri tali da permettere ai Peer di scambiarsi segnali di controllo, la natura di tali segnali e l’effetto che tali segnali possono avere sul processo di pacchettizzazione.

È parimenti noto dal lavoro di J. Rieckh, “Scalable Video for Peer-to-Peer Streaming†, Master Thesis, Institute of Communications and Radio-Frequency Engineering, Technical University of Vienna, estate 2008 (al momento del deposito della presente domanda disponibile su Internet come http://publik.tuwien.ac.at/files/PubDat_166631.pdf) un sistema scalabile P2P sperimentale in grado di integrare il software JSVM (ossia il modello di software di riferimento per lo standard SVC sviluppato dal comitato JVT) con una piattaforma P2P denominata Pulsar. Gli inventori hanno notato che questo sistema si riferisce a un caso molto specifico in cui una piattaforma P2P nota à ̈ utilizzata per scambiare contenuti mediali scalabili codificati in modo specifico con lo standard SVC utilizzando un criterio di scalabilità SVC di tipo medium-grain (MGS).

Scopo e sintesi dell’invenzione

In vista del panorama della tecnica relativa delineato in precedenza, emerge l’esigenza di disporre di soluzioni che permettano di diffondere contenuti mediali in un contesto P2P in modo funzionale ed efficiente, superando gli inconvenienti intrinseci delle soluzioni delineate in precedenza.

Scopo della presente invenzione à ̈ di fornire una risposta a tale esigenza.

Secondo la presente invenzione, tale scopo à ̈ raggiunto grazie ad un procedimento avente le caratteristiche richiamate in modo specifico nelle rivendicazioni che seguono. L’invenzione si riferisce anche a corrispondenti sistemi e ad un prodotto informatico, caricabile nella memoria di almeno un elaboratore e comprendente parti di codice software suscettibili di realizzare le fasi del procedimento quando il prodotto à ̈ eseguito su almeno un elaboratore. Così come qui utilizzato, il riferimento ad un tal prodotto informatico à ̈ inteso essere equivalente al riferimento ad un mezzo leggibile da elaboratore contenente istruzioni per il controllo del sistema di elaborazione per coordinare l’attuazione del procedimento secondo l'invenzione. Il riferimento ad "almeno ad un elaboratore" à ̈ evidentemente inteso a mettere in luce la possibilità che la presente invenzione sia attuata in forma modulare e/o distribuita.

Le rivendicazioni formano parte integrante dell’insegnamento tecnico qui somministrato in relazione all’invenzione.

Una forma di attuazione identifica un’architettura di sistema per la distribuzione di bitstream video scalabili in ambienti Peer-to-Peer (P2P).

Una forma di attuazione comprende un’architettura di terminale completa, mezzi per interfacciare una rete P2P con codificatori/decodificatori video scalabili, e/o un meccanismo di adattamento per l’allocazione di banda ottimale fra i Peer.

Una forma di attuazione prevede modalità per assemblare i pacchetti video in funzione delle rappresentazioni video cui appartengono.

Una forma di attuazione fornisce criteri per condividere questa informazione fra più livelli e/o relativa a come i Peer possono effettivamente accedere a e scegliere diverse rappresentazioni di codifica video, anche in funzione delle relazioni esistenti fra i livelli video.

In una forma di attuazione, in funzione del tipo di codifica a livelli (MDC o HVC, ad esempio SVC), Ã ̈ possibile ottenere diversi tipi di vantaggi nella distribuzione di contenuti streaming. La codifica SVC comporta vantaggi a livello di rete, mentre la tecnica MDC presenta vantaggi in termini di applicazione e, in una certa misura, a livello di rete. Nel caso della codifica SVC si conseguono vantaggi a livello di cooperazione fra Peer.

In una forma di attuazione che utilizza una codifica di tipo MDC, un vantaggio conseguibile à ̈ rappresentato dalla resistenza nei confronti di chunk perduti ed in termini di flessibilità dell’assegnazione delle descrizioni. La resistenza nei confronti delle perdite à ̈ un aspetto importante ed una misura delle prestazioni dei sistemi streaming. Nel caso in cui le descrizioni siano ottenute mediante filtraggio spaziale, il fatto di disporre di descrizioni multiple offre la possibilità di distribuire l’informazione di pixel spazialmente vicini su sub-stream destinati ad essere instradati su cammini diversi ed ad essere condivisi in sotto-sovrapposizioni (sub-overlay) diverse. Quando il client perde un chunk di una descrizione, l’effetto sul lato dell’utente terminale à ̈ un’immagine in cui i pixel mancanti sono uniformemente distribuiti su tutta l’immagine, piuttosto che essere concentrati in un’unica regione dell’immagine stessa, il che rende estremamente più facile la correzione dell’errore. Questo vantaggio naturalmente si paga con una perdita in efficienza di compressione, in quanto le descrizioni sono generalmente molto ridondanti, e quindi il bit-rate complessivo a parità di qualità e’ considerevolmente maggiore del caso a singola descrizione. Oltre a questo, una forma di attuazione basata sulla codifica MDC rende il sistema più flessibile a livello di rete. In effetti, i sotto-strati (sub-overlay) possono essere riconfigurati per rendere la distribuzione dei contenuti sulla rete più efficienti in termini di distribuzione dei carichi di lavoro, ottimizzazione dell’instradamento o in relazione alla congestione di rete. Dal momento che la codifica MDC non à ̈ codificata su livelli gerarchici, i Peer possono passare da un sub-overlay ad un altro e percepire ancora la stessa qualità dello stream, essendo questa soltanto funzione del numero delle diverse descrizioni ricevute. Se l’utilizzatore terminale richiede una qualità corrispondente a due descrizioni, al client à ̈ sufficiente ritrovare soltanto due qualsiasi dei sub-stream disponibili per ottenere la qualità richiesta.

Altri vantaggi sono osservabili a livello di rete nel caso in cui un Peer si disconnetta (oppure cambi canale) o in caso di congestione di rete. Se un Peer al bordo della sovrapposizione non à ̈ più servito da un certo link (ad esempio a causa di un guasto o di un fenomeno di congestione), il Peer stesso può cambiare la sua richiesta della descrizione e migrare ad un altro sub-overlay, mantenendo la stessa qualità dello stream originario.

In una forma di attuazione, la soluzione qui descritta fornisce una rete in sovrapposizione di tipo Peer-to-Peer dedicata alla distribuzione di segnali video codificati in modo stratificato o a livelli (Layered Video Coding).

In una forma di attuazione, a differenza di quanto avviene nel paradigma di codifica video tradizionale, in cui un bitstream compresso contiene una singola rappresentazione di un segnale video, la codifica a strati offre rappresentazioni multiple nell’ambito di un bitstream scalabile.

In una forma di attuazione, tali rappresentazioni possono essere codificate in modo congiunto con una codifica di tipo gerarchico, in modo che la decodifica di ciascun livello (inteso in generale come un sottoinsieme qualsiasi dei dati video completi) si basa anche su uno o più livelli inferiori nella gerarchia dello strema.

In una forma di attuazione, la codifica può essere indipendente per cui ciascun livello nello stream à ̈ decodificabile in modo indipendente.

In una forma di attuazione, la codifica video a strati fornisce una scalabilità del segnale video, con vantaggi in molte applicazioni di video digitale, consentendo un facile adattamento del segnale video alla rete e/o alle caratteristiche dei terminali.

In una forma di attuazione, il ricorso a reti di tipo Peer-to-Peer offre possibilità di accesso ad un ambiente creato a livello di applicazione in termini di applicazione software locale, permettendo di comunicare con altri Peer che utilizzano l’applicazione su internet. Tutto questo creando una rete in sovrapposizione a livello di applicazione in cui ciascun utente terminale à ̈ in grado di condividere le sue risorse con l’insieme della sovrapposizione.

In una forma di attuazione, questo aspetto di tipo cooperativo sfrutta appieno i vantaggi dei sistemi P2P in quanto consente alla comunità di crescere in modo indefinito senza necessità di server potenti e dedicati, offrendo vantaggi rilevanti in termini di scalabilità di rete e riducendo i costi degli investimenti per le nuove applicazioni di streaming.

In una forma di attuazione, il ricorso alla codifica video a strati implica rilevanti vantaggi sinergici in relazione all’impiego dei sistemi P2P, in particolare quelli che utilizzano grafi ad albero multiplo, fondendo la presenza di stream di dati video multipli con i vantaggi evidenti tanto a livello di rete quanto a livello di applicazione.

In una forma di attuazione, grazie al ricorso alla codifica SVC e ad una configurazione ottimizzata della rete in sovrapposizione, si hanno miglioramenti in termini di efficienza di rete per quanto riguarda la distribuzione dei contenuti, rendendo più facile la ricerca di Peer candidati.

In un contesto di tipo P2P, quale un ambiente P2P ad alberi multipli eterogeneo che ospita una piattaforma streaming scalabile, un forma di attuazione comporta notevoli vantaggi tanto a livello di rete quanto a livello applicativo. Questo offrendo all’utente la possibilità di commutare da un livello qualitativo all’altro ma evitando la diffusione simultanea dello stesso contenuto video con livelli di qualità diversi. L’utente riceve (e, se del caso, paga in modo differenziato) solo ciò che à ̈ effettivamente interessato e/o in grado di ricevere e la fonte dei contenuti immagazzina soltanto uno stream principale invece di più stream diversi conseguendo vantaggi in termini di costo di larghezza di banda dal momento che globalmente i server forniscono agli utilizzatori una quantità inferiori di dati.

In una forma di attuazione, utilizzando la codifica MDC, à ̈ possibile migliorare la resistenza nei confronti delle perdite dei dati conseguendo una maggiore flessibilità nell’assegnazione delle descrizioni. L’impiego della MDC, al fine di rendere più efficiente la distribuzione dei contenuti, permette ad un Peer di cambiare la sovrapposizione senza modificare la sua qualità video, il che costituisce un aspetto di rilievo per le applicazioni commerciali.

Breve descrizione delle viste annesse

L’invenzione sarà ora descritta, a puro titolo di esempio non limitativo con riferimento alle viste annesse, in cui:

- le figure 1 a 7 sono già state descritte in precedenza,

- la figura 8 illustra un’architettura di rete secondo una forma di attuazione,

- la figura 9 à ̈ uno schema a blocchi di una architettura di terminale secondo una forma di attuazione, - la figura 10 rappresenta l’organizzazione dei cosiddetti gruppi di immagini (Group Of Pictures o GOP) in una sequenza di immagini video digitali,

- la figura 11 illustra schematicamente una tecnica di incapsulamento dei dati secondo una forma di attuazione, - le figure 12 e 13 illustrano varie operazioni di trattamento dei cosiddetti chunk secondo una forma di attuazione,

- la figura 14 rappresenta l’organizzazione dei cosiddetti NALU secondo una forma di attuazione,

- la figura 15, comprendente due parti indicate rispettivamente con a) e b), illustra modalità di erogazione di contenuti mediali in una rete,

- la figura 16, comprendente due parti indicate rispettivamente con a) e b), illustra anch’essa modalità di erogazione di contenuti mediali in una rete, e

- le figure 17 e 18 rappresentano schematicamente modalità di erogazione di contenuti mediali in una rete.

Descrizione particolareggiata di esempi di attuazione Nella seguente descrizione sono illustrati vari dettagli specifici finalizzati ad una approfondita comprensione delle forme di attuazione. Le forme di attuazione possono essere realizzate senza uno o più dei dettagli specifici, o con altri metodi, componenti, materiali ecc. In altri casi, strutture, materiali o operazioni noti non sono mostrati o descritti in dettaglio per evitare di rendere oscuri vari aspetti delle forme di attuazione.

Il riferimento ad “una forma di attuazione†nell’ambito di questa descrizione sta ad indicare che una particolare configurazione, struttura o caratteristica descritte in relazione alla forma di attuazione à ̈ compresa in almeno una forma di attuazione. Quindi, frasi come “in una forma di attuazione†, eventualmente presenti in diversi luoghi di questa descrizione, non sono necessariamente riferite alla stessa forma di attuazione. Inoltre, particolari conformazioni, strutture o caratteristiche possono essere combinati in un modo adeguato in una o più forme di attuazione.

I riferimenti qui utilizzati sono soltanto per comodità e non definiscono dunque l’ambito di tutela o la portata delle forme di attuazione.

Varie forme di attuazione qui descritte sono suscettibili di essere realizzate sotto forma di una rete in sovrapposizione (overlay) di tipo Peer-to-Peer (P2P) dedicata alla distribuzione di bitstream video scalabili.

La figura 8 illustra schematicamente la possibile architettura di una tale rete P2P comprendente una pluralità di terminali T realizzata nell’ambito di una rete a commutazione di pacchetto N pre-esistente di tipo LAN, MAN o WAN, quale ad esempio Internet. Di conseguenza, negli esempi qui considerati, i nodi della rete P2P fanno anche parte della rete N e sono quindi indicati come terminali T.

Un terminale T appartenente alla rete P2P à ̈ chiamato “Peer†. La rete N può quindi comprendere anche uno o più nodi server che non fanno parte della rete P2P e/o che non scambiano dati di interesse ai fini della soluzione qui considerata e, come tali, non fanno in senso stretto parte della sovrapposizione, pur potendo giocare un ruolo nell’assistere i meccanismi di comunicazione fra Peer. Un esempio di un tale server à ̈ il server “tracker†nel caso del protocollo BitTorrent.

Nello schema della figura 8, le linee rappresentate a collegamento dei terminali T costituiscono i link L della rete Peer-to-Peer. Il blocco C, rappresentato a tratti, si riferisce alla possibile presenza di un nodo (server) con funzione di coordinatore.

In una possibile architettura funzionale di terminale T, così come rappresentata nella figura 9, sono distinguibili quattro elementi principali, ossia:

- un produttore o sorgente VP di contenuti mediali video,

- un consumatore VC di contenuti mediali video,

- un motore Peer-to-Peer E, e

- un’interfaccia di rete NI.

I suddetti elementi svolgono le seguenti funzioni di base:

- il produttore (video producer) VP genera bitstream video inviati al motore Peer-to-Peer E,

- il consumatore (video consumer) VC ottiene bitstream video dal motore Peer-to-Peer E in vista del possibile immagazzinamento e della riproduzione;

- il motore E scambia i dati relativi ai bitstream video in ingresso ed in uscita con gli altri terminali T collegati dalla rete P2P, e

- l’interfaccia di rete NI converte i pacchetti dati fra il protocollo utilizzato dalla rete P2P ed il protocollo utilizzato dalla rete a commutazione di pacchetto sottostante N.

Si apprezzerà che, almeno in linea di principio, ciascun Peer T nella rete P2P può fungere,:

- da sorgente di bitstream video destinati ad altri Peer;

- da consumatore di bitstream video ottenuti dagli altri Peer, e

- da elemento di scambio di dati video ottenuti da alcuni Peer e distribuiti ad altri Peer nella rete.

In una forma di attuazione, lo scopo del produttore video VP Ã ̈ quello di fornire al motore E un bitstream video scalabile.

Un tale bitstream può essere ottenuto (tramite un generale meccanismo di multiplexing) a partire da sorgenti diverse quali una memoria 12, un collegamento o link terreste, satellitare, wireless, ecc… 14 oppure da un codificatore 16 che codifica segnali video ottenuti a partire da una o più sorgenti di ripresa (video capture) 18a, 18b… (che naturalmente possono essere in numero qualsiasi).

Quale che sia la sorgente effettiva, il bitstream scalabile fornito dal produttore o producer VP al motore E contiene una pluralità di rappresentazioni (rappresentazioni multiple) ottenute tramite filtraggio spaziale e/o filtraggio temporale e/o tramite modulazione del passo di quantizzazione durante il processo di codifica (operazioni svolte sia presso il producer V oppure altrove, con il producer che riceve da un'altra fonte un segnale già sotto forma di un bitstream scalabile) in modo da fornire al motore E un segnale con caratteristiche di scalabilità temporale e/o spaziale e/o in termini di qualità e/o di capacità di fornire viste diverse dello stesso soggetto video.

Le rappresentazioni multiple possono essere codificate in modo indipendente sotto forma di più bitstream video elementari multiplexati fra loro, oppure essere codificate in modo congiunto sotto forma di un bitstream singolo con una struttura stratificata a livelli.

In una forma di attuazione, il bitstream scalabile à ̈ ottenuto multiplexando diversi stream conformi, ad esempio, a standard quali H.262/MPEG-2, MPEG-4, VC-1 o H.264/AVC.

In una forma di attuazione, il bitstream scalabile à ̈ conforme alla estensione Scalable Video Coding (SVC) dello standard H.264/AVC (annex G). In una forma di attuazione, il bitstream scalabile SBS à ̈ conforme all’estensione Multi-View Coding (MVC) dello standard H.264/AVC (annex H).

Il bitstream scalabile (quale ne sia la sorgente: il dispositivo di memoria 12, il collegamento terrestre/satellite/wireless/14, la codifica in tempo reale da parte di un codificatore 16 collegato ad uno o più dispositivi di cattura di segnale video 18a, 18b) può essere anche multiplexato in vista della distribuzione sulla rete P2P con altre forme di dati multimediali (ad esempio audio, musica, testo) oppure metadati (ad esempio in conformità con gli standard MPEG-7 o MPEG-21).

In una forma di attuazione, rifacendosi allo schema già descritto con riferimento alla figura 5, il bitstream scalabile SBS fornito dal produttore VP à ̈ formato da una serie di pacchetti di dati chiamati NALU (Network Abstraction Level Unit) ciascuno dei quali contiene un’intera immagine, o una parte di essa, oppure la informazione sintattica per decodificare correttamente il bitstream (ad esempio: dimensioni dell’immagine, framerate, ecc…).

Come si à ̈ visto, ciascun NALU comprende un header e un carico utile (payload) dove l’header può contenere informazioni relative almeno al livello scalabile cui l’immagine appartiene ed al fatto che l’immagine sia un’immagine RAP oppure no.

Come già si à ̈ detto, nell’ambito di ciascun livello della gerarchia scalabile, un’immagine à ̈ considerata RAP (Random-Access Point) se – insieme a tutte le immagini successive – può essere decodificata senza ricorrere ad alcuna immagine che la precede. Le immagini RAP forniscono punti di commutazione fra strati diversi nel bitstream scalabile permettendo così di commutare la visualizzazione video da una rappresentazione all’altra.

La figura 10 illustra la possibilità, per ciascun livello (ad esempio per due generici livelli K e K+1, compreso il livello di base per cui K = 0) di definire un gruppo di immagini (Group Of Picture o GOP) comprendente l’insieme delle immagini compreso fra due immagini RAP, comprendendo (nell’esempio qui illustrato) la prima immagine dell’insieme ed escludendo l’ultima.

In diverse applicazioni si hanno RAP ad intervalli fissati nel tempo e, in una forma di attuazione, tutti i GOP presentano una dimensione predefinita e fissa per ciascun livello.

In generale la figura 10 fa vedere che i GOP possono avere dimensioni diverse per livelli diversi: ad esempio nei livelli K e K+1 illustrati nella figura 10 i GOP comprendono, rispettivamente, 8 e 4 immagini.

In ciascun livello, ciascun GOP Ã ̈ codificato in un certo numero di NALU.

Per semplicità, e con riferimento allo schema della figura 11, ciascun gruppo di NALU à ̈ denominato GON, ossia Group Of NALU. Ancora una volta si noterà che i NALU hanno in generale dimensioni diverse, non solo fra livelli diversi (BL, EL1, El2, …), ma anche nell’ambito dello stesso livello e da immagine a immagine.

La funzione del motore P2P à ̈ quella di scambiare i dati con gli altri Peer nella rete P2P. I dati sono scambiati sotto forma di pacchetti di lunghezza fissa denominati “chunk†, aventi lunghezza fissa e predeterminata.

La figura 11 illustra una forma di attuazione relativa a una possibile conversione dei gruppi di NALU o GON (che, come si à ̈ detto possono avere lunghezza diversa) in cosiddetti chunk. La conversione à ̈ attuata tramite un modulo di incapsulamento 20 che agisce sui GON a valle del codificatore video LCOD, che genera i NALU ed i relativi gruppi GON a partire dalle immagini video di ingresso OV.

In una forma di attuazione, il modulo 20 converte i gruppi di NALU (GON) in gruppi di chunk (Group Of Chunk o GOC) con un meccanismo di incapsulamento in cui ciascun NALU in un gruppo GON può essere segmentato in modo da adattarsi in un gruppo GOC, per cui ciascun chunk contiene uno o più NALU e/o frammenti di NALU. La lunghezza dei gruppi GOC, ossia il numero di chunk per ogni livello, può essere tanto costante quanto variabile, in funzione del rate control applicato dal produttore VP.

Nella forma di attuazione qui considerata, ciascun chunk contiene soltanto dati appartenenti ad un determinato livello del bitstream scalabile SBS, e la figura 12 illustra, in funzione del tempo (Time), l’organizzazione dei gruppi di immagini GOP per i vari livelli (layer number), ossia per il livello base BL (BL GOP) e per i livelli superiori EL1 (EL1 GOP) , EL2 (EL2 GOP), ecc… incapsulati in chunk.

Ciascun chunk à ̈ identificato dalla informazione inerente al livello cui si riferisce (BL0, EL1, EL2…) ed all’ordine sequenziale dei chunk (1 chunk, 2 chunk, 3 chunk, 4 chunk, ….). Ossia il j-esimo chunk del livello EL i-esimo à ̈ indicato come EL i, j chunk, mentre per il livello base (o livello 0) i=0, per cui il j-esimo chunk del livello base à ̈ indicato con BL 0, j chunk.

Per permettere l’estrazione di un sotto-stream di specifica qualità dal bistream complessivo SBS, à ̈ possibile definire, così come illustrato nella figura 13, una funzione di mappatura basata su una maschera dei chunk destinata ad indicare il numero di chunk per ciascun livello nonché una legge di priorità di sincronizzazione per specificare come i chunk sono inseriti nello stream SBS.

Ciascun gruppo GON può così accogliere l’informazione relativa così come specificata nella mappa dei chunk.

La maschera dei chunk viene decisa all’inizio (nel caso di applicazioni a bit rate costante) o durante la sessione di streaming (nel caso di applicazioni a bit rate variabile) dal motore Peer-to-Peer E.

Per avere un numero fisso di chunk per livello, il codificatore video LCOD può comprendere un algoritmo di controllo a bit rate costante così da codificare ciascun gruppo di immagini GOP in un gruppo di NALU, indicato con GON, la cui lunghezza complessiva corrisponde quanto più possibile alla lunghezza del gruppo di chunk GOC.

Per evitare spreco di larghezza di banda nel caso di applicazioni a bit rate variabile, Ã ̈ possibile utilizzatore un numero variabile di chunk per livello.

Questa caratteristica permette di adattare la quantità di informazione al contenuto dello stream stesso, oppure di cambiare in tempo reale (on the fly) la qualità.

Ad esempio, qualora si abbia una scena fissa con uno sfondo costante che dura diversi secondi, il codificatore ha bisogno di meno dati rispetto a quando ci si trova di fronte a una scena con vari oggetti che si muovono. Pertanto, in funzione della specifica scena video, il numero di chunk per livello può essere adattato alla quantità di informazione effettivamente richiesta per codificare ciascun livello.

Cambiare la qualità al volo o in tempo reale significa variare la quantità di informazione convogliata dallo stream. In funzione del cambio delle condizioni di piattaforma (dispositivo di rendering e condizioni di rete), il numero di chunk per livello può essere adattato alla nuova quantità di informazione (maggiore o minore) richiesta per codificare ciascun livello.

La maschera dei chunk può dunque variare durante la sessione di streaming ed à ̈ specificata dal motore P2P tramite un header a ciascun inizio di un gruppo GOC.

Un esempio di maschera dei chunk à ̈ rappresentato in alto a destra nella figura 13, dove i tre numeri (2, 3, 4) si riferiscono, procedendo dal basso si riferiscono allo schema esemplificativo della figura 12 dove sono presenti:

- 2 chunk al livello base BL o livello 0,

- 3 chunk al livello 1 EL, e

- 4 chunk al livello 2 EL2.

La figura 13 rappresenta anche due possibili schema di priorità di sincronizzazione utilizzabili per multiplexare i chunk nello stream principale sul lato del produttore VP (ossia in ingresso al motore Peer-to-Peer E) e per identificare correttamente i chunk sul lato dell’utilizzatore o del consumatore (ossia in uscita dal motore Peer-to-Peer E), facendo sì che la sorgente (VP) e gli utilizzatori (VC) seguano gli stessi criteri così da poter far coincidere il significato semantico di ciascun chunk, permettendo, ad esempio, ad un utilizzatore VC di estrarre dal bitstream scalabile, un certo sottoinsieme o sub-stream corrispondente alla massima qualità l’utilizzatore desidera o à ̈ in grado di riprodurre.

Si apprezzerà peraltro che (così come desumibile dall’osservazione della figura 11) la sincronizzazione a livello di formazione dei gruppi GON à ̈ data dall’allineamento dei NALU appartenenti ad una immagine RAP.

La parte inferiore della figura 13 fa vedere due possibili organizzazioni dello stream scalabile SBS mettendo in luce, da un lato, la possibilità di usare maschere di chunk diverse, ad esempio, oltre alla maschera (2, 3, 4) rappresentata in alto a destra nella stessa figura, maschere diverse quali (2, 2, 2) o (2, 1, 1).

Dall’altro lato, la parte inferiore della figura 13 mette in luce la possibilità di utilizzare criteri di sincronizzazione diversi corrispondenti, ad esempio:

- allo schema A, in cui i chunk vengono organizzati mettendo in sequenza i chunk con lo stesso numero d’ordine nei vari livelli, ossia BL 0, 1; EL 1, 1; EL 2, 1 poi BL 0, 2; EL 1, 2; EL 2, 2 e poi EL 1, 3; EL 2, 3 e così via, vale dire procedendo per colonne successive;

- allo schema B in cui si mettono uno dopo l’altro i chunk relativi ad un unico livello, passando dal livello base ai livelli superiori, ossia BL 0, 1; BL 0, 2, poi EL 1, 1; EL 1, 2; EL 1, 3 e poi EL 2, 1; EL 2, 2; EL 2, 3 e così via, vale a dire procedendo per righe successive.

L’effetto dell’adozione dell’uno o dell'altro dei due criteri di sincronizzazione à ̈ apprezzabile dal confronto dell’esempio A e dell’esempio B nella parte bassa della figura 13. Nei due bitstream scalabili SBS ivi rappresentati à ̈ altresì riconoscibile, prima di ogni gruppo di chunk o GOP, la presenza di un header H che convoglia la relativa maschera di chunk.

La maschera (2, 3, 4) corrisponde all’esempio rappresentato nella figura 12. La maschera (2, 2, 2) corrisponde all’eliminazione dell’ultimo chunk del livello EL1 e degli ultimi due livelli del livello EL2. La maschera (2, 1, 1) corrisponde all’eliminazione degli ultimi due chunk del livello EL1 e degli ultimi tre chunk nel livello EL2. Come già si à ̈ detto, in funzione delle esigenze applicative, la maschera dei chunk può rimanere costante, oppure essere variata.

Nella forma di attuazione qui considerata, in ciascun livello, ciascun gruppo di immagini GOP à ̈ codificato in un gruppo di NALU GON che a sua volta à ̈ incapsulato in un gruppo di chunk GOC composto da un certo numero di chunk. Il numero di chunk à ̈ in generale variabile per ciascun livello come appunto illustrato ad esempio nella figura 12. Ciascun gruppo di chunk GOC comincia con i dati NALU corrispondenti ad un’immagine RAP, per cui l’inizio di ciascun gruppo di chunk GOC à ̈ suscettibile di costituire un punto di commutazione per ciascun livello.

Ciascun chunk à ̈ in un pacchetto dati comprendente un header e un carico utile, in cui il carico utile contiene i dati NALU e l’header contiene almeno l’informazione relativa al livello video cui appartengono i NALU nel carico utile. Si apprezzerà che questo criterio di interfacciamento può essere applicato anche a protocolli in grado di gestire un numero variabile di byte per chunk.

La figura 14 rappresenta schematicamente la possibile organizzazione di un NALU con specifico riferimento alla adozione di un criterio di codifica video scalabile (SVC) (vedere anche lo schema generale della figura 4).

Quando un terminale T nella figura 8 desidera diventare Peer “consumatore†VC in una rete P2P, ricerca in primo luogo l’informazione relativa almeno ai seguenti elementi:

- numero di livelli

- risoluzione temporale, risoluzione spaziale, qualità e bit-rate di ciascun livello

- livello di riferimento per ciascun livello (per poter comprendere la gerarchia dei livelli).

Un terminale T fornisce invece tale informazione quando si trova a fungere da produttore video VP nei confronti di altri Peer: un terminale “consumatore†VC può allora decidere quali livelli desidera ricevere dalla rete P2P così da stabilire un collegamento L con i Peer aventi i dati corrispondenti ai livelli selezionati.

Tornando allo schema della figura 9, quando agisce da consumatore VC, un terminale riceve dalla rete P2P i dati (ad es. dati video) organizzati in chunk per decodificarli in un dispositivo di memoria e/o per visualizzarli.

In una forma di attuazione il terminale configurato come consumatore video può quindi comprendere quindi un estrattore di stream 22, con in cascata un demultiplexer 24 per distribuire i vari (sotto)stream estratti ad uno o più decodificatori video 26a, 26b (anche questi suscettibili di essere presenti in un numero qualsiasi: il fatto che l’esempio illustrato ne presenti due ha carattere puramente esemplificativo) e ad una struttura di memoria 28 quale ad esempio un disco HDD.

Ciascun decodificatore à ̈ poi in grado di pilotare una o più unità di visualizzazione 30a, 30b, 30c, in generale diverse fra loro per quanto riguarda le caratteristiche di risoluzione (spaziale/temporale), qualità, bit rate, ecc.

Lo schema della figura 9 si riferisce ad una soluzione in cui uno o più stream e strati demultiplati sono mandati ad una memoria 28 senza essere decodificati. Questa può essere una scelta dettata dal fatto che un bitstream codificato occupa di solito molto meno spazio di memoria rispetto ad un bitstream decodificato. Naturalmente à ̈ anche possibile pensare di immagazzinare bitstream decodificati.

Allo stesso tempo, si apprezzerà che la struttura di “consumatore†VC può in realtà presentarsi in forma molto più semplice di quella descritta e comprendere, ad esempio, solo un decodificatore con associato un display (rendendo superflua la presenza del demultiplexer 24 e senza prevedere la memoria 28).

In generale, si supporrà che lo stream scalabile ricevuto dalla rete tramite l’interfaccia di rete NI ed il motore Peer-to-Peer E sia un sotto-flusso (sub-stream) del bitstream scalabile originario SBS fornito alla rete dal terminale fungente da produttore video VP.

In una forma di attuazione, il terminale agente da consumatore VC comprende un motore di adattamento 32 che à ̈ in grado di retroagire verso il motore Peer-to-Peer E così da scegliere l’insieme di livelli da ricevere.

In una forma di attuazione, il motore di adattamento 32 realizza una procedura di decisione che sceglie i livelli da ricevere in funzione di diversi parametri quali, ad esempio:

- la (massima) risoluzione spaziale/temporale del dispositivo o dei dispositivi di visualizzazione 30a, 30b, 30c al momento attivi,

- la larghezza di banda (massima) disponibile,

- la capacità (massima) di elaborazione dei decodificatori video (26a, 26b),

- le esigenze/richieste dell’utilizzatore.

Sulla base di tali parametri, il motore di adattamento 32 decide quali sono i livelli di interesse e comunica questa informazione al motore P2P che stabilisce un collegamento verso i Peer in grado di fornire i dati relativi ai livelli selezionati.

Il motore di adattamento 32 realizza questa funzione almeno una volta, quando il terminale T si aggiunge alla rete in sovrapposizione P2P al fine di capire quali livelli del bitstream scalabile reperire presso gli altri Peer.

In una forma di attuazione, l’adattamento à ̈ realizzato in modo continuo, identificando in ciascun momento i livelli da ricevere reagendo ad uno o più dei seguenti fattori:

- cambiamenti nelle preferenze/esigenze dell’utilizzatore;

- variazioni istantanee delle condizioni di rete (larghezza di banda di caricamento/scaricamento complessivo, jitter, congestione ed altri fattori);

- collegamento al terminale di nuovi dispositivi, suscettibili ad esempio di ricevere e di utilizzare nuovi livelli grazie ad una maggiore disponibilità di potenza elaborativa o ad una maggiore risoluzione di visualizzazione;

- scollegamento di dispositivi precedentemente collegati al terminale, con la possibilità di “lasciar perdere†uno o più livelli, ad esempio quando non sono più presenti la potenza elaborativa e/o la capacità/risoluzione di visualizzazione in grado di sfruttarli.

In una forma di attuazione, la commutazione da un livello ad un altro si realizza in corrispondenza della immagini RAP, in modo tale per cui la commutazione ha luogo con un ritardo dipendente dalla frequenza con cui tali punti di accesso casuale sono presenti nello stream. Tale frequenza di ricorrenza della immagini RAP può essere costante o variabile.

In una forma di attuazione in cui la frequenza RAP à ̈ variabile, essa à ̈ vincolata ad un limite superiore così da limitare il ritardo ad un valore tale da permettere un’elevata flessibilità senza risultare fastidiosa per l’utilizzatore.

Si apprezzerà peraltro che tutto quanto esemplificato in precedenza in relazione al motore di interfacciamento E facendo riferimento a dati mediali codificati con una codifica stratificata (HVC, SVC) comprendente un livello base BL ed uno o più livelli di miglioramento o enhancement layer EL1, EL2, … (eventualmente legati da un meccanismo di predizione – vedere i blocchi PRED della figura 4), si applica anche ad una codifica a descrizioni multiple (MDC, FTV) che fornisce una pluralità di descrizioni dello stesso contenuto mediale non necessariamente legate fra loro in un rapporto base layer/enhancement. Ciò vale, in particolare, per quanto riguarda l’organizzazione dei gruppi di chunk (GOC), che possono essere organizzati su più livelli corrispondenti ciascuno ad una delle descrizioni di una codifica a descrizioni multiple.

La presente descrizione si applica dunque – in generale – a tutte le forme di attuazione in cui pacchetti di dati mediali quali pacchetti NALU sono codificati con una codifica che fornisce una pluralità di rappresentazioni dello stesso contenuto mediale ed in cui tanto i gruppi di pacchetti di dati (GON) quanto i gruppi di chunk (GOC) sono organizzati su più livelli corrispondenti alla pluralità di rappresentazioni fornite dalla codifica. Il livelli base e di enhancement BL, EL1, EL2, … sono quindi solo un esempio di tali rappresentazioni diverse.

La figura 15a si riferisce ad un contesto in cui a terminali T compresi in una rete P2P vengono distribuiti contenuti mediali (ad esempio contenuti video) con almeno due livelli qualitativi diversi (per semplicità di illustrazione si può fare riferimento ad un livello qualitativo “basso†S1 ed un livello qualitativo “alto†S2). Nel caso considerato nella figura 15a, i due livelli qualitativi S1 e S2 sono distribuiti - in modo indipendente per ciascun livello – a partire da un unico server principale (main server) MS in condizioni tali per cui i nodi (ossia i terminali T) interessati a ricevere il livello “alto†S2 possono ricevere tale contenuto solo dal server principale MS oppure da un altro nodi Peer che già riceve o il contenuto elevato. Questo modo di operare richiede in pratica di organizzare – ad esempio secondo le modalità discusse nella parte introduttiva della presente descrizione – due reti di distribuzione di fatto indipendenti fra loro: l’una dedicata alla distribuzione del contenuto S1 e l’altra dedicata alla distribuzione del contenuto S2.

Se una sorgente di contenuti (broadcaster) rende disponibile, ad esempio, lo stesso contenuto video con due livelli di qualità diversa ma codificati indipendentemente, il motore P2P à ̈ costretto a gestire l’intera sovrapposizione come costituita da elementi indipendenti, uno per ciascun stream, anche se si tratta dello stesso contenuto video. Detto altrimenti, ricorrendo allo schema della figura 15°, ciascun terminale T interessato/capace di ricevere il bit stream di alto livello S2 dovrà riceverlo – integralmente – o dal server MS o tramite la catena di uno o più altri terminali T che già lo ricevono.

La figura 15b si riferisce invece alla possibilità di fornire gli stessi contenuti S1 e S2 ad una rete di terminali T di tipo Peer-to-Peer prevedendo la distribuzione del livello base L0 di una codifica SVC (vedere le figura 4) a tutti i nodi T e prevedendo altresì la distribuzione dei livelli qualitativi superiori (per semplicità nella figura 15b si fa riferimento, così come nel caso della figura 15a, ad un solo livello superiore S2) non come flusso intero ma sotto forma del o dei livelli di miglioramento (enhancement layer EL1, EL2 ecc.) corrispondenti.

Detto altrimenti, dal server principale MS fuoriuscirà un bitstream scalabile SBS con la struttura rappresentata nella figura 13 ed il singolo terminale T, in funzione delle sue esigenze/potenzialità (manifestate attraverso il motore di adattamento 32 della figura 9) estrarrà il o i sub-stream di suo specifico interesse, ottenendo i chunk corrispondenti dai Peer che ne sono in possesso, in funzione dell’informazione contenuta nella maschera di chunk associata a bistream o alle singole sezioni dello stesso.

Questo (facendo sempre riferimento per semplicità a due soli livelli qualitativi, S1 e S2) in uno scenario derivante dalla sovrapposizione dell’intera comunità dei terminali, che richiede il livello base (per cui, ad esempio S1 = BL), e di una sotto-sovrapposizione, che condivide il livello di miglioramento o enhancement layer EL1 (per cui S2= BL EL1). Questo contesto à ̈ interessante in quanto ciascun Peer ha facoltà di interagire, per quanto riguarda il livello base, con tutta la comunità dei terminali T che lo ricevono. Dal momento che i sistemi P2P sono basati sulla cooperazione, questo scenario à ̈ interessante dal momento che ciascun Peer à ̈ in grado di richiedere il contenuto condiviso come livello base (condiviso dall’intera comunità degli utenti) cui sono selettivamente sovrapponibili uno o più livelli di miglioramento qualitativo. In questo modo se la sovrapposizione condivisa à ̈ maggiore, sussistono maggiori possibilità di trovare fonti di erogazione situate nelle.

La figura 16 mira ad evidenziare i vantaggi resi disponibili dall’applicazione ad un contesto P2P della codifica a descrizioni multiple (MDC). Nel caso specifico, si suppone che il server principale MS renda disponibile lo stesso contenuto mediale sotto forma di due descrizioni diverse D1 e D2, qui non legate da un meccanismo di codifica HVC o SVC di tipo gerarchico così come considerato in precedenza. Detto altrimenti, si suppone in questo caso che le descrizioni D1 e D2 siano circa equipollenti fra loro dal punto di vista qualitativo, mentre la loro possibile combinazione porta a disporre di un livello qualitativo più elevato: ossia, volendo ancora una volta far riferimento ai due livelli qualitativi S1 (“basso†) e S2 (“alto†) visti in precedenza, si può ipotizzare, dal punto di vista qualitativo, D1 @ D2 @ S1 e D1 D2 = S2.

In una forma di attuazione, le due (o più) descrizioni D1 e D2 possono corrispondere “viste†diverse degli stessi soggetti ottenuti tramite una schiera di camere diverse, in modo che ciascuna vista rappresenta la stessa scena osservata però secondo una visuale diversa, in uno schema del tipo noto come televisione a punto di vista libero (Free View-Point television o FTV).

In particolare, la figura 16a fa vedere che in un contesto sostanzialmente assimilabile a quello della figura 15a, un particolare terminale indicato con T2 interessato a ricevere entrambe le due descrizioni D1 e D2 può ricevere le due descrizioni soltanto dal server MS o da un altro terminale T2 che le ha disponibili entrambe.

Al contrario, ricorrendo, così come illustrato nella figura 16b, ad una soluzione che combina le descrizioni multiple (MDC) con la filosofia Peer-to-Peer (P2P), il terminale T2 à ̈ in grado di ottenere la descrizione D1 da un terminale T1 la descrizione D2 da un altro terminale T1 quando né l’uno né l’altro di questi due terminali T1 agenti da “fornitori†dispone di per sé di entrambe le rappresentazioni D1 e D2.

In questa forma di attuazione, i terminali T1, T2 della rete Peer-to-Peer sono in grado di accedere selettivamente a più descrizioni in una molteplicità di descrizioni diverse (ad es. D1, D2) dello stesso contenuto mediale (ad es. uno stream video) e di combinarle fra loro (ad es. per ottenere un livello qualitativo più elevato).

Le figure 17 e 18 fanno vedere come l’impiego della tecnica MDC in una rete P2P permette di far fronte vantaggiosamente a fenomeni di guasto o di congestione di rete.

Così come nel caso delle viste della figura 16, anche nelle figure 17 e 18, il riferimento T2 indica i terminali della rete Peer-to-Peer che hanno disponibili entrambe le descrizioni D1 e D2, mentre il riferimento T1 indica i terminali che hanno disponibile solo una di tali descrizioni.

La figura 17 si riferisce in particolare al caso di un generico Peer Pn (quello racchiuso da un circolo a tratti) costituito da terminale T1 che ha sinora attinto, ad esempio, la descrizione D1 di une certo contenuto mediale da un altro terminale T1 fungente da “padre†e che, a seguito di un fenomeno di congestione di rete (o di un guasto) perde il collegamento rispetto a tale Peer “padre†.

La figura 18 fa vedere come, sfruttando la disponibilità di descrizioni multiple D1 e D2 dello stesso contenuto mediale, lo stesso Peer “figlio†Pn può continuare a ricevere il contenuto entrando in collegamento con un altro terminale “padre†T1 che abbia disponibile tale contenuto sotto forma di una qualsiasi delle descrizioni (ad esempio, anche la descrizione D2) resa disponibile nella rete Peer-to-Peer. Il Peer Pn, che prima riceveva tale contenuto multimediale sotto forma della descrizione D1, può continuare a ricevere tale contenuto anche se non à ̈ immediatamente disponibile un Peer in grado di subentrare al “padre†precedente fornendogli lo stesso contenuto sotto forma della stessa descrizione D1.

In questa forma di attuazione, i terminali T1, T2 della rete Peer-to-Peer sono in grado di accedere selettivamente a più descrizioni in una molteplicità di descrizioni diverse (ad es. D1, D2) dello stesso contenuto mediale (ad es. uno stream video) con la capacità di accedere ad una di tali descrizioni diverse (ad es. D2) in sostituzione di un’altra descrizione non più disponibile (ad es. D1, non più disponibile per un guasto o per uno stato di congestione) conservando l’accesso al relativo contenuto mediali.

La codifica MDC non à ̈ codificata su livelli gerarchici ed i Peer possono passare da un sub-overlay ad un altro e percepire ancora sostanzialmente la stessa qualità dello stream, dal momento che la qualità in questo caso dipende solo dal numero delle diverse descrizioni ricevute. Se l’utilizzatore richiede una qualità corrispondente a due descrizioni, al relativo terminale à ̈ sufficiente ritrovare soltanto due qualsiasi dei sub-stream disponibili per ottenere la qualità richiesta.

Altri vantaggi sono osservabili a livello di rete nel caso in cui un Peer si disconnetta (oppure cambi canale) o in caso di congestione di rete. Come si à ̈ visto, un Peer al bordo della sovrapposizione non à ̈ più servito da un unico link tradizionale: il Peer à ̈ in grado di cambiare la richiesta della descrizione e di migrare ad un altro suboverlay, mantenendo la stessa qualità dello stream originario.

La soluzione qui considerata si presta anche a contenere possibili fenomeni di spreco di banda dei provider a livello fisico di topologia della rete.

Si supponga di avere a che fare con un client collocato in posizione genericamente molto remota rispetto alla sorgente di un determinato contenuto mediale e che chiede due descrizioni D1 e D2 di tale contenuto, mentre tutti i client lungo il cammino verso tale cliente remoto chiedono una sola descrizione.

In questo quadro non à ̈ efficiente avere tanti client che chiedono ed ottengono, ad esempio, D1 ed un solo peer remoto che chiede D1 D2, rendendo necessario far transitare la descrizione D2 attraverso tutti i router disposti lungo il cammino senza utilizzarla per soddisfare alcuna richiesta: operando in tal modo si impegnerebbe tutta la infrastruttura per soddisfare un’esigenza manifestata da un solo peer, con una efficienza molto bassa. Per evitare che tutti i router fisici lungo il tragitto inoltrino due descrizioni equivalenti, di cui poi una sola à ̈ utilizzata per soddisfare le esigenze dell’ampia maggioranza degli utilizzatori, mentre l’altra serve ad un solo utilizzatore, à ̈ possibile intervenire con il meccanismo descritto in precedenza facendo in modo che i router destinati ad inoltrare la descrizione D2 verso l’utilizzatore “remoto†modifichino (almeno in parte) la loro richiesta da D1 a D2. In questo modo le descrizioni D1 e D2 inoltrate verso l†̃utilizzatore remote che le ha richieste sono entrambe utilizzate per soddisfare le esigenze di utenti disposti lungo il tragitto verso l’utilizzatore remoto.

Naturalmente, fermo restando il principio dell’invenzione, i particolari di realizzazione e le forme di attuazione potranno variare, anche in modo significativo, rispetto a quanto qui illustrato a puro titolo di esempio non limitativo, senza per questo uscire dall’ambito dell’invenzione così come definita dalle rivendicazioni annesse.

Claims (30)

1. RIVENDICAZIONI 1. Procedimento per l’interfacciamento di pacchetti di dati mediali codificati (NALU) nel trasferimento da e verso una rete Peer-to-Peer in cui detti dati sono resi disponibili su detta rete Peer-to-Peer sotto forma di cosiddetti chunk, in cui: - detti pacchetti di dati (NALU) sono inclusi in gruppi di pacchetti (GON), detti gruppi di pacchetti (GON) essendo suscettibili di presentare lunghezze diverse fra loro, - ciascun gruppo di pacchetti di dati (GON) à ̈ incapsulato (20) in un gruppo di chunk (GOC) di lunghezza data, con ciascun chunk contenente uno o più di detti pacchetti di dati e/o di frammenti di pacchetti di dati.
2. 2. Procedimento secondo la rivendicazione 1, in cui detti dati convogliano sequenze di immagini video organizzate in gruppi di immagini (GOP) ed in cui ciascuno di detti gruppi di pacchetti di dati (GON) comprende pacchetti di dati corrispondenti ad immagini comprese nello stesso gruppo di immagini (GOP).
3. 3. Procedimento secondo la rivendicazione 2, in cui detti dati convogliano sequenze di immagini video in cui ricorrono immagini di tipo RAP decodificabili in modo indipendente da ogni immagine precedente nella sequenza, ed in cui detti gruppi di immagini (GOP) comprendono le immagini comprese fra una coppia di immagini di tipo RAP più una delle immagini di tipo RAP di detta coppia.
4. 4. Procedimento secondo una qualsiasi delle precedenti rivendicazioni, in cui detti pacchetti di dati (NALU) sono codificati con una codifica che fornisce una pluralità di rappresentazioni (BL, EL1, EL2, …) dello stesso contenuto mediale ed in cui tanto detti gruppi di pacchetti di dati (GON) quanto detti gruppi di chunk (GOC) sono organizzati su più livelli corrispondenti a detta pluralità di rappresentazioni (BL, EL1, EL2, …) fornite da detta codifica.
5. 5. Procedimento secondo la rivendicazione 4, in cui detta codifica à ̈ una codifica a descrizioni multiple che fornisce una pluralità di descrizioni di uno stesso contenuto mediale.
6. 6. Procedimento secondo la rivendicazione 4 o la rivendicazione 5, in cui detta codifica à ̈ una codifica stratificata su più livelli (BL, EL1, EL2, …) ed in cui tanto detti gruppi di pacchetti di dati (GON) quanto detti gruppi di chunk (GOC) sono organizzati su più livelli corrispondenti ai livelli di detta codifica stratificata.
7. 7. Procedimento secondo la rivendicazione 6, in cui detta codifica stratificata à ̈ una codifica comprendente livello base (BL) ed almeno un livello di miglioramento o enhancement layer (EL1, EL2, …) di detto livello base (BL).
8. 8. Procedimento secondo la rivendicazione 7, in cui detto livello base (BL) e detto almeno un livello di miglioramento o enhancement layer (EL1, EL2, …) sono legati fra loro da un meccanismo di predizione (PRED) per cui ciascuno di detti livelli (EL1, EL2) tranne il livello di base à ̈ codificato (MTC) in funzione di almeno un rispettivo livello inferiore (EL1, BL).
9. 9. Procedimento secondo una qualsiasi delle rivendicazione 4 a 8, in cui a detti gruppi di chunk (GOC) à ̈ associata una maschera dei chunk identificativa della corrispondenza fra i singoli chunk del gruppo e detti più livelli (BL, EL1, EL2, …).
10. 10. Procedimento secondo la rivendicazione 9, in cui detta maschera dei chunk indica quanti chunk del gruppo corrispondono ad un determinato livello fra detti più livelli (BL, EL1, EL2, …).
11. 11. Procedimento secondo la rivendicazione 9 o la rivendicazione 10, in cui detta maschera dei chunk à ̈ presente negli header (H) di detti gruppi di chunk (GOC) come resi disponibili su detta rete Peer-to-Peer.
12. 12. Procedimento secondo una qualsiasi delle rivendicazioni 4 a 11, in cui i chunk del gruppo sono ordinati secondo una legge di sincronizzazione (A) in cui i chunk relativi a rappresentazioni diverse (BL, EL1, EL2, …) dello stesso contenuto mediale sono disposti in sequenza fra loro.
13. 13. Procedimento secondo una qualsiasi delle rivendicazioni 4 a 11, in cui i chunk del gruppo sono ordinati secondo una legge di sincronizzazione (B) in cui i chunk relativi allo stessa rappresentazione sono disposti in sequenza fra loro.
14. 14. Procedimento secondo una qualsiasi delle precedenti rivendicazioni 4 a 13, in cui detti gruppi di chunk (GOC) sono resi disponibili su detta rete Peer-to-Peer come bitstream scalabile, con i gruppi di chunk (GOC) relativi alle singole rappresentazioni (BL, EL1, EL2, …) di detto stesso contenuto mediale selettivamente estraibili (22) da detto bitstream scalabile.
15. 15. Procedimento secondo una qualsiasi delle rivendicazioni 1 a 14, comprendente distribuire detti pacchetti di dati mediali codificati fra i terminali (T1, T2) di detta rete Peer-to-Peer: - rendendo disponibili detti dati come molteplicità di descrizioni diverse (D1, D2) di una codifica a descrizioni multiple di uno stesso contenuto mediale, e - configurando detti terminali (T1, T2) di detta rete Peer-to-Peer per accedere selettivamente a detta molteplicità di descrizioni diverse (D1, D2) e realizzare almeno una operazione fra: - a) accedere ad una pluralità di dette descrizioni diverse (D1, D2), combinandole fra loro; e - b) accedere ad una (D2) di dette descrizioni diverse in sostituzione di un’altra (D1) di dette descrizioni diverse conservando l’accesso a detti contenuti mediali.
16. 16. Procedimento secondo la rivendicazione 15, comprendente, in corrispondenza di almeno uno (T2) di detti terminali (T1, T2) di detta rete Peer-to-Peer: - accedere ad una prima (D1) di dette descrizioni diverse (D1, D2) tramite un primo altro terminale di detta rete Peer-to-Peer; - accedere ad almeno una seconda (D2) di dette descrizioni diverse (D1, D2) tramite almeno un secondo altro terminale di detta rete Peer-to-Peer; e - combinare fra loro detta prima (D1) e detta almeno una seconda (D2) di dette descrizioni diverse (D1, D2).
17. 17. Procedimento secondo una qualsiasi delle rivendicazioni 15 o 16, comprendente: - rilevare, in corrispondenza di uno (T1) di detti terminali (T1, T2) di detta rete Peer-to-Peer, l’intervenuta indisponibilità di una prima (D1) di dette descrizioni diverse (D1, D2) di detti contenuti mediali, e - accedere, tramite detto uno (T1) di detti terminali (T1, T2) di detta rete Peer-to-Peer, ad un’altra (D2) di dette descrizioni diverse in sostituzione di detta prima (D1) di dette descrizioni diverse conservando l’accesso a detti contenuti mediali.
18. 18. Procedimento secondo una qualsiasi delle rivendicazioni 15 a 17, in cui detti dati convogliano sequenze di immagini video comprendenti immagini di tipo RAP riproducibili in modo indipendente dalle immagini precedenti nella rispettiva sequenza, il procedimento comprendendo configurare detti terminali (T1, T2) di detta rete Peer-to-Peer per commutare l’accesso dall’una all’altra di detta molteplicità di descrizioni diverse (D1, D2) in corrispondenza di una di dette immagini RAP.
19. 19. Procedimento secondo una qualsiasi delle precedenti rivendicazioni 15 a 18, comprendente rendere disponibili detti contenuti mediali sotto forma di descrizioni diverse (D1, D2) che, combinate fra loro, migliorano la rappresentazione di detti contenuti mediali.
20. 20. Procedimento secondo una qualsiasi delle precedenti rivendicazioni 15 a 19, in cui detti contenuti mediali sono resi disponibili come molteplicità di descrizioni diverse (D1, D2) di una codifica a descrizioni multiple a partire da una sorgente, il procedimento comprendendo: - rilevare la richiesta, da parte di uno di detti terminali (T1, T2) raggiungibile a partire da detta sorgente (MS) attraverso un cammino dato di detta rete Peer-to-Peer, di accedere ad almeno una prima (D1) ed una seconda (D2) descrizione di detta pluralità di descrizioni diverse (D1, D2), in vista della loro combinazione; e - rilevata detta richiesta, far accedere un insieme di terminali (T1, T2) di detta rete Peer-to-Peer disposti lungo detto cammino dato a detta seconda descrizione (D2) in sostituzione di detta prima descrizione (D1).
21. 21. Procedimento secondo una qualsiasi delle rivendicazioni 1 a 14, comprendente distribuire detti pacchetti di dati mediali codificati fra i terminali (T) di una rete Peer-to-Peer: - rendendo disponibili detti dati come livello base (BL) ed almeno un livello di miglioramento o enhancement layer (EL1, EL2, …) di una codifica stratificata di uno stesso contenuto mediale, e - configurando detti terminali (T) di detta rete Peerto-Peer per accedere selettivamente a detto livello base (BL) ed a detto almeno un livello di miglioramento o enhancement layer (EL1, EL2, …) e per combinare fra loro detto livello base (BL) e detto almeno un livello di miglioramento o enhancement layer (EL1, EL2, …).
22. 22. Procedimento secondo la rivendicazione 21, comprendente, in corrispondenza di almeno uno di detti terminali (T) di detta rete Peer-to-Peer: - accedere a detto livello base (BL) di detta una codifica stratificata tramite un primo altro terminale di detta rete Peer-to-Peer; - accedere a detto almeno un livello di miglioramento o enhancement layer (EL1, EL2, …) di detta codifica stratificata tramite almeno un secondo altro terminale di detta rete Peer-to-Peer; e - combinare fra loro detto livello base (BL) e detto almeno un livello di miglioramento o enhancement layer (EL1, EL2, …).
23. 23. Procedimento secondo la rivendicazione 21 o la rivendicazione 22, comprendente, presso detti terminali (T) in detta rete Peer-to-Peer: - rilevare (32) la modalità di fruizione (26a, 26b, 30a, 30b, 30c) di detti contenuti mediali da parte del rispettivo terminale (T), e - controllare l’accesso selettivo del rispettivo terminale (T) a detto livello base (BL) ed a detto almeno un livello di miglioramento o enhancement layer (EL1, EL2, …) in funzione di detta modalità di fruizione (26a, 26b, 30a, 30b, 30c).
24. 24. Procedimento secondo una qualsiasi delle precedenti rivendicazioni 21 a 23, in cui detti dati convogliano sequenze di immagini video (OV) di cui detto livello base (BL) fornisce una rappresentazione base e detto almeno un livello di miglioramento o enhancement layer (EL1, EL2, …) convoglia un miglioramento di detta rappresentazione base in termini di risoluzione temporale, risoluzione spaziale, qualità.
25. 25. Procedimento secondo una qualsiasi delle rivendicazioni 21 a 24, in cui detti dati convogliano sequenze di immagini video (OV) comprendono immagini di tipo RAP riproducibili in modo indipendente dalle immagini precedenti nella rispettiva sequenza, il procedimento comprendendo configurare detti terminali (T1, T2) di detta rete Peer-to-Peer per commutare l’accesso a detto livello base (BL) ed a detto almeno un livello di miglioramento o enhancement layer (EL1, EL2, …) in corrispondenza di una di dette immagini RAP.
26. 26. Dispositivo motore di interfacciamento (E, NI) di dati mediali codificati (NALU), configurato per attuare il procedimento secondo una qualsiasi delle rivendicazioni 1 a 25 nel trasferire dati mediali da una rete Peer-to-Peer dove detti dati sono resi disponibili sotto forma di detti gruppi di chunk (GOC) verso un terminale (T) di detta rete Peer-to-Peer operante come utilizzatore (VC) di detti pacchetti di dati mediali codificati (NALU).
27. 27. Dispositivo secondo la rivendicazione 26, accoppiato ad un motore di adattamento (32) configurato per: - rilevare (32) la modalità di fruizione (26a, 26b, 30a, 30b, 30c) di detti dati mediali (NALU) da parte di detto terminale (T) di detta rete Peer-to-Peer operante come utilizzatore (VC), e - controllare detto motore di interfacciamento (E, NI) nel trasferimento selettivo di detti dati mediali da detta rete Peer-to-Peer verso detto terminale (T) operante come utilizzatore (VC) in funzione di detta modalità di fruizione (26a, 26b, 30a, 30b, 30c).
28. 28. Dispositivo motore di interfacciamento (E, NI) di dati mediali codificati (NALU), configurato per attuare il procedimento secondo una qualsiasi delle rivendicazioni 1 a 25 nel trasferire detti dati mediali a partire da un terminale (T) di detta rete Peer-to-Peer operante come sorgente (VP) di detti pacchetti di dati mediali (NALU) verso una rete Peer-to-Peer dove detti dati mediali sono resi disponibili sotto forma di detti gruppi di chunk (GOC).
29. 29. Bitstream scalabile (SBS) convogliabile su una rete Peer-to-Peer comprendente una sequenza di gruppi di chunk (GOC) ottenuta con il procedimento secondo una qualsiasi delle rivendicazioni 1 a 14.
30. 30. Prodotto informatico caricabile nella memoria di almeno un elaboratore e comprendente porzioni di codice software per realizzare il procedimento secondo una qualsiasi delle rivendicazioni 1 a 25.