FR2771884A1 - Procede de gestion d'informations de service dans un systeme de television numerique et recepteur mettant en oeuvre ce procede - Google Patents
Procede de gestion d'informations de service dans un systeme de television numerique et recepteur mettant en oeuvre ce procede Download PDFInfo
- Publication number
- FR2771884A1 FR2771884A1 FR9715163A FR9715163A FR2771884A1 FR 2771884 A1 FR2771884 A1 FR 2771884A1 FR 9715163 A FR9715163 A FR 9715163A FR 9715163 A FR9715163 A FR 9715163A FR 2771884 A1 FR2771884 A1 FR 2771884A1
- Authority
- FR
- France
- Prior art keywords
- information
- updated
- database
- request
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
- H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/41—Structure of client; Structure of client peripherals
- H04N21/426—Internal components of the client ; Characteristics thereof
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
- H04N21/4332—Content storage operation, e.g. storage operation in response to a pause request, caching operations by placing content in organized collections, e.g. local EPG data repository
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
- H04N21/4335—Housekeeping operations, e.g. prioritizing content for deletion because of storage space restrictions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/47—End-user applications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N5/00—Details of television systems
- H04N5/76—Television signal recording
- H04N5/765—Interface circuits between an apparatus for recording and another apparatus
- H04N5/775—Interface circuits between an apparatus for recording and another apparatus between a recording apparatus and a television receiver
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/08—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division
- H04N7/087—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division with signal insertion during the vertical blanking interval only
- H04N7/088—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division with signal insertion during the vertical blanking interval only the inserted signal being digital
- H04N7/0887—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division with signal insertion during the vertical blanking interval only the inserted signal being digital for the transmission of programme or channel identifying signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Television Systems (AREA)
Abstract
L'invention concerne un procédé de gestion d'informations de service dans un système de télévision numérique.Le procédé comporte au niveau d'un récepteur du système les étapes suivantes- programmation de moyens d'extraction sélective d'informations d'un flux de données numérique : - mémorisation d'au moins une partie des informations extraites; - marquage d'une information mémorisée comme étant mise à jour ou non-mise à jour en fonction de la programmation, relative à cette information, desdits moyens d'extraction sélective. L'invention concerne également un dispositif de mise en oeuvre de ce procédé.
Description
L'invention concerne un procédé de gestion d'informations de service dans
un système de télévision numérique, notamment d'informations relatives à des guides de programmes. L'invention s'applique entre autres aux décodeurs
de télévision numérique.
Les guides de programmes électroniques ('Electronic Program Guides' ou 'EPG') sont des applications logicielles utilisées dans le cadre de systèmes de télévision numérique. Ces applications fournissent au téléspectateur une interface permettant de consulter des informations
concernant typiquement les programmes diffusés.
Les informations sont transmises par multiplexage de paquets de données appropriés dans le flux de données numérique. Une appellation souvent utilisée pour ce type de données est "Information de Service" ('Service Information'
en anglais ou plus simplement 'SI').
Les informations de service sont diffusées de façon périodique, la période étant choisie notamment en fonction de la bande passante disponible et de la fréquence des demandes des informations par l'utilisateur. En effe, lorsque l'utilisateur désire visionner rapidement les informations relatives à un grand nombre de programmes, il est souhaitable que le temps d'attente entre la demande d'information de l'utilisateur et la réponse à cette demande soit le plus court possible. Un moyen consiste à munir chaque récepteur ou décodeur d'une grande quantité de mémoire pour stocker le plus d'informations possible dans le but de pouvoir répondre immédiatement aux demandes de l'utilisateur. Il s'avère que la quantité totale d'information diffusée est telle que cette solution n'est pas viable dans un produit de masse destiné au grand
public, du moins au prix actuel des mémoires semi-
conducteurs. D'autre part, le fait que l'information évolue constamment obligerait le récepteur ou décodeur à consacrer une partie importante de ses ressources à la mise à jour des informations, que celles-ci soient utilisées postérieurement ou non. Notamment, le nombre de filtres de démultiplexage de paquets de données pouvant être programmés et mis en oeuvre simultanément est limité. Les deux demandes de brevet françaises 96 10067 et 96 10068 déposées le 9 août 1996 au nom de la demanderesse concernent un module de gestion de l'information de service dans un récepteur, notamment un décodeur de télévision numérique. La demande 96 10067 concerne un récepteur de télévision et un procédé de gestion de mise à jour de certains types de données mémorisées dans une base de données dynamique interne du récepteur, tandis que la demande 96 10068 concerne un procédé d'indexation, dans la base de données interne, des données reçues et extraites à
partir du flux numérique.
Ces deux demandes décrivent également les requêtes qu'une application telle qu'un guide de programmes peut émettre pour requérir telle ou telle information au module de gestion des données SI, module qui programme le démultiplexeur: requête permanente ou unique, anticipée ou non-anticipée. Selon ces deux demandes, des données correspondant à des requêtes permanentes sont stockées dans la base de données interne jusqu'à déprogrammation de la requête permanente, tandis que des données extraites suite à une requête unique ne sont pas gardées en mémoire au-delà du
traitement immédiat.
Dans le cas o l'utilisateur revient sur ses pas dans le guide de programmes, il se peut que des données récemment effacées doivent être extraites une nouvelle fois. L'invention propose d'augmenter la réactivité du
système dans un tel cas.
L'invention a pour objet un procédé de gestion d'informations de service dans un système de télévision numérique caractérisé en ce qu'il comporte au niveau d'un récepteur du système les étapes suivantes: - programmation de moyens (5) d'extraction sélective d'informations d'un flux de données numérique; - mémorisation d'au moins une partie des informations extraites; - marquage d'une information mémorisée comme étant mise à jour ou non-mise à jour en fonction de la programmation, relative à cette information, desdits moyens
d'extraction sélective.
Lorsque les moyens d'extraction sélecI- ve d'information du flux sont déprogrammés, les informations stockées au préalable dans la base de données interne du récepteur sont maintenues dans la base, mais marquées comme
non-mises à jour.
Ainsi, d'une part, si l'utilisateur revient sur ses pas, il est possible de lui fournir ces informations non mises à jour de manière très rapide, sans devoir attendre une nouvelle extraction. Bien que la mémoire du récepteur soit ainsi plus sollicitée, en cas de saturation de la mémoire, il est possible d'éliminer facilement les données
qui ne sont pas à jour.
Selon un mode de réalisation particulier de l'invention, suite à la formulation d'une requa-te d'information par une application, es eanes de programmation et de mémorisation sont raises _e 1.; suivante: - en cas de présence de l'information dans la base de données, de transfert de l'information vers une application, de programmation des moyens d'extraction sélective de l'information du flux de données et de mise à jour de l'information dans la base de données, le cas échéant, suite à l'extraction de l'information du flux de données; - en cas d'absence de l'information dans la base de données, de programmation des moyens d'extraction sélective et, le cas échéant, de stockage de l'information dans la base de données du décodeur suite à son extraction du flux
de données.
Ainsi, l'information, lorsqu'elle est présente dans la base, est transmise sans attente à l'application qui en fait la requête. C'est notamment le cas si elle a été stockée suite à une requête récente d'une application, par exemple dans le cas o un utilisateur revient sur ses pas dans un guide de programmes. Il y a de grandes chances que l'information ainsi mémorisée soit encore d'actualité, ou
du moins qu'elle suffise à renseigner l'utilisateur.
Les ressources de recherche d'une information dans le flux de données et de stockage de cette information ne sont utilisées que pour rechercher ou mettre à jour une information requise par une application, et non pour le stockage et la mise à jour d'informations sans aucune discrimination. Selon un mode de réalisation particulier, les
moyens de recherche comportent un démultiplexeur.
Selon un mode de réalisation particulier, le marquage d'une information mémorisée comme étant mise à jour est effectif pendant toute la période pendant laquelle les moyens de recherche sont programmés pour en extraire
une nouvelle valeur.
Selon un mode de réalisation particulier, le marquage d'une information mémorisée comme étant non-mise à jour suite à son extraction du flux est réalisé en conjonction avec une déprogrammation des moyens de recherche de cette information.35 Selon un mode de réalisation particulier, le marquage d'une information comme non-mise à jour comporte l'association de cette information avec la date à laquelle les moyens d'extraction sélective correspondant à
l'information ont été déprogrammés.
Cette caractéristique permet de déterminer le temps
écoulé depuis la dernière mise à jour de l'information.
Cela permet de juger de son obsolescence, notamment si l'on
connaît la périodicité de sa transmission.
Selon un mode de réalisation particulier, en cas de saturation de la base de données du récepteur, des informations marquées comme non-mises à jour sont effacées
par ordre d'ancienneté des dates.
Selon une variante de réalisation, le marquage d'une information est communiqué, avec cette information, à
une application ayant requis l'information.
Ainsi, l'application peut décider de l'utilisation
faite de cette information en fonction de l'état du marquage.
Selon une variante de réalisation, en cas de saturation de la base de données du récepteur, des informations marquées comme non-mises à jour sont effacées
par ordre d'ancienneté des dates.
Selon une variante de réalisation, une information non-mise à jour affichée sur un écran par une application
est visuellement identifiée comme étant non-mise à jour.
L'utilisateur est ainsi averti de l'état de l'information et du risque que celle-ci est peut-être obsolète. L'invention a également pour objet un récepteur dans un système de télévision numérique dans lequel sont transmis des informations de service et notamment de guide de programmes, ledit récepteur comprenant: un démultiplexeur d'un flux de données, ledit démultiplexeur comportant des filtres programmables pour une extraction sélective d'informations dudit flux, ledit récepteur étant caractérisé en ce qu'ii comporte: - une mémoire destinée à contenir une base de données dudit récepteur, ladite base de données comprenant des informations extraites précédemment; - des moyens de marquage des informations de la base de données comme mises à jour ou non-mises à jour. Selon une variante de réalisation, le marquage comme mis à jour ou comme non-mis à jour est effectué en
fonction de la programmation dudit multiplexeur.
Selon une variante de réalisation, le dispositif comporte en outre une horloge utilisée pour le marquage des
informations non-mises à jour.
D'autres caractéristiques et avantages de
l'invention apparaîtront à travers la description d'un mode
de réalisation non limitatif. Ce mode de réalisation est illustré par les figures jointes, parmi lesquelles: - la figure 1 est un diagramme bloc d'un récepteur de télévision conforme au 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 le démultiplexeur du dispositif de la figure 1, - 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, - la figure 5 est un diagramme de la base de données maintenue par le module de gestion à un moment donné. 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 numérique 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, par exemple une transmission par l'intermédiaire
de données modulées dans l'intervalle de retour trame.
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émultpiexeur similaire à celui décri: dans la demande de brevet -a:;ais 15767 déposée le 29 décembre 1995 au nom de THOCMSON multimedia. Le démultiplexeur 5 comporte un certain nombre de registres de filtrage, appelés filtres par extension, programmés par un microprocesseur 23 en fonction des diverses applications supportées par le décodeur. Le démultiplexeur compare le contenu des registres de filtrage à certains paramètres des paquets de données et charge les paquets de données correspondant à une comparaison positive. 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 des 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 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 17 ou du décodeur télétexte 18 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.
Selon le présent exemple de réalisation, le module de gestion des données de service 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, 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 requêtes 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 du démultiplexeur. Le transfert des données vers l'application est fait à travers une mémoire tampon dans laquelle le module de gestion écrit les données. La zone de la mémoire tampon à utiliser est identifiée dans la requête de l'application. L'application, une fois notifiée, y lira les données en temps utile. Ce
cas sera vu plus en détail plus loin.
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 au démultiplexeur. 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, le démultiplexeur notifie le module de gestion 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. Comme dans le cas précédent, 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.
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 du démultiplexeur 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- apres. 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 vers l'application. Les ressources sont en principe
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, l'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 d'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é.
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, les données appropriées de cette table sont comparées aux données dans la base de données. Un changement de version est indiqué par un changement de valeur d'un paramètre appelé "versionid" ou "version_number" transmis avec chaque table. Une notification de mise à jour n'est à priori transmise que si
au moins une de ces données a été modifiée.
L'identificateur de version de la table "version id" 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.
On distingue d'autre part des requêtes applicatives et requêtes élémentaires. Les requêtes applicatives sont, comme leur nom l'indique, des requêtes émises par les applications clientes. Une requête applicative est traduite par le module de gestion SI en autant de requêtes élémentaires que nécessaire. Une requête élémentaire est dans le contexte présent une requête pouvant être traduite en un seul filtre au niveau du démultiplexeur. Les requêtes élémentaires sont déterminées de façon à ce que les données
qu'elles concernent ne se recoupent pas.
Deux tables de requêtes sont maintenues par le module SI: une table de requêtes applicatives et une table
de requêtes élémentaires.
Identifian Typ Fonctio Atten SingNB SLi Paramè t Requête e n te st tres Table des requêtes applicatives Identif Fonctio Eta Type Date Nombre de Paramntr iant n t requêtes es Requête applic ativ es Table des requêtes élémentaires La table des requêtes applicatives comporte pour chaque requête les éléments suivants: - un identifiant de la requête, - le type de la requête (unique anticipée, unique non- anticipée...), - la fonction de la requête, - 'Attente': Nombre de requêtes élémentaires correspondantes en attente, c'est à dire n'ayant pas encore donné lieu à une réponse (une première notification à l'application ayant émis la requête est lancée lorsque ce chiffre est égal à zéro), - 'SingNB': nombre de requêtes élémentaires n'ayant pas donné lieu à un transfert de données vers la mémoire tampon, - 'SList': Liste des identifiants de requêtes élémentaires associées à cette requête applicative, - des paramètres liés à la requête applicative (par exemple identification d'un service pour lequel on
recherche une liste d'événements).
La table des requêtes élémentaires comporte pour chaque requête élémentaire les éléments suivants: - un identifiant de la requête, - le type de la requête, - la fonction de la requête, - l'état de la requête, le nombre de requêtes applicatives liées à la requête élémentaire, - la date d'inactivation de la requête (le cas échéant)
- des paramètres liés à la requête élémentaire.
Lorsque le module de gestion SI traduit une requête applicative en requête(s) élémentaire(s), il vérifie si oui ou non la table des requêtes élémentaires contient déjà ces requêtes. Une nouvelle requête élémentaire n'est insérée dans la table correspondante que s'il n'existe pas déjà une requête identique. Ceci permet d'éviter l'utilisation des
ressources du démultiplexeur à des fins redondantes.
Deux requêtes élémentaires sont considérées comme identiques si elles ont la même fonction et les mêmes paramètres. Si une requête élémentaire est déjà présente dans la table correspondante, alors le module SI vérifie le type de la requête élémentaire déjà existante. Si ce type a une moindre priorité que le type de la requête élémentaire nouvelle (il s'agit du type de la requête applicative ayant donné naissance à cette requête élémentaire nouvelle), alors le type de la requête élémentaire existante est modifié pour prendre la nouvelle valeur. La classification des types de requête de la priorité la plus basse à la plus élevée est: unique anticipée, permanent anticipée, unique
non anticipée, permanente non anticipée.
Les éléments suivants de la table des requêtes applicatives sont mis à jour suite à la programmation ou la modification de requêtes élémentaires correspondantes: Attente, SList. Le lien avec le contenu de la table des
requêtes élémentaires est ainsi établi.
La table des requêtes élémentaires a aussi un autre rôle: elle donne la possibilité de déterminer si oui ou non une donnée est présente dans la base et si cette donnée est
à jour ou pas.
Le champ 'Etat' d'une requête de cette table peut prendre l'une des valeurs suivantes: - 'En attente': la requête est active, mais les données n'ont pas encore été reçues; - 'Prêt': la requête est active et les données ont été stockées dans la base de données et sont mises à jour; 'Non-mis à jour': la requête n'est plus active et les données sont stockées dans la base de données, mais
ne sont plus mises à jour.
La table des requêtes élémentaires comptabilise également pour chaque requête élémentaire le nombre de requêtes applicatives actives concernées. Ce nombre est incrémenté ou décrémenté au gré de la décomposition de nouvelles requêtes applicatives ou la déprogrammation d'anciennes requêtes. Lorsque ce nombre tombe à zéro pour
une requête élémentaire, l'état de celle-ci devient 'non-
mis à jour' (si son état était auparavant 'Prêt'): en d'autres termes elle est inactive. Les données précédemment extraites, si données il y a, restent stockées dans la base. Une requête élémentaire pour laquelle le nombre de requêtes applicatives tombe à zéro et qui n'a pas, pour une raison ou pour une autre, stocké des informations dans la base, est éliminée de la table. Le filtre correspondant du démultiplexeur est libéré. Les raisons pour cela peuvent être diverses: déprogrammation trop rapide avant que des données n'aient pu être obtenues, données demandées non diffusées,... Une requête élémentaire inactive peut être réactivée par une requête applicative appropriée, ou être éliminée de la table de requêtes élémentaires lorsqu'il sera nécessaire de libérer de la place dans la mémoire occupée dans la base de données et que les données qui lui
correspondent seront effacées.
La date d'inactivation d'une requête est mémorisée dans la table des requêtes élémentaires. Dans le cas présent, cette date est constituée par la valeur de l'horloge système ("System Clock" en anglais), cette
horloge étant synchronisée avec celle de l'encodeur.
Cependant, la mise en oeuvre d'un autre type d'horloge peut
également être envisagée.
Lorsque les données correspondant à une requête élémentaire (de type unique ou permanent) sont démultiplexées, elles sont transférées vers la mémoire tampon. Ce transfert a lieu autant de fois qu'il y a de liens avec des requêtes applicatives. Le nombre de requêtes élémentaires 'SingNB' dans chacune des requêtes applicatives concernées est décrémenté. La notification de la disponibilité des données par le module de gestion SI à une application n'est effectué que lorsque ce nombre atteint 0 pour cetteapplication, c'est à dire lorsque toutes les requêtes élémentaires liées à la requête applicative émise par l'application auront donné un
résultat et l'auront transféré dans la mémoire tampon.
Par contre, en cas de changement subséquent de données dans la base pour une requête élémentaire, ce changement est notifié immédiatement aux applications concernées. La figure 5, décrite plus loin, donne un exemple
des deux tables dans un cas déterminé.
Lorsqu'une requête élémentaire est estampillée comme étant 'non-mise à jour', cela ne veut pas dire que les données dans la base ne sont effectivement plus à jour, mais simplement qu'il y a une probabilité qu'elles ne le soient plus, étant donné que la requête qui est à leur origine n'a pas été maintenue pendant une période de temps déterminable à partir de la date d'inactivation mentionnée
plus haut.
Lorsque le module de gestion transfère des données dans la mémoire tampon en vue du transfert vers l'application, le contenu du ou des champs 'Date' et du ou des champs 'Etat' y est également stocké. Ces valeurs seront lues par l'application, qui décidera de l'utilisation de cette information. Lorsque l'état est
'Prêt', les données sont à jour. Lorsque l'état est 'Non-
mis à jour', elles ne le sont pas et le champ 'Date' indique leur ancienneté. Si l'application est un guide de programmes, les données affichées estampillées comme n'étant pas mises à jour sont affichées de manière à les identifier comme telles: par exemple affichage en grisé ou dans une couleur distincte d'une information qui serait
mise à jour.
Lorsque l'état d'une requête élémentaire est Prêt', les données sont à jour. Pour indiquer cela à l'application, lors du transfert des données, la valeur du
champ 'Date' transférée est nulle.
Bien que selon le présent mode de réalisation, seules les requêtes élémentaires permanentes (anticipées ou non) donnent lieu à une mémorisation des données extraites dans la base de données, on prévoit selon une variante de réalisation de mémoriser également les données correspondant à des requêtes uniques. Il faudra bien sûr dans ce cas maintenir également les requêtes élémentaires
de type unique dans la table correspondante.
Que des données non mises à jour aient été lues dans la base de données interne ou non suite à une requête, les filtres du démultiplexeur sont programmés (s'ils ne le sont pas déjà) en vue d'extraire du flux les valeurs les plus récentes. Ces valeurs, une fois extraites du flux, sont écrites dans la base de données, écrasant le cas échéant les données plus anciennes. Les changements d'état des requêtes élémentaires sont faits en conséquence: une requête déjà existante dans la table peut passer de l'état Attente' à l'état 'Prêt', mais aussi de l'état 'Non-mis à jour' à l'état 'Prêt' et vice-versa. S'il n'y a pas de requêtes élémentaires correspondantes aux données à
extraire, elles sont bien sûr créées.
Selon le présent exemple de réalisation, la gestion des paramètres 'versionid' est effectuée au niveau du démultiplexeur. Deux types de filtres sont utilisés: un premier type o le numéro de version de l'information à récupérer est masqué (la première version détectée est démultiplexée, quelque soit son numéro de version) et un second type o le numéro de version a une valeur particulière déterminée (seule l'information ayant ce
numéro de version sera démultiplexée).
Quand une requête élémentaire est générée et qu'aucun filtre correspondant n'existe déjà, c'est le premier type de filtre qui est mis en oeuvre. Une fois l'information correspondante détectée et extraite, si la requête élémentaire est de type permanent, la valeur du numéro de version extrait est incrémentée et ajoutée au
filtre existant: un filtre du second type mentionnée ci-
dessus est ainsi créé. On est ainsi certain de détecter la
prochaine version de l'information.
Il est bien sûr envisageable de stocker les valeurs
des numéros de version dans la base de données.
Le nettoyage de la base de données en vue de libérer de la mémoire est effectué en se servant de la date indiquée dans le champ 'Date' de la table des requêtes élémentaires. Sont éliminées par ordre d'ancienneté les requêtes élémentaires à l'état "Non-mis à jour" ainsi que les données rattachées à ces requêtes. Ce nettoyage est réalisé lorsque la base de données est p eine. i es% réalisé à l'initiative et sous le contrôle du module de gestion du SI tant qu'il ne concerne que des requêtes élémentaires à l'état "Non-mis à jour". Lorsque la base de données est pleine alors qu'il n'existe plus de requêtes à l'état 'non- mis à jour', ce fait est notifié aux applications. Un nettoyage supplémentaire peut alors être
réalisé sous le contrôle des applications.
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 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 es 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) e: d'identificateurs de tables (tableid), 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: - networkid (identifiant du réseau), couple (transport_streamid; original_network_id), - service id (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 à OxO010 sont filtrés. Ces paquets contiennent en effet les tables NIT, identifiées de plus par une variable tableid. 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 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 données AdresseListeRéseaux ListeRéseaux L:.;iZ O AdresseRéseau
......................................................................... DTD: .......................................................DTD: 1 AdresseRéseau 2 AdresseRéseau 3 AdresseRéseau 4 AdresseRéseau AdresseRéseau 6 AdresseRéseau 7 AdresseRéseau _ AdresseProchainTableauRéseaux | enifcaeRRéseau lIdentificateurRéseau ("networkid") INomRéseau ("network namne") AdresseListeCanaux ListeCanaux
A dresseCanal.............................................
i AdresseCanal 2 AdresseCanal 3 AdresseCanal 4 AdresseCanal AdresseCanal 6 AdresseCanal 7 AdresseCanal AdresseProchainTableauCanaux Canal Identificateurcanal ("TransportStream id")
Idniiae.. c n l C rnP.tS ra t)......................................
IdentificateurRéseauOrigine ("OriginalNetworkId") AdresseListeServices ListeServices 0 AdresseService
i A dresseService.......................................................
........................................DTD: I2 AdresseService 23 AdresseService 34 AdresseService AdresseService AdresseService 6 AdresseService 7 Adresse Serice AdresseProchainTableauServices Service
IdentificateurService ("serviceid)......
NomService ("service namne")
Etat ("runningstatus")............................
AdresseEvénementCourantSuivant
......................................................................... DTD: ...........................................DTD: Evénement CourantSuivant IdentificateurEvénementCourant ("Event id") DébutEvénementCouran....t (.start.t,.me........rne",).""","," DuréeEvénementCourant ("duration") EtatEvénementCourant ("runningstatus")
LongueurTitreEvénementCourant ("event naine enth).
I-...ngu.....e'....i..t. eE.e t.9.......t.(....t...,m.... e!. en........ )... -... i....i.
TitreEvénementCourant
LongueurDescriptionEvénementCourant ("text length")
DescriptionEvénementCourant
IdentificateurEvénementSuivant ("Event id") DébutEvénementSuivant ("start time">
DébutEvénem ent uiva.,nt.yt.a......m....t.....y............ e,.,.?......
.......................................DTD: DuréeEvénementSuivant ("duration") EtatEvénementSuivant ("runningstatus") ongueurTitreEvénementSuivant.(event nainel1ength
oitreEvénemesntSuivant ' f...................
LongueurDescriptionEvénementSuivant ("text length")
DescriptionEvénementSuivant
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é 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 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 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. 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 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.
Elles font partie des paramètres stockés dans les tables de
requêtes.
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 déjà mentionnée 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.
Dans le cas présent, étant donné que deux canaux existent dans le réseau, deux requêtes élémentaires sont nécessaires pour traduire la requête applicative: une requête élémentaire par liste de services ou encore par
canal est inscrite dans la table des requêtes élémentaires.
Sur la figure, les filtres correspondant à chaque requête élémentaire se trouvent à gauche de la table des
requêtes élémentaires.
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 main:enus après la
première obtention des données attendues.
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 Courant/Suivant' ("Event Information Table" en anglais) correspondante. On supposera pour la suite de l'exposé qu'une telle table est bien diffusée pour chaque service, c'est à dire que les drapeaux EIT presentfollowingflag de la table de descriDpion de
service ont la valeur 1 pour ces services.
La requête émise par l'application comporte, pour un service donné, les paramètres suivants: - un identifiant de requête, - le type de la requête, - la clé logique du service concerné, - une adresse mémoire d'une mémoire tampon destinée à recevoir des données démultiplexées de la part du module SI. On supposera dans un premier temps qu'il n'existe dans la base aucune donnée relative aux événements en cours ou suivants, c'est à dire que la table des requêtes élémentaires ne comporte pas de requête éiémeneaire
relative à ces données.
* L'application guide de programmes recherche par exemple les événements courant et suivant du second service ("1") appartenant au premier canal ("0") du premier réseau ("0"). Cette requête fait suite à un ordre de l'utilisateur d'afficher des informations sur le programme en cours et le programme immédiatement consécutif au programme en cours
d'un service donné, par exemple Canal+.
La clé logique du service concerné est alors:
0000 00000 000001
Une requête applicative correspondante est transmise au module SI. Cette requête sera de type permanent. Etant donné que dans le cadre de cet exemple, seuls les événements courant et suivant d'un seul service sont demandés par l'application, cette requête est élémentaire et ne doit pas être davantage décomposée par le module SI. La requête élémentaire est inscrite dans la
table des requêtes correspondante.
Le module SI programme d'autre part un filtre du démultiplexeur pour que le filtrage de la table EIT concernant cette requête soit correctement effectué. La valeur du PID des paquets comportant les tables EIT Courant/Suivant' est 0x0012, selon le document (a). Les valeurs des identificateurs de service ("serviceid"), de canal ("transport_streamid" et "original_networkid") nécessaires pour déterminer quelle est la bonne table EIT parmi celles diffusées sont disponibles dans la base de données grâce à la clé logique. L'état de la requête élémentaire dans la table des requêtes élémentaires est d'autre part mis à l'état 'Attente' Une fois la table EIT correcte détectée, le module SI extrait des paquets les valeurs des données à mémoriser dans sa base de données interne. Selon le présent exemple de réalisation, ces données sont celles figurant dans la
structure de données "Evénement CourantSuivant" décrite ci-
dessus. Le module SI notifie à l'application requérante -a présence des données et les copie dans la memoire tampon réservée au préalable par l'application. Dans la base de données, le pointeur adresse "AdresseEvénementCourantSuivant" de la structure de données Service correspondant au chemin indiqué par la clé logique est programmé avec l'adresse mémoire correspondant à la structure "AdresseEvénementCourantSuivant". L'état de la requête élémentaire dans la table des requêtes élémentaires passe de 'Attente' à 'Prêt'. Il est à remarquer qu'il existe au plus un seul événement courant et un événement suivant par service. Il n'y a donc pas lieu d'indexer, dans ce cas particulier, la structure de données "Evénement CourantSuivant", puisqu'elle est déjà parfaitement identifiée par la clé
logique menant au service dont elle dépend.
Le cas serait différent si l'on chargeait le contenu des tables EIT contenant des séries chronologiques d'événements. Dans ce cas, une indexation pourrait s'avérer nécessaire. A un moment ou un autre, l'application annulera sa requête, par exemple suite à un ordre de l'utilisateur de refermer le guide de programmes. Etant donné que dans ce cas, il n'y a plus de requêtes applicatives en cours faisant référence à la requête élémentaire concernant l'événement courant/suivant, le module SI libère les filtres du démultiplexeur et inscrit la valeur actuelle de l'horloge système dans le champ 'Date' de la table des requêtes primitives. L'état de la requête devient 'Non-mis à jour', en supposant que des données aient effectivement été démultiplexées et stockées dans la base auparavant, ce qui est le cas ici. Dans le cas contraire, elles auraient
simplement été effacées de la table.
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.
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 ou préenregistrés. D'autre part, si les exemples donnés concernent plus particulièrement les données de service, il est clair que l'invention ne se limite pas à ce type de données. Des données dites privées peuvent, par exemple, être traitées
de manière analogue.
Claims (12)
1. Procédé de gestion d'informations de service dans un système de télévision numérique caractérisé en ce qu'il comporte au niveau d'un récepteur du système Les étapes suivantes: - programmation de moyens (5) d'extraction sélective d'informations d'un flux de données numérique; mémorisation d'au moins une partie des informations extraites; - marquage d'une information mémorisée comme étant mise à jour ou non-mise à jour en fonction de la programmation, relative à cette information, desdits moyens
d'extraction sélective.
2. Procédé selon la revendication 1, caractérisé en ce que suite à la formulation d'une requête d'information par une application, les étapes de programmation et de mémorisation sont réalisées de la façon suivante: - en cas de présence de l'information dans la base de données, de transfert de l'information vers xe application, de programmation des moyens d'extracon sélective de l'information du flux de données et de mise à jour de l'information dans la base de données, le cas échéant, suite à l'extraction de l'information du flux de données; - en cas d'absence de l'information dans la base de données, de programmation des moyens d'extraction sélective et, le cas échéant, de stockage de l'information dans la base de données du décodeur suite à son extraction du flux
de données.
3. Procédé selon l'une des revendications 1 ou 2,
caractérisé en ce que les moyens d'extraction sélective
comportent un démultiplexeur.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que le marquage d'une information
mémorisée comme étant mise à jour est effectif pendant toute la période pendant laquelle les moyens de recherche5 sont programmés pour en extraire une nouvelle valeur.
5. Procédé selon l'une des revendications 1 à 4,
caractérisé en ce que le marquage d'une information mémorisée comme étant non-mise à jour suite à son extraction du flux est réalisé en conjonction avec une déprogrammation des moyens de recherche de cette information.
6. Procédé selon la revendication 5, caractérisé en ce que le marquage d'une information comme non-mise à jour comporte l'association de cette information avec la date à laquelle les moyens d'extraction sélective correspondant à
l'information ont été déprogrammés.
7. Procédé selon la revendication 6, caractérisé en ce qu'en cas de saturation de la base de données du récepteur, des informations marquées comme non-mises à jour
sont effacées par ordre d'ancienneté des dates.
8. Procédé selon l'une des revendications
précédentes, caractérisé en ce que le marquage d'une information est communiqué, avec cette information, à une
application ayant requis l'information.
9. Procédé selon l'une des revendications
précédentes, caractérisé en ce qu'une information non-mise à jour affichée sur un écran par une application est
visuellement identifiée comme étant non-mise à jour.
10. Récepteur dans un système de télévision numérique dans lequel sont transmis des informations de service et notamment de guide de programmes, ledit récepteur comprenant: un démultiplexeur (5) d'un flux de données, ledit démultiplexeur comportant des filtres programmables pour une extraction sélective d'informations dudit flux, ledit récepteur étant caractérisé en ce qu'il comporte: - une mémoire (12) destinée à contenir une base de données dudit récepteur, ladite base de données comprenant des informations extraites précédemment; - des moyens de marquage (23) des informations de
la base de données comme mises à jour ou non-mises à jour.
11. Dispositif selon la revendication 10, caractérisé en ce que le marquage comme mis à jour ou comme non-mis à jour est effectué en fonction de la programmation
dudit multiplexeur (5).
12. Dispositif selon l'une des revendications 10 ou
11, caractérisé en ce qu'il comporte en outre une horloge utilisée pour le marquage des informations non-mises à
jour.
Priority Applications (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9715163A FR2771884B1 (fr) | 1997-12-02 | 1997-12-02 | Procede de gestion d'informations de service dans un systeme de television numerique et recepteur mettant en oeuvre ce procede |
| EP98402880A EP0921681B2 (fr) | 1997-12-02 | 1998-11-20 | Procédé et appareil pour la gestion d'informations de service dans un système de télévision numérique |
| DE69805044T DE69805044T3 (de) | 1997-12-02 | 1998-11-20 | Verfahren und Vorrichtung zur Verwaltung von Dienstinformationen in einem Digitalfernsehsystem |
| JP34164798A JP4111255B2 (ja) | 1997-12-02 | 1998-12-01 | デジタルテレビジョンシステムにおけるサービス情報を管理するための方法及び受信機 |
| CNB981230407A CN1157948C (zh) | 1997-12-02 | 1998-12-01 | 数字电视系统中用于管理服务信息的方法和接收机 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR9715163A FR2771884B1 (fr) | 1997-12-02 | 1997-12-02 | Procede de gestion d'informations de service dans un systeme de television numerique et recepteur mettant en oeuvre ce procede |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2771884A1 true FR2771884A1 (fr) | 1999-06-04 |
| FR2771884B1 FR2771884B1 (fr) | 1999-12-31 |
Family
ID=9514056
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR9715163A Expired - Fee Related FR2771884B1 (fr) | 1997-12-02 | 1997-12-02 | Procede de gestion d'informations de service dans un systeme de television numerique et recepteur mettant en oeuvre ce procede |
Country Status (5)
| Country | Link |
|---|---|
| EP (1) | EP0921681B2 (fr) |
| JP (1) | JP4111255B2 (fr) |
| CN (1) | CN1157948C (fr) |
| DE (1) | DE69805044T3 (fr) |
| FR (1) | FR2771884B1 (fr) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2352914A (en) * | 1999-08-03 | 2001-02-07 | Sony Uk Ltd | Data broadcast method |
| FR2803966B1 (fr) * | 2000-01-19 | 2002-11-22 | Sagem | Procede de collecte dans un decodeur de television de signaux de parametres de reglage |
| WO2001063933A1 (fr) * | 2000-02-23 | 2001-08-30 | Koninklijke Philips Electronics N.V. | Procede, emetteur et systeme de transmission |
| WO2004010701A1 (fr) * | 2002-07-24 | 2004-01-29 | General Instrument Corporation | Procede et appareil pour saisir rapidement des donnees d'identification de programme dans un multiplexeur transcodeur a large bande |
| JP4308546B2 (ja) * | 2003-02-20 | 2009-08-05 | パナソニック株式会社 | デジタル放送受信装置、デジタル放送受信方法及びデジタル放送受信プログラム |
| EP1673933A1 (fr) * | 2003-10-06 | 2006-06-28 | Koninklijke Philips Electronics N.V. | Systeme, emetteur, recepteur, signal et procede pour distribuer des services |
| EP1542472A1 (fr) * | 2003-12-10 | 2005-06-15 | Canal + Technologies | Procédé et dispositif de récupération d'information dans des systèmes de TV numérique interactive |
| GB0420814D0 (en) * | 2004-09-18 | 2004-10-20 | Koninkl Philips Electronics Nv | Managing stored service information |
| WO2006035404A1 (fr) * | 2004-09-30 | 2006-04-06 | Koninklijke Philips Electronics N.V. | Detection d'une nouvelle image logicielle pour telechargement destinee a une television numerique/hybride en mode-application |
| KR100785177B1 (ko) | 2006-05-08 | 2007-12-11 | 주식회사 대우일렉트로닉스 | Ａｔｓｃ의 아웃밴드를 이용한 데이터 저장 방법 및 그시스템 |
| EP1983744A1 (fr) * | 2007-04-20 | 2008-10-22 | Thomson Licensing | Procédés de gestion d'un dispositif vidéo et dispositif vidéo correspondant |
| US8634310B2 (en) * | 2007-06-26 | 2014-01-21 | Qualcomm Incorporated | Methods and apparatus for improved program acquisition for use with MPEG-2 based systems |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1996013932A1 (fr) * | 1994-10-27 | 1996-05-09 | Index Systems, Inc. | Appareil et procedes de telechargement de donnees de programmation d'enregistreur dans un signal video |
| WO1996034491A1 (fr) * | 1995-04-24 | 1996-10-31 | Tv Guide On Screen | Systeme electronique de choix de programmes televisuels et procede permettant de passer commande de produits a distance |
| EP0782346A1 (fr) * | 1995-12-29 | 1997-07-02 | THOMSON multimedia | Dispositif de démultiplexage pour un système de télévision digitale |
| WO1997030549A1 (fr) * | 1996-02-14 | 1997-08-21 | Powertv, Inc. | Telechargement par diffusion multiple de modules de logiciels et de donnees en fonction des exigences de ceux-ci en matiere de compatibilite |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5038211A (en) * | 1989-07-05 | 1991-08-06 | The Superguide Corporation | Method and apparatus for transmitting and receiving television program information |
-
1997
- 1997-12-02 FR FR9715163A patent/FR2771884B1/fr not_active Expired - Fee Related
-
1998
- 1998-11-20 DE DE69805044T patent/DE69805044T3/de not_active Expired - Lifetime
- 1998-11-20 EP EP98402880A patent/EP0921681B2/fr not_active Expired - Lifetime
- 1998-12-01 CN CNB981230407A patent/CN1157948C/zh not_active Expired - Fee Related
- 1998-12-01 JP JP34164798A patent/JP4111255B2/ja not_active Expired - Fee Related
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1996013932A1 (fr) * | 1994-10-27 | 1996-05-09 | Index Systems, Inc. | Appareil et procedes de telechargement de donnees de programmation d'enregistreur dans un signal video |
| WO1996034491A1 (fr) * | 1995-04-24 | 1996-10-31 | Tv Guide On Screen | Systeme electronique de choix de programmes televisuels et procede permettant de passer commande de produits a distance |
| EP0782346A1 (fr) * | 1995-12-29 | 1997-07-02 | THOMSON multimedia | Dispositif de démultiplexage pour un système de télévision digitale |
| WO1997030549A1 (fr) * | 1996-02-14 | 1997-08-21 | Powertv, Inc. | Telechargement par diffusion multiple de modules de logiciels et de donnees en fonction des exigences de ceux-ci en matiere de compatibilite |
Also Published As
| Publication number | Publication date |
|---|---|
| CN1157948C (zh) | 2004-07-14 |
| DE69805044D1 (de) | 2002-05-29 |
| EP0921681B2 (fr) | 2006-01-25 |
| EP0921681B1 (fr) | 2002-04-24 |
| DE69805044T2 (de) | 2002-09-19 |
| CN1221285A (zh) | 1999-06-30 |
| DE69805044T3 (de) | 2006-08-03 |
| EP0921681A1 (fr) | 1999-06-09 |
| FR2771884B1 (fr) | 1999-12-31 |
| JPH11234633A (ja) | 1999-08-27 |
| JP4111255B2 (ja) | 2008-07-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2752350A1 (fr) | Procede d'extraction de donnees dans un systeme de transmission cyclique et dispositif de mise en oeuvre | |
| EP2039159B1 (fr) | Procede d'affichage d'une image mosaïque au sein d'un recepteur pour la selection de programmes audiovisuels, recepteurs et serveurs associes | |
| FR2767005A1 (fr) | Procede et systeme de videodiffusion pour fournir et afficher des donnees auxiliaires avec des signaux video et audio diffuses | |
| FR2771884A1 (fr) | Procede de gestion d'informations de service dans un systeme de television numerique et recepteur mettant en oeuvre ce procede | |
| EP2063638A1 (fr) | Méthode d'évaluation de droits d'utilisateurs stockés dans un module de sécurité | |
| FR2627045A1 (fr) | Systeme de selection pour la reception d'emissions radiodiffusees ou telediffusees | |
| FR2863127A1 (fr) | Procedes et dispositifs pour la delivrance asynchrone de donnees numeriques | |
| WO2012131258A1 (fr) | Procede d'acces a un service, notamment un portail web, par un terminal de restitution d'un flux multimedia | |
| EP1432246B1 (fr) | Procede et dispositif de decodage et d'affichage en marche arriere d'images mpeg, circuit pilote video et boitier decodeur incorporant un tel dispositif | |
| WO2015132500A1 (fr) | Procédé de fourniture, à un terminal, de contenus multimédias protégés | |
| EP1537747B1 (fr) | Systeme et procede de synchronisation pour programmes audiovisuels, dispositifs et procedes associes | |
| WO2003077561A1 (fr) | Procédé de transmission de flux de données dependants | |
| FR2752351A1 (fr) | Procede d'indexation de donnees dans un systeme de transmission de television numerique | |
| FR2800958A1 (fr) | Procede de transmission et de traitement d'informations de service dans un systeme de television, recepteur et emetteur dans un tel systeme | |
| FR2794602A1 (fr) | Dispositif recepteur/decodeur de television numerique a lecture interactive de programme de television prealablement enregistre | |
| WO2004073292A2 (fr) | Dispositif securise pour la diffusion, l'enregistrement et la visualisation a la demande des oeuvres audiovisuelles au format de type mpeg-2 ts | |
| FR2812504A1 (fr) | Systeme de cryptage/decryptage "a la volee" pour la diffusion de donnees | |
| EP1119967B1 (fr) | Procede et dispositif de gestion de donnees de service dans un systeme de television | |
| FR3069996B1 (fr) | Procede de lecture d'un flux multimedia chiffre avec acces rapide au contenu en clair et dispositif d'utilisation | |
| FR2792154A1 (fr) | Procede de gestion de donnees de service et recepteur dans un systeme de television numerique | |
| EP1460852A1 (fr) | Procédé et dispositif de diffusion et de chargement d'une information dans un système de communication du type télévision numérique | |
| EP1542472A1 (fr) | Procédé et dispositif de récupération d'information dans des systèmes de TV numérique interactive | |
| EP1383336A2 (fr) | Procédé de décompression et de restitution d'un flux de données multimédia numériques compressées comprenant une pluralité d'entités encodées. Dispositif, système et signal correspondants | |
| EP1755338A1 (fr) | Méthode et dispositif pour la transmission et réception de données multimédia chiffrés | |
| FR2812160A1 (fr) | Decodeur avec fonction de creation d'images mosaiques de services de television |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |