Brevet FR2961651A1 — publié le 20111223

Procédé et dispositif de traitement de flux média entre une pluralité de terminaux média et une unité de traitement à travers un réseau de communication La présente invention concerne le traitement de flux média entre une pluralité de terminaux média et une unité de traitement à travers un réseau de communication. Elle trouve une application générale en communication entre plusieurs terminaux média tels que des téléphones portables, des ordinateurs, des assistants personnels numériques, et plus particulièrement en visioconférence ou analogue. En visioconférence, les flux media audio et vidéo en provenance de chaque participant sont reçus par une unité de traitement qui sélectionne le ou les participant (s) actif(s) destiné(s) à être affiché(s) sur les terminaux média des participants et qui envoie le(s) flux média audio et vidéo du(es) participant(s) actif(s) à destination des autres participants. Dans ce contexte, tous les flux média audio et vidéo des autres participants ne sont pas utilisés par l'unité de traitement et ne sont pas davantage affichés. Il en résulte une consommation inutile de la bande passante du réseau de communication. Par exemple, dans le cas d'une visioconférence à cinq participants, 80% de la bande passante du réseau est inutile ce qui constitue un important gâchis en terme de ressources radiofréquence, coeur de réseau, transmission et application. Le Demandeur s'est posé le problème de remédier à cet inconvénient tout en conservant une fluidité, rapidité et réactivité dans le traitement des flux média. La présente invention apporte justement une solution à ce problème. Elle porte sur un procédé de traitement de flux média entre une pluralité de terminaux média et une unité de traitement à travers un réseau de communication. Selon une définition générale de l'invention, l'unité de traitement émet un signal de commande de coupure/reprise d'émission de flux média au format d'un protocole de communication en temps réel de type RTP/RTCP ou équivalent à destination d'au moins un terminal média en réponse à un évènement choisi. Ainsi, grâce à l'invention, selon un évènement choisi, par exemple en visioconférence, en fonction de l'activité sonore des participants, l'unité de traitement coupe (« pause » en anglais) ou reprend (« resume » en anglais) l'activité média (video et/ou audio) desdits participants sur le réseau de communication. De plus, grâce au signal de commande de type RTP/RTCP la coupure ou reprise de l'activité est réalisée en temps réel et au niveau bas du protocole de communication ce qui favorise un traitement fluide, rapide et réactif des flux média. Selon une réalisation, l'unité de traitement comprend un module de détection d'activité sonore des terminaux média. En pratique le signal de commande est apte à couper/reprendre l'émission du flux média d'au moins un terminal média en fonction de l'activité sonore dudit terminal média ainsi détectée. Selon une autre réalisation, l'unité de traitement comprend un module de réception apte à recevoir une requête choisie et le signal de commande est apte à couper/reprendre l'émission du flux média d'au moins un terminal média en fonction de la requête ainsi reçue. Par exemple la requête émane d'un participant qui joue le rôle de modérateur. La présente invention a également pour objet un dispositif de traitement de flux média entre une pluralité de terminaux média et une unité de traitement à travers un réseau de communication. Selon un autre aspect de l'invention, l'unité de traitement est apte à émettre un signal de commande de coupure/reprise d'émission de flux média au format d'un protocole de communication en temps réel de type RTP/RTCP ou équivalent à destination d'au moins un terminal média en réponse à un évènement choisi 30 D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée et des dessins dans lesquels : - la figure 1 représente schématiquement une architecture d'un système mettant en oeuvre une visioconférence ; et25 - les figures 2 et 3 représentent schématiquement le système de visioconférence de la figure 1 dans lequel le procédé de traitement selon l'invention est mis en place. En référence à la figure 1, on a décrit l'architecture d'un système de visioconférence entre quatre terminaux média UA, UB, UC, et UD, par exemple de type téléphone portable, ordinateur, assistant personnel numérique ou analogue Les terminaux média sont connectés à une unité de traitement de visioconférence UV via un réseau de communication par exemple de type IMS pour « IP Multimédia System ». Le système de visioconférence comprend un serveur d'application VI qui contrôle les sessions et organise la conférence et une unité de visioconférence UV, généralement sous la forme d'un serveur média qui assure les fonctions principales suivantes : - un module de sélection de participant(s) qui détermine quel(s) participant(s) est (sont) à retransmettre aux autres participants. Généralement, le module de sélection est un module de détection d'activité sonore, appelé encore VAD pour « Voice Activity Detection ». L'unité de visioconférence sélectionne les N plus fort participant en terme d'activité sonore afin de les mélanger. Les autres participants sont mis en sourdine (muted). Si l'un des participants souhaite parler, alors le module VAD le détecte et si son activité sonore est suffisante, il est inclus avec les participants actifs et mélangé avec les autres ; et - un module de mélange MX qui reçoit les flux media 6 (audio et vidéo) en provenance des terminaux média via une interface d'entrée MSI et qui redistribue les flux média après mélange 2 à destination des participants à travers une interface de sortie MSO. En pratique, le module MX mélange les flux audio des N participants les plus actifs sur le plan sonore et les redistribuent aux autres participants. Le module MX sélectionne le participant le plus actif sur le plan sonore et envoie le flux vidéo correspondant à tous les participants. En variante, le module MX mélange dans une seule image les N participants les plus actifs (par exemple en partitionnant l'écran) et envoie leur image aux autres participants. Dans ce contexte, la partie vidéo des flux media 4 en provenance des participants non actif sur le plan sonore sont inutiles puisque non réellement utilisés ni affichés par les participants. En référence à la figure 2, l'unité de visioconférence UV envoie un signal de commande de coupure SC (« pause » en anglais) à destination des participants non actif sur le plan sonore afin de couper leur flux vidéo et ainsi économiser les ressources du réseau. Par exemple, dans le cas où le participant UA est actif sur le plan sonore et les participants UB, UC, et UD sont inactifs, l'unité de visioconférence UV envoie un signal de coupure SC, individualisé en SCB, SCC, et SCD respectivement aux terminaux UB, UC, et UD. Dans ce contexte, le participant UA envoie le flux audio et vidéo 4 à l'interface d'entrée MSI et reçoit le flux audio et vidéo 2 en provenance de l'interface de sortie MSO, après mélange. Les participants UB, UC, et UD envoient respectivement uniquement leur flux audio 6 à destination de l'interface d'entrée MSI, la partie du flux vidéo étant coupée en réponse à la réception du signal de coupure SC. En variante, l'unité de visioconférence UV comprend un module de réception (non représenté) qui reçoit une requête choisie, par exemple émanant d'un participant UA qui joue le rôle de modérateur de conférence. En réponse à cette requête, par exemple le modérateur UA se tait et donne la parole au participant UB, un signal de coupure SC d'émission de flux média est alors adressé aux participants UA, UC et UD. En référence à la figure 3, on a représenté le système de visioconférence dans lequel le participant UC devient actif sur le plan sonore. L'activité du participant UA est détectée par le module de détection. En réponse à cette détection, l'unité de visioconférence UV envoie un signal de commande SRC de reprise (« resume » en anglais) à destination du participant UC et un signal de coupure SCA à destination du participant UA. En réponse au signal de commande de reprise SRC, le participant UC devient actif et envoie les flux audio et vidéo 4 à destination de l'interface d'entrée MSI. En réponse au signal de commande de coupure SCA, le participant UA devient inactif et envoie uniquement son flux audio 6 à destination de l'interface d'entrée MSI. Dans la variante « modérateur », le modérateur peut donner la parole à un autre participant, après l'intervention du participant UB, par exemple la parole est donnée au participant UD. Dans ce cas, un signal de coupure est envoyé au participant UB tandis qu'un signal de reprise est envoyé au participant UD. Pour conserver une visioconférence fluide, rapide et réactive, le signal de commande de coupure et de reprise de flux vidéo est choisi au format d'un protocole de communication en temps réel, de type RTP (Real time transport Protocol) ou RTCP (Real Time Transport Control Protocol). Par exemple, le signal de commande de coupure (PAUSE) ou de reprise (RESUME) d'émission de flux vidéo est conforme au document RFC 3550. Cette conformité permet d'assurer une compatibilité avec les terminaux média n'implémentant pas le mécanisme de traitement décrit ci-avant. Dans ce cas seule la couche applicative est impactée par ce mécanisme, directement après le traitement des paquets par la couche RTP. Ce procédé est donc plus rapide et réactif que de passer par de la signalisation. En réponse à un signal de commande de coupure (PAUSE), la couche RTP du terminal média arrête d'envoyer des paquets RTP, demande au transcodeur audio ou vidéo d'arrêter son traitement, ne demande pas à la couche RTP de fermer ses extrémités UDP/TCP afin de les réutiliser sans une nouvelle négociation SDP (RFC3264), ne demande pas à la couche RTP d'arrêter de recevoir les paquets RTP et demande à la couche RTP d'envoyer des paquets vides ou de continuer à envoyer des paquets RTCP SR et de recevoir des paquets RR. En réponse à un signal de commande de reprise (RESUME), la couche applicative du terminal media demande au transcodeur audio ou video de redémarrer son traitement et demande à la couche RTP d'envoyer des paquets RTP. En variante, un nouveau document RFC est destiné à être implémenté dans les terminaux média ainsi que dans l'unité de visioconférence. Le mécanisme de traitement conforme à l'invention est appliqué uniquement au niveau de la couche RTP/RTCP des terminaux média. La couche RTP/RTCP arrête l'émission des paquets RTP en réponse à un message RTCP de coupure d'émission (PAUSE) et envoie à nouveau le flux vidéo RTP en réponse à un message de reprise d'émission (RESUME).10 REVENDICATIONS1. Procédé de traitement de flux média entre une pluralité de terminaux média (UA, UB, UC, UD) et une unité de traitement (UV) à travers un réseau de communication, caractérisé en ce que ladite unité de traitement (UV) émet un signal de commande de coupure (SC) /reprise (SR) d'émission de flux média au format d'un protocole de communication en temps réel de type RTP/RTCP ou équivalent à destination d'au moins un terminal média en réponse à un évènement choisi. 2. Procédé selon la revendication 1, dans lequel l'unité de traitement (UV) comprend un module de détection d'activité sonore des terminaux média. 3. Procédé selon la revendication 2, caractérisé en ce que le signal de commande est apte à couper/reprendre l'émission du flux média d'au moins un terminal média en fonction de l'activité sonore dudit terminal média ainsi détectée. 4. Procédé selon la revendication 1, caractérisé en ce que l'unité de traitement comprend un module de réception apte à recevoir une requête choisie et en ce que le signal de commande est apte à couper/reprendre l'émission du flux média d'au moins un terminal média en fonction de la requête ainsi reçue. 5. Dispositif de traitement de flux média entre une pluralité de terminaux média (UA, UB, UC, UD) et une unité de traitement (UV) à travers un réseau de communication, caractérisé en ce que ladite unité de traitement (UV) est apte à émettre un signal de commande de coupure/reprise d'émission de flux média au format d'un protocole de communication en temps réel de type RTP/RTCP ou équivalent à destination d'au moins un terminal média en réponse à un évènement choisi. 730