ITTO20130437A1 - Metodo di elaborazione di un contenuto video ricevibile da una pluralità di piattaforme di distribuzione e relativo apparato di ricezione video - Google Patents

Description

“METODO DI ELABORAZIONE DI UN CONTENUTO VIDEO RICEVIBILE DA UNA PLURALITÀ DI PIATTAFORME DI DISTRIBUZIONE E RELATIVO APPARATO DI RICEZIONE VIDEOâ€

DESCRIZIONE

[CAMPO DELLA TECNICA]

La presente invenzione si riferisce ad un metodo di elaborazione di un contenuto video e ad un relativo apparato di ricezione video, implementante il metodo suddetto. In particolare la presente invenzione à ̈ applicabile in ambiti in cui dispositivi di riproduzione video, tipicamente in ambiente domestico, interagiscono con i sistemi di distribuzione utilizzati dai fornitori di contenuti video mediante apparati di ricezione ibridi, ovvero apparati in grado di ricevere e processare contenuti video distribuiti su piattaforme diversificate.

[ARTE NOTA]

Al giorno d’oggi i sistemi per la ricezione e la riproduzione di contenuti video, per esempio radiotelevisivi, sono in veloce evoluzione.

Per esempio, la distribuzione di contenuti radiotelevisivi in ambito domestico si effettua mediante differenti infrastrutture, quali infrastrutture broadcast (terrestri, via cavo o satellitari, tipicamente digitali) ed infrastrutture di rete o broadband (denominate anche CDN o “Content Delivery Network†in Inglese). La domanda di brevetto WO12129762A1 si riferisce ad un sistema di ricezione ibrido di contenuti multimediali, che riceve contenuti da una pluralità di broadcast network, anche secondo lo standard Internet Protocol Television o IPTV.

Inoltre, all’interno della distribuzione domestica di contenuti video, si assiste ad una diffusione di sistemi come sono quelli previsti dalla “Digital Living Network Alliance†o DLNA.

In generale, le infrastrutture di tipo broadcast hanno un costo che à ̈ indipendente dal numero di utenti che ricevono effettivamente il contenuto, e non sono soggette a problemi di congestione (tipici invece dei sistemi “web†); le infrastrutture di tipo broadcast permettono una distribuzione agevole di segnali video ad alta qualità. Il limite delle infrastrutture broadcast à ̈ dato dal fatto che la banda radio, su cui avviene la distribuzione dei contenuti video, à ̈ una risorsa limitata ed il suo impiego à ̈ giustificato solamente se il numero di utenti che effettivamente ricevono un dato contenuto, supera una soglia dettata da criteri di costo.

In generale invece, le infrastrutture di rete web, o broadband, hanno un costo che dipende dal numero di utenti effettivamente collegati, e dal traffico sviluppato da ciascuno; le infrastrutture broadband possono essere soggette a problemi di congestione, soprattutto nel caso di servizi che portano ad una accentuata variabilità del traffico, con picchi molto pronunciati. Inoltre la gestione di segnali ad alta qualità (ovvero con un alto bit rate) su infrastrutture broadband comporta costi molto elevati, soprattutto nel caso di contenuti video che interessano un pubblico di massa.

[OBIETTIVI E SINTESI DELL’INVENZIONE]

Scopo della presente invenzione à ̈ di presentare una soluzione che consenta di migliorare la distribuzione di contenuti video.

È in particolare scopo della presente invenzione migliorare l’utilizzo della banda disponibile sulle piattaforme di distribuzione di contenuti video.

È inoltre scopo della presente invenzione consentire agli utenti la ricezione e la riproduzione di contenuti video, con una migliore qualità, senza che sia richiesto ad un utente o all’apparato di ricezione di informarsi preventivamente sulle possibilità e qualità di accesso a differenti piattaforme di distribuzione e/o sulla loro efficienza di utilizzo, né di intervenire in alcun modo sull’apparato di ricezione.

È inoltre scopo della presente invenzione presentare un metodo che consenta una miglior gestione della distribuzione dei contenuti video trasmessi su una pluralità di piattaforme, e che in particolare consenta al fornitore di detti contenuti di ottimizzare l’impiego delle risorse disponibili, minimizzando al contempo l’impatto che il metodo ha sulla fruizione dei contenuti da parte degli utenti finali.

Questi ed altri scopi sono raggiunti mediante un metodo di elaborazione di un contenuto video, ed un relativo apparato di ricezione video.

Un’idea alla base della presente invenzione à ̈ quella di prevedere un metodo di elaborazione di un contenuto video, in cui un apparato di ricezione di contenuti à ̈ atto a ricevere contenuti video attraverso una pluralità di piattaforme di distribuzione ed à ̈ operativamente associabile ad almeno un apparato di riproduzione che à ̈ atto a riprodurre contenuti video; il metodo prevede di: identificare un contenuto video da riprodurre; identificare almeno una piattaforma attiva tra una pluralità di piattaforme distribuzione su cui il contenuto video da riprodurre à ̈ correntemente trasmesso; selezionare la ricezione del contenuto video attraverso la piattaforma attiva; generare un segnale di uscita, che comprende il contenuto video in forma riproducibile, da inviare all’apparato di riproduzione.

Preferibilmente, la pluralità di piattaforme comprende almeno una prima piattaforma di tipo broadband ed almeno una seconda piattaforma di tipo broadcast, e si prevede di: commutare tra la prima piattaforma e la seconda piattaforma o viceversa, per selezionare la piattaforma attiva su cui il contenuto video di interesse à ̈ ricevuto. Preferibilmente, la piattaforma di tipo broadcast à ̈ una piattaforma di televisione satellitare, dal momento che i fornitori di contenuti in quest’ambito sfruttano tipicamente una pluralità di piattaforme di distribuzione, e possono trarre vantaggio da un impiego ottimale delle stesse.

Preferibilmente, per identificare il contenuto video si provvede alla lettura di un identificativo ad esso associato, e l’apparato di ricezione video comunica e trasmette remotamente, ovvero all’esterno, l’identificativo mediante almeno una delle piattaforme.

Preferibilmente, si prevede di: segnalare informazioni relative alla pluralità di piattaforme di distribuzione da cui l’apparato di ricezione à ̈ atto a ricevere i contenuti video. Preferibilmente, tale segnalazione di informazioni e/o la trasmissione dell’identificativo sono effettuate ad un server remoto.

Preferibilmente, la commutazione tra la prima piattaforma e la seconda piattaforma o viceversa, avviene in conseguenza alla ricezione di un comando impartito remotamente all’apparato di ricezione video, in cui il comando dipende dalle informazioni relative alla pluralità di piattaforme, o dall’identificativo stesso. In questo modo, la commutazione tra la prima piattaforma e la seconda piattaforma o viceversa può avvenire in base a criteri stabiliti centralmente, per esempio dal fornitore di contenuti video, che ha così modo di stabilire politiche di distribuzione su varie piattaforme di distribuzione, che possano ottimizzare l’utilizzazione della piattaforma per esempio prevedendo l’utilizzo di piattaforme broadcast per un largo numero di utenti, o di piattaforme broadband per utenti che siano in numero più ridotto o siano sparsamente distribuiti in località remote tra loro.

La presente invenzione si riferisce inoltre ad un relativo apparato di ricezione video, che à ̈ atto ad essere operativamente connesso mediante opportuni mezzi di collegamento (per esempio mediante una connessione wireless o via cavo) ad un apparato di riproduzione video, e a mezzi di elaborazione video, atti a: ricevere contenuti video attraverso una pluralità di piattaforme di distribuzione; identificare un contenuto video da riprodurre; identificare almeno una piattaforma attiva tra la pluralità di piattaforme su cui il contenuto video da riprodurre à ̈ correntemente trasmesso; l’apparato di ricezione à ̈ poi atto a configurare i mezzi per ricevere i contenuti video, in modo da selezionare la piattaforma attiva; l’apparato di ricezione à ̈ quindi atto ad inviare il contenuto video da riprodurre all’apparato di riproduzione, generando un segnale video da esso riproducibile.

Preferibilmente, i mezzi di elaborazione video comprendono mezzi di connessione tra cui una prima connessione di tipo broadband ed almeno una seconda connessione di tipo broadcast, e l’apparato di ricezione comprende ulteriormente mezzi per commutare tra la connessione broadband e quella broadcast o viceversa. Preferibilmente, la connessione broadcast à ̈ verso una piattaforma di televisione satellitare.

