WO2009112785A1 - Réception de metadonnees sur un terminal - Google Patents

Réception de metadonnees sur un terminal Download PDF

Info

Publication number
WO2009112785A1
WO2009112785A1 PCT/FR2009/050328 FR2009050328W WO2009112785A1 WO 2009112785 A1 WO2009112785 A1 WO 2009112785A1 FR 2009050328 W FR2009050328 W FR 2009050328W WO 2009112785 A1 WO2009112785 A1 WO 2009112785A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
stream
synchronization information
metadata
phi
Prior art date
Application number
PCT/FR2009/050328
Other languages
English (en)
Inventor
Roberto Agro
Halim Bendiabdallah
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR0851264 priority Critical
Priority to FR0851264A priority patent/FR2928065A1/fr
Application filed by France Telecom filed Critical France Telecom
Publication of WO2009112785A1 publication Critical patent/WO2009112785A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network, synchronizing decoder's clock; Client middleware
    • H04N21/435Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network, synchronizing decoder's clock; Client middleware
    • H04N21/4302Content synchronization processes, e.g. decoder synchronization
    • H04N21/4307Synchronizing display of multiple content streams, e.g. synchronisation of audio and video output or enabling or disabling interactive icons for a given period of time
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network, synchronizing decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network, synchronizing decoder's clock; Client middleware
    • H04N21/434Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348Demultiplexing of additional data and video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/472End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4722End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting additional data associated with the content
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/8126Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/8133Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts specifically related to the content, e.g. biography of the actors in a movie, detailed information about an article seen in a video program
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84Generation or processing of descriptive data, e.g. content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/16Analogue secrecy systems; Analogue subscription systems
    • H04N7/173Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309Transmission or handling of upstream communications
    • H04N7/17318Direct or substantially direct transmission and handling of requests

Abstract

La présente invention concerne une communication de données, notamment multimédias, à un terminal, les données comportant des premières données, de contenu, et des deuxièmes données, typiquement des métadonnées associées aux données de contenu. Au sens de l'invention, les données sont traitées pour séparer : d'une part, une succession de premières données et, d'autre part, au moins un jeu de deuxièmes données, associé à cette succession de premières données, en attribuant au jeu de deuxièmes données une information de synchronisation avec la succession de premières données. Cette information de synchronisation est jointe (3) aux premières données pour former un flux (ΦN) adapté pour une communication au terminal, tandis que les deuxièmes données (MET) sont réservées pour une communication séparée (C2) au terminal. L'information de synchronisation est alors utilisée, sur réception du flux adapté par le terminal, pour formuler une requête en vue d'obtenir le jeu de deuxièmes données.

Description

Réception de métadonnées sur un terminal

La présente invention concerne le domaine de la réception de données de contenu multimédia, notamment de télévision numérique, via un réseau étendu par exemple au protocole IP (pour « Internet Protocol »).

En particulier pour la transmission de métadonnées dans un flux numérique vers un terminal, par exemple un terminal STB pour « Set-Top Box », on connaît des systèmes notamment conformes à la norme MPEG2 TS ("TS" pour "transport stream").

On entend par "métadonnées" (ou "metadata" en anglais) des données numériques sur, par exemple, le titre d'une œuvre, le nom d'un artiste ou autres (donc des données textuelles), ainsi que des données sur la pochette d'un disque ou l'affiche d'un film (donc des données d'image), ou encore d'autres types de données sur le contenu multimédia (des liens url vers des sites Internet, ou tout autre type de données).

