FR2816145A1 - Procede et dispositif de filtrage des sections utiles d'un flux de donnees emises sous forme numerique - Google Patents
Procede et dispositif de filtrage des sections utiles d'un flux de donnees emises sous forme numerique Download PDFInfo
- Publication number
- FR2816145A1 FR2816145A1 FR0013845A FR0013845A FR2816145A1 FR 2816145 A1 FR2816145 A1 FR 2816145A1 FR 0013845 A FR0013845 A FR 0013845A FR 0013845 A FR0013845 A FR 0013845A FR 2816145 A1 FR2816145 A1 FR 2816145A1
- Authority
- FR
- France
- Prior art keywords
- section
- fragment
- packet
- sections
- filter
- 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.)
- Pending
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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
- H04N21/23608—Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
- H04N21/2365—Multiplexing of several video streams
-
- 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
-
- 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/4344—Remultiplexing of multiplex streams, e.g. by modifying time stamps or remapping the packet identifiers
-
- 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/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/4347—Demultiplexing of several video streams
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Abstract
La présente invention a pour objet un procédé et un dispositif de filtrage des sections utiles d'un flux de données émises sous forme numérique. Le procédé consiste à ajouter à la tête des fragments (15) correspondant chacun à une partie d'une section (13) située dans un paquet (9) unique un en-tête (16) de fragment indiquant la position dudit fragment dans la section, le numéro du filtre ayant filtré la section et le "PID " ayant traité le paquet contenant le fragment, tous les fragments utiles étant envoyés à l'utilisateur à la fin de chaque paquet de façon à ne pas nécessiter de de mémoire de stockage temporaire dans le bloc de filtrage. L'invention se rapporte d'une manière générale au domaine de la réception d'informations numériques transmise par un réseau de télécommunications et utilisant le codage par " paquets " constitués d'un ensemble de données acheminées en blocs, et plus particulièrement des diffusions émises selon le protocole MPEG 2.
Description
<Desc/Clms Page number 1>
La présente invention a pour objet un procédé et un dispositif de filtrage des sections utiles d'un flux de données émises sous forme numérique.
Elle se rapporte d'une manière générale au domaine de la réception d'informations numériques transmises par un réseau de télécommunications et utilisant le codage par"paquets"constitués d'un ensemble de données acheminées en blocs, et plus particulièrement des diffusions émises selon le protocole MPEG 2.
Les données et informations sont de plus en plus diffusées sous forme de flux numériques découpés en"paquets". Cette technique se prête particulièrement bien à la transmission par satellites et est d'ores et déjà employée pour la télévision qui s'intègre progressivement dans les nouveaux réseaux de communications informatiques multimédias.
Les récepteurs de signaux numériques tels que décodeurs satellites 1 ou ordinateurs équipés d'une carte de réception 2 peuvent sélectionner les données à recevoir sur un écran 3 en fonction du choix d'un utilisateur (par exemple une chaîne de télévision déterminée) (figure 1).
Actuellement la diffusion d'émissions de télévision numérique par satellite s'effectue en général selon un protocole désigné par le sigle"MPEG-2"et caractérisé par des paquets en tête de chacun desquels est placé un identificateur ("PID": Packet Identifier) permettant d'identifier un flux de paquets.
Un récepteur traitant un flux transport 4 au format MPEG-2 réalise plusieurs traitements afin d'exploiter ce flux. Un des traitements nécessaires consiste à filtrer des informations reçues sous forme de sections (cf norme MPEG-2 système : ISO/IEC 13818-1). Cette opération s'effectue au moyen d'un bloc de filtrage 5 comportant un filtre d'en-têtes 6 et un filtre de sections 7 permettant de ne transmettre
<Desc/Clms Page number 2>
que les sections filtrées à l'utilisateur 8. On parle alors de filtrage de sections dans un flux transport MPEG-2 (figure 2).
Un flux transport 4 MPEG-2 est formé de paquets 9 de taille fixe (188 octets), composés chacun d'une en-tête 10 de 4 octets, et d'une partie utile 11 de 0 à 184 octets (on parle de"payload"). Le reste du paquet est constitué par un champ 12
appelé"adaptation field" (figure 3).
appelé"adaptation field" (figure 3).
L'en-tête 10 d'un paquet contient plusieurs champs, dont l'un est l'identificateur ou"Packet Identifier" (P) D). Ce champ permet d'isoler un flux de paquets transports 9 dans le flux transport 4 principal. Ce dernier est en effet composé de plusieurs flux d'information, chacun ayant un identificateur"PID"attribué, tous les flux d'information étant multiplexés en un seul flux transport.
Les sections 13 à filtrer sont contenues dans la partie utile 11 ("payload") des paquets 9, et sont encapsulées dans ces paquets suivants certaines règles : - Un flux de section est contenu sur un PID et un seul, mais plusieurs flux de sections 13, 13'peuvent exister dans le flux transport 4 (chacun sur un PID dans ce cas) (figure 4).
- Une section n'est par forcément alignée en début de paquet 9.
- Une section peut être plus longue ou plus courte qu'un paquet.
- Il peut y avoir plusieurs sections par paquet (si elles sont plus courtes que la partie utile 11 du paquet 9).
- Une section peut être transmise sur plusieurs paquets si sa taille le nécessite.
- Il est possible d'ajouter des octets de"bourrage" (valeur 255) à un paquet après une section pour indiquer qu'il n'y a plus de sections contenues dans ce paquet.
Si un paquet 9 contient un début de section, son en-tête 10 l'indique par un bit particulier si sa valeur est 1 (Payload Unit Start Indicator ou PUSI : indicateur de
<Desc/Clms Page number 3>
début de contenu utile). Si le bit"PUSI"est monté dans l'en-tête du paquet (il y a un début de section dans le paquet), alors le premier octet de la partie utile 11 (payload) du paquet contient une valeur particulière appelée le pointeur de champ (pointer field), qui sert à donner la distance en nombre d'octets du premier début de section dans le paquet. Les positions des autres débuts de section dans ce paquet (s'il y en a) sont déduites à partir de la longueur de la première section qui est pointée par le pointeur de champ (ou pointer field).
Une section a elle-même un en-tête, qui contient plusieurs champs dont la longueur de la section. Cette longueur permet de connaître la position de la section suivante. L'en-tête de section peut éventuellement être à cheval sur deux paquets transport (figure 5).
Lors de la réception d'un flux transport 4, un récepteur doit filtrer les sections pour ne conserver que celles qui sont utiles, un composant de filtrage matériel, ou bloc de filtrage 5 pouvant être utilisé pour cela.
La première étape consiste à isoler les flux de sections utiles dans le flux transport. Cette opération est réalisée par un filtre d'en-tête 6 appelé"demux" (démultiplexeur), qui filtre sur les PID contenus dans les en-têtes 10 des paquets transport.
La deuxième étape consiste à filtrer les sections utiles dans le flux de section. Le récepteur utilise un filtre 7 sur des octets particuliers de la section, qui permettent de connaître son type, ainsi que des informations dépendant du type (voir figure 2).
Le type de la section 13 est indiqué par le premier octet de celle-ci constituant l'identificateur de table"Tablejd" (TID). Les deuxième et troisième octets contiennent plusieurs champs, dont l'un indique la longueur de la section. Ces octets ne sont généralement pas utilisés dans le filtrage, sauf pour connaître la taille de la section.
<Desc/Clms Page number 4>
La signification des octets suivants dépend du type de la section (premier octet ou TID). Les premiers d'entre eux peuvent être utilisés par le mécanisme de filtrage.
Les sections filtrées sont envoyées par l'intermédiaire d'un bus afin d'être stockées et traitées. Ce bus peut être par exemple : - un bus d'accès à une mémoire où les sections seront stockées avant d'être traitées par le processeur, - un bus de transfert (USB, Ethernet, ) qui permet d'envoyer les sections filtrées au matériel qui utilise ces sections (PC par exemple),
Actuellement, les sections utiles ne sont envoyées que quand tous les octets 14 participant au filtrage de la section ont été vérifiés. Un problème se pose quand ces octets sont à cheval sur deux paquets transport (figure 5), car il faut alors stocker temporairement les octets qui ont été reçus, en attendant que tous les octets aient été vérifiés. La mémoire utilisée pour ce mécanisme fait partie du bloc de filtrage 5, et est assez conséquente, étant donné qu'elle est nécessaire pour chaque filtre de sections. Sa profondeur doit être égale au nombre d'octets maximum à filtrer permettant de dire si l'ensemble de la section sera récupérée (profondeur de filtrage).
Actuellement, les sections utiles ne sont envoyées que quand tous les octets 14 participant au filtrage de la section ont été vérifiés. Un problème se pose quand ces octets sont à cheval sur deux paquets transport (figure 5), car il faut alors stocker temporairement les octets qui ont été reçus, en attendant que tous les octets aient été vérifiés. La mémoire utilisée pour ce mécanisme fait partie du bloc de filtrage 5, et est assez conséquente, étant donné qu'elle est nécessaire pour chaque filtre de sections. Sa profondeur doit être égale au nombre d'octets maximum à filtrer permettant de dire si l'ensemble de la section sera récupérée (profondeur de filtrage).
A titre indicatif, pour 16 filtres de 16 octets de profondeur, la taille de la mémoire est de 8 bits * 16 filtres * 16 octets = 2 Kbits, sans compter la logique relativement complexe permettant de contrôler l'utilisation de cette mémoire.
La présente invention a pour objectif de remédier à cet état de choses en apportant une solution permettant de réduire fortement la taille et la complexité du bloc de filtrage, grâce à la suppression de la mémoire de stockage temporaire des sections, et de la logique associée à cette mémoire.
Le procédé consiste à ajouter à la tête des fragments correspondant chacun à une partie d'une section située dans un paquet unique un en-tête de fragment indiquant la position du fragment dans la section, le numéro du filtre ayant filtré la
<Desc/Clms Page number 5>
section, et le"PID"ayant traité le paquet contenant le fragment, tous les fragments utiles étant envoyés à l'utilisateur à la fin de chaque paquet de façon à ne pas nécessiter de mémoire de stockage temporaire dans le bloc de filtrage.
L'invention sera mieux comprise par la description qui va suivre, faite en se référant aux schémas annexés à titre indicatif seulement, et sur lesquels : la figure 1, déjà citée (de même que les figures 2 à 5), représente le schéma synoptique d'une station de réception, la figure 2 est un schéma du bloc de filtrage, la figure 3 montre la structure du flux transport, la figure 4 représente le placement de deux sections sur des paquets de"PID"différent, la figure 5 montre une section dont les octets à filtrer sont à cheval sur deux paquets, et les figures 6 à 8 illustrent différents cas de génération de fragments à partir des sections filtrées.
Dans ce qui suit, le terme"utilisateur"8 des sections désigne l'entité (matérielle ou logicielle) qui reçoit et traite les sections 13 filtrées.
Par ailleurs, on dira qu'une section est validée quand tous les bits ou octets permettant de filtrer cette section ont été comparés avec succès aux valeurs de référence.
Pour éviter de stocker dans le bloc de filtrage les octets tant que tous les octets à filtrer n'ont pas été reçus, le mécanisme suivant est utilisé : - les sections 13 sont divisées en fragments 15 de section, un fragment correspondant à une partie d'une section située dans un paquet transport 9 unique (une section comprise entièrement dans un seul paquet transport sera composé d'un seul fragment. ) - chaque fragment 15 de section est encapsulé avant d'être envoyé à l'utilisateur 8. L'encapsulation consiste en l'ajout d'un en-tête de section 16 ou"header"
<Desc/Clms Page number 6>
devant le fragment de section, permettant de donner des indications sur le fragment, comme par exemple : si le fragment est un début de section, une fin de section, ou les deux, ainsi que le numéro du filtre ayant filtré la section, et le"PID"ou numéro de canal "PID"ayant traité le paquet 9 qui contient le fragment 15 (figure 6).
- à chaque fin de paquet, tout fragment de section qui a été filtré avec succès est envoyé à l'utilisateur 8, Toutefois, cette situation est indiquée par la montée d'un indicateur F (F comme fragmenté), situé dans le "header" associé au fragment de section, indiquant à l'utilisateur du fragment que d'autres fragments de la section en cours de transmission sont attendus, et que ce dernier ne doit pas être utilisé tout de suite - il est possible que lors de la réception des derniers octets permettant de filtrer la section 13, la section soit rejetée. Dans ce cas, le récepteur du premier fragment 15 (incomplet) ne recevra jamais la suite de la section, mais recevra à la place un nouveau début de section lors de l'arrivée d'une prochaine section validée. Le fragment de la section incomplète doit alors être détruit sans être utilisé, ce traitement étant à la charge de l'utilisateur 8 (ordinateur, processeur ou autre) des sections (figure 7).
Un problème se pose quand, à la fin d'un paquet, plusieurs filtres ont validé le fragment de la section, mais que la suite de la section est attendue dans un prochain paquet (un seul filtre validera la section finalement). Il est alors impossible d'attribuer un numéro de filtre au fragment de section. Ce problème est résolu de la façon suivante : - un numéro de filtre est choisi parmi les filtres ayant validé le fragment de section, et est attribué au fragment (placé dans le"header"du fragment) - l'indicateur F est monté, comme indiqué précédemment. Il permet à l'utilisateur de la section de savoir qu'il faut attendre la suite de la section afin d'être sûr du numéro de filtre - si lors de la réception des octets suivants de la section, le même filtre valide la section, alors tout se poursuit de façon classique
<Desc/Clms Page number 7>
- si lors de la réception des octets suivants de la section, aucun filtre ne valide la section, alors aucun autre fragment ne sera envoyé à l'utilisateur des sections (figure 7). Un nouveau fragment de début de section sera envoyé lors de la réception de la prochaine section validée. Le fragment de la section incomplète doit alors être détruit sans être utilisé, ce traitement étant à la charge de l'utilisateur (ordinateur, processeur ou autre) des sections - si lors de la réception des octets suivants de la section, un filtre différent valide la section, alors le numéro de ce nouveau filtre est attribué au fragment contenant ces nouveaux octets. L'utilisateur des sections doit détecter cette situation grâce à l'indicateur F et au numéro de canal du PID, qui reste le même entre les deux fragments. Autrement dit, un récepteur recevant un fragment avec l'indicateur F monté dans son en-tête de section 16 doit s'attendre à recevoir éventuellement la suite de cette section sur un autre filtre (le PID restant le même entre les deux fragments). Le numéro de filtre à utiliser dans l'en-tête de section 16'est le numéro de filtre du dernier fragment reçu (figure 8).
La mémoire de stockage est transférée du bloc de filtrage 5 vers l'utilisateur 8 des sections (ordinateur, processeur,...). Elle n'est donc pas supprimée, mais transférée dans un bloc où la mémoire est généralement moins coûteuse.
La suppression de cette fonctionnalité dans le bloc de filtrage requiert un travail supplémentaire du côté de l'utilisateur des sections. Toutefois, la situation où l'indicateur F est monté est assez rare, même si elle peut arriver, dans les flux MPEG.
La plupart des sections filtrées ne nécessiteront pas de traitement supplémentaire par le bloc utilisateur des sections.
Le positionnement des divers éléments constitutifs donne à l'objet de l'invention un maximum d'effets utiles qui n'avaient pas été, à ce jour, obtenus par des procédés similaires.
Claims (4)
- 3. Procédé selon la revendication 2, se caractérisant par le fait que l'en-tête de fragment (16) de chaque fragment (15) comporte un indicateur de fragmentation indiquant à l'utilisateur (8) du fragment que d'autres fragments (15) utiles au filtrage de la section (13) en cours de transmission sont attendus, et que ledit fragment ne doit pas être utilisé tout de suite.
- 4. Procédé selon la revendication 3 se caractérisant par le fait que, lorsque plusieurs filtres du bloc de filtrage (5) ont validé le fragment (15) de la section (13) et que la suite de la section est attendue dans un prochain paquet (9), un numéro de filtre choisi parmi les filtres ayant validé le fragment est attribué au dit fragment et<Desc/Clms Page number 9>l'indicateur de fragmentation est activé pour indiquer à l'utilisateur (8) de la section de savoir qu'il faut attendre la suite de la section.
- 5. Procédé selon l'une quelconque des revendications précédentes, se caractérisant par le fait que l'utilisateur (8) des sections (13) comporte un système lui permettant d'éliminer un fragment (15) d'une section (9) incomplète lorsqu'il reçoit un nouveau début de section sur le même"PID"sans avoir reçu la fin de la section précédente.
- 6. Dispositif de filtrage des sections utiles d'un flux de données émises sous forme numérique et transmises par un réseau de télécommunications en utilisant le codage par"paquets"selon le protocole MPEG 2, destiné à être utilisé pour l'application du procédé selon les revendications précédentes, se caractérisant par le fait qu'il est dépourvu de mémoire de stockage temporaire des octets reçus.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0013845A FR2816145A1 (fr) | 2000-10-27 | 2000-10-27 | Procede et dispositif de filtrage des sections utiles d'un flux de donnees emises sous forme numerique |
| PCT/FR2001/003327 WO2002035750A2 (fr) | 2000-10-27 | 2001-10-26 | Procede et dispositif de filtrage des sections utiles d'un flux de donnees emises sous forme numerique. |
| EP01982562A EP1410597A2 (fr) | 2000-10-27 | 2001-10-26 | Procede et dispositif de filtrage des sections utiles d'un flux de donnees emises sous forme numerique. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0013845A FR2816145A1 (fr) | 2000-10-27 | 2000-10-27 | Procede et dispositif de filtrage des sections utiles d'un flux de donnees emises sous forme numerique |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2816145A1 true FR2816145A1 (fr) | 2002-05-03 |
Family
ID=8855833
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0013845A Pending FR2816145A1 (fr) | 2000-10-27 | 2000-10-27 | Procede et dispositif de filtrage des sections utiles d'un flux de donnees emises sous forme numerique |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP1410597A2 (fr) |
| FR (1) | FR2816145A1 (fr) |
| WO (1) | WO2002035750A2 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0917356A1 (fr) * | 1997-11-17 | 1999-05-19 | CANAL+ Société Anonyme | Filtrage de packets |
| EP0999679A2 (fr) * | 1998-08-31 | 2000-05-10 | Matsushita Electric Industrial Co., Ltd. | Appareil pour le filtrage de paquets qui applique à chaque paquet plusieurs conditions de filtrage avec différent comparisons |
-
2000
- 2000-10-27 FR FR0013845A patent/FR2816145A1/fr active Pending
-
2001
- 2001-10-26 WO PCT/FR2001/003327 patent/WO2002035750A2/fr active Application Filing
- 2001-10-26 EP EP01982562A patent/EP1410597A2/fr not_active Withdrawn
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0917356A1 (fr) * | 1997-11-17 | 1999-05-19 | CANAL+ Société Anonyme | Filtrage de packets |
| EP0999679A2 (fr) * | 1998-08-31 | 2000-05-10 | Matsushita Electric Industrial Co., Ltd. | Appareil pour le filtrage de paquets qui applique à chaque paquet plusieurs conditions de filtrage avec différent comparisons |
Non-Patent Citations (1)
| Title |
|---|
| "DESIGN ARCHITECTURE FOR MPEG2 TRANSPORT DEMULTIPLEXOR ASSIST", IBM TECHNICAL DISCLOSURE BULLETIN,US,IBM CORP. NEW YORK, vol. 39, no. 4, 1 April 1996 (1996-04-01), pages 283 - 286, XP000587499, ISSN: 0018-8689 * |
Also Published As
| Publication number | Publication date |
|---|---|
| EP1410597A2 (fr) | 2004-04-21 |
| WO2002035750A2 (fr) | 2002-05-02 |
| WO2002035750A3 (fr) | 2002-08-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2218203A1 (fr) | Procede et dispositif de transmission robuste d'en-tetes reseau compresses | |
| WO2019068982A1 (fr) | Signalisation d'une requête d'adaptation d'une session de communication en voix sur ip | |
| FR2929787A1 (fr) | Procede et dispositif de traitement d'un flux de donnees | |
| EP2605475A2 (fr) | Procédé et dispositif de transmission robuste de flux de paquets de données à en-têtes compressés sans augmentation de débit | |
| EP3750285B1 (fr) | Procédé et dispositif d'envoi de paquets de données sur un réseau ip/mpls | |
| EP3378232B1 (fr) | Procédé de traitement de données codées, procédé de réception de données codées, dispositifs, et programmes d'ordinateurs associés | |
| EP1845685A1 (fr) | Transmission perfectionnée de paquets IP de contenus, par adjonction à ces paquets IP de données d'information rélatives aux contenus | |
| EP3229483A1 (fr) | Extraction de flux video | |
| FR2816145A1 (fr) | Procede et dispositif de filtrage des sections utiles d'un flux de donnees emises sous forme numerique | |
| FR2790892A1 (fr) | Procede et dispositif de controle de la synchronisation entre deux bus de communication serie d'un reseau | |
| FR2812504A1 (fr) | Systeme de cryptage/decryptage "a la volee" pour la diffusion de donnees | |
| EP3654613B1 (fr) | Protocole de transmission d'un flux de données transitant entre un ordinateur hôte et un client distant | |
| EP0792071B1 (fr) | Dispositif de décodage de signaux de type MPEG2 | |
| FR2838898A1 (fr) | Dispositif d'aiguillage a commutation et routage centralises | |
| WO2001008374A1 (fr) | Procedes de transmission et de diffusion de paquets de donnees et recepteurs pour la mise en oeuvre des procedes | |
| EP0781480B1 (fr) | Dispositif de routage de paquets | |
| EP0992161B1 (fr) | Procede de transmission de donnees en paquets entre un emetteur de television numerique et des recepteurs de television | |
| WO2009138480A1 (fr) | Procede de transmission de donnees multimedia selon un protocole du type protocole internet | |
| FR2785755A1 (fr) | Procede de restitution de donnees de datagrammes encapsules dans des paquets de transport et recepteur pour la mise en oeuvre du procede | |
| WO2022200703A1 (fr) | Emission d'un signal par un premier composant electronique d'un vehicule a destination d'au moins un second composant electronique du vehicule | |
| EP0788716A1 (fr) | Multiplexeur de paquets d'informations numeriques, notamment pour la television numerique | |
| WO2005009047A2 (fr) | Methode d'insertion de marques de synchronisation dans un flux video, compatible avec un chiffrage par blocs | |
| WO1996013940A1 (fr) | Multiplexeur de paquets d'informations numeriques, notamment pour la television numerique | |
| WO1999027692A1 (fr) | Protocole de transmission de donnees numeriques sous forme d'elements mpeg-ts | |
| FR2867004A1 (fr) | Procede, systeme et dispositif de temporisation d'un flux de paquets de donnees |