Preferibilmente, il contenuto video à ̈ identificato tramite la lettura di un identificativo associato al contenuto video e ricevuto mediante i mezzi di connessione, e l’apparato di ricezione video à ̈ atto a segnalare remotamente, ovvero all’esterno, detto identificativo mediante almeno una delle connessioni. Preferibilmente, l’apparato di ricezione video comprende ulteriormente mezzi di segnalazione che segnalano informazioni relative alla pluralità di piattaforme, ed ulteriormente l’identificativo.

Preferibilmente, l’apparato di ricezione video comprende almeno una connessione ad un server remoto dal quale può ricevere e al quale può inviare segnali e dati informativi.

Preferibilmente, l’apparato di ricezione comprende mezzi atti a ricevere comandi impartiti remotamente, in cui i mezzi per commutare sono atti a eseguire operazioni di commutazione che dipendono dai comandi impartiti remotamente.

Altre caratteristiche tecniche vantaggiose della presente invenzione saranno più evidenti considerando le rivendicazioni allegate, le quali formano parte integrante della presente descrizione.

[BREVE DESCRIZIONE DEI DISEGNI]

Alcuni esempi di realizzazione preferiti e vantaggiosi vengono descritti a titolo esemplificativo e non limitativo, con riferimento alle figure allegate, in cui:

- la Figura 1 esemplifica il metodo di elaborazione di un contenuto video secondo la presente invenzione;

- la Figura 2 esemplifica uno schema a blocchi di una prima forma di realizzazione dell’apparato di ricezione, ovvero un server video locale secondo l’invenzione;

- la Figura 3 esemplifica uno schema a blocchi di una seconda forma di realizzazione dell’apparato di ricezione, ovvero un set-top-box ibrido secondo l’invenzione.

Le figure illustrano differenti aspetti e forme di realizzazione della presente invenzione e, dove appropriato, strutture, componenti, materiali e/o elementi analoghi in differenti figure sono indicati da uguali riferimenti; l’eventuale lettera finale diversa, in stessi riferimenti numerici, indica diverse forme di realizzazione del medesimo elemento.

[DESCRIZIONE DETTAGLIATA DELL’INVENZIONE]

La presente invenzione trova un ambito di realizzazione nelle tecnologie radiotelevisive (in particolare satellitari), in cui i set-top-box o apparati riceventi siano al contempo connessi alla rete Internet.

La presente invenzione trova un ambito di realizzazione, in aggiunta o alternativa a quello sopra menzionato, nella tecnologia DLNA (o in sistemi di condivisione di contenuti video, basati su principi equivalenti).

Si prevede che un contenuto video generico sia preferibilmente distribuito almeno mediante una piattaforma di distribuzione broadband di tipo CDN “Content Delivery Network†, ovvero con costi proporzionali al numero di utenti che visionano il contenuto video; questo scenario diverrà sempre più diffuso, specie con l’adozione di sistemi a banda larga, quali per esempio i cellulari LTE.

Si prevede in particolare che il contenuto video sia distribuito su piattaforme di tipo broadband secondo modalità di “streaming live†per assicurare la sincronia e la contemporaneità del contenuto stesso a tutti gli utenti che lo visualizzano.

Per semplicità nella presente descrizione ci si riferisce a “contenuti video†volendo intendere con tale espressione dei contenuti audiovisivi comprendenti componenti video, audio ed eventualmente anche associati dati informativi, di segnalazione o controllo (dati EPG, teletext, MHP, identificativi di sorgente o canale, eccetera), quali per esempio quelli compresi in un transport stream MPEG composto secondo una delle norme previste dagli standard DVB, ATSC, e così via.

Si prevede inoltre che gli apparati di riproduzione (di seguito più brevemente i “player†), anche mentre sono in riproduzione di un contenuto video che stanno ricevendo in “streaming†da una CDN, possano svolgere delle ulteriori funzioni utili per la gestione della CDN stessa. I player sono quindi atti a connettersi operativamente (via cavo, o via wireless, eventualmente mediante una semplice installazione di un’apposita applicazione) a dispositivi di ricezione, i quali possono comunicare al fornitore del contenuto (per mezzo di server a cui sono connessi) le seguenti informazioni: il tipo di player che sta riproducendo il contenuto, se il player si trova in una rete, per esempio di tipo DLNA, e se in tale rete sono disponibili dispositivi di ricezione da altre piattaforme, quali per esempio piattaforme broadcast.

Tali informazioni sono quindi segnalate “esternamente†, ovvero a dispositivi e/o apparati remoti rispetto all’apparato di ricezione video, che si trovano quindi al di fuori dell’ambiente domestico e sono appunto disponibili al fornitore di contenuti o al fornitore dei servizi di connessione delle piattaforme utilizzate dai fornitori di contenuti.

Disponendo di tali informazioni, i sistemi adottati del fornitore di contenuti sono così in grado di: notificare al player l’eventuale disponibilità del contenuto video su una piattaforma, in particolare broadcast, a cui l’apparato di ricezione si può connettere, ad esempio facendo apparire un’icona sullo schermo, oppure mandando un messaggio su qualche altro apparato; in questo caso l’utente può decidere di passare la ricezione del contenuto video sulla piattaforma broadcast beneficiando, ad esempio, di una qualità video superiore.

Disponendo di tali informazioni, i sistemi adottati del fornitore di contenuti sono poi in grado di interrompere il flusso streaming ed attivare automaticamente la ricezione sulla rete broadcast, nel caso il profilo di servizio dell’utente in questione lo consenta.

Disponendo di tali informazioni, i sistemi adottati del fornitore di contenuti sono poi in grado di attivare una piattaforma di broadcast apposita, nel caso in cui la CDN sia sovraccarica a causa di numerosi utenti collegati ed il contenuto video non sia ancora distribuito su piattaforma broadcast; il fornitore di contenuti può quindi valutare la convenienza ad occupare risorse broadcast adibite allo scopo di distribuire contenuti video che occasionalmente (ed imprevedibilmente) presentano dei picchi di “share†; l’attivazione di tale distribuzione su piattaforma broadcast permette di “migrare†un certo numero di utenti (quelli che possono supportare questa procedura, e che sono noti al fornitore di contenuti, grazie alle notifiche sopra previste) sulla distribuzione broadcast “alleggerendo†il carico sulla CDN.

Analogamente, i sistemi adottati del fornitore di contenuti sono anche in grado di disattivare una piattaforma broadcast nel caso un numero esiguo o comunque non sufficiente di utenti stia visualizzando il contenuto video, ed attivare una CDN apposita su cui subentri la trasmissione del medesimo contenuto video, e su cui dirottare gli apparati di ricezione degli utenti, in maniera automatica impartendo un comando da remoto. Il fornitore di contenuti può quindi valutare la convenienza a liberare risorse broadcast per distribuire contenuti video che presentano “share†ridotti; l’attivazione di tale distribuzione su piattaforme broadband permette di non caricare eccessivamente la CDN, ed al contempo di liberare risorse broadcast vantaggiosamente utilizzabili per altre trasmissioni, per esempio per diversi contenuti video.

Il metodo può essere oggetto di numerose varianti, in particolare qualora la rete a cui à ̈ connesso il player sia una rete pubblica, strutturata ad “isole†dotate di server idonei a svolgere le funzioni di un server DLNA, o funzioni analoghe. Tali “isole†potrebbero essere Hot-spot wireless o singole celle di una rete cellulare. In tal caso il metodo potrebbe prevedere una variante secondo cui il fornitore di contenuti può reperire le suddette informazioni, non solo dal player, ma anche dai server locali stessi. La procedura di trasmissione delle informazioni potrebbe quindi essere svolta in diversi modi, purché le informazioni siano reperite e quindi trasmesse ai sistemi di gestione a cura del fornitore di contenuti.

Con riferimento alla Figura 1, si descrive ora una forma di realizzazione esemplificativa e non limitativa, in cui si definiscono blocchi funzionali, i quali possono o meno coincidere con apparati o dispositivi fisici distinti, oppure possono essere dei sistemi o apparati comprendenti più dispositivi, oppure possono essere funzioni integrate in un unico apparato, che potrebbe svolgere anche funzioni aggiuntive.

Il sistema di ricezione video 101 comprende almeno un apparato di riproduzione 102 o player 102. Il player 102 può per esempio essere un televisore connesso ad una rete DLNA, oppure un tablet PC, etc., atto a riprodurre un contenuto video, oppure un tradizionale schermo (in inglese, display) radiotelevisivo atto ad essere connesso ad un ricevitore/decodificatore o ad un set-top-box.