La structure d'un flux MPEG2 TS est simple et générique. Elle se compose à la fois de flux audio/vidéo et de données. Le flux comporte aussi des tables de signalisation prescrites par les normes MPEG2 et DVB (pour « Digital Video Broadcast »). Parmi ces tables de signalisation, une table permet de véhiculer des données de texte : la table dite « EIT » (pour « Event Information Table »). Cette table EIT est utilisée pour transmettre des informations sur l'émission en cours et éventuellement une émission à venir (durée, titre de l'émission ou autres), mais elle peut être utilisée à d'autres fins, comme par exemple l'affichage d'un bandeau publicitaire. La table EIT est parfaitement synchronisée avec le flux global diffusé et reçu sur un terminal STB, lequel identifie facilement et sans délai notable la table EIT et la traite dès réception.

On connaît aussi des systèmes de transmission des métadonnées dans un flux diffusé sur un réseau étendu tel que l'Internet, selon le protocole IP. A titre d'exemple, le flux audio issu d'un site WEB de radiodiffusion (ou « Web Radio ») gérée par un fournisseur de contenus peut être diffusé selon différents protocoles (par exemple « Shoutcast », « Microsoft Media Server », ou « RealAudio »). Le flux diffusé embarque plus précisément, à la fois, une piste audio et des métadonnées (titre de l'émission en cours, genre musical de la piste en cours de diffusion, image de la pochette de l'album de musique, ou autres). Le flux est capturé par des programmes lecteurs ou « players » (tels que Windows Media Player, Winamp, ou autres) qui sont capables de traiter à la volée, comme un terminal STB du type précité, les données de la piste audio et les métadonnées, sans toutefois respecter les normes MPEG2 et DVB.

On comprendra alors qu'il existe actuellement deux moyens pour transmettre les métadonnées provenant d'un flux Internet :

- une insertion des métadonnées dans des tables de type EIT,

- ou une insertion des métadonnées dans des tables privées (leur gestion n'étant pas normalisée et étant assurée par des règles "propriétaires").

Or, la table EIT, selon les spécifications de la norme DVB, n'est pas particulièrement adaptée, a priori, à recevoir et/ou diffuser tous types d'informations. En effet, son contenu a une longueur maximale et il est interprété comme étant un ensemble de données textuelles par un terminal STB. Ainsi, il n'est pas prévu de véhiculer dans une table EIT des données binaires telles que des métadonnées et notamment des données d'images. Par ailleurs, les tables privées, par définition, ont un format propriétaire qui peut être conçu pour une transmission de données binaires par un diffuseur donné. Il en résulte que le traitement de ces tables privées implique une modification du logiciel principal installé en mémoire du terminal STB, du fait de l'utilisation de formats propriétaires non spécifiés par les normes.

Ainsi, les techniques existantes ne permettent pas de diffuser tout type de métadonnées dans un flux multimédia, à destination de tout terminal (et en particulier d'un terminal "non propriétaire").

La présente invention vient améliorer la situation.

Elle propose à cet effet un procédé de codage de données destinées à être transmises à un dispositif de décodage, les données comportant :

- des premières données, de contenu, et

- des deuxièmes données, de description de contenu. Le procédé comporte une étape dans laquelle on obtient: o d'une part, une succession de premières données et, o d'autre part, au moins un jeu de deuxièmes données, associé à la succession de premières données, une information de synchronisation avec la succession de premières données étant attribuée au jeu de deuxièmes données.

Cette information de synchronisation est alors jointe aux premières données pour former un flux qui est adapté pour une communication au dispositif de décodage, tandis que les deuxièmes données sont réservées pour être communiquées au dispositif de décodage séparément du flux adapté. L'information de synchronisation est alors destinée à être utilisée par le dispositif de décodage, lors du décodage du flux adapté précité, pour formuler une requête en vue d'obtenir le jeu de deuxièmes données.

Le dispositif de décodage peut être par exemple un terminal STB, ou tout autre terminal pouvant recevoir des données multimédias. Le codage peut, quant à lui, être réalisé dans une plate-forme de transcodage ou directement en aval d'un serveur de diffusion de contenu.

Les deuxièmes données, de description de contenu, peuvent inclure typiquement des métadonnées associées au contenu. On entend par « associées au contenu » le fait que de telles métadonnées sont en relation avec le contenu en cours de diffusion et sont donc associées temporellement aux données de contenu. Il peut s'agir par exemple de données de texte (titre d'un film, résumé, etc.) accompagnant les données de contenu (données vidéo par exemple). Il peut s'agir de données « plus riches » telles que des images (affiche du film par exemple) ou du son, ou autre.

L'information de synchronisation précitée, incorporée dans le flux destiné au terminal, permet à ce dernier d'accéder à des métadonnées qui ne sont pas présente dans ce flux mais qui sont bien associées temporellement au contenu en cours de diffusion. L'accès aux métadonnées par le terminal peut s'effectuer par exemple par téléchargement auprès d'un portail de service, ou par tout autre moyen de communication. En termes plus génériques, dans une réalisation, les deuxièmes données précitées peuvent être stockées au moins temporairement dans une mémoire, distante du dispositif de décodage mais accessible par ce dernier pour récupérer les deuxièmes données.

Cette mémoire distante peut être partie intégrante d'un serveur auprès duquel le terminal télécharge par exemple les deuxièmes données via un deuxième canal distinct du premier canal par lequel le terminal reçoit le flux comportant les données de contenu. Ce serveur peut se présenter comme un portail de service auquel peuvent accéder une multiplicité de terminaux. La mémoire distante peut stocker alors au moins un répertoire de fichiers de jeux de deuxièmes données. Par exemple, cette mémoire distante peut stocker une arborescence complexe de répertoires comportant des fichiers de métadonnées et correspondant à une multiplicité de flux multimédias (de télévision ou de radio ou autre) que peut recevoir un terminal.

Dans une réalisation avantageuse, un changement, par le dispositif de codage, de l'information de synchronisation jointe aux premières données provoque une émission d'une nouvelle requête par le dispositif de décodage, par exemple auprès de cette mémoire distante. L'information de synchronisation sert donc de signal de déclenchement (ou "trigger" selon la terminologie anglo-saxonne) pour déclencher une procédure d'obtention d'un jeu de deuxième données.

Ainsi, la présente invention permet notamment de véhiculer des métadonnées, qu'elles soient textuelles et/ou binaires (d'image, de son, ou autre), provenant d'un flux dans un réseau étendu tel que l'Internet et de synchroniser ces métadonnées avec le flux de contenu diffusé et reçu directement sur un terminal STB, en étant conforme aux normes actuelles, telles que MPEG2 TS et DVB. Ainsi, on entend ci-avant par "flux adapté au terminal" notamment le fait que le flux que reçoit le terminal puisse être conforme à l'une de ces normes. On évite ainsi toute modification du logiciel principal du terminal STB. Le respect des normes dans la mise en œuvre de l'invention rend son application très générale et compatible avec tout type de terminal, notamment les terminaux simplement conformes aux normes MPEG2 TS et DVB. En particulier, il est proposé, dans un mode de réalisation, d'exploiter la technologie des tables d'événement (EIT), par exemple au sens de la norme DVB, pour y enregistrer l'information de synchronisation et transmettre ces tables EIT dans le flux comportant les données de contenu, via un premier canal, dit canal principal. En termes plus génériques, le flux adapté au terminal comporte des données de tables d'événement associées aux premières données et, en particulier, l'information de synchronisation précitée est avantageusement incluse dans un champ de donnée prédéfini d'une table d'événement. Ainsi, à chaque obtention d'un nouveau jeu de deuxièmes données, l'information de synchronisation peut être insérée parmi les données des tables d'événement pour être jointe aux premières données et former le flux précité, adapté au traitement par le dispositif de décodage.

Dans une réalisation avantageuse, une mise à jour, par le dispositif de codage, de l'information de synchronisation est accompagnée d'une mise à jour d'un numéro de version de section de la table d'événement destinée à véhiculer l'information de synchronisation mise à jour.

La réception d'une table d'événement comportant un nouveau numéro de version de section de table d'événement provoque la mémorisation et le traitement par le dispositif de décodage d'une nouvelle information de synchronisation contenue dans cette table d'événement, ce qui, comme indiqué plus haut, permet de déclencher un rafraîchissement par le dispositif de décodage des métadonnées associées au flux en cours de décodage.

Etant donné que la norme DVB stipule que les tables d'événement doivent être lues et traitées au fur et à mesure qu'un flux DVB est décodé, tout dispositif de décodage conforme à cette norme est conçu pour traiter les informations présentes dans ces tables. Il suffit donc de prévoir, dans un tel dispositif, une fonction adaptée au traitement des informations de synchronisation. Il n'est pas nécessaire de modifier les fonctions connues, normalisées, qui sont mises en œuvre dans un tel dispositif de décodage.

Dans un premier mode de réalisation, les premières et deuxièmes données sont présentes dans un flux initial commun. Le flux initial est alors traité pour extraire : o d'une part, la succession de premières données et, o d'autre part, le jeu de deuxièmes données, associé à la succession de premières données.

L'information de synchronisation est fonction d'un instant d'extraction des deuxièmes données du flux commun. Dans cette réalisation, le signal de déclenchement précité peut être délivré par un module en charge de l'extraction du jeu de deuxièmes données, comme on le verra plus loin en référence à la figure 1.

Dans un deuxième mode de réalisation où, par exemple, les premières données et les deuxièmes données peuvent être issues de deux flux initiaux distincts, l'information de synchronisation jointe aux premières données est mise à jour lorsque qu'un nouveau jeu de deuxièmes données est disponible pour une communication au dispositif de décodage. Dans cette réalisation, le signal de déclenchement précité peut encore être délivré par un module en charge de l'extraction du jeu de deuxièmes données, mais la mise à jour effective de l'information de synchronisation que comportent les tables EIT est conditionnée par la réception et le stockage effectifs des deuxièmes données dans la mémoire distante précitée, comme on le verra plus loin en référence à la figure 4.

Dans un troisième mode de réalisation où les premières données et les deuxièmes données peuvent encore être issues de deux flux initiaux distincts, on peut prévoir que le jeu de deuxièmes données soit reçu maintenant par le dispositif de codage avec une donnée d'association temporelle aux premières données. L'information de synchronisation est alors définie par cette donnée d'association temporelle. Ce mode de réalisation sera décrit en détails plus loin en référence à la figure 6.

La présente invention vise aussi un procédé de décodage de données reçues dans un flux comportant au moins des premières données, de contenu. En particulier, une information, incluse dans le flux, de synchronisation d'un jeu de deuxièmes données, de description de contenu, associées aux première données, est extraite de ce flux et interprétée. Au sens de l'invention, en fonction de l'interprétation de cette information de synchronisation, une requête d'obtention du jeu de deuxièmes données est formulée, ce jeu de deuxièmes données étant obtenues séparément du flux comportant les premières données.

Dans une réalisation, au décodage :

- on compare une deuxième information de synchronisation extraite du flux à une première information de synchronisation reçue antérieurement, et

- en cas d'évolution de l'information de synchronisation, on formule une requête pour obtenir un nouveau jeu de deuxièmes données.

Avantageusement, l'information de synchronisation comporte une indication de date de traitement du jeu de deuxièmes données par le dispositif de codage.

On entend ici par les termes génériques « date de traitement des deuxièmes données » :

- l'instant d'extraction de ces deuxièmes données, au codage, du flux initial comportant aussi les données de contenu, comme dans le premier mode de réalisation, ou - l'instant de stockage des deuxièmes données dans la mémoire distante et de leur mise à disposition pour le terminal, comme dans le deuxième mode de réalisation, ou

- la date issue de la lecture de la donnée d'association temporelle des deuxièmes données aux premières données, lorsqu'elles sont obtenues par deux flux distincts au codage, comme dans le troisième mode de réalisation.

Préférentiellement, au décodage, une vérification est menée pour s'assurer que les deuxièmes données reçues de la mémoire distante sont bien à jour. Cette vérification est avantageusement mise en œuvre auprès du dispositif de décodage (pour ne pas surcharger un dispositif de codage susceptible de délivrer des flux à une pluralité de terminaux). Ainsi, comme les deuxièmes données sont stockées au moins temporairement dans la mémoire distante et qu'un instant de sauvegarde est déterminé pour le stockage du jeu de deuxièmes données dans cette mémoire distante, sur réception du flux de données, au décodage:

- l'information de synchronisation extraite du flux est comparée à l'instant de sauvegarde des deuxièmes données, et

- au moins si l'information de synchronisation extraite du flux indique une date antérieure ou égale à l'instant de sauvegarde des deuxièmes données, les deuxièmes données obtenues sont utilisées en tant que données de description de contenu associées aux données de contenu reçues dans le flux.

Le procédé de décodage peut alors être mis en œuvre par tout dispositif de décodage du type précité (terminal STB ou autres lecteurs multimédias). Un tel dispositif de décodage est simplement équipé d'un module comportant au moins :

- des moyens pour interpréter une information de synchronisation des deuxièmes données, cette information de synchronisation étant reçue dans le flux comportant les premières données, et

- des moyens pour décider, en fonction de l'information de synchronisation, de formuler une requête d'obtention des deuxièmes données.

Le procédé de codage, quant à lui, peut être mise en œuvre par un dispositif de codage de données destinées à être transmises à un dispositif de décodage, les données comportant :

- des premières données, de contenu, et

- des deuxièmes données, de description de contenu. Le dispositif de codage comporte :

- des moyens d'obtention : o d'une part, d'une succession de premières données et, o d'autre part, au moins un jeu de deuxièmes données, associé à ladite succession de premières données,

- des moyens d'attribution au jeu de deuxièmes données d'une information de synchronisation avec la succession de premières données,

- des moyens pour joindre ladite information de synchronisation aux premières données pour former un flux adapté pour une communication audit dispositif de décodage, et

- des moyens pour communiquer ledit jeu de deuxièmes données au dispositif de décodage, séparément dudit flux adapté.

La présente invention vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé de codage exposé ci-avant, lorsque ce programme est exécuté par un processeur.

Elle vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé de décodage exposé ci-avant, lorsque ce programme est exécuté par un processeur.

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés sur lesquels :

- la figure 1 illustre un premier mode de réalisation d'un dispositif de codage 10, dans lequel les informations de synchronisation que comportent les tables d'événement sont définies par un instant de traitement d'un flux initial comportant des données de contenu et des métadonnées associées à ces donnes de contenu,

- la figure 2 illustre les étapes pour récupérer ces métadonnées, mises en œuvre par un dispositif décodeur (terminal STB dans l'exemple représenté), dans ce premier mode de réalisation,

- la figure 3 illustre le flux initial comportant les données de contenu (multimédia par exemple) et les métadonnées associées, la position des métadonnées dans le flux définissant, dans le premier mode de réalisation, un horodatage pour estampiller temporellement les métadonnées,

- la figure 4 illustre un deuxième mode de réalisation du dispositif de codage, dans lequel l'injection des tables d'événement dans le flux destiné au dispositif de décodage est conditionnée par la mise à disposition des métadonnées pour un téléchargement à partir de la mémoire distante précitée (dans l'exemple représenté un répertoire (ou « repository ») 7, accessible via un portail de téléchargement 9),

- la figure 5 illustre les étapes de récupération de métadonnées mises en œuvre par le dispositif décodeur, dans le deuxième mode de réalisation, et

- la figure 6 illustre un troisième mode de réalisation du dispositif de codage, dans lequel une partie au moins des métadonnées est transmise au dispositif de codage séparément du flux initial de données de contenu et les tables d'événement comportent une information temporelle sur l'instant de réception de ces métadonnées auprès du dispositif de codage.

La figure 1 représente un dispositif de codage 10 (ou de façon équivalente, de transcodage) qui peut être intégré à un serveur de diffusion de contenu ou qui peut être réalisé sous la forme d'une plate-forme de transcodage. Ce dispositif 10 réalise en particulier les opérations de traitement et d'encodage des flux et des données destinés à être transmis au terminal STB. Dans cette optique, le dispositif 10 sera également nommé par la suite "dispositif de transcodage" et le terminal STB "dispositif de décodage".

Le dispositif de transcodage 10 peut être placé par exemple immédiatement en aval d'une tête de réseau de diffusion (non représentée) et implanté à celle-ci, ou encore implanté dans une passerelle entre un réseau étendu (type Internet) et un réseau IP (pour « Internet Protocol ») à spécificités dédiées pour l'application visée. La figure 1 représente alors le cas où le dispositif de transcodage est implanté dans une passerelle entre le réseau étendu RE et un réseau IP, la référence C1 désignant un canal du réseau IP utilisé pour la transmission des flux de données notamment de contenu (audio et/ou vidéo) du dispositif de transcodage 10 au dispositif de décodage STB. Ces données de contenu, appelées « premières données » précédemment, sont transportées par paquets du flux multimédia ΦN (au format MPEG2-TS ou autre) via le canal C1. Un fournisseur de contenus multimédias (non représenté sur la figure 1 ) est relié aussi au réseau étendu RE pour envoyer via ce réseau RE les données de contenu au moins.

Une partie au moins des métadonnées MET associées à ces données de contenu (appelées « deuxièmes données » précédemment) ne sont pas transportées via le canal C1. Elles sont transportées par un autre canal C2, établi entre le dispositif de transcodage 10 et le dispositif STB, par exemple un canal à bande passante plus réduite que le canal C1 , par exemple dans le cadre d'une transmission TCP/IP classique (pour "Transmission Control Protocol/Internet Protocof). Les canaux C2 et C1 sont établis indépendamment l'un de l'autre, notamment sans lien de synchronisation entre eux, l'invention visant à établir à la réception un lien de synchronisation entre des données transmises respectivement via ces deux canaux, à partir d'informations de synchronisation insérées dans le flux multimédia ΦN transmis via le premier canal.

Une telle information de synchronisation sert de signal de déclenchement (appelé "trigger" dans la terminologie anglo-saxonne) en ce que, en cas de changement de valeur de cette information de synchronisation, le dispositif de décodage est conçu pour déclencher une procédure d'obtention d'un nouveau jeu de métadonnées, associées au flux multimédia ΦN en cours de décodage et disponibles via le canal C2.

En référence à la figure 1 , correspondant au premier mode de réalisation, on a représenté en particulier :

- le dispositif de transcodage 10 au sens de l'invention opérant comme un serveur transcodeur pour le terminal STB,

- le dispositif de décodage représenté tel le terminal STB lui-même,

- un répertoire de métadonnées 7 relié à un portail 9, tel qu'un portail de service auquel peut accéder le terminal STB via le canal C2 pour récupérer des métadonnées MET du répertoire 7, et

- un module applicatif 8 gérant notamment les communications avec le portail 9 et pouvant être en charge, par exemple, de l'affichage d'un ou plusieurs éléments définis par les métadonnées (titre d'une chanson ou d'un film, nom du ou des artiste(s), affiche du film ou pochette du disque, instant de lecture, etc.) sur une interface homme/machine telle qu'un écran relié au terminal STB. En variante, les données de titres, artistes, ou autres peuvent être lues par une interface homme/machine telle qu'un dispositif de restitution sonore.

Dans le premier mode de réalisation, le dispositif de transcodage 10 peut comporter des éléments parmi lesquels :

- un démultiplexeur 1 capture le flux Φ|P issu du réseau étendu RE et dissocie ce flux Φ|P pour en extraire les métadonnées MET, d'une part, et le flux Φ de données de contenu (audio et/ou vidéo), d'autre part ;

- un décodeur/encodeur 2 du flux audio/vidéo Φ issu du démultiplexeur 1 transforme ce flux Φ en un flux Φ' interprétable par le terminal STB ;

- en outre, le démultiplexeur 1 , en détectant la présence d'un jeu de métadonnées à un instant donné dans le flux Φ|P, transmet un signal d'horodatage ES de cet instant donné à un générateur 5 de table d'événement ;

- ce générateur 5 de table d'événement EIT (ou "EIT trigger"), sur réception du signal d'horodatage ES, génère une table d'événement incluant, en tant que signal de déclenchement, l'horodate que comporte le signal d'horodatage ES.

En pratique, il peut être prévu d'insérer cette donnée dans un champ prédéfini, de type "date" d'une table d'événement EIT (pour « Event Information Table »). Ainsi, les tables d'événement générées dans le premier mode de réalisation comportent, par exemple dans un champ de date, une horodate, constituant une estampille temporelle (ou « Time Stamp »), correspondant à l'instant de réception des métadonnées par le dispositif de transcodage 10, ou, plus précisément, à l'instant de traitement des métadonnées pour les extraire du flux initial). Bien entendu, cette horodate peut être stockée dans un autre champ de la table d'événement. On rappelle en effet qu'une table d'événement comporte plusieurs champs, tels que le champ indiquant le contenu en cours de diffusion ou le champ indiquant le prochain contenu à diffuser, ou encore les champs respectifs indiquant les instants de diffusion de ces contenus.

En principe, le module applicatif 8 du terminal doit interroger régulièrement le contenu d'une mémoire cache du terminal STB stockant la dernière table EIT reçue pour lire l'horodate indiquée et détecter alors une éventuelle évolution d'horodate, ce qui signifie qu'un nouveau jeu de métadonnées peut être récupéré du répertoire 7. Pour éviter ces interrogations répétées, une réalisation avantageuse consiste à utiliser un autre champ de la table d'événement EIT servant à insérer un numéro de version de tables EIT (un identifiant de version nommé habituellement « version ID »), lors de la génération des tables par le module 5. Cette mise en œuvre permet, dans certains terminaux au moins, de notifier au module applicatif 8, via un logiciel médiateur du terminal (ou « middleware »), un changement de numéro de version de table, de sorte que le middleware, détectant un tel changement, lit et stocke le contenu de la table EIT reçue dans une zone mémoire, à partir de laquelle le module applicatif 8 pourra lire le champ de date prédéfini des tables EIT et détecter une éventuelle évolution de l'horodate. Cette mise en œuvre sera détaillée plus loin.

A chaque présence d'un nouveau jeu de métadonnées dans le flux initial Φ|P, le générateur 5 crée une table d'événement SEIT avec un nouveau numéro de version et dont le champ date comporte une horodate correspondant à ce nouveau jeu de métadonnées. Le module 6 d'injection procède ensuite à l'injection des tables EIT ainsi formées à la volée par le module 5, et fournit ces tables sous forme de paquets de données PEIT au module multiplexeur 3. On distingue :

- la « section de table » SEIT comprenant des données définissant la structure de la table complète (succession de bits) et donnant des informations sur cette table,

- des « paquets de données » PEIT dont la concaténation représente la table complète au format MPEG2-TS (la succession complète).

A réception d'un signal d'horodatage ES comprenant une horodate différente de celle incluse dans le signal d'horodatage reçu précédemment, le module 5 génère une nouvelle section de table EIT (le terme « section » étant conforme à la norme MPEG2 TS). En particulier, le générateur 5 remplit avec l'horodate du signal d'horodatage ES la partie adéquate (en pratique le champ de type « date ») de la section de table SEIT, par exemple dans la partie privée « Content Private Stream » de cette section de table.

Chaque section de table SEIT est mise en forme par le module 6 pour être injectée sous forme de paquet PEIT dans le flux encodé audio/vidéo ΦN. En particulier, à chaque nouveau jeu de métadonnées (extraites du flux incident Φ|P dans le premier mode de réalisation) correspond à la fois une nouvelle version de table EIT marquée (ou "taguée") et une nouvelle horodate.

Le module 3 associe, dans un même flux ΦN, les paquets de tables PEIT et le flux Φ' interprétable par le terminal STB. Ce module 3 délivre alors un flux ΦN qui respecte les normes habituelles pour la gestion des tables d'événement EIT dans un flux multimédia, par exemple MPEG2-TS ou autres. Le module de diffusion 4 met en forme le flux normalisé ΦN incluant les paquets de données des tables EIT afin que ce flux ΦN soit apte à être communiqué au terminal STB (flèche 20 de la figure 1 ) et interprété par celui-ci.

On rappelle que les tables d'événement EIT (pour « Event Information Table ») sont couramment utilisées (notamment selon les normes classiques telles que MPEG2 TS ou DVB, ou autres) pour transmettre des informations sur un flux multimédia en cours de réception (durée, titre de l'émission ou autres). En particulier, un avantage de la table EIT est qu'elle est parfaitement synchronisée avec le flux reçu sur le terminal STB, lequel identifie facilement et sans délai notable la table EIT et la traite dès réception, dès lors que la table courante est identifiée par un numéro de version différent du numéro de version de la table traitée précédemment.

Ainsi, parallèlement à la diffusion d'un flux audio/vidéo sur le terminal STB, les étapes suivantes peuvent avantageusement être mises en œuvre par le dispositif de transcodage 10 :

- après la capture du flux Φ|P, démultiplexage et extraction à la volée des métadonnées (module 1 en particulier),

- obtention, à partir du flux Φ|P, des horodates, extraites des signaux d'horodatage ES, associées aux métadonnées extraites (module 5 en particulier),

- création des tables d'événement EIT, contenant ces horodates, et multiplexage de ces tables avec le flux audio/vidéo, conformément aux normes habituelles,

- parallèlement, stockage régulier des métadonnées extraites du flux dans le répertoire 7, pour récupération par ailleurs par le terminal STB via le portail 9.

En particulier, le module applicatif 8, auprès du terminal STB, assure :

- le traitement des tables EIT présentes dans le flux ΦN reçu via le canal à relativement haut débit C1 (par rapport au canal C2),

- la récupération, auprès du portail de service 9, de nouvelles métadonnées MET indiquées par une nouvelle horodate dans les tables EIT reçues dans le flux ΦN, et

- la gestion de l'interface homme/machine précitée pour afficher ou jouer ces métadonnées.

Le répertoire 7 contenant les métadonnées MET qui sont tirées du flux initial Φ|P fournit en particulier les métadonnées dans un format approprié au terminal STB, via le portail de service 9 et le canal C2 (liaison de type TCP/IP par exemple). Il est décrit ci-après comment le terminal STB les récupère du portail 9.

Le module applicatif 8, qui intervient pour l'interprétation des tables de données reçues et pour la récupération des métadonnées auprès du portail 9, se présente sous la forme d'un programme informatique comportant des instructions pour mettre en œuvre les étapes suivantes.

Chaque horodate courante, transmise via l'une au moins des dernières tables EIT reçues, est stockée en mémoire du terminal STB par le module applicatif. Le module applicatif 8 (qui se peut se présenter sous la forme d'une brique logicielle coopérant avec un logiciel médiateur ou « middleware » du terminal STB) est notifié par des couches logicielles plus basses du terminal STB d'un changement de numéro de version (« version ID ») de table EIT. En cas de changement de numéro de version, le middleware lit et stocke le contenu de la table EIT reçue dans une zone mémoire réservée à cet effet et accessible par le module applicatif 8. Le module applicatif 8 compare alors l'horodate indiquée dans le champ date de la table nouvellement mémorisée dans cette zone mémoire, avec l'horodate courante stockée en mémoire du terminal STB par le module applicatif et, en cas d'évolution de cette horodate (horodate des dernières tables reçues postérieure à l'horodate stockée), détermine que de nouvelles métadonnées doivent être récupérées du répertoire 7 et formule une requête d'obtention des métadonnées du répertoire 7, via le portail 9 (flèche 21 de la figure 1 ). Cette étape sera décrite en détail plus loin, en référence à la figure 2.

Ainsi, le fait d'attribuer un nouveau numéro de version à chaque table EIT associée à un nouveau jeu de métadonnées permet de forcer la mise à jour des métadonnées par le dispositif de décodage (terminal STB) auquel est destiné le flux audio/vidéo ΦN contenant cette table. Cette mise en œuvre assure que le terminal STB, recevant une table d'événement avec un nouveau numéro de version, traite la table en question et, en particulier, que le module applicatif 8 y lise l'horodate ES pour déclencher éventuellement une recherche des métadonnées en interrogeant le portail 9.

Toutefois, les couches logicielles basses de certains terminaux peuvent ne pas être conçues pour notifier les nouveaux numéros de version de tables EIT. Dans ce cas, le module applicatif 8 de ces terminaux effectue une simple interrogation régulière (ou "polling") pour vérifier si une horodate a changé dans les tables EIT reçues.

Les métadonnées sont préférentiellement stockées sous la forme d'une page html auprès du répertoire 7 (par exemple un fichier html nommé « index.html »). Il est choisi, dans un exemple de réalisation, de conserver un même nom de fichier html et d'écraser la version précédente de ce fichier à chaque mise à jour (à chaque réception de nouvelles métadonnées). L'avantage d'une telle réalisation (stocker un seul fichier de même nom mais susceptible de mises à jour) est qu'un terminal qui n'a pas d'information sur un fichier courant de métadonnées à récupérer (par exemple dans le cas d'une première mise en service ou de mise sous tension du terminal) interroge le portail 9 en requérant toujours le même nom de fichier, un fichier étant toujours disponible pour un téléchargement, sous le même nom, sur le portail 9. Cette mise en œuvre permet alors d'offrir toujours une adresse de chargement de métadonnées au terminal sans risque de générer un message d'erreur auprès du terminal.

