[go: up one dir, main page]

FR3079705A1 - Communication par video conference - Google Patents

Communication par video conference Download PDF

Info

Publication number
FR3079705A1
FR3079705A1 FR1852735A FR1852735A FR3079705A1 FR 3079705 A1 FR3079705 A1 FR 3079705A1 FR 1852735 A FR1852735 A FR 1852735A FR 1852735 A FR1852735 A FR 1852735A FR 3079705 A1 FR3079705 A1 FR 3079705A1
Authority
FR
France
Prior art keywords
video
data
current time
users
streams
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
FR1852735A
Other languages
English (en)
Inventor
Julien Godier
Johnny Rubin
Matthias Hamel
Alexandre Ferrieux
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1852735A priority Critical patent/FR3079705A1/fr
Publication of FR3079705A1 publication Critical patent/FR3079705A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/56—Arrangements for connecting several subscribers to a common circuit, i.e. affording conference facilities
    • H04M3/567—Multimedia conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1813—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast for computer conferences, e.g. chat rooms
    • H04L12/1827—Network arrangements for conference optimisation or adaptation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/32—Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/33—Flow control; Congestion control using forward notification
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/10—Multimedia information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne une communication par vidéo conférence entre N terminaux (N≥2) de N utilisateurs, implémentant ce qui suit, au niveau d'un terminal considéré : - compter (S300) les paquets de données non reçus à partir de N-1 flux reçus en provenance d'un dispositif de traitement de flux, les N-1 flux reçus étant associés respectivement à N-1 utilisateurs autres que l'utilisateur du terminal considéré, - 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) 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) 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) uniquement le flux correspondant aux données vidéo reçues.