Il sistema di ricezione video 101 comprende poi almeno un apparato di ricezione video 103, che può includere anche funzioni di decodifica dello stream video per veicolarlo all’apparato di riproduzione 102. L’apparato di ricezione video 103 può essere per esempio un set-top-box ibrido, connesso ad una pluralità di piattaforme di distribuzione tra cui piattaforme satellitari come sarà descritto nel seguito. In generale l’apparato di ricezione 103 può comprendere una pluralità di funzioni aggiuntive, e sarà in tal caso definito nel seguito “Server Video Locale†.

Le Figure 2 e 3 dettagliano la struttura e il funzionamento di un apparato di ricezione video secondo l’invenzione, rispettivamente in caso di Server Video Locale (103a) e di set-top-box ibrido (103b).

A tal proposito, si può prevedere uno scenario in cui una pluralità di apparati di riproduzione 102 siano connessi ad un medesimo apparato di ricezione 103, ovvero al medesimo Server Video locale per esempio in ambito DLNA; per semplicità se in Figura 1 se ne à ̈ riportato solo uno.

Un’altra forma di realizzazione preferita dell’apparato di ricezione video 103 prevede che esso sia dotato di una connessione ad almeno una parabola satellitare, comprenda un decoder satellitare per esempio del tipo DVB-S, e comprenda inoltre una connessione ad Internet, per esempio di tipo LAN o Wi-Fi, risultando quindi essere un set-top-box ibrido.

I contenuti video da riprodurre sono originati da una sorgente di contenuti 104, che potrebbe rappresentare anche una pluralità di sorgenti tra loro aggregate. In generale, i contenuti video sono gestiti dal fornitore di contenuti video e resi accessibili agli utenti tramite la sorgente di contenuti 104.

Si prevedono due tipologie di piattaforme di distribuzione (in Inglese: delivery): le piattaforme broadband 105, quali CDN basate su reti broadband di tipo web/telecom e che sono soggette ad essere congestionate al crescere del numero di utenti che le usano contemporaneamente, e le piattaforme broadcast 106 (satellite, digitale terrestre, cavo, etc.) che sono invece insensibili al numero di utenti che vi si collegano contemporaneamente.

Secondo l’invenzione, la connessione alle piattaforme di distribuzione 105 e 106 à ̈ basata sullo scambio di opportune informazioni tra i vari blocchi funzionali rappresentati.

In particolare, si prevede che il sistema di riproduzione video 101 sia atto a realizzare connessioni operative tra i vari blocchi funzionali, sia internamente (verso l’apparato di ricezione 103 e l†̃apparato di riproduzione 102) che esternamente (verso le piattaforme 105 e 106). Si prevede inoltre che il sistema di riproduzione video 101 sia atto ad eseguire comandi, impartiti dall’utente o dal fornitore di contenuti, come sarà più chiaro nel seguito.

Si prevede che il sistema di riproduzione video 101 sia ulteriormente atto ad interfacciarsi con un server remoto 107, connettendosi operativamente e scambiando messaggi ed informazioni secondo opportuni protocolli, stabili dall’operazione dell’apparato di ricezione 103. Il server remoto 107 sarà quindi definito nel seguito “Delivery Management Server†.

Secondo la forma di realizzazione preferita esemplificata, il sistema video 101, ed in particolare il server video locale 103 o set-top-box ibrido 103 à ̈ atto a comunicare al Delivery Management Server 107: il contenuto video attualmente in riproduzione; la piattaforma di distribuzione da cui esso à ̈ ricevuto, ovvero 105 o 106; la sorgente 104 da cui esso à ̈ tratto; le piattaforme di distribuzione alternative a cui si à ̈ connessi, ovvero l’altra tra 105 e 106 rispetto a quella di cui al punto precedente.

Il Delivery Management Server 107 à ̈ atto quindi a monitorare: lo stato della piattaforma broadband 105 (o le piattaforme, se più d’una) a cui il server video locale 103 à ̈ atto a connettersi; la disponibilità di banda sulla piattaforma broadband 105 suddetta; l’eventuale presenza di una trasmissione del contenuto video su una piattaforma broadcast 106 disponibile al server video locale 103.

Il Delivery Management Server 107 à ̈ ulteriormente atto a calcolare o valutare quale piattaforma di distribuzione tra la piattaforma broadband 105 e la piattaforma broadcast 106 sia la più idonea all’attuale distribuzione del contenuto video in oggetto. Si possono prevedere vari criteri, tra cui per esempio: un minor costo economico per il fornitore di contenuti; un maggiore bit rate consegnato all’utente (in generale, se possibile e giustificato dal numero di utenti attivi, à ̈ sempre preferibile la distribuzione broadcast).

Il Delivery Management Server 107 à ̈ ulteriormente atto a comunicare al fornitore dei contenuti della sorgente 104, l’opportunità di commutare la distribuzione su un’altra tipologia piattaforma, in base ad opportuni criteri determinati su base economico/statistica.

Il Delivery Management Server 107 à ̈ ulteriormente atto a comandare il server video locale 103 in modo che sia effettuata la commutazione della ricezione sulla piattaforma così prescelta. Può essere previsto o meno che il Delivery Management Server 107 richieda un’autorizzazione di conferma prima di far eseguire la commutazione all’apparato di ricezione; tale autorizzazione può essere automatizzata, o fornita dall’utente stesso.

La Figura 2 illustra in dettaglio la struttura di principio di un server video locale 103a secondo una forma di realizzazione esemplificativa dell’invenzione. Le linee di controllo e segnalazione sono riportate in linea tratteggiata, le linee di collegamento di segnale con linea continua; quest’ultima à ̈ ingrossata se il contenuto video à ̈ incapsulato in un flusso contenitore che può potenzialmente contenere anche altri contenuti, quali metadati; i blocchi opzionali sono rappresentati con contorno tratteggiato. Le componenti elementari del contenuto video, quali la componente video e quella audio sono pertanto rappresentate con una linea sottile. Il server video locale 103a presenta un sintonizzatore 201a, per esempio di tipo DVB-T o T2, DVB-S o S2, DVB-C o C2, in grado di sintonizzare la ricezione su di un contenuto video, incapsulato in un qualsiasi formato contenitore utilizzato per la trasmissione di segnali radiotelevisivi, quali il transport stream MPEG2. Nel transport stream possono essere incapsulati anche ulteriori segnali o comandi di controllo, provenienti dal service provider che possono essere utilizzati dal ricevitore. Il sintonizzatore 201 ed altri blocchi funzionali possono essere controllati dall’unità di governo 202a dell’apparato (CPU), di solito costituita da un microprocessore in grado di sovrintendere al funzionamento dell’intero apparato 103a.

Pertanto l’unità di governo 202a à ̈ rappresentata essendo collegata alle altre unità funzionali dell’apparato 103a con apposite linee di segnalazione e controllo, di solito bidirezionali, tramite le quali l’ unità di governo 202a può ricevere dati sullo stato di funzionamento delle ulteriori unità ad essa collegate, ed impartire specifici comandi indirizzati ad esse.

Il Server Video Locale 103a à ̈ dotato anche di una interfaccia IP 203a di ingresso, per esempio un ricetrasmettitore in grado di ricevere e trasmettere dati digitali a pacchetto secondo il sistema TCP/IP, sia mediante rete LAN o mediante protocolli Wireless. Tipicamente anche qui il contenuto video (per esempio un servizio radiotelevisivo digitale) viene incapsulato insieme ad altri servizi radiotelevisivi dello stesso tipo, in un flusso contenitore (per esempio un transport stream MPEG). I segnali di uscita del sintonizzatore 201a e dell’interfaccia IP 203a vengono addotti ad un selettore di ingresso 204a in grado di convogliare su uno dei due terminali di uscita uno dei due segnali di ingresso, in base al comando di selezione arrivante a un suo apposito ingresso collegato alla CPU 202a.

Il sintonizzatore 201a e l’interfaccia IP 203a costituiscono i mezzi di connessione dell’apparato 103a rispettivamente con le piattaforme di distribuzione video 105 e 106.

Il Server Video Locale 103a rappresentato in Figura 2 presenta preferibilmente due diverse linee di elaborazione interne del contenuto video, poste tra il selettore di ingresso 204a e un selettore di uscita 205, avente due terminali di ingresso ed un terminale di uscita.

