Brevet FR2928065A1 — publié le 20090828

î 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 5 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 10 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 15 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 20 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 25 é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 2928065 2 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 5 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 10 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. 15 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 20 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é 25 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 2928065 3 ê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. 5 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"). 10 La présente invention vient améliorer la situation. Elle propose à cet effet un procédé de communication de données à un terminal, les données comportant : - des premières données, de contenu, et 15 - des deuxièmes données, de description de contenu, telles que, par exemple, des métadonnées. Avant communication à destination d'au moins un terminal, les premières et deuxièmes données sont présentes dans un flux commun, initial. 20 Au sens de l'invention : - le flux initial est traité, pour extraire, à la volée : 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 25 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, et - l'information de synchronisation précitée est jointe aux premières données 2928065 4 pour former un deuxième flux, adapté pour une communication audit terminal, tandis que les deuxièmes données sont réservées pour une communication séparée au terminal. 5 Ainsi, la présente invention permet notamment de véhiculer des métadonnées en tant que "deuxièmes données précité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 diffusé et reçu directement sur un terminal par exemple de type STB, en étant conforme aux 10 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 15 terminal, notamment les terminaux conformes aux normes MPEG2 TS et DVB. En particulier, il est proposé, dans un mode de réalisation, d'exploiter la technologie des tables EIT, par exemple au sens de la norme DVB, pour transmettre avec le flux multimédia sur un canal principal une information d'événement déclenchant un 20 rafraîchissement des métadonnées disponibles par un autre canal pour le terminal. Ainsi, dans une réalisation, l'information de synchronisation précitée peut être incluse dans une table d'événement générée à chaque extraction d'un nouveau jeu de deuxièmes données du flux initial, et jointe aux premières données pour former 25 le deuxième flux adapté pour le terminal. Les deuxièmes données réservées pour une transmission séparée vers le terminal peuvent être stockées temporairement dans une mémoire distante. On peut prévoir 2928065 5 à cet effet un portail de service auprès duquel le terminal peut télécharger ces données, comme un serveur comportant une telle mémoire distante. En particulier, sur réception du deuxième flux auprès du terminal : - l'information de synchronisation est extraite du deuxième flux, et 5 - à partir de cette information de synchronisation, une requête auprès de la mémoire distante est établie pour récupérer le jeu de deuxièmes données. Ces étapes peuvent être mises en œuvre par le terminal, comme décrit plus loin dans un exemple de réalisation. Ainsi, le terminal peut être apte à recevoir: 10 - le flux adapté par un premier canal, et - les deuxièmes données issues de la mémoire distante par un deuxième canal qui peut être distinct du premier canal. Cette mémoire distante peut être partie intégrante d'un serveur auprès duquel le 15 terminal télécharge les deuxièmes données via le deuxième canal, ce serveur pouvant se présenter alors tel qu'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 20 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. Pour gérer la synchronisation entre les données issues du premier canal et les données issues du deuxième canal, il peut être avantageux de prévoir une 25 estampille temporelle affectée à chaque jeu de deuxièmes données dans le flux initial, cette estampille temporelle étant alors lue suite à l'extraction des deuxièmes données du flux initial pour être recopiée dans la table d'événement précitée en tant qu'information de synchronisation associée à un jeu de deuxièmes données. 2928065 6 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 une architecture générale d'un dispositif additionnel, par 5 exemple intégré à un terminal, pour mener la synchronisation au sens de l'invention de métadonnées sur le terminal, - la figure 2 illustre les étapes de récupération de métadonnées auprès du terminal, dans un exemple de réalisation, - la figure 3 illustre un flux initial comportant des données multimédia et des 10 métadonnées, avec en particulier une estampille temporelle associée aux métadonnées. En référence à la figure 1, un dispositif additionnel 10 pour la mise en œuvre de l'invention est prévu en amont du terminal STB dans le sens du flux multimédia. Le 15 dispositif 10 peut être implanté dans le terminal STB pour la réception du flux Ainsi, à titre d'exemple de réalisation, des métadonnées MET ne sont pas 2928065 7 transportées par des paquets du flux multimédia n (au format MPEG2-TS ou autre) via le canal C1. Elles sont transportées par un autre canal C2, comme par exemple un canal plus lent pour une transmission TCP/IP classique (pour "Transmission Control Protocol/Internet Protocor). 5 En référence à la figure 1, on a représenté en particulier : - le dispositif additionnel 10 au sens de l'invention opérant comme un serveur transcodeur pour le terminal STB, - un répertoire de métadonnées 7 relié à un portail 9, tel qu'un portail de 10 service auquel peut accéder le terminal STB 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 15 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. 20 Sur la figure 1, les entités externes sont : - le réseau étendu RE (par exemple Internet) auquel est relié le dispositif additionnel 10, - le fournisseur de contenus multimédias (non représenté) relié aussi au 25 réseau, et - le terminal STB. Des éléments qui peuvent constituer le dispositif additionnel 10 sont listés ci-après 2928065 8 à titre d'exemple : - un démultiplexeur 1 agencé pour capturer le flux issu du réseau étendu RE et noté ip et pour le démultiplexer pour en extraire les métadonnées, d'une part, et le flux multimédia (audio et/ou vidéo), d'autre part, 5 - un décodeur/encodeur 2 du flux audio/vidéo issu du démultiplexeur 1 pour transformer ce flux en un flux interprétable par le terminal STB, - un générateur de déclencheurs (ou "triggers") 5, recevant du démultiplexeur 1 un signal ES indiquant la présence de jeux de métadonnées à des instants donnés dans le flux ip et capable d'associer à chacun de ces instants une 10 table d'événement EIT, - un module 6 d'injection des tables EIT ainsi formées à la volée par le module 5, sous forme de paquets de données PEIT, dans le module 3 décrit ci-après, - le module 3, multiplexeur des tables EIT et du flux interprétable par le 15 terminal STB, ce module 3 délivrant ainsi un flux N respectant les normes habituelles pour la gestion des tables d'événement EIT dans un flux multimédia, par exemple MPEG2-TS ou autres, et - un module de diffusion 4 du flux normalisé n incluant les paquets de données des tables EIT, à destination du terminal STB. 20 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 25 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 qu'elle est identifiée par un nouveau numéro de version, comme détaillé plus loin. 2928065 9 Le répertoire 7 contenant les métadonnées MET qui sont tirées du flux incident initial ip 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 5 exemple). Il est décrit ci-après comment le terminal STB les récupère du 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 à haut débit C2, 10 - la récupération, auprès du portail de service 9, des métadonnées MET déclarées dans les tables EIT, et - la gestion de l'interface homme/machine précitée pour afficher ou jouer ces métadonnées. 15 Ainsi, parallèlement à la diffusion d'un flux audio/vidéo sur le terminal STB, les étapes suivantes peuvent avantageusement être réalisées : - après la capture du flux ip, démultiplexage et extraction à la volée des métadonnées (module 1 en particulier), - obtention, à partir de l'extraction, des instants de présence des 20 métadonnées dans le flux (module 5 en particulier), - création des tables d'événement EIT, associées à ces instants, et multiplexage de ces tables avec le flux audio/vidéo, conformément aux normes habituelles, et - stockage régulier des métadonnées extraites du flux dans le répertoire 7, 25 pour récupération par ailleurs par le terminal STB via le portail 9. On décrit maintenant comment assurer 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. Le 2928065 10 démultiplexeur 1, une fois qu'elles sont fournies répertoire 7, notifie le générateur de triggers 5. Plus particulièrement, le module 5 génère une nouvelle section de table EIT, selon un terme conforme à la norme MPEG2 TS, référencée SEIT sur la figure 1. 5 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 audio/vidéo ip correspond une nouvelle version de table EIT marquée (ou "taguée"). Ainsi, il est attribué un 10 nouveau numéro de version à chaque nouveau jeu de métadonnées détecté dans le flux. Cette réalisation assure alors que le terminal STB, recevant une table d'événement avec un nouveau numéro de version, déclenche une recherche des métadonnées en interrogeant le portail 9. 15 En effet, le terminal possède un logiciel intermédiaire standard (ou « middleware »), naturellement agencé pour : - identifier chaque nouveau numéro de version de table EIT dans le flux N arrivant du canal à haut débit C1, et - notifier dans un document (par exemple un script java) la présence d'une 20 nouvelle table EIT dont un contenu associé est à aller chercher. Il convient de préciser ici que certains terminaux STB ne sont pas conçus pour notifier les tables EIT. Dans ce cas, des terminaux de ce type effectueront une interrogation régulière ou "polling" pour vérifier si une table EIT a changé ou non. 25 A titre d'exemple de réalisation, le module applicatif 8 peut alors se présenter sous la forme d'une page html contenant un script java à lire et exécuter, le terminal STB comportant classiquement un interpréteur ("browser") de la page html pour 2928065 il analyser son contenu et en particulier requérir auprès du portail 9 des métadonnées déclarées dans des tables EIT identifiées dans le document html. On comprendra ici que le module applicatif 8 peut être un moyen habituel qui ne complique absolument pas nécessairement la structure matérielle ou logicielle 5 standard du terminal STB. Quand le composant applicatif 8 comporte l'identifiant d'une nouvelle version de table EIT (laquelle table est reçue avec le flux audio/vidéo par la flèche 20, puis détectée), il effectue alors une requête (flèche 21) au répertoire 7 stockant les 10 métadonnées pour les récupérer (flèche 22) et les traiter au niveau du terminal STB, en correspondance du flux audio/vidéo reçu. On comprendra qu'il est préférable d'assurer la cohérence entre la table EIT marquée (avec un nouveau numéro de version) et le jeu de métadonnées 15 associées car en effet, au moment où le composant applicatif 8 récupère l'information d'un jeu de métadonnées à récupérer, il n'est pas certain que ce jeu ait déjà été adapté pour être téléchargé du portail 9 et, par conséquent, qu'il soit disponible pour le terminal STB. 20 On prévoit à cet effet : - d'associer déjà, dans le flux destiné au dispositif additionnel 10, une estampille temporelle, quantitative, à chaque jeu de métadonnées, - de lire cette estampille au niveau du démultiplexeur 1 qui capture et extrait les métadonnées, et 25 - de la transmettre au générateur de triggers 5 (sous la forme du signal ES précité), - lequel générateur 5 remplit avec cette estampille temporelle ES la partie adéquate d'une table EIT, par exemple la partie privée « Content Private 2928065 12 Stream » de la section de table EIT. En effet, en référence à la figure 3, le flux initial ip, par exemple un flux audio, est constitué d'une succession de : 5 - 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 10 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 une estampille temporelle 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 telle estampille est lue 15 à l'extraction de chaque jeu de métadonnées du flux initial incident ip, par le module 1 de la figure 1, et qu'un jeu de métadonnées MT#n est stocké en correspondance de cette estampille ES#n, dans le répertoire 7. A titre d'exemple, la "correspondance" précitée entre un jeu de métadonnées et une estampille peut être une date de création d'un fichier incluant les métadonnées et stocké dans le 20 répertoire 7. D'ailleurs, un exemple de réalisation consiste à stocker dans un même fichier un jeu de métadonnées d'un flux multimédia particulier (par exemple un flux audio issu d'une même radio) et à écraser régulièrement ce fichier par une nouvelle version de fichier (donc en le sauvegardant en lui affectant le même nom), cette nouvelle version contenant un nouveau jeu de métadonnées dernièrement 25 récupéré du flux ip. Le répertoire 7 stocke alors une pluralité de fichiers associés chacun à un flux particulier (donc, par exemple, à une radio donnée). A la détection des tables EIT au niveau du terminal STB, au moment de la 2928065 13 récupération des métadonnées du répertoire 7, les trois situations suivantes peuvent advenir : - l'estampille temporelle associée à un jeu de métadonnées peut être égale à l'estampille temporelle transmise par la table d'événement EIT, auquel cas 5 les métadonnées correspondent bien à celles que la table EIT déclare, de sorte que le module applicatif 8 peut récupérer et mettre à jour les métadonnées sans difficulté ; - l'estampille temporelle associée à un jeu de métadonnées peut être strictement supérieure (c'est-à-dire de date postérieure) à celle transmise 10 par la table EIT, ce qui signifie que les métadonnées ont été mises à jour avant que la notification ait été transmise via la table EIT, de sorte que le module applicatif 8 peut, encore ici, récupérer les métadonnées sans difficulté ; - l'estampille temporelle associée à un jeu de métadonnées peut être 15 strictement inférieure (c'est-à-dire de date antérieure) à celle transmise par la table EIT, 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 finies d'être adaptées pour être disponibles auprès du portail 9 pour le terminal STB. Dans ce dernier cas, une routine de temporisation (ou 20 « Timeout ») 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'estampille temporelle des métadonnées reste inférieure à celle de la table EIT et, par exemple, qu'un nombre maximum de répétitions de requêtes 25 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. 2928065 14 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 5 tout type de terminal STB et sans avoir recours à une modification quelconque du logiciel principal du terminal (ou « firmware »). Il convient de noter qu'il peut être introduit un temps de latence dans le troisième cas ci-avant, pour la synchronisation des métadonnées avec le flux, du fait de : 10 - l'adaptation éventuelle à faire des métadonnées au terminal STB, - 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, 15 pour minimiser avantageusement ce temps de latence. Par ailleurs, le terminal STB met en œuvre un logiciel de type "middleware" afin de développer le composant applicatif 8 lié au traitement des tables EIT. Toutefois, un tel middleware existe surtout terminal STB classique, sans nécessité de modifier le 20 terminal ou ses applications logicielles. 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 25 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 2928065 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 5 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 10 à 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 à un logiciel de couche intermédiaire 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 15 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 20 décrit ci-avant par comparaison des valeurs d'estampilles temporelles). Typiquement, tant que l'estampille temporelle 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'estampille temporelle de la table EIT est 25 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 auprès du terminal STB pour un affichage d'image ou autre. 2928065 16 La présente invention vise aussi un dispositif 10 pour la mise en œuvre du procédé selon l'invention et comportant alors au moins, conformément à la figure 1: - des moyens d'extraction 1 des deuxièmes données précitées telles les métadonnées, à la volée, du flux initial ip, 5 - des moyens d'attribution 5 d'une information de synchronisation (telle une table d'événement) aux deuxièmes données extraites du flux initial, - optionnellement, des moyens d'adaptation 2 des premières données au terminal, et - des moyens de multiplexage 3 des premières données adaptées et de 10 l'information de synchronisation dans un même flux N destiné au terminal. Il peut comporter aussi le répertoire 7 et/ou le portail 9, ou optionnellement, simplement des moyens de communication desdites deuxièmes données à destination d'une mémoire distante 7, en tant que répertoire apte à stocker au 15 moins temporairement les deuxièmes données. Le dispositif 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") 20 entre deux réseaux de télécommunication. La présente invention vise aussi un programme d'ordinateur destiné à être stocké en mémoire d'un tel dispositif et comportant des instructions pour la mise en œuvre du procédé selon l'invention, lorsque ce programme est exécuté par un processeur. 25 La présente invention vise aussi un serveur pour la mise en œuvre du procédé et comportant la mémoire distante 7, à la manière du portail de service 9 de la figure 1 relié au répertoire 7. Une telle mémoire stocke alors des fichiers comportant les 2928065 17 métadonnées, avantageusement en correspondance d'une estampille temporelle affectée à chaque jeu de métadonnées. 2928065 18 REVENDICATIONS 1. Procédé de communication de données à un terminal, les données comportant : - des premières données (DAT#n), de contenu, et 5 - des deuxièmes données (MT#n), de description de contenu, dans lequel, avant communication à destination d'au moins un terminal (STB), les premières et deuxièmes données sont présentes dans un flux commun ( ip), initial, caractérisé en ce que : - le flux initial est traité (1 ), pour extraire, à la volée : 10 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, en attribuant au jeu de deuxièmes données une information de synchronisation (SEIT) avec la succession de premières données, et 15 - ladite information de synchronisation est jointe (3) aux premières données pour former un deuxième flux ( 20 2. Procédé selon la revendication 1, caractérisé en ce que les deuxièmes données réservées sont stockées au moins temporairement dans une mémoire distante (7), et en ce que, sur réception dudit deuxième flux par le terminal : - ladite information de synchronisation est extraite du deuxième flux (S21), et - à partir de l'information de synchronisation (S22), une requête auprès de la 25 mémoire distante est établie (S23) pour récupérer les deuxièmes données réservées. 3. Procédé selon la revendication 1, caractérisé en ce que l'information de 2928065 19 synchronisation est incluse dans une table d'événement (SEIT), générée à chaque extraction d'un nouveau jeu de deuxièmes données du flux initial, et jointe aux premières données pour former ledit deuxième flux adapté pour le terminal. 5 4. Procédé selon la revendication 3, caractérisé en ce que, une estampille temporelle étant affectée à un jeu de deuxièmes données dans le flux initial, ladite estampille temporelle (ES#n) est lue suite à l'extraction des deuxièmes données (MT#n) du flux initial ( ip), pour être recopiée dans la table d'événement (SEIT) en tant qu'information de synchronisation associée audit jeu de deuxièmes données. 10 5. Procédé selon la revendication 4, caractérisé en ce que les deuxièmes données réservées sont stockées dans ladite mémoire distante (7), en correspondance de leur estampille temporelle, et en ce que, sur réception d'une table d'événement dans le deuxième flux, une 15 première estampille temporelle lue dans ladite table d'événement reçue dans le deuxième flux est comparée (T24) à une deuxième estampille temporelle d'un jeu de données stockées dans la mémoire distante, et si la première estampille est postérieure à la deuxième estampille, une temporisation (S23) est appliquée pour requérir à nouveau ledit jeu de 20 métadonnées de la mémoire distante. 6. Procédé selon la revendication 2, caractérisé en ce que le terminal reçoit : - ledit flux adapté par un premier canal (C1 ), - lesdites deuxièmes données issues de la mémoire distante par un deuxième 25 canal (C2) distinct du premier canal. 7. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé selon la revendication 1, lorsque ce programme est exécuté par un 2928065 20 processeur. 8. Dispositif pour la mise en œuvre du procédé selon la revendication 1, caractérisé en ce qu'il comporte : 5 - des moyens (1) d'extraction des deuxièmes données, à la volée, du flux initial, - des moyens d'attribution d'une information de synchronisation (5) aux deuxièmes données extraites du flux initial, - des moyens de multiplexage (3) des premières données et de ladite 10 information de synchronisation dans un même flux ( 9. Dispositif selon la revendication 8, caractérisé en ce qu'il comporte des moyens d'adaptation (2) des premières données au terminal. 15 10. Dispositif selon la revendication 8, caractérisé en ce qu'il comporte au moins des moyens de communication desdites deuxièmes données à destination d'une mémoire distante (7) apte à stocker au moins temporairement lesdites deuxièmes données. 20 11. Serveur pour la mise en œuvre du procédé selon la revendication 2, caractérisé en ce qu'il comporte ladite mémoire distante.