Brevet FR2902267A1 — publié le 20071214

Procédés de réception et d'émission de services de télévision numérique. 1. Domaine de l'invention. La présente invention concerne la transmission de services de télévision numérique sur un réseau de diffusion ou de communication bidirectionnel. Plus précisément, l'invention se rapporte au domaine des changements de services (ou zapping en anglais). 2. Etat de l'art. Selon l'état de la technique, le passage d'un service de télévision numérique à un autre dans un récepteur peut prendre du temps (typiquement quelques dixièmes de seconde à plusieurs secondes). En effet, le décodeur doit recevoir une image qu'il peut décoder (typiquement une image Intra ou I selon la technologie MPEG, insérée dans un flux d'images P (ou Predict signifiant en français prédites ) et B (ou Bidirectionnelles). Afin de réduire la bande passante nécessaire, le nombre d'images I est réduit. En outre, lorsqu'un réseau IP (ou Protocole Internet de l'anglais Internet Protocol ), des mémoires tampons sont utilisées pour compenser la gigue du réseau. Aussi, un écran noir plus ou moins long s'affiche lors d'un changement de service. 3. Résumé de l'invention. L'invention a pour but de pallier les inconvénients de l'art antérieur et en particulier d'améliorer le changement d'un service de télévision numérique à un autre. A cet effet, l'invention propose un procédé de réception de services de télévision numérique, remarquable en ce qu'il comprend une étape de réception d'au moins une information représentative du délai d'affichage d'un nouveau service (en particulier lors du chargement d'un premier service ou lors d'un changement de service), l'information étant insérée dans des données de contrôle qui comprennent au moins une liste de services. Ainsi, un récepteur (par exemple un décodeur, un téléviseur, un dispositif d'enregistrement, un terminal de communication, un ordinateur), recevant une information représentative du délai d'affichage du nouveau service peut utiliser cette information pour effectuer une action dépendant de ce temps (par exemple affichage, fondu, ...). Selon une caractéristique avantageuse, la ou les information s représentatives du délai d'affichage d'un nouveau service comprennent une information représentative de la durée du délai de décodage et/ou de transport du nouveau service. Selon une autre caractéristique, il comprend une étape de réception d'au moins une information représentative d'une action à effectuer lors du chargement d'un nouveau service, l'information étant insérée dans des données de contrôle qui comprennent au moins une liste de services. Avantageusement, il comprend une étape de fourniture d'au moins un contenu à afficher pendant un changement de service (par exemple du texte, une ou plusieurs images, vidéo). Selon une caractéristique particulière, il comprend une étape du choix du contenu en fonction de la ou des informations représentatives du délai d'affichage d'un nouveau service. Avantageusement, il comprend une étape de réception d'au moins une information représentative du contenu et/ou de son emplacement. Selon une caractéristique avantageuse, il comprend la réalisation d'un fondu pendant le changement de service, la durée du fondu dépendant de la ou des informations représentatives du délai d'affichage d'un nouveau service. Selon une caractéristique particulière, la ou les information s représentatives du délai d'affichage d'un nouveau service sont dans une structure XML (dans DVB-IP) et/ou dans une table de signalisation du flux (par exemple table SI/PSI pour DVB/MPEG). L'invention concerne également un procédé d'émission de services de télévision numérique, remarquable en ce qu'il comprend une étape d'émission d'au moins une information représentative du délai d'affichage d'un nouveau service, l'information étant présente dans des données de contrôle comprenant au moins une liste de services. Selon une caractéristique avantageuse, le procédé d'émission comprend une étape de détermination de la ou des informations en fonction des paramètres d'encodage vidéo (par exemple structure du GOP) associés au nouveau service. Selon une caractéristique particulière, il comprend une étape de détermination de la ou des informations en fonction des paramètres du transport du flux vidéo (par exemple taille et nombre de mémoires tampon nécessaires pour éliminer la gigue réseau) associé au nouveau service. Avantageusement, le procédé d'émission comprend une étape d'émission d'au moins une information représentative d'une action à effectuer par un décodeur lors d'un chargement de service, la ou les informations étant présentes dans des données de contrôle comprenant au moins une liste de services. 4. Liste des figures. L'invention sera mieux comprise, et d'autres particularités et avantages apparaîtront à la lecture de la description qui va suivre, la description faisant référence aux dessins annexés parmi lesquels : la figure 1 illustre un système de diffusion de services de télévision numérique, selon l'invention ; les figures 2 et 3 sont des synoptiques très schématiques respectivement d'un décodeur et d'un serveur du système de la figure 1, mettant en oeuvre l'invention ; les figures 4 et 5 représentent chronologiquement, les échanges de données entre des éléments du système de la figure 1 ; et les figures 6 et 7 illustrent des algorithmes mis en oeuvre respectivement dans un procédé de réception et un procédé d'émission de services de télévision numériques selon l'invention. 5. Description détaillée de l'invention. D'une manière générale, l'invention permet de tirer profit de la connaissance du temps de changement de service en évitant l'affichage d'un écran noir. Ainsi, selon différents modes de réalisation, ce temps dont une estimation est transmise avec la liste de services, peut être utilisé pour afficher une image fixe, une information sous forme textuelle ou encore des images animées (le contenu affiché dépendant ou non du service quitté et/ou du nouveau service). Il peut également être utilisé pour un changement doux de programme, en mettant en oeuvre un fondu (ou fading en anglais) associé à l'une des dernières image (et préférentiellement la dernière) du service quitté et dont la durée dépend du temps estimé, de chargement du nouveau service. Les informations sur les services de télévision numériques sont transmises dans des structures spécifiques. Ainsi, dans le cas d'une diffusion (en anglais broadcast ) monodirectionnelle (par exemple sur DVB-T (ou Diffusion de Télévision Numérique û Terrestre de l'anglais Digital Video Broadcasting û Terrestrial ) ou DVB-S (ou DVB satellite) ou encore DVB-H (ou DVB- mobile de l'anglais DVB-Handheld ), des listes de services sont diffusées sous forme de tables SI/PSI (de l'anglais System Information/Program Specific Information ou Information de système/ Information spécifique de programme en français) et récupérées par les décodeurs. Avec une diffusion bidirectionnelle (par exemple sur un réseau internet à large bande), les listes de services peuvent être diffusées sous forme de structure SD&S (de l'anglais Service Description & Selection ou Sélection et description de services en français). Les listes de services permettent de décrire des services ou programmes de télévision numériques et donnent des informations pour trouver un service et le charger. Selon l'invention, on améliore les listes de services connues en y insérant des informations représentatives du temps de chargement (ou du délai d'affichage) d'un nouveau service. Préférentiellement, le format des listes reste générique pour ne pas être lié à une technologie de codage particulière. A titre illustratif, le codage MPEG est basé sur l'utilisation de GoP (de l'anglais Group of Pictures ou Groupe d'Images en français). Un GoP est une séquence de différents types d'images, et notamment d'images Intra I, Predict P et Bidirectionnelles B. Seules les images I peuvent être utilisées pour démarrer un décodage de flux vidéo, les images P et B se référant directement ou indirectement à une image I. Ainsi, si la structure d'un flux a un GOP du type IBBPBBPBBPBB, une image I est présente toutes les 12 images soit toute les demi-secondes. Ainsi, le décodeur peut être amené à attendre 0,5 s avant d'afficher un service, la moyenne se situant autour de 0,25 s. Ainsi, selon l'invention, la liste de service comprend pour au moins une partie des services et préférentiellement pour chaque service une estimation statistique du temps de chargement d'un service associé (par exemple temps moyen ou temps maximum). Dans le cadre d'une transmission sur un réseau internet, le temps de chargement dépend également du temps de transport, par exemple du temps nécessaire pour remplir les mémoires tampon (ou buffers en anglais) vidéo et qui leur permet de ne pas s'assécher ou de déborder, ces mémoires tampon étant utilisées sur le réseau entre un serveur vidéo du service requis et le décodeur. Ce temps est généralement négligeable pour les services diffusés par voie hertzienne ou satellite monodirectionnelle. En revanche, il peut être de l'ordre de 0,5s à plusieurs secondes pour les services diffusés sur un réseau internet. Ainsi, préférentiellement, l'estimation statistique du temps de chargement d'un service associé (par exemple temps moyen ou temps maximum) transmise avec la liste de service tient compte à la fois des délais associés au décodage et des paramètres de transport des flux vidéo correspondant au service demandé. La figure 1 illustre schématiquement un système 1 de diffusion de services de télévision numérique, selon un mode particulier de réalisation de l'invention. Le système 1 comprend : - un décodeur 10 ; - un réseau internet 18 auquel est relié un serveur SD&S 12 et un serveur de télévision numérique 13 ; et - un réseau de diffusion monodirectionnel 16 auquel est relié un serveur SI/PSI 14 et un serveur de télévision numérique 15. Le décodeur 10 est adapté à recevoir des services de télévision numériques d'au moins un des réseaux 16 ou 18. Le décodeur est adapté à charger et décoder un service requis par l'utilisateur pour l'afficher sur un téléviseur (non représenté). Afin de faciliter la compréhension de l'invention, seul un décodeur a été représenté. Bien entendu, les flux de télévision numérique sont diffusés vers de nombreux décodeurs mettant en oeuvre l'invention. Par ailleurs, les réseaux 16 et 19 peuvent comprendre plusieurs serveurs de listes de service mettant en oeuvre l'invention et plusieurs serveurs vidéos. En outre, ils peuvent se recouper, un serveur de listes de service et/ou un serveur vidéo pouvant appartenir aux deux réseaux. De plus, le décodeur 10 peut être adaptés à recevoir des données de plusieurs réseaux distincts (par exemple DVB-T et DVB-S) et/ou être connecté à de tels réseaux via une passerelle ou un routeur. La figure 2 illustre schématiquement le décodeur 10. Le décodeur 10 comprend, reliés entre eux par un bus d'adresses et de données 103 : -un microprocesseur 100 (ou CPU) ; - une mémoire non volatile de type ROM (de l'anglais Read Only Memory ) 101 ; - une mémoire vive ou RAM (de l'anglais Random Access Memory ) 102 ; - une interface 104 permettant de recevoir des informations de flux d'images et de données de contrôle des réseaux 16 et/ou 18 et, le cas échéant, de transmettre des informations ou requêtes vers le réseau 18 ; et - une interface 105 transmettant le contenu propre au chargement d'un service et les données audio/vidéo du service requis reçues vers l'application audio/vidéo (par exemple pour affichage ou enregistrement). Par ailleurs, chacun des éléments illustrés en figure 2 est bien connu de l'homme du métier. Ces éléments communs ne sont pas décrits ici. On observe que le mot registre utilisé dans la description désigne dans chacune des mémoires mentionnées, aussi bien une zone de mémoire de faible capacité (quelques données binaires) qu'une zone mémoire de grande capacité (permettant de stocker un programme entier ou tout ou partie des données représentatives d'un service audio/vidéo reçu ou d'un contenu utilisé lors d'un chargement de service). La mémoire ROM 101 comprend notamment : - un programme prog 1010 ; et - un paramètre de seuil temporel t-seuil 1011. Les algorithmes mettant en oeuvre les étapes du procédé décrit ci-après sont stockés dans la mémoire ROM 101 associée au décodeur 10 mettant en oeuvre ces étapes. A la mise sous tension, le microprocesseur 100 charge et exécute les instructions de ces algorithmes. La mémoire vive 102 comprend notamment : - dans une registre 1020, le programme de fonctionnement du microprocesseur 100 chargé à la mise sous tension du décodeur 10 ; - un flux vidéo correspondant au service décodé dans un registre 1021 ; - une ou plusieurs listes de services dans un registre 1022 ; - une valeur de temps moyen associé à chaque service dans un registre 1023 mis à jour à la réception d'une liste de services associée au service correspondant; - une adresse de contenu associé à chaque service dans un registre 1024 mis à jour à la réception d'une liste de services associée au service correspondant ; - un contenu et une action associés à chaque service dans un registre respectivement 1025 et 1026 mis à jour à la réception d'une liste de services associée au service correspondant ou à tout moment après la réception de la liste de services ou encore lors du chargement du service ; et - une information représentative du service demandé dans un registre 1027. La figure 3 illustre schématiquement le serveur 12. Par ailleurs, le serveur 14 a une structure tout à fait similaire. Le serveur 12 comprend, reliés entre eux par un bus d'adresses et de données 123 : -un microprocesseur 120 (ou CPU) ; - une mémoire non volatile de type ROM 121 ; - une mémoire vive ou RAM 102 ; - une interface 124 permettant de transmettre des données de contrôle du réseau 18 et, le cas échéant, de recevoir des informations ou requêtes vers le réseau 18 ; et - une interface applicative 125. Par ailleurs, chacun des éléments illustrés en figure 3 est bien connu de l'homme du métier. Ces éléments communs ne sont pas décrits ici. La mémoire ROM 121 comprend notamment : - un programme prog 1210. Les algorithmes mettant en oeuvre les étapes du procédé décrit ci-après sont mémorisés dans la mémoire ROM 121 associée au serveur 12 mettant en oeuvre ces étapes. A la mise sous tension, le microprocesseur 120 charge et exécute les instructions de ces algorithmes. La mémoire vive 122 comprend notamment : - dans une registre 1220, le programme de fonctionnement du microprocesseur 120 chargé à la mise sous tension du serveur 12 - les listes de services associés à chaque fournisseur du réseau 18 dans un registre 1221 ; - une valeur de temps moyen associé à chaque service dans un registre 1222 ; - une adresse de contenu associé à chaque service dans un registre 1223 ; - un contenu (par exemple image fixe, texte, images animées) associé à chaque service dans un registre 1224 ; - une action (par exemple, chargement, lien RSS, fondu, texte, néant, ...) associée à chaque service dans un registre 1225 ; les paramètres d'encodage vidéo propres à chaque service dans un registre 1226 ; et - les paramètres de transport propres à chaque service dans un registre 12276. Selon une variante de l'invention, seule une partie des services ont des valeurs de temps moyens associés et/ou un contenu associé et/ou une adresse de contenu associé. On peut définir une valeur par défaut de ces données indiquant un champ vide dans la mémoire 122 pour prendre en compte cet aspect. Selon une autre variante les registres 1023 à 1025 ne sont pas utilisés, les valeurs correspondantes étant directement inscrite dans la liste 1022. Selon encore une autre variante pouvant être combinées avec les précédentes, le registre 1023 comprend à la place ou en sus du temps moyen, un temps minimum ou maximum associé à chaque service. La figure 4 représente chronologiquement, les échanges de données entre le décodeur 10, le serveur vidéo 13 et le serveur SD&S 12. Lors d'une première étape, le décodeur 10 transmet vers le serveur 12 une requête 400 pour obtenir la liste des services suivant un protocole SD&S. Ensuite, le serveur 12 lui transmet la liste 401 des fournisseurs de services. Puis, le décodeur 10 transmet au serveur 12 une requête 402 demandant la liste des services d'un fournisseur particulier (par exemple le serveur 13). Le serveur 12 transmet la liste 403 des services requis telle que mémorisée dans le registre 1221, cette liste 403 étant sous la forme d'une structure XML (de l'anglais eXtensible Markup Language ) et le décodeur 10 mémorise cette liste dans le registre 1022 avec les informations associées au temps de chargement et au contenu associés aux services de la liste lorsqu'elles sont fournies. Puis, le décodeur 10 transmet au serveur 13 une commande 410 IGMP (de l'anglais Internet Group Management Protocol ou Protocole de gestion de groupe internet en français) demandant un service particulier (commande join selon le protocole IGMP avec adresse IP du service) et reçoit le flux vidéo 411. Lorsque le chargement du service requis est demandé par l'utilisateur, le décodeur 10 affiche le contenu (après un test éventuel du temps moyen de chargement t'1 associé au service requis), le contenu et le temps moyen étant associés au service requis et indiqués dans la liste 403. Ce contenu est affiché durant un temps t1 jusqu'à ce que le service soit chargé et disponible pour l'application (t1 étant égal à la durée séparant l'émission de la commande 410 du moment 412 où la première image du service requis est décodée). La commande 410 décrite ci-dessus est transmise en mode requête-réponse à la demande du décodeur 10. Elle est préférentiellement régulièrement rafraîchie à l'initiative du serveur 12 (mode push ). Ensuite, suite à une demande de changement de service par un utilisateur, le décodeur 10 transmet au serveur 13 une commande 413 IGMP de type leave pour quitter le service courant et une commande 420 IGMP demandant un nouveau service particulier (commande du type join avec adresse IP du nouveau service) et reçoit le flux vidéo 421. Ici, par exemple, on suppose un fondu d'image à partir de l'une des dernières images (et préférentiellement la dernière image) du service précédent au moment du lancement de l'une des commandes 413 ou 420 (émises pratiquement simultanément), la durée du fondu étant calculée en fonction du temps moyen (ou maximal) t'2 associé au chargement du service requis et tel que fourni dans la liste de service 403. Un fondu est, par exemple, lié à une commande explicite associée au service demandé dans la liste 403, à un temps t'2 inférieur au seuil 1011 ou à une absence de contenu à afficher lors du chargement du nouveau service dans la liste 403. L'une des dernières images du service précédent est donc affichée durant un temps t2 jusqu'à ce que le nouveau service soit chargé et disponible pour l'application (t2 étant égal à la durée séparant l'émission de l'une des commandes 413 ou 420, du moment 42 2 où la première image du service requis est décodée). Puis, le décodeur 10 transmet au serveur 13 une commande 423 IGMP de type leave pour quitter le service courant et une commande 430 IGMP demandant un nouveau service particulier (commande du type join avec adresse IP du nouveau service) et reçoit le flux vidéo 431. Lorsque le chargement du service requis est demandé par l'utilisateur, le décodeur 10 affiche le contenu (après un test éventuel du temps moyen de chargement t'3 associé au service requis), le contenu étant associé au service quitté et le temps moyen étant associé au service requis. En effet, selon l'invention, le contenu affiché peut dépendre du service quitté (par exemple, par paramétrage ou indication dans la liste des services 403). Ce contenu est affiché durant un temps t3 jusqu'à ce que le service soit chargé et disponible pour l'application (t3 étant égal à la durée séparant l'émission de l'une des commandes 423 ou 430, du moment 432 où la première image du service requis est décodée). La figure 5 représente chronologiquement, les données transmises par le serveur vidéo 15 et le serveur SI/PSI 14 au décodeur 10 via un réseau de diffusion monodirectionnel. Lors d'une première étape, le serveur 14 transmet au décodeur 10 la liste 501 des fournisseurs de services. Puis ou en parallèle le serveur vidéo 15 diffuse des multiplex vidéo 502 vers le décodeur 10. Ensuite, le serveur 14 transmet la ou les listes 503 des services disponibles, cette ou ces listes 503 étant sous la forme d'une ou de plusieurs tables SI/PSI et le décodeur 10 mémorise cette liste dans le registre 1022 avec les informations associées au temps de chargement et au contenu associés aux services de la ou des listes lorsqu'elles sont fournies. Puis, en fonction des souhaits de l'utilisateur, le décodeur 10 se cale (opération 511) sur la fréquence (via son tuner non représenté en figure 2) et le multiplex du service souhaité dans le flux vidéo transmis par le serveur 15. Le décodeur 10 affiche le contenu (après un test éventuel du temps moyen de chargement t'1 associé au service requis), le contenu et le temps moyen étant associés au service requis et indiqués dans la ou les listes 503. Ce contenu est affiché durant un temps t1 jusqu'à ce que le service soit chargé et disponible pour l'application (t1 étant égal à la durée séparant le début de calage 511 du moment 512 où la première image du service requis est décodée). Ensuite, suite à une demande de changement de service par un utilisateur, le décodeur 10 se cale (opération 521) sur la fréquence (si un changement de fréquence est nécessaire) et le multiplex du nouveau service souhaité dans le flux vidéo transmis par le serveur 15. Ici, par exemple, on suppose un fondu d'image à partir de l'une des dernières images (et préférentiellement la dernière image) du service précédent au moment du lancement du début du calage, la durée du fondu étant calculée en fonction du temps moyen (ou maximal) t'2 associé au chargement du service requis et tel que fourni dans la liste de service 503. Un fondu est, par exemple, lié à une commande explicite associée au service demandé dans la ou les listes 503, à un temps t'2 inférieur au seuil 1011 ou à une absence de contenu à afficher lors du chargement du nouveau service dans la liste 503. L'une des dernières images du service précédent est donc affichée durant un temps t2 jusqu'à ce que le nouveau service soit chargé et disponible pour l'application (t2 étant égal à la durée le début de calage 521, du moment 522 où la première image du service requis est décodée). Puis, suite à une demande de changement de service par un utilisateur, le décodeur 10 se cale (opération 531) sur la fréquence (si un changement de fréquence est nécessaire) et le multiplex du nouveau service souhaité dans le flux vidéo transmis par le serveur 15. Lorsque le chargement du service requis est demandé par l'utilisateur, le décodeur 10 affiche le contenu (après un test éventuel du temps moyen de chargement t'3 associé au service requis), le contenu étant associé au service quitté et le temps moyen étant associé au service requis. Ce contenu est affiché durant un temps t3 jusqu'à ce que le service soit chargé et disponible pour l'application (t3 étant égal à la durée séparant le début de calage 521, du moment 532 où la première image du service requis est décodée). La figure 6 illustre un algorithme correspondant à un procédé de réception mis en oeuvre dans le récepteur 10, selon l'invention. Au cours d'une première étape 60 d'initialisation, le décodeur 10 charge en mémoire vive 102 le programme 1010 et initialise les différents paramètres nécessaires à son bon fonctionnement. Puis, au cours d'une étape 61, le décodeur 10 reçoit du serveur SD&S 12 et/ou du serveur SI/SPI 14 une ou plusieurs listes de services qu'il mémorise dans son registre 1022. Ensuite, au cours d'une étape 62, il extrait et mémorise dans le registre 1023, les données temporelles associées à chaque service présent dans les listes reçues à l'étape 61 (typiquement les temps minimaux, moyens et/ou maximaux correspondant au chargement du service). Puis au cours d'une étape 63, lorsqu'elles sont présentes, le décodeur extrait les données à un contenu et/ou une action à effectuer, ces données étant associées à chaque service présent dans les listes reçues à l'étape 61, et les mémorise dans les registre 1024 et/ou 1025. Selon une variante de réalisation, ces données mémorisées aux étapes 62 et 63 sont présentées à l'utilisateur (ou à l'application cliente du décodeur) avec les services disponibles. Les étapes 61 et 63 sont effectuées lors de la mise en route du décodeur 10, et, également, lors de la réception d'une mise à jour d'une liste de services et/ou d'une nouvelle liste de services. Ensuite, au cours d'une étape 64, le décodeur attend puis reçoit une instruction d'un utilisateur ou de son application cliente demandant le chargement d'un premier ou d'un nouveau service appartenant à une liste reçue lors de l'étape 61. Puis, au cours d'un test 65, le décodeur 10 vérifie si le temps estimé de chargement du service est inférieur à une valeur seuil 1011 (qui vaut par exemple 0,5s) (temps moyen, minimal ou maximal lue dans le registre 1023 associé au service souhaité). Dans l'affirmative, on suppose que l'utilisateur n'a pas le temps de prendre en compte un contenu de type image ou texte pendant le chargement et, au cours d'une étape 67, un fondu (associé à l'une des dernières images décodées) dont la durée est calculée en fonction du temps estimé est lancé. Dans la négative, au cours d'une étape 66, le décodeur 10 effectue l'action associée au chargement du nouveau service (par exemple, affichage ou fourniture à un afficheur (moniteur ou téléviseur par exemple) d'une image fixe ou d'un film, affichage d'un texte, affichage d'une information RSS, fondu, ...). En cas d'absence d'action associée à ce nouveau service dans la liste 1022 reçue, le décodeur 10 effectue l'action associée au service précédent ou une action par défaut (par exemple affichage d'une image ou d'une série d'images enregistrées localement (par exemple curseur indiquant un chargement et dont la vitesse dépend du temps estimé) ou distante (par exemple publicité présente à une adresse web spécifique ou dans le flux diffusé, cette adresse ou le fichier recherché pouvant dépendre du temps estimé de chargement mentionné dans la liste 1022), d'un texte prédéfini ou dépendant du nouveau service (par exemple chargement du service avec nom du service et/ou temps estimé du chargement mentionné dans la liste 1022). Selon une variante de l'invention, les étapes 65 et 67 sont supprimées et l'étape 66 est effectuée systématiquement après l'étape 64. La figure 7 illustre un algorithme correspondant à un procédé d'émission de liste de services mis en oeuvre dans les serveurs de listes 12 et/ou 14, selon l'invention. Au cours d'une première étape 70 d'initialisation, le serveur charge en mémoire vive 122 le programme 1210 et initialise les différents paramètres nécessaires à son bon fonctionnement (notamment adresse des serveurs vidéo). Puis, au cours d'une étape 71, le serveur construit une ou plusieurs listes de services à transmettre aux décodeurs. La ou les listes de services et les serveurs vidéo sont paramétrés par l'opérateur et sont donc directement accessibles. Ensuite, le serveur de liste récupère, pourchaque service disponible, le GOP de l'encodeur correspondant (qui peut être distinct des serveurs vidéo 13 et 15 et qui est connu du serveur de liste). Il en déduit les temps minimaux, moyens et/ou maximaux de décodage. Puis, en fonction du mode de diffusion, il estime le temps de transport. Une valeur par défaut peut être prédéfinie (par exemple 500ms pour une transmission via internet et Oms pour une diffusion monodirectionnelle). Selon une variante plus complexe, le serveur de liste 12 estime la gigue pour la transmission de services issus du serveur 13 en utilisant par exemple le protocole RTCP ( de l'anglais Real Time Control Protocol ) comme voie de retour pour récupérer des informations sur l'état du réseau et notamment la gigue. Le serveur de liste fait la somme des temps minimaux, moyens et/ou maximaux et l'insère dans les informations associées à chaque service dans la ou les listes 1221 qu'il construit. Selon une variante, le serveur de liste ne fait pas cette somme et l'insère séparément les temps correspondant aux paramètres respectivement de décodage et de transport, dans les informations associées à chaque service dans la ou les listes 1221 qu'il construit, le décodeur en déduisant le temps total. Selon une autre variante, ces données ne sont pas exprimées en secondes, mais respectivement en nombre minimal, moyen et/ou maximal de GOP et/ou de nombre ou taille de mémoires tampon (ou buffers en anglais) entre le serveur vidéo et le décodeur 10 (la traversée d'une mémoire tampon pouvant être paramétrée dans le décodeur 10 (par exemple 100ms) ou estimée plus finement). L'action et les éventuelles données associée à un chargement de services peuvent être paramétrées ou récupérées par le serveur de liste à une adresse prédéfinie (locale ou distante) à une fréquence ou des instants également paramétrés (le contenu d'une nouvelle ou d'une publicité pouvant être modifié régulièrement). Ensuite, lors d'une étape 72, le serveur de liste diffuse ou transmet la ou les listes construites au cours de l'étape 71 vers le ou les décodeurs. Les étapes 71 et 72 sont mise en oeuvre à la mise en route du serveur et à chaque fois que nécessaire (notamment lorsqu'il y a des changement dans le contenu des listes (notamment de manière périodique et/ou changement de services disponibles, changement dans les actions à effectuer par un décodeur lors du chargement d'un nouveau service ou changement dans les paramètres d'encodage ou de transport d'au moins un service). Bien entendu, l'invention ne se limite pas aux modes de réalisation décrits précédemment. La nature et le nombre des serveurs de listes ne sont notamment pas limités aux exemples précédemment illustrés. En particulier, les listes de services peuvent être construites et/ou émises par un ou plusieurs serveurs de listes de type diffusion interactive ou, au contraire, monodirectionnelle, via tout moyen de communication filaire ou sans fil. Les actions associées à un service ne sont pas non plus limitées aux actions précédemment décrites mais concernent tout type d'action possible au cours d'un chargement de service. Les données temporelles estimées ne sont pas nécessairement les temps moyens estimés mais peuvent également, selon l'invention, être associées à des valeurs minimales, maximales ou correspondant à une valeur intermédiaire (par exemple valeur maximale valable avec une probabilité de 0,95). La liste de services transmise peut comprendre tout ou partie de ces valeurs. Le décodeur peut alors choisir la valeur qu'il va prendre en compte pour effectuer une action (par exemple par paramétrage). L'utilisateur d'un décodeur ou l'application associée peut aussi, selon l'invention, interdire certaines actions (par exemple affichage de publicité et/ou affichage d'image si le temps de chargement estimé est inférieur à un seuil) et effectuer alors une action par défaut ou une action correspondant à un service précédent. Il peut également configurer le décodeur pour que ce dernier télécharge ou enregistre un contenu spécifique lors du chargement d'un service (par exemple, nouvelle via un lien RSS). Selon un mode avantageux de l'invention, toutes les listes de services transmises ou les données de contrôles les comprenant comprennent un temps estimé de chargement et/ou une action à effectuer par le décodeur lors d'un chargement, pour chaque service. Selon des variantes de l'invention, ces données de temps estimé de chargement et/ou d'action à effectuer sont transmises pour seulement une partie des services présents. Selon une autre variante de l'invention, ces données sont associées à une liste et transmise une fois avec la liste correspondante, tous les services de la liste étant associés au(x) temps estimé(s) de chargement et/ou à l'action à effectuer lors du chargement. Le décodeur associe alors ces informations à l'ensemble des services concernés. Selon une mise en oeuvre particulière de cette variante, un booléen est associé à chaque service pour indiquer si les paramètres de chargement doivent lui être associés ou non. L'invention n'est pas limitée aux décodeurs (ou set top box en anglais) coté réception mais concernent tout récepteur adapté à recevoir et décoder des listes de services et des flux de services, et notamment les décodeurs, les téléviseurs, les dispositifs d'enregistrement, les terminaux de communication, les ordinateurs comprenant des moyens de réception et de décodage. Annexe. Un exemple de codage XML d'une liste de services est illustré ci-après dans le cadre d'une diffusion bidirectionnelle sur un réseau internet. Dans cette liste, les ajouts par rapport à une liste SD&S selon l'état de l'art sont indiqués en gras. A titre d'exemple, trois services sont décrits à l'aide d'un paramètre appelé AverageRenderingTime qui représente le temps moyen de chargement du service correspondant et un paramètre optionnel appelé TemporaryScreen qui soit indique l'emplacement d'un contenu à afficher lors du chargement du service correspondant, soit contient directement le contenu à afficher. Pour un premier service, la liste indique un temps moyen de chargement égal à 1200 ms, l'unité (ms) (selon l'instruction AverageRenderingTime Unit= ) et le temps (1200) (selon l'instruction Value = ) étant indiqués explicitement. Pour ce service, la liste indique également un emplacement à une adresse internet d'une image à télécharger lors du chargement du service (selon l'instruction TemporaryScreen Type qui indique un contenu de type lien (ou adresse) et un champ Value qui mentionne explicitement l'adresse internet http://www.provider1.com/zappingAd5002.jpg). Pour un second service, la liste indique un temps moyen de chargement égal à 800 ms (selon l'instruction AverageRenderingTime Unit="ms" Value="800"). Pour ce service, la liste n'indique pas de contenu explicite à utiliser lors de son chargement. Pour un troisième service, la liste indique un temps moyen de chargement égal à 1500 ms, l'unité (ms) (selon l'instruction AverageRenderingTime Unit="ms" Value="1500" ). Pour ce service, la liste indique également un contenu de type texte à afficher (selon l'instruction TemporaryScreen Type qui indique un contenu de type texte et un champ Value qui contient les caractères textuels du message à afficher sur l'écran). Le texte affiché peut être un texte de nouvelles en temps réel (en fonction du rafraîchissement des listes de services) ou différé, un texte de publicité, un message indiquant un changement de service ou toute autre information. Pour un quatrième service, la liste indique un temps moyen de chargement égal à 600 ms. Pour ce service, la liste indique également un lien de type RSS (de l'anglais Really Simple Syndication ou 16 syndication vraiment simple en français) (selon l'instruction TemporaryScreen Type = RSS qui indique un contenu de type lien RSS et un champ Value qui mentionne explicitement l'adresse internet http://www.provider3.com/RSSnews.xml). Pour un cinquième service, la liste indique un temps moyen de chargement égal à 600 ms. Pour ce service, la liste indique également une action de type fondu (selon l'instruction TemporaryScreen Type = fade . 4 4 4 3 3 Dans un mode diffusé monodirectionnel, les listes de services sont transmises sous forme SI/PSI dans lesquelles on insère des champs équivalents à ceux indiqués cidessus en prévoyant, par exemple, une structure du type : - indicateur de présence d'un descripteur lié au chargement du service (booléen à 1 si le descripteur est présent) ; - descripteur comprenant : - une unité sur 4 bits (par exemple 0000 pour ms) ; - une valeur sur 16 bits ; - un type d'écran temporaire sur 8 bits (par exemple 0x00 (en notation hexadécimale) à 0x03 signifiant respectivement lien, texte, image, RSS, ...) ; - une taille de contenu du champ associé à l'écran temporaire sur 20 bits ; - le contenu du champ associé à l'écran temporaire (par exemple http://www.providerl.com/zappingAd5002.jpg qui est codé sur 42 octets). 20 25 REVENDICATIONS 1. Procédé de réception de services de télévision numérique, caractérisé en ce qu'il comprend une étape de réception (61) d'au moins une information représentative du délai d'affichage (1023) d'un nouveau service, ladite information étant insérée dans des données de contrôle qui comprennent au moins une liste de services (1022). 2. Procédé selon la revendication 1, caractérisé en ce que ladite au moins une information représentative du délai d'affichage d'un nouveau service comprend une information représentative de la durée du délai de décodage et/ou de transport du nouveau service. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'il comprend une étape de réception d'au moins une information représentative d'une action (1026) à effectuer lors du chargement d'un nouveau service, ladite information étant insérée dans des données de contrôle qui comprennent au moins une liste de services. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comprend une étape de fourniture d'au moins un contenu (1024, 1025) à afficher pendant un changement de service. 5. Procédé selon la revendication 4, caractérisé en ce qu'il comprend une étape du choix dudit contenu en fonction de ladite au moins une information représentative du délai d'affichage d'un nouveau service. 6. Procédé selon l'une quelconque des revendications 4 et 5, caractérisé en ce qu'il comprend une étape de réception d'au moins une information représentative dudit contenu (1025) et/ou de son emplacement (1024). 7. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce qu'il comprend la réalisation d'un fondu (67) pendant le changement de service, la durée du fondu dépendant de ladite au moins une information représentative du délai d'affichage d'un nouveau service. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que ladite au moins une information représentative du délai d'affichage d'un nouveau service est dans une structure XML et/ou dans une table de signalisation du flux. 9. Procédé d'émission de services de télévision numérique, caractérisé en ce qu'il comprend une étape d'émission (72) d'au moins une information représentative du délai d'affichage (1222) d'un nouveau service, ladite information étant présente dans des données de contrôle comprenant au moins une liste de services. 10. Procédé selon la revendication 9, caractérisé en ce qu'il comprend une étape de détermination de ladite au moins une information en fonction des paramètres d'encodage vidéo associés audit nouveau service. 11. Procédé selon l'une des revendications 9, caractérisé en ce qu'il comprend une étape de détermination de ladite au moins une information en fonction des paramètres du transport du flux vidéo associé audit nouveau service. 20 12. Procédé d'émission de services de télévision numérique, caractérisé en ce qu'il comprend une étape d'émission d'au moins une information représentative d'une action à effectuer par un décodeur lors d'un chargement de service, ladite information étant présente dans des données 25 de contrôle comprenant au moins une liste de services.15