Questo parallelismo a due vie nelle linee di elaborazione si adatta vantaggiosamente alle caratteristiche degli apparati di riproduzione (Tablet PC, smartphone, etc.) associabili all’uscita del Server Video Locale 103a, ed alla banda di trasmissione disponibile sul canale di collegamento per il segnale di uscita 220 tra il Server Video Locale 103a e gli apparati di riproduzione.

Se gli apparati di riproduzione sono in grado di trasmettere, ricevere ed elaborare un intero flusso video contenitore, che comprenda diversi contenuti video (per esempio servizi radiotelevisivi) ed estrarre dal flusso video contenitore il particolare contenuto video selezionato dall’utente per la riproduzione viene utilizzato la linea inferiore, costituita da un semplice by-pass; questa modalità à ̈ vantaggiosamente utilizzata secondo criteri che saranno descritti in dettaglio nel seguito.

Se invece la banda disponibile per la trasmissione del segnale 220 uscente dall’interfaccia IP 209 sulla linea di collegamento tra Server Video Locale 103a e gli apparati di riproduzione 102 à ̈ limitata, o l’apparato di riproduzione 102 à ̈ in grado di elaborare flussi contenitori comprendenti un solo contenuto video, allora il flusso video di ingresso contenente il contenuto video selezionato viene vantaggiosamente dirottato sulla linea interna superiore, dove le componenti audio e video del contenuto video vengono estratte dal flusso di ingresso mediante un demultiplatore 206a, eventualmente decodificate e ricodificate in via opzionale tramite un banco di codificatori e decodificatori audio e video 207 e successivamente multiplati da un multiplatore 208 in un flusso contenitore di uscita, contenente perciò il solo contenuto video in forma direttamente processabile dall’apparato di riproduzione in questione.

In generale, l’operazione di co-decodifica può essere prevista se il riproduttore supporta solo particolari metodi di decodifica di sorgente, o se à ̈ necessario comprimere maggiormente il segnale audio e/o video sorgente per la limitata banda disponibile sul canale di collegamento tra Server Video Locale 103a e apparati di riproduzione 102.

In entrambi i casi sopra descritti, il selettore di uscita 205 convoglia il flusso video così processato, dalle linee interne all’unica uscita da cui viene trasmessa agli apparati di riproduzione connessi tramite l’interfaccia IP di uscita 209. Quest’ultima può utilizzare per la trasmissione ai riproduttori un canale o linea di collegamento per il segnale di uscita 220 conforme al protocollo DLNA basato a sua volta sul protocollo TCP/IP, vuoi tramite collegamento su cavo Ethernet vuoi tramite collegamento senza fili (Wi-Fi), o attraverso altre connessioni di tipo noto.

Aggiuntivamente può essere previsto nel server video locale 103a almeno un banco di processori video e audio, non rappresentato in Figura 2, cui vengono condotti i segnali di uscita del banco di decodificatori video e audio per essere associati mediante una apposita linea di collegamento a un apparato riproduttore audiovisivo 102 in grado di riprodurre flussi audio e video già decodificati, come si vedrà più in dettaglio nella descrizione a proposito della Figura 3.

In ogni caso l’interfaccia IP di uscita 209 e il banco di processori audio e video eventualmente presente costituiscono mezzi di interfaccia con almeno un apparato riproduttore 102 associabile all’apparato ricevitore 103a, al quale sono in grado di fornire il contenuto video in forma da esso riproducibile.

Ovviamente il contenuto video contiene in genere anche altri dati di segnalazione e controllo, quali il nome della stazione, il titolo del programma in corso di trasmissione, la frequenza di trasmissione, il nome del bouquet o transport stream contenitore, nonché dati informativi utili veri e propri quali per esempio un servizio teletext, dati EPG (Electronic Program Guide), dati MHP (Multimedia Home Platform); per semplicità in Figura 2 (e anche nella successiva Figura 3) sono stati rappresentate solo le linee di flusso delle componenti audio e video.

In particolare, se la banda disponibile sull’interfaccia IP di uscita 209 à ̈ limitata, conviene che il multiplatore 208 produca in uscita un transport stream contenente il solo contenuto video da riprodurre su un associato apparato riproduttore; se per esempio l’utente ha selezionato il servizio tv digitale RAI3 il multiplatore 208 genera un flusso contenitore di uscita comprendente le sole componenti (audio, video, teletext, dati ancillari, dati EPG, nome della stazione e titolo del programma, eccetera) appartenenti al servizio digitale RAI3, mentre vengono scartate le componenti appartenenti ad altri contenuti video, per esempio quelli di RAI1, RAI2 e RAI4 presenti nel flusso contenitore di ingresso.

Si illustra ora in maggior dettaglio il funzionamento del Server Video Locale 103a secondo l’invenzione.

Supponiamo che l’utente dell’apparato di riproduzione abbia selezionato un certo contenuto video per visionarlo, per esempio quanto trasmesso sulla rete radiotelevisiva RAI3 che supponiamo essere l’evento musicale dal titolo “Concerto del primo Maggio†.

Il Server Video Locale 103a riceve dall’interfaccia DLNA bidirezionale di uscita 209 la richiesta dell’utente, la sua CPU 202a ordina al sintonizzatore 201a di sintonizzarsi sul canale di trasmissione in cui detto concerto à ̈ trasmesso, ovvero quello corrispondente al servizio radiotelevisivo RAI3, attraverso la piattaforma di broadcast 106.

Si suppone quindi che la rete radiotelevisiva RAI3 sia trasmessa in tale momento, anche sulla piattaforma CDN 105, e sia quindi ricevibile dal Server Video Locale 103a anche tramite la sua Interfaccia IP di ingresso 203a.

Se l’apparato (o gli apparati) di riproduzione connessi al Server Video Locale 103a à ̈ in grado di estrarre il contenuto video dal transport stream, la CPU 202a del Server Video Locale 103a ordina al selettore di ingresso 204a di dirottare il flusso di ingresso sulla linea inferiore di by-pass, e ordina al selettore di uscita 205 di convogliare verso l’Interfaccia IP di uscita 209 il segnale presente sulla linea suddetta. La CPU 202a à ̈ quindi a conoscenza del contenuto video in corso di riproduzione sull’apparato riproduttore in esempio (RAI3) e può aggiuntivamente, tramite un’apposita interrogazione, ricevere dall’apparato riproduttore l’informazione relativa al titolo del programma in corso di riproduzione, ovvero “Concerto del primo Maggio†che quest’ultima ha estratto dal flusso contenitore demultiplato. Inoltre la CPU 202a à ̈ a conoscenza della piattaforma di trasmissione (105 o 106, in questo esempio 106) utilizzata per ricevere e riprodurre il contenuto video: se per esempio il sintonizzatore 201a à ̈ di tipo DVB-T la piattaforma radiotelevisiva di ricezione broadcast 106, à ̈ la rete di trasmissione radiotelevisiva digitale terrestre DVB-T.

Se diversamente da quanto sopra ipotizzato, à ̈ invece necessario inviare all’apparato riproduttore un flusso contenitore comprendente il solo contenuto video selezionato, per la riproduzione viene utilizzata la linea interna di elaborazione superiore. In tal caso il demultiplatore 206a estrae le componenti dei contenuti video incapsulati nel flusso contenitore, e può inviare alla CPU 202a oltre al nome della stazione, per esempio “RAI3†, ad essa comunque già nota in quanto ricevuta nella richiesta proveniente dall’apparato riproduttore, anche il titolo del programma in corso di trasmissione, la sua durata e altre informazioni relative al contenuto video da riprodurre, in quanto anch’essi incapsulati in appositi campi del transport stream.

La CPU 202a, secondo modalità stabilite dal firmware presente, per esempio in una memoria 210a ad esso associata, memorizza l’identificativo del contenuto video che permette al service provider 104 del contenuto video di identificarlo. L’identificativo può comprendere per esempio il nome della stazione “RAI3†, il codice LCN (Logical Channel Number), un codice identificativo di stazione associato al servizio televisivo RAI3, uno o più valori dei campi previsti dagli enti di standardizzazione radiotelevisivi a tale scopo (per esempio, per il transport stream MPEG: Network_Name, Network_Country_Code, Network, Operator Network_ID, Original Network ID, Platform_ID, Bouquet_ID, eccetera) che vengono trasmessi congiuntamente al contenuto video su una sua qualsiasi piattaforma di distribuzione. Gli identificativi del contenuto video possono variare da una piattaforma a un'altra, pur identificando uno stesso contenuto video, e possono contenere indicazioni anche sul tipo di piattaforma utilizzata per la trasmissione del contenuto video, anche se - come già detto - l’apparato di ricezione video 103a à ̈ già a conoscenza di tale informazione.

La CPU 202a causa l’invio a un server remoto gestito dal service provider del contenuto video, per esempio al server 107, l’identificativo del contenuto video, per esempio tramite l’Interfaccia IP di ingresso 203a che consente una comunicazione bidirezionale da e verso l’apparato di ricezione 103. Preferibilmente la CPU 202a causa l’invio congiuntamente anche di un dato segnalante la piattaforma di distribuzione usata per la ricezione (nell’esempio la piattaforma broadcast 106, per esempio DVB-T). Alternativamente l’invio può avvenire anche tramite una linea dedicata, quale per esempio una linea telefonica tramite un MODEM.

In tal modo il fornitore del contenuto video 104 (nell’esempio la RAI) viene a sapere su quale delle molteplici piattaforme di distribuzione in uso, un certo contenuto video (nel nostro esempio il servizio tv RAI3 trasmesso sulla piattaforma DVB-T e sulla piattaforma CDN via Internet) viene effettivamente ricevuto dall’utenza. Qualora la RAI decida per qualsiasi ragione di modificare l’utilizzo delle piattaforme di distribuzione per la trasmissione del contenuto video (RAI3 tramite piattaforma DVB-T o Internet), essa può far inviare dal server remoto 107 un comando che induca una parte o tutti gli apparati di ricezione 103 riceventi RAI3 di cambiare la piattaforma di ricezione in uso per adeguare la ripartizione d’uso delle piattaforme alle nuove esigenze del fornitore 104. Se per esempio l’ascolto del Concerto del primo Maggio à ̈ molto basso, il server remoto 107 può far commutare tutti i ricevitori 103 sulla piattaforma CDN Internet, e incominciare a trasmettere sul canale broadcast DVB-T prima occupato dal servizio RAI3 qualcos’altro, per esempio un altro servizio radiotelevisivo o cessare del tutto la sua trasmissione per risparmiare. In via aggiuntiva, si può prevedere che la CPU notifichi all’apparato riproduttore il cambiamento di piattaforma ed, eventualmente, altre informazioni associate quali per esempio l’informazione sul programma o servizio che sta per essere trasmesso sul canale broadcast prima occupato da RAI3 DVB-T. L’apparato riproduttore 102, alla ricezione della notifica suddetta, può visualizzare sul display un messaggio che avvisa l’utente del cambiamento della piattaforma utilizzata per ricevere il contenuto video in corso di riproduzione.

Qualora la RAI abbia deciso di effettuare una modifica dell’utilizzo delle piattaforme di distribuzione di RAI3, essa può inviare attraverso il server remoto 107 un comando di commutazione su diverse piattaforme, a seconda dei casi. Se per esempio si vogliono commutare tutti i ricevitori di RAI3 su una determinata piattaforma, allora à ̈ possibile utilizzare sia la piattaforma broadcast 106 che quella broadband 105 per la trasmissione del comando. Qualora invece si volesse commutare solo una parte dell’utenza (per esempio far passare la quota che riceve il contenuto video sulla piattaforma broadband 105 (Internet) dal 30% al 50%) allora à ̈ vantaggioso inviare il comando di commutazione tramite la stessa piattaforma broadband 105, che consente di inviare segnali punto-punto ad uno specifico sottoinsieme dei ricevitori 103 che sono raggiungibili singolarmente, in quanto individuati da uno specifico indirizzo (ovvero l’indirizzo IP), noto al fornitore dei servizi, per la natura del meccanismo di funzionamento di una rete IP. Questa possibilità à ̈ invece esclusa su una piattaforma di tipo broadcast 106, che per sua stessa natura invia il medesimo contenuto contemporaneamente a tutti i ricevitori sintonizzati nell’area di copertura, senza la possibilità di escluderne alcuno.

Se si vuole utilizzare un canale della piattaforma broadcast 106, à ̈ necessario inviare l’uno dopo l’altro a tutti i ricevitori 103 interessati (ma esso viene inviato anche a quelli non interessati) un comando di commutazione associato a un codice identificativo, il quale à ̈ a sua volta associato a ciascun apparato ricevitore 103 (per esempio il numero dell’abbonamento, o il numero seriale dell’apparato ricevitore 103). La CPU 202a à ̈ a conoscenza di tale codice, in quanto memorizzato in modo permanente nella memoria 210a; qualora il codice associato al comando di commutazione coincida col codice rilevato dalla CPU 202a, essa provvede ad eseguire il comando di commutazione. Se si vuole utilizzare il sopra esposto meccanismo, il fornitore di servizi deve essere preventivamente a conoscenza dei codici identificativi degli apparati di ricezione 103 che stanno ricevendo il contenuto video interessato alla commutazione (nell’esempio RAI3); questo scenario à ̈ più facile a verificarsi nel caso di apparato ricevitore costituito da un set-top-box proprietario, ovvero fornito dallo stesso fornitore di servizi.

Tale scenario à ̈ più frequente nel caso di set-top-box ibridi per televisione satellitare. Si può prevedere che, periodicamente o in corrispondenza di ogni nuova selezione del contenuto video da riprodurre, la CPU 202a causi l’invio al server remoto 107 non solo dell’identificativo di contenuto video, ma anche congiuntamente del proprio codice identificativo. In via alternativa, la CPU 202a può anche inviare al server remoto 107 il proprio indirizzo IP, il MAC address dell’interfaccia IP 203 e/o qualsiasi altra informazione in grado di identificare in modo univoco l’apparato ricevitore 103a. L’invio può avvenire mediante l’interfaccia IP di ingresso 203a, collegata al server remoto 107 mediante Internet, o alternativamente mediante una linea dedicata (per esempio la linea telefonica). L’invio dell’identificativo del ricevitore può essere omessa se il server remoto 107 à ̈ in grado di identificare il mittente dei dati inviatigli da un apparato ricevitore in altro modo, come avviene per i pacchetti dati IP ricevuti che contengono l’indirizzo di sorgente del pacchetto.

Il comando emesso dal fornitore di servizi 104 tramite il server remoto 107, può vantaggiosamente essere di tipo condizionale nel senso che esso à ̈ di questo tenore o viene comunque interpretato dai ricevitori in senso condizionato: “se tu apparato ricevitore stai ricevendo il contenuto video X sulla piattaforma 1, allora devi d’ora in poi riceverlo tramite la piattaforma 2 operando la commutazione tra le piattaforme†. La CPU 202a, in tal caso, à ̈ atta a verificare se l’apparato di ricezione 103a soddisfa la condizione suddetta, e commuta solo in caso positivo, in modo da evitare indesiderate commutazioni di piattaforma e/o di contenuto video ricevuto nel caso in cui la condizione non sia soddisfatta.

Quanto alla specifica posizione di inserimento del comando all’interno del flusso contenitore, operato da parte del fornitore, si può prevedere la presenza opzionale di dati riservati, detti “private data†, in cui il produttore del transport stream può inserire informazioni proprietarie non standardizzate. Tali informazioni proprietarie non standardizzate sono utili per scopi particolari quali quelli previsti dalla presente invenzione, dal momento che apparati di ricezione non secondo la presente invenzione sarebbero liberi di ignorare tali informazioni. In linea generale, i comandi per gli apparati di ricezione 103 possono essere trasmessi in forma di codice eseguibile, in forma di istruzioni di codice sorgente (per esempio linguaggio JAVA o codice MHP) oppure in forma di semplici dati informativi la cui chiave di lettura à ̈ memorizzata all’interno degli apparati riceventi 103a per cui la CPU 202a à ̈ in grado di interpretarli correttamente.

Quanto detto nei paragrafi precedenti riguardo alla gestione da parte dell’ente radiotelevisivo delle trasmissioni sulle piattaforme di distribuzione video disponibili (105, 106) vale per qualsiasi tipo di apparato di ricezione 103, cioà ̈ sia per server video locali 103a, sia per i set-top-box ibridi 103b.

Esistono numerosi varianti alla forma di realizzazione di Server Video Locale 103a illustrata in Figura 2. Per esempio possono essere presenti ulteriori interfacce con ulteriori piattaforme di distribuzione di contenuti video broadcast e/o broadband: per esempio potrebbe essere presente un’interfaccia con la piattaforma DVB-T/T2 e/o una con la piattaforma DVB-S/S2, e/o una con la piattaforma Wimax, e/o una con la piattaforma LTE, e così via.

