Brevet FR2863130A1 — publié le 20050603

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- REVENDICATIONS 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.