En outre, on stocke dans le fichier html du répertoire 7 l'horodate ES-html des métadonnées dernièrement mises à jour. Ainsi, lorsque le terminal STB récupère le fichier html comportant les métadonnées du répertoire 7 (flèche 22 de la figure 1 ), le module applicatif 8 compare l'horodate ES-html indiquée dans ce fichier html à l'horodate ES-EIT indiquée dans les tables EIT dernièrement reçues. De manière générale, le terminal STB comporte classiquement un interpréteur html ("browser") permettant d'analyser le contenu de la page html issue du portail 9.

Plus particulièrement, dans un exemple de réalisation, l'horodate ES-html du fichier html peut simplement correspondre à la date de dernière mise à jour du fichier html (donc la date d'écrasement du fichier précédent et de création du nouveau fichier html).

En outre, on peut prévoir une pluralité de fichiers html stockés dans le répertoire 7 et que chaque fichier soit propre à un fournisseur de contenu (par exemple propre à un flux audio issu d'une même radio). Le répertoire 7 stocke alors une pluralité de fichiers associés chacun à un flux particulier (donc, par exemple, à une radio donnée). On peut classer aussi les fichiers html selon une arborescence de répertoires dans le cas où, parmi plusieurs fournisseurs de contenu, au moins un même fournisseur de contenu diffuse plusieurs flux multimédias distincts.

En fonction de la comparaison des horodates ES-html et ES-EIT, contenues dans une table d'événement, d'une part, et dans un fichier html, d'autre part, menée par le module applicatif 8, trois cas peuvent se présenter : - si les horodates correspondent entre elles, les métadonnées sont valables et peuvent être associées au contenu en cours de diffusion,

- si l'horodate ES-html du fichier html indique une date postérieure à celle qu'indique l'horodate ES-EIT de la table EIT, ce qui signifie que les métadonnées correspondant à l'horodate ES-EIT ont été mises à jour avant que la notification ait été transmise via la table EIT (et donc que la version des métadonnées disponibles couramment sur le portail est issue d'une mise à jour plus récente que ce qu'indique la table EIT), le module applicatif 8 peut, encore ici, récupérer les métadonnées sans difficulté ;

- si l'horodate ES-EIT de la table EIT indique une date postérieure à celle qu'indique l'horodate ES-html du fichier html, ce qui signifie que la notification au moyen de la table EIT est arrivée au terminal STB avant même que les métadonnées associées ne soient mises à jour auprès du portail 9, une routine de temporisation peut être déclenchée au niveau du module applicatif 8 afin de relancer une requête de récupération de métadonnées périodiquement jusqu'à leur obtention. En effet, cette routine peut être active tant que l'horodate des métadonnées disponibles dans le répertoire 7 reste inférieure à celle de la table EIT et, par exemple, qu'un nombre maximum de répétitions de requêtes n'est pas atteint. Si ce nombre est atteint, il peut être décidé que les métadonnées sont perdues ou erronées et qu'elles ne seront plus attendues (décision dite de « Timeout »).

Cette méthode de comparaison suppose que les horodates ES-EIT et ES-html utilisées soient croissantes en fonction du temps. Toute autre grandeur croissante en fonction du temps est donc utilisable en lieu et place d'une horodate, par exemple un simple compteur incrémenté à chaque nouveau jeu de métadonnées.

Il convient de noter qu'il peut être introduit un temps de latence dans le traitement des données, pour la synchronisation des métadonnées avec le flux, du fait :

- de l'adaptation au terminal STB à faire éventuellement sur les métadonnées,

- du stockage des métadonnées dans le répertoire 7, et

- du téléchargement des métadonnées par le composant applicatif 8.

On optimisera l'architecture du système au sens de l'invention ou la qualité des liaisons entre, par exemple, le répertoire 7, le portail 9 et le module application 8, pour minimiser avantageusement ce temps de latence.

Le module applicatif 8 peut être un programme informatique écrit par exemple en langage javascript. On comprendra que le module applicatif 8 peut être un moyen s'intégrant simplement dans la structure matérielle ou logicielle standard (dans le sens « normalisée ») d'un terminal STB classique.

Ainsi, la présente invention permet de transmettre tout type de métadonnées, textuelles ou non, à un terminal STB quelconque, qu'il soit compatible ou non avec une norme telle que MPEG2-TS ou DVB, ou autres. La synchronisation du flux et des métadonnées est garantie tout en respectant les normes usuelles, et ce sur tout type de terminal STB et sans avoir recours à une modification quelconque du hardware ou du logiciel embarqué du terminal (ou « firmware »).

Par ailleurs, le terminal STB met en œuvre un logiciel médiateur ou "middleware", formant une couche applicative servant d'intermédiaire de communication entre différents composants logiciels et/ou processus mis en œuvre dans le terminal STB. Un tel middleware existe sur tout terminal STB classique décodant des flux DVB ou MPEG2-TS. Ce "middleware" présente une structure permettant un interfaçage avec le composant applicatif 8 lié au traitement des tables EIT et des informations de synchronisation qui, selon l'invention, sont transmises via ces tables. . Une application possible de l'invention peut se situer dans le cadre d'un service de diffusion de radio sur réseau Internet (service "WebRadio"), notamment pour un diffuseur de contenu tel que "OrangeTV". Etant donné que le parc des terminaux STB est conforme à la norme MPEG2 DVB, la diffusion des flux peut être au format MPEG1 Layer 2. Par conséquent, le flux original (qui peut être au format Shoutcast MP3, MMS WMA, ou autre) ne peut pas être diffusé directement sur un terminal STB et nécessite une adaptation pour être adressé au parc des terminaux STB pour ce service. Cette adaptation, en particulier la synchronisation des métadonnées sur le terminal STB avec le flux reçu, est réalisée par la mise en œuvre de l'invention, laquelle permet une synchronisation générique de métadonnées, textuelles ou non, s'appliquant à l'architecture de diffusion du service OrangeTV.

Le traitement des tables EIT, auprès du terminal STB, dans le cadre de ce service comme au sens général d'une mise en œuvre de l'invention, peut être réalisé ainsi qu'illustré à titre d'exemple sur la figure 2. Sur réception du flux multimédia ΦN reçu à haut débit (étape S20), un démultiplexeur du logiciel de base du terminal STB (ou "firmware") traite ce flux à l'étape S21 pour y capturer à l'étape S22 une table d'événement EIT. La table EIT est notifiée au logiciel médiateur du terminal STB (ou "middleware"), lequel transmet l'information d'événement associée à la table EIT à une couche logicielle supérieure, applicative, telle que le module applicatif 8 de la figure 1. En particulier, ce dernier forme une requête http (étape S23), sur la base du contenu de la table EIT pour que les métadonnées associées à cette table soient communiquées au terminal. Le terminal transmet alors cette requête REQ au portail 9 de la figure 1. Au test T24, le module applicatif 8 effectue la vérification de cohérence (en particulier le test de synchronisation décrit ci-avant par comparaison des valeurs d'horodates). Typiquement, tant que l'horodate de la table EIT est strictement supérieure à celle des métadonnées du répertoire 7 (flèche N en sortie de test), une routine de temporisation et de reformulation de requête réitère l'étape S23 un nombre choisi de fois. Si, en revanche, l'horodate de la table EIT est inférieure ou égale à celle des métadonnées du répertoire 7 (flèche O en sortie de test), alors les métadonnées MET peuvent être récupérées du répertoire 7 pour être traitées (étape S25) auprès du terminal STB pour un affichage d'image ou autre.

On décrit maintenant comment est assurée la synchronisation entre la récupération des métadonnées et la réception du flux audio/vidéo auprès du terminal STB, dans différents modes de réalisation.

Dans le premier mode de réalisation de la figure 1 , la position des métadonnées dans le flux initial Φ|P, relativement aux données de contenu, définit l'association temporelle à considérer entre un jeu de métadonnées et une partie du flux de données de contenu. En effet, en référence à la figure 3, le flux initial Φ|P, par exemple un flux audio, est constitué, dans le premier mode de réalisation, d'une succession de :

- données de contenu DAT#1 , DAT#2, ... , DAT#n-1 , DAT#n,

- et de données descriptives de ce contenu, telles des métadonnées MT#1 , MT#2, MT#3, ... , MT#n.

Les métadonnées précèdent, dans l'exemple représenté, les données de contenu, de sorte que, sur réception d'un jeu de métadonnées MT#n, il est possible d'afficher les données textuelles (titre d'une chanson, artiste interprète et/ou compositeur) et d'image (affiche du disque), pendant la lecture des données de contenu DAT#n. On relèvera alors qu'il est possible d'associer dans le flux initial incident Φ|P un signal d'horodatage ES#1 , ES#2, ES#3, ... , ES#n à chaque jeu de métadonnées MT#1 , MT#2, MT#3, ... , MT#n, suivant leur ordre d'apparition dans le flux. C'est ainsi qu'une horodate est obtenue à partir d'un signal d'horodatage à l'extraction de chaque jeu de métadonnées du flux initial incident Φ|P, par le module 1 de la figure 1 , et qu'un jeu de métadonnées MT#n est stocké en correspondance de cette horodate ES#n, dans le répertoire 7.