Il Server Video Locale 103a può presentare più di due linee interne di elaborazione del contenuto video (vuoi di tipo by-pass, vuoi di tipo demultiplazione e rimultiplazione) in modo da poter servire contemporaneamente diversi apparati di riproduzione 102 associati, ciascuno in grado di riprodurre a un certo istante contenuti video diversificati. In generale, potrebbero cambiare i selettori di ingresso e di uscita dell’apparato 103a, ma non il funzionamento del metodo di elaborazione secondo l’invenzione, che può essere applicato parimenti senza alcuna difficoltà.

Non à ̈ poi strettamente necessario che l’interfaccia IP di ingresso 203a sia fisicamente distinta da quella di uscita 209: in via di principio, i meccanismi di funzionamento propri del protocollo IP consentono di far svolgere i compiti delle due interfacce IP suddette anche dalla medesima interfaccia IP fisica (per esempio in forma di ricetrasmettitore TCP/IP), ma tali funzionalità sono state descritte in figura come realizzate da ricetrasmettitori IP separati per maggior semplicità di esposizione.

In Figura 3 à ̈ rappresentato un ulteriore esempio di realizzazione di un apparato di ricezione video 103 secondo l’invenzione, in una forma particolare di set-top-box ibrido 103b.

Per semplicità, si suppone che il set-top-box ibrido 103b sia privo dell’interfaccia IP di uscita di collegamento con gli apparati riproduttori, e dotato invece di una interfaccia di collegamento audio-video per un apparato di riproduzione (Audio & Video reproducer) a esso associabile.

