FR2863130A1 - Dispositif et procede de preparation de donnees d'emission et produits correspondants - Google Patents
Dispositif et procede de preparation de donnees d'emission et produits correspondants Download PDFInfo
- Publication number
- FR2863130A1 FR2863130A1 FR0314076A FR0314076A FR2863130A1 FR 2863130 A1 FR2863130 A1 FR 2863130A1 FR 0314076 A FR0314076 A FR 0314076A FR 0314076 A FR0314076 A FR 0314076A FR 2863130 A1 FR2863130 A1 FR 2863130A1
- Authority
- FR
- France
- Prior art keywords
- data
- entities
- entity
- transmission rate
- rate
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims abstract description 27
- 230000005540 biological transmission Effects 0.000 claims abstract description 64
- 238000012937 correction Methods 0.000 claims abstract description 32
- 238000002360 preparation method Methods 0.000 claims abstract description 21
- 238000004891 communication Methods 0.000 claims abstract description 8
- 238000012546 transfer Methods 0.000 claims abstract description 6
- 208000027744 congestion Diseases 0.000 claims description 16
- 238000001514 detection method Methods 0.000 claims description 9
- 238000004590 computer program Methods 0.000 claims description 6
- 241001527806 Iti Species 0.000 claims 1
- 238000007792 addition Methods 0.000 description 17
- 238000009792 diffusion process Methods 0.000 description 7
- 230000000750 progressive effect Effects 0.000 description 7
- 238000012913 prioritisation Methods 0.000 description 6
- 230000033228 biological regulation Effects 0.000 description 5
- 230000006870 function Effects 0.000 description 5
- 238000007726 management method Methods 0.000 description 5
- 230000001934 delay Effects 0.000 description 3
- 230000015654 memory Effects 0.000 description 3
- 238000012545 processing Methods 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 238000000605 extraction Methods 0.000 description 2
- 230000006872 improvement Effects 0.000 description 2
- 230000008569 process Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 239000000654 additive Substances 0.000 description 1
- 230000000996 additive effect Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000001174 ascending effect Effects 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 208000013407 communication difficulty Diseases 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000008030 elimination Effects 0.000 description 1
- 238000003379 elimination reaction Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 230000002123 temporal effect Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
-
- 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
-
- 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/1066—Session management
- H04L65/1101—Session protocols
-
- 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
-
- 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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
- H04N21/2383—Channel coding or modulation of digital bit-stream, e.g. QPSK modulation
-
- 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
- H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
-
- 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
-
- 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4382—Demodulation or channel decoding, e.g. QPSK demodulation
-
- 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
- H04N21/64322—IP
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Communication Control (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
Abstract
La présente invention concerne un dispositif (1) et un procédé de préparation de données (21) à émettre en flux continu via un réseau de communication.Le dispositif comprend des moyens d'obtention (11 ) des données en provenance d'une base de données (2), qui contient au moins deux entités (Ej) de flux de données associées respectivement à des débits de transmission (24) différents, des moyens de transfert (12) de ces données vers un système d'émission (3), des moyens de branchement (13) sur une de ces entités, et des moyens de commutation (14) des moyens de branchement d'une des entités vers une autre.Le dispositif de préparation comprend aussi des moyens d'ajout régulier (15) aux données transférées, de codes de correction d'erreurs (22). Les moyens de commutation commutent d'une première vers une deuxième des entités de débit supérieur, lorsque ce flux de données augmenté (DATA) atteint la somme du débit d'émission associé à la deuxième entité et d'un débit additionnel (éventuellement nul) associé à un apport initial de codes de correction d'erreurs pour la deuxième entité, et les moyens d'ajout réinitialisent l'ajout des codes à cet apport initial lors de cette commutation.Application au streaming sur réseau IP.
Description
La présente invention se rapporte à un dispositif et un procédé de
préparation de données à émettre en flux continu vers au moins un récepteur via un réseau de communication. Elle s'applique en particulier à un transfert de données en flux continu, ou streaming , notamment pour
flux audiovisuels (multimédia) transmis sur réseau IP (pour Internet Protocol ). L'invention se rapporte également à un serveur de données et à un programme d'ordinateur associés.
Les réseaux de type IP s'appuient sur un maillage de noeuds interconnectés qui effectuent des routages de paquets de données, appelés routeurs. Un tel réseau est généralement exposé à des délais, de la gigue et des pertes de paquets, qui résultent de ce que les ressources des routeurs ne sont pas infinies et de ce que le trafic peut être sujet à de fortes variations de charge. En particulier, les routeurs ont leurs capacités restreintes par les tailles de mémoires FIFO (pour First ln, First Out ) et les durées de traitements divers, tels que notamment résolutions d'adresses, corrections d'erreurs et/ou retransmissions, sommes de contrôle ( checksum ) et gestions de protocoles d'administration du réseau (mises à jour de tables de routage, qualité de service, groupes de multidiffusion ou multicast , etc.).
Les ressources des routeurs sont également affectées par des pannes, dont l'existence est d'autant plus probable que le nombre de noeuds du réseau est élevé et que ce dernier est utilisé pendant une longue période.
Une autre conséquence pénalisante de cette situation est que les applications qui utilisent le réseau disposent d'une bande passante qui s'avère à la fois limitée et très variable.
Les pertes de données peuvent être partiellement corrigées par des mécanismes de vérification avec répétition automatique des messages en erreur, appelés aussi ARQ (pour Automatic Repeat and Request ), ou par des ajouts de codes de correction d'erreurs tels que notamment des codes de correction d'erreurs sans voie de retour, appelés codes FEC (pour Forward Error Correction ). Cependant, ces techniques introduisent 2863130 -2- elles-mêmes des délais supplémentaires, diminuant encore la bande passante disponible.
Ces difficultés ont entraîné deux types de développements, les uns relatifs au partage des ressources entre utilisateurs, et les autres concernant l'adaptation de chaque diffuseur à la bande passante disponible au cours du temps.
En ce qui concerne le premier point, pour pouvoir partager équitablement les ressources du réseau (bande passante par utilisateur) tout en limitant autant que possible les pertes de paquets, les utilisateurs doivent suivre des règles de loyauté ( fairness ). En particulier, ils doivent utiliser des protocoles respectant le principe désigné par AIMD ( Additive Increase, Multiplicative Decrease ). Selon ce dernier, un diffuseur de contenu sur le réseau doit faire croître lentement et linéairement (à pas constant) son débit d'émission tant que son estimation de l'état du réseau le permet, en prenant en compte des paramètres tels que: estimation de la valeur d'un taux de perte, durée d'aller-retour ( RTT pour Round Time Trip ), débit utile ( goodput ), etc. En revanche, il doit réduire drastiquement son débit d'émission ( Multiplicative Decrease ) dès qu'une perte a été détectée.
Le principe AIMD pour réseau IP est intégré dans le protocole de communication TCP (pour Transmission Control Protocol ). Cependant, utilisant un système d'acquittement et de retransmission des paquets perdus, il est généralement considéré comme inadapté au transport des flux audiovisuels, car il introduit des délais inacceptables et ne permet pas le mode de multidiffusion. C'est pourquoi on lui préfère pour la transmission en flux continu (streaming), l'exploitation combinée des protocoles RTP (pour Real Time Transport Protocol ) et UDP (pour User Datagram Protocol ) . Il s'agit cependant de bâtir sur cette technique de transmission un système AIMD. En particulier, on parle de régulation TCP-friendly 2863130 -3- (c'est-à-dire équitable par rapport à TCP) lorsque le débit utilisé n'est pas plus grand que celui qui aurait été utilisé par une source TCP dans des conditions similaires.
Pour ce qui concerne le second type de développements effectués pour tenir compte des difficultés de communication sur réseau, il existe traditionnellement deux manières d'adapter un flux vidéo à la bande passante disponible. La première consiste à utiliser un codeur temps réel avec un module de régulation efficace. On est ainsi capable de générer à la volée un flux vidéo respectant une consigne de débit.
Cependant, de tels encodeurs sont généralement moins efficaces que des encodeurs en différé (non temps réel), dits off-line . En effet, ces derniers peuvent être mis en place avec des algorithmes de codage susceptibles de disposer de la complexité voulue (puisqu'ils ne sont pas contraints par le temps) et être donc bien plus efficaces (meilleure qualité des images décodées pour un même débit). Les algorithmes de codage peuvent consister par exemple en un mode à plusieurs passages (codage multipass ) ou en un choix du type de codage pour chaque bloc. Pour des raisons similaires, un codeur off-line respecte souvent mieux des consignes de débit.
La seconde manière traditionnelle d'adapter un flux vidéo à la bande passante disponible consiste à générer un ensemble de flux de la même vidéo, codés à des débits différents. Le serveur vidéo diffuse alors sélectivement un flux plutôt qu'un autre en fonction d'une consigne de débit désirée. Comme indiqué précédemment, les flux off-line pouvant être de meilleure qualité que les flux temps réel , ce mode de diffusion apporte généralement une meilleure qualité de service pour le client.
On peut distinguer essentiellement deux branches pour l'exercice de ce type de méthodes. Selon une technique de diffusion sélective directe, appelée simulcast , on encode directement plusieurs versions d'une 2863130 -4- même séquence à des débits différents. Durant une diffusion et en fonction de la bande passante disponible de la connexion, on envoie alors un flux plutôt qu'un autre. Par exemple, on dispose de trois flux encodés à taux de bits constants (mode CBR pour Constant Bit Rate ), associés respectivement à trois débits distincts. Si à un instant donné on diffuse le deuxième flux et que des pertes de paquets apparaissent, on commute automatiquement sur le premier flux, de débit inférieur. Si au contraire la bande passante disponible devient suffisamment grande, on peut commuter sur le troisième flux, de débit supérieur.
Selon une deuxième technique de diffusion sélective, par hiérarchisation ou scalability , on prévoit une couche de base et une ou plusieurs couches supplémentaires d'amélioration ( enhancement layers ). Ces couches supplémentaires permettent d'accroître la qualité de diffusion et/ou la résolution temporelle et/ou spatiale. Selon la disponibilité en bande passante, on ajoute ainsi à la couche de base une ou plusieurs couches d'amélioration.
Dans l'industrie, on observe que les différentes normes de codage vidéo de ces dernières années, telles que H263, MPEG2 et MPEG4 (pour Moving Picture Experts Group ) ou AVC (pour Advanced Video Coding ), sont d'une complexité croissante et que les premières implémentations de codeurs associés sont off-line . De plus, même après plusieurs années et en dépit de la puissance toujours croissante des calculateurs, les codeurs off-line restent sensiblement meilleurs que les codeurs temps réel . Les techniques simulcast et de hiérarchisation sont donc particulièrement intéressantes pour tenir compte efficacement de la disponibilité en bande passante.
Cependant, elles ont l'inconvénient, dans leur forme générique, de violer le principe AIMD d'accroissement progressif du débit. En effet, l'écart entre deux flux simulcast ou correspondant à l'ajout d'une couche de 2863130 -5- hiérarchisation produit des paliers d'augmentation de débit, lors de phases de disponibilité en bande passante. Ces écarts sont d'autant plus grands que le nombre de flux prévus (encodage selon plusieurs débits ou avec couches d'amélioration) est relativement restreint. En effet, en pratique, on n'encode les séquences qu'un nombre réduit de fois, ou on ne prévoit qu'un nombre réduit de couches, par souci d'économie d'espace mémoire et de traitement, et pour la simplicité de gestion et de mise en oeuvre.
D'autre part, en cas de congestion (perte de paquets), la commutation d'un flux à un autre de débit moindre requiert des opérations spécifiques de traitement de la part du serveur. Pendant ce temps, le client reçoit un flux dégradé.
Certaines autres méthodes de flux off-line permettent de réduire ces problèmes. Ainsi, la technique de hiérarchisation fine ou FGS (pour Fine Grain Scalability ) permet d'ajuster en temps réel le débit du flux émis en tronquant la couche supérieure d'amélioration. Cependant, cette technique s'avère offrir une efficacité de codage assez réduite par rapport aux techniques génériques de diffusion sélective.
La technique de codage sous-bande repose également sur une troncature d'une couche d'amélioration et s'avère assez efficace. Cependant, elle implique un niveau de complexité supérieur à celui requis pour les algorithmes de codage habituellement utilisés (fondés sur des méthodes DCT, pour Discrete Cosinus Transforms ).
Afin de remédier aux problèmes de sauts de débit des techniques simulcast et de hiérarchisation, une personne du métier pourrait être tentée de multiplier le nombre de flux prévus (c'est-à-dire de versions à débits distincts en technique simulcast ou de couches en technique de hiérarchisation). Ainsi, les écarts de débits entre deux entités successives pourraient être réduits en conséquence. Cependant, une telle solution s'avère très coûteuse en stockage nécessaire et en gestion des flux, et ce 2863130 -6- d'autant plus qu'elle permet d'approcher de plus près le principe AIMD d'accroissement progressif du débit.
La présente invention concerne un dispositif de préparation de données, pouvant être apte à fournir un flux de données respectant le principe AIMD de croissance progressive de débit, tout en étant susceptible d'être efficace en terme de codage, de ne pas accroître significativement la complexité et d'éviter un accroissement significatif des coûts de gestion et de stockage. Le dispositif de l'invention peut même être TCP-friendly.
D'autre part, il peut être capable de réagir très rapidement à des pertes de paquets.
L'invention concerne également un procédé de préparation de données et un programme d'ordinateur correspondant au dispositif de l'invention, ayant les avantages cités ci-dessus, ainsi qu'un serveur de données comprenant un dispositif conforme à l'invention.
Elle s'applique en particulier au domaine du streaming de flux audiovisuels sur réseau IP.
A cet effet, l'invention a pour objet un dispositif de préparation de données à émettre en flux continu vers au moins un récepteur via un réseau de communication. Ce dispositif comprend: - des moyens d'obtention des données en provenance d'une base de données, cette base de données contenant au moins deux entités de flux de données associées respectivement à des débits de transmission différents, - des moyens de transfert de ces données obtenues vers un système d'émission des données en flux continu sur le réseau, - des moyens de branchement des moyens d'obtention sur une des entités de flux de la base de données, 2863130 -7- et des moyens de commutation des moyens de branchement d'une des entités vers une autre des entités.
Selon l'invention: - le dispositif de préparation comprend des moyens d'ajout régulier aux données transférées vers le système d'émission, de codes de correction d'erreurs de façon à former un flux de données augmenté, - les moyens de commutation sont prévus pour commuter les moyens de branchement d'une première des entités associée à un premier débit d'émission vers une deuxième des entités associée à un deuxième débit d'émission supérieur au premier débit d'émission, lorsque le flux des données transférées augmentées des codes de correction d'erreurs ajoutés atteint un débit de seuil égal à la somme du deuxième débit d'émission et d'un débit additionnel (pouvant être réduit à zéro) associé à un apport initial de codes de correction d'erreurs pour la deuxième entité, et - les moyens d'ajout sont prévus pour réinitialiser l'ajout des codes à cet apport initial lors de la commutation de la première entité vers la deuxième entité.
Par émission en flux continu , ou streaming , on entend une émission des données qui permettent aux récepteurs de les lire en temps réel pendant la transmission, sans avoir à attendre leur téléchargement complet.
Le terme régulier relatif à l'ajout des codes de correction 25 d'erreurs vise des ajouts cumulés et progressifs au cours du temps, de préférence périodiques.
Par atteindre le débit de seuil, on entend devenir égal ou supérieur.
Le dispositif de l'invention repose ainsi sur une croissance progressive de débit pour chaque entité de flux, jusqu'à atteindre une valeur nominale correspondant à une entité de débit supérieur, éventuellement augmentée d'une valeur additionnelle correspondant à des codes de correction d'erreurs de précaution (au regard de risques de congestion). Un basculement vers cette dernière entité peut alors être déclenché sans saut de débit, ou avec un saut significativement réduit. Il est ainsi possible d'exploiter les méthodes existantes et éprouvées de simulcast ou de hiérarchisation, tout en respectant le principe AIMD de croissance progressive de débit.
Cependant, contrairement à la solution que la personne du métier mentionnée plus haut serait tentée de mettre en oeuvre pour parvenir à une telle réalisation, c'est-à-dire du bourrage, le dispositif de l'invention exploite des codes de correction d'erreurs. L'intervention de ces codes, inattendue dans une telle utilisation, est particulièrement avantageuse en cas de pertes de données. En effet, ils permettent alors de corriger automatiquement ces pertes (au moins partiellement).
Ainsi, non seulement le dispositif de l'invention peut être apte à respecter le principe AIMD, aussi bien vis-à-vis de la croissance progressive de débit que de sa brusque décroissance (par élimination totale ou partielle des codes de correction d'erreurs ajoutés), mais il peut également éviter des dégradations au niveau de la réception par compensation des pertes de paquets.
L'apport initial éventuel de codes de correction d'erreurs pour la deuxième entité de flux de données est déterminé sur la base de cette deuxième entité, de préférence en temps réel lors de l'émission. II permet de prendre en compte des risques de congestion dès les premiers instants suivant la commutation vers la deuxième entité et/ou de corriger un niveau de pertes résiduelles. Dans une variante, les codes de correction d'erreurs sont déterminés au préalable, et stockés avec la deuxième entité de flux.
La quantité de cet apport (donnant le niveau de débit additionnel) est avantageusement fixée dynamiquement en fonction de l'état courant 2863130 -9- estimé du réseau (risque de congestion). Dans le cas où les codes de correction d'erreurs associés à la deuxième entité sont enregistrées au préalable avec cette entité, on prévoit alors d'ajuster dynamiquement la quantité de ces codes qui est exploitée pour la commutation. Les entités sont ainsi pourvues de niveaux de plafonnement prédéterminés des codes de correction d'erreurs, qui peuvent être exploités totalement ou partiellement lors des commutations. Dans une variante de réalisation, le niveau de débit additionnel est prédéfini, et peut être identique pour toutes les entités.
La quantité de l'apport initial de codes de correction d'erreurs représente avantageusement entre 1% et 3% de débit additionnel, comparé au débit nominal de la deuxième entité de flux.
Selon un mode de réalisation particulier, l'apport initial de codes de correction d'erreurs est nul. Les moyens de commutation sont alors prévus pour commuter les moyens de branchement lorsque le flux des données transférées augmentées des codes de correction d'erreurs ajoutés atteint le deuxième débit d'émission, et les moyens d'ajout sont prévus pour réinitialiser à zéro l'ajout des codes lors de la commutation.
Préférentiellement, le dispositif comprend des moyens de régulation automatique de débit capables de réduire la quantité des codes ajoutés lors d'une détection de risque de congestion. Ces moyens sont alors avantageusement prévus pour réinitialiser à zéro l'ajout de ces codes lors d'une telle détection.
On peut ainsi aisément parvenir à un comportement TCP-friendly, tout en garantissant une qualité optimale aux clients. La détection d'un risque de congestion peut notamment consister en un constat de pertes de paquets, d'une augmentation du RTT et/ou d'une valeur de débit reçu inférieure à celle du débit envoyé. Il est avantageux de ne redémarrer 2863130 -10ensuite l'ajout des codes de correction d'erreurs qu'après une durée prédéfinie par exemple comprise entre une seconde et trente secondes.
Avantageusement, les moyens de branchement sont prévus pour sélectionner une des entités en fonction d'une consigne de débit modifiable au cours du temps et les moyens d'ajout sont prévus pour être activés lorsque l'entité sélectionnée est associée à un débit d'émission supérieur au débit d'émission d'une autre des entités en cours d'émission. Cette forme de réalisation s'applique notamment pour les techniques simulcast et de hiérarchisation.
Selon un mode particulier de réalisation (technique de hiérarchisation), les moyens d'obtention sont capables d'obtenir au moins une des entités en superposant à une autre des entités au moins une couche de flux de données disponible dans la base de données.
Préférentiellement, les moyens d'ajout sont prévus pour que chaque incrément des codes ajoutés aux données transférées provoque un accroissement du débit d'émission du flux de données augmenté qui soit inférieur à un tiers de la différence entre le deuxième débit d'émission et le premier débit d'émission respectivement associés à la deuxième entité et à la première entité. On réduit ainsi d'au moins un facteur trois les sauts de débits lors des passages entre entités successives.
Selon une réalisation avantageuse, les moyens de commutation sont capables de commuter les moyens de branchement d'une des entités en cours d'émission associée à un débit nominal courant d'émission vers une autre des entités associée à un débit nominal d'émission de repli inférieur au débit nominal courant, lors d'une détection de risque de congestion.
En cas de risque de congestion, on effectue alors de préférence un basculement de l'entité en cours d'émission vers l'autre entité de débit 2863130 -11- nominal inférieur, tout en ajoutant à cette dernière entité de flux un apport initial de codes de correction d'erreurs apte à compenser le taux de perte estimé au moment du basculement. De plus, on fait avantageusement en sorte que le débit total obtenu après basculement (entité de repli avec codes de correction d'erreurs) soit très inférieur au débit précédemment utilisé (entité courante avec codes de correction d'erreurs). On respecte ainsi la contrainte de décroissance multiplicative selon le principe AIMD, tout en réduisant les risques de pertes de données.
L'invention est également relative à un serveur de données, préférentiellement de données vidéo, caractérisé en ce qu'il comprend un dispositif de préparation de données conforme à l'un quelconque des modes de réalisation de l'invention.
Ce serveur est avantageusement prévu pour émettre des 15 données sur un réseau IP, conformément aux protocoles RTP et UDP exploités conjointement.
L'invention a aussi pour objet un procédé de préparation de données à émettre en flux continu vers au moins un récepteur via un réseau 20 de communication, selon lequel: - on obtient ces données en provenance d'une base de données, cette base de données contenant au moins deux entités de flux de données associées respectivement à des débits de transmission différents, en extrayant les données de l'une des entités de flux, - on transfère lesdites données obtenues vers un système d'émission de ces données en flux continu sur le réseau, - et on commute d'une des entités vers une autre des entités pour obtenir ces données.
Selon l'invention: 2863130 -12- - on ajoute régulièrement aux données transférées vers le système d'émission, des codes de correction d'erreurs de façon à former un flux de données augmenté, - on commute d'une première des entités associée à un premier débit d'émission vers une deuxième des entités associée à un deuxième débit d'émission supérieur au premier débit d'émission, lorsque le flux des données transférées augmentées des codes de correction d'erreurs ajoutés atteint un débit de seuil égal à la somme du deuxième débit d'émission et d'un débit additionnel (pouvant être réduit à zéro) associé à un apport initial de codes de correction d'erreurs pour la deuxième entité, et - on réinitialise l'ajout de ces codes à cet apport initial lorsqu'on commute de la première entité vers la deuxième entité.
L'invention s'applique également à un produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon l'invention, lorsque ce programme est exécuté sur un ordinateur. Par produit programme d'ordinateur , on entend un support de programme d'ordinateur, qui peut consister non seulement en un espace de stockage contenant le programme, tel qu'une disquette ou une cassette, mais aussi en un signal, tel qu'un signal électrique ou optique.
L'invention sera mieux comprise et illustrée au moyen des exemples suivants de réalisation et de mise en oeuvre, nullement limitatifs, 25 en référence aux figures annexées sur lesquelles: - la Figure 1 est un schéma de principe d'un ensemble d'émission réception incluant un serveur de données, qui comprend un dispositif de préparation de données conforme à l'invention, des récepteurs, et un réseau de communication entre le serveur et les récepteurs; - la Figure 2 détaille le dispositif de préparation de données de la Figure 1, sous forme de blocs fonctionnels; 2863130 -13- - la Figure 3 représente dans une application particulière de streaming vidéo sur réseau IP par diffusion simulcast, mettant en oeuvre l'invention par ajout progressif de codes FEC, l'évolution en fonction du temps (exprimé en secondes) des débits (en kbits I s) émis par le serveur de la Figure 1 et reçu par l'un des récepteurs de la Figure 1, ainsi que du débit nominal simulcast correspondant aux entités de flux successivement diffusées; - et la Figure 4 représente la variation en fonction du temps (exprimé en secondes) du taux de codes FEC dans le flux émis par le serveur de la Figure 1, pour l'application représentée à la Figure 3.
Sur les Figures 1 et 2, les modules représentés sont des unités fonctionnelles, qui peuvent ou non correspondre à des unités physiquement distinguables. Par exemple, ces modules ou certains d'entre eux peuvent être regroupés dans un unique composant, ou constituer des fonctionnalités d'un même logiciel. A contrario, certains modules peuvent éventuellement être composés d'entités physiques séparées.
Un serveur 10 de données (Figure 1) comprend une base de données 2, un dispositif de préparation de données 1 à émettre par le serveur 10 sous la forme de données DATA complétées et formatées pour diffusion après leur extraction de la base de données 2, et un système d'émission 3 de ces données extraites vers des récepteurs RI, R2... Rn via un réseau de communication 5.
Le serveur 10 est également apte à exploiter des informations de contrôle CTRL reçues en provenance du réseau 5, notamment à partir de signaux envoyés en retour par les récepteurs Ri.
Plus précisément (Figure 2), la base de données 2 contient des entités Ej de flux de données (j = 1-4 dans l'exemple illustré), ces entités Ej 2863130 -14- étant associées à des débits de transmission distincts et étant classées par ordre croissant de débit.
Le dispositif de préparation 1 de données comprend (Figure 2) : - un module d'obtention 11 des données 21 en provenance de la base de données 2; - un module de transfert 12 de ces données 21, complétées et formatées sous la forme des données DATA, vers le système d'émission 3; - un module de branchement 13 du module d'obtention 11 sur une des entités Ej de flux de la base de données 2 (l'entité El dans l'illustration de la Figure 2) ; - un module de commutation 14 du module de branchement 13, d'une des entités vers une autre; par exemple, le module de commutation 14 est apte à faire passer le branchement du module 13 de l'entité courante (El) vers l'entité suivante ayant un débit immédiatement supérieur (E2) ; - un module d'ajout régulier 15 aux données 21 récupérées par le module de transfert 12, de codes FEC référencés 22; les données DATA diffusées intègrent ainsi à la fois les données 21 extraites de la base de données 2 et les codes 22; - et un module de régulation automatique 16 de débit, apte à exploiter les informations de contrôle CTRL pour agir d'une part sur le module d'ajout 15 des codes FEC et d'autre part sur le module de commutation 14; plus précisément, le module de régulation 16 est apte à commander au module d'ajout 15 une réinitialisation à zéro (ou à une valeur minimale) des codes FEC lors d'une détection de risque de congestion; dans une variante de réalisation, le module de régulation 16 provoque seulement une diminution significative de la quantité des codes 22 fournis par le module d'ajout 15, par exemple une division par deux; le module de régulation 16 est aussi apte à commander au module de commutation 14 un branchement du module 13, de l'entité courante vers une entité ayant un débit inférieur en cas de détection de congestion, ou de risque de congestion.
Le module de commutation 14 est prévu pour fonctionner de la manière suivante. Il dispose des débits d'émission nominaux 24 associés aux entités Ej de la base de données 2, et reçoit en provenance du module de transfert 12 le débit d'émission effectif 23 des données DATA. Le débit d'émission effectif 23 est initialement celui de l'entité Ej de flux en cours de diffusion (par exemple El) et est inférieur à celui de l'entité E(j+1) suivante (ici, E2). Il croît à mesure de l'ajout des codes FEC. Le module de commutation 14 compare alors régulièrement les deux débits 23 et 24, et lorsque le débit effectif 23 atteint le débit nominal associé à l'entité E(j+1) suivante, il déclenche une commutation du module de branchement 13 vers cette dernière entité.
De plus, le module de branchement 13 est prévu pour recevoir une consigne de débit 25 modifiable au cours du temps, qui dépend de la disponibilité en bande passante pour diffusion vers le réseau 5. Le module de branchement 13 sélectionne alors une des entités Ej en fonction de cette consigne 25, en choisissant l'entité Ej ayant un débit nominalimmédiatement inférieur à la valeur de cette consigne 25. Cette sélection ne vaut cependant pas branchement sur l'entité choisie, mais conditionne l'activation du module d'ajout 15 de codes, lorsque l'entité sélectionnée est associée à un débit d'émission nominal supérieur au débit nominal de l'entité en cours de diffusion.
Par exemple, l'entité en cours de diffusion est El et la consigne de débit 25 est comprise entre les débits nominaux 24 associés respectivement aux entités de flux E3 et E4. Dans ce cas, l'entité sélectionnée par le module de branchement est E3, et l'ajout des codes FEC est déclenché dans le module d'ajout 15.
Cette fonctionnalité permet d'améliorer les passages d'une entité 30 Ej de flux à une autre, en évitant de déclencher inutilement l'ajout des codes 22.
2863130 -16- Dans un premier mode de réalisation, les entités Ej correspondent à des flux simulcast.
Dans un deuxième mode de réalisation, ils correspondent à des flux obtenus par hiérarchisation, en superposant des couches successives.
Dans ce cas, l'entité El correspond à la couche de base, et les entités E2 à E4 comprennent respectivement 1 à 3 couches d'amélioration additionnelles. En pratique, les flux ne sont alors pas préformés dans la base de données 2, mais construits lors de l'extraction des données 21, par superposition des couches appropriées.
Des résultats de tests effectués par simulation permettent de mieux appréhender l'intérêt et l'efficacité du dispositif de préparation 1 décrit plus haut. Selon ces tests, on pratique une régulation pour flux multimédia audio et/ou vidéo, par streaming sur réseau IP (le réseau 5). On combine la méthode de diffusion simulcast avec un ajout progressif des codes FEC (module d'ajout 15), en l'occurrence sous forme de codes de Reed-Solomon, en suivant les recommandations AIMD pour l'incrémentation du débit d'émission. Pour les tests, on choisit quatre flux simulcast (entités E1-E4) codés respectivement aux débits 256, 415, 615 et 800 kbits/s, et une bande passante limitée à 760 kbits/s.
On obtient ainsi (Figure 3) une variation en fonction du temps (axe 31) du débit de transmission des données (axe 32) pour le flux émis par le serveur 10 (courbe 41), le flux reçu par l'un des récepteurs Ri (courbe 42) et la valeur nominale pour l'entité de flux en cours de diffusion (courbe 43). On dispose également (Figure 4, courbe 44) de l'évolution dans le temps (axe 31) du taux de codes FEC ajoutés (axe 33).
Ainsi, partant de la première entité de flux (256 kbitsls), on augmente progressivement le taux de codes FEC tant qu'aucune perte n'est détectée (entre 0 et environ 11,5 s), puis on bascule vers la deuxième entité de flux (415 kbits/s). On procède de même pour passer de la deuxième à la troisième entité (615 kbits/s, entre environ 11,5 et 19 s).
On continue ensuite d'augmenter régulièrement le taux de FEC, mais dès qu'un risque de congestion est détecté, on réinitialise à zéro l'ajout des codes FEC. Cette détection est obtenue par le constat d'augmentation du paramètre RTT et d'un débit d'émission supérieur au débit reçu (ce qui correspond à un remplissage des mémoires FIFO des routeurs présageant l'apparition d'une congestion). Ces opérations de réinitialisation sont effectuées aux alentours de 24, 28 et 36 s: les tentatives d'augmentation de débit avortent toutes car la bande passante disponible (760 kbitsls) est inférieure au débit du quatrième flux (800 kbitsls). Le processus d'ajout de codes FEC est à chaque interruption, repris ultérieurement, 1 seconde plus tard (donc aux alentours de 25, 29 et 37 s).
Ainsi qu'il apparaît, le débit augmente progressivement, de manière beaucoup plus douce que si on passait directement d'une entité de flux à une autre. De plus, même si des pertes apparaissent au niveau des instants 24, 28 et 35 s, le taux de codes FEC est tel à ce moment-là qu'elles sont automatiquement corrigées.
2863130 -18-
Claims (11)
1. Dispositif de préparation (1) de données (21) à émettre en flux 5 continu vers au moins un récepteur (Ri) via un réseau de communication (5) , ledit dispositif (1) comprenant: - des moyens d'obtention (11) desdites données (21) en provenance d'une base de données (2), ladite base de données (2) contenant au moins deux entités (Ej) de flux de données associées respectivement à des débits de transmission (24) différents, des moyens de transfert (12) desdites données obtenues vers un système d'émission (3) desdites données en flux continu sur ledit réseau (5), des moyens de branchement (13) desdits moyens d'obtention (11) sur une desdites entités de flux (Ej) de la base de données (2), - et des moyens de commutation (14) des moyens de branchement (13) d'une desdites entités vers une autre desdites entités, caractérisé en ce que: - ledit dispositif de préparation (1) comprend des moyens d'ajout régulier (15) aux dites données (21) transférées vers le système d'émission (3), de codes de correction d'erreurs (22) de façon à former un flux de données augmenté (DATA), - lesdits moyens de commutation (14) étant prévus pour commuter les moyens de branchement (13) d'une première desdites entités (El) associée à un premier débit d'émission vers une deuxième desdites entités (E2) associée à un deuxième débit d'émission supérieur audit premier débit d'émission, lorsque le flux (DATA) desdites données (21) transférées augmentées desdits codes de correction d'erreurs (22) ajoutés atteint un débit de seuil égal à la somme du deuxième débit d'émission et d'un débit additionnel associé à un apport initial de codes de correction d'erreurs pour ladite deuxième entité (E2), et 2863130 -19- - lesdits moyens d'ajout (15) étant prévus pour réinitialiser à zéro l'ajout desdits codes (22) audit apport initial lors de la commutation de ladite première entité (El) vers ladite deuxième entité (E2).
2. Dispositif de préparation (1) selon la revendication 1, caractérisé en ce qu'il comprend des moyens de régulation automatique (16) de débit capables de réduire la quantité desdits codes ajoutés (22) lors d'une détection de risque de congestion.
3. Dispositif de préparation (1) selon la revendication 2, caractérisé en ce que lesdits moyens de régulation automatique (16) de débit sont prévus pour réinitialiser à zéro l'ajout desdits codes (22) lors d'une détection de risque de congestion.
4. Dispositif de préparation (1) selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens de branchement (13) sont prévus pour sélectionner une desdites entités (Ej) en fonction d'une consigne de débit (25) modifiable au cours du temps et en ce que lesdits moyens d'ajout (15) sont prévus pour être activés lorsque ladite entité sélectionnée est associée à un débit d'émission supérieur au débit d'émission d'une autre desdites entités en cours d'émission.
5. Dispositif de préparation (1) selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens d'obtention (11) sont capables d'obtenir au moins une desdites entités (Ej) en superposant à une autre desdites entités au moins une couche de flux de données disponible dans la base de données (2).
6. Dispositif de préparation (1) selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens d'ajout (15) sont prévus pour que chaque incrément desdits codes (22) ajoutés aux données transférées (21) provoque un accroissement du débit d'émission -202863130 dudit flux de données augmenté (DATA) qui soit inférieur à un tiers de la différence entre le deuxième débit d'émission et le premier débit d'émission respectivement associés à la deuxième entité (E2) et à la première entité (E 1).
7. Dispositif de préparation (1) selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits moyens de commutation (14) sont capables de commuter les moyens de branchement (13) d'une des entités en cours d'émission associée à un débit nominal courant d'émission vers une autre des entités associée à un débit nominal d'émission de repli inférieur au débit nominal courant, lors d'une détection de risque de congestion.
8. Serveur (10) de données, préférentiellement de données vidéo, 15 caractérisé en ce qu'il comprend un dispositif de préparation (1) de données conforme à l'une quelconque des revendications 1 à 7.
9. Serveur (10) de données selon la revendication 8, caractérisé en ce qu'il est prévu pour émettre des données sur un réseau IP, 20 conformément aux protocoles RTP et UDP exploités conjointement.
10. Procédé de préparation de données (21) à émettre en flux continu vers au moins un récepteur (Ri) via un réseau de communication (5), selon lequel: - on obtient lesdites données (21) en provenance d'une base de données (2) , ladite base de données (2) contenant au moins deux entités (Ej) de flux de données associées respectivement à des débits de transmission (24) différents, en extrayant lesdites données (21) de l'une desdites entités (Ej) de flux, - on transfère lesdites données (21) obtenues vers un système d'émission (3) desdites données en flux continu sur ledit réseau (5), 2863130 -21- - et on commute d'une desdites entités vers une autre desdites entités pour obtenir lesdites données (21), caractérisé en ce que: - on ajoute régulièrement aux dites données (21) transférées vers le système d'émission (3), des codes de correction d'erreurs (22) de façon à former un flux de données augmenté (DATA), - on commute d'une première desdites entités (El) associée à un premier débit d'émission vers une deuxième desdites entités (E2) associée à un deuxième débit d'émission supérieur au premier débit d'émission, lorsque le flux (DATA) desdites données (21) transférées augmentées desdits codes de correction d'erreurs (22) ajoutés atteint un débit de seuil égal à la somme du deuxième débit d'émission et d'un débit additionnel associé à un apport initial de codes de correction d'erreurs pour ladite deuxième entité (E2), et - on réinitialise l'ajout desdits codes (22) audit apport initial lorsqu'on commute de ladite première entité (El) vers ladite deuxième entité (E2), ledit procédé de préparation étant préférentiellement prévu pour être mis en oeuvre au moyen d'un dispositif de préparation (1) de données (21) à émettre conforme l'une quelconque des revendications 1 à 7.
11. Produit programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé selon la revendication 10, lorsque ledit programme est exécuté sur un ordinateur.
Priority Applications (11)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0314076A FR2863130A1 (fr) | 2003-12-01 | 2003-12-01 | Dispositif et procede de preparation de donnees d'emission et produits correspondants |
| BRPI0416896-8A BRPI0416896B1 (pt) | 2003-12-01 | 2004-11-26 | Dispositivo e método para a preparação de envio de dados e produtos correspondentes |
| JP2006540466A JP4748729B2 (ja) | 2003-12-01 | 2004-11-26 | データおよび対応するプロダクトを送信する準備のための装置と方法 |
| KR1020067010495A KR101126118B1 (ko) | 2003-12-01 | 2004-11-26 | 전송될 데이터의 준비를 위한 디바이스 및 방법과 대응하는 데이터 서버 |
| EP04816333A EP1698148B1 (fr) | 2003-12-01 | 2004-11-26 | Dispositif et procede de preparation d'envoi de donnees et produits correspondants |
| CA2546984A CA2546984C (fr) | 2003-12-01 | 2004-11-26 | Dispositif et procede de preparation d'envoi de donnees et produits correspondants |
| PCT/EP2004/053143 WO2005055553A2 (fr) | 2003-12-01 | 2004-11-26 | Dispositif et procede de preparation d'envoi de donnees et produits correspondants |
| CN2004800355427A CN1886968B (zh) | 2003-12-01 | 2004-11-26 | 用于准备发送数据的设备和方法以及相应的产品 |
| DE602004026109T DE602004026109D1 (de) | 2003-12-01 | 2004-11-26 | Einrichtung und verfahren zur vorbereitung des sendens von daten und entsrechende produkte |
| US10/580,943 US7711839B2 (en) | 2003-12-01 | 2004-11-26 | Device and method for the preparation of sending data and corresponding products |
| MXPA06006177A MXPA06006177A (es) | 2003-12-01 | 2004-11-26 | Dispositivo y metodo para la preparacion de envio de datos y productos correspondientes. |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0314076A FR2863130A1 (fr) | 2003-12-01 | 2003-12-01 | Dispositif et procede de preparation de donnees d'emission et produits correspondants |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2863130A1 true FR2863130A1 (fr) | 2005-06-03 |
Family
ID=34566274
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0314076A Withdrawn FR2863130A1 (fr) | 2003-12-01 | 2003-12-01 | Dispositif et procede de preparation de donnees d'emission et produits correspondants |
Country Status (11)
| Country | Link |
|---|---|
| US (1) | US7711839B2 (fr) |
| EP (1) | EP1698148B1 (fr) |
| JP (1) | JP4748729B2 (fr) |
| KR (1) | KR101126118B1 (fr) |
| CN (1) | CN1886968B (fr) |
| BR (1) | BRPI0416896B1 (fr) |
| CA (1) | CA2546984C (fr) |
| DE (1) | DE602004026109D1 (fr) |
| FR (1) | FR2863130A1 (fr) |
| MX (1) | MXPA06006177A (fr) |
| WO (1) | WO2005055553A2 (fr) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8296778B2 (en) | 2006-06-27 | 2012-10-23 | International Business Machines Corporation | Computer data communications in a high speed, low latency data communications environment |
| US20070299936A1 (en) * | 2006-06-27 | 2007-12-27 | Borgendale Kenneth W | Interactively streaming data from a database in a high speed, low latency data communications environment |
| US8122144B2 (en) | 2006-06-27 | 2012-02-21 | International Business Machines Corporation | Reliable messaging using redundant message streams in a high speed, low latency data communications environment |
| US20070300234A1 (en) * | 2006-06-27 | 2007-12-27 | Eliezer Dekel | Selecting application messages from an active feed adapter and a backup feed adapter for application-level data processing in a high speed, low latency data communications environment |
| US8676876B2 (en) * | 2006-06-27 | 2014-03-18 | International Business Machines Corporation | Synchronizing an active feed adapter and a backup feed adapter in a high speed, low latency data communications environment |
| US10051238B2 (en) * | 2006-09-18 | 2018-08-14 | Imagine Communications Corp. | Bandwidth based licensing scheme for video, audio and/or multimedia content |
| US20080114938A1 (en) * | 2006-11-14 | 2008-05-15 | Borgendale Kenneth W | Application Message Caching In A Feed Adapter |
| US8695015B2 (en) * | 2006-12-06 | 2014-04-08 | International Business Machines Corporation | Application message conversion using a feed adapter |
| US20080140550A1 (en) * | 2006-12-07 | 2008-06-12 | Berezuk John F | Generating a global system configuration for a financial market data system |
| US20080141273A1 (en) * | 2006-12-11 | 2008-06-12 | Borgendale Kenneth W | Accessing Application Message Data In A Messaging Environment |
| US20080137830A1 (en) * | 2006-12-12 | 2008-06-12 | Bhogal Kulvir S | Dispatching A Message Request To A Service Provider In A Messaging Environment |
| US8327381B2 (en) * | 2006-12-12 | 2012-12-04 | International Business Machines Corporation | Referencing message elements in an application message in a messaging environment |
| US8850451B2 (en) | 2006-12-12 | 2014-09-30 | International Business Machines Corporation | Subscribing for application messages in a multicast messaging environment |
| JP2008172515A (ja) * | 2007-01-11 | 2008-07-24 | Sony Corp | 送信装置および方法、通信装置、並びにプログラム |
| US7917912B2 (en) * | 2007-03-27 | 2011-03-29 | International Business Machines Corporation | Filtering application messages in a high speed, low latency data communications environment |
| US20090006560A1 (en) * | 2007-06-27 | 2009-01-01 | Bhogal Kulvir S | Terminating An Application Message Subscription |
| US20090006559A1 (en) * | 2007-06-27 | 2009-01-01 | Bhogal Kulvir S | Application Message Subscription Tracking In A High Speed, Low Latency Data Communications Environment |
| AU2007237313A1 (en) * | 2007-12-03 | 2009-06-18 | Canon Kabushiki Kaisha | Improvement for error correction in distributed vdeo coding |
| AU2007242924A1 (en) * | 2007-12-12 | 2009-07-02 | Canon Kabushiki Kaisha | Improvement for error correction in distributed video coding |
| CN101860895B (zh) * | 2010-06-11 | 2012-12-19 | 上海海维工业控制有限公司 | 一种改进的aimd拥塞控制方法 |
| US8683480B2 (en) | 2011-06-01 | 2014-03-25 | International Business Machines Corporation | Resource allocation for a plurality of resources for a dual activity system |
| US9781488B2 (en) * | 2015-07-30 | 2017-10-03 | Adi Rozenberg | Controlled adaptive rate switching system and method for media streaming over IP networks |
| CN110300315B (zh) | 2019-07-24 | 2021-08-13 | 北京达佳互联信息技术有限公司 | 一种视频码率确定方法、装置、电子设备及存储介质 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1154190A (zh) * | 1995-05-09 | 1997-07-09 | 诺基亚电信公司 | 数字通信系统中的非透明数据发送 |
| US5699365A (en) * | 1996-03-27 | 1997-12-16 | Motorola, Inc. | Apparatus and method for adaptive forward error correction in data communications |
| JP2001045098A (ja) * | 1999-05-26 | 2001-02-16 | Canon Inc | データ通信システム、データ通信装置、データ通信方法及び記憶媒体 |
| US6519461B1 (en) * | 1999-10-29 | 2003-02-11 | Telefonaktiebolaget Lm Ericsson (Publ) | Channel-type switching from a common channel to a dedicated channel based on common channel load |
| EP1253736A3 (fr) * | 2001-04-26 | 2003-12-10 | NTT DoCoMo, Inc. | Commande de liaison de données pour communications mobiles |
| US6789123B2 (en) | 2001-12-28 | 2004-09-07 | Microsoft Corporation | System and method for delivery of dynamically scalable audio/video content over a network |
| EP1359722A1 (fr) * | 2002-03-27 | 2003-11-05 | BRITISH TELECOMMUNICATIONS public limited company | Système et procédé pour transmettre des flux de données |
| KR20030095995A (ko) | 2002-06-14 | 2003-12-24 | 마츠시타 덴끼 산교 가부시키가이샤 | 미디어 전송방법 및 그 송신장치 및 수신장치 |
| US7571246B2 (en) * | 2004-07-29 | 2009-08-04 | Microsoft Corporation | Media transrating over a bandwidth-limited network |
-
2003
- 2003-12-01 FR FR0314076A patent/FR2863130A1/fr not_active Withdrawn
-
2004
- 2004-11-26 CN CN2004800355427A patent/CN1886968B/zh not_active Expired - Fee Related
- 2004-11-26 JP JP2006540466A patent/JP4748729B2/ja not_active Expired - Fee Related
- 2004-11-26 WO PCT/EP2004/053143 patent/WO2005055553A2/fr not_active Application Discontinuation
- 2004-11-26 CA CA2546984A patent/CA2546984C/fr not_active Expired - Fee Related
- 2004-11-26 EP EP04816333A patent/EP1698148B1/fr not_active Expired - Lifetime
- 2004-11-26 DE DE602004026109T patent/DE602004026109D1/de not_active Expired - Lifetime
- 2004-11-26 MX MXPA06006177A patent/MXPA06006177A/es active IP Right Grant
- 2004-11-26 KR KR1020067010495A patent/KR101126118B1/ko not_active Expired - Fee Related
- 2004-11-26 US US10/580,943 patent/US7711839B2/en active Active
- 2004-11-26 BR BRPI0416896-8A patent/BRPI0416896B1/pt active IP Right Grant
Non-Patent Citations (2)
| Title |
|---|
| MOHR A E ET AL: "Generalized multiple description coding through unequal loss protection", IMAGE PROCESSING, 1999. ICIP 99. PROCEEDINGS. 1999 INTERNATIONAL CONFERENCE ON KOBE, JAPAN 24-28 OCT. 1999, PISCATAWAY, NJ, USA,IEEE, US, 24 October 1999 (1999-10-24), pages 411 - 415, XP010369146, ISBN: 0-7803-5467-2 * |
| PURI R ET AL: "Forward error correction (FEC) codes based multiple description coding for internet video streaming and multicast", SIGNAL PROCESSING. IMAGE COMMUNICATION, ELSEVIER SCIENCE PUBLISHERS, AMSTERDAM, NL, vol. 16, no. 8, May 2001 (2001-05-01), pages 745 - 762, XP004249804, ISSN: 0923-5965 * |
Also Published As
| Publication number | Publication date |
|---|---|
| KR20060123212A (ko) | 2006-12-01 |
| CA2546984A1 (fr) | 2005-06-16 |
| BRPI0416896B1 (pt) | 2018-04-24 |
| US7711839B2 (en) | 2010-05-04 |
| WO2005055553A2 (fr) | 2005-06-16 |
| EP1698148B1 (fr) | 2010-03-17 |
| US20070106813A1 (en) | 2007-05-10 |
| DE602004026109D1 (de) | 2010-04-29 |
| KR101126118B1 (ko) | 2012-03-29 |
| JP2007516669A (ja) | 2007-06-21 |
| EP1698148A2 (fr) | 2006-09-06 |
| BRPI0416896A (pt) | 2007-03-06 |
| CA2546984C (fr) | 2013-05-14 |
| WO2005055553A3 (fr) | 2005-09-15 |
| MXPA06006177A (es) | 2006-08-25 |
| JP4748729B2 (ja) | 2011-08-17 |
| CN1886968A (zh) | 2006-12-27 |
| CN1886968B (zh) | 2010-04-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| FR2863130A1 (fr) | Dispositif et procede de preparation de donnees d'emission et produits correspondants | |
| US11032344B2 (en) | Content delivery | |
| US7752327B2 (en) | Receiver driven streaming in a peer-to-peer network | |
| JP6072276B2 (ja) | マルチメディアデータの処理 | |
| US10812559B2 (en) | Just-in-time variable adaptive encoding and delivery of media content | |
| US7664109B2 (en) | System and method for distributed streaming of scalable media | |
| CN1324851C (zh) | 适用于动态网络丢失条件的数据通信方法 | |
| US20100274920A1 (en) | Adjustment of Transmission Data Rate Based on Data Errors and/or Latency | |
| KR20060050266A (ko) | 피어-투-피어 네트워크에서의 수신자 구동형 스트리밍을위한 시스템 및 방법 | |
| EP3238406B1 (fr) | Procédé de traitement d'une requête de livraison de données | |
| Bruneau-Queyreix et al. | MS-Stream: A multiple-source adaptive streaming solution enhancing consumer's perceived quality | |
| Abdullah et al. | Survey of transportation of adaptive multimedia streaming service in internet | |
| EP2075960B1 (fr) | Système et procédé d'adaptation des flux de contenu vidéo à la variabilité des conditions de transmission d'un réseau radiotéléphonique et à la dynamique du contenu de la source vidéo | |
| EP4468686A1 (fr) | Basculement optimisé depuis un serveur de contenu unicast vers un serveur de contenu multicast | |
| Schierl et al. | Improving P2P live-content delivery using SVC | |
| FR2980936A1 (fr) | Technique de distribution d'un contenu dans un reseau de communication | |
| FR2926177A1 (fr) | Procede et disositif de transmission de donnees avec partage specifique des ressources de debit d'un reseau. | |
| Purkayastha et al. | Enhanced Streaming services in 3GPP systems | |
| FR2905221A1 (fr) | Procede et systemes pour optimiser la transmission d'un flux de donnees. | |
| EP2087733A1 (fr) | Procédé de retardement temporel de flux de contenus numériques, dispositif, et produit programme d'ordinateur correspondants |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| ST | Notification of lapse |