On se réfère maintenant à la figure 4 pour décrire un deuxième mode de réalisation.

Pour s'affranchir avantageusement de la routine de temporisation déclenchée par le module applicatif 8 et éviter ainsi de relancer une requête de récupération périodique des métadonnées jusqu'à leur obtention (comme décrit ci-avant en référence à la figure 2), il est proposé, dans un deuxième mode de réalisation, d'inclure un module de synchronisation 11 (figure 4) au dispositif de transcodage 10 de l'invention. Dans ce deuxième mode de réalisation, le flux initial ΦIP comporte toujours, à la fois, des données de contenu et des métadonnées associées (comme représenté sur la figure 3) que le terminal STB cherche à récupérer ultérieurement sur le portail 9. Toutefois, les tables d'événement générées comportent, en tant qu'information de synchronisation pour le déclenchement du processus de mise à jour des métadonnées, non pas une horodate comme c'est le cas dans le premier mode de réalisation, mais une simple valeur numérique ou compteur, par exemple une valeur numérique binaire, insérée dans un des champs de type "date" de la table. En effet, dans ce deuxième mode de réalisation, l'information de synchronisation n'est pas immédiatement injectée par le module 6 dans le flux à diffuser : l'injection des tables EIT portant une nouvelle valeur d'information de synchronisation est conditionnée par la mise à disposition des métadonnées correspondantes sur le répertoire 7. Dans ce deuxième mode de réalisation, la valeur numérique utilisée comme information de synchronisation change à chaque fois qu'un nouveau jeu de métadonnées est disponible auprès du portail 7. En cas d'utilisation d'une valeur numérique binaire comme information de synchronisation, celle-ci peut prendre successivement, par exemple, les valeurs "0" puis "1", à nouveau "0" puis "1 ", etc., chacune de ces deux valeurs étant interprétable - conformément au système de codage de date utilisé pour le champ date - comme une représentation d'une date particulière.