Description

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 œuvre de communications par vidéo conférence et/ou visiophonie entre N terminaux, tel que N>2.
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 œuvre 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 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 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.
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 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 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 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 améliorations.
A cet effet, un objet de la présente invention concerne un procédé de communication par vidéo conférence entre N terminaux de communication, tel que N>2, 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 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é :
- 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 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 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 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 débit de transmission des données, depuis le dispositif de traitement de flux vers le terminal, est :
- 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 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.
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.
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.
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 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.
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 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 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 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.
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 :
- 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 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 :
- 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, 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 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 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 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é,
- 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 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 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, 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 œuvre en fonction du débit de transmission courant des 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.
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 appartenant à un ensemble de N terminaux de communication, tel que N>2, 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 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,
- 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,
- 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 vidéo reçues.
Selon un mode de réalisation particulier, le module de traitement 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.
Selon un mode de réalisation particulier, l’action mise en œuvre 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 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 de données correspondant à l’utilisateur qui parle à l’instant courant.
Selon un mode de réalisation particulier, l’action mise en œuvre 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 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 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.
Selon un mode de réalisation particulier, le module de traitement met en œuvre 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 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 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 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 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.
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.
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 encore tel qu’une mémoire vive RAM (abréviation anglaise de « Random Access Memory >>).
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.
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
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 œuvre le procédé de communication par vidéo conférence dans un 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 de l’invention,
- les figures 4A à 4E représentent respectivement cinq modes d’affichage mis en œuvre 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 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
La figure 1 représente un environnement dans lequel est mis en œuvre le procédé de communication par vidéo conférence selon l’invention.
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.
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 TER15 TER2, ..., TERi,...,TERj,.., TERk,..., TERN, tel que 1<i<j<k<N, associés respectivement à N utilisateurs Un U2, ..., U,...,Uj,..., Uk,..., 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 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 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
- 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 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 :
- 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,
- 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,
- 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 :
- 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 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 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.
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 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 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 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 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 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 TER,, TER2, ..., TERi,...,TERj,..., TERk,..., TERN de la figure 1, tel que par exemple le terminal de communication TER, représenté sur la figure 2.
Il est supposé que chacun des terminaux TER,, TER2, ..., TERi,...,TERj,..., 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 initialisation S1 de la vidéo conférence. A cet effet, en référence à la figure 3A, un des terminaux de communication TER,, TER2, ..., TERi,...,TERj,..., TERk,..., TERN de la 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 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 de communication,
- un identifiant URI (abréviation anglaise de « Uniform Resource Identifier »),
- une adresse de messagerie électronique,
- etc...
Ainsi, les N terminaux TER1; TER2, ..., TERi,...,TERj,..., TERk,..., TERN sont associés respectivement à N identifiants ID15 ID2, ..., ID,,..., IDj;..., 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 M1.
En S102, le pont de gestion de vidéo conférence PVC extrait les identifiants ID15 ID2, ..., IDi,..., IDn du message M1.
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 S102. Le message M2 contient un lien Internet (Ll) 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 flux de données vidéo ou bien N flux de données audio et vidéo P15 F2, ..., F,,...,Fj5..., Fk,..., Fn représentant respectivement les N utilisateurs Ui, U2, ..., U,,..., Uj,..., Uk,...,
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 Fb F2, ..., Fi,..., Fj,..., Fk,..., FN.
En S107, le pont de gestion de vidéo conférence PVC traite ces différents flux, 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.
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 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 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 Ut à 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.
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.
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 référence à la figure 3B, pour un terminal de communication donné TER,, une opération de traitement S3 est mise en œuvre 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 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 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 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, l=8.
Selon une première option, si NB<I, en S303, les N flux vidéo ou bien audio et vidéo sont restitués classiquement par le terminal TER,, les données vidéo de chaque flux étant préalablement décodées par le décodeur DEC, puis affichées sur l’écran EC (figure 2) du terminal TER, et les données audio préalablement décodées par le décodeur DEC puis restituées de façon sonore par le(s) haut-parleur(s) HP (figure 2) du terminal TER,.
En alternative à cette première option, les N flux vidéo ou bien audio et vidéo sont restitués classiquement par le terminal TER, si NB<I.
Dans l’exemple représenté sur la figure 4B, et de façon connue en soi, la restitution visuelle des données vidéo de chacun des N flux se présente sous la forme d’une vidéo mosaïque VM, selon laquelle :
- un flux audio vidéo F,, tel que 1<j<N, correspondant à l’un des N utilisateurs qui parle à l’instant courant, est affiché dans une fenêtre disposée par exemple au centre de l’écran EC du terminal TER,,
- les N-1 autres flux de données reçus étant affichés autour de cette fenêtre, dans des fenêtres toutes de même taille et plus petites que cette dernière.
Dans l’exemple représenté sur la figure 3B, l’utilisateur Uj qui parle à l’instant courant est identifié par le terminal TER, par une valeur particulière prise par une information d’activité vocale IAV associée au flux Fj de cet utilisateur et transmise dans ce flux par le pont de gestion de vidéo conférence PVC.
Ainsi, pour chacun des N utilisateurs, l’information d’activité vocale IAV de l’utilisateur prend une première valeur V1 représentative de la présence d’activité vocale de cet utilisateur ou une deuxième valeur V2 représentative de l’absence d’activité vocale de cet utilisateur.
A titre d’exemple, V1=1 et V2=0.
Selon une deuxième option, tant que NB>I et qu’un des N-1 utilisateurs autres que l’utilisateur U, du terminal TER, a été détecté comme parlant à l’instant courant, autrement dit pour lequel l’information d’activité vocale IAV associé à son flux est à la valeur V1, en S304, le module de traitement MT commande l’interface de communication IC du terminal TER, pour qu’elle 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 N2 utilisateurs qui ne parlent pas à l’instant courant.
En alternative à cette deuxième option, si NB>I, 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 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 Fj associé à l’utilisateur Uj qui a été détecté, parmi les N-1 utilisateurs, comme parlant à l’instant courant.
En S305, le flux de données audio et vidéo Fj associé à l’utilisateur Uj qui parle à 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,.
En S306, le flux de données audio et vidéo Fj associé à l’utilisateur Uj 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 Q sont restituées par le(s) haut-parleur(s) HP de la figure 2, tandis que les données vidéo relatives à l’utilisateur Uj 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 Q 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 Q sont affichées dans une fenêtre disposée par exemple 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 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 IDj de l’utilisateur UTj parlant à l’instant courant,
- 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 ».
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 N19 utilisateurs qui ne parlent pas à l’instant courant comprend ;
- un message qui contient :
- l’identifiant IDj de l’utilisateur UTj parlant à l’instant courant,
- une information d’activation de la réception des données vidéo du flux correspondant Fj5 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 »,
- N-2 autres 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 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 ».
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 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 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 ».
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 terminal TER, :
- le flux Fj 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.
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 Fj associé à l’utilisateur U, qui a été détecté, parmi les N-1 utilisateurs, comme parlant à l’instant courant, et
- 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 Fj associé à celui des N-1 utilisateurs qui parle à l’instant courant est reçu par le module de réception REC (figure 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 Fj associé à l’utilisateur Uj 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 à 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 Intra, qui a é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 œuvre 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 transmission au terminal TER, des données d’image fixe correspondant à chacun des N-2 utilisateurs qui ne parlent pas à l’instant courant.
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 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 UT15 UT2 et UTk est représenté.
Le fait de ne plus recevoir les données vidéo ou bien de ne recevoir que les 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 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 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 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 Fj associé à l’utilisateur Uj qui a été 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 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.
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.
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 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 TER1; TER2, ..., TERi,...,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 S1 de la 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 Ui à UN. Pour un terminal de communication donné TER., la procédure de détection d’activité vocale est 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 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 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 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 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 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 U, en association avec l’identifiant ID,,
- 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,, . . .,
- une information lAVj relative à l’activité vocale de l’utilisateur U, en association avec l’identifiant IDj, . . .,
- une information IAVk relative à l’activité vocale de l’utilisateur Uk en association avec l’identifiant IDk,
- 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 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 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 ΙΑν,-ID,, IAV2-ID2,..., IAVN-IDN qui 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.
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, l=8.
Selon une première option, si NB<I, en S303’, les N flux vidéo ou bien audio et vidéo sont restitués par le terminal TER,, les données vidéo de chaque flux étant affichées sur l’écran EC (figure 2) du terminal TER., après avoir été décodées par le décodeur DEC et les données audio étant restituées par le(s) haut-parleur(s) HP (figure 2) du terminal TER., après avoir été décodées par le décodeur DEC.
En alternative à cette première option, les N flux vidéo ou bien audio et vidéo sont restitués classiquement par le terminal TER, si NB<I.
Dans l’exemple représenté sur la figure 5A, est alors mise en œuvre une procédure de détection d’activité vocale afin de déterminer si :
- un ou plusieurs utilisateurs parmi N parlent à l’instant courant, ou bien
- aucun utilisateur parmi N ne parle à l’instant courant.
A cet effet, en S321’, le module DAC (figure 2) du terminal TER, extrait la première information ΙΑΆ reçue et détermine si la première information ΙΑΆ est à la première valeur VAL1 ou à la deuxième valeur VAL2, puis recommence ces opérations pour la deuxième information IAV2 et ainsi de suite jusqu’à l’information IAVN.
Si une seule information d’activité vocale, par exemple lAVj, est à la valeur VAL1, le terminal TER, détermine en S322’ si l’information lAVj est à la valeur VAL1 depuis un instant prédéterminé tP. La durée qui sépare l’instant courant t de l’instant prédéterminé tP est par exemple définie dans la procédure de détection d’activité vocale par un nombre K prédéterminé d’unités de temps de, par exemple, 500ms chacune. Selon un exemple de réalisation K=4.
Si oui, en S323’, le terminal TER, envoie au pont de gestion de vidéo conférence PVC, via le réseau RC, un message de requête en réception :
- du flux audio vidéo F, associé à l’utilisateur U, ayant été détecté comme parlant depuis l’instant prédéterminé tP, en tant que flux audio vidéo principal à afficher,
- des N-1 flux audio vidéo associés respectivement aux N-1 autres utilisateurs qui n’ont pas été détectés comme parlant depuis l’instant prédéterminé tP, en tant que respectivement N-1 flux audio vidéo secondaires à afficher.
Le message de requête contient l’identifiant IDj de l’utilisateur Uj, ainsi que les N-1 autres identifiants associés respectivement aux N-1 autres utilisateurs. En variante de cet autre mode, le terminal TER, pourrait se passer de requérir, en tant que flux audio vidéo secondaire, le flux audio vidéo relatif à l’utilisateur U, ce qui permettrait de réduire les ressources en bande passante du réseau de communication RC.
En réponse au message de requête, le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, le flux audio vidéo principal Fj et les N1 ou N-2 flux audio vidéo secondaires.
En S324’, le flux audio vidéo principal Fj et les N-1 ou N-2 flux audio vidéo secondaires sont reçus par le module de réception REC (figure 2) du terminal TER,.
En S303’, les N flux vidéo ou bien audio et vidéo sont restitués classiquement par le terminal TER,, les données vidéo de chaque flux étant affichées sur l’écran EC (figure 2) du terminal TER, et les données audio étant restituées par le(s) hautparleurs) HP (figure 2) du terminal TER,, après décodage par le décodeur DEC.
Dans l’exemple représenté sur la figure 4B, et de façon connue en soi, la restitution visuelle des données vidéo de chacun des N flux se présente sous la forme d’une vidéo mosaïque VM, selon laquelle :
- un flux audio vidéo Fj, tel que 1<j<N, correspondant à l’un des N utilisateurs qui parle à l’instant courant, est affiché dans une fenêtre disposée par exemple au centre de l’écran EC du terminal TER,,
- les N-1 autres flux de données reçus étant affichés autour de cette fenêtre, dans des fenêtres de même taille et plus petites que cette dernière.
Selon un mode particulier de réalisation, le terminal TER, peut se passer de requérir en S323’ les N-1 ou N-2 flux audio vidéo secondaires. Le message envoyé en S323’ pourrait par exemple comprendre une information qui indique au pont de gestion de vidéo conférence PVC s’il renvoie au terminal TER, uniquement le flux audio vidéo principal Fj ou bien le flux audio vidéo principal Fj et les N-1 ou bien N-2 flux audio vidéo secondaires. Une telle information pourrait être un bit mis par exemple à 1 pour ne requérir que le flux audio vidéo principal ou à 0 pour requérir le flux audio vidéo principal Fj et les N-1 ou bien N-2 flux audio vidéo secondaires.
Si à l’issue de l’opération S322’, au moins deux informations lAVj et IAVk sont à la valeur VAL1, le terminal TER, met en œuvre les opérations illustrées en figure 5B.
En référence à la figure 5B, en S330’, le module DAC du terminal TER, compare l’instant t1, précédant l’instant courant t, à partir duquel l’information lAVj est passée de la deuxième valeur VAL2 à la première valeur VAL1, avec l’instant t2 précédant l’instant courant t, à partir duquel l’information IAVk est passée de la deuxième valeur VAL2 à la première valeur VAL1.
En S331’, le module DAC (figure 2) du terminal TER, sélectionne parmi les instants t1 et t2, celui qui est le plus proche de l’instant courant t.
S’il s’agit de l’instant t2, en S332’, le terminal TER, envoie au pont de gestion de vidéo conférence PVC, via le réseau RC, un message de requête en réception :
- du flux audio vidéo Fk associé à l’utilisateur Uk ayant été détecté comme parlant depuis l’instant t2 le plus proche de l’instant courant t, en tant que flux audio vidéo principal à afficher,
- des N-1 flux audio vidéo associés respectivement aux N-1 autres utilisateurs en tant que respectivement N-1 flux audio vidéo secondaires à afficher.
Le message de requête contient l’identifiant IDk de l’utilisateur Uk, ainsi que les N-1 autres identifiants associés respectivement aux N-1 autres utilisateurs. En variante de cet autre mode, le terminal TER, pourrait se passer de requérir, en tant que flux audio vidéo secondaire, le flux audio vidéo relatif à l’utilisateur U,, ce qui permettrait de réduire les ressources en bande passante du réseau de communication RC.
En réponse au message de requête, le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, le flux audio vidéo principal Fk et les N1 ou N-2 flux audio vidéo secondaires.
En S333’, le flux audio vidéo principal Fj et les N-1 ou N-2 flux audio vidéo secondaires sont reçus par le module de réception REC (figure 2) du terminal TER,.
Le procédé retourne alors en S303’ sur la figure 5A, où les N flux vidéo ou bien audio et vidéo sont restitués classiquement par le terminal TER., les données vidéo de chaque flux étant affichées sur l’écran EC (figure 2) du terminal TER, et les données audio étant restituées par le(s) haut-parleur(s) HP (figure 2) du terminal TER., après décodage par le décodeur DEC.
D’une façon similaire au mode d’affichage de la figure 4B, les N-1 flux audio vidéo secondaires sont par exemple affichés sur l’écran EC du terminal TER,, autour d’une fenêtre centrale dans laquelle est affiché le flux audio vidéo principal Fk.
En référence à la figure 5B, si à l’issue de l’opération S331 ’, il s’agit de l’instant t1, le terminal TER, envoie, en S334’, au pont de gestion de vidéo conférence PVC, via le réseau RC, un message de requête en réception:
- du flux audio vidéo Fj associé à l’utilisateur U, ayant été détecté comme parlant depuis l’instant t1 le plus proche de l’instant courant t, en tant que flux audio vidéo principal à afficher,
- des N-1 flux audio vidéo associés respectivement aux N-1 autres utilisateurs en tant que respectivement N-1 flux audio vidéo secondaires à afficher.
Le message de requête contient l’identifiant IDj de l’utilisateur Uj, ainsi que les
N-1 autres identifiants associés respectivement aux N-1 autres utilisateurs. En variante de cet autre mode, le terminal TER, pourrait se passer de requérir, en tant que flux audio vidéo secondaire, le flux audio vidéo relatif à l’utilisateur U,, ce qui permettrait de réduire les ressources en bande passante du réseau de communication RC.
En réponse au message de requête, le pont de gestion de vidéo conférence PVC envoie au terminal TER,, via le réseau RC, le flux audio vidéo principal Fj et les N1 ou N-2 flux audio vidéo secondaires.
En S335’, le flux audio vidéo principal Fj et les N-1 ou N-2 flux audio vidéo secondaires sont reçus par le module de réception REC (figure 2) du terminal TER,.
Le procédé retourne alors en S303’ sur la figure 5A, où les N flux vidéo ou bien audio et vidéo sont restitués classiquement par le terminal TER,, les données vidéo de chaque flux étant affichées sur l’écran EC (figure 2) du terminal TER, et les données audio étant restituées par le(s) haut-parleur(s) HP (figure 2) du terminal TER,, après décodage par le décodeur DEC.
D’une façon identique au mode d’affichage de la figure 4B, les N-1 flux audio vidéo secondaires sont par exemple affichés sur l’écran EC du terminal TER., autour d’une fenêtre centrale dans laquelle est affiché le flux audio vidéo principal Fj.
En référence à nouveau à la figure 5A, si en S321 ’, le module DAC (figure 2) du terminal TER, détermine qu’aucune des informations IAV1; IAV2, ..., IAV,, ..., IAVN reçues en S300’ sont à la première valeur VAL1 depuis l’instant prédéterminé tP, le module DAC détermine en S325’ si les informations IAV1; IAV2,..., IAV,, ..., IAVN reçues en S300’ sont à la deuxième valeur VAL2 depuis l’instant prédéterminé tP.
Si tel est le cas, le terminal TER, ne requiert aucun flux audio vidéo à afficher auprès du pont de gestion de vidéo conférence PVC. Dans le cas où un unique flux audio vidéo Fj était affiché à l’instant précédent t-1 sur l’écran EC du terminal TER,, en S303’ ou en S306’, le flux Fj continue d’être affiché de la même façon à l’instant courant t, comme représenté sur la figure 4C, 4D ou 4E. Dans le cas où à l’instant t-1, le flux audio vidéo Fj était affiché en tant que flux principal, avec les N-1 flux audio vidéo secondaires affichés autour du flux audio vidéo Fj, comme représenté sur la figure 4B, ces N flux audio vidéo continuent, en S303’ ou en S309’, d’être affichés de la même façon à l’instant courant t.
Si en S325’, le module DAC du terminal TER, détermine que toutes les informations IAV15 IAV2, IAV,, IAVN reçues en S300’ ne sont pas à la deuxième valeur VAL2 depuis l’instant prédéterminé tP, il est mis fin au procédé de détection d’activité vocale et le terminal TER, se met en attente de la réception, à l’instant suivant t+1, de nouvelles informations d’activité vocale IAV15 IAV2,..., IAV,, ..., IAVN relatives respectivement aux N utilisateurs, en provenance du pont de gestion de vidéo conférence PVC.
Selon une deuxième option, tant que NB>I et qu’un des N-1 utilisateurs autres que l’utilisateur U, du terminal TER, a été détecté comme parlant à l’instant courant selon la procédure de détection d’activité vocale qui a été décrite ci-dessus, en S304’, le module de traitement MT commande l’interface de communication IC du terminal TER, pour qu’elle 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 pas à l’instant courant.
En alternative à cette deuxième option, si NB>I, 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 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 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 en œuvre :
- si le test 322’ est positif, 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 Fj,
- 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 fonction du résultat du test S331’ de la figure 5B :
- uniquement le flux de données audio et vidéo Fj 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.
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 é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 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.
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 courant, et en association avec chacun des N-2 autres utilisateurs qui ont été 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 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 œuvre 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 de l’opération d’affichage S306’, est mis en œuvre 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 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.
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 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.

