FR3079704A1 - Communication par video conference - Google Patents

Communication par video conference Download PDF

Info

Publication number
FR3079704A1
FR3079704A1 FR1852736A FR1852736A FR3079704A1 FR 3079704 A1 FR3079704 A1 FR 3079704A1 FR 1852736 A FR1852736 A FR 1852736A FR 1852736 A FR1852736 A FR 1852736A FR 3079704 A1 FR3079704 A1 FR 3079704A1
Authority
FR
France
Prior art keywords
received
data packets
bit rate
video
terminal
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.)
Pending
Application number
FR1852736A
Other languages
English (en)
Inventor
Julien Godier
Matthias Hamel
Alexandre Ferrieux
Johnny Rubin
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 FR1852736A priority Critical patent/FR3079704A1/fr
Publication of FR3079704A1 publication Critical patent/FR3079704A1/fr
Pending 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/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • 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
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2385—Channel allocation; Bandwidth allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147—Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/152—Multipoint control units therefor
    • 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)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (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é : - déterminer (S301) un nombre de paquets de données d'un flux envoyé par le terminal considéré à pont de gestion de vidéo conférence, qui n'ont pas été reçus par le pont, - réduire (S304) le débit, dans le cas où le nombre de paquets de données non reçus est supérieur à un nombre prédéterminé (J), - itérer (S305) l'opération de détermination, - à chaque itération, réduire (S308) le débit, tant que le débit ne passe pas sous un premier seuil prédéterminé (L) ou que le nombre de paquets de données non reçus est supérieur au nombre prédéterminé (J).

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 un traitement 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 vidéo ou bien audio vidéo reçus, éventuellement à l’exception du flux vidéo ou bien audio vidéo qui a été reçu en provenance du terminal de l’utilisateur donné.
Chaque flux audio vidéo ou bien 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 ou bien seulement 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 quels paquets de données il envoie.
De manière similaire, pour un terminal de communication donné, utilisé lors de la vidéo conférence, le flux audio vidéo ou bien vidéo, qui est envoyé à un instant courant par le terminal donné à destination du pont de gestion de vidéo conférence et qui est représentatif de l’utilisateur du terminal donné, contient l’identifiant de cet utilisateur et une pluralité de paquets de données audio et vidéo ou seulement vidéo qui sont numérotés. Ainsi, le terminal donné est capable de connaître avec précision quels paquets de données il envoie au pont.
Il arrive que certains des paquets de données envoyés par un terminal de communication donné participant à la vidéo conférence ne soient pas reçus par le pont.
Une telle situation se produit dans le cas par exemple où le débit courant de transmission de données, depuis le terminal de communication vers le pont de gestion de vidéo conférence, devient réduit pour diverses raisons, par exemple parce que, simultanément à la vidéo conférence en cours, le terminal de communication ou bien d’autres terminaux connectés au même réseau que ce dernier procèdent à la consultation de différents sites Web, ce qui provoque ainsi une congestion du trafic de transmission des données.
Dans cette situation, le pont de gestion de vidéo conférence, qui n’a pas reçu un ou plusieurs paquets de données contenu(s) dans un flux envoyé par un terminal de communication considéré utilisé dans la vidéo conférence, est capable, puisque les paquets de données sont numérotés, 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 en provenance du terminal de communication considéré. Afin de récupérer ce ou ces paquets manquants, le pont envoie au terminal de communication considéré une requête en fourniture du ou des paquets manquants, la requête contenant l’identifiant de l’utilisateur du terminal considéré et l’identifiant du ou des paquets manquants. A réception de cette requête, le terminal de communication considéré renvoie les paquets de données manquants au pont de gestion de vidéo conférence.
Un inconvénient de ce mécanisme d’échange de messages entre le pont de gestion de vidéo conférence et le terminal de communication considéré réside dans le fait qu’à force d’être répété au cours de la vidéo conférence, il entraîne une congestion du réseau de communication qui relie le pont de vidéo conférence et les terminaux utilisés dans la vidéo conférence. Une telle congestion peut en outre provoquer un ralentissement de la restitution des flux reçus en provenance du pont et/ou de l’envoi, par le terminal au pont, du flux représentatif de l’utilisateur du terminal. 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 et vice-versa retrouve un niveau correct, les flux vidéo affichés sur l’écran du terminal demeurent figés. Il en résulte ainsi une perturbation de l’affichage des flux vidéo qui se propage sur l’ensemble des terminaux utilisés dans la vidéo conférence.
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, dans lequel un terminal de communication considéré parmi les N terminaux envoie, selon un débit ayant une valeur initiale prédéterminée, à un dispositif de traitement de N flux vidéo ou de N flux audio et vidéo émis respectivement par les N terminaux, un flux de données associé à l’utilisateur du terminal considéré, le flux envoyé contenant une pluralité de paquets de données audio et/ou vidéo.
Un tel procédé est remarquable en ce qu’il met en œuvre ce qui suit, au niveau du terminal de communication considéré :
- déterminer un nombre de paquets de données d’un flux envoyé par le terminal considéré au dispositif de traitement de flux, qui n’ont pas été reçus par le dispositif de traitement,
- réduire le débit, dans le cas où le nombre de paquets de données non reçus est supérieur à un nombre prédéterminé,
- itérer l’opération de détermination,
- à chaque itération, réduire le débit, tant que le débit ne passe pas sous un premier seuil prédéterminé ou que le nombre de paquets de données non reçus est supérieur au nombre prédéterminé,
- si au cours d’une itération, le débit passe au-dessous du premier seuil prédéterminé ou bien le nombre déterminé de paquets de données non reçus est inférieur audit nombre prédéterminé, augmenter le débit,
- itérer l’opération de détermination du nombre de paquets de données non reçus suite à l’augmentation du débit,
- à chaque itération, selon que le nombre déterminé de paquets de données non reçus est inférieur, respectivement supérieur, au nombre prédéterminé, augmenter, respectivement diminuer, le débit, tant que le débit ne dépasse pas un deuxième seuil prédéterminé, respectivement ne passe pas sous le premier seuil prédéterminé.
Grâce à l’invention, il est possible, pour tout terminal qui communique par vidéo conférence avec d’autres terminaux de communication, et cela tout au long de la vidéo conférence, de faire fluctuer à la baisse ou à la hausse la valeur du débit de transmission des données depuis le terminal vers le dispositif de traitement de flux, en fonction du nombre de paquets de données qui n’ont pas été reçus par le dispositif de traitement en provenance de ce terminal ou bien de la valeur courante de ce débit.
Un tel mécanisme est peu coûteux en termes de ressources de calculs pour le terminal, est par ailleurs simple à implémenter et permet efficacement d’éviter que les flux qui sont envoyés au dispositif de traitement de flux par chacun des terminaux utilisés dans la vidéo conférence contiennent un trop grand nombre de paquets manquants.
Il en résulte que grâce à l’invention, la qualité de restitution visuelle des flux de chaque participant à la vidéo conférence, pour n’importe quel terminal participant à la vidéo conférence, est nettement améliorée.
Ce mécanisme de fluctuation du débit est avantageusement déclenché à la suite d’une opération de comparaison, au niveau du terminal, du nombre de paquets de données non reçus par le dispositif de traitement de flux en provenance du terminal, par rapport à 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 terminal vers le dispositif de traitement de flux, doit être réduit si le nombre de paquets non reçus dépasse ce seuil ou bien au contraire rester à sa valeur initiale si le nombre de paquets non reçus ne dépasse pas ce seuil.
A cet effet, si le nombre de paquets non reçus dépasse ce seuil, le terminal diminue régulièrement le débit au cours de la vidéo conférence tout en contrôlant que le débit ne passe pas sous un seuil critique qui perturberait la communication de la vidéo conférence et en vérifiant régulièrement que le nombre de paquets non reçus est toujours supérieur au seuil prédéfini.
Dans le cas où le débit viendrait à passer sous le seuil critique ou que le nombre de paquets non reçus viendrait à passer en dessous du seuil prédéfini, le terminal est capable d’augmenter régulièrement le débit.
Un tel mécanisme de détermination des paquets de données non reçus suivi d’un réglage à la baisse ou à la hausse selon le nombre de paquets de données reçus permet en outre au débit de transmission des données, depuis le terminal vers le dispositif de traitement, de revenir rapidement à un niveau permettant au terminal d’envoyer au dispositif de traitement de flux, un flux qui contienne la totalité ou presque des paquets de données vidéo ou bien audio et vidéo, relatifs à l’utilisateur du terminal.
Selon un mode de réalisation particulier, l’action d’augmenter, respectivement diminuer, le débit, est mise en œuvre selon un pas fixe prédéterminé.
De façon avantageuse, tout terminal est ainsi apte à réduire ou augmenter le débit de façon régulière, selon un pas défini de telle manière que chaque réduction ou diminution du débit selon ce pas ne perturbent pas les conditions de fonctionnement de la vidéo conférence.
En outre, l’utilisation d’un pas fixe pour réduire ou augmenter le débit est peu consommatrice en termes de ressources de calculs du terminal.
Selon un mode de réalisation particulier, pour une itération donnée de détermination du nombre de paquets de données non reçus à la suite de l’augmentation du débit, l’action d’augmenter, respectivement diminuer, le débit, est mise en œuvre selon un pas dont la valeur dépend du nombre de paquets non reçus qui a été déterminé à l’itération donnée.
De façon avantageuse, tout terminal est ainsi apte à réduire ou augmenter le débit de façon régulière et variable, selon des pas de plus en plus faibles de façon à obtenir des fluctuations du débit qui soient faibles et non perceptibles visuellement par l’utilisateur du terminal.
Un tel mode de réalisation optimise ainsi les conditions de fonctionnement de la vidéo conférence, sans impact notable sur l’augmentation en ressources de calculs du terminal.
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 commander l’envoi, selon un débit ayant une valeur initiale prédéterminée, à un dispositif de traitement de N flux vidéo ou de N flux audio et vidéo émis respectivement par les N terminaux, d’un flux de données associé à l’utilisateur du terminal de communication par vidéo conférence, le flux envoyé contenant 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 commander ce qui suit:
- déterminer un nombre de paquets de données d’un flux envoyé par le terminal considéré au dispositif de traitement de flux, qui riont pas été reçus par le dispositif de traitement,
- réduire le débit, dans le cas où le nombre de paquets de données non reçus est supérieur à un nombre prédéterminé,
- itérer l’opération de détermination,
- à chaque itération, réduire le débit, tant que le débit ne passe pas sous un premier seuil prédéterminé ou que le nombre de paquets de données non reçus est supérieur au nombre prédéterminé,
- si au cours d’une itération, le débit passe au-dessous du premier seuil prédéterminé ou bien le nombre déterminé de paquets de données non reçus est inférieur audit nombre prédéterminé, augmenter le débit,
- itérer l’opération de détermination du nombre de paquets de données non reçus suite à l’augmentation du débit,
- à chaque itération, selon que le nombre déterminé de paquets de données non reçus est inférieur, respectivement supérieur, au nombre prédéterminé, augmenter, respectivement diminuer, le débit, tant que le débit ne dépasse pas un deuxième seuil prédéterminé, respectivement ne passe pas sous le premier seuil prédéterminé.
Selon un mode de réalisation particulier du terminal, le débit est augmenté, respectivement diminué, selon un pas fixe prédéterminé.
Selon un mode de réalisation particulier du terminal, pour une itération donnée de détermination du nombre de paquets de données non reçus à la suite de l’augmentation du débit, le débit est augmenté, respectivement diminué, selon un pas dont la valeur dépend du nombre de paquets non reçus qui a été déterminé à l’itération donnée.
L'invention concerne également un programme d'ordinateur pour mettre en œuvre 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 œuvre 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 modes de réalisation particuliers de l'invention, donnés à titre d’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 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 à 3D représentent les principales étapes d’un procédé de communication par vidéo conférence selon un mode de réalisation particulier de l’invention,
- les figures 4A et 4B représentent respectivement deux modes d’affichage mis en oeuvre dans le procédé de communication par vidéo conférence des figures 3A à3D.
Description détaillée d’un mode particulier de réalisation
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.
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 nœuds, 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, ..., Ui5...,Uj5..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 REC de réception en temps réel 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,
- un module ENV d’envoi en temps réel de flux de données audio vidéo ou de flux de données vidéo représentatifs de l’utilisateur du terminal TER,,
- 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 :
- tout flux de données audio vidéo contient une pluralité de paquets de données audio et vidéo,
- tout 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 œuvre 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 DET de détermination du nombre de paquets de données non reçus par le pont de gestion de vidéo conférence PVC, suite à la réception d’un flux de données envoyé par le terminal TER,,
- un module MSD de mesure de la valeur courante du débit de transmission de données depuis le terminal TER, vers le pont de gestion de vidéo conférence PVC,
- un module VAR de variation de la valeur courante du débit de transmission de données depuis le terminal TER, vers le pont de gestion de vidéo conférence PVC, le module VAR étant relié au module MSD et au module DET.
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 J de paquets de données non reçus,
- une valeur prédéterminée d’un pas P d’augmentation, respectivement de diminution, du débit de transmission de données depuis le terminal TER, vers le pont de gestion de vidéo conférence PVC.
Les modules DET, MSD, VAR et MEM sont piloté par le processeur PROC du module de traitement MT.
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 œuvre 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 œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
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 mode de réalisation de l’invention, mettant en œuvre une détermination du nombre de paquets de données non reçus par le pont de gestion de vidéo conférence PVC, suite à la réception par ce dernier d’un flux envoyé par 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 œuvre 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 TER,, TER2, ..., TERi,...,TERj,..., TERk,..., TERN sont associés respectivement à N identifiants ID,, 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 IDb ID2, ..., IDj,..., 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, via leur module ENV, à 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 Fi, F2, ..., Fi,...,Fj,..., 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 F1; F2, ..., Fi,..., Fj5..., 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.
De façon connue en soi, au cours de la phase d’initialisation S1 :
- le débit R de transmission de données depuis chacun des N terminaux vers le pont de gestion de vidéo conférence est fixé à une valeur initiale K prédéterminée, par exemple 512 kbits/s,
- le format des données vidéo envoyées par chacun des N terminaux vers le pont de gestion de vidéo conférence PVC est prédéterminé et est par exemple conforme au standard SD (« Définition Standard >>) ou HD (« Haute Définition »).
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 détermination du nombre de paquets de données audio/vidéo qui n’ont pas été reçus par le pont de gestion de vidéo conférence PVC, suite à la réception des flux envoyés par chacun des N terminaux.
Conformément à l’invention, également lors de la phase d’initialisation S1 :
- un seuil minimal et un seuil maximal du débit RC courant de transmission de données depuis chacun des N terminaux vers le pont de gestion de vidéo conférence sont fixés respectivement à une valeur L prédéterminée, par exemple 200 kbits/s, et à une valeur M prédéterminée, par exemple 2000 kbits/s,
- un pas d’augmentation ou de réduction du débit courant RC est fixé à une valeur prédéterminée P, telle que par exemple P=100 kbits/s.
Un tel téléchargement est transparent pour les utilisateurs Ui à UN. Pour un terminal de communication donné TER,, la procédure de détermination du nombre de paquets de données audio/vidéo non reçus par le pont PVC suite à la réception d’un flux envoyé par le terminal TER., est téléchargée dans le module DET tel que représenté sur la figure 2.
La procédure de détermination du nombre de paquets de données audio/vidéo non reçus par le pont PVC 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étermination du nombre de paquets de données audio/vidéo non reçus par le pont PVC 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 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 oeuvre par le terminal TER, au cours de la vidéo conférence, de la façon suivante.
En S300, à chaque instant courant de la vidéo conférence, le terminal TER, reçoit via son interface de communication IC, en provenance du pont de gestion de vidéo conférence PVC, un message REQ de requête en fourniture de paquets de données qui riont pas été reçus par le pont PVC suite à la réception par ce dernier d’un flux audio vidéo ou bien vidéo envoyé par le module d’envoi ENV du terminal TER, à un instant précédent l’instant courant. Un tel flux audio vidéo (ou seulement vidéo) contient classiquement une pluralité de paquets de données vidéo et audio (ou seulement vidéo). De façon connue en soi, 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.
Le message de requête REQ reçu en provenance du pont PVC contient le nombre de paquets de données qui manquaient dans le flux envoyé par le terminal TER, à l’instant précédent, ainsi que leur numéro d’identification respectif.
Selon un exemple de réalisation, un tel message est envoyé par le pont PVC selon le protocole http ou Websocket.
En S301, au bout d’une durée prédéterminée de quelques secondes, par exemple 2 secondes après le début de la vidéo conférence, le module de traitement MT du terminal TER, active alors une première fois le module de détermination DET (figure 2) qui procède alors au comptage des paquets de données audio/vidéo non reçus à partir des informations contenues dans le message de requête reçu en S300.
Soit NB le nombre de paquets non reçus qui ont été déterminé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é J de paquets non reçus, tel que stocké dans la mémoire MEM de la figure 2. Selon un exemple non exhaustif, J=8.
Selon une première option, si NB<J, en S303, la vidéo conférence se poursuit classiquement, les N flux vidéo ou bien audio et vidéo étant 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, 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 de la figure 2.
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<J.
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, selon laquelle :
- un flux audio vidéo Fb tel que 1<j<N, correspondant à par exemple l’utilisateur UTj 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 une deuxième option, si pour la première fois depuis le début de la vidéo conférence, NB>J, le module de traitement MT commande en S304 le module de variation VAR du terminal TER, pour qu’il réduise la valeur du débit courant RC mesurée par le module MSD de la figure 2, à une valeur VC1, telle que VC1= K - P.
En alternative à cette deuxième option, NB>J au lieu de NB>J.
A cet effet, en S304, le module de traitement MT commande l’interface de communication IC du terminal TER,, pour envoyer au pont PVC, via le réseau RC, un message NOTIF de notification de la valeur VC1.
Selon un exemple de réalisation, un tel message NOTIF est envoyé selon le protocole http ou Websocket.
En S305, au bout d’une durée prédéterminée de quelques secondes, par exemple 4 secondes, après la réduction du débit courant RC mise en œuvre en S304, le module de traitement MT du terminal TER, active alors une nouvelle fois le module de détermination DET (figure 2) qui procède alors au comptage du nombre NB de paquets de données audio/vidéo non reçus à partir des informations contenues dans un nouveau message de requête reçu en S300.
En S306, si le module de traitement MT compare le nombre NB déterminé de paquets non reçus à la valeur du nombre prédéterminé J de paquets non reçus.
Si NB<J ou bien NB<J selon l’implémentation de comparaison mise en œuvre, une phase de tentative d’augmentation du débit courant RC est alors mise en œuvre. Cette phase sera décrite plus loin en référence à la figure 3C.
Si NB>J ou bien NB>J selon l’implémentation de comparaison mise en œuvre, le module de traitement MT compare en S307 la valeur VC1 du débit courant RC au seuil minimal prédéterminé L.
Si VC<L ou bien VC<L selon l’implémentation de comparaison mise en oeuvre, la phase de tentative d’augmentation du débit courant RC de la figure 3C est alors mise en oeuvre.
Si VC>L ou bien VC>L selon l’implémentation de comparaison mise en oeuvre, le module de traitement MT commande en S308 le module de variation VAR du terminal TER,, pour qu’il réduise la valeur du débit courant RC, à une valeur VC2, telle que VC2= VCi - P.
A cet effet, en S308, le module de traitement MT commande l’interface de communication IC du terminal TER,, pour envoyer au pont PVC, via le réseau RC, un message NOTIF de notification de la valeur VC2.
Les opérations S305, S306 et S307 sont itérées tout au long de la vidéo conférence, tant qu’en S302, il est déterminé que NB>J ou NB>J.
En référence à la figure 3C, on décrit maintenant le déroulement de la phase de tentative d’augmentation du débit courant RC, selon un premier mode de réalisation.
On suppose qu’à l’instant où est déclenchée cette phase, le débit courant RC a atteint une valeur de réduction VCq après q itérations de réduction, tel que q>1.
Si à l’issue de l’action S306 (figure 3B), NB<J ou bien NB<J selon l’implémentation de comparaison mise en oeuvre, ou bien de l’action S307 (figure 3B), VCq<L ou bien VCq<L selon l’implémentation de comparaison mise en oeuvre, au bout d’une durée prédéterminée de quelques secondes, par exemple 2 secondes si c’est la première fois que la phase d’augmentation est déclenchée, en S310, le module de traitement MT (figure 2) du terminal TER, active le module de détermination DET (figure 2) qui procède alors au comptage du nombre NB de paquets de données audio/vidéo non reçus à partir des informations contenues dans un nouveau message de requête reçu en S300 (figure 3B).
En S311, si le module de traitement MT compare le nombre NB déterminé de paquets non reçus à la valeur du nombre prédéterminé J de paquets non reçus.
Si NB>J ou bien NB>J selon l’implémentation de comparaison mise en oeuvre, le module de traitement MT compare en S312 la valeur VCq du débit courant RC au seuil minimal prédéterminé L.
Si VCq>L ou bien VCq>L selon l’implémentation de comparaison mise en œuvre, le module de traitement MT commande en S313 le module de variation VAR du terminal TER, pour qu’il réduise la valeur VCq du débit courant RC, à une valeur Vr1, telle que Vr1= VCq - P.
A cet effet, en S313, le module de traitement MT commande l’interface de communication IC du terminal TER,, pour envoyer au pont PVC, via le réseau RC, un message NOTIF de notification de la valeur Vr1.
A l’issue de la réduction de débit S313 ou bien si en S312, VCq<L ou bien VCq<L selon l’implémentation de comparaison mise en œuvre, la phase de tentative d’augmentation revient alors en S310 pour une nouvelle détermination du nombre NB de paquets qui n’ont pas été reçus en S300 (figure 3B), laquelle détermination est déclenchée au bout d’une durée prédéterminée supérieure à celle à laquelle la détermination S310 a été déclenchée pour la première fois, soit par exemple 10 secondes ou 60 secondes.
Ainsi la valeur courante Vr1 du débit courant RC pourra être réduite de P, tel que Vr2=Vr1-P, si à nouveau NB>J (ou NB>J) et Vr1>L (ou Vr1>L) puis Vr2 pourra être diminuée de P à son tour, et ainsi de suite tout au long de la vidéo conférence, tant qu’il est répondu « oui >> au test S311 et au test S312.
Si en S311, NB<J ou bien NB<J selon l’implémentation de comparaison mise en œuvre, le module de traitement MT compare en S314 la valeur VCq du débit courant RC au seuil maximal prédéterminé M.
Si VCq<M ou bien VCq<M selon l’implémentation de comparaison mise en œuvre, le module de traitement MT commande en S315 le module de variation VAR du terminal TER, pour qu’il augmente la valeur VCq du débit courant RC, à une valeur Va1, telle que Va1= VCq + P.
A cet effet, en S315, le module de traitement MT commande l’interface de communication IC du terminal TER,, pour envoyer au pont PVC, via le réseau RC, un message NOTIF de notification de la valeur Va1.
A l’issue de l’augmentation de débit S315 ou bien si en S311, Va1>M ou bien
Va1>M selon l’implémentation de comparaison mise en œuvre, la phase de tentative d’augmentation revient alors en S310 pour une nouvelle détermination du nombre NB de paquets qui n’ont pas été reçus en S300 (figure 3B), laquelle est déclenchée au bout d’une durée prédéterminée supérieure à celle à laquelle la détermination S310 a été déclenchée pour la première fois, soit par exemple 10 secondes ou 60 secondes.
Ainsi la valeur courante Va1 du débit courant RC pourra être augmentée de P, tel que Va2=Va1+P, si à nouveau NB>J (ou NB>J) et Va1<M (ou Va1<M), puis Va2 pourra être augmentée de P à son tour, et ainsi de suite tout au long de la vidéo conférence, tant qu’il est répondu « non >> au test S311 et oui au test S314.
Dans ce premier mode de réalisation de la phase de tentative d’augmentation du débit courant, la réduction ou bien l’augmentation du débit courant est mise en œuvre selon un pas fixe à chaque itération.
En référence à la figure 3D, on décrit maintenant le déroulement de la phase de tentative d’augmentation du débit courant RC, selon un deuxième mode de réalisation.
Le deuxième mode de réalisation se distingue du premier mode de la figure 3C par le fait que la valeur de réduction ou d’augmentation du débit courant varie à chaque itération.
Comme pour le premier mode de réalisation de la figure 3C, on suppose qu’à l’instant où est déclenchée cette phase, le débit courant RC a atteint une valeur de réduction VCq après q itérations de réduction, tel que q>1.
Si à l’issue de l’action S306 (figure 3B), NB<J ou bien NB<J selon l’implémentation de comparaison mise en œuvre, ou bien de l’action S307 (figure 3B), VCq<L ou bien VCq<L selon l’implémentation de comparaison mise en œuvre, au bout d’une durée prédéterminée de quelques secondes, par exemple 2 secondes si c’est la première fois que la phase d’augmentation est déclenchée, en S320, le module de traitement MT (figure 2) du terminal TER, active le module de détermination DET (figure 2) qui procède alors au comptage du nombre NB de paquets de données audio/vidéo non reçus, à partir des informations contenues dans un nouveau message de requête reçu en S300.
En S321, si le module de traitement MT compare le nombre NB déterminé de paquets non reçus à la valeur du nombre prédéterminé J de paquets non reçus.
Si NB>J ou bien NB>J selon l’implémentation de comparaison mise en œuvre, le module de traitement MT compare en S322 la valeur VCq du débit courant RC au seuil minimal prédéterminé L.
Si VCq>L ou bien VCq>L selon l’implémentation de comparaison mise en œuvre, le module de traitement MT commande en S323 le module de variation VAR (figure 2) du terminal TER, pour qu’il réduise :
• le pas P à une nouvelle valeur P1=P/2, • la valeur VCq du débit courant RC, à une valeur V’r1, telle que V’r1 = VRvai-(Plx^) où VRvai est la valeur du dernier débit obtenu pour lequel le module de détermination DET de la figure 2 a déterminé que NB<J (ou NB<J), et où, dans le cas où NB/10<1, NB/10= 1.
Le module de traitement MT commande alors en S323 l’interface de communication IC du terminal TER,, pour envoyer au pont PVC, via le réseau RC, un message NOTIF de notification de la valeur V’r1.
A l’issue de la réduction de débit S323 ou bien si en S322, VCq<L ou bien VCq<L selon l’implémentation de comparaison mise en œuvre, la phase de tentative d’augmentation revient alors en S320 pour une nouvelle détermination du nombre NB de paquets non reçus en S300 (figure 3B), laquelle est déclenchée au bout d’une durée prédéterminée supérieure à celle à laquelle la détermination S320 a été déclenchée pour la première fois, soit par exemple 10 secondes ou 60 secondes.
Ainsi, si à nouveau NB>J (ou NB>J) et Vr1>L (ou Vr1>L), au cours de X itérations de l’action de détermination S320, la valeur courante V’r1 du débit courant
NB
RC pourra être réduite à une valeur V’r2, telle que V’r2= V’r1 - (P2x—), tel que NB
P2=Pi/2, et ainsi de suite jusqu’à une valeur V’rX= V’rX-1 - (Pxx—).
Ainsi, le pas initial P diminue de plus en plus à chaque itération de manière à obtenir des fluctuations à la baisse du débit courant RC de plus en plus faibles et non perçues par l’utilisateur UT, du terminal TER,.
Si en S321, NB<J ou bien NB<J selon l’implémentation de comparaison mise en œuvre, le module de traitement MT compare en S324 la valeur VCq du débit courant
RC au seuil maximal prédéterminé M.
Si VCq<M ou bien VCq<M selon l’implémentation de comparaison mise en œuvre, le module de traitement détermine en S325 si le nombre NB de paquets non reçus en S300 est nul ou pas.
Si NB=0, le module de traitement MT commande en S326 le module de variation VAR du terminal TER, pour qu’il augmente de P la valeur VRVAl du dernier débit obtenu pour lequel le module de détermination DET de la figure 2 a déterminé que NB<J (ou NB<J). Le débit courant RC prend alors la valeur V’a1= VRva, +P.
Le module de traitement MT commande alors en S326 l’interface de communication IC du terminal TER,, pour envoyer au pont PVC, via le réseau RC, un message NOTIF de notification de la valeur V’a1.
Si NB>0, le module de traitement MT commande en S327 le module de variation VAR du terminal TER, pour que :
• il diminue le pas P à une nouvelle valeur Pi=P/2, • il augmente la valeur VCq du débit courant RC, à une valeur V”a1, telle que V”a1 = VRva, + Pt
A l’issue de l’augmentation de débit S326 ou S327 ou bien si en S324, VCq>M ou bien VCq<M selon l’implémentation de comparaison mise en œuvre, la phase de tentative d’augmentation revient alors en S320 pour une nouvelle détermination du nombre NB de paquets non reçus en S300 (figure 3B), laquelle est déclenchée au bout d’une durée prédéterminée supérieure à celle à laquelle la détermination S320 a été déclenchée pour la première fois, soit par exemple 10 secondes ou 60 secondes.
Ainsi, si à nouveau NB<J ou bien NB<J et que soit V’a1<M (ou V’a1<M), soit V”a1<M (ou V”a1<M), au cours de Y itérations de l’action de détermination S320,
- soit si NB=0, la valeur courante V’a1 du débit courant RC pourra être augmentée, en S326, à une valeur V’a2, telle que V’a2= V’a1+P, etc.., jusqu’à une valeur V’aY= V’aY-1 + P,
- soit si NB>0, la valeur courante V”a1 du débit courant RC pourra être augmentée, en S327, à une valeur V”a2, telle que V”a2= V”a1 +P2, tel que P2=Pi/2, et ainsi de suite jusqu’à une valeur V”aY= V”aY-1 + PY, tel que PY=PY.1/2.
Ainsi, dans le cas où NB>0, le pas initial P diminue de plus en plus à chaque itération de manière à obtenir des fluctuations à la hausse du débit courant RC de plus en plus faibles et non perceptibles par l’utilisateur UT, du terminal TER,.
Dans le cas où NB=0, le dernier débit valide sera augmenté de P à chaque itération pour retrouver dès que possible un débit courant RC satisfaisant.
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 (8)

  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, dans lequel un terminal de communication (TER,) considéré parmi les N terminaux envoie, selon un débit ayant une valeur initiale prédéterminée, à un dispositif (PVC) de traitement de N flux vidéo ou de N flux audio et vidéo émis respectivement par les N terminaux, un flux de données associé à l’utilisateur du terminal considéré, ledit flux envoyé contenant 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,) :
    - déterminer (S301) un nombre de paquets de données d’un flux envoyé par le terminal considéré au dispositif de traitement de flux, qui n’ont pas été reçus par le dispositif de traitement,
    - réduire (S304) le débit, dans le cas où le nombre de paquets de données non reçus est supérieur à un nombre prédéterminé (J),
    - itérer (S305) l’opération de détermination,
    - à chaque itération, réduire (S308) le débit, tant que le débit ne passe pas sous un premier seuil prédéterminé (L) ou que le nombre de paquets de données non reçus est supérieur audit nombre prédéterminé (J),
    - si au cours d’une itération, le débit passe au-dessous du premier seuil prédéterminé (L) ou bien le nombre déterminé de paquets de données non reçus est inférieur audit nombre prédéterminé (J), augmenter (S315) le débit,
    - itérer l’opération de détermination du nombre de paquets de données non reçus suite à l’augmentation du débit,
    - à chaque itération, selon que le nombre déterminé de paquets de données non reçus est inférieur, respectivement supérieur, au nombre prédéterminé (J), augmenter, respectivement diminuer, le débit, tant que le débit ne dépasse pas un deuxième seuil prédéterminé (M), respectivement ne passe pas sous ledit premier seuil prédéterminé (L).
  2. 2. Procédé de communication selon la revendication 1, dans lequel l’action d’augmenter, respectivement diminuer, le débit, est mise en oeuvre selon un pas (P) fixe prédéterminé.
  3. 3. Procédé de communication selon la revendication 1, dans lequel pour une itération donnée de détermination du nombre de paquets de données non reçus à la suite de l’augmentation du débit, l’action d’augmenter, respectivement diminuer, le débit, est mise en oeuvre selon un pas dont la valeur dépend du nombre de paquets non reçus qui a été déterminé à l’itération donnée.
  4. 4. 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 commander l’envoi, selon un débit ayant une valeur initiale prédéterminée, à un dispositif de traitement de N flux vidéo ou de N flux audio et vidéo émis respectivement par les N terminaux, un flux de données associé à l’utilisateur du terminal de communication par vidéo conférence, ledit flux envoyé contenant 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 commander ce qui suit :
    - déterminer un nombre de paquets de données d’un flux envoyé par le terminal considéré au dispositif de traitement de flux, qui n’ont pas été reçus par le dispositif de traitement,
    - réduire le débit, dans le cas où le nombre de paquets de données non reçus est supérieur à un nombre prédéterminé (J),
    - itérer l’opération de détermination,
    - à chaque itération, réduire le débit, tant que le débit ne passe pas sous un premier seuil prédéterminé (L) ou que le nombre de paquets de données non reçus est supérieur audit nombre prédéterminé (J),
    - si au cours d’une itération, le débit passe au-dessous du premier seuil prédéterminé (L) ou bien le nombre déterminé de paquets de données non reçus est inférieur audit nombre prédéterminé (J), augmenter le débit,
    - itérer l’opération de détermination du nombre de paquets de données non reçus suite à l’augmentation du débit,
    - à chaque itération, selon que le nombre déterminé de paquets de données non reçus est inférieur, respectivement supérieur, au nombre prédéterminé (J), augmenter, respectivement diminuer, le débit, tant que le débit ne dépasse pas un deuxième seuil prédéterminé (M), respectivement ne passe pas sous ledit premier seuil prédéterminé (L).
  5. 5. Terminal de communication selon la revendication 4, dans lequel le débit est augmenté, respectivement diminué, selon un pas fixe prédéterminé.
  6. 6. Terminal de communication selon la revendication 5, dans lequel pour une itération donnée de détermination du nombre de paquets de données non reçus à la suite de l’augmentation du débit, le débit est augmenté, respectivement diminué, selon un pas dont la valeur dépend du nombre de paquets non reçus qui a été déterminé à l’itération donnée.
  7. 7. Programme d'ordinateur comportant des instructions qui implémentent le procédé de communication selon l’une quelconque des revendications 1 à 3, lorsque ledit programme est exécuté sur un ordinateur.
  8. 8. 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 à 3, lorsque ledit programme est exécuté par un ordinateur.