En pratique, lors de la réception de nouvelles métadonnées par le répertoire 7, une nouvelle version de fichier html est créée et l'information de création de nouvelle version est envoyée au module de synchronisation 11 , lequel autorise alors l'injection des tables EIT portant la nouvelle valeur d'information de synchronisation, dans le flux à diffuser. On rappelle que la génération et la diffusion des tables d'événement sont régulières (cycliques). Ici, tant que le module d'injection 6 n'a pas reçu du module de synchronisation 11 l'autorisation d'injecter des tables avec une nouvelle valeur d'information de synchronisation, le module 6 fournit au multiplexeur 3 les mêmes tables avec une ancienne valeur d'information de synchronisation.

Les autres modules de la figure 4 portant les mêmes références que ceux de la figure 1 ont sensiblement les mêmes fonctions dans le dispositif.

Il s'en suit, en référence maintenant à la figure 5, que, dans ce deuxième mode de réalisation, le test répété T24 de la figure 2 peut avantageusement être supprimé. La requête de l'étape S23 n'est formulée qu'une fois par le terminal STB de la figure 4 et fait simplement suite à la réception de tables EIT avec une nouvelle valeur d'information de synchronisation dans le champ date prédéfini. On est assuré ici que la version disponible des métadonnées sur le répertoire 7 est bien celle à récupérer et non pas une version antérieure.

On relèvera ainsi que le module applicatif 8 comporte a minima : - des moyens mettant en œuvre l'étape S22 (de la figure 2 ou de la figure 5) pour interpréter l'information de synchronisation des métadonnées ES que portent les tables d'événement, et

- des moyens mettant en œuvre l'étape S23 pour décider, en fonction de cette information de synchronisation, de formuler ou non une requête REQ d'obtention des métadonnées auprès du répertoire 7.

Comme le test T24 de la figure 2 n'est plus nécessaire, des moyens pour mettre en œuvre ce test ne sont pas nécessaires au module applicatif 8 au moins dans ce deuxième mode de réalisation.

On indique qu'une autre variante possible du deuxième mode de réalisation consiste à prendre, comme information de synchronisation pour les tables EIT, l'horodate correspondant à l'instant de mise à jour des métadonnées auprès du répertoire 7. En effet, une telle horodate change à chaque fois qu'un nouveau jeu de métadonnées est disponible auprès du portail 7 et est ainsi apte à déclencher l'exécution, par le dispositif de décodage, d'un processus de mise à jour des métadonnées courantes. Ainsi, dans cette variante, les signaux d'horodatage ES proviennent du répertoire 7 et non pas du démultiplexeur 1.

On comprendra alors que le traitement du flux commun initial des figures 1 et 4 et l'extraction à la volée des métadonnées pour remplir les tables EIT en fonction de l'instant de cette extraction n'est pas une réalisation nécessaire pour la mise en œuvre de l'invention.

Ainsi, dans un troisième mode de réalisation, en référence maintenant à la figure 6, les métadonnées (ou au moins certaines métadonnées enrichies par rapport à du texte, comme notamment des images, du son ou autres) et les données de contenu sont véhiculées par deux flux distincts (référencés respectivement ΦMET et Φ|P et issus par exemple de serveurs distincts SERM et SERC). En particulier, on prévoit un module 12 qui interroge régulièrement (par « polling ») le serveur de métadonnées SERM pour récupérer d'éventuelles nouvelles métadonnées MET (telles que des métadonnées enrichies) et les stocker sur le répertoire 7. Ainsi, en cas de réception de nouvelles métadonnées, le module 12 :

- transmet ces nouvelles métadonnées au répertoire 7 pour leur mise à disposition via le portail 9 et une mise à jour du fichier html correspondant, et

- fournit au générateur 5 un signal d'horodatage correspondant à l'instant de réception des nouvelles métadonnées afin que le générateur 5 crée une table d'événement comportant cette horodate.

Toutefois, dans ce troisième mode de réalisation comme dans le deuxième mode de réalisation, il est possible d'utiliser comme information de synchronisation non pas une horodate, mais une simple valeur numérique, par exemple une valeur numérique binaire, insérée dans l'un champ date prédéfini de la table, du moment que cette valeur numérique change à chaque fois qu'un nouveau jeu de métadonnées est disponible auprès du portail 7.

Il reste toutefois à s'assurer d'une correspondance temporelle effective entre un jeu de métadonnées et un contenu associé à diffuser. Cette correspondance était assurée, dans les premier et deuxième modes de réalisation ci-avant, par la position des métadonnées dans le flux initial (comme décrit ci-avant en référence à la figure 3). Dans le troisième mode de réalisation, plusieurs mises en œuvre sont possibles pour assurer cette correspondance temporelle.

Une première mise en œuvre consiste à faire en sorte que les serveurs de métadonnées SERM et de contenu SERC soient synchronisés entre eux. A cet effet, ces deux serveurs peuvent par exemple consulter un même serveur de date SNTP (pour « Simple Network Time Protocol »). Ainsi, les métadonnées sont mises à disposition par le serveur SERM et pour le module 12 à l'heure exacte de diffusion prévue des données de contenu associées. Dès réception, ce module 12 délivre au module 5 l'information de l'instant de réception des métadonnées pour former l'horodate des tables EIT, et met à jour les métadonnées du répertoire 7, sans délai.

Certes, de légers décalages temporels liés à des voies différentes de traitement peuvent intervenir entre les données de contenu et les métadonnées. Toutefois, les métadonnées et les données de contenu peuvent être reçues par le terminal avec un décalage jusqu'à quelques dizaines de secondes au plus. Dans ce troisième mode de réalisation, il peut être advenir en particulier que les métadonnées soient disponibles pour le terminal STB avant les données de contenu. Un tel décalage n'est pas réellement pénalisant néanmoins, notamment par exemple pour un morceau musical qui doit durer quelques minutes : l'utilisateur du terminal pourra avoir les données de description de contenu quelques secondes à peine (voire moins, en pratique) après le début du morceau.

Une variante de cette mise en œuvre consiste à lire, dans le module 12, une date de diffusion prévue, du contenu associé aux métadonnées, cette date de diffusion pouvant être une donnée accompagnant les métadonnées reçues par le module 12 et lue par ce module 12 pour délivrer l'horodate pour l'estampille temporelle des tables EIT. Dans une telle mise en œuvre, le module 12 peut recevoir tout un ensemble de métadonnées prévues pour plusieurs heures de diffusion dans la journée (voire pour toute une journée), avec des instants de diffusion dans la journée des contenus associés à ces métadonnées. Dans ce cas, le module 12 consulte régulièrement un serveur de date SNTP pour :

