Brevet FR2752351A1 — publié le 19980213

Procédé d'indexation de données dans un système de transmission de télévision numérique L'invention concerne un procédé d'indexation de données, notamment de données de service, dans un système de transmission de télévision numérique. L'invention s'applique au récepteur de telles transmissions. Certains systèmes de télévision numérique tels que le DVB (pour Direct Video Broadcasting en anglais) prévoient la transmission de données dites de services en multiplex avec les données vidéo et audio. ces données de services (données 'SI') comportent par exemple des informations sur l'organisation hiérarchique du flux numérique reçu ou d'un autre flux. Cette hiérarchie peut comprendre plusieurs réseaux de transmission, chaque réseau comportant plusieurs canaux, chaque canal comportant divers services, etc. Un récepteur et décodeur de télévision numérique doit pouvoir connaître cette hiérarchie pour pouvoir accéder aux données transmises. Or, la gestion de cette hiérarchie pose des problèmes car elle est d'une part évolutive par nature, d'autre part soumise à des contraintes de standardisation qui peuvent ne pas être adaptées aux contraintes de produits grand public. Par exemple, chaque élément de la hiérarchie (réseaux, canaux, services, etc.) est identifié à l'aide d'un identificateur dont la longueur standardisée est relativement grande, ce qui peut poser des problèmes de stockage et de traitement de ces identificateurs. Pour identifier, par exemple, un service de manière unique, huit octets seraient théoriquement nécessaires. Ces huit octets devraient être utilisés à chaque référence au service et devraient ainsi être stockés de nombreuses fois par les applications du récepteur. L'invention a pour objet un procédé d'indexation de données dans un système de transmission de télévision numérique à organisation hiérarchique comportant au moins un récepteur caractérisé en ce qu'il comprend, au niveau du récepteur, les étapes - d'extraction du flux de données numérique transmis d'au moins une liste d'éléments parmi les listes de réseaux, de canaux pour un réseau donné, de services pour un canal donné ou d'événements pour un service donné, - de mémorisation d'un tableau comportant un pointeur d'adresse par élément particulier de la liste, ce pointeur pointant vers une zone mémoire du récepteur comportant des informations supplémentaires relatives audit élément particulier, - d'utilisation, par une application dudit récepteur, de l'index d'un élément particulier dans ledit tableau pour désigner ledit élément particulier. Le récepteur se constitue ainsi une image d'au moins une partie de la hiérarchie des données auxquelles il peut avoir accès. Les listes de réseaux, canaux, services, événements, ou d'ailleurs d'autres éléments (bouquets, etc.) sont mémorisées et indexées par le récepteur. L'indexation permet de réduire considérablement la place mémoire nécessaire pour stocker les identificateurs. Une fois établie la relation entre un index et un élément (ou la structure de données comportant les informations relatives à cet élément), ce seront les index qui seront employés pour faire référence à un élément. La nature hiérarchique des données permet de référencer de manière unique un élément, par exemple un service, en juxtaposant les index de réseau, de canal et de service. L'utilisation de la "clé logique" constituée par les index diminue le temps d'exécution en évitant la recopie de la "clé physique" dans la pile du processeur à chaque appel de fonction et en réduisant les comparaisons nécessaires lors de parcours de la base de données interne lors d'une recherche de donnée. Selon un mode de réalisation particulier, une liste d'éléments est répartie sur plusieurs tableaux de même dimension, le dernier pointeur d'adresse d'un tableau pointant vers le tableau suivant. Les listes d'éléments sont répartis sur plusieurs tableaux pour en faciliter la gestion. Les tableaux sont reliés par des pointeurs d'adresse pointant vers un éventuel tableau suivant. Selon un mode de réalisation particulier, un tableau comporte un nombre de pointeurs d'adresse relatifs à un élément de liste égal à une puissance de deux. L'utilisation d'une puissance de deux permet d'obtenir facilement le tableau contenant le pointeur d'un élément recherché en masquant le nombre de bits adéquats dans l'index de cet élément. D'autres caractéristiques et avantages de l'invention 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, (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). II 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 francais 95 15767 déposée le 29 décembre 1995 au nom de THOMSON multimedia. Le démultiplexeur 5 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 à 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 1 2 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 1 3 relié au réseau téléphonique commuté 1 4 est également commandé par le microprocesseur. Un générateur de caractères 1 5 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 1 8 vers 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.). II gère les requetes 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, l'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 requetes relatives aux informations dont les applications ont besoin. 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 l'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 l'application cliente. Cette notification arrive donc dans ce cas moins rapidement que dans le cas 2a. Selon une variante, le module de gestion ne procède pas à la notification de l'indisponibilité de l'information, mais accuse simplement réception de la requête. 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, L'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. 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. La partie supérieure 40 ne peut afficher qu'une partie de la liste des événements. Pour accéder aux autres événements, I'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. II 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. II 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 l'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é. 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 l'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), - service~id (identifiant du service proprement dit). Les trois variables sont des entiers naturels codés sur 1 6 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 à Ox0010 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 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 event~id 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 f3zlse de données AdresseListeRéseaux ListeRéseaux O AdresseRéseau 1 AdresseRéseau 2 AdresseRéseau 3 AdresseRéseau 4 AdresseRéseau 5 AdresseRéseau 6 AdresseRéseau 7 AdresseRéseau AdresseProchainTableauRéseaux Reseau IdentificateurRéseau ("network id") NomRéseau ("network name") AdresseListeCanaux 77 Liste(:anaux O AdresseCanal i AdresseCanal 2 AdresseCanal 3 AdresseCanal 4 AdresseCanal 5 AdresseCanal 6 AdresseCanal 7 AdresseCanal AdresseProchainTableauCanaux Canal Identificateurcanal ("TranportStream~id") IdentificateurRéseauOrigine (11OnginalNetwork Id") AdresseListeServices ListeServices O AdresseService 1 AdresseService 2 AdresseService 3 AdresseService 4 AdresseService 5 AdresseService 6 AdresseService 7 AdresseService AdresseProchainTableauServices Service IdentificateurService ("service~id") NomService ("service name") Etat ("running~status")... 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. Ce dernier pointeur n'est pas indexé. Les tableaux comportent huit éléments, ce qui correspond à une puissance de deux. Ceci permet de déterminer le tableau comportant un pointeur recherché en masquant, dans ce cas, les trois derniers bits de l'index de canal. 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 Liste Ré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 le premier tableau de la liste des canaux associés à ce réseau. La structure des autres tableaux est similaire à ce qui vient d'être dit. II 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 à l'endroit où est stockée l'information. 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 traduite 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 la requê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. II existe un événement en cours par service; ceci impose de filtrer la table 'EIT Present/Following' ("évent 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é, - 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 l'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 010 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 (PlD=0x0012) ainsi que l'identificateur de la table ElT~present~following (table~id = 0x4E) 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 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 façon permanente. II 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. REVENDICATIONS 1. Procédé d'indexation de données dans un système de transmissions de télévision numérique à organisation hiérarchique comportant au moins un récepteur caractérisé en ce qu'il comprend, au niveau du récepteur, les étapes - d'extraction du flux de données numérique transmis d'au moins une liste d'éléments parmi les listes de réseaux, de canaux pour un réseau donné, de services pour un canal donné ou d'événements pour un service donné, - de mémorisation d'un tableau comportant un pointeur d'adresse par élément particulier de la liste, ce pointeur pointant vers une zone mémoire du récepteur comportant des informations supplémentaires relatives audit élément particulier, - d'utilisation, par une application dudit récepteur, de l'index d'un élément particulier dans ledit tableau pour désigner ledit élément particulier. 2. Procédé selon la revendication 1, caractérisé en ce qu'une liste d'éléments est répartie sur plusieurs tableaux de même dimension, le dernier pointeur d'adresse d'un tableau pointant vers le tableau suivant. 3. Procédé selon la revendication 2, caractérisé en ce qu'un tableau comporte un nombre de pointeurs d'adresse relatifs à un élément de liste égal à une puissance de deux.