Brevet FR2828053A1 — publié le 20030131

La présente invention concerne les transmissions de données par l'intermédiaire d'un réseau numérique. Plus précisément, l'invention concerne un procédé de stabilisation de flux de données audio et/ou vidéo transitant par l'intermédiaire d'un réseau numérique, tel que le réseau Internet. Les réseaux numériques sont couramment utilisés pour acheminer des données audio et/ou vidéo (on précise que dans la suite de ce texte les données audio et/ou vidéo seront désignées par le terme général de données audio/vidéo). On peut ainsi de manière connue connecter un ordinateur (ou tout autre type de terminal) pour récupérer de telles données provenant d'un système émetteur relié au réseau, les données transitant du système émetteur à l'ordinateur par un système serveur également relié au réseau. L'ordinateur constitue un système client par rapport au système serveur (d'autres systèmes clients pouvant par ailleurs être connectés au système serveur pour récupérer de la même manière des données audio/vidéo-dans ce cas le système serveur distribue aux différents systèmes clients qui lui sont connectés les données audio/vidéo). Les données audio/vidéo transitent généralement sous forme compressée, des moyens de décompression adéquats étant prévus dans les systèmes clients pour restituer aux utilisateurs finaux ces données dans leur intégralité. On précise que d'un point de vue pratique l'acheminement des données audio/vidéo du système émetteur vers le système client peut en outre être combiné avec le transfert d'autres types de données vers le système client, lesdites données des autres types correspondant à des applications spécifiques du système client (par exemple données de discussions électronique en ligne- chat selon la terminologie anglosaxonne-, ou données graphiques permettant d'échanger des pages de présentation pour une application telle que powerpoint (marque déposée), etc..). Dans le cas spécifique mentionné ci-dessus et mettant en oeuvre le transfert de plusieurs types de données vers le système client, on dit que chaque type de données respectif correspond à un sous-système . Il est ainsi envisageable de concevoir une plate-forme d'échanges multimédia à partir d'un système client, mettant en oeuvre un sous-système pour les données audio/vidéo, un sous-système pour la discussion électronique en ligne, un sous-système pour échanger des images ou des présentations,...). On précise toutefois que si le cadre de l'invention peut être élargi à de telles plates-forme multimédia, l'objet de l'invention concerne comme on va le voir essentiellement les données audio/vidéo. La stabilité du flux de ces données audio/vidéo est très importante, dans la mesure ou des variations de débit de ces données perturbent leur réception par les systèmes clients reliés au système serveur. Or, le fonctionnement des réseaux numériques (et en particulier du réseau Internet) ne garantit pas toujours une stabilité suffisante du flux de ces données. De plus, dans le cas des ordinateurs reliés au réseau Internet, la connection de l'ordinateur au réseau se fait souvent par l'intermédiaire d'un modem analogique du système client. Et on a observé qu'une telle connection provoquait des variations de débit supplémentaires. Les variations de débit se traduisent par des perturbations telles qu'une image saccadée et des coupures de son. Ceci constitue un inconvénient qui peut s'avérer inacceptable, par exemple dans le cas d'utilisateurs désirant écouter et/ou voir des données audio/vidéo en temps réel (exemple d'utilisateurs mettant en oeuvre des ordinateurs pour des applications de téléconférence en temps réel, ou toute autre application interactive). Pour tenter de pallier à cet inconvénient, il est connu de prévoir comme représenté sur la figure 1 un tampon de données audio/vidéo, en aval du point d'entrée de ces données sur le système client (en l'occurrence, l'ordinateur de l'utilisateur). Sur cette figure sont représentées la séquence des opérations effectuées par un système client qui reçoit de manière connue des données audio/vidéo (par exemple d'un système serveur). Le système client reçoit tout d'abord en 10 un ordre de réception d'un flux de données. Cette étape correspond à une ouverture de session de transfert de données ; elle comprend la définition d'une bande passante (qui pendant toute la session sera allouée au transfert que des informations audio/vidéo transitent effectivement vers le système client ou non). L'ordre de réception de flux de données provient du système émetteur. Ce système émetteur est également apte à envoyer en fin de session un signal de fin de communication informant le destinataire (i. e. le système client en l'occurrence) que la session va se terminer. Une fois l'ordre de réception de données reçu, le système client exécute continuellement pendant toute la session la séquence 11 des étapes 111 à 113 : En 111, réception des données compressées, . En 112, stockage des données compressées reçues en 111 dans un tampon de données audio/vidéo. Ce tampon est un tampon temps réel, c'est à dire que les données en sortent en même temps qu'elles y rentrent, sans limitation de débit (le débit ayant été fixé par la bande passante définie en 10), . En 113, décompression et restitution des données à l'utilisateur destinataire (par l'intermédiaire d'une interface dédiée de l'ordinateur). Le système client emmagasine ainsi une certaine quantité de données avant de les décompresser et de les restituer ; le tampon joue le rôle d'un réservoir de données correspondant à une durée prédéfinie de restitution de données-on appelle cette durée la durée tampon . En cas de perturbation très courte du débit de données parvenant au système client, une partie du contenu du tampon peut ainsi être décompressée et restituée pendant que la perturbation se termine. Cette solution connue permet en cas de perturbation de débit d'assurer la continuité du flux des données restituées à l'utilisateur, pendant une durée limitée correspondant au maximum à la durée de restitution des données contenues dans le tampon ( durée tampon ). En effet, pendant une perturbation qui entraîne une diminution ou une annulation du débit d'entrée des données dans le système client, le tampon se vide de manière à maintenir le débit de données vers les moyens de décompression et de restitution du système client à sa valeur nominale. Cependant, une telle solution n'apporte qu'une réponse très imparfaite au problème des perturbations de débit. En effet, la durée limitée mentionnée ci-dessus est généralement très réduite (de l'ordre de quelques centaines de millisecondes-cette durée étant particulièrement réduite pour les applications temps réel), de sorte qu'en cas de perturbation persistante dont la durée excède la durée limitée mentionnée ci-dessus la transmission des données est purement et simplement interrompue. Et normalement, la perturbation de débit se terminera suite à la mise en oeuvre de moyens de régulation de débit du réseau, sur lesquels les systèmes clients n'ont pas de contrôle : les coupures et autres inconvénients résultant d'un tampon vidé de ses données sont ainsi une situation totalement subie par les systèmes clients. Le but de l'invention est de permettre d'améliorer cette situation. Afin d'atteindre ce but, l'invention propose un procédé de stabilisation d'un flux de données audio/vidéo transmises par un système émetteur à un système client par l'intermédiaire d'un système serveur, le procédé comprenant la constitution d'un tampon temps réel de données entre la réception des données compressées et la restitution de ces données à un utilisateur, caractérisé en ce que le procédé comprend : * la surveillance des débits d'entrée et de sortie de données du tampon, . la comparaison entre lesdits débits d'entrée et de sortie, et l'émission par le système client d'une demande de réacheminement de données dès que la différence entre lesdits débits d'entrée et de sortie dépasse une valeur prédéterminée. Des aspects préférés, mais non limitatifs du procédé selon l'invention sont les suivants : . ladite surveillance et ladite comparaison sont réalisés continuellement, * ladite surveillance et ladite comparaison sont effectués selon une fréquence de prélèvement de paquets de données, * ladite fréquence de prélèvement est de l'ordre de 100 prélèvements par seconde, * l'émission de demande de réacheminement est répétée en cas d'échec, pendant un délai donné, édit déliai donné correspond à la durée tampon associée au tampon, . le procédé comprend une tentative de reconnection du système client au système serveur, en cas de débit sortant du tampon nul, . en cas de réception par le système client d'un ordre concernant un sous-système autre que les données audio/vidéo, le système client procède à une demande de reconnection au système serveur pour le transfert des données audio/vidéo. D'autres aspects, buts et avantages de l'invention apparaîtront mieux à la lecture suivante d'une forme de réalisation de l'invention, faite en référence à la figure 2 qui représente la séquence des opérations effectuées par un système client qui reçoit selon l'invention des données audio/vidéo. Sur cette figure, on retrouve les étapes 10, ainsi que la séquence 11 des étapes 111, 112, 113 déjà exposées en référence à l'état de la technique. Dans le cas de l'invention, une autre séquence, notée 20, est réalisée continuellement à partir des flux de données qui entrent et sortent du tampon juste avant et juste après l'étape 112. Les opérations de cette séquence 20 sont réalisées sur des paquets de données audio/vidéo de ces deux flux respectifs, prélevés à intervalles réguliers. La fréquence de prélèvement de ces paquets de données pour leur traitement (traitement qui sera exposé ci-dessous) peut être de l'ordre de 100 fois par seconde-cette fréquence étant également celle à laquelle sont réalisées les étapes de la séquence 20. La séquence 20 comporte ainsi les étapes suivantes, dont certaines se déroulent en parallèle : En 201, on vérifie tout d'abord que le débit sortant du tampon n'est pas nul. Cette vérification, ainsi que l'ensemble des opérations réalisées dans le procédé selon t'invention, peut être effectuée par un ou plusieurs programme (s) réalisé (s) à cet effet. On précise que même dans le cas où aucune image et aucun son n'est acheminé en dehors du tampon, le débit sortant de ce tampon n'est normalement pas nul si un transfert de données audio/vidéo est en cours. En effet, lors d'un tel transfert, des données sont envoyées, permettant de différencier un simple silence (des données sont envoyées) d'une rupture de communication (aucune donnée n'est envoyée). On précise également qu'il est possible de définir a priori une limite en-dessous de laquelle le débit est considéré comme nul. Si le débit sortant du tampon n'est pas nul, on stocke en 202 sa valeur dans une zone de mémoire vive. Par ailleurs, on stocke également en 203 la valeur du débit entrant dans le tampon. Cette opération est effectuée en parallèle des étapes 201 et 202. En 204, on compare ensuite les deux débits (entrant et sortant du tampon) entre eux et on vérifie qu'ils satisfont une relation prédéterminée. Typiquement cette relation est que la différence entre le débit entrant et le débit sortant reste inférieure à une valeur prédéterminée. Cette valeur prédéterminée peut être par exemple 10 paquets de données pour une seconde d'échantillonnage (durant la seconde écoulée, pendant laquelle on a prélevé en entrée et en sortie de tampon 100 paquets de données audio/vidéo et pendant laquelle 100 paquets de données ont normalement été identifiés en sortie de tampon, on a identifié au moins 90 paquets de données en entrée de tampon). Si la relation prédéterminée est satisfaite, on ne procède à aucune opération et le processus s'arrête. Si la relation n'est pas satisfaite, en 21 le système client effectue automatiquement une demande de réacheminement. L'ordre de réacheminement est envoyé par le système client au système serveur. Les paquets audio/vidéo étant par ailleurs identifiés de manière connue par le protocole de transmission des données audio/vidéo utilisé (numéro unique d'identification donné au premier paquet audio/vidéo, chaque paquet suivant ayant un numéro individuel généré séquentiellement à la suite de ce premier numéro), les numéros des paquets perdus sont envoyés par le système client au système serveur. On précise que le protocole de transmission des données audio/vidéo utilisé peut être de tout type connu en soi, par exemple le protocole MMS (marque déposée-MMS étant un acronyme qui correspond à Multimedia Streaming). Il est ensuite procédé lors de l'étape 22 à la vérification que cette demande de réacheminement a bien permis de rétablir le débit d'entrée. Plus précisément, si le système client reçoit les paquets demandés avec les numéros d'identification demandés dans un délai dit de time out prédéterminé choisi, c'est que la demande a abouti. La valeur dudit délai de time out peut être de 300 millisecondes par exemple-ce qui dans le cas d'une transmission à 100 paquets de données par seconde correspond à la transmission de 30 paquets. Ainsi, si dans ledit délai de time out les paquets demandés sont récupérés par le système client, lesdits paquets sont automatiquement insérés dans le tampon dans leur position normale, en fonction des numéros de paquets (d'autres paquets ayant pu pendant ladite récupération arriver dans le tampon du système client avec des numéros d'identification ultérieurs aux numéros des paquets récupérés). Si au bout de la durée de time out, aucune réponse n'est parvenue, c'est que la demande de réacheminement a échoué. Dans ce cas, le système client génèrera des demandes de réacheminement successives pour les mêmes paquets de données, chacune avec un délai de time out associé, jusqu'à ce que les données concernées soient récupérées (étape 23). Toutefois, lorsque la durée totale des time out associés aux différentes demandes de réacheminement pour les mêmes paquets de données atteint la durée tampon, de sorte que les paquets manquants devraient se trouver en situation d'être décompressés et restitués en sortie de tampon, le processus se termine en 24 sans que la communication ait été rétablie. Dans le cas où au contraire les paquets manquants ont été récupérés en temps voulu, le débit de données audio/vidéo vers le système client est pendant une période transitoire égal à la somme du débit nominal qui a été défini en début de session, et d'un débit supplémentaire correspondant aux paquets manquants réémis. Si la demande de réacheminement a abouti (les paquets demandés ont bien été retransmis par le système serveur au système client), la communication est rétablie et la séquence 11 reprend. De même, si une des demandes de réacheminement effectuées en 23 aboutit, la séquence 11 reprend. Par ailleurs, si le système client a déterminé en 201 que le débit sortant du tampon était nul (ou considéré comme nul en référence à une valeur de seuil donnée), ledit système client effectue en 25 une tentative de reconnection au système serveur. On précise que la différence entre une demande de réacheminement et une tentative de reconnection est que dans le premier cas, la demande n'est considérée comme ayant abouti que si les paquets de données manquants sont effectivement réacheminés et récupérés par le système client ; dans le deuxième cas le système client ne demande plus les paquets manquants, mais se comporte comme un nouveau système client qui demande une nouvelle connection au système serveur. De la même manière que pour une demande de réacheminement, les étapes 22 à 24 s'appliquent cependant ensuite, comme représenté sur la figure 2. Enfin, dans le cas où le système client reçoit un ordre concernant un sous-système différent des données audio/vidéo (étape 26), le système client procède automatiquement en 21 à une demande de reconnection pour rétablir la connection avec le système serveur en ce qui concerne le transfert des données audiolvidéo. Cette disposition est intéressante dans le cadre d'une exploitation de l'invention avec une plate-forme de communication multimédia telle qu'évoquée en préambule de cette demande (mise en oeuvre du transfert en parallèle de données de types différentes, correspondant chacun à un sous-système respectif). En effet, dans ce cas la réception d'un ordre concernant un soussystème quelconque déclenche la connection du système client pour recevoir d'éventuelles données audio/vidéo qui pourraient accompagner les données dudit sous-système dans l'application multimédia. REVENDICATION 1. Procédé de stabilisation d'un flux de données audio/vidéo transmises par un système émetteur à un système client par l'intermédiaire d'un système serveur, le procédé comprenant la constitution d'un tampon temps réel de données entre la réception des données et la restitution de ces données à un utilisateur, caractérisé en ce que le procédé comprend : * la surveillance des débits d'entrée (203) et de sortie (201,202) de données du tampon, * ta comparaison (204) entre lesdits débits d'entrée et de sortie, et l'émission (21) par le système client d'une demande de réacheminement de données dès que lesdits débits d'entrée et de sortie ne satisfont pas une relation prédéterminée. 2. Procédé selon la revendication 1, caractérisé en ce que ladite surveillance et ladite comparaison sont réalisés continuellement. 3. Procédé selon la revendication 2, caractérisé en ce que ladite surveillance et ladite comparaison sont effectués selon une fréquence de prélèvement de paquets de données. 4. Procédé selon la revendication 3, caractérisé en ce que ladite fréquence de prélèvement est de l'ordre de 100 prélèvements par seconde. 5. Procédé selon l'une ou l'autre des revendications précédentes, caractérisé en ce que l'émission de demande de réacheminement est répétée en cas d'échec, pendant un délai donné. 6. Procédé selon la revendication 5, caractérisé en ce que ledit délai donné correspond à la durée tampon associée au tampon. 7. Procédé selon l'une ou l'autre des revendications précédentes, caractérisé en ce que le procédé comprend une tentative de reconnection du système client au système serveur, en cas de débit sortant du tampon nul. 8. Procédé selon l'une ou l'autre des revendications précédentes, caractérisé en ce qu'en cas de réception par le système client d'un ordre concernant un sous-système autre que les données audio/vidéo, le système client procède à une demande de reconnection au système serveur pour le transfert des données audio/vidéo.