- tenir à jour une horloge,

- se référer à cette horloge pour surveiller les instants de diffusion indiqués, et - au moment de chaque instant de diffusion indiqué, délivrer un signal d'horodatage au module 5 pour l'estampille temporelle des tables EIT. Par ailleurs, le serveur SERM doit fournir à temps les métadonnées par rapport aux instants de diffusion et il est préférable que le serveur SERM se synchronise aussi sur le même serveur de date SNTP que celui que consulte le module 12. En revanche, dans une telle mise en œuvre, il n'est pas nécessaire que le serveur de contenu SERC consulte le serveur de date SNTP.

Le module de synchronisation 11 reçoit du répertoire 7 l'information de mise à jour des métadonnées et pilote, comme dans le deuxième mode de réalisation, le module d'injection 6 pour l'injection des tables EIT avec une nouvelle horodate dans le flux destiné à la diffusion. Toutefois, cette mise en œuvre est optionnelle ici et le module de synchronisation 11 n'est pas nécessaire car le module 12 communique sans délai les métadonnées pour leur mise à jour auprès du répertoire 7. Ainsi, le terminal STB ne peut être informé d'une mise à jour des métadonnées (par les tables EIT) qu'après leur mise à jour effective sur le répertoire 7.

Hormis le module de démultiplexage 1 qui ne délivre maintenant que les données de contenu et éventuellement des métadonnées simples (par exemple du texte), les autres modules de la figure 6 sont conformes à ceux de la figure 4.

