Brevet FR2752350A1 — publié le 19980213

Procédé d'extraction de données dans un système de transmission cyclique et dispositif de mise en oeuvre L'invention concerne un procédé d'extraction de données dans un système de transmission cyclique et un dispositif de mise en oeuvre de ce procédé. L'invention s'applique notamment dans le domaine de la transmission de télévision numérique et d'informations de service liées. Dans le cadre de la transmission de télévision digitale, par exemple selon la norme DVB (Digital Video Broadcast en anglais), il est prévu de transmettre un certain nombre de données destinées notamment à informer l'utilisateur sur les programmes transmis ou à i15 permettre une certaine interactivité. Le flux de données multiplexé forme ainsi une base de données constamment mise à jour et retransmise cycliquement, selon la bande passante allouée. Il devient nécessaire de développer des outils pour exploiter de façon efficace cette base de données, tout en prenant en compte les possibilités et limitations des récepteurs. D'un côté, les récepteurs sont limités en mémoire par rapport à la masse de données disponibles, ce qui impose un souci constant d'optimisation de l'utilisation de cette mémoire. D'un autre côté, les caractéristiques de transmission des données peuvent varier de façon importante temporellement, ce qui peut causer des délais d'attente importants avant qu'une donnée recherchée ne soit disponible. L'invention a pour objet un procédé d'extraction de données d'un flux de données dans un système de transmission cyclique de données par paquets comportant au moins un récepteur caractérisé en ce qu'il comporte, au niveau du récepteur, les étapes: - de détermination de requêtes d'extraction relatives aux données à extraire, - de détermination d'un niveau de priorité de chaque requête, - de programmation de filtres de paquets de données dans l'ordre de priorité desdites requêtes, 2 2752350 - d'extraction desdites données à partir des paquets filtrés. Le fait de donner priorité à certaines requêtes vis-à-vis d'autres requêtes du point de vue du traitement interne permet de hiérarchiser les données requises selon leur importance, notamment en fonction du moment auquel ces données seront nécessaires. Des données dont le besoin est immédiat, ou proche dans le temps, auront une priorité plus grande que des données dont le besoin est plus lointain, ou, selon les variantes de réalisation ci-dessous, moins probable. Les ressources du système seront allouées selon ces priorités et il deviendra possible de les libérer plus rapidement si nécessaire. Selon une variante de réalisation, l'étape de détermination d'un niveau de priorité comprend la détermination d'un niveau de i 5 priorité anticipé et d'un niveau de priorité non-anticipé, le niveau de priorité non-anticipé ayant une priorité plus haute que le niveau de priorité anticipé. Selon une variante de réalisation, le niveau de priorité non- anticipé est attribué à des requêtes relatives à des données dont le traitement par une application est certain. Selon une variante de réalisation, le niveau de priorité non- anticipé est attribué à des requêtes relatives à des données destinées à être affichées le plus rapidement possible. Selon une variante de réalisation, le niveau de priorité anticipé est attribué à des requêtes relatives à des données dont le traitement par une application n'est pas certain. Selon les ressources disponibles, des données dont l'application pourrait avoir besoin sont préchargées. Ceci réduit le temps d'attente nécessaire pour pouvoir transférer ces données à Il'application. Selon une variante de réalisation, ledit récepteur comportant d'une part au moins une application comprenant des moyens pour 3 2752350 déterminer lesdites requêtes et traiter les données extraites et d'autre part des moyens de gestion desdites requêtes et de programmation desdits filtres, ledit procédé comporte en outre les étapes: - de mémorisation des données relatives à une requête déterminée par ladite application suite à leur extraction, - de notification d'une application par lesdits moyens de gestion et de programmation de la disponibilité desdites données. Selon une variante de réalisation, une requête est de type permanent, lesdits moyens de gestion et de programmation maintenant ladite requête jusqu'à avis contraire de l'application dont cette requête est originaire. Selon une variante de réalisation, lesdits moyens de gestion et de programmation maintiennent une base de données comportant les données relatives à des requêtes permanentes. Selon une variante de réalisation, une application ayant formulé une requête permanente n'est notifiée d'une mise à jour des données relatives à cette requête que si le numéro de version de la structure de données du flux de données correspondant à ces données change et qu'en même temps il existe une différence entre au moins une valeur d'une donnée stockée dans la base de données et la valeur de cette donnée extraite du flux de données. Selon une variante de réalisation, une requête est de type unique, ladite requête de type unique étant effacée après notification des données relatives à cette requête par lesdits moyens de gestion et de programmation. L'invention a aussi pour objet un dispositif d'extraction de données d'un flux de données dans un système de transmission cyclique de données par paquets comportant au moins un récepteur caractérisé en ce qu'il comporte: - des moyens de démultiplexage et de filtrage desdits paquets, 4 2752350 - des moyens de détermination de requêtes d'extraction relatives aux données à extraire et de détermination d'un niveau de priorité de chaque requête, - des moyens de programmation desdits moyens de démultiplexage et de filtrage dans l'ordre de priorité desdites requêtes, - des moyens d'extraction desdites données à partir des paquets filtrés. Selon un mode de réalisation particulier, les moyens de détermination de requêtes relatives aux données à extraire et de détermination d'un niveau de priorité de chaque requête comprennent une application de type guide électronique de programmes. D'autres caractéristiques et avantages de l'invention i15 apparaîtront à travers la description d'un exemple de réalisation particulier non limitatif, illustré par les figures jointes faisant partie intégrante de la présente description: - la figure 1 est un diagramme bloc d'un récepteur de télévision mettant en oeuvre le présent exemple de réalisation, - les figures 2a à 2c sont des diagrammes temporels des échanges ayant lieu entre une application, le module de gestion de données et la source de données, conformément au présent exemple, - la figure 3a, respectivement 3b est un diagramme d'état illustrant le fonctionnement d'une requête unique, respectivement permanente, - la figure 4 est un schéma d'un écran d'une application, à savoir un guide de programmes électronique selon le présent exemple de réalisation, - la figure 5 est un diagramme de la base de données maintenue par le module de gestion. On remarquera que pour de plus amples informations sur le format et le contenu des données de service, sections et tables MPEG et DVB, on se référera notamment aux trois documents suivants: (a) ETS 300 468 Specification for Service Information (SI) in Digital Video Broadcast (DVB) systems - January 23, 1996, 2752350 (b) ISO/IEC 13818-1 (1994) Generic Coding of Moving Pictures and Associated Audio - Recommendation H.220, aussi appelé "MPEG II Systems", et (c) ETR 211 - Digital Broadcasting systems for television: Implementation guidelines for the use of MPEG-2 systems; Guidelines on implementation and usage of service information. La figure 1 est un diagramme bloc d'un décodeur-récepteur intégré de télévision digitale de type DVB (Digital Video Broadcasting en anglais). Il est bien évident que l'invention ne se limite pas à cet environnement physique, mais peut être facilement adaptée à un autre type de transmission de données de service. Le décodeur de la figure 1 est relié à une antenne 1, elle même reliée à un tuner 2 du décodeur. Le signal fourni par le tuner est démodulé par un démodulateur 3. Les données démodulées sont corrigées par un circuit correcteur 4 et transmises à un démultiplexeur 5. Ce dernier est par exemple un démultiplexeur similaire à celui décrit dans la demande de brevet francçais 95 15767 déposée le 29 décembre 1995 au nom de THOMSON multimedia. Le démultiplexeur comporte un certain nombre de filtres programmés par un microprocesseur 23 en fonction des diverses applications supportées par le décodeur. Pour la clarté du schéma, seules les connexions les plus importantes du microprocesseur 23 sont illustrées. Les sections ou paquets audio ou vidéo filtrés par le démultiplexeur sont stockés dans des zones prédéfinies d'une mémoire tampon 6 à l'attention de ces applications. Si nécessaire, les informations sont tout d'abord décryptées par un circuit décrypteur 7 en fonction des droits de l'utilisateur, avant d'être stockées dans cette mémoire tampon 6. Selon le présent exemple, les applications sont au nombre de cinq: un décodeur audio 16, un décodeur vidéo 17, un décodeur Teletext 18, un ensemble de contrôle d'accès (comprenant le décrypteur 7, un microcontrôleur vérificateur 8 et une interface pour carte à microprocesseur 9 relié en mode de fonctionnement normal à 6 2752350 une carte à microprocesseur 10), ainsi qu'un module de gestion des données de service. Le décodeur comporte également une interface infrarouge d'une télécommande 24, ladite interface étant également reliée au microprocesseur 23. Ce dernier est connecté à une mémoire 12 comportant le système d'exploitation ainsi que les programmes résidents ou téléchargés de mise en oeuvre des applications. Un modem 13 relié au réseau téléphonique commuté 14 est également commandé par le microprocesseur. Un générateur de caractères 15 permet la génération de menus de commande ou de graphiques relatifs aux paramètres du décodeur ou à une application particulière. Le signal vidéo généré par ce générateur de caractères est multiplexé avec l'un des signaux vidéo en provenance du décodeur vidéo 1 7 ou du décodeur télétexte 18 vers i15 une première prise Péritel (prise SCART en anglais) reliée à un téléviseur 22 ou une seconde prise Péritel reliée à un magnétoscope 21. Le circuit de multiplexage 20 est géré par le microprocesseur 23. L'invention concerne plus particulièrement le fonctionnement du module de gestion des données de service. Dans le cas présent, ce module est physiquement parlant un programme géré par le microprocesseur, bien que conceptuellement, il s'agisse d'une application traitant des paquets de données, au même titre qu'un décodeur audio ou vidéo, pour lesquels des circuits dédiés sont utilisés. Le module est une interface entre les données de service (sections et tables MPEG et DVB) et des applications clientes (guide de programmes, téléachat, jeux interactifs, etc.). Il gère les requêtes des applications clientes et maintient une base de données interne à partir des données de service reçues. Selon le présent exemple de réalisation, I'application cliente est un guide de programmes également géré par le microprocesseur. Le module de gestion met à la disposition des applications clientes un certain nombre de fonctions destinées à formuler les requêtes relatives aux informations dont les applications ont besoin. 7 2752350 Les fonctions de requête ont un fonctionnement asynchrone. La réponse à une requête, si réponse il y a, est notifiée à une application par le module de gestion quand cette réponse est disponible. Ceci requiert la mise en oeuvre d'un mécanisme d'identification d'une fonction de requête. Dans ce but, un identifiant est choisi par l'application pour chaque requête émise et transmis avec cette requête. Cet identifiant est lié à la notification de réponse par le module de gestion. Les figures 2a à 2c illustrent les trois cas d'échanges, suite à une requête, entre l'application cliente, le module de gestion des données de service et la source de ces données, à savoir l'ensemble démultiplexeur-mémoire tampon-microprocesseur. La figure 2a concerne le cas o la base de données interne ("mémoire cache") comporte l'information requise par l'application cliente. La requête de cette dernière est suivie d'une notification de mise à disposition de cette information. L'information étant dans ce cas présente dans la base de données, la notification de réponse est quasi- immédiate. Dans ce cas, aucune donnée n'a à être transférée vers ou à partir de la source. La figure 2b illustre le cas o l'information demandée ne figure pas dans la base de données interne. Dans ce cas, la requête de l'application cliente est également suivie d'une notification par le module de gestion à l'application destinée à l'informer de I'indisponibilité temporaire de l'information, puis d'une commande adressée par le module de gestion à la source de données. Lorsque la ou les sections correspondant à l'information recherchée ont été trouvées dans le flux de données, démultiplexées et stockées dans la mémoire tampon, la source notifie le module SI que ces sections sont disponibles. Après lecture et reformattage des données des sections, le module de gestion notifie à son tour à l'application cliente que l'information recherchée est disponible. Le module écrit l'information recherchée (qui peut n'être qu'une partie des données de la section) dans une mémoire tampon allouée lors de sa requête initiale par I'application cliente. Cette notification arrive donc dans ce cas moins rapidement que dans le cas 2a. 8 2752350 Selon une variante, le module de gestion ne procède pas à la notification de l'indisponibilité de l'information. La figure 2c illustre le cas o la requête initiale telle que celle de la figure 2a spécifie que les changements de l'information recherchée doivent être signalés. Dans ce cas, les filtres de la source ayant permis d'extraire du flux de données le paquet de données contenant cette information sont maintenus aux valeurs précédentes au lieu d'être désactivés. Ce type de requête, dite requête permanente, sera décrite plus en détail ci-après. Selon le présent exemple de réalisation, il existe quatre types de requête: (a) Requête unique Lorsqu'une telle requête est adressée par l'application au module de gestion, celui-ci met à disposition ses ressources (filtre et mémoire) uniquement jusqu'au moment du transfert des données requises. Les ressources sont immédiatement libérées. (b) Requête unique anticipée Cette requête possède les caractéristiques de la requête unique, mais possède une priorité moindre. Le module de gestion maintient deux mémoires de type FIFO, I'une pour les requêtes anticipées, I'autre pour les requêtes non anticipées. Les requêtes anticipées en attente sont toujours traitées après les requêtes non anticipées. (c) Requête permanente Les ressources du module de gestion sont maintenues, même après démultiplexage et transfert des données requises. A chaque fois qu'un changement intervient dans ces données, une notification est transmise à l'application. Le module de gestion effectue donc une surveillance systématique, et ce jusqu'à ce que l'application envoie une commande d'interruption de cette surveillance. (d) Requête permanente anticipée Cette requête est similaire à la requête permanente, mais avec un niveau de priorité inférieur. 9 2752350 Les priorités fixées aux requêtes ne préjugent bien sûr en rien de l'ordre de réception véritable des données relatives à ces requêtes. Cet ordre dépend également de facteurs tels que la périodicité de chaque donnée et l'instant auquel la requête est formulée par rapport à cette période. La figure 3a est un diagramme d'état d'une requête unique, tandis que la figure 3b est un diagramme d'état d'une requête permanente. A chaque fois qu'une application formule une requête, un type de requête doit lui être associée. Dans le cas d'une requête permanente, les données récupérées dans le flux sont d'autre part mémorisées dans la base de données interne du module de gestion. Ce n'est pas le cas pour les données extraites suite à une requête unique, pour laquelle aucune copie des données n'est conservée. Lorsqu'une nouvelle version d'une table contenant des données relatives à une requête permanente est détectée (c'est à dire lorsque le paramètre version id de la table change), les données appropriées de cette table sont comparées aux données dans la base de données. Une notification de mise à jour n'est transmises que si au moins une de ces données a été modifiée. L'identificateur de version de la table est en effet modifié quelque soit la modification intervenue dans la table, même si elle ne concerne que des données non demandées par une application. Ce mécanisme évite un transfert de données redondantes entre l'application et le module de gestion. Le choix du type de requête est laissé à l'application. A titre d'exemple de critère de décision d'une application quant au type de requête, la figure 4 est un schéma d'un écran de guide de programme. L'écran comporte deux parties: une partie inférieure 40 donnant accès à des fonctions de commande grâce à une télécommande, ainsi qu'une partie supérieure 41, comportant une liste d'événements sélectionnés grâce auxdites commandes. Pour chacun des événements, le guide de programmes affiche le titre, le nom du service correspondant, I'heure de début et de fin. 2752350 La partie supérieure 40 ne peut afficher qu'une partie de la liste des événements. Pour accéder aux autres événements, l'utilisateur utilise des flèches de défilement de la télécommande. Lorsque l'application guide de programmes adresse au module de gestion les requêtes relatives aux informations des événements de la liste, les requêtes concernant les événements affichés en premier seront de type non-anticipé, c'est à dire prioritaire. Il s'agit là en effet d'informations devant obligatoirement être affichées. Les requêtes relatives aux autres événements de la liste seront de type anticipé, et traitées par le module de gestion après les requêtes non-anticipées. Il n'est en effet pas sûr que l'application ait besoin des informations correspondantes, car il n'est pas certain que l'utilisateur fasse effectivement défiler les événements si le renseignement qu'il cherche se trouve parmi les événements affichés au départ. Dans le but d'accélérer l'affichage de ces données au cas o elles seraient requises, elles sont cependant préchargées. Lorsque les données en réponse à une requête anticipée ont été démultiplexées, le module de gestion notifie ce fait à l'application ayant lancé la requête. Le transfert des données vers un buffer mis à disposition par I'application n'a cependant pas lieu tant que l'application ne demande pas ce transfert. L'un des rôles du module de gestion des données de service est de programmer les filtres du démultiplexeur. Pour remplir cette fonction et permettre un accès rapide aux données recherchées, il maintient conformément au présent exemple de réalisation une image de la structure physique du ou des réseaux (networks en anglais) auxquels il a accès. Les documents a et b définissent dix tables donnant des informations sur la configuration du ou des réseaux, bouquets, services et événements transmis. Les tables sont identifiées par des valeurs particulières de PID (Packet Identification Data en anglais) et d'identificateurs de tables (table_id), dont les valeurs sont définies par lesdits documents. Chaque table contient un identificateur de version, permettant de déterminer si d'une transmission de la table à l'autre, le contenu de cette table a changé. 1il 2752350 La table qui nous intéresse ici est la table appelée NIT (pour Network Information Table en anglais). La table NIT comporte des informations sur un réseau de transmission donné, notamment la liste des services disponibles par canal de transmission (Transport Stream en anglais). Le module de gestion de données construit une indexation interne des réseaux, canaux et services disponibles. Lors de la mise en route du décodeur ou lors d'une mise à jour de la table NIT, une clé logique est attribuée à chacun des services disponibles. Cette clé est I'index de ce service dans la base de données maintenue par le module. Dans un système DVB, un service est localisable de manière unique par le chemin comprenant les variables suivantes - network id (identifiant du réseau), - couple (transport stream_id; original_network_id) - serviceid (identifiant du service proprement dit). Les trois variables sont des entiers naturels codés sur 16 bits. Trois types de listes sont créés: une liste pour les réseaux, une liste de canaux pour chaque réseau et une liste de services pour chaque canal. Un élément de la liste des réseaux est créé chaque fois qu'une table NIT comportant un nouveau réseau est démultiplexée. Pour ce faire, les paquets de transport dont le PID est égal à OxOO10 sont filtrés. Ces paquets contiennent en effet les tables NIT, identifiées de plus par une variable table id. Un code sur 4 bits est associé à chaque réseau, dans l'ordre du démultiplexage des tables correspondantes. Le code est l'index du pointeur adresse de la structure comportant les informations relatives à ce réseau. La table NIT comporte la liste des canaux pour ce réseau, ainsi que pour chaque canal la liste des services disponibles. Pour chaque réseau de la liste de réseaux, une liste de canaux est créée. Chaque élément d'une liste de canaux est indexé à l'aide de 5 bits. La liste contient les pointeurs d'adresse des structures 12 2752350 comportant les données spécifiques à chaque canal. La clé logique pour identifier un canal dans la base de données se compose des 4 bits d'index du réseau, suivis des 5 bits de l'index du canal de ce réseau. Pour chaque canal, une liste de services est créé, comportant les identifiants des services décrits par la table NIT. Chaque service dans une liste est indexé sur 7 bits. La clé logique d'un service dans la base de données comporte donc en tout 16 bits: 4 bits d'index de réseau, 5 de canal et 7 de service. Un événement d'un service sera identifié à l'aide des 16 bits désignant cet événement (variable eventid de la table), auxquels on ajoutera les 16 bits de clé logique du service associé. La structure de la base de données (hors événements) est organisée selon les structures suivantes ::: Base de -onnées:: AdresseListeRéseaux jisteReseaux ! AdresseRéseau i AdresseRéseau 2 AdresseRéseau 3 AdresseRéseau 4 AdresseRéseau AdresseRéseau 6 AdresseRéseau 7 AdresseRéseau IAdresseProchaineListeRéseaux Réseau IdentificateurRéseau ("network id") NomRéseau ("network name") AdresseListeCanaux 13 2752350 ListeCanaux O AdresseCanal 1 AdresseCanal 2 AdresseCanal 3 AdresseCanal 4 AdresseCanal AdresseCanal 6 AdresseCanal 7 AdresseCanal AdresseProchainTableauCanaux Cana - Identificateurcanal ("TranportStream id") IdentificateurRéseauOrigine ("OriginalNetwork Id") AdresseListeServices 0 AdresseService 1 AdresseService 2 AdresseService 3 AdresseService 4 AdresseService AdresseService 6 AdresseService 7 AdresseService AdresseProchainListeServices -Servi ce IdentificateurService ("service id") NomService ("service name") Etat ("runningstatus")... 14 2752350 Les variables dont le nom contient le terme "Adresse" sont des pointeurs vers des zones mémoire correspondant au début d'une structure de données. Les autres variables correspondent à des informations extraites du flux de données. Pour faciliter la compréhension, ces variables sont suivies entre parenthèses et guillemets de la dénomination utilisée dans le document (a). On notera que les listes de réseaux, de canaux et de services sont chacune organisées en tableaux, chaque tableau étant composé de d'une part de huit pointeurs vers des structures de données de type réseau, canal ou service, et d'autre part d'un pointeur vers un éventuel tableau comportant la suite de la liste. Ce dernier pointeur est nul lorsqu'il n'existe pas d'autre tableau, c'est-à-dire lorsqu'un tableau comporte les derniers éléments d'une liste. Le tableau Base de données contient un pointeur vers le tableau contenant la première partie de la liste de réseaux. Le tableau ListeRéseaux comporte les pointeurs vers les huit premiers réseaux. Selon le présent exemple de réalisation, il y a au maximum deux tableaux ListeRéseaux, contenant la liste complète des réseaux. Le tableau Réseau comporte les informations relatives à un réseau donné, ainsi qu'un pointeur vers la liste des canaux associés à ce réseau. La structure des autres tableaux est similaire à ce qui vient d'être dit. Il est d'autre part facile de l'étendre aux événements et à d'autres types de données. Selon une variante de réalisation, les requêtes relatives aux données concernant la structure du réseau, des canaux et des services sont des requêtes de type permanent, ceci dans le but de maintenir constamment à jour l'image du réseau dans la base de données. Dans leurs échanges avec le module de gestion, les applications utilisent uniquement les clés logiques. Celles-ci sont traduites par le module en une adresse mémoire correspondant à I'endroit o est stockée l'information. 2752350 La figure 5 est un diagramme de la base de données du module de gestion dans le cas de l'existence d'un réseau, comportant deux canaux, chaque canal comportant lui-même deux services. La table des requêtes applicatives donne la liste des requêtes en cours formulées par les applications. Selon le présent exemple, la seule requête en cours est une requête de type permanent destinée à récupérer la liste des services présents sur un réseau. La table des requêtes du module de gestion comporte les requêtes primitives correspondant aux requêtes applicatives. Une requête primitive est dans le contexte présent une requête pouvant être traduits en un seul filtre au niveau du démultiplexeur. Dans le cas présent, étant donné que deux canaux existent dans le réseau, deux requêtes primitives sont nécessaires pour traduire la requête applicative: une requête primaire par liste de services ou encore par canal. C'est le module de gestion qui effectue la séparation des requêtes applicatives en requêtes primitives. Sur la figure, les filtres correspondant à chaque requête primitive se trouvent à gauche de la table des requêtes du module de gestion. On suppose qu'à l'instant illustré par la figure 5, les listes de service ont été acquises une première fois. Etant donné la nature permanente de larequête applicative, les filtres correspondants, ainsi que le contenu de la base de données concernant cette requête sont maintenus. Les chiffres identifiant les branches reliant une liste et un élément dans cette liste correspondent à l'index (clé logique) de cet élément dans la liste. L'application cherche maintenant à obtenir la liste des événements en cours dans le réseau. Il existe un événement en cours par service; ceci impose de filtrer la table 'EIT Present/Following' ("Event Information Table" en anglais) correspondante. La requête émise par l'application comporte, pour un service donné, les paramètres suivants: - un identificateur de requête, - le type de la requête, - la clé logique du service concerné, 16 2752350 - un ensemble de drapeaux indiquant quelles sont les données des descripteurs d'événement qui seront à stocker dans la base, - une structure de données destinée à contenir d'une part I'heure de début de l'événement, sa durée, une information sur le contrôle d'accès et le nom de l'événement, et d'autre part un pointeur d'adresse vers l'adresse à partir de laquelle les données identifiées par les drapeaux seront stockées. Selon le présent exemple, on suppose que les requêtes relatives aux événements en cours du premier canal (TS_id =7) sont non-anticipées, tandis que les requêtes relatives aux événements en cours du second canal (TS_id = 9) sont anticipées. Ceci peut par exemple être le cas lorsque seuls deux événements peuvent être affichés en même temps, et que les événements des services 1 (Service_id = 1) et 3 (Service_id =3) sont affichés en premier à l'écran. Pour obtenir les renseignements sur les événements en cours, I'application doit lancer quatre requêtes distinctes, qui sont déjà des requêtes primitives. On supposera dans ce qui suit que ces requêtes ne sont pas permanentes. Les données concernant les événements ne seront par conséquent pas stockées dans la base de données interne, une fois transférées vers l'application cliente. Le module de gestion passe en revue les requêtes primitives et traite en priorité les requêtes non-anticipées. Les clés logiques transmises par l'application seront respectivement: 0. 0.0 0.0.1 0.1.0 0.1.1 o le premier chiffre représente le réseau, le second le couple (canal, réseau d'origine) et le troisième le service. Grâce aux listes maintenues par le module de gestion, les identificateurs réels peuvent être envoyés au démultiplexeur, en donnant priorité aux deux premières requêtes. La valeur du PID de la table EIT (PID=0xOO12) ainsi que l'identificateur de la table 17 2752350 EIT_present_following (table id = Ox4E) sont définis par le document (a) et sont accessibles via une table de correspondance indexée par la fonction de requête. A l'aide de ces informations, un des filtres du démultiplexeur peut être programmé. Selon une variante de réalisation, en cas de mémoire insuffisante, au moins une partie des données stockées correspondant aux requêtes anticipées permanentes est effacée. Selon une variante de réalisation, le type d'une requête en cours peut être changé. Un exemple particulier envisagé consiste à changer une requête de type permanent non anticipé en une requête de type permanent anticipé. Une fonction spécifique pour un tel i 5 changement est disponible pour l'application cliente. Selon une variante, le module de gestion génère lui-même certaines requêtes relatives à la structure des réseaux (notamment la liste des réseaux et les listes de canaux associées) et les maintient de facçon permanente. Il est à noter que l'invention ne se limite pas à la seule transmission de données par voie satellitaire, hertzienne ou par câble, mais peut être mise en oeuvre dans tout système o des données ou paquets de données apparaissent périodiquement dans le flux de données. Ceci est notamment le cas pour des flux de données enregistrés et relus. 18 2752350 REVENDICATIONS 1. Procédé d'extraction de données d'un flux de données dans un système de transmission cyclique de données par paquets comportant au moins un récepteur caractérisé en ce qu'il comporte, au niveau du récepteur, les étapes: - de détermination de requêtes d'extraction relatives aux données à extraire, - de détermination d'un niveau de priorité de chaque requête, - de programmation de filtres de paquets de données dans l'ordre de priorité desdites requêtes, - d'extraction desdites données à partir des paquets filtrés. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de détermination d'un niveau de priorité comprend la détermination d'un niveau de priorité anticipé et d'un niveau de priorité non-anticipé, le niveau de priorité non-anticipé ayant une priorité plus haute que le niveau de priorité anticipé. 3. Procédé selon la revendication 2, caractérisé en ce que le niveau de priorité non-anticipé est attribué à des requêtes relatives à des données dont le traitement par une application est certain. 4. Procédé selon la revendication 3, caractérisé en ce que le niveau de priorité non-anticipé est attribué à des requêtes relatives à des données destinées à être affichées le plus rapidement possible. 5. Procédé selon l'une des revendications 3 ou 4, caractérisé en ce que le niveau de priorité anticipé est attribué à des requêtes relatives à des données dont le traitement par une application n'est pas certain. 6. Procédé selon l'une des revendications précédentes, caractérisé en ce que, ledit récepteur comportant d'une part au moins une application comprenant des moyens pour déterminer lesdites 19 2752350 requêtes et traiter les données extraites et d'autre part des moyens de gestion desdites requêtes et de programmation desdits filtres (5), ledit procédé comporte en outre les étapes: - de mémorisation (6) des données relatives à une requête déterminée par ladite application suite à leur extraction, - de notification d'une application par lesdits moyens de gestion et de programmation (19,)de la disponibilité desdites données. 7. Procédé selon la revendication 6, caractérisé en ce qu'une requête est de type permanent, lesdits moyens de gestion et de programmation maintenant ladite requête jusqu'à avis contraire de l'application dont cette requête est originaire. 8. Procédé selon la revendication 7, caractérisé en ce que lesdits moyens de gestion et de programmation maintiennent une base de données comportant les données relatives à des requêtes permanentes. 9. Procédé selon la revendication 8, caractérisé en ce qu'une application ayant formulé une requête permanente n'est notifiée d'une mise à jour des données relatives à cette requête que si le numéro de version de la structure de données du flux de données correspondant à ces données change et qu'en même temps il existe une différence entre au moins une valeur d'une donnée stockée dans la base de données et la valeur de cette donnée extraite du flux de données. 10. Procédé selon la revendication 6, caractérisé en ce qu'une requête est de type unique, ladite requête de type unique étant effacée après notification des données relatives à cette requête par lesdits moyens de gestion et de programmation. 11. Dispositif d'extraction de données d'un flux de données dans un système de transmission cyclique de données par paquets comportant au moins un récepteur caractérisé en ce qu'il comporte: - des moyens (5) de démultiplexage et de filtrage desdits paquets, 2752350 - des moyens (23) de détermination de requêtes d'extraction relatives aux données à extraire et de détermination d'un niveau de priorité de chaque requête, - des moyens (19, 23) de programmation desdits moyens de démultiplexage et de filtrage dans l'ordre de priorité desdites requêtes, - des moyens (19, 23) d'extraction desdites données à partir des paquets filtrés. 12. Dispositif selon la revendication 11, caractérisé en ce que les moyens de détermination de requêtes relatives aux données à extraire et de détermination d'un niveau de priorité de chaque requête comprennent une application de type guide électronique de programmes. 13. Dispositif selon les revendications 1 1 ou 12, caractérisé en ce qu'il met en oeuvre le procédé selon l'une des revendications 1 à 10. 14. Récepteur de télévision digitale, caractérisé en ce qu'il comprend un dispositif selon l'une des revendications 10 à 13.