Claims (14)

  1. REVENDICATIONS
    1. Procédé de communication par vidéo conférence entre N terminaux de communication, tel que N>2, 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. 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. 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) 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 de données correspondant à l’utilisateur qui parle à l’instant courant.
  4. 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) 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 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.
  5. 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 :
    - 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 au flux de données (Fj) associé à l’utilisateur qui parle à l’instant courant.
  6. 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 œuvre en fonction du débit de transmission courant des données depuis le dispositif de traitement vers le terminal de communication (TER,) considéré.
  7. 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 N>2, associés respectivement à N utilisateurs, comprenant un module de traitement (MT) 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 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, 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 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 à l’instant courant,
    - restituer visuellement uniquement le flux correspondant aux données vidéo reçues.
  8. 8. Terminal de communication selon la revendication 7, dans lequel le module de 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. 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 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 du flux de données correspondant à l’utilisateur qui parle à l’instant courant.
  10. 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 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 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 données correspondant à l’utilisateur qui ne parle pas à l’instant courant.
  11. 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 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 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 (Fj) audio et vidéo associé à l’utilisateur qui parle à l’instant courant.
  12. 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 traitement vers le terminal de communication (TER,) considéré.
  13. 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.
  14. 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.
FR1852735A 2018-03-29 2018-03-29 Communication par video conference Ceased FR3079705A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1852735A FR3079705A1 (fr) 2018-03-29 2018-03-29 Communication par video conference

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1852735A FR3079705A1 (fr) 2018-03-29 2018-03-29 Communication par video conference
FR1852735 2018-03-29