Gli stadi di ingresso del set-top-box ibrido 103b (ovvero l’Interfaccia IP di ingresso 203b, il Sintonizzatore 201b, la CPU 202b, la Memoria 210b e il Selettore di ingresso 204b coincidono sostanzialmente con gli elementi descritti in relazione al Server Video Locale 103a di Figura 2 (con il suffisso “a†al numero di riferimento), così come il loro funzionamento relativo al metodo di elaborazione secondo l’invenzione. La descrizione di tali elementi non viene pertanto ripetuta qui, per brevità, e ci si soffermerà sulle differenze.

Come nel caso di Figura 2, si suppone che il sintonizzatore 201b e l’interfaccia IP 203b costituiscono i mezzi di connessione dell’apparato 103b rispettivamente con le piattaforme di distribuzione video 105 e 106. Come nel caso precedente del server video locale anche qui à ̈ possibile prevedere altri mezzi di connessione ad altre piattaforme di distribuzione video che cambieranno di caratteristiche a seconda della piattaforma con cui si interfacciano e della natura del segnale video che vi arriva.

Innanzitutto la struttura del set top box ibrido 103b risulta semplificata rispetto alla struttura del Video Server Locale 103a di Figura 2, poiché non à ̈ più necessario prevedere un’interfaccia IP di uscita per la trasmissione del segnale audio-video in forma riproducibile. In particolare, il set-top-box ibrido 103b comprende preferibilmente un’unica linea di elaborazione interna, per cui non à ̈ più necessario prevedere un selettore di uscita, e non à ̈ altresì necessario eventualmente ricodificare il contenuto video, ma solo decodificarlo; non à ̈ neppure necessaria la presenza di un’unità multiplatrice per incapsulare il contenuto video in un flusso contenitore da addurre ad una interfaccia di uscita.

Nel caso di set-top-box ibrido 103b, il contenuto video da riprodurre, per esempio il servizio radiotelevisivo SKY TG24, viene comunicato direttamente all’apparato di ricezione 103b video dall’utente tramite una tastiera o un telecomando, non rappresentato in Figura 3; nell’esempio suddetto va composto il numero di programma “500†.

L’unico selettore presente 204b (corrispondente a quello di ingresso di Figura 2) seleziona il flusso video contenitore comprendente il contenuto video da riprodurre sull’apparato di riproduzione 102, dall†̃interfaccia di ingresso alimentata dalla piattaforma di distribuzione 105 o 106 tramite l’interfaccia IP di ingresso 203b o il sintonizzatore 201b rispettivamente, decisa dalla CPU 202b secondo criteri già descritti, e segnalata tramite la apposita linea di segnalazione e controllo.

Il flusso selezionato dal selezionatore 204b viene addotto ad una unità demultiplexer 206b che estrae le componenti (audio, video, EPG, teletext, dati identificativi) del contenuto video da riprodurre. Le componenti audio e video vengono decodificate da appositi decodificatori 305 (per esempio conformi agli standard secondo MPEG2, MPEG4, HEVC, VC1 per il video e AAC, AAC+/HE-AAC, AC3, MPEG1 layer 3, MPEG2 layer 1 o 2 per l’audio), in conformità alle codifiche audio e video utilizzate dal fornitore di servizi in sede di produzione del contenuto.

Quindi le componenti audio e video vengono addotte ad appositi processori audio e video 301, che effettuano gli adattamenti di segnale necessari per essere consegnati a un apparato di riproduzione 102 audio-video, accoppiato all’interfaccia audio-video di uscita dei processori 301, tramite una linea di collegamento per il segnale di uscita 310. Gli adattamenti adottati dai processori 301 varieranno in base alle caratteristiche dell’interfaccia (analogica con audio e video separati tra loro quest’ultimo di tipo componenti Y, PB/CB, PR/CR, RGB o composito CVBS) oppure di tipo digitale (per esempio DVI e S/PDIF, o con audio-video unificato HDMI) e dell’apparato di riproduzione 102 stesso (per esempio, tenendo conto della risoluzione video supportata dallo schermo dell’apparato di riproduzione 102). Ovviamente à ̈ possibile prevedere la presenza aggiuntiva o sostitutiva di un’interfaccia IP di uscita, in grado di alimentare altri riproduttori tramite altrettante linee di collegamento per segnali di uscita 310 dai processori 301, per esempio riproduttori compatibili con il protocollo DLNA.

Supponiamo che si voglia alimentare i riproduttori 102 collegati all’interfaccia suddetta, con lo stesso contenuto video inviato all’interfaccia audio video.

Se occorre avere un flusso contenitore “ristretto†, ovvero comprendente il solo contenuto video da riprodurre, può essere previsto a valle del demultiplexer 206b un ripartitore (non rappresentato) che adduce aggiuntivamente le componenti del contenuto video da riprodurre a un multiplexer (non rappresentato) del tipo 208 di Figura 2, collegato alla interfaccia IP di uscita.

Se si volesse invece inviare ad un’Interfaccia IP di uscita (non rappresentata) tutto il flusso contenitore, sarebbe sufficiente interporre tra il selettore di ingresso 204b e il demultiplexer 206b un ripartitore a due uscite, che adduca il flusso selezionato sia al demultiplexer 206b sia ad una linea di by-pass (non rappresentata) collegata alla Interfaccia IP di uscita (non rappresentata) che si vuole aggiungere.

In entrambi i modi suddetti à ̈ comunque possibile inviare contemporaneamente a diversi apparati riproduttori 102 lo stesso contenuto video.

Se si volesse infine poter inviare contenuti video diversi sulla interfaccia audio-video 301 e su quella IP di uscita (non rappresentata) sarebbe necessario aumentare il grado di parallelismo di elaborazione video dell’apparato come già descritto con riferimento alle linee di elaborazione parallele del Server Video Locale di Figura 2.

Il processore video 301 e l’interfaccia IP di uscita eventualmente presenti nel set-top-box 103b costituiscono in combinazione i mezzi di interfaccia con almeno un apparato riproduttore 102 associabile all’apparato ricevitore 103b, al quale sono in grado di fornire il contenuto video in forma da esso riproducibile.

L’apparato di riproduzione 102 può essere indifferentemente esterno, oppure integrato nell’apparato di ricezione 103b: in quest’ultimo caso esso viene a costituire un sistema di riproduzione composto da un unico apparecchio tipo televisore.

Sono possibili numerose varianti implementative rispetto allo schema esemplificativo delle Figure 2 e 3: le funzioni svolte da alcuni blocchi funzionali possono essere svolte dalla stessa unità, unità rappresentate come entità separate possono essere integrate in un unico componente fisico o viceversa compiti svolti nelle Figure 2 e 3 dalla stessa unità possono essere eseguiti da blocchi funzionali diversi. Per esempio la CPU nonché i decoder audio e/o video possono essere implementati su uno stesso circuito integrato, i decodificatori possono essere realizzati totalmente in hardware, in software o in una loro combinazione, e così via.

Anche secondo quanto già descritto, rappresenta quindi una forma di realizzazione preferita della presente invenzione, quella in cui il server video locale 103a sia sostituito da un set-top-box 103b di tipo satellite e Internet (ibrido), cioà ̈ un set-top-box comprendente una connessione ad una parabola satellitare, ed al contempo una connessione ad Internet, per esempio di tipo LAN o WiFi.

L’apparato di riproduzione 102 può quindi per esempio comprendere uno o più schermi radiotelevisivi, operativamente connessi al set-top-box 103b. Nel caso di televisione satellitare (in particolare televisione a pagamento), il set-top-box 103b comprende funzionalità definite dal fornitore di contenuti stesso, per far fronte alle necessità di criptazione/decriptazione del segnale stesso, ed eventuali necessità di addebito del servizio (billing). Come detto, il set-top-box per esempio di tipo satellitare 103b comprende ulteriormente una connessione ad Internet 203b, tramite cui à ̈ possibile sia reperire aggiornamenti software/firmware, che accedere a contenuti video on-demand. Il fornitore di contenuti di televisione satellitare può quindi, in maniera semplice ed immediata, monitorare il set-top-box satellitare 103b e le richieste di contenuti video effettuate dagli utenti, tramite un canale di ritorno che sfrutti la suddetta connessione. Pertanto, un fornitore di contenuti di televisione satellitare si trova in condizioni privilegiate per implementare un Delivery Management Server 107 che sia asservito alle funzionalità già sopra descritte.

Per esempio, à ̈ possibile prevedere che un utente, tramite il proprio set-top-box 103b, stia visionando un particolare contenuto video attraverso la piattaforma broadband 105, ovvero Internet, per esempio un evento sportivo on-demand in diretta. Il fornitore di contenuti à ̈ quindi a conoscenza di quale contenuto video sta visionando l’utente, grazie proprio al canale di ritorno Internet, mediante il quale il set-top-box 103b comunica con il proprio Delivery Management Server 107 inviando l’identificativo del contenuto video in corso di riproduzione da un associato apparato di riproduzione. Vantaggiosamente il set-top-box 103b invia anche informazioni sulla particolare piattaforma (per esempio broadcast satellitare o broadband) utilizzata per ricevere il contenuto video identificato. In tal modo il service provider può venire a conoscenza dell’audience di un certo contenuto video in via di trasmissione (per esempio il programma diffuso su un servizio radiotelevisivo quale RAI2 o BBC3), nonché delle proporzioni in cui le piattaforme di trasmissione del contenuto sono effettivamente sfruttate dal bacino d’utenza. In tal modo esso può decidere a ragion veduta sulla gestione migliore della distribuzione del contenuto video ed eventualmente cambiare all’occorrenza la piattaforma utilizzata dagli apparati di ricezione video. Per esempio il service provider grazie alle informazioni raccolte dal bacino d’utenza può determinare che un certo programma radiotelevisivo (per esempio un concerto musicale) trasmesso contemporaneamente sulla piattaforma satellitare e via CDN Internet à ̈ visto dal 70% degli spettatori tramite broadcast satellitare e il rimanente 30% tramite la piattaforma broadband. Se l’utilizzo della piattaforma broadband scende al di sotto di un livello ritenuto critico il service provider può disattivare l’uso per quel contenuto video di questa piattaforma, dopo aver preventivamente fatto commutare sulla parallela piattaforma broadcast tutti gli apparati di ricezione video 103 che stavano utilizzando la piattaforma broadband per la ricezione del concerto musicale suddetto. In questo modo potrà utilizzare la CDN per altri servizi o comunque risparmiare economicamente se il costo della CDN dipende dal traffico smaltito dalla stessa.

Il fornitore di contenuti, analizzando statisticamente in maniera centralizzata le informazioni inviate dai settop-box 103b al Delivery Management Server 107, può valutare se à ̈ conveniente trasferire la trasmissione on-demand visualizzata su una diversa piattaforma, ovvero su un canale satellitare 106 a propria disposizione, e non altresì attualmente utilizzato. Il fornitore di contenuti di televisione satellitare, grazie alla maggiore disponibilità di banda disponibile, ha infatti, tipicamente, a disposizione un numero di canali satellitari maggiore di quelli mediamente utilizzati per le trasmissioni, per avere la possibilità di trasmettere un numero maggiore di contenuti video in momenti di picchi di richieste, per esempio durante eventi sportivi particolari quali i Campionati di sport molto seguiti, per esempio i Mondiali di calcio. Il fornitore di contenuti di televisione satellitare trova quindi desiderabile, se le circostanze verificabili tramite il Delivery Management Server 107 lo consentono, migrare la trasmissione del contenuto video richiesto dagli utenti su un canale satellitare 106; tale canale satellitare potrebbe risultare infatti altrimenti inutilizzato, e il fornitore di contenuti satellitari ha invece l’interesse a impiegare quanto più possibile i propri canali, ricorrendo all’uso di sistemi broadband/CDN 105 solo quando altrimenti non evitabile.

Il fornitore di contenuti di televisione satellitare può quindi avere a disposizione opportune modalità di controllo per la distribuzione dei contenuti video su piattaforme di distribuzione satellitari piuttosto che broadband, mediante l’intervento delle logiche di controllo del Delivery Management Server 107.

È possibile prevedere diverse modalità di controllo per la distribuzione dei contenuti video da parte del Delivery Management Server 107: il Delivery Management Server 107 può gestire direttamente i comandi di richiesta verso il fornitore di contenuti nella sorgente 104 e “forzare†quindi la commutazione del server video locale 103a o set-top-box 103b, oppure delegare al server video locale 103a o set-top-box ibrido 103b le operazioni di commutazione, come illustrato per gli esempi di realizzazione delle Figure 2 e 3. Similmente, il Delivery Management Server 107 può farsi carico di attivare la trasmissione su una certa piattaforma, per esempio il suddetto broadcast 106, oppure delegare ciò al fornitore di contenuti che gestisce la sorgente di contenuto 104, a seconda delle politiche di gestione adottate.

Si deve intendere che la funzionalità esemplificata con riferimento al Delivery Management Server 107 potrebbe essere svolta da apparati dedicati, potrebbe essere una funzione eseguita in modo centralizzato o distribuito, oppure potrebbe essere integrata nei sistemi costituenti una CDN.

Si prevede pertanto che un server video locale 103a, quale un Server DLNA, o un set-top-box ibrido 103b, siano atti a scambiare informazioni che riguardano le alternative possibilità di riproduzione di contenuti video sui player 102 della loro rete.

Si prevede inoltre che un Delivery Management Server 107 sia atto a valutare quali singoli “flussi di streaming†dei contenuti video possano essere rimossi eventualmente dalla CDN, in quanto sono riproducibili da player che hanno accesso ai medesimi contenuti video mediante piattaforme di distribuzione alternative. Si prevede inoltre che un Delivery Management Server 107 sovraintenda alle funzioni di coordinamento di tutti gli elementi del sistema coinvolti, quali il sistema di riproduzione video 101, i sistemi CDN 105, le piattaforme broadcast 106, i server video locali 103a o set-top-box ibridi 103b e i player 102.

Si prevede in particolare l'introduzione nel protocollo di richiesta di contenuto video (ad es. nel protocollo DLNA) di messaggi idonei a comunicare al fornitore di contenuti 104 il potenziale di ricezione dei player 102 tramite un server video locale 103a o set-top-box 103b, ed inoltre di messaggi idonei a segnalare ai player 102 la possibilità di commutare (ed eventualmente di forzare una commutazione) tra una piattaforma di distribuzione e un’altra.

[APPLICABILITÀ INDUSTRIALE]

Il metodo di elaborazione di contenuti video e l’apparato di ricezione video secondo l’invenzione, consentono ai fornitori di contenuti video di monitorare in tempo reale le potenzialità di ricezione/riproduzione video dei dispositivi di riproduzione connessi, nonché i contenuti video in corso di riproduzione e le piattaforme di distribuzione utilizzate per la loro ricezione. In virtù di dette informazioni, i fornitori di contenuti possono cooperare con i gestori di CDN in modo tale da distribuire i contenuti attraverso le diverse piattaforme disponibili, cercando così di ottimizzare l’efficienza delle infrastrutture, anche in tempo reale.

Grazie al metodo e sistema di riproduzione di contenuti video secondo l’invenzione, à ̈ possibile che il fornitore di contenuti e l’operatore di CDN distribuiscano su reti broadcast tutti i contenuti per cui vi sia possibilità e convenienza a ricorrere a tale tipo di piattaforma.

È possibile quindi prevedere uno scenario in cui i contenuti video ad alta percentuale d’ascolto e che necessitano di alta qualità siano distribuiti mediante piattaforme di distribuzione broadcast, ad es., anche satellitari, mentre i contenuti di nicchia o per cui non à ̈ richiesta un’elevata qualità video, siano distribuiti su una normale CDN mediante una piattaforma broadband.

In tal modo, il fornitore di contenuti video non sarà più legato ad un canale fisico di una specifica piattaforma di distribuzione. Un contenuto video potrà essere ricevuto dagli utenti attraverso una particolare piattaforma tra una pluralità di piattaforme, selezionata in funzione del tipo di contenuto video offerto, ed in funzione del numero di utenti interessati a tale contenuto.

Di converso, come accennato nel corso della descrizione di Figura 2 il fornitore di servizi può anche impiegare una piattaforma a costo più alto per un programma a basso ascolto e utilizzare quella a costo minore per trasmettere un contenuto video diverso che riscuoti un maggiore interesse o che sia comunque più proficuo.

Il metodo di elaborazione di contenuti video e l’apparato di ricezione video secondo l’invenzione possono essere applicati in particolare in uno scenario di diffusione dello standard DLNA (o di sistemi equivalenti). Il metodo di elaborazione di contenuti video e l’apparato di ricezione video secondo l’invenzione si applicano anche in ambienti con coperture Hot-spot Wireless, in cui venga inserito un opportuno server video locale, per esempio del tipo dei Server DLNA o un set-top-box dotato di funzionalità DLNA. Il metodo di elaborazione di contenuti video e l’apparato di ricezione video secondo l’invenzione si applicano anche in scenari in cui un fornitore di contenuti video mediante televisione per esempio satellitare, sfrutti un opportuno set-top-box che sia al contempo connesso ad Internet, mediante il quale un utente visualizza contenuti video.

La persona esperta del ramo può facilmente comprendere che molte ulteriori varianti sono possibili alla presente invenzione, senza dipartire dall’ambito di protezione delle seguenti rivendicazioni.

Claims (15)

1. RIVENDICAZIONI 1. Metodo di elaborazione di un contenuto video, in cui un apparato di ricezione (103) à ̈ atto a ricevere contenuti video attraverso una pluralità di piattaforme di distribuzione (105, 106), ed in cui in cui detto apparato di ricezione (103) di contenuti video à ̈ operativamente associabile ad almeno un apparato di riproduzione (102) atto a riprodurre detti contenuti video, detto metodo comprendente i passi di: identificare un contenuto video da riprodurre; identificare almeno una piattaforma attiva tra detta pluralità di piattaforme (105, 106) su cui detto contenuto video da riprodurre à ̈ correntemente trasmesso; selezionare la ricezione di detto contenuto video attraverso detta piattaforma attiva; generare un segnale di uscita comprendente detto contenuto video in forma riproducibile da detto apparato di riproduzione (102).
2. 2. Metodo di elaborazione secondo la rivendicazione 1, in cui detta pluralità di piattaforme (105, 106) comprende almeno una prima piattaforma di tipo broadband (105) ed almeno una seconda piattaforma di tipo broadcast (106), in cui detto metodo comprende ulteriormente il passo di: commutare tra detta prima piattaforma (105) e detta seconda piattaforma (106) o viceversa per selezionare detta piattaforma attiva.
3. 3. Metodo di elaborazione secondo la rivendicazione 2, in cui detta seconda piattaforma di tipo broadcast (106) Ã ̈ una piattaforma di televisione satellitare.
4. 4. Metodo di elaborazione secondo la rivendicazione 2 o 3, in cui il passo di identificare detto contenuto video avviene mediante la lettura di un identificativo associato a detto contenuto video, in cui detto apparato di ricezione video (103) comunica remotamente detto identificativo mediante almeno una di dette piattaforme (105, 106).
5. 5. Metodo di elaborazione secondo la rivendicazione 4, ulteriormente comprendente il passo di: segnalare informazioni relative a detta pluralità di piattaforme (105, 106) da cui detto apparato di ricezione (103) à ̈ atto a ricevere contenuti video.
6. 6. Metodo di elaborazione secondo la rivendicazione 4 o 5, in cui detta trasmissione di detto identificativo o detta segnalazione di informazioni relative a detta pluralità di piattaforme sono trasmesse ad un server remoto (107).
7. 7. Metodo secondo la rivendicazione 4 o 5 o 6, in cui detta commutazione tra detta prima piattaforma (105) e detta seconda piattaforma (106) o viceversa avviene in conseguenza della ricezione da parte di detto apparato di ricezione video (103) di un comando impartito da un server remoto (107), in cui detto comando à ̈ preferibilmente dipendente almeno da detto identificativo o almeno da dette informazioni relative a detta pluralità di piattaforme (105, 106).
8. 8. Apparato di ricezione di contenuti video (103a; 103b) comprendente mezzi di interfaccia (209, 301) con almeno un associabile apparato di riproduzione video (102) e mezzi di elaborazione video atti a: - ricevere contenuti video mediante mezzi di connessione (201a, 203a; 201b, 203b) a una pluralità di piattaforme di distribuzione (105, 106), - identificare un contenuto video da riprodurre; - identificare almeno una piattaforma attiva tra detta pluralità di piattaforme (105, 106) su cui detto contenuto video da riprodurre à ̈ correntemente trasmesso; - selezionare la ricezione di detto contenuto video attraverso detta piattaforma attiva; - generare un segnale video (220; 310) comprendente detto contenuto video in forma riproducibile da un apparato di riproduzione (102) associabile a detto apparato di ricezione (103a; 103b) mediante detti mezzi di interfaccia (209; 301).
9. 9. Apparato di ricezione video (103a; 103b) secondo la rivendicazione 8, in cui detti mezzi di elaborazione video comprendono mezzi di connessione (201a, 203a, 201b, 203b) a detta pluralità di piattaforme (105, 106), in cui almeno una prima connessione (203a; 203b) à ̈ di tipo broadband ed almeno una seconda connessione (201a; 201b) à ̈ di tipo broadcast, ed in cui detto apparato di ricezione video (103) comprende ulteriormente mezzi di commutazione per commutare tra detta prima connessione (203a; 203b) e detta seconda connessione (201a; 201b) o viceversa.
10. 10. Apparato di ricezione video (103a; 103b) secondo la rivendicazione 9, in cui detta seconda connessione (201a, 201b) di tipo broadcast à ̈ atta a connettersi ad una piattaforma di televisione satellitare (106).
11. 11. Apparato di ricezione video (103a; 103b) secondo la rivendicazione 8, in cui il passo di identificare detto contenuto video à ̈ compiuto tramite la lettura di un identificativo associato a detto contenuto video e ricevuto mediante detti mezzi di connessione (201a, 203a; 201b, 203b), in cui detto apparato di ricezione video (103a; 103b) à ̈ atto a comunicare remotamente detto identificativo mediante almeno una connessione (203a; 203b) di detti mezzi di connessione (201a, 203a; 201b, 203b).
12. 12. Apparato di ricezione video (103a; 103b) secondo la rivendicazione 11, ulteriormente comprendente mezzi di segnalazione (203a; 203b) atti a segnalare informazioni relative a detta pluralità di piattaforme.
13. 13. Apparato di ricezione video (103a; 103b) secondo la rivendicazione 11 o 12, in cui detto apparato di ricezione video (103) comprende mezzi per segnalare (203a; 203b) detto identificativo o dette informazioni ad un server remoto (107).
14. 14. Apparato di ricezione video (103a; 103b) secondo la rivendicazione 11 o 12 o 13, comprendente mezzi di elaborazione (202a; 202b) atti a ricevere comandi impartiti da un server remoto (107), in cui detti mezzi di elaborazione (202a; 202b) sono atti ad eseguire operazioni di commutazione tra due connessioni (201a, 203a; 201b, 203b) di detti mezzi di connessione (201a, 203a; 201b, 203b) che dipendono da detti comandi ricevuti dal server remoto (107).
15. 15. Apparato di ricezione video (103a; 103b) secondo la rivendicazione 14, in cui dette operazioni di commutazione dipendono ulteriormente da detto identificativo o da dette informazioni relative a detta pluralità di piattaforme (105, 106).