FR1852736A 2018-03-29 2018-03-29 Communication par video conference Pending FR3079704A1 (fr)

Priority Applications (1)

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1852736 2018-03-29
FR1852736A FR3079704A1 (fr) 2018-03-29 2018-03-29 Communication par video conference

Publications (1)

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

Family

ID=62751069

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1852736A Pending FR3079704A1 (fr) 2018-03-29 2018-03-29 Communication par video conference

Country Status (1)

Country Link
FR (1) FR3079704A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030041165A1 (en) * 2001-08-24 2003-02-27 Spencer Percy L. System and method for group video teleconferencing using a bandwidth optimizer
US20080117819A1 (en) * 2001-11-26 2008-05-22 Polycom, Inc. System and method for dynamic bandwidth allocation for videoconferencing in lossy packet switched networks
US20150244760A1 (en) * 2014-02-21 2015-08-27 Myo Tun Efficient bitrate adaptation in video communications over ip networks

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030041165A1 (en) * 2001-08-24 2003-02-27 Spencer Percy L. System and method for group video teleconferencing using a bandwidth optimizer
US20080117819A1 (en) * 2001-11-26 2008-05-22 Polycom, Inc. System and method for dynamic bandwidth allocation for videoconferencing in lossy packet switched networks
US20150244760A1 (en) * 2014-02-21 2015-08-27 Myo Tun Efficient bitrate adaptation in video communications over ip networks