On précise ci-après dans quel contexte il peut être avantageux de prévoir, comme indiqué précédemment, le transport de métadonnées « enrichies » dans un flux ΦMET séparé du flux Φ|P véhiculant les autres métadonnées et les données de contenu. Cette situation se présente lorsqu'un fournisseur de contenu communique à partir du serveur SERC des métadonnées simples, accompagnant les données de contenu, et ces métadonnées simples indiquent que des métadonnées enrichies (mais qui sont associées aux mêmes données de contenu) peuvent être récupérées en outre d'un autre serveur SERM. Dans une telle réalisation, le démultiplexeur 1 , après extraction des métadonnées simples, détermine, en coopération avec un lecteur de ces métadonnées simples, que des métadonnées enrichies peuvent être obtenues en association des données de contenu reçues auprès du serveur SERM. Le multiplexeur 1 transmet cette information au module 12 (flèche en traits pointillés de la figure 6) pour interroger le serveur SERM sans délai (c'est-à-dire en dehors de sa routine de polling régulier).

Bien entendu, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemples ; elle s'étend à d'autres variantes. Par exemple, le dispositif de codage au sens de l'invention peut se situer immédiatement en aval d'une tête de réseau de diffusion, ou immédiatement en amont d'un terminal (module de réception intermédiaire), ou encore en cascade avec une passerelle (ou "gateway") entre deux réseaux de télécommunication.

Le dispositif peut intégrer le répertoire 7 et/ou le portail 9, ou optionnellement, simplement des moyens de communication des métadonnées à destination d'une mémoire distante 7, via un canal approprié.

La présente invention peut viser aussi un serveur comportant cette mémoire distante 7, à la manière du portail de service 9 relié au répertoire 7.

Claims

REVENDICATIONS
1. Procédé de codage de données destinées à être transmises à un dispositif de décodage, les données comportant :
- des premières données (DAT#n), de contenu, et
- des deuxièmes données (MT#n, MET), de description de contenu, caractérisé en ce qu'il comporte une étape dans laquelle on obtient : o d'une part, une succession de premières données et, o d'autre part, au moins un jeu de deuxièmes données, associé à ladite succession de premières données, une information de synchronisation avec la succession de premières données étant attribuée au jeu de deuxièmes données, et en ce que ladite information de synchronisation est jointe (3) aux premières données pour former un flux (ΦN) adapté pour une communication audit dispositif de décodage, tandis que les deuxièmes données (MET) sont réservées pour être communiquées au dispositif de décodage séparément dudit flux adapté (ΦN), ladite information de synchronisation étant destinée à être utilisée par ledit dispositif de décodage, lors du décodage dudit flux adapté, pour formuler une requête pour obtenir ledit jeu de deuxièmes données.
2. Procédé de codage selon la revendication 1 , caractérisé en ce qu'un changement par le dispositif de codage de l'information de synchronisation jointe aux premières données provoque une émission d'une nouvelle requête par le dispositif de décodage.
3. Procédé de codage selon l'une des revendications 1 et 2, dans lequel les premières et deuxièmes données sont présentes dans un flux initial commun (Φip), caractérisé en ce que le flux initial est traité (1 ), pour extraire : o d'une part, la succession de premières données et, o d'autre part, le jeu de deuxièmes données, associé à ladite succession de premières données, et en ce que l'information de synchronisation est fonction d'un instant d'extraction des deuxièmes données du flux commun.
4. Procédé de codage selon l'une des revendications 1 et 2, caractérisé en ce que l'information de synchronisation jointe aux premières données est mise à jour lorsque qu'un nouveau jeu de deuxièmes données (MET) est disponible pour une communication au dispositif de décodage.
5. Procédé de codage selon l'une des revendications précédentes, dans lequel le flux adapté au terminal comporte des données de table d'événement (PEIT) associées aux premières données, caractérisé en ce que l'information de synchronisation est incluse (5) dans un champ de donnée prédéfini d'une dite table d'événement.
6. Procédé de codage selon la revendication 5, caractérisé en ce qu'une mise à jour, par le dispositif de codage, de l'information de synchronisation est accompagnée d'une mise à jour d'un numéro de version de section de la table d'événement destinée à véhiculer ladite information de synchronisation.
7. Procédé de codage selon l'une des revendications précédentes, caractérisé en ce que les deuxièmes données réservées sont stockées au moins temporairement dans une mémoire (7) distante du dispositif de décodage et accessible par ledit dispositif de décodage pour obtenir le jeu de deuxièmes données.
8. Procédé de décodage de données reçues dans un flux (ΦN) comportant au moins des premières données (DAT#n), de contenu, caractérisé en ce qu'une information, incluse dans le flux (ΦN), de synchronisation d'un jeu de deuxièmes données (MT#n), de description de contenu, associées aux première données, est extraite dudit flux (ΦN) et interprétée, et en ce que, en fonction de l'interprétation de ladite information de synchronisation, une requête d'obtention dudit jeu de deuxièmes données (MET) est formulée, lesdites deuxièmes données étant obtenues séparément du flux (ΦN) comportant les premières données.
9. Procédé de décodage selon la revendication 8, caractérisé en ce que :
- on compare (S22) une deuxième information de synchronisation extraite du flux (S21 ) à une première information de synchronisation reçue antérieurement, et
- en cas d'évolution de l'information de synchronisation, on formule (S23) une requête pour obtenir un nouveau jeu de deuxièmes données.
10. Procédé de décodage selon la revendication 9, dans lequel l'information de synchronisation comporte une indication de date de traitement des deuxièmes données par le dispositif de codage.
11. Procédé de décodage selon la revendication 10, caractérisé en ce que, les deuxièmes données étant stockées au moins temporairement dans une mémoire distante (7) et un instant de sauvegarde étant déterminé pour le stockage des deuxièmes données, sur réception du flux de données :
- l'information de synchronisation extraite du flux est comparée à l'instant de sauvegarde des deuxièmes données, et
- au moins si (T24) l'information de synchronisation extraite du flux indique une date antérieure ou égale à l'instant de sauvegarde des deuxièmes données, les deuxièmes données obtenues sont utilisées en tant que données de description de contenu associées aux données de contenu reçues dans le flux.
12. Procédé de décodage selon la revendication 11 , caractérisé en ce que si (T24) l'information de synchronisation extraite du flux indique une date postérieure à l'instant de sauvegarde des deuxièmes données, une temporisation (S23) est appliquée pour requérir un nombre de fois choisi des deuxièmes données auprès de la mémoire distante, jusqu'à obtenir des deuxièmes données dont l'instant de sauvegarde est antérieur ou égal à la date qu'indique l'information de synchronisation extraite du flux.
13. Dispositif de codage de données destinées à être transmises à un dispositif de décodage, les données comportant :
- des premières données (DAT#n), de contenu, et
- des deuxièmes données (MT#n, MET), de description de contenu, caractérisé en ce qu'il comporte :
- des moyens (1 ) d'obtention : o d'une part, d'une succession de premières données et, o d'autre part, au moins un jeu de deuxièmes données, associé à ladite succession de premières données,
- des moyens (1 ; 12) d'attribution au jeu de deuxièmes données d'une information de synchronisation avec la succession de premières données,
- des moyens (5, 6, 3) pour joindre ladite information de synchronisation aux premières données pour former un flux (ΦN) adapté pour une communication audit dispositif de décodage,
- des moyens (9, 7) pour communiquer ledit jeu de deuxièmes données (MET) au dispositif de décodage, séparément dudit flux adapté (ΦN), ladite information de synchronisation étant destinée à être utilisée par ledit dispositif de décodage, lors du décodage dudit flux adapté, pour formuler une requête pour obtenir ledit jeu de deuxièmes données.
14. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de codage selon l'une des revendications 1 à 8, lorsque ce programme est exécuté par un processeur.
15. Programme d'ordinateur (8) comportant des instructions pour la mise en œuvre du procédé de décodage selon l'une des revendications 9 à 12, lorsque ce programme est exécuté par un processeur.
16. Module (8) d'un dispositif de décodage de données reçues dans un flux (ΦN) comportant au moins des premières données (DAT#n), de contenu, caractérisé en ce qu'il comporte au moins :
- des moyens pour interpréter une information de synchronisation de deuxièmes données (MT#n), de description de contenu, associées aux première données, ladite information de synchronisation étant reçue dans ledit flux (ΦN) comportant les premières données, et
- des moyens pour décider, en fonction de ladite information de synchronisation, de formuler une requête d'obtention desdites deuxièmes données (MET), lesdites deuxièmes données étant obtenues séparément du flux (ΦN).
PCT/FR2009/050328 2008-02-27 2009-02-27 Réception de metadonnees sur un terminal WO2009112785A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0851264 2008-02-27
FR0851264A FR2928065A1 (fr) 2008-02-27 2008-02-27 Reception de metadonnees sur un terminal.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP09719421A EP2253144A1 (fr) 2008-02-27 2009-02-27 Réception de metadonnees sur un terminal

Publications (1)

Publication Number Publication Date
WO2009112785A1 true WO2009112785A1 (fr) 2009-09-17

Family

ID=39743723

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/050328 WO2009112785A1 (fr) 2008-02-27 2009-02-27 Réception de metadonnees sur un terminal

Country Status (3)

Country Link
EP (1) EP2253144A1 (fr)
FR (1) FR2928065A1 (fr)
WO (1) WO2009112785A1 (fr)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999020049A1 (fr) * 1997-10-14 1999-04-22 Thomson Licensing S.A. Systeme permettant de formater et de traiter des donnees de programme multimedia et des informations de programme
EP1003304A1 (fr) * 1998-05-13 2000-05-24 Sony Corporation Systeme con u pour produire le contenu
JP2000197018A (ja) * 1998-12-25 2000-07-14 Toshiba Corp デジタル映像コンテンツにおける番組関連情報のmpegトランスポ―トストリ―ムへの挿入方法、番組関連情報に対応するアプリケ―ションソフトウェアの起動方法及びデジタル映像コンテンツ送受信システム
US20020035726A1 (en) * 2000-04-17 2002-03-21 Corl Mark T. Information descriptor and extended information descriptor data structures for digital television signals
US20020188959A1 (en) * 2001-06-12 2002-12-12 Koninklijke Philips Electronics N.V. Parallel and synchronized display of augmented multimedia information
WO2003056828A1 (fr) * 2001-12-28 2003-07-10 Koninklijke Philips Electronics N.V. Acces transparent d'un intergiciel de television numerique de plate-forme locale multimedia de decodeur a un contenu video ip
WO2003092274A1 (fr) * 2002-04-24 2003-11-06 Thomson Licensing S.A. Synchronisation de signal auxiliaire pour l'insertion de sous-titrages codes
EP1443773A1 (fr) * 2003-01-31 2004-08-04 Thomson Licensing S.A. Dispositif et méthode de synchronisation en lecture de données vidéo et de données annexes
DE102006026316A1 (de) * 2006-06-02 2007-12-06 Deutsche Thomson Ohg Verfahren zur Vervollständigung einer elektronischen Programmzeitschrift

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999020049A1 (fr) * 1997-10-14 1999-04-22 Thomson Licensing S.A. Systeme permettant de formater et de traiter des donnees de programme multimedia et des informations de programme
EP1003304A1 (fr) * 1998-05-13 2000-05-24 Sony Corporation Systeme con u pour produire le contenu
JP2000197018A (ja) * 1998-12-25 2000-07-14 Toshiba Corp デジタル映像コンテンツにおける番組関連情報のmpegトランスポ―トストリ―ムへの挿入方法、番組関連情報に対応するアプリケ―ションソフトウェアの起動方法及びデジタル映像コンテンツ送受信システム
US20020035726A1 (en) * 2000-04-17 2002-03-21 Corl Mark T. Information descriptor and extended information descriptor data structures for digital television signals
US20020188959A1 (en) * 2001-06-12 2002-12-12 Koninklijke Philips Electronics N.V. Parallel and synchronized display of augmented multimedia information
WO2003056828A1 (fr) * 2001-12-28 2003-07-10 Koninklijke Philips Electronics N.V. Acces transparent d'un intergiciel de television numerique de plate-forme locale multimedia de decodeur a un contenu video ip
WO2003092274A1 (fr) * 2002-04-24 2003-11-06 Thomson Licensing S.A. Synchronisation de signal auxiliaire pour l'insertion de sous-titrages codes
EP1443773A1 (fr) * 2003-01-31 2004-08-04 Thomson Licensing S.A. Dispositif et méthode de synchronisation en lecture de données vidéo et de données annexes
DE102006026316A1 (de) * 2006-06-02 2007-12-06 Deutsche Thomson Ohg Verfahren zur Vervollständigung einer elektronischen Programmzeitschrift

Also Published As

Publication number Publication date
FR2928065A1 (fr) 2009-08-28
EP2253144A1 (fr) 2010-11-24

Similar Documents

Publication Publication Date Title
JP6254208B2 (ja) シグナリング又はブロック生成を用いた拡張ブロック−要求ストリーミングシステム
US10362130B2 (en) Apparatus and method for providing streaming contents
US10257587B2 (en) Integrating continuous and sparse streaming data
US10516913B2 (en) Receiving device and method, transmitting device and method, and program
US9871844B2 (en) Method and apparatus for transmitting and receiving adaptive streaming mechanism-based content
US20190230313A1 (en) System and method for modifying media streams using metadata
US10341715B2 (en) Extensions to trigger parameters table for interactive television
JP2018170791A (ja) コンテンツの送受信方法及び装置
KR102057107B1 (ko) 수신 장치, 수신 방법, 프로그램 및 정보 처리 시스템
JP6034458B2 (ja) スケーラブルビデオコーディングを利用したリニアなデジタルtv番組の伝送方法
US9426196B2 (en) Live timing for dynamic adaptive streaming over HTTP (DASH)
JP6122523B2 (ja) マルチメディアサービス送受信方法及び装置
US20150281781A1 (en) Reception apparatus, reception method, and program
US9602891B2 (en) Service signaling recovery for multimedia content using embedded watermarks
US9749667B2 (en) Method for receiving broadcast service and reception device thereof
US8453177B2 (en) Non-real time services
KR101741484B1 (ko) 저-레이턴시 스트림을 처리하기 위한 개선된 블록-요청 스트리밍 시스템
US10257553B2 (en) Contents reception device and method, contents transmission device and method, program, and recording medium
KR101709030B1 (ko) 코딩된 비디오 데이터의 네트워크 스트리밍을 위한 트릭 모드들
KR101946861B1 (ko) 멀티미디어 방송 서비스의 미디어 데이터 동기화 방법 및 장치
KR101479890B1 (ko) 미디어 콘텐트 송수신 방법 및 그를 이용한 송수신 장치
KR101206698B1 (ko) 스트리밍 콘텐츠 제공 장치 및 방법
US10129609B2 (en) Method for transceiving media files and device for transmitting/receiving using same
US20180124465A1 (en) Reception apparatus, reception method, transmission apparatus, and transmission method
CA2875467C (fr) Appareil et procede de traitement d'un service interactif

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09719421

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE

REEP

Ref document number: 2009719421

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2009719421

Country of ref document: EP