Brevet FR3079705A1 — publié le 20191004

Communication par vidéo conférence Domaine de l'invention Le domaine général de l'invention est celui des télécommunications. L'invention concerne plus particulièrement la mise en oeuvre de communications par vidéo conférence et/ou visiophonie entre N terminaux, tel que Nk2. Etat de la technique Actuellement, les systèmes de communication par vidéo conférence multipoint utilisent un pont de gestion de vidéo conférence auquel se connectent, via un réseau de communication, N terminaux qui sont associés respectivement à N utilisateurs invités à une vidéo conférence. Au cours de la vidéo conférence, le pont de gestion de vidéo conférence reçoit, à un instant courant, N flux audio vidéo ou seulement vidéo qui sont émis respectivement par les N terminaux. Il met en oeuvre une analyse de ces flux afin de détecter quel est l'utilisateur qui parle de façon prépondérante ou dont la prise de parole est la plus active. Puis, pour un utilisateur donné, le pont renvoie vers le terminal de cet utilisateur l'ensemble des flux audio vidéo reçus, éventuellement à l'exception du flux audio vidéo qui a été reçu en provenance du terminal de l'utilisateur donné. Chaque flux audio vidéo (respectivement vidéo) reçu par le terminal de l'utilisateur donné contient un identifiant de l'utilisateur correspondant au flux et une pluralité de paquets de données audio et vidéo (respectivement vidéo) qui sont numérotés. Ainsi, le pont de gestion de vidéo conférence est capable de connaître avec précision quel paquet de données il envoie. Il arrive que certains des paquets de données envoyés par le pont ne soient pas reçus par un terminal de communication participant à la vidéo conférence. Une telle situation se produit dans le cas par exemple où le débit courant de transmission de données, depuis le pont de gestion de vidéo conférence vers le terminal de communication, devient réduit pour diverses raisons, par exemple parce que le terminal de communication procède simultanément au déroulement de la vidéo 2 conférence, au téléchargement depuis un serveur, d'un fichier de données de grande taille, tel qu'une vidéo par exemple. Dans cette situation, le terminal de communication qui n'a pas reçu un ou plusieurs paquets de données est capable, pour chaque flux de données reçu en provenance du pont, d'identifier avec précision quels sont les paquets 5 reçus manquants à partir des paquets de données qu'il a déjà identifiés dans le flux reçu donné. Afin de récupérer ce ou ces paquets manquants, le terminal de communication envoie au pont une requête en réception du ou des paquets manquants, la requête contenant l'identifiant de l'utilisateur correspondant au flux reçu donné et l'identifiant du ou des paquets manquants. 10 Un inconvénient de ce mécanisme d'envoi de requête en fourniture de paquets de données manquants réside dans le fait qu'il sollicite les ressources logicielles du terminal de communication qui les envoie. Une telle consommation des ressources logicielles du terminal peut en outre provoquer un ralentissement de la restitution des flux reçus en provenance du pont. De ce fait, l'utilisateur du terminal ne peut pas suivre 15 correctement la vidéo conférence, les conditions d'exécution de cette dernière étant dégradées. Un autre inconvénient réside aussi dans le fait que lorsque le nombre de paquets perdus augmente trop, les flux vidéo représentatifs des participants à la vidéo conférence qui sont reçus en provenance du pont ne s'affichent pas correctement sur 20 l'écran du terminal qui les reçoit. Ces flux vidéo ont ainsi tendance à se figer sur l'écran du terminal, ce qui ne permet pas à l'utilisateur de suivre toujours correctement la vidéo conférence et dans de bonnes conditions de fonctionnement. Par ailleurs, il a été constaté que même si le débit de transmission des données depuis le pont vers le terminal retrouve un niveau correct, les flux vidéo affichés sur l'écran du terminal 25 demeurent figés. Objet et résumé de l'invention Un des buts de l'invention est donc de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des 30 améliorations. A cet effet, un objet de la présente invention concerne un procédé de 3 communication par vidéo conférence entre N terminaux de communication, tel que Nk2, associés respectivement à N utilisateurs, mettant en oeuvre, au niveau d'un terminal de communication considéré parmi les N terminaux, la réception, en provenance d'un dispositif de traitement de N flux vidéo ou de N flux audio et vidéo émis respectivement 5 par les N terminaux, de N-1 flux de données traités tels qu'associés respectivement aux N-1 utilisateurs autres que l'utilisateur du terminal considéré, les N-1 flux de données contenant chacun une pluralité de paquets de données audio et/ou vidéo. Un tel procédé est remarquable en ce qu'il met en oeuvre ce qui suit, au niveau du terminal de communication considéré : 10 - compter les paquets de données non reçus, - le nombre de paquets de données non reçus étant supérieur à un nombre prédéterminé et un des N-1 utilisateurs parlant à l'instant courant, requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de données associé à celui 15 des N-1 utilisateurs qui parle à l'instant courant, - en réponse à la requête, recevoir uniquement les données vidéo du flux de données audio et vidéo associé à celui des N-1 utilisateurs qui parle à l'instant courant, - restituer visuellement uniquement le flux correspondant aux données 20 vidéo reçues. Grâce à l'invention, il est possible, pour tout terminal qui communique par vidéo conférence avec N-1 terminaux de communication, de requérir de sa propre initiative auprès du dispositif de traitement de flux, uniquement l'affichage du flux vidéo associé celui des N-1 utilisateurs qui parle à l'instant courant, lorsque le débit de transmission 25 des données, depuis le dispositif de traitement de flux vers le terminal, devient faible. Ce mécanisme d'envoi de requêtes est avantageusement déclenché à la suite d'une opération de comptage, au niveau du terminal, des paquets de données non reçus, indiquant que le nombre de paquets non reçus est passé en-dessous d'un seuil prédéfini. Ce seuil prédéfini permet au terminal de déterminer astucieusement que le 30 débit de transmission des données, depuis le dispositif de traitement de flux vers le terminal, est : 4 - soit trop faible, si le nombre de paquets non reçus dépasse ce seuil, - soit suffisant, si le nombre de paquets non reçus ne dépasse pas ce seuil. A cet effet, quand le terminal détermine que le débit est trop faible, le terminal 5 demande explicitement au dispositif de traitement de ne plus recevoir les paquets de données vidéo associés aux utilisateurs qui ne parlent pas à l'instant courant, ce qui permet de réduire rapidement et de façon simple et efficace la consommation en bande passante du canal de transmission de ces paquets de données vidéo, en provenance du dispositif de traitement. 10 Un tel mécanisme de comptage des paquets de données non reçus permet en outre au débit de transmission des données, depuis le dispositif de traitement vers le terminal, de revenir rapidement à un niveau permettant au terminal de recevoir la totalité ou presque des paquets de données audio et vidéo des N-1 flux de données associés respectivement aux N-1 utilisateurs. 15 Les paquets de données audio, quant à eux, continuent d'être reçus par le terminal pour l'ensemble des N-1 utilisateurs, sachant que les paquets de données audio ne représentent que 5 à 10% du trafic d'une communication par vidéo conférence, ce qui est peu significatif en comparaison des paquets de données vidéo qui représentent 90 à 95% du trafic de la communication par vidéo conférence. 20 Selon un mode de réalisation particulier, l'action de comptage du nombre de paquets de données non reçus est réitérée plusieurs fois au cours de la vidéo conférence. De façon avantageuse, tout terminal est ainsi apte à estimer régulièrement au cours de la vidéo conférence si le débit de transmission, depuis le dispositif de 25 traitement de flux vers le terminal, redevient suffisant pour alors stopper l'envoi des requêtes d'interruption au dispositif de traitement et recevoir les paquets de données audio et vidéo des N-1 flux de données associés respectivement aux N-1 utilisateurs, de façon à retrouver dès que possible des conditions de fonctionnement normales de la vidéo conférence. 30 Selon un mode de réalisation particulier, l'action de requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de 5 données, à l'exception de ceux du flux de données associé à celui des N-1 utilisateurs qui parle à l'instant courant, comprend ce qui suit : - envoyer au dispositif de traitement une requête contenant un identifiant relatif à celui des N-1 utilisateurs qui parle à l'instant courant, l'identifiant étant associé à une 5 information d'activation de la réception des paquets de données audio et vidéo du flux de données correspondant à l'utilisateur qui parle à l'instant courant. De par le contenu de la requête envoyée par le terminal, celui-ci est ainsi avantageusement apte à préciser au dispositif de traitement exactement quel flux de données audio et vidéo, parmi l'ensemble de flux de données audio vidéo ou vidéo 10 reçus par le terminal, il souhaite continuer à recevoir. Un tel mode de réalisation particulier est avantageux en ce sens qu'il ne nécessite l'envoi que d'une seule requête de la part du terminal, optimisant ainsi la réduction de la bande passante du canal de transmission de données, depuis le terminal vers le dispositif de traitement de flux. 15 En variante du mode de réalisation ci-dessus, l'action de requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de données associé à celui des N-1 utilisateurs qui parle à l'instant courant, comprend ce qui suit : envoyer au dispositif de traitement : 20 - une première requête contenant un identifiant relatif à celui des N-1 utilisateurs qui parle à l'instant courant, l'identifiant étant associé à une information d'activation de la réception des paquets de données audio et vidéo du flux de données correspondant à l'utilisateur qui parle à l'instant courant, et/ou - N-2 autres requêtes contenant chacune un identifiant relatif à un 25 utilisateur qui ne parle pas à l'instant courant, l'identifiant étant associé à une information de désactivation de la réception des paquets de données vidéo du flux de données correspondant à l'utilisateur qui ne parle pas à l'instant courant. De par le contenu de la requête envoyée par le terminal, celui-ci est ainsi avantageusement apte à préciser au dispositif de traitement exactement : 30 - quel flux de données audio et vidéo, parmi l'ensemble de flux de données audio vidéo reçus par le terminal, il souhaite continuer à recevoir, mais aussi, 6 ou bien, - quels flux de données vidéo, associés à chacun des N-2 utilisateurs qui ne parlent pas à l'instant courant, il souhaite ne plus recevoir. Un tel mode de réalisation permet, moyennant l'envoi au dispositif de traitement 5 de flux, par le terminal, de N-1 ou bien N-2 requêtes peu consommatrices en termes de débit de transmission de données, une économie non négligeable de la bande passante du canal de transmission de données, depuis le dispositif de traitement de flux vers le terminal, puisque les paquets de données vidéo des N-2 flux associés respectivement aux N-2 utilisateurs qui ne parlent pas à l'instant courant, quant à eux 10 très consommateurs en termes de débit de transmission de données, ne sont temporairement plus reçus par le terminal. Selon un mode de réalisation particulier, le procédé de communication par vidéo conférence comprend en outre ce qui suit, en réponse à l'envoi de la requête d'interruption de la réception des paquets de données vidéo des flux de 15 données : - recevoir, en provenance du dispositif de traitement, N-2 flux de données associés respectivement aux N-2 utilisateurs qui ne parlent pas à l'instant courant, tout flux considéré, parmi les N-2 flux, contenant des données d'image fixe associée à l'utilisateur correspondant au flux donné, 20 - restituer les N-2 flux de données d'image fixe simultanément au flux de données associé à l'utilisateur qui parle à l'instant courant. Grâce à un tel mode de réalisation, en réponse à la demande du terminal auprès du dispositif de traitement de flux, de ne pas recevoir les paquets de données vidéo des N-2 flux de données associés respectivement aux N-2 utilisateurs qui ne 25 parlent pas à l'instant courant, le terminal reçoit avantageusement N-2 flux contenant des données d'image fixe à la place des données vidéo associées respectivement aux utilisateurs qui ne parlent pas à l'instant courant. Un tel mode de réalisation permet ainsi avantageusement d'afficher sur l'écran du terminal, des informations d'image « minimalistes » qui sont associées à chacun 30 des N-2 utilisateurs qui ne parlent pas à l'instant courant, les données d'image fixe étant beaucoup moins coûteuses à transmettre que les données vidéo. De cette façon, 7 les conditions de suivi de la vidéo conférence par l'utilisateur du terminal s'en trouvent nettement améliorées. Selon un mode de réalisation particulier, la réception des N-2 flux de données d'image fixe est mise en oeuvre en fonction du débit de transmission courant des 5 données depuis le dispositif de traitement vers le terminal de communication considéré. Un tel mode de réalisation permet ainsi au terminal considéré de recevoir les données d'images fixes des N-2 flux, uniquement dans le cas où le débit de transmission de données, depuis le dispositif de traitement de flux vers le terminal considéré, est suffisant. 10 Les différents modes ou caractéristiques de réalisation précités peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé de communication par vidéo conférence tel que défini ci-dessus. L'invention concerne également un terminal de communication par vidéo conférence avec au moins un autre terminal de communication, les deux terminaux 15 appartenant à un ensemble de N terminaux de communication, tel que Nk2, associés respectivement à N utilisateurs, comprenant un module de traitement qui est agencé pour recevoir, en provenance d'un dispositif de traitement de N flux vidéo ou de N flux audio et vidéo émis respectivement par les N terminaux, N-1 flux de données traités tels qu'associés respectivement aux N-1 utilisateurs autres que l'utilisateur du terminal 20 de communication par vidéo conférence, les N-1 flux de données contenant chacun une pluralité de paquets de données audio et/ou vidéo. Un tel terminal est remarquable en ce que le module de traitement est agencé pour : - compter les paquets de données non reçus, 25 - le nombre de paquets de données non reçus étant supérieur à un nombre prédéterminé et un des N-1 utilisateurs parlant à l'instant courant, requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de données associé à celui des N-1 utilisateurs qui parle à l'instant courant, 30 - en réponse à la requête, recevoir uniquement les données vidéo du flux de données audio et vidéo associé à celui des N-1 utilisateurs qui parle à l'instant 8 courant, - restituer visuellement uniquement le flux correspondant aux données vidéo reçues. Selon un mode de réalisation particulier, le module de traitement réitère 5 plusieurs fois le comptage du nombre de paquets de données non reçus au cours de la vidéo conférence. Selon un mode de réalisation particulier, l'action mise en oeuvre par le module de traitement de requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de 10 données associé à celui des N-1 utilisateurs qui parle à l'instant courant, comprend ce qui suit : - envoyer au dispositif de traitement une requête contenant un identifiant relatif à celui des N-1 utilisateurs qui parle à l'instant courant, l'identifiant étant associé à une information d'activation de la réception des paquets de données audio et vidéo 15 du flux de données correspondant à l'utilisateur qui parle à l'instant courant. Selon un mode de réalisation particulier, l'action mise en oeuvre par le module de traitement de requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de données associé à celui des N-1 utilisateurs qui parle à l'instant courant, comprend ce 20 qui suit : envoyer au dispositif de traitement : - une première requête contenant un identifiant relatif à celui des N-1 utilisateurs qui parle à l'instant courant, l'identifiant étant associé à une information d'activation de la réception des paquets de données audio et vidéo du flux de données 25 correspondant à l'utilisateur qui parle à l'instant courant, et/ou - N-2 autres requêtes contenant chacune un identifiant relatif à un utilisateur qui ne parle pas à l'instant courant, l'identifiant étant associé à une information de désactivation de la réception des paquets de données vidéo du flux de données correspondant à l'utilisateur qui ne parle pas à l'instant courant. 30 Selon un mode de réalisation particulier, le module de traitement met en oeuvre en outre ce qui suit, en réponse à l'envoi de la requête d'interruption de la réception 9 des paquets de données vidéo des flux de données : - recevoir, en provenance du dispositif de traitement, N-2 flux de données associés respectivement aux N-2 utilisateurs qui ne parlent pas à l'instant courant, tout flux considéré, parmi les N-2 flux, contenant des données d'image fixe 5 associée à l'utilisateur correspondant au flux considéré, - restituer les N-2 flux de données d'image fixe simultanément au flux de données audio et vidéo associé à l'utilisateur qui parle à l'instant courant. Selon un mode de réalisation particulier, la réception, par le module de traitement, des N-2 flux de données d'image fixe est mise en oeuvre en fonction du 10 débit de transmission courant des données depuis le dispositif de traitement vers le terminal de communication considéré. L'invention concerne également un programme d'ordinateur pour mettre en oeuvre des instructions de code de programme pour l'exécution des étapes du procédé de communication par vidéo conférence selon l'invention, lorsque le programme est 15 exécuté dans un terminal de communication. Un tel programme peut utiliser n'importe quel langage de programmation et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. 20 L'invention concerne également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes du procédé de communication par vidéo conférence selon l'invention, lorsque le programme est exécuté dans un terminal de communication tel que mentionné ci-dessus. 25 Les supports d'enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM (abréviation anglaise de « Read-Only Memory »), par exemple un CD ROM ou une ROM de circuit microélectronique, une clé USB ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou bien 30 encore tel qu'une mémoire vive RAM (abréviation anglaise de « Random Access Memory »). 10 D'autre part, le support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. 5 Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé d'établissement de communication précité. Brève description des dessins 10 D'autres caractéristiques et avantages apparaîtront à la lecture de plusieurs modes de réalisation particuliers de l'invention, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels : - la figure 1 est une vue schématique et générale d'une architecture dans laquelle est mis en oeuvre le procédé de communication par vidéo conférence dans un 15 mode de réalisation particulier de l'invention, - la figure 2 représente un terminal de communication de vidéo conférence dans un mode de réalisation particulier de l'invention, - les figures 3A à 3C représentent les principales étapes d'un procédé de communication par vidéo conférence selon un premier mode de réalisation particulier 20 de l'invention, - les figures 4A à 4E représentent respectivement cinq modes d'affichage mis en oeuvre dans le procédé de communication par vidéo conférence des figures 3A à 3C, - les figures 5A et 5B représentent les principales étapes d'un procédé de 25 communication par vidéo conférence selon un deuxième mode de réalisation particulier de l'invention. Description détaillée d'un mode particulier de réalisation d'architecture de vidéo conférence 30 La figure 1 représente un environnement dans lequel est mis en oeuvre le procédé de communication par vidéo conférence selon l'invention. 11 Dans un souci de clarté de la figure 1, certains éléments bien connus de cet environnement ne sont pas représentés. De tels éléments sont par exemple des serveurs, des noeuds, des stations de base, des passerelles ou encore d'autres entités du réseau de télécommunications utilisé dans cet environnement. 5 Sur la figure 1 sont représentés : - un dispositif de traitement de flux audio vidéo PVC, tel que par exemple un pont de gestion de vidéo conférence, - un ensemble de N terminaux de communication TER,, TER2, TERk,..., TERN, tel que 1 associés respectivement à N 10 utilisateurs U1, U2, UN et aptes à se connecter au pont PVC, via un réseau de communication RC tel que par exemple de type IP (abréviation anglaise de « Internet Protocol »). Chaque terminal de communication comprend une interface de connexion au réseau de communication RC, via par exemple un réseau local (non représenté), par 15 exemple sans fil, en particulier du type WiFi ou CPL (abréviation de « courants porteurs en ligne »). En variante, l'interface de connexion est par exemple, de type xDSL, fibre ou encore 3G, 4G, 5G, etc.... Un exemple d'interface de connexion est un navigateur web. Un terminal de communication donné TER, est par exemple à titre non 20 exhaustif : - un téléphone portable, et/ou - un smartphone (« téléphone intelligent »), et/ou - une tablette, et/ou - un ordinateur portable, et/ou 25 - un ordinateur personnel de type PC, et/ou - une télévision connectée, - etc.... En relation avec la figure 2, on considère maintenant la structure simplifiée d'un 30 terminal de communication donné TER, selon un exemple de réalisation de l'invention. De façon connue en soi, le terminal de communication TER, comprend : 12 - une interface de connexion IC qui est adaptée pour communiquer, via le réseau de communication RC, selon par exemple le protocole http (abréviation anglaise de « HyperText Transfer Protocol »), avec le pont de gestion de vidéo conférence PVC de la figure 1, 5 - un module de réception REC de flux de données audio vidéo ou de flux de données vidéo émis en provenance du pont de gestion de vidéo conférence, - une interface IT de traitement des interactions utilisateurs, - un écran de visualisation EC, - un haut-parleur HP, 10 - une caméra CAM, - une interface DEC de décodage audio/vidéo des contenus de type texte, audio, vidéo ou audiovisuel, ladite interface étant adaptée pour transmettre les signaux décodés à l'écran EC ou dans le haut-parleur HP. Selon l'invention : 15 - un flux de données audio et vidéo contient une pluralité de paquets de données audio et vidéo, - un flux de données vidéo contient une pluralité de paquets de données vidéo. Le terminal de communication TER, comprend des ressources physiques et/ou 20 logicielles, en particulier un module de traitement MT pour mettre en oeuvre le procédé de communication par vidéo conférence selon l'invention, qui va être décrit ci-dessous. Le module de traitement MT contient un processeur PROC piloté par un programme d'ordinateur PG. A l'initialisation, les instructions de code du programme d'ordinateur PG sont 25 par exemple chargées dans une mémoire RAM, notée MR, avant d'être exécutées par le module de traitement MT. Selon l'invention, le terminal de communication TER, comprend également un module CPT de comptage de paquets de données non reçus en provenance du pont de gestion de vidéo conférence PVC. 30 Selon l'invention, le terminal de communication TER, comprend également une mémoire de stockage MEM qui est adaptée pour stocker une valeur prédéterminée 13 d'un nombre I de paquets de données non reçus en provenance du pont de gestion de vidéo conférence PVC. A titre optionnel, le terminal de communication TER, comprend également un module DAC de détection d'activité vocale piloté par le processeur PROC du module 5 de traitement MT. Le module DAC est représenté en pointillé sur la figure 2 est sera décrit plus loin en relation avec un deuxième mode de réalisation du procédé de communication par vidéo conférence. Précisons ici que le terme module utilisé dans la présente demande peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un 10 ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble 15 matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). Premier mode de réalisation du procédé de communication par vidéo conférence En référence aux figures 3A et 3B, on décrit maintenant le déroulement d'un 20 procédé de communication par vidéo conférence selon un premier mode de réalisation de l'invention, mettant en oeuvre un comptage des paquets de données non reçus en provenance du pont de gestion de vidéo conférence PVC, dans au moins un des terminaux de communication TER1, TER2, TERk,..., TERN de la figure 1, tel que par exemple le terminal de communication TER, représenté sur la 25 figure 2. Il est supposé que chacun des terminaux TER1, TER2, TERk,..., TERN a téléchargé au préalable une application de vidéo conférence spécifique, cette application spécifique étant commune à l'ensemble des terminaux. Le procédé de communication par vidéo conférence met d'abord en oeuvre une 30 initialisation S1 de la vidéo conférence. A cet effet, en référence à la figure 3A, un des terminaux de communication TER1, TER2, TERk,..., TERN de la 14 figure 1 envoie, en S100, au pont de gestion de vidéo conférence PVC, via le réseau RC, un message M1 de demande de création d'une vidéo conférence, ledit message M1 comprenant classiquement un identifiant associé au terminal qui envoie le message et un identifiant associé à chaque terminal d'un utilisateur invité à la vidéo 5 conférence. A titre d'exemples non exhaustifs, un tel identifiant peut être : - l'identifiant d'appel MSISDN correspondant de manière unique à la carte SIM (en anglais « Subscriber Identity Module ») qui est fournie par l'opérateur du réseau de communication auprès duquel s'est inscrit l'utilisateur d'un des N terminaux 10 de communication, - un identifiant URI (abréviation anglaise de « Uniform Resource Identifier »), - une adresse de messagerie électronique, - etc... 15 Ainsi, les N terminaux TER,, TER2, TERk,..., TERN sont associés respectivement à N identifiants ID1, ID2, ID,,..., ID;,..., IDk,..., IDN du type précité. On suppose par exemple que les N terminaux de communication participent à la vidéo conférence requise par le terminal requérant. En S101, le pont de gestion de vidéo conférence PVC reçoit le message Ml. 20 En S102, le pont de gestion de vidéo conférence PVC extrait les identifiants ID1, ID2, ID,,..., IDN du message Ml. En S103, le pont de gestion de vidéo conférence PVC envoie un message M2 d'invitation à la vidéo conférence proposée par le terminal de communication requérant à chaque terminal de communication associé à un identifiant correspondant extrait en 25 S102. Le message M2 contient un lien Internet (LI) vers la vidéo conférence à établir. En S104, chacun des N terminaux reçoit le message M2. En S105, chacun des N terminaux se connecte au pont de vidéo conférence PVC à l'aide du lien Internet contenu dans le message M2. A cet effet, les N terminaux envoient respectivement, à destination du pont de gestion de vidéo conférence PVC, N 30 flux de données vidéo ou bien N flux de données audio et vidéo Fl, F2, ..., Fk,..., FN représentant respectivement les N utilisateurs U1, U2, Uj,..., Uk,..., 15 UN de ces terminaux. En S106, le pont de gestion de vidéo conférence PVC reçoit les N flux vidéo ou bien audio et vidéo Fl, F2, ..., FN. En S107, le pont de gestion de vidéo conférence PVC traite ces différents flux, 5 générant une vidéo mosaïque VM1 contenant les N flux vidéo reçus en S106. Comme représenté sur la figure 4A, la vidéo mosaïque VM1 est configurée de façon à ce que, en début de vidéo conférence, les N flux vidéo soient affichés sur l'écran EC (figure 2) d'un terminal de communication donné TER,, dans respectivement N fenêtres de même taille. 10 En S108, le pont de gestion de vidéo conférence PVC transmet un message M3 à chacun des N terminaux invités, le message M3 contenant la vidéo mosaïque VM1. En S109, chacun des N terminaux de communication reçoit le message M3. En S110, le décodeur DEC de chacun des N terminaux de communication 15 décode la vidéo mosaïque VM1 contenue dans le message M3 reçu. En S111, les N flux audio vidéo sont affichés sur l'écran EC de chacun des N terminaux, respectivement dans N fenêtres de même taille. Conformément à l'invention, lors de l'initialisation S1, chacun des N terminaux procède, en S2, à un téléchargement depuis le pont de gestion de vidéo conférence 20 PVC, d'une procédure de comptage des paquets de données audio/vidéo non reçus parmi les flux reçus en provenance du pont de gestion de vidéo conférence PVC. Un tel téléchargement est transparent pour les utilisateurs U1 à UN. Pour un terminal de communication donné TER,, la procédure de comptage est téléchargée dans le module CPT de comptage tel que représenté sur la figure 2. 25 La procédure de comptage est par exemple encapsulée dans le message d'invitation M2 envoyé en S103 à chacun des N terminaux ou encore dans le message M3 envoyé en S108. Selon un autre mode de réalisation, la procédure de comptage est téléchargée automatiquement par chacun des N terminaux lors de la connexion S105 de ces derniers au pont de gestion de vidéo conférence PVC. 30 Une fois que l'initialisation S1 de la vidéo conférence et que le téléchargement S2 sont terminés, conformément au premier mode de réalisation de l'invention et en 16 référence à la figure 3B, pour un terminal de communication donné TER,, une opération de traitement S3 est mise en oeuvre par le terminal TER, de la façon suivante : En S300, le module de réception REC du terminal TER, reçoit, en provenance 5 du pont de gestion de vidéo conférence PVC, via le réseau RC, N-1 flux de données traités par le pont, les N-1 flux étant associés respectivement aux N-1 utilisateurs participant à la vidéo conférence, autres que l'utilisateur du terminal TER,. Chacun des N-1 flux reçus contient classiquement une pluralité de paquets de données vidéo et audio. De façon connue en soi, pour chacun des N-1 flux reçus, les 10 paquets de données vidéo sont numérotés dans un ordre prédéfini. Il en est de même pour les paquets de données audio. En S301, au bout d'une durée prédéterminée de quelques secondes, par exemple 5 secondes, le module de traitement MT du terminal TER, active alors le module de comptage CPT (figure 2) qui procède au comptage des paquets de 15 données audio/vidéo qui n'ont pas été reçus en provenance du pont PVC. Soit NB le nombre de paquets non reçus qui ont été comptés. En S302, si le module de traitement MT compare le nombre NB de paquets non reçus à la valeur d'un nombre prédéterminé I de paquets non reçus, tel que stocké dans la mémoire MEM de la figure 2. Selon un exemple non exhaustif, 1=8. 20 Selon une première option, si NB l, l'interface de communication IC du terminal TER, envoie au pont de gestion de vidéo conférence PVC, via le réseau RC, une requête M4 d'interruption de la réception des paquets de données vidéo 25 contenus dans les N-2 flux associés respectivement aux N-2 utilisateurs qui ne parlent pas à l'instant courant. En réponse à la requête M4, le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, uniquement le flux de données audio et vidéo F, associé à l'utilisateur U, qui a été détecté, parmi les N-1 utilisateurs, comme 30 parlant à l'instant courant. En S305, le flux de données audio et vidéo F, associé à l'utilisateur U, qui parle 18 à l'instant courant est reçu par le module de réception REC (figure 2) du terminal TER,. En S305, les flux de données uniquement audio associés aux N-2 qui ne parlent pas à l'instant courant sont également reçus par le module de réception REC (figure 2) du terminal TER,. 5 En S306, le flux de données audio et vidéo F, associé à l'utilisateur Li, qui parle à l'instant courant est restitué par le terminal TER,, après avoir été préalablement décodé par le décodeur DEC de la figure 2. A cet effet, les données audio relatives à l'utilisateur Li, sont restituées par le(s) haut-parleur(s) HP de la figure 2, tandis que les données vidéo relatives à l'utilisateur 10 U sont affichées sur l'écran EC (figure 2). Selon un premier mode d'affichage représenté à la figure 4C, les données vidéo relatives à l'utilisateur Li, sont affichées en plein écran. Selon un deuxième mode d'affichage représenté à la figure 4D, les données vidéo relatives à l'utilisateur Li, sont affichées dans une fenêtre disposée par exemple 15 au centre de l'écran EC. Autour de cette fenêtre centrale sont affichées N-1 fenêtres de plus petite taille que la fenêtre centrale, ces N-1 fenêtres étant grisées puisque que correspondant respectivement aux N-1 flux exempts de données vidéo. Eventuellement, comme représenté sur la figure 4E, les données vidéo du flux F, associé à l'utilisateur UT, peuvent être affichées dans une des N-1 fenêtres, puisque le 20 flux F, est généré en local au niveau du terminal TER,. Selon un premier exemple, la requête M4 d'interruption de la réception des paquets de données vidéo contenus dans les N-2 flux associés respectivement aux N2 utilisateurs qui ne parlent pas à l'instant courant est un message qui contient : - l'identifiant ID, de l'utilisateur UT, parlant à l'instant courant, 25 - une information d'activation de la réception des données vidéo du flux correspondant FJ, se présentant par exemple sous la forme « video : 1 », - éventuellement une information d'activation de la réception des données audio du flux correspondant FJ, se présentant par exemple sous la forme « audio' : 1 ». 30 Selon un deuxième exemple, la requête M4 d'interruption de la réception des paquets de données vidéo contenus dans les N-2 flux associés respectivement aux N- 19 2 utilisateurs qui ne parlent pas à l'instant courant comprend ; - un message qui contient : - l'identifiant ID, de l'utilisateur UT, parlant à l'instant courant, - une information d'activation de la réception des données vidéo 5 du flux correspondant Fi, se présentant par exemple sous la forme « video : 1 », - éventuellement une information d'activation de la réception des données audio du flux correspondant Fi, se présentant par exemple sous la forme « audio' : 1 », - N-2 autres messages contenant chacun : 10 - un identifiant d'utilisateur ne parlant pas à l'instant courant, autre que l'utilisateur UT, du terminal TER,, - une information de désactivation de la réception des données vidéo de chacun des N-2 flux respectifs, se présentant par exemple sous la forme « video : 0 », 15 - éventuellement une information d'activation de la réception des données audio de chacun des N-2 flux respectifs, se présentant par exemple sous la forme « audio' : 1 ». En variante de ce deuxième exemple, la requête M4 d'interruption de la réception des paquets de données vidéo contenus dans les N-2 flux associés 20 respectivement aux N-2 utilisateurs qui ne parlent pas à l'instant courant pourrait comprend uniquement les N-2 messages contenant chacun : - un identifiant d'utilisateur ne parlant pas à l'instant courant, autre que l'utilisateur UT, du terminal TER,, - une information de désactivation de la réception des données vidéo de 25 chacun des N-2 flux respectifs, se présentant par exemple sous la forme « video : 0 », - éventuellement une information d'activation de la réception des données audio de chacun des N-2 flux respectifs, se présentant par exemple sous la forme « audio' : 1 ». 30 Quel que soit le premier exemple ou le deuxième exemple de requête M4 considéré, à réception de cette dernière, le pont PVC est configuré pour envoyer au 20 terminal TER, : - le flux F, avec ses données audio et vidéo, - les N-2 autres flux contenant uniquement les données audio des N-2 utilisateurs respectifs qui ne parlent pas à l'instant courant. 5 Selon une variante de réalisation du premier mode de réalisation représentée à la figure 3C, en réponse à la requête M4, le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC : - le flux de données audio et vidéo F, associé à l'utilisateur Li, qui a été détecté, parmi les N-1 utilisateurs, comme parlant à l'instant courant, et 10 - en association avec chacun des N-2 autres utilisateurs qui ne parlent pas à l'instant courant, respectivement N-2 flux contenant des données d'image fixe représentative des N-2 utilisateurs correspondants. En S3050, le flux de données audio et vidéo F, associé à celui des N-1 utilisateurs qui parle à l'instant courant est reçu par le module de réception REC (figure 15 2) du terminal TER,, de même que les N-2 flux de données d'image fixe. En S3060, le flux de données audio et vidéo F, associé à l'utilisateur Li, qui parle à l'instant courant est restitué par le terminal TER,. Comme illustré en figure 3C, le flux vidéo F, est affiché simultanément aux N-2 flux d'image fixe correspondant respectivement aux N-2 utilisateurs, autres que l'utilisateur UT,, qui ne parlent pas à 20 l'instant courant. Eventuellement, les données vidéo du flux F, associé à l'utilisateur UT, peuvent également être affichées dans une des N-1 fenêtres, puisque le flux F, est généré en local au niveau du terminal TER,. Dans l'exemple représenté sur la figure 3C, les données d'image fixe de chacun des N-2 utilisateurs appartiennent à une image fixe, par exemple de type Infra, qui a 25 été extraite par le pont PVC à partir respectivement des N-2 flux vidéo représentatifs des N-2 utilisateurs, tels que reçus par le pont PVC. La variante de la figure 3C est par exemple mise en oeuvre dans le cas où le pont de gestion de vidéo conférence PVC détermine que le débit de transmission depuis le pont PVC vers le terminal TER, a une valeur suffisante pour permettre la 30 transmission au terminal TER, des données d'image fixe correspondant à chacun des N-2 utilisateurs qui ne parlent pas à l'instant courant. 21 Une telle variante permet ainsi d'optimiser, pour l'utilisateur UT,, les conditions de visualisation de la vidéo conférence. Comme illustré en figure 3C, les données d'image fixe reçues en S3060 par le module de réception REC du terminal TER sont rafraîchies à intervalles réguliers, par 5 exemple de quelques secondes, tant que le débit de transmission des données transmission depuis le pont PVC vers le terminal TER, se maintient à une valeur suffisante. Dans un souci de clarté de la figure 3C, seul le rafraîchissement des données d'image fixe pour les utilisateurs UT1, UT2 et UTk est représenté. Le fait de ne plus recevoir les données vidéo ou bien de ne recevoir que les 10 données d'image fixe des N-2 flux correspondant respectivement aux N-2 utilisateurs, autres que l'utilisateur UT,, qui ne parlent pas à l'instant courant, économise grandement la bande passante du canal de transmission de données audio et/ou vidéo depuis le pont de vidéo conférence PVC vers le terminal TER,. De cette manière, il se peut qu'à l'issue de l'opération S306, le débit de transmission de données depuis le 15 pont de vidéo conférence PVC vers le terminal TER, soit revenu à une valeur permettant au terminal TER, de recevoir à nouveau les données vidéo de chacun des N-1 flux. A cet effet, selon une première variante du premier mode de réalisation de l'invention, le module de traitement MT de la figure 2 déclenche en S307 une itération 20 de l'opération S301 de comptage des paquets non reçus. L'itération S307 est mise en oeuvre une pluralité de fois durant la vidéo conférence, par exemple à intervalles de temps réguliers. En référence à la figure 3B, on décrit maintenant une deuxième variante de réalisation du premier mode de réalisation de l'invention. Selon cette deuxième 25 variante représentée en pointillé sur la figure 3B, à l'issue de l'opération d'affichage S306, est mis en oeuvre ce qui suit. Au bout d'une durée prédéterminée, par exemple 60s, après l'opération d'affichage S306, le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, le flux de données audio et vidéo F, associé à l'utilisateur U, qui a été 30 détecté, parmi les N-1 utilisateurs, comme parlant à l'instant courant, mais également chacun des N-2 autres flux de données audio et vidéo. Il est supposé ici que le pont de 22 gestion de vidéo conférence PVC a déterminé que le débit de transmission depuis le pont PVC vers le terminal TER, a retrouvé une valeur suffisante pour permettre la transmission au terminal TER, de tous les paquets de données vidéo et audio de chacun des N-1 flux. 5 Par conséquent, en S308, le module de réception REC du terminal TER reçoit en provenance du pont de gestion de vidéo conférence PVC, les données vidéo et audio de chacun des N-1 flux. En S309, chacun des N flux est alors affiché sur l'écran EC (figure 2) du terminal TER,, comme par exemple selon le mode d'affichage représenté à la figure 4B. 10 Deuxième mode de réalisation du procédé de communication par vidéo conférence En référence aux figures 3A et 5A, on décrit maintenant le déroulement d'un procédé de communication par vidéo conférence selon un deuxième mode de réalisation de l'invention. Un tel deuxième mode de réalisation met en oeuvre, outre la 15 procédure précitée de comptage des paquets de données non reçus en provenance du pont de gestion de vidéo conférence PVC, dans au moins un des terminaux de communication TER,, TER2, TER,,...,TERJ,..., TERk,..., TERN de la figure 1, une procédure de détection d'activité vocale de chacun des N utilisateurs. Selon le deuxième de réalisation de l'invention, lors de l'initialisation 51 de la 20 figure 3A, chacun des N terminaux procède en outre, en S2, à un téléchargement depuis le pont de gestion de vidéo conférence PVC, d'une procédure de détection d'activité vocale de chacun des N utilisateurs. Un tel téléchargement est transparent pour les utilisateurs U1 à UN. Pour un terminal de communication donné TER,, la procédure de détection d'activité vocale est 25 téléchargée dans le module DAC de détection d'activité vocale tel que représenté sur la figure 2. La procédure de détection d'activité vocale est par exemple encapsulée dans le message d'invitation M2 envoyé en S103 à chacun des N terminaux ou encore dans le message M3 envoyé en S108. Selon un autre mode de réalisation, la procédure de 30 détection d'activité vocale est téléchargée automatiquement par chacun des N terminaux lors de la connexion S105 de ces derniers au pont de gestion de vidéo 23 conférence PVC. Une fois que l'initialisation S1 de la vidéo conférence et que le téléchargement S2 sont terminés, conformément au deuxième mode de réalisation de l'invention et en référence à la figure 5A, pour un terminal de communication donné TER,, une 5 opération de traitement S3' est mise en oeuvre par le terminal TER, de la façon suivante : En S300', le module de réception REC du terminal TER, reçoit, en provenance du pont de gestion de vidéo conférence PVC, via le réseau RC, N-1 flux de données traités par le pont, les N-1 flux étant associés respectivement aux N-1 utilisateurs 10 participant à la vidéo conférence, autres que l'utilisateur du terminal TER,. Chacun des N-1 flux reçus contient classiquement une pluralité de paquets de données vidéo et audio ou seulement vidéo si l'utilisateur ne parle pas à l'instant courant. De façon connue en soi, pour chacun des N-1 flux reçus, les paquets de données vidéo sont numérotés dans un ordre prédéfini. Il en est de même pour les 15 paquets de données audio. En S300', le terminal TER, reçoit en outre, en provenance du pont de gestion de vidéo conférence PVC : - une information IAV, relative à l'activité vocale de l'utilisateur U1 en association avec l'identifiant ID1, 20 - une information IAV2 relative à l'activité vocale de l'utilisateur U2 en association avec l'identifiant ID2, - une information IAV, relative à l'activité vocale de l'utilisateur U, en association avec l'identifiant ID,, 25 - une information lAV, relative à l'activité vocale de l'utilisateur U, en association avec l'identifiant ID], - une information IAVk relative à l'activité vocale de l'utilisateur Uk en 30 association avec l'identifiant IDk, 24 - une information IAVN relative à l'activité vocale de l'utilisateur UN en association avec l'identifiant IDN. L'information IAV, d'un utilisateur donné U, prend une première valeur VAL1 représentative de la présence d'activité vocale de cet utilisateur ou une deuxième 5 valeur VAL2 représentative de l'absence d'activité vocale de cet utilisateur. A titre d'exemple, VAL1=1 et VAL2=0. Selon un mode de réalisation, une telle information est déterminée à l'instant courant par le pont de gestion de vidéo conférence PVC, par analyse des paquets audio contenus dans les N flux audio vidéo reçus respectivement en provenance des N 10 terminaux. Selon un autre mode de réalisation, une telle information est déterminée individuellement à l'instant courant par chacun des N terminaux de communication puis envoyée par chaque terminal au pont de gestion de vidéo conférence PVC qui concatène alors chaque association d'informations lAV1-1D1, IAV2-1D2,..., IAVN-IDN qui 15 a été reçue en S300'. En S301', au bout d'une durée prédéterminée de quelques secondes, par exemple 5 secondes, le module de traitement MT du terminal TER, active le module de comptage CPT (figure 2) qui procède au comptage des paquets de données audio/vidéo non reçus en provenance du pont de gestion de vidéo conférence PVC. 20 Soit NB le nombre de paquets non reçus qui ont été comptés. En S302', si le module de traitement MT compare le nombre NB de paquets non reçus à la valeur d'un nombre prédéterminé Ide paquets non reçus, tel que stocké dans la mémoire MEM de la figure 2. Selon un exemple non exhaustif, 1=8. Selon une première option, si NB l, l'interface de communication IC du terminal TER, envoie au pont de gestion de vidéo conférence PVC, via le réseau RC, une requête M4' d'interruption de la réception des paquets de données vidéo contenus dans les N-2 flux associés respectivement aux N-2 utilisateurs qui ne parlent 20 pas à l'instant courant. Des exemples de requête d'interruption ont déjà été mentionnés ci-dessus en liaison avec la figure 3B et ne seront pas à nouveau décrits ici. En réponse à la requête M4', le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, uniquement le flux de données audio et 25 vidéo associé à l'utilisateur que le terminal TER, a détecté, parmi les N-1 utilisateurs, comme parlant à l'instant courant, en appliquant la procédure de détection d'activité vocale décrite plus haut. Ainsi, si au cours de la procédure de détection d'activité vocale réalisée par le module DAC du terminal TER, de la figure 2, c'est l'opération de test S322' qui est mise 30 en oeuvre : - si le test 322' est positif, en réponse à la requête M4', le pont de 30 gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, uniquement le flux de données audio et vidéo Fp - si le test 322' est négatif, en réponse à la requête M4', le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, en 5 fonction du résultat du test S331' de la figure 5B : - uniquement le flux de données audio et vidéo F, si le résultat du test S331' est négatif, - uniquement le flux de données audio et vidéo Fk si le résultat du test S331' est négatif. 10 En S305', le flux de données audio et vidéo associé à celui des N-1 utilisateurs qui a été détecté par le terminal TER, comme parlant à l'instant courant est reçu par le module de réception REC (figure 2) du terminal TER,. En S305', les flux de données uniquement audio associés aux N-2 utilisateurs qui n'ont pas été détecté par le terminal TER, comme parlant à l'instant courant sont 15 également reçus par le module de réception REC (figure 2) du terminal TER,. En S306', le flux de données audio et vidéo associé à l'utilisateur ayant été détecté par le terminal TER, comme parlant à l'instant courant est restitué par le terminal TER,. A cet effet, les données audio relatives à l'utilisateur ayant été détecté par le 20 terminal TER, comme parlant à l'instant courant sont restituées par le(s) haut-parleur(s) HP de la figure 2, après décodage de ces dernières par le décodeur DEC, tandis que les données vidéo relatives à l'utilisateur ayant été détecté par le terminal TER, comme parlant à l'instant courant sont affichées sur l'écran EC (figure 2), après décodage de ces dernières par le décodeur DEC. 25 Selon la variante de réalisation décrite en référence à la figure 3C, en réponse à la requête M4', le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC : - le flux de données audio et vidéo associé à l'utilisateur qui a été détecté parmi les N-1 utilisateurs, par le terminal TER,, comme parlant à l'instant 30 courant, et - en association avec chacun des N-2 autres utilisateurs qui ont été 31 détectés par le terminal TER, comme ne parlant pas à l'instant courant, respectivement N-2 flux contenant des données d'image fixe représentative des N-2 utilisateurs correspondants. Selon une première variante du deuxième mode de réalisation de l'invention, le 5 module de traitement MT de la figure 2 déclenche en S307' une itération de l'opération S301' de comptage des paquets non reçus. L'itération S307' est mise en oeuvre une pluralité de fois durant la vidéo conférence, par exemple à intervalles de temps réguliers. Selon une deuxième variante représentée en pointillé sur la figure 5A, à l'issue 10 de l'opération d'affichage S306', est mis en oeuvre ce qui suit. Au bout d'une durée prédéterminée, par exemple 60s, après l'opération d'affichage S306', le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, le flux de données audio et vidéo associé à l'utilisateur qui a été détecté, parmi les N-1 utilisateurs, par le terminal TER, comme parlant à l'instant 15 courant, mais également chacun des N-2 autres flux de données audio et vidéo. Il est supposé ici que le pont de gestion de vidéo conférence PVC a déterminé que le débit de transmission depuis le pont PVC vers le terminal TER, a retrouvé une valeur suffisante pour permettre la transmission au terminal TER, de tous les paquets de données vidéo et audio de chacun des N-1 flux. 20 Par conséquent, en S308', le module de réception REC du terminal TER reçoit en provenance du pont de gestion de vidéo conférence PVC, les données vidéo et audio de chacun des N-1 flux. En S309', chacun des N flux est alors affiché sur l'écran EC (figure 2) du terminal TER,, comme par exemple selon un mode d'affichage similaire à celui qui est 25 représenté à la figure 4B. Il va de soi que les modes de réalisation qui ont été décrits ci-dessus ont été donnés à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention. REVENDICATIONS1. Procédé de communication par vidéo conférence entre N terminaux de communication, tel que Nk2, associés respectivement à N utilisateurs, mettant en oeuvre, au niveau d'un terminal de communication (TER,) considéré parmi les N terminaux, la réception, en provenance d'un dispositif (PVC) de traitement de N flux vidéo ou de N flux audio et vidéo émis respectivement par les N terminaux, de N-1 flux de données traités tels qu'associés respectivement aux N-1 utilisateurs autres que l'utilisateur du terminal considéré, les N-1 flux de données contenant chacun une pluralité de paquets de données audio et/ou vidéo, le procédé étant caractérisé en ce qu'il met en oeuvre ce qui suit, au niveau du terminal de communication considéré (TER,) : - compter (S301 ; S301') les paquets de données non reçus, - le nombre de paquets de données non reçus étant supérieur à un nombre prédéterminé (I) et un des N-1 utilisateurs parlant à l'instant courant, requérir (S304 ; S304') auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de données (FJ) associé à celui des N-1 utilisateurs qui parle à l'instant courant, - en réponse à la requête, recevoir (S305 ; S305') uniquement les données vidéo du flux de données audio et vidéo (FJ) associé à celui des N-1 utilisateurs qui parle à l'instant courant, - restituer visuellement (S306 ; S306') uniquement le flux correspondant aux données vidéo reçues. 2. Procédé de communication selon la revendication 1, dans lequel l'action de comptage du nombre de paquets de données non reçus est réitérée (S308 ; S310 ; S308' ; S310') plusieurs fois au cours de la vidéo conférence. 3. Procédé de communication selon la revendication 1 ou 2, dans lequel l'action de requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de données (FJ) 33 associé à celui des N-1 utilisateurs qui parle à l'instant courant, comprend ce qui suit : - envoyer au dispositif de traitement une requête contenant un identifiant relatif à celui des N-1 utilisateurs qui parle à l'instant courant, l'identifiant étant associé à une information d'activation de la réception des paquets de données audio et vidéo du flux 5 de données correspondant à l'utilisateur qui parle à l'instant courant. 4. Procédé de communication selon la revendication 1 ou 2, dans lequel l'action de requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de données (FJ) 10 associé à celui des N-1 utilisateurs qui parle à l'instant courant, comprend ce qui suit : - envoyer au dispositif de traitement : - une première requête contenant un identifiant relatif à celui des N-1 utilisateurs qui parle à l'instant courant, l'identifiant étant associé à une information d'activation de la réception des paquets de données audio et vidéo du flux de données 15 correspondant à l'utilisateur qui parle à l'instant courant, et/ou - N-2 autres requêtes contenant chacune un identifiant relatif à un utilisateur qui ne parle pas à l'instant courant, l'identifiant étant associé à une information de désactivation de la réception des paquets de données vidéo du flux de données correspondant à l'utilisateur qui ne parle pas à l'instant courant. 20 5. Procédé de communication selon l'une quelconque des revendications 1 à 4, comprenant en outre ce qui suit, en réponse à l'envoi (S304 ; S304') de la requête d'interruption de la réception des paquets de données vidéo des flux de données : 25 - recevoir (S3050), en provenance du dispositif de traitement, N-2 flux de données associés respectivement aux N-2 utilisateurs qui ne parlent pas à l'instant courant, tout flux considéré, parmi les N-2 flux, contenant des données d'image fixe associée à l'utilisateur correspondant au flux donné, - restituer (S3060) les N-2 flux de données d'image fixe simultanément 30 au flux de données (FJ) associé à l'utilisateur qui parle à l'instant courant. 34 6. Procédé de communication selon la revendication 5, dans lequel la réception des N2 flux de données d'image fixe est mise en oeuvre en fonction du débit de transmission courant des données depuis le dispositif de traitement vers le terminal de communication (TER,) considéré. 5 7. Terminal (TER,) de communication par vidéo conférence avec au moins un autre terminal de communication, les deux terminaux appartenant à un ensemble de N terminaux de communication, tel que Nk2, associés respectivement à N utilisateurs, comprenant un module de traitement (MT) qui est agencé pour recevoir, en 10 provenance d'un dispositif de traitement de N flux vidéo ou de N flux audio et vidéo émis respectivement par les N terminaux, N-1 flux de données traités tels qu'associés respectivement aux N-1 utilisateurs autres que l'utilisateur du terminal de communication par vidéo conférence, les N-1 flux de données contenant chacun une pluralité de paquets de données audio et/ou vidéo, 15 le terminal de communication par vidéo conférence étant caractérisé en ce que le module de traitement (MT) est agencé pour : - compter les paquets de données non reçus, - le nombre de paquets de données non reçus étant supérieur à un nombre prédéterminé (I) et un des N-1 utilisateurs parlant à l'instant courant, requérir 20 auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des flux de données, à l'exception de ceux du flux de données (FJ) associé à celui des N-1 utilisateurs qui parle à l'instant courant, - en réponse à la requête, recevoir uniquement les données vidéo du flux de données audio et vidéo (FJ) associé à celui des N-1 utilisateurs qui parle à 25 l'instant courant, - restituer visuellement uniquement le flux correspondant aux données vidéo reçues. 8. Terminal de communication selon la revendication 7, dans lequel le module de 30 traitement (MT) réitère plusieurs fois le comptage du nombre de paquets de données non reçus au cours de la vidéo conférence. 9. Terminal de communication selon la revendication 7 ou la revendication 8, dans lequel l'action mise en oeuvre par le module de traitement (MT) de requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des 5 flux de données, à l'exception de ceux du flux de données (FJ) associé à celui des N-1 utilisateurs qui parle à l'instant courant, comprend ce qui suit : - envoyer au dispositif de traitement une requête contenant un identifiant relatif à celui des N-1 utilisateurs qui parle à l'instant courant, l'identifiant étant associé à une information d'activation de la réception des paquets de données audio et vidéo 10 du flux de données correspondant à l'utilisateur qui parle à l'instant courant. 10. Terminal de communication selon la revendication 7 ou la revendication 8, dans lequel l'action mise en oeuvre par le module de traitement (MT) de requérir auprès du dispositif de traitement l'interruption de la réception des paquets de données vidéo des 15 flux de données, à l'exception de ceux du flux de données (FJ) associé à celui des N-1 utilisateurs qui parle à l'instant courant, comprend ce qui suit : - envoyer au dispositif de traitement : - une première requête contenant un identifiant relatif à celui des N-1 utilisateurs qui parle à l'instant courant, l'identifiant étant associé à une information 20 d'activation de la réception des paquets de données audio et vidéo du flux de données correspondant à l'utilisateur qui parle à l'instant courant, et/ou - N-2 autres requêtes contenant chacune un identifiant relatif à un utilisateur qui ne parle pas à l'instant courant, l'identifiant étant associé à une information de désactivation de la réception des paquets de données vidéo du flux de 25 données correspondant à l'utilisateur qui ne parle pas à l'instant courant. 11. Terminal de communication selon l'une quelconque des revendications 7 à 10, dans lequel le module de traitement (MT) met en oeuvre en outre ce qui suit, en réponse à l'envoi de la requête d'interruption de la réception des paquets de données 30 vidéo des flux de données : - recevoir, en provenance du dispositif de traitement, N-2 flux de 36 données associés respectivement aux N-2 utilisateurs qui ne parlent pas à l'instant courant, tout flux considéré, parmi les N-2 flux, contenant des données d'image fixe associée à l'utilisateur correspondant au flux considéré, - restituer les N-2 flux de données d'image fixe simultanément au flux de 5 données (FJ) audio et vidéo associé à l'utilisateur qui parle à l'instant courant. 12. Terminal de communication selon la revendication 11, dans lequel la réception, par le module de traitement (MT), des N-2 flux de données d'image fixe est mise en oeuvre en fonction du débit de transmission courant des données depuis le dispositif de 10 traitement vers le terminal de communication (TER,) considéré. 13. Programme d'ordinateur comportant des instructions qui implémentent le procédé de communication selon l'une quelconque des revendications 1 à 6, lorsque ledit programme est exécuté sur un ordinateur. 15 14. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions qui implémentent le procédé de de communication selon l'une quelconque des revendications 1 à 6, lorsque ledit programme est exécuté par un ordinateur. 20 25 30