Brevet FR3047377A1 — publié le 20170804

Procédé et terminal de réception d'un flux vidéo issu d'une communication visiophonique établie entre deux terminaux. La demande d'invention se situe dans le domaine des télécommunications et plus particulièrement dans le domaine des services de communication visiophonique. Les normes ViLTE (GSMA IR.94) et ViWIFI sont adaptées à fournir un service de communication visiophonique sur respectivement des réseaux mobiles 4G et WIFI. De tels services de visiophonie nécessitent des ressources importantes car bien que compressée par des standard de compression vidéo adapté, la composante vidéo d'une communication visiophonique nécessite une bande passante importante, de l'ordre de 384kbits/s au minimum, et pouvant aller jusqu'à 1.5Mbits/s si le débit est disponible au niveau de la cellule 4G. On rappelle qu'en technologie radio cellulaire 4G, il n'y a pas de réservation de canaux ou de ressources dédiés à la téléphonie ou à la visiophonie comme cela est le cas en technologie circuit 2G/3G. En technologie radio cellulaire 4G, la bande passante d'une cellule radio est partagée entre tous les utilisateurs attachés à cette cellule, quelles que soient les applications utilisées par ces utilisateurs. Des mécanismes connus de priorisation de paquets IP sont mis en oeuvre afin d'attribuer la bande passante aux terminaux en temps réel. Ainsi, les applications de type Internet transportées selon une qualité de service (QOS) dite en « best effort » sont pénalisées lorsque la cellule radio prend en charge un nombre significatif de communications vocales VoLTE actives, car de telles communications vocales ont une QOS garantie et sont donc prioritaires en termes de bande passante et de réservation de ressources. Dès lors que les services ViLTE seront mis en oeuvre, le problème de bande passante au niveau d'une cellule radio 4G notamment va s'intensifier puisque la composante vidéo d'une communication est beaucoup plus consommatrice de bande passante que la composante vocale. On constate ainsi qu'une session de communication en ViLTE à 768kbit/s peut consommer jusqu'à 20% de la bande passante d'une cellule 4G utilisant un bloc de fréquence de largeur 10Mhz à cause des mécanismes GBR (pour Guaranteed Bit Rate en anglais, débit garanti en français). De tels mécanismes consomment beaucoup de ressources additionnelles lorsqu'un terminal en communication ViLTE se trouve en bordure de la cellule 4G. Ceci réduit donc considérablement les ressources disponibles pour les autres 3047377 2 utilisateurs de la cellule 4G. Ceci limite fortement le nombre de terminaux et les applications pouvant être servis avec une qualité acceptable par une telle cellule. En particulier, lorsque plusieurs sessions de communication ViLTE avec QoS garantie, typiquement avec une affectation de classe de service QCI=2 (pour Quality Class 5 Identifier en anglais) pour le service ViLTE, sont établies simultanément avec des terminaux connectés à une même cellule 4G, les ressources radio de cette cellule seront préemptées pour ces sessions de communication ViLTE et les applications de moindre priorité verront leur débit chuter très fortement. Il existe donc un besoin d'améliorer l'état de la technique. 10 Pour diminuer la bande passante utilisée lors d'une communication audio, il est connu d'activer au sein des terminaux participant à la communication un mécanisme de détection de silence. Un tel mécanisme est normalisé et négocié en début de session entre les terminaux participant à la communication via le protocole SDP (pour Session Description Protocol) lors de la négociation du codec audio. Par exemple, dans un 15 message SIP de négociation de session, un paramètre » annexb » associé au codec G.729 est positionné à « yes ». Lorsque le mécanisme de détection de silence est activé, au cours de la communication lorsqu'aucun flux audio capturé par un terminal émetteur n'est détecté pendant un intervalle de temps prédéterminé, un paquet IP spécifique (appelé Descripteur de silence) 20 est transmis régulièrement par le terminal émetteur vers un terminal récepteur de la communication pour informer le terminal récepteur que le flux média est interrompu et que le terminal récepteur doit restituer un signal audio représentatif d'un bruit de confort pour l'utilisateur du terminal récepteur. Le paquet IP « Descripteur de silence» est transmis régulièrement depuis le terminal émetteur vers le terminal récepteur tant que 25 l'utilisateur du terminal émetteur ne parle pas. Lorsque l'utilisateur du terminal émetteur se remet à parler, le flux média audio est classiquement transmis au terminal récepteur selon le protocole RTP. Un tel mécanisme permet de gagner de l'ordre de 40% de la bande passante sans dégrader la qualité de la communication audio et en particulier sans dégrader l'interactivité de l'échange vocal. 30 Un tel mécanisme n'est pas transposable au cas de la composante vidéo, car même si l'utilisateur du terminal émetteur ne parle pas, il est nécessaire de transmettre son flux vidéo au terminal récepteur pour conserver l'interactivité et l'expérience utilisateur. 3047377 3 L'utilisateur du terminal récepteur doit pouvoir voir que l'utilisateur du terminal émetteur est en communication vidéo avec lui-même s'il ne parle pas. L'invention vise à améliorer l'état de la technique. Pour cela, l'invention propose un procédé de réception, mis en oeuvre par un terminal 5 récepteur, d'un flux vidéo émis par un équipement émetteur, au cours d'une communication établie entre ledit équipement émetteur et ledit terminal récepteur. Avantageusement, le procédé de réception détecte un état du terminal récepteur inadapté à la visualisation par un utilisateur du terminal récepteur, du flux vidéo de la communication reçu en provenance de l'équipement émetteur, et envoie à l'équipement 10 émetteur un message adapté à déclencher sur l'équipement émetteur l'arrêt de l'émission vers le terminal récepteur dudit flux vidéo. Le procédé de réception permet ainsi de limiter l'utilisation de la bande passante au cours d'une communication vidéo unidirectionnelle ou d'une communication visiophonique, lorsque l'utilisateur du terminal récepteur ne peut pas visualiser la vidéo émise par 15 l'équipement émetteur. Plus particulièrement, lorsque l'équipement émetteur correspond à un terminal émetteur d'un utilisateur et qu'une communication visiophonique est établie entre le terminal émetteur et le terminal récepteur, la communication visiophonique n'est alors plus symétrique. Le terminal émetteur n'émet plus de flux vidéo, mais il continue d'émettre un 20 flux audio. Le terminal récepteur, lui, continue d'émettre un flux vidéo et un flux audio. Ainsi, l'utilisation de la bande passante à l'accès, i.e. au niveau de la cellule 4G à laquelle le terminal émetteur est attaché, est optimisée dans le sens montant du terminal vers le réseau. Le débit économisé au niveau de la cellule 4G peut alors être redistribué à d'autres utilisateurs de la cellule de l'émetteur. 25 De même, l'utilisation de la bande passante à l'accès, i.e. au niveau de la cellule 4G à laquelle le terminal récepteur est attaché, est optimisée dans le sens descendant du réseau vers le terminal. Le débit économisé au niveau de la cellule 4G peut alors être redistribué à d'autres utilisateurs de la cellule du récepteur. Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment 30 ou en combinaison les uns avec les autres, aux étapes du procédé de réception défini ci- dessus. 3047377 4 Selon un mode particulier de réalisation, le procédé détecte également un état du terminal récepteur adapté à la visualisation par un utilisateur du terminal récepteur, du flux vidéo de la communication émis par l'équipement émetteur, et envoie à l'équipement émetteur un message adapté pour déclencher sur l'équipement émetteur la reprise de 5 l'émission vers le terminal récepteur dudit flux vidéo. Ce mode particulier de réalisation de l'invention permet la reprise de la transmission du flux vidéo depuis l'équipement émetteur vers le terminal récepteur dès que l'utilisateur du terminal récepteur peut visualiser le flux vidéo. Selon un autre mode particulier de réalisation, la détection de l'état du terminal récepteur 10 est mise en oeuvre par au moins une des sous-étapes suivantes : - détection d'une inclinaison par rapport à un axe vertical ou horizontal, d'un écran du terminal récepteur, selon un angle d'une valeur supérieure ou égale à une valeur d'un angle prédéterminé, ledit angle étant calculé par rapport à une position initiale prédéterminée de l'écran adaptée à la visualisation de l'écran par un utilisateur, 15 - détection d'un visage face à l'écran du terminal récepteur, -détection d'une valeur d'exposition lumineuse supérieure ou égale à une valeur seuil prédéterminée, - détection d'une mise en avant-plan d'une interface d'une application exécutée par le terminal récepteur, 20 - détection d'un passage en mode veille de l'écran du terminal récepteur. L'invention concerne également un procédé d'émission, mis en oeuvre par un équipement émetteur, d'un flux vidéo vers un terminal récepteur, au cours d'une communication établie entre ledit équipement émetteur et ledit terminal récepteur. Le procédé d'émission comprend une étape de réception en provenance du terminal récepteur d'un message 25 indiquant une demande d'arrêt de requête du flux vidéo, et une étape d'arrêt de l'émission dudit flux vidéo vers le terminal récepteur. Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, aux étapes du procédé d'émission défini ci-dessus. 3047377 5 Selon un mode particulier de réalisation, l'équipement émetteur est un terminal comprenant un écran et l'équipement émetteur affiche sur ledit écran une information indiquant l'arrêt de la transmission du flux vidéo vers le terminal récepteur. Ainsi, l'utilisateur de l'équipement émetteur est informé que son flux vidéo n'est plus transmis 5 vers le terminal récepteur. Selon un autre mode particulier de réalisation, l'équipement émetteur est un terminal comprenant une caméra capturant le flux vidéo, et suite à la réception du message précité, l'équipement émetteur arrête la capture dudit flux vidéo par la caméra. Ainsi, l'utilisation des ressources de l'équipement émetteur est optimisée, et notamment la 10 charge de la batterie de l'équipement émetteur est économisée. Selon un autre mode particulier de réalisation du procédé de réception et/ou du procédé d'émission, le message comprend un code indiquant un arrêt de requête vidéo et le message est transmis dans un flux vidéo émis par le terminal récepteur selon le protocole RTP. Ce mode particulier de réalisation de l'invention permet d'utiliser un flux vidéo RTP 15 utilisé pour transmettre la vidéo capturée par le terminal récepteur afin de transmettre à l'équipement émetteur l'indication d'arrêter la transmission du flux vidéo par l'équipement émetteur. Selon ce mode particulier de réalisation de l'invention, un code spécifique est inséré dans le flux vidéo RTP. Ce mode particulier de réalisation de l'invention permet de ne pas modifier les paramètres négociés au début de la session de communication. 20 L'avantage de ce mode particulier de réalisation de l'invention est qu'il n'augmente pas le nombre de messages de signalisation transmis entre l'équipement émetteur et le terminal récepteur pour la mise en oeuvre de l'invention. Selon un autre mode particulier de réalisation du procédé de réception et/ou du procédé d'émission, le message est un message SIP de renégociation des paramètres de la 25 communication établie entre l'équipement émetteur et le terminal récepteur. Ce mode particulier de réalisation de l'invention offre l'avantage que les équipements réseaux via lesquels les flux de signalisation de la communication sont transmis sont informés qu'un flux vidéo n'est plus transmis depuis l'équipement émetteur vers le terminal récepteur. Ainsi, il est possible pour l'opérateur d'adapter la facturation de la communication en 30 tenant compte du fait que la communication selon la composante vidéo n'est plus en mode full duplex (dans les deux sens), mais seulement en mode half-duplex (dans un sens seulement). 3047377 6 De plus, il n'est pas nécessaire selon ce mode particulier de réalisation de l'invention de normaliser l'invention car les messages SIP de renégociation sont déjà supportés par les terminaux de communication. L'invention concerne également un dispositif récepteur apte à mettre en oeuvre le procédé 5 de réception selon l'un quelconque des modes particuliers de réalisation de l'invention. Un tel dispositif comprend un module de communication adapté à la réception d'un flux vidéo émis par un équipement émetteur. Avantageusement, le dispositif comprend en outre un module de détection configuré pour détecter un état du dispositif inadapté à la visualisation par un utilisateur du dispositif, du flux vidéo de la communication reçu en 10 provenance de l'équipement émetteur, un module de traitement configuré pour, suite à la détection dudit état, déclencher l'envoi, via le module de communication, à l'équipement émetteur d'un message adapté pour déclencher sur l'équipement émetteur l'arrêt de l'émission vers le dispositif dudit flux vidéo. Selon un mode particulier de réalisation de l'invention, le dispositif récepteur est compris 15 dans un terminal. L'invention concerne également un dispositif émetteur apte à mettre en oeuvre le procédé d'émission selon l'un quelconque des modes particuliers de réalisation de l'invention. Un tel dispositif comprend un module de communication adapté pour émettre un flux vidéo vers un terminal récepteur, un module de traitement configure pour, suite à la réception 20 par le module de communication d'un message indiquant une demande d'arrêt de requête du flux vidéo, en provenance du terminal récepteur, arrêter l'émission dudit flux vidéo vers le terminal récepteur. Selon un mode particulier de réalisation de l'invention, le dispositif émetteur est compris dans un terminal ou un serveur ou un objet connecté. 25 Dans un mode particulier de réalisation de l'invention, les différentes étapes du procédé de réception d'un flux vidéo et du procédé d'émission d'un flux vidéo sont mises en oeuvre par des instructions de programmes d'ordinateurs. En conséquence, l'invention vise aussi des programmes d'ordinateur sur un support d'informations, ces programmes étant susceptibles d'être mis en oeuvre respectivement 30 dans un terminal ou plus généralement dans un ordinateur, ces programmes comportant respectivement des instructions adaptées à la mise en oeuvre des différentes étapes du 3047377 7 procédé de réception d'un flux vidéo et du procédé d'émission d'un flux vidéo qui viennent d'être décrits. Ces programmes peuvent 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 5 objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de 10 stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique ou électronique, par exemple une clé USB ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal 15 é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'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans 20 l'exécution des procédés en question. Liste des figures D'autres avantages et caractéristiques de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier de l'invention, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi 25 lesquels: la figure 1 présente un environnement de mise en oeuvre de l'invention selon un mode particulier de réalisation de l'invention, la figure 2 présente des étapes du procédé de réception et des étapes du procédé d'émission d'un flux vidéo selon un mode particulier de réalisation de l'invention, 3047377 8 les figures 3A et 3B illustrent schématiquement respectivement un terminal adapté à la mise en oeuvre des étapes du procédé de réception d'un flux vidéo et un terminal adapté à la mise en oeuvre des étapes du procédé d'émission d'un flux vidéo selon un mode particulier de réalisation de l'invention, 5 les figures 4A à 4E illustrent schématiquement un terminal adapté à la mise en oeuvre des étapes du procédé de réception d'un flux vidéo selon différents variantes de réalisation de l'invention. Description d'un mode particulier de réalisation de l'invention La figure 1 présente un environnement de mise en oeuvre de l'invention selon un mode 10 particulier de réalisation de l'invention. La figure 1 présente un réseau de communication mobile RES constitué par un réseau d'accès radio cellulaire 4G d'un opérateur de télécommunication, connecté à un sous-système IMS (pour IP Multimedia Subsystem) du même opérateur. Un tel réseau de communication RES comprend une architecture apte à fournir un service de communication vidéo selon la norme ViLTE (GSMA IR.94). 15 Le réseau de communication RES est ici représenté comme un seul réseau de communication d'un opérateur pour plus de simplicité. Selon d'autres variantes, le réseau de communication RES peut aussi être constitué de plusieurs réseaux de communication gérés par des opérateurs de télécommunication différents et interconnectés entre eux par des serveurs d'interconnexion (non représentés). 20 La figure 1 comprend également des terminaux TR et TE connectés au réseau de communication RES, via respectivement une première et une deuxième cellules radio 4G ou antenne eNodeB (non représentées). De manière connue, la connexion des terminaux TR et TE au réseau de communication RES est effectuée via une procédure d'attachement telle que définie dans la norme 3GPP TS 23 401.. 25 Les terminaux TR et TE peuvent être tout type de terminaux apte à établir des communications audio et vidéo selon les normes VoLTE et ViLTE. Lorsque les terminaux TR et TE sont en communication vidéo selon la norme ViLTE, le terminal TR reçoit un flux vidéo émis par le terminal TE et l'affiche sur son écran afin que l'utilisateur du terminal TR regarde le flux vidéo émis par le terminal TE. Ce flux vidéo peut représenter l'utilisateur 30 du terminal TE en communication ou bien une vidéo que l'utilisateur du terminal TE souhaite partager avec l'utilisateur du terminal TR. Une telle vidéo peut être une vidéo capturée en temps réel au cours de la communication par la caméra arrière du terminal 3047377 9 TE ou bien une vidéo enregistrée au préalable disponible sur le terminal TE ou sur un serveur d'un réseau de communication et téléchargée par le terminal TE. Eventuellement, au cours de la communication vidéo, le terminal TR capture, via la caméra avant de terminal TR, un flux vidéo représentant l'utilisateur du terminal TR et 5 l'envoie au terminal TE qui l'affiche sur son écran afin que l'utilisateur du terminal TE voie l'utilisateur du terminal TR au cours de la communication. Selon une autre variante, le terminal TE est un serveur de flux multimédia depuis lequel le terminal TR télécharge et visualise un flux vidéo. Par exemple, un tel serveur de flux multimédia est un serveur offrant un service de vidéo à la demande. 10 Une communication vidéo nécessite des ressources importantes, notamment au niveau des cellules radio 4G auxquelles le terminal TE et le terminal TR sont respectivement attachées. Afin d'optimiser la bande passante utilisée pour la communication vidéo, le terminal TR met en oeuvre le procédé de réception d'un flux vidéo émis par le terminal TE selon un mode particulier de réalisation de l'invention et le terminal TE met en oeuvre le 15 procédé d'émission selon un mode particulier de réalisation de l'invention. La figure 2 illustre des étapes du procédé de réception, mis en oeuvre par le terminal TR, d'un flux vidéo émis par le terminal TE, et des étapes du procédé d'émission mis en oeuvre par le terminal TE, selon un premier mode particulier de réalisation de l'invention. Dans ce premier mode particulier de réalisation de l'invention, l'envoi par le terminal TR 20 d'une information indiquant au terminal TE de ne plus envoyer de flux vidéo au terminal TR est fait par l'envoi d'un code spécifique dans le flux RTP du média vidéo émis par le terminal TR. Selon ce premier mode particulier de réalisation de l'invention, le support par le terminal TR et par le terminal TE d'un tel mécanisme doit être négocié lors de l'établissement de la session de communication. Pour cela, un nouveau paramètre appelé 25 par exemple «VWD » (pour Video Watcher Detection en anglais) est inséré dans le champ SDP des messages de signalisation échangés lors de la négociation des paramètres de la session de communication entre le terminal TR et le terminal TE. Un tel paramètre VWD peut être affecté d'une valeur booléenne « YES/NO » (oui/non en français) indiquant : lorsque la valeur est « YES » que le terminal envoyant le SDP supporte le procédé 30 selon l'invention selon le premier mode de réalisation décrit ici, lorsque la valeur est « NO » que le terminal envoyant le SDP ne supporte pas le procédé selon l'invention selon le premier mode de réalisation décrit ici. 3047377 10 Lors d'une étape E200, afin d'établir une communication visiophonique entre le terminal TE et le terminal TR, le terminal TR envoie un message SIP INVITE au terminal TE, via le réseau RES. Un tel message SIP INVITE comprend un champ SDP comprenant au moins un paramètre indiquant un codec audio, par exemple WB-AMR, et un paramètre indiquant 5 un codec vidéo, par exemple H.264, à utiliser lors de la communication à établir. Le champ SDP comprend également le paramètre «VWD » associé au paramètre de codec vidéo. Dans l'exemple de réalisation décrit ici, le paramètre « VWD » est affecté de la valeur « YES ». Tous les messages de signalisation SIP échangés entre les terminaux TE et TR et le 10 réseau RES lors des phases d'établissement d'une communication (par exemple message SIP 100 Trying, SIP 180 Ringing , SIP 200 OK, SIP ACK,) ne sont pas représentés dans les figures pour plus de clarté et ne sont pas décrits ici. De tels messages sont connus de l'homme du métier et ne sont pas modifiés par les procédés de réception et d'émission selon l'invention. 15 Lors de l'étape E200, le terminal TE reçoit le message SIP INVITE émis par le terminal TR. On suppose que le terminal TE supporte le codec audio WB-AMR, le codec vidéo H.264 et les procédés de réception et d'émission selon le premier mode particulier de réalisation de l'invention. Au cours d'une étape E201, le terminal TE envoie alors, via le réseau RES, au terminal TR 20 en réponse, un message SIP 2000k comprenant un champ SDP comprenant notamment : un paramètre indiquant le codec audio WB-AMR, un paramètre indiquant le codec vidéo H.264 et un paramètre « VWD » affecté de la valeur « YES ». Au cours d'une étape E202, la communication visiophonique entre le terminal TE et le terminal TR est établie en mode « full duplex ». Un flux audio et un flux vidéo sont 25 transmis depuis le terminal TR vers le terminal TE et depuis le terminal TE vers le terminal TR selon le protocole de transport RTP. Au cours de l'étape E202, le terminal TR affiche sur son écran le flux vidéo reçu du terminal TE de sorte que l'utilisateur visualise un tel flux. Au cours d'une étape E203, le terminal TR détecte un état du terminal TR inadapté à la 30 visualisation par l'utilisateur du terminal TR du flux vidéo reçu. 3047377 11 Par exemple, l'utilisateur du terminal TR a positionné le terminal TR près de son oreille pour écouter la conversation, ou bien le terminal TR est dans une position dans laquelle l'utilisateur ne peut visualiser un flux. L'étape 203 de détection de l'état du terminal peut être mise en oeuvre selon différentes 5 variantes pouvant être utilisées seules ou en combinaison. Le terminal TR détecte par exemple au moyen d'un capteur gyroscopique placé dans le terminal TR que l'écran du terminal TR est incliné par rapport à un axe vertical ou horizontal définis par rapport au terminal TR. Par exemple, sur la figure 4A, l'utilisateur du terminal TR peut faire tourner le terminal TR selon l'axe X (horizontal) et/ou selon l'axe Y 10 (vertical). Le terminal TR a mémorisé au préalable, à l'aide du capteur gyroscopique, une position initiale du terminal TR et donc de l'écran, par rapport à l'axe vertical et/ou horizontal du terminal TR, une telle position initiale étant adaptée à la visualisation de l'écran par un utilisateur. Par exemple, une position initiale peut être enregistrée par le terminal TR 15 lorsque l'utilisateur du terminal TR accepte la demande de communication reçue lors de l'étape E200. Lorsque l'utilisateur du terminal TR accepte la demande de communication, le terminal TR est en général dans une position dans laquelle l'utilisateur peut voir correctement l'écran du terminal TR. Le terminal TR est donc dans cette position initiale dans un état adapté à la visualisation d'un flux vidéo par l'utilisateur. 20 Le terminal TR dispose également en mémoire de valeurs seuils d'angle selon l'axe Y et selon l'axe X. Par exemple, des telles valeurs seuils peuvent être selon l'axe Y : +60° et 60° et selon l'axe X : +60° et -60°. . Lorsque le terminal TR détecte, via le capteur gyroscopique, que la position du terminal TR est incliné selon l'axe Y ou selon l'axe X d'une valeur d'angle par rapport à la position 25 initiale qui est supérieure à la valeur seuil selon l'axe Y, respectivement X, en mémoire , le terminal TR identifie qu'il est dans un état inadapté à la visualisation de l'écran par un utilisateur et donc que le terminal TR est dans un état inadapté à la visualisation du flux vidéo émis par le terminal TE. Selon une autre variante, à l'aide des images capturées par la caméra avant du terminal 30 TR (CAM, figure 4D), autrement dit la caméra placée sur le même côté du terminal TR que l'écran du terminal TR, le terminal TR met en oeuvre une détection de visage ou 3047377 12 d'yeux sur les images capturées. Selon cette variante, le terminal TR détecte si le visage de l'utilisateur du terminal TR est placé devant l'écran du terminal TR et s'il est donc en position de pouvoir visualiser le flux vidéo émis par le terminal TE. Si le terminal TR ne détecte ni visage, ni yeux dans les images capturées par la caméra CAM, cela signifie que 5 le terminal TR n'est pas positionné face à l'utilisateur et que le terminal TR est donc dans une position dans laquelle l'utilisateur ne peut pas regarder l'écran. Par exemple, l'utilisateur a placé le terminal TR dans sa poche ou dans son sac, ou sur une table... Le terminal TR identifie ainsi qu'il est dans un état inadapté à la visualisation du flux vidéo émis par le terminal TE. 10 Selon une autre variante, le terminal TR est muni d'un capteur de température couplé à un capteur haptique (TEM, figure 4C). Le capteur de température permet au terminal TR de mesurer la température au niveau du capteur TEM. Le capteur haptique placé à proximité du capteur de température permet de détecter une pression de l'oreille de l'utilisateur. Un tel couple TEM de capteurs permet ainsi de détecter si l'utilisateur a placé 15 le terminal TR près de son oreille pour écouter la conversation. Dans une telle position, le terminal TR est dans un état inadapté à la visualisation par l'utilisateur du flux vidéo émis par le terminal TE. Selon une autre variante, le terminal TR est muni d'un capteur luminosité (LUM, figure 4E). Un tel capteur est placé à proximité de l'écran du terminal TR et permet au terminal 20 TR de mesurer l'exposition lumineuse subie de l'écran. Lorsque l'exposition lumineuse subie par l'écran est supérieure à un seuil prédéterminé, par exemple 500 Lux détecté sur l'écran du terminal, le terminal TR est dans un état inadapté à la visualisation par l'utilisateur du flux vidéo émis par le terminal TE. Selon une autre variante, le terminal TR détecte, via notamment le système d'exploitation 25 du terminal TR et ses API (pour Application Programming Interface en anglais), l'application affichée en avant-plan sur l'écran du terminal TR (AP, figure 4C). Lorsque l'application affichée en avant-plan ne correspond pas à l'application de visiophonie avec laquelle la communication visiophonique est établie, le terminal TR est dans un état inadapté à la visualisation par l'utilisateur du flux vidéo émis par le terminal TE. 3o Selon encore une autre variante, le terminal TR détecte, via notamment le système d'exploitation du terminal TR et ses API, la mise en mode veille de l'écran du terminal TR. 304 73 7 7 13 Lorsque l'écran est en mode veille, le terminal TR est dans un état inadapté à la visualisation par l'utilisateur du flux vidéo émis par le terminal TE. Selon encore une autre variante, le terminal TR détecte, via notamment le système d'exploitation du terminal TR et ses API, le niveau de charge de la batterie du terminal 5 TR. Lorsque le niveau de charge de la batterie est inférieur à un seuil prédéterminé, par exemple 5% de charge, le terminal TR est dans un état inadapté à la visualisation par l'utilisateur du flux vidéo émis par le terminal TE. Suite à l'étape E203, lorsque le terminal TR a détecté qu'il est dans un état inadapté à la visualisation par l'utilisateur du flux vidéo émis par le terminal TE, c'est-à-dire une position 10 inadaptée ou un état interne (niveau de charge de batterie, exécution d'autres applications affichées sur l'écran, écran en mode veille) inadapté à une visualisation de l'écran par l'utilisateur, le terminal TR déclenche l'envoi au terminal TE d'un message permettant de déclencher sur le terminal TE l'arrêt de l'émission vers le terminal TR du flux vidéo de la communication. 15 Lors d'une étape E204, le terminal TR envoie alors via le canal de transmission du flux vidéo qu'il émet à destination du terminal TE selon le protocole RTP, un paquet RTP spécifique comprenant un code indiquant un arrêt de requête vidéo, par exemple un tel paquet est appelé « Stop Video Request ». Suite à la réception par le terminal TE du paquet RTP « Stop Video Request », au cours 20 d'une étape E205, le terminal TE arrête l'émission du flux vidéo vers le terminal TR. Puis, le terminal TE envoie en réponse au terminal TR un paquet RTP d'acquittement, par exemple appelé « Stop Video Ack » (non représenté). La communication visiophonique établie lors de l'étape E202 se poursuit au cours de l'étape E206. Au cours de l'étape E206, seul le terminal TR transmet au terminal TE un 25 flux audio et vidéo. Le terminal TE ne transmet au terminal TR qu'un flux audio. Le flux audio est donc toujours transmis en mode « full duplex », le flux vidéo est transmis en mode « half duplex ». Selon une variante, au cours de l'étape E206, le terminal TE continue cependant la transmission au terminal TR de paquets selon le protocole RTCP Vidéo de sorte à fournir 30 au terminal TR des informations sur la qualité (QOS) de la vidéo que le terminal TR émet et à maintenir un flux associé à un média vidéo dans les équipements traversés du réseau 3047377 14 RES. Un tel mécanisme permet de maintenir les éventuels traductions (« binding » en anglais) NAT (pour Network Adress Translation en anglais à faire par ces équipements et éviter que la libération de la communication par les équipements média (par exemple la AGW IMS pour Access GateWay IMS) lorsqu'ils détectent une inactivité média. 5 Selon un mode particulier de réalisation de l'invention, lors d'une étape E207, le terminal TE affiche à l'utilisateur une information indiquant l'arrêt de la transmission du flux vidéo vers le terminal récepteur. Par exemple, le terminal TE affiche un message texte indiquant que le terminal TR ne permet pas temporairement de regarder la vidéo. Ou bien, le terminal TE affiche un fond noir dans la zone où la vidéo capturée par le terminal TE est 10 habituellement affichée lors d'une communication visiophonique, éventuellement accompagné du message texte précité. Selon un autre mode particulier de réalisation de l'invention, lors d'une étape E208, le terminal TE commande l'arrêt de l'encodage de la vidéo capturée par la caméra placée à l'avant du terminal TE. 15 Selon encore un autre mode particulier de réalisation de l'invention, lors de l'étape E208, le terminal TE commande l'arrêt de la capture par la caméra placée à l'avant du terminal TE de la vidéo. Selon un mode particulier de réalisation de l'invention, lors d'une étape E209, le terminal TR détecte que la condition détectée lors de l'étape E203 n'est plus vérifiée. Par exemple, 20 le terminal TR met en oeuvre régulièrement l'étape de détection E203. Au cours de l'étape E209, le terminal TR identifie donc qu'il est dans un état adapté à la visualisation, par l'utilisateur, du flux vidéo émis par le terminal TE. Lors d'une étape E210, le terminal TR envoie au terminal TE un message permettant de déclencher sur le terminal TE la reprise de l'émission du flux vidéo vers le terminal TR. 25 Selon ce mode particulier de réalisation de l'invention, au cours de l'étape E210, le terminal TR envoie au terminal TE un paquet RTP spécifique, par exemple appelé « Restart Video Request ». Suite à la réception par le terminal TE du paquet RTP « Restart Video Request », le terminal TE envoie en réponse au terminal TR un message d'acquittement, sous la forme d'un paquet RTP, par exemple appelé « Restart Video 30 Ack ». 3047377 15 Puis, lors d'une étape E211, le terminal TE commande la reprise de la transmission vers le terminal TR du flux vidéo capturé par la caméra utilisée par le terminal TE. Lorsque le terminal TE avait arrêté l'encodage et/ou la capture du flux vidéo, le terminal TE commande la reprise de la capture du flux vidéo et de l'encodage. 5 La communication visiophonique se poursuit au cours de l'étape E212 en mode « full duplex » pour la composante vidéo. Au cours de l'étape E212, le terminal TR transmet au terminal TE un flux audio et vidéo et le terminal TE transmet au terminal TR un flux audio et un flux vidéo. 10 Selon un deuxième mode particulier de réalisation de l'invention, l'envoi par le terminal TR d'une information indiquant au terminal TE de ne plus envoyer de flux vidéo au terminal TR est fait par l'envoi d'un message de renégociation des paramètres de la communication. Selon ce deuxième mode particulier de réalisation de l'invention, la communication visiophonique entre le terminal TR et le terminal TE est établie de manière 15 classique (sans paramètre « VWD » dans le champ SDP). Selon ce deuxième mode particulier de réalisation de l'invention, seules les étapes E204 et E210 sont modifiées. Suite à l'étape E203, lorsque le terminal TR a détecté qu'il est dans un état inadapté à la visualisation par l'utilisateur du flux vidéo émis par le terminal TE, le terminal TR envoie 20 au terminal TE, lors de l'étape E204, un message SIP Re-Invite comprenant dans un champ attribut SDP un paramètre « Audio a=sendrcv » indiquant que le terminal TR peut envoyer et recevoir un flux audio et un paramètre « Video a=sendonly » indiquant que le terminal TR peut envoyer un flux vidéo mais ne peut pas en recevoir. Lorsque le terminal TE reçoit le message de renégociation SIP Re-Invite, le terminal TE 25 envoie au terminal TR en réponse un message SIP 2000K comprenant dans le champ SDP un paramètre « Audio a=sendrcv » indiquant que le terminal TE peut envoyer et recevoir un flux audio et un paramètre « Video a= rcvonly » indiquant que le terminal TE peut uniquement recevoir un flux vidéo. Suite à l'étape E209, lorsque le terminal TR a détecté qu'il est dans un état adapté à la 30 visualisation par l'utilisateur du flux vidéo émis par le terminal TE, le terminal TR envoie au terminal TE, lors de l'étape E210, un message SIP Re-Invite comprenant dans un 3047377 16 champ SDP un paramètre « Audio a=sendrcv » indiquant que le terminal TR peut envoyer et recevoir un flux audio et un paramètre « Video a=sendrcv » indiquant que le terminal TR peut envoyer et recevoir un flux vidéo. Lorsque le terminal TE reçoit ce message de renégociation SIP Re-Invite, le terminal TE 5 envoie au terminal TR en réponse un message SIP 2000K comprenant dans le champ SDP un paramètre « Audio a=sendrcv » et un paramètre « Video a= sendrcv » indiquant que le terminal TE peut envoyer et recevoir un flux vidéo. La figure 3A illustre schématiquement un dispositif DR adapté pour la mise en oeuvre du procédé de réception d'un flux vidéo selon un mode particulier de réalisation de 10 l'invention. Le dispositif DR a l'architecture classique d'un ordinateur. Le dispositif DR comprend un module de stockage MEMR, par exemple une mémoire, un module de traitement PROCR, équipé par exemple d'un microprocesseur, et piloté par un programme d'ordinateur PGR. A l'initialisation, les instructions de code du programme d'ordinateur PGR sont par 15 exemple chargées en mémoire MEMR avant d'être exécutées par le processeur du module de traitement PROCR. Selon les instructions du programme d'ordinateur PGR, le processeur du module de traitement PROCR met en oeuvre les étapes du procédé de réception d'un flux vidéo émis par un équipement émetteur, au cours d'une communication établie entre l'équipement 20 émetteur et le dispositif DR. Le processeur du module de traitement PROCR met notamment en oeuvre les étapes de détection d'un état du dispositif DR inadapté à la visualisation par un utilisateur du dispositif DR, du flux vidéo de la communication reçu en provenance de l'équipement émetteur, et d'envoi à l'équipement émetteur d'un message adapté à déclencher sur l'équipement émetteur l'arrêt de l'émission vers le dispositif DR 25 dudit flux vidéo. Le dispositif DR comprend aussi un module de communication COMR adapté pour communiquer avec d'autres équipements via notamment le réseau de communication RES décrit en relation avec la figure 1. Le module de communication COMR coopère avec le module de traitement PROCR pour permettre notamment au dispositif DR d'établir une 30 communication, via le réseau RES, avec l'équipement émetteur et envoyer à l'équipement émetteur ledit message. 3047377 17 Le dispositif DR dispose d'un module d'affichage (AFFR), tel qu'un écran, permettant l'affichage d'un flux vidéo émis par l'équipement émetteur. Le dispositif DR comprend au moins une caméra (CAM) placée sur la même face que l'écran du dispositif. 5 Le dispositif DR comprend un ensemble d'API associées au système d'exploitation (OS : operating system en anglais)) du dispositif DR permettant au dispositif DR de détecter un état interne du dispositif (application affichée sur l'écran, mode veille activé/désactivé, niveau de charge de la batterie). Eventuellement, le dispositif DR comprend de capteurs (CAP) adaptés pour mesurer un 10 état du dispositif DR, tels que capteur gyroscopique, capteur de température et capteur de pression, capteur de luminosité. Selon un mode particulier de réalisation de l'invention, le dispositif DR est compris dans un terminal mobile, ou un smartphone (téléphone intelligent), une tablette, etc... La figure 3B illustre schématiquement un dispositif DE adapté pour la mise en oeuvre du 15 procédé d'émission d'un flux vidéo selon un mode particulier de réalisation de l'invention. Le dispositif DE a l'architecture classique d'un ordinateur. Le dispositif DE comprend un module de stockage MEME, par exemple une mémoire, un module de traitement PROCE, équipé par exemple d'un microprocesseur, et piloté par un programme d'ordinateur PGE. A l'initialisation, les instructions de code du programme d'ordinateur PGE sont par 20 exemple chargées en mémoire MEME avant d'être exécutées par le processeur du module de traitement PROCE. Selon les instructions du programme d'ordinateur PGE, le processeur du module de traitement PROCE met en oeuvre les étapes du procédé d'émission d'un flux vidéo vers un terminal récepteur, au cours d'une communication établie entre le dispositif DE et le 25 terminal TR. Le processeur du module de traitement PROCR met notamment en oeuvre les étapes de réception en provenance du terminal récepteur d'un message indiquant une demande d'arrêt de requête du flux vidéo, et d'arrêt de l'émission dudit flux vidéo vers le terminal récepteur. Le dispositif DE comprend aussi un module de communication COME adapté pour 30 communiquer avec d'autres équipements via notamment le réseau de communication RES 3047377 18 décrit en relation avec la figure 1. Le module de communication COME coopère avec le module de traitement PROCE pour permettre notamment au dispositif DE d'établir une communication, via le réseau RES, avec le terminal récepteur TR et recevoir en provenance du terminal TR ledit message précité. 5 Eventuellement, le dispositif DE dispose d'un module d'affichage (AFFE), tel qu'un écran, permettant l'affichage d'un flux vidéo reçu depuis le terminal récepteur. Le dispositif DE comprend au moins une caméra placée sur la même face que l'écran du dispositif DE. Le module de traitement PROCE, sur instructions du programme d'ordinateur PGE, est apte : 10 à commander et à arrêter la capture d'un flux vidéo de l'utilisateur du dispositif DE, à commander l'encodage et l'arrêt de l'encodage du flux vidéo capturé selon un codec déterminé par les paramètres de la communication établie avec le terminal TR, 15 à commander l'envoi et l'arrêt de l'envoi du flux vidéo au terminal TR selon le protocole RTP. Selon un mode particulier de réalisation de l'invention, le dispositif DE est compris dans un terminal mobile ou fixe, par exemple le terminal TE de la figure 1, une tablette, ou un ordinateur. 20 Selon un autre mode particulier de réalisation de l'invention, le dispositif DE est compris dans un serveur multimédia apte à fournir un service de téléchargement ou de « streaming » vidéo à un terminal récepteur. Selon un autre mode particulier de réalisation de l'invention, le dispositif DE décrit à la figure 3B et le dispositif DR décrit à la figure 3A sont compris dans un même terminal 25 mobile (téléphone mobile, smartphone, ou tablettes). REVENDICATIONS1. Procédé de réception, mis en oeuvre par un terminal récepteur (TR), d'un flux vidéo émis par un équipement émetteur (TE), au cours d'une communication établie (E202) entre ledit équipement émetteur et ledit terminal récepteur, caractérisé en ce qu'il comprend les étapes suivantes: - détection (E203) d'un état du terminal récepteur inadapté à la visualisation, par un utilisateur du terminal récepteur, du flux vidéo de la communication reçu en provenance de l'équipement émetteur, - envoi (E204) à l'équipement émetteur d'un message adapté pour déclencher sur l'équipement émetteur l'arrêt (E205) de l'émission vers le terminal récepteur dudit flux vidéo. 2. Procédé de réception selon la revendication 1, comprenant en outre les étapes suivantes : - détection d'un état du terminal récepteur adapté à la visualisation, par un utilisateur du terminal récepteur, du flux vidéo de la communication émis par l'équipement émetteur, - envoi à l'équipement émetteur d'un message adapté pour déclencher sur l'équipement émetteur la reprise de l'émission vers le terminal récepteur dudit flux vidéo. 3. Procédé de réception selon la revendication 1, dans lequel l'étape de détection de l'état zo du terminal récepteur est mise en oeuvre par au moins une des sous-étapes suivantes : - détection d'une inclinaison par rapport à un axe vertical ou horizontal, d'un écran du terminal récepteur, selon un angle d'une valeur supérieure ou égale à une valeur d'un angle prédéterminé, ledit angle étant calculé par rapport à une position initiale prédéterminée de l'écran adaptée à la visualisation de l'écran par un utilisateur, 25 - détection d'un visage face à l'écran du terminal récepteur, -détection d'une valeur d'exposition lumineuse supérieure ou égale à une valeur seuil prédéterminée, 3047377 - détection d'une mise en avant-plan d'une interface d'une application exécutée par le terminal récepteur, - détection d'un passage en mode veille de l'écran du terminal récepteur. 4. Procédé d'émission, mis en oeuvre par un équipement émetteur (TE), d'un flux vidéo 5 vers un terminal récepteur (TE), au cours d'une communication établie (E202) entre ledit équipement émetteur et ledit terminal récepteur, caractérisé en ce qu'il comprend les étapes suivantes: - réception (E204) en provenance du terminal récepteur d'un message indiquant une demande d'arrêt de requête du flux vidéo, 10 - arrêt (E205) de l'émission dudit flux vidéo vers le terminal récepteur. 5. Procédé d'émission selon la revendication 4, comprenant en outre une étape d'affichage sur un écran de l'équipement émetteur d'une information indiquant l'arrêt de la transmission du flux vidéo vers le terminal récepteur. 6. Procédé d'émission selon la revendication 4, comprenant en outre une étape d'arrêt de 15 la capture dudit flux vidéo par une caméra de l'équipement émetteur. 7. Procédé selon l'une quelconque des revendications 1 ou 4, dans lequel le message comprend un code indiquant un arrêt de requête vidéo et le message est transmis dans un flux vidéo émis par le terminal récepteur selon le protocole RTP. 8. Procédé selon l'une quelconque des revendications 1 ou 4, dans lequel le message est 20 un message SIP de renégociations de paramètres de la communication établies entre l'équipement émetteur et le terminal récepteur. 9. Terminal récepteur d'un flux vidéo émis par un équipement émetteur, au cours d'une communication établie entre ledit équipement émetteur et ledit terminal récepteur, le terminal récepteur comprend un module de communication adapté à la réception dudit flux vidéo, le terminal récepteur est caractérisé en ce que : - il comprend en outre un module de détection configure pour détecter un état du terminal récepteur inadapté à la visualisation, par un utilisateur du terminal récepteur, du flux vidéo de la communication reçu en provenance de l'équipement émetteur, 3047377 21 - un module de traitement configuré pour, suite à la détection dudit état inadapté du terminal récepteur, déclencher l'envoi, via le module de communication, à l'équipement émetteur d'un message adapté pour déclencher sur l'équipement émetteur l'arrêt de l'émission vers le terminal récepteur dudit flux vidéo. 5 10. Equipement émetteur d'un flux vidéo vers un terminal récepteur, au cours d'une communication établie entre ledit équipement émetteur et ledit terminal récepteur, l'équipement émetteur comprend un module de communication adapté pour émettre dudit flux vidéo, l'équipement émetteur est caractérisé en ce qu'il comprend un module de traitement configuré pour, suite à la réception par le module de communication d'un 10 message indiquant une demande d'arrêt de requête du flux vidéo, en provenance du terminal récepteur, arrêter l'émission dudit flux vidéo vers le terminal récepteur. 11. Programme d'ordinateur comportant des instructions de code de programme pour l'exécution des étapes du procédé de réception selon l'une quelconque des revendications 1 à 3 ou 7 ou 8, ou des étapes du procédé d'émission selon l'une quelconque des 15 revendications 4 à 8, lorsque le programme est exécuté par un processeur. 12. Message émis par un terminal récepteur d'un flux vidéo émis par un équipement émetteur au cours d'une communication établie entre ledit équipement émetteur et ledit terminal récepteur, le message étant configuré pour être reçu par ledit équipement émetteur, le message est caractérisé en ce qu'il comprend un code indiquant une 20 demande d'arrêt de l'émission par l'équipement émetteur vers le terminal récepteur dudit flux vidéo. 13. Message de négociation des paramètres d'une communication à établir entre un équipement émetteur et un terminal récepteur, ladite communication comprenant au 25 moins un flux vidéo émis par l'équipement émetteur vers le terminal récepteur, - le message de négociation étant émis par le terminal récepteur vers l'équipement émetteur ou par l'équipement émetteur vers le terminal récepteur, - le message de négociation est caractérisé en ce qu'il comprend un paramètre indiquant que le terminal récepteur est adapté pour mettre en oeuvre le procédé de réception selon la revendication 7 ou que l'équipement émetteur est adapté pour mettre en oeuvre le procédé d'émission selon la revendication 7.