Publications (1)

Publication Number Publication Date
FR3079705A1 true FR3079705A1 (fr) 2019-10-04

Family

ID=62751068

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1852735A Ceased FR3079705A1 (fr) 2018-03-29 2018-03-29 Communication par video conference

Country Status (1)

Country Link
FR (1) FR3079705A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140028785A1 (en) * 2012-07-30 2014-01-30 Motorola Mobility LLC. Video bandwidth allocation in a video conference
US20160301727A1 (en) * 2015-04-10 2016-10-13 Microsoft Technology Licensing, Llc Snapshot Capture for a Communication Session

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140028785A1 (en) * 2012-07-30 2014-01-30 Motorola Mobility LLC. Video bandwidth allocation in a video conference
US20160301727A1 (en) * 2015-04-10 2016-10-13 Microsoft Technology Licensing, Llc Snapshot Capture for a Communication Session

Similar Documents

Publication Publication Date Title
EP3840388B1 (fr) Equipement décodeur à double liaison audio
FR3092718A1 (fr) Procédé de traitement de flux audiovidéo en conférence multipartite, dispositifs, système et programme correspondants
CN112584194A (zh) 视频码流的推送方法、装置、计算机设备和存储介质
EP4184922A1 (fr) Procédé de gestion de l&#39; accès à un contenu multimédia
EP2846520B1 (fr) Procédé et dispositif d&#39;enrichissement d&#39;une communication
EP3718301B1 (fr) Communication par vidéo conférence
FR3079705A1 (fr) Communication par video conference
EP3461135A1 (fr) Procédé de gestion du droit d&#39;accès à un contenu numérique
EP3092777B1 (fr) Procede de traitement d&#39;erreur de restitution d&#39;un contenu numerique
EP3661221A1 (fr) Procédé de suivi d&#39;une émission audiovisuelle et équipement permettant sa mise en oeuvre
FR3079704A1 (fr) Communication par video conference
EP4468686A1 (fr) Basculement optimisé depuis un serveur de contenu unicast vers un serveur de contenu multicast
EP3548997B1 (fr) Procédé de gestion de la réception de contenus numériques par un dispositif de gestion
EP4564823A1 (fr) Passerelle pour encodage local de contenus de télévision numérique terrestre en segments de contenus adaptatifs sur http (has)
FR3150386A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
EP4554187A1 (fr) Téléchargement d&#39;une page web optimisé pour des pics de trafic événementiels
FR3148887A1 (fr) Procédé de gestion du traitement d’un flux vidéo dans un réseau local.
EP4654590A1 (fr) Procédé de gestion de la lecture d&#39;un contenu multimédia
EP4391521A1 (fr) Gestion de mise en veille d&#39;un terminal lecteur de flux multimédia
FR2940870A1 (fr) Systeme de distribution de flux multimedia
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique en mode économiseur d&#39;écran
FR3111497A1 (fr) Procédé de gestion de la restitution d’un contenu multimédia sur des dispositifs de restitution.
WO2011023904A1 (fr) Procede de diffusion d&#39;un contenu dans un reseau de telecommunications de maniere geolocalisee
FR2987535A1 (fr) Procede et dispositif de mise a disposition d&#39;au moins une donnee de communication
FR2905546A1 (fr) Procede et systeme de synchronisation d&#39;informations avec un flux

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20191004

RX Complete rejection

Effective date: 20200327