Similar Documents

Publication Publication Date Title
US8621576B2 (en) System and method of multimedia access
EP3087706B1 (fr) Procédé et système de communication entre navigateurs web, utilisant un environnement de communication unifiée
CN112954464A (zh) 一种基于网络异常预测的视频清晰度选择方法及装置
CN112584194A (zh) 视频码流的推送方法、装置、计算机设备和存储介质
EP2947888A1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
EP3646196B1 (fr) Procédé et dispositif de téléchargement de contenu audiovisuel
EP2767060B1 (fr) Passerelle, et procédé, programme d&#39;ordinateur et moyens de stockage correspondants
FR3079704A1 (fr) Communication par video conference
EP2680603B1 (fr) Technique de traitement pour proposer un contenu temps réel à des entités clientes
FR3068852A1 (fr) Procede de gestion du droit d&#39;acces a un contenu numerique
EP3718301B1 (fr) Communication par vidéo conférence
EP3987820A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d&#39;un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d&#39;ordinateur correspondants
FR3079705A1 (fr) Communication par video conference
EP3235255B1 (fr) Dispositif et procede de gestion des priorites pour le telechargement de contenus multimedia
FR3102904A1 (fr) Procédé de gestion de zapping de contenus multimédias numériques obtenu par téléchargement progressif adaptatif (HAS), dispositif de gestion, lecteur de flux multimédia et programme d’ordinateur correspondants.
EP2858327B1 (fr) Procédé de mise en oeuvre d&#39;une session de communication entre une pluralité de terminaux
EP2846520A1 (fr) Procédé et dispositif d&#39;enrichissement d&#39;une communication
EP3228083B1 (fr) Procédé de gestion du droit d&#39;accès a un contenu numérique
FR3019429A1 (fr) Procede et dispositif de controle d&#39;un telechargement de contenus multimedia
EP4300259A1 (fr) Gestion de consommation d&#39;énergie d&#39;un appareil
WO2022144512A2 (fr) Contrôle de la transmission d&#39;au moins un contenu depuis un equipement fournisseur vers un noeud d&#39;ingestion
FR3114720A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu tenant compte de la qualité du signal échangé entre le terminal client et le point d’accès au réseau
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
FR3134940A1 (fr) Gestion de la restitution d’un contenu multimédia

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