Brevet FR3076158A1 — publié le 20190628

La présente invention concerne un procédé de régulation de débit entre un émetteur et un récepteur reliés par une pluralité de liens réseau lors d'une transmission de données audio/vidéo, un dispositif et un système mettant en oeuvre le procédé. Depuis quelques années, on assiste à une multiplication des applications utilisant des transmissions de données audio/vidéo sur réseau sans fil. Aux classiques transmissions de programmes télévisuels sur des dispositifs fixes tels que des téléviseurs, s'ajoutent des applications de transmission audio/vidéo à partir ou entre des dispositifs mobiles tels que des téléphones intelligents (« smartphone » en terminologie anglo-saxonne), des tablettes, et des drones. Il est courant que les dispositifs mobiles soient adaptés pour utiliser plusieurs types de réseau sans fil. Par exemple, un téléphone intelligent est adapté pour utiliser un réseau de téléphonie mobile (tel qu'un réseau GSM (Système global pour communications mobiles : « Global System for Mobile communications » en terminologie anglo-saxonne) aussi appelé réseau 2G, un réseau UMTS (système de télécommunication mobile universel : « Universal Mobile Communication System » en terminologie anglo-saxonne), aussi appelé réseau 3G, un réseau LTE-advanced (Evolution à long terme avancée : « Long Term Evolution Advanced » en terminologie anglo-saxonne), aussi appelé réseau 4G, ou un réseau LTE-advanced pro appelé aussi réseau 5G, etc) et un réseau domestique (tel que par exemple un réseau IEEE 802.11 (ISO/CEI 8802-11) aussi appelé réseau Wi-Fi ou un réseau bluetooth). Ces dispositifs mobiles n'utilisent généralement qu'un de ces réseaux sans fil à la fois, en général, le réseau offrant les meilleurs performances de transmission. Une transmission de données audio/vidéo sur un lien réseau sans fil fait en général appel à une méthode de régulation de débit permettant d'estimer les performances en termes de bande passante et de latence dudit lien. En effet, un dispositif n'a a priori aucune idée des performances d'un lien réseau sans fil. Le dispositif doit par lui-même découvrir quelles sont ces performances afin de transmettre des données avec un débit en adéquation avec ces performances. La littérature est foisonnante sur les méthodes de régulation de débit pour la transmission de données audio/vidéo sur un lien réseau. On recherche généralement pour ces méthodes des propriétés de réactivité permettant 2 d'adapter le plus rapidement possible une transmission audio/vidéo aux variations des performances dudit lien. Toutefois, avec l'augmentation des quantités de données à transmettre sur les réseaux sans fil, due par exemple à l'augmentation des résolutions des images 5 audio/vidéo ou à la nécessité de transmettre des données de contrôle dans le cas d'un drone, l'utilisation d'un lien réseau sans fil unique s'avère insuffisante. C'est pourquoi, certains dispositifs mobiles sont adaptés pour communiquer sur plusieurs liens réseau sans fil en parallèle (par exemple plusieurs liens 4G, plusieurs liens 5G, une combinaison de liens 4G, 5G et de Wi-Fi, etc) afin d'augmenter le débit disponible. 10 Cependant, communiquer en parallèle sur plusieurs liens réseau complexifie grandement le problème de régulation de débit. En effet, les méthodes de régulation de débit classiques ne sont pas immédiatement transposables au cas multi-liens. Ces méthodes, bien que performantes pour réguler un débit sur un lien donné, ne répondent pas à la question de la répartition des données sur plusieurs liens ayant des performances 15 variant indépendamment. Il est souhaitable de pallier ces inconvénients de l'état de la technique. Il est notamment souhaitable de trouver une méthode de régulation de débit qui soit adaptée au contexte des transmissions sur une pluralité de liens réseau en parallèle. Il est de plus souhaitable que cette méthode soit simple à mettre en oeuvre et ait un faible coût 20 calculatoire. Selon un premier aspect de la présente invention, la présente invention concerne un procédé de régulation de débit lors d'une transmission de données audio/vidéo sur un lien réseau entre un émetteur et un récepteur, ledit procédé étant mis en oeuvre lors de réceptions par l'émetteur d'informations représentatives de la transmission 25 transmises par le récepteur. Le procédé est mis en oeuvre par l'émetteur et comprend : une pluralité de modes de régulation de débit comprenant un premier mode de régulation de débit, exécuté au démarrage de la transmission, dans lequel la seule modification possible du débit de transmission par l'émetteur est une augmentation, chaque valeur d'augmentation de débit étant déterminée en ne prenant en compte 30 aucune information représentative de la transmission, et au moins un second mode de régulation mis en oeuvre à la suite du premier mode, dans lequel au moins une des informations représentatives de la transmission est utilisée pour augmenter ou diminuer le débit de transmission, un passage du premier mode vers un second mode se faisant lorsqu'une des informations représentatives de la transmission indique que le débit de 3 transmission a atteint un débit maximum disponible sur le lien réseau ; ledit débit de transmission étant partagé entre un budget de débit de données utiles comprenant les données audio/vidéo, dit budget utile, et un budget de débit de données secondaires, dit budget secondaire, non nécessaires au décodage des données audio/vidéo, seul le budget 5 secondaire est augmenté lors d'une augmentation du débit de transmission, le budget utile n'étant augmenté que lorsqu'aucune information représentative de la transmission reçue suite à une augmentation du budget secondaire n'indique une augmentation d'un risque de pertes de données. L'utilisation d'un mode de régulation de débit très agressif au démarrage permet 10 d'atteindre plus rapidement un débit disponible sur le lien réseau. L'utilisation de mode de régulation de débit plus doux par la suite permet de poursuivre la régulation de débit tout en limitant les risques de pertes de données. Par ailleurs, utiliser des données secondaires pour sonder le débit disponible sur le réseau permet de limiter un impact qu'auraient des pertes de données sur les données audio/vidéo. 15 Selon un mode de réalisation, dans le premier mode, lorsqu'au moins une des informations représentatives de la transmission indique qu'une augmentation d'un budget utile est possible, le procédé comprend : augmenter le budget utile d'un deuxième pourcentage prédéfini du budget secondaire lorsqu'un débit de transmission par l'émetteur des données secondaires est inférieur à un premier pourcentage prédéfini 20 du débit de transmission par l'émetteur des données utiles et diminuer le budget secondaire de la valeur de l'augmentation du budget utile ; augmenter le budget utile en fixant la valeur du budget utile à la somme du budget secondaire et d'une valeur représentative du débit de réception par le récepteur des données utiles et secondaire transmises par l'émetteur. 25 Selon un mode de réalisation, dans le premier mode, lorsqu'au moins une des informations représentatives de la transmission indique qu'une augmentation d'un budget secondaire doit être appliquée, le procédé comprend : augmenter le budget secondaire d'une première valeur d'augmentation prédéfinie. Selon un mode de réalisation, dans un deuxième mode, lorsqu'au moins une des 30 informations représentatives de la transmission indique qu'une augmentation du budget utile est possible, le procédé comprend : lorsqu'une des informations représentatives de la transmission indique qu'un débit de réception du récepteur atteint un troisième pourcentage prédéfini du maximum de débit disponible sur le réseau, allouer respectivement au budget utile et au budget secondaire un quatrième et un cinquième 4 pourcentages prédéfinis du débit de réception, une somme du budget utile et du budget secondaire étant égale audit débit de réception, le budget utile étant supérieur au budget secondaire ; lorsqu'une des informations représentatives de la transmission indique que ledit débit de réception est inférieur au troisième pourcentage prédéfini du maximum 5 de débit disponible sur le réseau, mettre le budget secondaire à zéro, allouer au budget utile un sixième pourcentage prédéfini dudit maximum et diminuer ledit maximum d'un septième pourcentage prédéfini. Selon un mode de réalisation, dans un deuxième mode, lorsqu'au moins une des informations représentatives de la transmission indique qu'une augmentation du budget 10 secondaire doit être appliquée, le procédé comprend : calculer une valeur d'augmentation en multipliant une deuxième valeur d'augmentation prédéfinie inférieure à la première valeur d'augmentation prédéfinie par un coefficient compris entre zéro et l'unité, ledit coefficient étant calculé à partir d'une information représentative d'une fenêtre de congestion et d'informations dépendantes de temps 15 d'aller observés par le récepteur et transmises dans les informations représentatives de la transmission à l'émetteur ; et ; augmenter le budget utile de la valeur d'augmentation calculée. Selon un mode de réalisation, lorsqu'au moins une des informations représentatives de la transmission indique qu'aucune augmentation du débit de 20 transmission n'est possible, le procédé comprend : appliquer une procédure de vérification du taux de pertes de paquets et réduire le débit de transmission si le taux de pertes est supérieur à un seuil de pertes prédéfini; si le taux de pertes est inférieur au seuil de pertes prédéfini, appliquer une procédure de vérification du délai d'aller et réduire le débit de transmission lorsqu'un écart entre le délai d'aller et une valeur de 25 délai d'aller de référence est supérieur à un écart prédéfini. Selon un deuxième aspect de l'invention, l'invention concerne un procédé de régulation de débit entre un émetteur et un récepteur reliés par une pluralité de liens réseau lors d'une transmission de données audio/vidéo. Le procédé comprend : former une liste de liens ordonnés ; parcourir les liens selon l'ordre de la liste ; pour chaque 30 lien : définir un budget de données à transmettre par ledit lien, dit lien courant, en utilisant des informations fournies pour le lien courant par le procédé de régulation de débit selon le premier aspect; et, transmettre une quantité de données correspondant audit budget ; passer au lien suivant lorsque la quantité de données correspondant audit 5 budget a été transmise en reprenant la liste au début lorsque tous les liens de la liste ont été parcourus. Ainsi, on utilise plusieurs liens en parallèle, chaque lien étant utilisé en fonction de ses capacités. 5 Selon un mode de réalisation, la liste est ordonnée suivant une métrique de performance calculée pour chaque lien de la pluralité de liens, pour un lien, ladite métrique étant une fonction croissante du budget de données à transmettre par ledit lien, une fonction décroissante d'une information représentative d'un taux de pertes de paquets sur ledit lien, et une fonction croissante d'une différence entre une taille de 10 fenêtre de congestion des liens et d'une information représentative d'un temps d'aller mesuré pour ledit lien. Selon un mode de réalisation, la métrique de performance pour un lien réseau i de la pluralité de liens se calcule de la manière suivante : (B datai + B_ 'timewindow timewindow = (13,i)2 x T D 3 owcli) 15 où Bdatai est le budget utile pour le lien réseau i, Bseci est le budget secondaire pour le lien réseau i, la somme dudit budget utile et dudit budget secondaire étant le budget de données à transmettre par le lien réseau i, pci est une information représentative d'un taux de pertes de paquets pour le lien réseau i, TD est une somme de budget secondaire pour tous les liens réseau de ladite pluralité, et owdi est 20 l'information représentative d'un délai d'aller mesuré pour le lien réseau i. timewindow est une latence que le système constitué du drone 1 et du système de commande 3 doit respecter. En d'autres termes, il doit s'écouler un délai de timewindow entre le moment ou un paquet de données entre dans le système (i.e. par exemple le moment ou le paquet est généré par le drone 1) et le moment ou il en sort (i.e. par exemple, le moment ou le 25 paquet est consommé par le système de commande 3). On note qu'un mécanisme de synchronisation d'horloge est mis en oeuvre entre le drone 1 et le système de commande 3 pour que la latence puisse être contrôlée efficacement. Timewindow est une valeur prédéfinie fixée par un utilisateur du système constitué du drone 1 et du système de commande 3. Par exemple, lorsqu'un utilisateur souhaite réaliser un duplex, il choisit 30 un valeur de Timewindow faible (par exemple 100 millisecondes). Par contre, si l'utilisateur souhaite implémenter une transmission de données audio/vidéo en sens unique sans contrainte de temps sur l'affichage desdites données, il choisit une valeur de timewindow élevée (par exemple 400 millisecondes). 6 Selon un mode de réalisation, lorsque l'émetteur se retrouve sans données à transmettre après une transmission d'un paquet, le prochain lien utilisé pour transmettre un paquet est le premier de la liste, la liste étant ensuite parcourue en repartant du premier lien de la liste. 5 Ainsi, on privilégie les liens réseau les plus performants. Selon un troisième aspect de l'invention, l'invention concerne un dispositif de régulation de débit lors d'une transmission de données audio/vidéo sur un lien réseau entre un émetteur et un récepteur, le dispositif comprenant des moyens adaptés pour mettre en oeuvre le procédé selon le premier aspect. 10 Selon un quatrième aspect de l'invention, l'invention concerne un dispositif de régulation de débit entre un émetteur et un récepteur reliés par une pluralité de liens réseau lors d'une transmission de données audio/vidéo, comprenant des moyens adaptés pour mettre en oeuvre le procédé selon le deuxième aspect. Selon un cinquième aspect de l'invention, l'invention concerne un système de 15 transmission de données audio/vidéo comprenant un émetteur comprenant un dispositif selon le troisième ou le quatrième aspect et un récepteur, l'émetteur et le récepteur étant reliés par au moins un lien réseau. Selon un sixième aspect, l'invention concerne un programme d'ordinateur, comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon le 20 premier aspect ou le procédé selon le deuxième aspect, lorsque ledit programme est exécuté par un processeur dudit dispositif. Selon un septième aspect, l'invention concerne des moyens de stockage stockant un programme d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon le premier aspect ou le procédé selon le deuxième aspect, 25 lorsque ledit programme est exécuté par un processeur dudit dispositif. Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : 30 - la Fig. 1 illustre schématiquement un exemple de système de transmission audio/vidéo utilisant une pluralité de liens réseau; - la Fig. 2 illustre schématiquement un exemple de drone utilisé dans le système de transmission audio/vidéo; 7 - la Fig. 3 illustre schématiquement un exemple de système de commande utilisé dans le système audio/vidéo ; - la Fig. 4A illustre schématiquement un exemple d'architecture matérielle d'un module de traitement d'un émetteur selon l'invention ; 5 - la Fig. 4B illustre schématiquement un exemple d'architecture matérielle d'un module de traitement d'un récepteur selon l'invention ; - la Fig. 5 illustre schématiquement un procédé de régulation de débit global selon l'invention permettant une répartition de données sur une pluralité de liens réseau; - la Fig. 6 illustre schématiquement une pluralité de modes de régulation de débit 10 utilisés dans un procédé de régulation de débit de lien; - la Fig. 7 illustre schématiquement un procédé de régulation de débit de lien selon l'invention; - la Fig. 8 illustre schématiquement un premier détail du procédé de régulation de débit d'un lien réseau selon l'invention; 15 - la Fig. 9 illustre schématiquement un deuxième détail du procédé de régulation de débit d'un lien réseau selon l'invention; - la Fig. 10 illustre schématiquement un troisième détail du procédé de régulation de débit d'un lien réseau selon l'invention; - la Fig. 11 illustre schématiquement un quatrième détail du procédé de 20 régulation de débit d'un lien réseau selon l'invention ; et, - la Fig. 12 décrit un détail d'une étape du procédé de la Fig. 9. Par la suite l'invention est décrite dans un contexte de système de drone dans lequel un opérateur contrôle un drone à partir d'un système de commande et le drone est adapté pour acquérir des données audio/vidéo et à les transmettre au système de 25 commande sur lequel celles-ci sont affichées. Dans ce système, les communications sont bidirectionnelles puisque au moins des données audio/vidéo sont transmises du drone vers le système de commande et au moins des données de contrôle sont transmises du système de commande vers le drone. Par ailleurs, ces communications utilisent de multiples liens réseau sans fil. 30 L'invention est toutefois adaptée à d'autres contextes, notamment au cas d'un système comprenant deux dispositifs mobiles jouant alternativement un rôle d'émetteur et de récepteur, chaque dispositif mobile étant apte à acquérir des données audio/vidéo et à les transmettre à l'autre dispositif en utilisant une pluralité de liens réseau en 8 parallèle. Dans ce cas, les deux dispositifs mobiles pourraient par exemple être des téléphones intelligents. Par ailleurs, l'invention est adaptée à des systèmes où seules des données audio ou seules des données vidéo sont échangées. Dans ce cas, bien qu'on parle par la suite 5 de données audio/vidéo celle-ci pourraient ne contenir que des données audio ou que des données vidéo. La Fig. 1 illustre schématiquement un exemple de système de transmission audio/vidéo utilisant une pluralité de liens réseau. Ce système comprend un système 1 et un système 3 reliés par une pluralité de 10 liens réseau 2A, 2B et 2C. Le système 3 est un système de commande permettant à un opérateur de contrôler le système 1 qui est un drone. La pluralité de liens réseau 2A, 2B et 2C comprend au moins un lien 4G ou 5G, au moins un lien Wi-Fi et, dans certains modes de réalisation, au moins un lien satellite. De cette manière, le système 1 et le système 3 peuvent communiquer à courte distance 15 en utilisant un lien Wi-Fi et, au-delà de la portée du lien Wi-Fi, en utilisant un lien 4G ou 5G. La Fig. 2 illustre schématiquement un exemple de drone utilisé dans le système de transmission audio/vidéo. Le drone 1 comprend un module de contrôle 11, un module d'acquisition 10, un 20 module de traitement 12 et un module réseau 13. Le module d'acquisition 10 comprend une caméra 100 adaptée pour acquérir des images dans l'environnement du drone 1. La caméra 100 fournit les images acquises à un encodeur audio/vidéo 101, qui compresse les images vidéo dans un format tel que le format AVC (codage vidéo avancé : « advanced Video Coding » en terminologie anglo- 25 saxonne (UIT-T H.264 - ISO/CEI MPEG-4 Part 10 (ISO/CEI 14496-10)) ou le format HEVC (Codage Vidéo hautement efficace, « High Efficiency Video Coding » en terminologie anglo-saxonne (UIT-T H.265 - ISO/CEI 23008-2)). La caméra 100 comprend de plus un capteur audio, qui capture des données audio et les fournit à l'encodeur audio/vidéo 101 qui les compresse par exemple au format AAC (« Avanced 30 Audio Coding » en terminologie anglo-saxonne). Les données audio/vidéo compressées sont ensuite insérées dans un flux de transport par l'encodeur audio/vidéo 101 tel que par exemple un flux MPEG-TS (Moving Picture Expert Group - Transport Stream). L'encodeur audio/vidéo 101 encapsule le flux de transport dans des paquets tels que des paquets RTP (Protocole de transport temps réel, « Real-Time Transport Protocol » en 9 terminologie anglo-saxonne, RFC 3550), les données audio et les données vidéo étant encapsulées dans des paquets différents. On obtient alors un flux audio/vidéo encapsulé dans des paquets en sortie du module de contrôle et d'acquisition 10. Lorsque le système 1 est un drone, celui-ci comprend un module de contrôle 11, 5 comprenant des moteurs 112, un contrôleur de déplacement 113 et au moins un capteur 114, tel qu'un gyroscope. Le contrôleur de déplacement 113 reçoit des signaux de commande en provenance du système de commande 3, et des informations de la part de chaque capteur 114 et agit sur les moteurs 112 afin de déplacer le drone 1 en prenant en compte ces signaux de commande et informations. Lorsque le contrôleur de 10 déplacement 113 ne reçoit aucun signal de commande, en cas de coupure réseau par exemple, il agit sur les moteurs 112 afin de stabiliser le drone dans une position actuelle en attendant de nouveaux signaux de commande. Le module réseau 13 comprend un module de communication 13A, 13B et 13C correspondant respectivement aux liens réseau 2A, 2B et 2C. Le Module de 15 communication 13A est par exemple un premier module 5G. Le Module de communication 13B est par exemple un deuxième module 5G. Le Module de communication 13C est par exemple un module Wi-Fi. Le module de traitement 12 est un élément central du drone 1. En effet, le module de traitement 12 reçoit des informations statistiques sur l'état de chaque lien réseau 2A, 20 2B et 2C, dites informations représentatives de la transmission, en provenance du module réseau 13 et les utilise pour mettre en oeuvre un procédé de régulation de débit selon l'invention. Les informations représentatives de la transmission comprennent notamment pour chaque lien réseau, un temps d'aller OWD (« one way delay » en terminologie anglo-saxonne), une information représentative d'un dernier paquet 25 acquitté, une information représentative d'un taux de pertes sur le lien, et une information représentative d'un nombre total d'octets reçus. Le module de traitement 12 détermine notamment une contrainte de débit à allouer à l'encodeur audio/vidéo 101. Par ailleurs, le module de traitement 12 reçoit les paquets de données audio/vidéo produits par l'encodeur audio/vidéo 101 et se charge de répartir ces paquets sur les 30 modules de communication 13A, 13B et 13C en prenant en compte des résultats du procédé de régulation de débit. Le module de traitement 12 reçoit aussi des paquets comprenant des signaux de commandes en provenance du système de commande 3, extrait ces signaux de commande des paquets et transmet les signaux de commande au module de contrôle 11. 10 Dans un mode de réalisation, le module réseau 13 comprend plus de trois modules de communication. Dans un mode de réalisation, le module de traitement 12 implémente un module de contrôle d'erreurs par anticipation (« Forward Error Control (FEC) » en terminologie 5 anglo-saxonne) non représenté. Le module de contrôle d'erreurs par anticipation traite chaque type de données indépendamment. Le module contrôle d'erreur par anticipation calcule des données redondantes, par exemple sous forme de code correcteur d'erreur, indépendamment pour les données vidéo, pour les données audio et pour toutes autres données transitant entre le drone 1 et le système de commande 3. Ces données 10 redondantes sont transmises sous forme de paquets et peuvent être utilisées par le système de contrôle 3 pour réparer des paquets de données utiles perdus lors de la transmission. Dans un mode de réalisation, le module de traitement 12 implémente un module de retransmission de paquets perdus. Le module de retransmission de paquets perdus 15 gère chaque type de données indépendamment. Lorsque les statistiques reçues du système de commande 3 indiquent qu'un ou plusieurs paquets ont été perdus, le module de retransmission retransmet les paquets perdus au moins une fois. Dans un mode de réalisation, le module de traitement 12implémente un module de contrôle d'erreurs par anticipation et un module de retransmission. Cependant, ces 20 modules ne sont pas activés en même temps. Le module de retransmission d'un module de communication est activé lorsqu'une latence moyenne entre le drone 2 et le système de commande 3est inférieure à un seuil prédéterminé. Dans ce cas, le module de contrôle d'erreurs par anticipation est désactivé. Lorsque la latence moyenne dépasse ledit seuil prédéterminé, le module de contrôle d'erreurs par anticipation est activé et le module 25 de retransmission est désactivé. Le seuil prédéterminé est par exemple égal à «100ms»de latence. Dans un mode de réalisation, le module de traitement 12 utilise en outre des informations de l'encodeur audio/vidéo 101 pour mettre en oeuvre le procédé de régulation de débit selon l'invention. Par exemple, le module de traitement 12 utilise 30 une information représentative d'un état d'une mémoire (« buffer » en terminologie anglo-saxonne) de sortie de l'encodeur audio/vidéo 101. La Fig. 3 illustre schématiquement un exemple de système de commande utilisé dans le système audio/vidéo. 11 Le système de commande 3 comprend un module multimédia 30, un module de contrôle 31, un module de traitement 32 et un module réseau 33. Le module multimédia 30 comprend un module 300 d'affichage (tel qu'un écran) et de diffusion de données audio (tel qu'au moins un haut-parleur). Le module 300 reçoit les données audio/vidéo 5 décodées de la part d'un module de décodage 301. Lorsque le système 1 est un drone, le système de commande 3 comprend un module de contrôle 31. Le module de contrôle 31 reçoit les commandes d'un opérateur obtenues grâce à une interface homme machine tel que des manettes, des boutons ou des commandes vocales et les traduits en signaux de commande. 10 Le module réseau 33 comprend un module de communication 33A, 33B et 33C correspondant respectivement aux liens réseau 2A, 2B et 2C. Le Module de communication 33A est par exemple un premier module 5G. Le Module de communication 33B est par exemple un deuxième module 5G. Le Module de communication 33C est par exemple un module Wi-Fi. 15 Le module de traitement 32 reçoit les données audio/vidéo sous forme de paquets en provenance du module réseau, remet en ordre ces paquets, et transmet les paquets réordonnés au module de décodage audio/vidéo 301. Par ailleurs, le module de traitement 32 reçoit les signaux de commande produits par le module de contrôle 31, les insère dans des paquets et prend en charge la répartition 20 des paquets obtenus sur les modules de communication 33A, 33B et 33C. Le module de traitement 32 reçoit en outre des statistiques sur l'état de chaque lien réseau 2A, 2B et 2C de la part du module réseau 33, met ces informations sous forme d'informations représentatives de la transmission et insère ces informations dans des paquets pour qu'elles soient transmises au drone 1. Dans un mode de réalisation, le 25 module de traitement 32 utilise les deux liens réseau offrant les meilleures performances pour transmettre les informations représentatives de la transmission. Chaque paquet contenant des informations représentatives de la transmission est donc transmis une première fois sur le lien réseau offrant les meilleures performances de transmission et en parallèle, une deuxième fois sur le lien offrant les secondes meilleures performances 30 de transmission. Dans un mode de réalisation, lorsque le module de traitement 12 du drone 1 implémente un module de contrôle d'erreurs par anticipation, le module de traitement 32implémente un module symétrique capable de décoder les données redondantes si nécessaire. 12 Dans un mode de réalisation, lorsque le module de traitement 12 du drone 1 implémente un module de retransmission, le module de traitement 32 implémente un module symétrique capable de demander des retransmissions de paquets perdus. Dans un mode de réalisation, le module de traitement 32 récupère des 5 informations représentatives de l'état du décodeur audio/vidéo 301 et les transmet sous forme de paquets au drone 1. Par exemple, le module de traitement 32 récupère l'état d'une mémoire d'entrée du module de décodage 301 et transmet des informations représentatives de cet état au drone 1. L'état de la mémoire d'entrée du drone peut être utilisé par le module de traitement 12 du drone 1 pour affiner sa régulation de débit. 10 Dans un mode de réalisation, le module réseau 33 comprend plus de trois modules de communication. Comme nous l'avons vu plus haut, le drone 1 et le système de commande 3 communiquent en utilisant des paquets. Chaque paquet échangé comprend un entête global, décrit dans le tableau 1 ci-dessous, dont la syntaxe et la sémantique sont les 15 mêmes quelle que soient les données transportées par le paquet. Un champ « Packet ID » décrit le contenu du paquet, i.e. décrit si le paquet contient une commande ou des données audio/vidéo. Un champ « Packet type » décrit si le paquet est une requête ou une réponse à une requête. Un paquet contenant des données audio/vidéo est par exemple considéré comme une requête. Un paquet d'accusé de réception est considéré 20 comme une réponse à une requête. 13 Champ Taille (en bits) Sémantique Packet ID 4 Décrit le contenu du paquet (commandes, données) Packet type 1 Décrit si le paquet est une requête ou une réponse à une requête Packet seqnum 11 Numéro de séquence du paquet Tableau 1: Entête global A la suite de l'entête global, chaque paquet comprend un entête dépendant des données transportées par le paquet. Lorsque le paquet comprend des données 5 audio/vidéo ou assimilées aux données audio/vidéo, que nous appelons par la suite données secondaires, le paquet comprend un entête, dite entête de paquet de données, décrite par le tableau 2. 14 Champ Taille (en bits) Sémantique Stream Id 4 Identifiant du flux de données auquel le paquet appartient retransmission 1 Egal à « 1 » pour un paquet de retransmission ou un paquet secondaire Reserved 3 Réservé pour de prochain usage seqnum 32 Numéro de séquence global Data timestamp 32 Indicateur temporel des données transportées Packet timestamp 16 Indicateur temporel d'envoi du paquet Link seqnum 16 Numéro de séquence du lien utilisé Data size 16 Taille des données utiles contenues dans le paquet FEC 16 Informations concernant les données de contrôle d'erreur par anticipation Tableau 2 : entête de paquet de données L'entête de paquet de données comprend : - un champ « Stream Id » identifiant le flux de données auquel le paquet appartient ; 5 - un champ « retransmission » égal à « 1 » pour un paquet de retransmission ou un paquet de données secondaire, « 0 » sinon ; - un champ « reserved » réservé pour de prochain usage ; - un « seqnum » comprenant un numéro de séquence du paquet de données ; - un champ « Data timestamp » comprenant un indicateur temporel pour les 10 données transportées par le paquet de données ; - un champ « packet timestamp » comprenant un indicateur temporel d'envoi de paquets (i.e. instant d'envoi du paquet) ; 15 - un champ « link seqnum » comprenant un numéro de séquence du lien utilisé ; - un champ « data size » donnant la taille en octet des données contenues dans le paquet ; - un champ « FEC » donnant des indications sur la méthode employée pour 5 générer des données de contrôle d'erreurs par anticipation. Lorsque le paquet comprend des commandes permettant de contrôler le drone 1, l'entête global est suivi d'un entête de paquet de commandes représenté dans le tableau 3. Champ Taille (en bits) Sémantique Command type 8 Type de commande Counter 32 Numéro de la commande Retry 8 Utilisé pour les acquittements Timestamp 32 Indicateur temporel, pour gérer les expirations de commande 10 Tableau 3 : entête de paquet de commandes L'entête de paquet de commandes comprend : - un champ « command type » décrivant le type d'une commande (par exemple, avant, arrière, à gauche, à droite, etc. ) ; - un champ « Counter » indiquant un numéro de commande ; 15 - un champ « Retry » utilisé pour lors d'acquittements ; - un champ « timestamp » correspondant à un indicateur temporel d'envoi de la commande. Cet indicateur est utilisé par exemple pour déterminer si une commande est arrivée trop tard et qu'elle ne doit pas être considérée par le drone. Lorsque le paquet comprend des informations représentatives de la transmission, 20 l'entête global est suivi d'un entête de paquet d'informations représentatives de la transmission décrite dans le tableau 4. 16 Champ Taille (en bits) Sémantique Links connected 8 Nombre de liens connectés Link index 8 Indice du lien pour lequel les statistiques qui suivent sont envoyées OWD 16 Délai d'aller Ack end seq 16 Dernier paquet acquitté Total link loss 16 Nombre de paquets perdus sur le lien Total link received bytes 32 Octets reçus sur le lien Link index 8 Indice du lien pour lequel les statistiques qui suivent sont envoyées OWD 16 Délai d'aller Ack end seq 16 Dernier paquet acquitté Total link loss 16 Nombre de paquets perdus sur le lien Total link received bytes 32 Octets reçus sur le lien Tableau 4 : Entête de paquets d'informations représentatives de la transmission L'entête de paquet d'informations représentatives de la transmission comprend des statistiques sur une pluralité de liens. Comme nous l'avons vu plus haut, ce type de 5 paquet est transmis sur les deux meilleurs liens réseaux de la pluralité de liens. Plus précisément, l'entête de paquet d'informations représentatives de la transmission comprend : - un champ « link connected » indiquant le nombre de liens entre le drone 1 et le système de commande 3 et donc le nombre de liens pour lesquels des statistiques 10 sont transmises dans le paquet d'informations représentatives de la transmission ; - au moins un champ « link index » donnant un indice du lien pour lequel les statistiques qui suivent sont envoyées, i.e. indice du lien concerné par les quatre champs suivants du paquet ; 17 - au moins un champ « OWD » transportant une information représentative d'un délai d'aller entre le drone et le système de commande pour le lien d'indice « link index » calculé par le module de traitement 32; - au moins un champ « Ack end seq » transportant une information représentative 5 du dernier paquet acquitté par le module de traitement 32 pour le lien d'indice « link index » ; - au moins un champ «Total link loss » transportant une information représentative d'un nombre de paquets perdus sur le lien d'indice « link index » ; 10 - au moins un champ «Total link received bytes » transportant une information représentative d'une quantité d'octets reçus sur le lien d'indice « link index ». La Fig. 4A illustre schématiquement un exemple d'architecture matérielle du module de traitement 12. Le module de traitement 12 comprend alors, reliés par un bus de communication 120: un processeur ou CPU (« Central Processing Unit » en anglais) 15 121 ; une mémoire vive RAM (« Random Access Memory » en anglais) 122; une mémoire morte ROM (« Read Only Memory » en anglais) 123 ; une unité de stockage ou un lecteur de support de stockage, tel qu'un lecteur de cartes SD (« Secure Digital » en anglais) 124 ; un ensemble d'interfaces de communication 125 permettant au module de traitement 120 de communiquer avec les autres modules compris dans le drone 1. 20 Le processeur 121 est capable d'exécuter des instructions chargées dans la RAM 122 à partir de la ROM 123, d'une mémoire externe (non représentée), d'un support de stockage, tel qu'une carte SD, ou d'un lien réseau. Lorsque le module de traitement 120 est mis sous tension, le processeur 121 est capable de lire de la RAM 122 des instructions et de les exécuter. Ces instructions forment un programme d'ordinateur 25 causant la mise en oeuvre, par le processeur 121, du procédé décrit en relation avec les Figs. 5 à 11. Tout ou partie du procédé décrit en relation avec la Fig. 5 à 11, peut être implémenté sous forme logicielle par exécution d'un ensemble d'instructions par une machine programmable, telle qu'un DSP (« Digital Signal Processor » en anglais) ou 30 un microcontrôleur, ou être implémenté sous forme matérielle par une machine ou un composant dédié, tel qu'un FPGA (« Field-Programmable Gate Array » en anglais) ou un ASIC (« Application-Specific Integrated Circuit » en anglais). La Fig. 4B illustre schématiquement un exemple d'architecture matérielle du module de traitement 32. Le module de traitement 32 comprend alors, reliés par un bus 18 de communication 320: un processeur ou CPU 321 ; une mémoire vive RAM 322 ; une mémoire morte ROM 323 ; une unité de stockage ou un lecteur de support de stockage, tel qu'un lecteur de cartes SD 324; un ensemble d'interfaces de communication 325 permettant au module de traitement 320 de communiquer avec les autres modules 5 compris dans le système de commande 3. Le processeur 321 est capable d'exécuter des instructions chargées dans la RAM 322 à partir de la ROM 323, d'une mémoire externe (non représentée), d'un support de stockage, tel qu'une carte SD, ou d'un lien réseau. Lorsque le module de traitement 320 est mis sous tension, le processeur 321 est capable de lire de la RAM 322 des 10 instructions et de les exécuter. Ces instructions forment un programme d'ordinateur causant la mise en oeuvre, par le processeur 321, d'étapes de reformation du flux audio/vidéo à partir de paquets contenant les données audio/vidéo, d'étapes de formation de paquets contenant les signaux de contrôle, d'étapes de récupération de statistiques sur les liens réseau et d'insertion d'informations représentatives de la 15 transmission obtenues à partir de ces statistiques dans des paquets. Tout ou partie des étapes exécutées par le module de traitement 32, peut être implémenté sous forme logicielle par exécution d'un ensemble d'instructions par une machine programmable, telle qu'un DSP (« Digital Signal Processor » en anglais) ou un microcontrôleur, ou être implémenté sous forme matérielle par une machine ou un 20 composant dédié, tel qu'un FPGA (« Field-Programmable Gate Array » en anglais) ou un ASIC (« Application-Specific Integrated Circuit » en anglais). Par la suite, nous décrivons le procédé de régulation de débit selon l'invention. Ce procédé comprend pour chaque lien d'une pluralité de liens, une exécution d'un procédé de régulation de débit de lien permettant de déterminer un débit à transmettre 25 sur ledit lien et pour la pluralité de liens, une exécution d'un procédé de régulation de débit global permettant de répartir des données sur une pluralité de liens réseau. Le procédé de régulation de débit de lien et le procédé de régulation de débit global sont exécutés parallèlement, le procédé de régulation de débit global utilisant des informations fournies par le procédé de régulation de débit de lien au cours de son 30 exécution. Le procédé de régulation de débit de lien est décrit en relation avec les Figs. 6 à 11 et le procédé de régulation de débit global est décrit en relation avec la Fig. 5. Le procédé de régulation de débit de lien est mis en oeuvre par un dispositif émetteur. Dans le cadre de l'exemple décrit en relation avec la Fig. 1, il est donc mis en 19 oeuvre par le drone 1 et plus précisément par le module de traitement 12. Comme nous l'avons vu plus haut, le module de traitement 12 exécute le procédé de régulation de débit de lien pour chaque lien réseau 2A, 2B et 2C. A chaque lien réseau 2A, 2B et 2C est donc associée une instance du procédé de régulation de débit de lien. 5 Le procédé de régulation de débit de lien comprend une pluralité de modes de régulation de débit. La Fig. 6 illustre schématiquement une pluralité de modes de régulation de débit utilisés dans le procédé de régulation de débit de lien selon l'invention. La pluralité de modes de régulation de débit de lien comprend un premier mode 10 de régulation de débit, dit mode agressif, exécuté au démarrage de la transmission. Dans le mode agressif la seule modification possible du débit de transmission est une augmentation. Chaque valeur d'augmentation de débit est déterminée en ne prenant en compte aucune information représentative de la transmission. Pour un lien réseau, dit lien courant, le mode agressif est utilisé pour permettre au drone d'atteindre rapidement 15 un débit maximum disponible sur le lien courant. La pluralité de modes de régulation de débit comprend au moins un second mode de régulation mis en oeuvre à la suite du mode agressif, dans lequel au moins une information représentative de la transmission sur le lien courant est utilisée pour augmenter ou diminuer le débit de transmission. 20 Dans le mode agressif, le module de traitement 12 boucle sur une étape 60 d'augmentation de débit tant que le débit de transmission du drone 1 n'a pas atteint un débit maximum disponible sur le lien courant. Dans une étape 61, le module de traitement passe du mode agressif vers un second mode lorsqu'au moins une information représentative de la transmission sur le lien courant indique que le débit de 25 transmission a atteint le débit maximum disponible sur le lien courant. L'information représentative de la transmission est par exemple un taux de pertes de paquets ou un délai d'aller (OWD). Lorsque le taux de pertes de paquets (lorsqu'un écart entre le dernier délai d'aller mesuré owd et un délai d'aller minimum min_OWD) dépasse un seuil de passage prédéterminé (respectivement un écart prédéterminé), le module de 30 traitement 12 passe à un second mode. Le seuil de passage prédéterminé est par exemple « 1% » de pertes de paquets. L'écart prédéterminé est par exemple égal à 2 x min_OWD ce qui équivaut à avoir un délai d'aller trois fois supérieur au délai d'aller minimum min OWD. 20 Une fois passé dans un second mode de régulation, le module de traitement ne revient jamais dans le mode agressif. Dans un mode de réalisation, la pluralité de modes de régulation de débit comprend deux seconds modes, un premier second mode, dit mode doux, et un 5 deuxième second mode, dit mode sécurisé. Lors de l'étape 61, le module de traitement 12 passe du mode agressif au mode doux. Dans le mode doux, le module de traitement continue à explorer le lien courant en augmentant le débit de transmission mais, cette fois-ci, de manière plus progressive. Pour ce faire, comme nous le verrons en relation avec la Fig. 9, le module de traitement 10 12 utilise des valeurs d'augmentation de débit plus faibles que dans le mode agressif. Dès que les augmentations de débit successives effectuées dans le mode doux provoquent des pertes de paquets, une augmentation du délai d'aller ou que la valeur d'augmentation de débit est inférieure à un seuil d'augmentation bas prédéterminé, le module de traitement 12 passe au mode sécurisé lors d'une étape 62. 15 Dans le mode sécurisé, le module de traitement 12 diminue le débit de transmission dès que des pertes de paquets ou temps d'aller trop élevés sont constatés. Lorsque la diminution du débit de transmission a permis d'empêcher les pertes de paquets et que le temps d'aller est revenu à un niveau acceptable, le module de traitement 12 détermine une valeur d'augmentation de débit et applique l'augmentation 20 déterminée au débit de transmission sur le lien courant. Si la valeur d'augmentation de débit est supérieure au seuil d'augmentation bas prédéterminé, le module de traitement retourne au mode doux lors d'une étape 63. Sinon, le module de traitement 12 boucle dans le mode sécurisé lors d'une étape 64. De cette manière, les valeurs d'augmentation dans le mode sécurisé sont plus faibles que dans le mode doux. 11 y a donc moins de 25 risques de provoquer des pertes de paquets ou des augmentations de délais d'aller dans le mode sécurisé que dans le mode doux. La Fig. 7 illustre schématiquement le procédé de régulation de débit de lien selon 1 ' invention. Comme dit plus haut, le procédé de régulation de débit de lien est exécuté en 30 parallèle pour chaque lien de la pluralité de liens. Dans une étape 70, le module de traitement 12 reçoit un paquet d'informations représentatives d'une transmission. Chaque réception d'un paquet d'informations représentatives d'une transmission provoque un lancement du procédé de régulation de 21 débit de lien. Ces paquets sont transmis régulièrement à l'équipement de commande 3 par le drone 1, par exemple toutes les «5 ms ». Dans une étape 71, le module de traitement 12 détermine si une augmentation du débit de transmission sur le lien courant est possible. Pour ce faire le module de 5 traitement 12 utilise notamment les informations contenues dans les paquets d'informations représentatives de la transmission. A partir de l'information contenue dans le champ « Total link loss » et de l'information « Ack end seq », le module de traitement 12 calcule un taux de pertes courant 13, sur le lien. L'information « Ack end seq » représente le numéro de séquence 10 du dernier paquet acquitté. En divisant la valeur du champ « Total link loss » par une différence entre les deux dernières valeurs de l'information « Ack end seq » reçues dans des paquets d'informations représentatives de la transmission, on peut déterminer le taux de pertes courant P. A partir du taux de pertes courant /3, et d'un taux de pertes Pp', précédent le taux de pertes courant /3,, le module de traitement 12 calcule une 15 valeur d'augmentation du taux de pertes Ap = Pc Pprev - A partir du taux de pertes courant /3, et d'un nombre prédéfini de taux de perte précédant le taux de pertes courant /3', le module de traitement calcule un taux de pertes moyen sur le lien courant P. A partir de l'information contenue dans le champ « OWD », le module de 20 traitement 12 obtient un délai d'aller courant owd, et calcule une différence Aowd entre le délai d'aller courant owd, et une valeur minimale du délai d'aller courant min OWD. La valeur minimale du délai d'aller courant min OWD est calculée au fur et à mesure de la transmission en prenant la valeur minimale du délai d'aller observée. A partir de l'information contenue dans le champ « Total link received bytes », le 25 module de traitement calcule le débit rx bitrate de réception du système de commande 3 sur le lien courant. Chaque paquet comprend dans son entête un indicateur temporel (non représenté dans les tableaux 1 à 4). Le débit rx bitrate est calculé en divisant la valeur du champ « Total link received bytes » par une différence entre les valeurs d'indicateur temporel des deux derniers paquets d'informations représentatives de la 30 transmission. Dans un mode de réalisation, cette valeur de débit rx bitrate est filtrée, par exemple par un filtre de Butterworth d'ordre 2, afin d'atténuer d'éventuelles fortes variations dans les débits Rxcalculés successivement. A la suite de ces calculs, le module de traitement 12 vérifie si des contraintes d'un ensemble prédéfini de contraintes sont respectées : 22 1P P70*tx bitrate, le module de traitement 12 détermine que c'est le budget utile qui peut être augmenté. Le module de traitement 12 23 augmente alors le budget utile lors d'une étape 73. Sinon, le module de traitement 12 augmente le budget secondaire lors d'une étape 74. Les étapes 72, 73 et 74 sont détaillées en relation avec les Figs. 8 et 9. Lors de l'étape 75, le module de traitement 12 détermine si le taux de pertes 5 courant Pc. est supérieur à zéro. Si oui, le module de traitement 12 exécute une étape 76 au cours de laquelle il applique une réduction du débit de transmission permettant de réduire le taux de pertes sur le lien. L'étape 76 est détaillée en relation avec la Fig. 10. Si le taux de pertes courant Pc. est nul, le module de traitement 12 vérifie si la latence est trop importante lors d'une étape 77. 10 Si la latence est admissible, le module de traitement 12 ne fait rien et se met en attente lors d'une étape 79. Sinon, le module de traitement 12 applique une réduction du débit de transmission permettant de réduire le délai d'aller lors d'une étape 78. Les étapes 77, 78 et 79 sont détaillées en relation avec la Fig. 11. Les étapes 73, 74, 76, 78 et 79 sont suivies de l'étape 70. 15 On note que, alors que les étapes d'augmentation du débit de transmission 73 et 74 peuvent concerner les trois modes de régulation de débit, les étapes de diminutions du débit de transmission ne concernent que les seconds modes de régulation de débit. Par ailleurs, dès qu'une des contraintes examinées lors de l'étape 71 n'est pas vérifiée, le module de traitement 12 quitte irrémédiablement le mode agressif. 20 La Fig. 8 illustre schématiquement un premier détail de l'étape 73 du procédé de régulation de débit d'un lien réseau selon l'invention. Dans une étape 730, le module de traitement 12 détermine s'il se trouve dans le mode agressif. Il suffit pour cela que le module de traitement 12 vérifie qu'il n'a constaté aucune perte de paquet jusque-là. 25 Si le module de traitement 12 se trouve dans le mode agressif, il passe à l'étape 731. Sinon, il exécute l'étape 734. Lors de l'étape 731, le module de traitement 12 vérifie si un débit de transmission des données secondaires tx bitrate sec est inférieur à un premier pourcentage prédéfinie P81 d'un débit de transmission de données utiles tx bitrate data. Par 30 exemple P81,15%. Si tx bitrate sec max bitrate*P84, le module de traitement 12 alloue lors d'une étape 736, respectivement au budget utile B data et au budget secondaire B sec un quatrième pourcentage P87 et un cinquième pourcentage P88 prédéfinis du débit de 25 réception rx bitrate, une somme du budget utile B data et du budget secondaire B sec étant égal audit débit de réception rx bitrate, le budget utile B data étant supérieur au budget secondaire B sec : B data = P87*rx bitrate B sec = P88*rx bitrate 30 B data+B sec=rx bitrate B data> Bsec Dans un mode de réalisation P87=90% et P88=10%. Lors de l'étape 736, en prenant des pourcentages du débit de réception rx bitrate, on s'assure de rester dans les limites de bande passante du lien courant. 25 Lorsque Rx bitrate fi, alors Percent est fixé à la valeur prédéfinie fi. Ainsi le pourcentage de baisse Percent ne dépasse jamais la valeur prédéfinie fi (ici 10%). La valeur prédéfinie fi est donc le pourcentage de baisse maximum. 20 Si Percent 51, le budget de débit secondaire B sec est diminué de la manière suivante : (100 -Percent) x B _sec B_ sec = /100 29 Si B sec max OWD min, le module de traitement 12 détermine que le lien est un lien à forte latence. Dans ce cas, il exécute une étape 1203. Sinon il exécute une étape 1204. Dans l'étape 1203, le module de traitement 12 calcule une valeur de la variable Coeff N en prenant le maximum entre la valeur de Coeff N calculée lors de l'étape 1201 15 et une valeur minimale de Coeff N adaptée au lien à forte latence MIN N HIGH LATENCY. Dans l'étape 1204, le module de traitement 12 calcule une valeur de la variable Coeff N en prenant le maximum entre la valeur de Coeff N calculée lors de l'étape 1201 et une valeur minimale de Coeff N adaptée au lien à faible latence 20 MIN N LOW LAIENCY. Les étapes 1203 et 1204 sont suivies d'une étape 1208 au cours de laquelle, la valeur de la variable Coeff N est pondérée. Dans un mode de réalisation, la valeur de coeff N calculée par pondération lors de l'étape 1208 résulte d'une moyenne pondérée des quatre dernières valeurs de la variable coeff N calculées, la dernière valeur calculée 25 ayant le poids le plus élevé dans la moyenne pondérée. Si aucune perte de paquet n'a été constatée au cours de l'étape 1200, le module de traitement 12 vérifie lors d'une étape 1205 combien de fois le délai d'aller a dépassé la valeur Coeff_N * min_OWD pendant la période Ô précédente sans que des pertes de paquets soient constatées. Si le délai d'aller a dépassé un nombre de fois prédéfini Kowd 30 (par exemple Km/y,/ = 5) la valeur Coeff_N * min_OWD sans que des pertes de paquets soient constatées, le module de traitement 12 exécute une étape 1206. Sinon, le module de traitement 12 décide de ne pas modifier la valeur de la variable Coeff N au cours d'une étape 1209. 33 Lors de l'étape 1206, le module de traitement 12 vérifie si la valeur de la variable Coeff N est inférieure à une valeur maximale MAX _N prédéfinie de la valeur Coeff N.Si oui, la valeur de la variable Coeff N est incrémentée de «0.01 ». Sinon, le module de traitement 12 exécute l'étape 1209 déjà expliquée. 5 L'étape 1207 est suivie de l'étape 1208. L'étape 1208 est toutefois optionnelle et le module de traitement 12 pourrait aussi utiliser la valeur de la variable Coeff N issue des étapes 1203, 1204 et 1207. Dans un mode de réalisation : - MIN N HIGH LA1ENCY= 1.5 10 - MIN N LOW LA1ENCY= 2.5 - MAX N = REVENDICATIONS1) Procédé de régulation de débit lors d'une transmission de données audio/vidéo sur un lien réseau entre un émetteur et un récepteur, ledit procédé étant mis en oeuvre lors de réceptions par l'émetteur d'informations représentatives de la transmission transmises par le récepteur, caractérisé en ce que le procédé est mis en oeuvre par l'émetteur et comprend : une pluralité de modes de régulation de débit comprenant un premier mode de régulation de débit, exécuté au démarrage de la transmission, dans lequel la seule modification possible du débit de transmission par l'émetteur est une augmentation, chaque valeur d'augmentation de débit étant déterminée en ne prenant en compte aucune information représentative de la transmission, et au moins un second mode de régulation mis en oeuvre à la suite du premier mode, dans lequel au moins une des informations représentatives de la transmission est utilisée pour augmenter ou diminuer le débit de transmission, un passage du premier mode vers un second mode se faisant lorsqu'une des informations représentatives de la transmission indique que le débit de transmission a atteint un débit maximum disponible sur le lien réseau ; ledit débit de transmission étant partagé entre un budget de débit de données utiles comprenant les données audio/vidéo, dit budget utile, et un budget de débit de données secondaires, dit budget secondaire, non nécessaires au décodage des données audio/vidéo, seul le budget secondaire est augmenté lors d'une augmentation du débit de transmission, le budget utile n'étant augmenté que lorsqu'aucune information représentative de la transmission reçue suite à une augmentation du budget secondaire n'indique une augmentation d'un risque de pertes de données. 2) Procédé selon la revendication 1 caractérisé en ce que, dans le premier mode, lorsqu'au moins une des informations représentatives de la transmission indique qu'une augmentation d'un budget utile est possible (72), le procédé comprend : augmenter (732) le budget utile d'un deuxième pourcentage prédéfini du budget secondaire lorsqu'un débit de transmission par l'émetteur des données secondaires est inférieur à un premier pourcentage prédéfini du débit de transmission par l'émetteur des données utiles et diminuer le budget secondaire de la valeur de l'augmentation du budget utile ; augmenter (733) le budget utile en fixant la valeur du budget utile à la somme du budget secondaire et d'une valeur représentative du débit de réception par le récepteur des données utiles et secondaire transmises par l'émetteur. 5 3) Procédé selon la revendication 1 ou 2 caractérisé en ce que, dans le premier mode, lorsqu'au moins une des informations représentatives de la transmission indique qu'une augmentation d'un budget secondaire doit être appliquée (73), le procédé comprend : augmenter (741, 745) le budget secondaire d'une première valeur 10 d'augmentation prédéfinie. 4) Procédé selon la revendication 1, 2 ou 3 caractérisé en ce que, dans un deuxième mode, lorsqu'au moins une des informations représentatives de la transmission indique qu'une augmentation du budget utile est possible, le procédé 15 comprend : lorsqu'une des informations représentatives de la transmission indique (734) qu'un débit de réception du récepteur atteint un troisième pourcentage prédéfini du maximum de débit disponible sur le réseau, allouer (736) respectivement au budget utile et au budget secondaire un quatrième et un cinquième pourcentage prédéfinis du débit 20 de réception, une somme du budget utile et du budget secondaire étant égale audit débit de réception, le budget utile étant supérieur au budget secondaire ; lorsqu'une des informations représentatives de la transmission indique (734) que ledit débit de réception est inférieur au troisième pourcentage prédéfini du maximum de débit disponible sur le réseau, mettre (735) le budget secondaire à zéro, allouer au 25 budget utile un sixième pourcentage prédéfini dudit maximum et diminuer ledit maximum d'un septième pourcentage prédéfini. 5) Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que, dans un deuxième mode, lorsqu'au moins une des informations représentatives 30 de la transmission indique qu'une augmentation du budget secondaire doit être appliquée, le procédé comprend : calculer (742, 743, 744) une valeur d'augmentation en multipliant une deuxième valeur d'augmentation prédéfinie inférieure à la première valeur d'augmentation prédéfinie par un coefficient compris entre zéro et l'unité, ledit coefficient étant calculé 36 à partir d'une information représentative d'une fenêtre temporelle et d'informations dépendantes de temps d'aller observés par le récepteur et transmises dans les informations représentatives de la transmission à l'émetteur ; et ; augmenter (745) le budget utile de la valeur d'augmentation calculée. 5 6) Procédé selon l'une quelconque des revendications précédentes caractérisé en ce que, lorsqu'au moins une des informations représentatives de la transmission indique qu'aucune augmentation du débit de transmission n'est possible, le procédé comprend : appliquer une procédure de vérification du taux de pertes de paquets et réduire 10 le débit de transmission si le taux de pertes est supérieur à un seuil de pertes prédéfini (760, 761, 762); si le taux de perte est inférieur au seuil de pertes prédéfini, appliquer une procédure de vérification du délai d'aller (780, 781, 783) et réduire le débit de transmission lorsqu'un écart entre le délai d'aller et une valeur de délai d'aller de 15 référence est supérieur à un écart prédéfini. 7) Procédé de régulation de débit entre un émetteur et un récepteur reliés par une pluralité de liens réseau lors d'une transmission de données audio/vidéo, caractérisé en ce que le procédé comprend : 20 former une liste de liens ordonnés ; parcourir les liens selon l'ordre de la liste ; pour chaque lien : définir un budget de données à transmettre par ledit lien, dit lien courant, en utilisant des informations fournies pour le lien courant par le procédé de régulation de 25 débit selon l'une quelconque des revendications 1 à 6 ; et, transmettre une quantité de données correspondant audit budget ; passer au lien suivant lorsque la quantité de données correspondant audit budget a été transmise en reprenant la liste au début lorsque tous les liens de la liste ont été parcourus. 30 8) Procédé selon la revendication 7, caractérisé en ce que la liste est ordonnée suivant une métrique de performance calculée pour chaque lien de la pluralité de liens, pour un lien, ladite métrique étant une fonction croissante du budget de données à transmettre par ledit lien, une fonction décroissante d'une information représentative 37 d'un taux de pertes de paquets sur ledit lien, et une fonction croissante d'une différence entre une taille de fenêtre de congestion des liens et d'une information représentative d'un temps d'aller mesuré pour ledit lien. 5 9) Procédé selon la revendication 8, caractérisé en ce que la métrique de performance pour un lien réseau i de la pluralité de liens se calcule de la manière suivante : (B datai + B_seci)2 (timewindow = (13,i)2 x TD 3 où Bdatai est le budget utile pour le lien réseau i, Bseci est le budget secondaire pour le 10 lien réseau i, la somme dudit budget utile et dudit budget secondaire étant le budget de données à transmettre par le lien réseau i, pci est une information représentative d'un taux de pertes de paquets pour le lien réseau i, TD est une somme de budget secondaire pour tous les liens réseau de ladite pluralité, timewindow est une latence maximale admissible entre l'émetteur et le récepteur, et owdi est l'information représentative d'un 15 délai d'aller mesuré pour le lien réseau i. 10) Procédé selon la revendication 8 ou 9, caractérisé en ce que lorsque l'émetteur se retrouve sans données à transmettre après une transmission d'un paquet, le prochain lien utilisé pour transmettre un paquet est le premier de la liste, la liste étant 20 ensuite parcourue en repartant du premier lien de la liste. 11) Dispositif de régulation de débit lors d'une transmission de données audio/vidéo sur un lien réseau entre un émetteur et un récepteur, caractérisé en ce qu'il comprend des moyens adaptés pour mettre en oeuvre le procédé selon les revendications 25 1 à 6. 12) Dispositif de régulation de débit entre un émetteur et un récepteur reliés par une pluralité de liens réseau lors d'une transmission de données audio/vidéo, caractérisé en ce qu'il comprend des moyens adaptés pour mettre en oeuvre le procédé selon les 30 revendications 7 à 10. 13) Système de transmission de données audio/vidéo comprenant un émetteur comprenant un dispositif selon la revendication 11 ou 12 et un récepteur, l'émetteur et le récepteur étant reliés par au moins un lien réseau. 38 14) Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions pour mettre en oeuvre, par un dispositif (12), le procédé selon l'une quelconque des revendications 1 à 6 ou le procédé selon l'une quelconque des revendications 7 à 10, 5 lorsque ledit programme est exécuté par un processeur dudit dispositif. 15) Moyens de stockage, caractérisés en ce qu'ils stockent un programme d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif (12), le procédé selon l'une quelconque des revendications 1 à 6 ou le procédé selon les 10 revendications 7 à 10, lorsque ledit programme est exécuté par un processeur dudit dispositif.