FR2996714A1 - Procede de selection d'un flux video en fonction d'une cible a visualiser, dispositif et programme d'ordinateur correspondants - Google Patents

Abstract

L'invention concerne un procédé de traitement de flux vidéo, mettant en œuvre, sur réception d'une requête de visualisation (Req) d'une cible (17) choisie par un utilisateur, une sélection d'un flux vidéo (Vidéo A) contenant la cible choisie. Selon l'invention, un tel procédé comprend des étapes de : - réception de métadonnées contextuelles (MCA, MCB) associées à des flux vidéo en temps réel ; - pour une liste de cibles potentielles, réception de données de géolocalisation (GL) associées aux cibles potentielles, la cible choisie par l'utilisateur étant choisie au sein de cette liste. En outre, la sélection du flux vidéo contenant la cible choisie tient compte d'un critère de proximité des données de géolocalisation (GL) de la cible choisie (17) et des métadonnées contextuelles (MCA) associées au flux vidéo sélectionné (Vidéo A).

Description

Procédé de sélection d'un flux vidéo en fonction d'une cible à visualiser, dispositif et programme d'ordinateur correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui du traitement de flux vidéo, et plus particulièrement de l'analyse de vidéos en temps réel, ou en direct. Plus précisément, l'invention concerne une technique de traitement de flux vidéo permettant d'offrir à un utilisateur une sélection de vidéos offrant le meilleur point de vue sur une cible, ou un point d'intérêt, de son choix. 2. Art antérieur et ses inconvénients Les vidéos en temps réel, permettant de suivre le déroulement d'un événement en direct, vont représenter une part de plus en plus importante des contenus consultés sur Internet dans les années à venir. En effet, le nombre de terminaux mobiles de type « Smartphones », permettant à un utilisateur de filmer son environnement, croît de manière particulièrement rapide. La mise à disposition sur Internet et le partage de vidéos filmées par le grand public se généralise massivement. A ce jour, les vidéos personnelles consultées par le grand public sur Internet sont surtout des vidéos en différé, auxquelles on accède par recherche de mots clés par exemple. Cependant, l'augmentation des débits de transmission de données facilite la diffusion massive de vidéos en temps réel, et on peut imaginer que, dans un avenir proche, on puisse consulter en direct une pluralité de vidéos relatives à un même événement, par exemple réalisées par différents utilisateurs assistant à cet événement, au moyen de leur caméscope ou de leur terminal mobile.

Un utilisateur souhaitant suivre à distance cet événement particulier, ou se concentrer sur un point d'intérêt particulier au sein de cet événement, sera donc confronté à la difficulté de choisir, parmi le grand nombre de vidéos amateurs et professionnelles à sa disposition, la ou les vidéos offrant le meilleur point de vue par rapport à son point d'intérêt. Ce choix sera d'autant plus complexe que son point d'intérêt peut être mobile (par exemple une voiture particulière au sein d'une course automobile), et que les caméras des vidéastes professionnels et amateurs peuvent également se déplacer, changer d'orientation, de direction... Une caractéristique des dispositifs d'acquisition de vidéo modernes, tels que les terminaux mobiles de type « Smartphones », est qu'ils sont généralement équipés de puces GPS (pour « General Positioning System », ou système de localisation mondial), qui leur permettent, grâce à un système de positionnement par satellite, d'être localisés et de publier (en temps réel ou de façon différée) leurs coordonnées géographiques (généralement sous forme d'un couple longitude/latitude). Les vidéos acquises au moyen de ces dispositifs sont donc des vidéos géo-référencées, en ce sens que les séquences vidéo sont associées à des métadonnées contextuelles, telles que la localisation géographique du dispositif d'acquisition de la vidéo et son orientation. On connaît, à ce jour, différentes techniques d'analyse de vidéos exploitant les métadonnées contextuelles de ces vidéos géo-référencées. Ainsi, dans l'article « Design and Implementation of geo-tagged Video Search Framework », J. Vis. Commun. Image R. 21 (2010) 773-786, Seon Ho Kim et al. ont proposé un système de recherche de séquences vidéo contenant un objet particulier, au sein d'une base de données contenant un ensemble de vidéos géo-référencées, hébergée par un serveur. Plus précisément, selon cette technique, un utilisateur qui souhaite visualiser un objet particulier envoie au serveur une requête de visualisation, contenant des informations de localisation de cet objet. En utilisant les métadonnées contextuelles associées à chaque séquence vidéo de la base de données, et notamment leurs données de géolocalisation associées, le serveur sélectionne l'ensemble des séquences sur lesquelles l'objet recherché est susceptible de figurer, en comparant ces données de géolocalisation aux informations de localisation de l'objet fournies par l'utilisateur. Selon cette technique, l'ensemble des vidéos géo-référencées disponibles sont tout d'abord collectées, indexées et pré-enregistrées, en relation avec leurs métadonnées contextuelles associées, dans une base de données. Sur réception d'une requête de visualisation d'un utilisateur, le serveur, à la recherche d'un point de vue, doit parcourir tout l'historique des vidéos préenregistrées, qui ont au préalable été indexées selon des techniques d'indexation complexes. L'algorithme de recherche de vidéos mis en oeuvre selon cette technique n'est donc pas adapté aux vidéos en temps réel. En outre, selon cette technique, la localisation de l'objet qui intéresse l'utilisateur est fournie par l'utilisateur lui-même, dans sa requête de visualisation. Cette technique, qui peut présenter un intérêt pour les objets statiques, tels que les monuments par exemple, n'est donc pas adaptée lorsque l'utilisateur souhaite rechercher une séquence vidéo contenant un objet mobile, tel qu'un véhicule en déplacement par exemple. En effet, dans le cas d'une cible mobile, il serait nécessaire que l'utilisateur envoie une nouvelle requête de visualisation à chaque changement de position de la cible, ce qui nécessiterait, de la part de l'utilisateur, une connaissance précise du déplacement de la cible, et s'avérerait particulièrement fastidieux et consommateur en ressources. Il existe donc un besoin d'une technique de sélection de séquences vidéos offrant un point de vue sur une cible choisie par un utilisateur, qui puisse être utilisée pour le traitement de séquences vidéos en temps réel et qui soit adaptée à tout type de cible, notamment aux cibles mobiles. 3. Exposé de l'invention L'invention répond à ce besoin en proposant un procédé de traitement de flux vidéo, mettant en oeuvre, sur réception d'une requête de visualisation d'au moins une cible choisie par un utilisateur, une sélection d'au moins un flux vidéo contenant ladite au moins une cible choisie, et qui comprend des étapes de : - réception d'au moins une métadonnée contextuelle associée à au moins un flux vidéo en temps réel ; - pour une liste d'au moins une cible potentielle, réception de données de géolocalisation associées à ladite au moins une cible potentielle, ladite au moins une cible choisie par ledit utilisateur étant choisie au sein de ladite liste d'au moins une cible potentielle. En outre, selon l'invention, ladite sélection d'au moins un flux vidéo contenant ladite au moins une cible choisie tient compte d'un critère de proximité desdites données de géolocalisation de ladite au moins une cible choisie et de ladite au moins une métadonnée contextuelle associée audit au moins un flux vidéo sélectionné. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de l'analyse de vidéos en temps réel et des métadonnées contextuelles qui leur sont associées, permettant d'offrir aux utilisateurs un contenu pertinent en fonction de leur point d'intérêt. En effet, l'invention propose de sélectionner dynamiquement la ou les vidéos en temps réel proposant, à un instant donné, un point de vue d'une ou plusieurs cibles recherchée(s) par un utilisateur, en comparant les métadonnées contextuelles associées aux vidéos et les données de géolocalisation de cette ou ces cibles. Un tel procédé de traitement vidéo est par exemple mis en oeuvre dans un serveur ou une plateforme de service, qui reçoit les métadonnées contextuelles associées aux flux vidéo en temps réel acquis par plusieurs sources, par exemple un ensemble de terminaux mobiles de vidéastes amateurs et de caméras professionnelles. Un tel serveur ou plateforme de service reçoit également, de la part d'un utilisateur, une requête de visualisation d'une cible choisie parmi une liste de cibles potentielles qui lui est proposée. Ainsi, dans le cadre d'un match de football par exemple, la liste de cibles potentielles proposée à l'utilisateur peut comprendre chacun des joueurs des deux équipes en compétition, ainsi que le ballon. L'utilisateur peut ainsi choisir de se focaliser sur l'un de ses joueurs préférés, ou sur le ballon pour être toujours au coeur de l'action, ou encore simultanément sur ce joueur et le ballon. On suppose que chacune des cibles potentielles est équipée d'un dispositif de géolocalisation (qui peut être de toute nature, notamment : géolocalisation par satellite, par GSM (pour « Global System for Mobile Communications » en anglais, en français « Groupe Spécial Mobile »), par WiFi, par RFID (pour « Radio Frequency Identification », en français, « identification radio fréquence »), etc.). Ainsi, les cibles envoient elles-mêmes vers le serveur ou la plateforme de service leurs données de géolocalisation, grâce à un module de communication dont elles sont équipées. Un tel procédé selon l'invention est particulièrement avantageux dans le cadre de cibles mobiles. Le serveur compare alors les métadonnées contextuelles associées aux différents flux vidéos en temps réel captés par les différentes sources avec lesquelles il est en relation et les données de géolocalisation de la ou des cible(s) choisie(s) par l'utilisateur, et sélectionne, en fonction d'un critère de proximité de ces différentes données et métadonnées, le ou les flux vidéo le(s) plus pertinent(s) pour répondre à la requête de l'utilisateur, i.e. le ou les flux vidéo offrant le meilleur point de vue sur la ou les cible(s) qu'il a choisie(s).

Le procédé selon l'invention offre la possibilité aux utilisateurs spectateurs de consommer les vidéos au moment où elles sont produites : il permet ainsi d'éviter une phase coûteuse d'indexation des séquences vidéos, qui est nécessaire selon les techniques de l'art antérieur.

Selon une première caractéristique de l'invention, un tel procédé comprend également une étape de transmission dudit au moins un flux vidéo sélectionné à un dispositif émetteur de ladite requête de visualisation. Après sélection du flux vidéo le plus pertinent par rapport à la cible choisie par l'utilisateur, ce dernier est en effet envoyé vers le terminal de l'utilisateur, pour y être visualisé. Plusieurs flux vidéo peuvent également être envoyés à l'utilisateur si plusieurs flux vidéo pertinents ont été identifiés comme répondant à son besoin. On notera que cette étape de transmission est généralement mise en oeuvre par le serveur ou la plateforme de service ayant opéré la sélection du flux vidéo. Dans ce cas, le serveur ou la plateforme de service a donc préalablement reçu ce flux vidéo en provenance de sa source, par exemple sous forme d'une réception combinée du flux vidéo et de ses métadonnées contextuelles associées. Dans un souci d'économies de ressources, notamment de bande passante, ce flux vidéo peut également n'être reçu qu'après l'étape de sélection, sur demande formulée par le serveur ou la plateforme de service auprès de sa source. On notera que, dans ce dernier cas, on perd en réactivité : en effet, le temps de réponse à l'utilisateur est accru par le temps nécessaire au serveur ou à la plateforme de service pour se procurer le flux vidéo auprès de sa source. A titre de variante, un tel procédé selon l'invention peut être mis en oeuvre sur un ensemble de serveurs, dont l'un opèrerait la sélection de flux vidéo, puis adresserait une requête spécifique à un serveur vidéo en charge de diffuser le ou les flux vidéo sélectionné(s) vers l'utilisateur en ayant fait la requête. Selon un aspect de l'invention, ladite étape de réception de données de géolocalisation associées à ladite au moins une cible potentielle est itérée périodiquement et/ou en fonction d'un déplacement de ladite au moins une cible potentielle. Ainsi, la localisation exacte des différentes cibles potentielles est toujours connue du serveur ou de la plateforme de service mettant en oeuvre le procédé de l'invention, même dans le cas de cibles mobiles. Il est donc possible de toujours sélectionner le flux vidéo le plus adapté pour visualiser une cible donnée, même en cas de déplacement de cette dernière et ce, sans que l'utilisateur n'ait besoin de signaler ce déplacement au serveur ou à la plateforme de service. La cible peut remonter ses données de géolocalisation à intervalles de temps réguliers, par exemple toutes les secondes, ou se contenter d'envoyer une mise à jour de ses données de géolocalisation uniquement en cas de modification de ces dernières, ou encore procéder selon une combinaison de ces deux alternatives. Selon un autre aspect de l'invention, l'étape de réception d'au moins une métadonnée contextuelle associée à au moins un flux vidéo en temps réel est itérée périodiquement et/ou en fonction d'un déplacement d'un dispositif d'acquisition dudit flux vidéo associé Ainsi, la localisation exacte de différents dispositifs d'acquisition de flux vidéo est toujours connue du serveur ou de la plateforme de service mettant en oeuvre le procédé de l'invention, même dans le cas de dispositifs d'acquisition, ou de capture mobiles. Il est donc possible de toujours sélectionner le flux vidéo le plus adapté pour visualiser une cible donnée, même en cas de déplacement des dispositifs d'acquisition vidéo et ce, sans que le vidéaste manipulant ce dispositif d'acquisition n'ait besoin de signaler ce déplacement au serveur ou à la plateforme de service. Les dispositifs de capture peuvent remonter leurs métadonnées contextuelles à intervalles de temps réguliers, par exemple toutes les secondes, ou se contenter d'envoyer une mise à jour uniquement en cas de modification de ces dernières, ou encore procéder selon une combinaison de ces deux alternatives. Selon un autre aspect de l'invention, l'étape de sélection est mise en oeuvre périodiquement et/ou en cas de modification des données de géolocalisation de la ou les cible(s) choisie(s) ou de la ou les métadonnée(s) contextuelle(s) associée(s) au flux vidéo sélectionné.

Ainsi, on est assuré que l'utilisateur dispose toujours du flux vidéo le plus pertinent par rapport à la cible qu'il a choisie, même en cas de déplacement de cette cible ou de la source du flux vidéo. On peut procéder à un rafraîchissement périodique de la sélection du flux vidéo, par exemple en vérifiant toutes les cinq secondes que le flux vidéo sélectionné reste le plus pertinent par rapport à la ou les cible(s) choisie(s) par l'utilisateur, en fonction du critère de proximité prédéfini dans le cadre de l'invention. En effet, un déplacement de la cible, ou de la caméra à l'origine du flux vidéo, ou un changement de direction de cette caméra, ou encore l'arrivée d'un nouveau flux vidéo dont la source serait plus proche de la cible choisie, pourraient conduire à modifier la sélection du flux vidéo, pour offrir un contenu plus pertinent à l'utilisateur. On peut également, en variante, ne rafraîchir la sélection du flux vidéo qu'en cas de détection d'un changement survenu, soit dans les données de géolocalisation de la cible choisie (déplacement de la cible), soit dans les métadonnées contextuelles du flux vidéo sélectionné (changement de localisation ou d'orientation de la caméra par exemple), soit dans les métadonnées contextuelles d'un autre flux vidéo disponible, qui pourrait ainsi devenir un meilleur candidat pour répondre à la requête d'un utilisateur (par exemple, une caméra située à proximité de la cible, mais qui n'avait pas la cible dans son angle de vision, change d'orientation pour se focaliser sur la cible choisie par l'utilisateur). On peut bien sûr également rafraîchir la sélection du flux vidéo en combinant ces différentes variantes. On rafraîchit également la sélection du flux vidéo dès que l'on reçoit une nouvelle requête de visualisation en provenance de l'utilisateur, notamment lorsque ce dernier souhaite changer de cible. Selon une caractéristique avantageuse de l'invention, ladite au moins une métadonnée contextuelle appartient au groupe comprenant : - une position d'un dispositif d'acquisition du flux vidéo associé ; - une orientation du dispositif d'acquisition ; - un angle de vision du dispositif d'acquisition ; - un paramètre de mise au point du dispositif d'acquisition. En effet, la position du dispositif d'acquisition du flux vidéo permet de connaître la localisation géographique de la source (caméra ou terminal mobile), par exemple sous la forme du triplet « longitude/latitude/altitude » du dispositif d'acquisition. L'orientation du dispositif d'acquisition définit généralement l'angle d'orientation de la caméra par rapport au nord, et éventuellement par rapport à l'axe de cote, ou d'altitude z. L'angle de vision représente la portion d'espace vue par la caméra. Enfin, les paramètres de mise au point définissent la netteté de l'image, ainsi que la distance focale de la caméra. On notera que, dans l'ensemble de ce document, on utilise indifféremment les termes dispositif d'acquisition, dispositif de capture, caméra, caméscope, source vidéo, ou encore terminal mobile pour désigner l'équipement utilisé pour faire l'acquisition d'un flux vidéo en temps réel.

Selon un aspect particulier de l'invention, l'étape de sélection comprend une première sous-étape d'identification du ou des flux vidéo pour le(s)quel(s) une distance entre la position du dispositif d'acquisition du flux vidéo et une position de la ou les cible(s) choisie(s) est inférieure à un seuil prédéterminé, la première sous-étape d'identification délivrant un premier sous-ensemble d'au moins un flux vidéo. Ainsi, pour sélectionner le flux vidéo le plus pertinent par rapport à la requête de l'utilisateur, on identifie tout d'abord, parmi l'ensemble des flux vidéos disponibles, un premier sous-ensemble de flux vidéos dont la source est située à proximité de la cible choisie, en comparant les positions respectives des caméras et de la ou des cible(s). Cela permet notamment d'écarter les flux vidéos captés par des sources situées trop loin des cibles, qui ne pourraient donc pas offrir de vue, ou une vue trop éloignée, de la ou des cibles. Par exemple, pour une cible située à Rennes (France), on peut d'embler écarter les flux vidéos captés par des dispositifs d'acquisition localisés à Paris (France). Selon un aspect complémentaire de l'invention, l'étape de sélection comprend également une deuxième sous-étape d'identification, au sein du premier sous-ensemble d'au moins un flux vidéo, du ou des flux vidéo pour le(s)quel(s) le dispositif d'acquisition du flux vidéo est orienté vers la ou les cible(s) choisie(s), la deuxième sous-étape d'identification délivrant un deuxième sous- ensemble d'au moins un flux vidéo. Après avoir écarté les flux vidéo dont les sources sont trop éloignées de la ou des cible(s) choisie(s), on s'intéresse ensuite, parmi le premier sous-ensemble de flux vidéo, à ne conserver que les flux vidéo captés par des dispositifs d'acquisition orientés vers la ou les cible(s) choisie(s). En effet, un dispositif d'acquisition peut être situé à proximité d'une cible, mais lui tourner le dos, de sorte que la cible choisie ne peut figurer sur le flux vidéo capté. On construit ainsi un deuxième sous-ensemble plus restreint de flux vidéo, enregistrés par des dispositifs d'acquisition situés à proximité de la ou des cible(s), et orienté(s) en direction de cette ou ces dernière(s). Selon un autre aspect complémentaire de l'invention, l'étape de sélection comprend également une troisième sous-étape d'identification, au sein du deuxième sous-ensemble d'au moins un flux vidéo, du ou des flux vidéo pour le(s)quel(s) l'angle de vision du dispositif d'acquisition du flux vidéo couvre la ou les cible(s) choisie(s), la troisième sous-étape d'identification délivrant un troisième sous-ensemble d'au moins un flux vidéo. Ainsi, on restreint encore le nombre de flux vidéos candidats à la sélection à un troisième sous-ensemble de flux vidéos, en ne conservant que les flux vidéo issus de dispositifs d'acquisition présentant un angle de vision suffisamment large, compte tenu de leur orientation et de la position de la cible, pour que la cible figure effectivement sur le flux vidéo. En effet, un dispositif d'acquisition peut être situé à proximité de la cible, être orienté vers la cible, mais présenter un angle de vision trop étroit pour que la cible figure effectivement dans le champ de vision de la caméra. Selon encore un aspect complémentaire de l'invention, l'étape de sélection comprend également une quatrième sous-étape d'identification, au sein du troisième sous-ensemble d'au moins un flux vidéo, du ou des flux vidéo dans le(s)quel(s) une représentation de la ou les cible(s) choisie(s) satisfait au moins un critère de qualité prédéterminé. Un tel critère de qualité peut être fonction du paramètre de mise au point du dispositif d'acquisition du flux vidéo et/ou d'une représentation significative de la cible choisie (par exemple, il faut que la cible apparaisse de suffisamment grande taille au sein de la vidéo) et/ou d'une préférence utilisateur de la représentation de la ou les cible(s) choisie(s) (par exemple, plan large ou plan rapproché). Ainsi, en tenant compte de paramètres de mise au point du dispositif d'acquisition, on peut par exemple écarter les flux vidéo sur lesquels la cible est floue, et qui n'offriraient donc pas un confort de visualisation suffisant pour l'utilisateur.

Selon un autre aspect de l'invention, un tel procédé comprend également une étape de transmission d'un message d'erreur à un dispositif émetteur de la requête de visualisation si aucun des flux vidéo ne satisfait le critère de proximité. En effet, il est possible qu'aucun des flux vidéo disponibles n'offre un contenu pertinent par rapport à la cible choisie par l'utilisateur. On en informe alors l'utilisateur, en lui adressant un message correspondant, afin de lui offrir la possibilité par exemple de choisir une autre cible au sein du même événement (par exemple, quand son joueur préféré est sur le banc de touche, et qu'aucun flux vidéo ne le fait donc apparaître, l'utilisateur peut choisir de suivre un autre joueur de l'équipe, en attendant le retour éventuel de son favori sur le terrain).

L'invention concerne également un dispositif de traitement de flux vidéo, comprenant des moyens aptes à sélectionner au moins un flux vidéo contenant au moins une cible choisie par un utilisateur, sur réception d'une requête de visualisation de ladite au moins une cible choisie.

Selon l'invention, un tel dispositif comprend : - des moyens de réception d'au moins une métadonnée contextuelle associée à au moins un flux vidéo en temps réel ; - des moyens de réception, pour une liste d'au moins une cible potentielle, de données de géolocalisation associées à ladite au moins une cible potentielle, ladite au moins une cible choisie par ledit utilisateur étant choisie parmi ladite liste d'au moins une cible potentielle. En outre, lesdits moyens aptes à sélectionner au moins un flux vidéo contenant ladite au moins une cible choisie tiennent compte d'un critère de proximité desdites données de géolocalisation de ladite au moins une cible choisie et de ladite au moins une métadonnée contextuelle associée audit au moins un flux vidéo sélectionné. Un tel dispositif peut être un serveur ou une plateforme de service mettant en oeuvre, en combinaison, tout ou partie des caractéristiques exposées précédemment en relation avec le procédé de traitement de flux vidéo de l'invention. L'invention concerne encore un programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé tel que décrit précédemment lorsque ce programme est exécuté par un processeur.

L'invention concerne également un procédé et un dispositif présentant en combinaison tout ou partie des caractéristiques exposées dans l'ensemble de ce document. 4. Liste des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : - la figure 1 présente sous forme d'organigramme les principales étapes du procédé de traitement vidéo de l'invention; - les figures 2A, 2B et 2C illustrent un exemple de mise en oeuvre des étapes du procédé de la figure 1 dans le cadre du suivi d'un marathon; - la figure 3 illustre un exemple de structure simplifiée d'un dispositif de traitement vidéo selon l'invention. 5. Description détaillée de modes de réalisation de l'invention Le principe général de l'invention repose sur l'utilisation conjointe de données de géolocalisation de cibles d'intérêt potentiel pour un utilisateur et de métadonnées contextuelles (notamment données de localisation et d'orientation) associées à un ensemble de flux vidéo en temps réel en provenance de différentes sources, pour sélectionner et offrir à un utilisateur le ou les flux vidéo dont le contenu est le plus pertinent par rapport à la ou les cibles d'intérêt qu'il a choisie(s). On présente désormais, en relation avec la figure 1, les principales étapes du procédé de traitement de flux vidéo de l'invention.

Un tel procédé est implémenté sur un serveur ou une plateforme de service comprenant éventuellement plusieurs serveurs. Par la suite, sauf précision contraire, on emploiera par souci de simplification le terme serveur pour désigner le système mettant en oeuvre les étapes de la figure 1. Ce serveur reçoit en données d'entrée : - des métadonnées contextuelles MC associées à un ou plusieurs flux vidéo en temps réel, en provenance d'une pluralité de sources d'acquisition, telles que des terminaux mobiles ou des caméras de vidéastes professionnels ou amateurs. - des données de géolocalisation GL d'une pluralité de cibles potentielles au sein d'un ou plusieurs événements gérés par le serveur ; - une requête de visualisation Req, en provenance d'un terminal d'utilisateur, comprenant un identifiant d'une cible que l'utilisateur souhaite pouvoir suivre en vidéo.

Plus précisément, on considère que le serveur gère plusieurs événements, tels que, par exemple, l'ensemble des épreuves sportives en cours dans le cadre des Jeux Olympiques. Un grand nombre de spectateurs assistent aux épreuves, et certains sont équipés de caméscopes, ou de terminaux mobiles équipés de modules d'acquisition vidéo. Un grand nombre de journalistes de chaînes de télévision sont également présents, et filment l'ensemble des épreuves. Toutes ces vidéos professionnelles ou amateurs en direct offrent de nombreux points de vue, très divers, sur les épreuves, les différents athlètes, mais également l'environnement dans lequel elles se déroulent.

On suppose que tous ces dispositifs d'acquisition vidéo (caméscopes, terminaux mobiles, caméras...) sont équipés de moyens de localisation (par exemple une puce GPS ou équivalent), et de moyens de communication aptes à communiquer avec le serveur de l'invention. Ces dispositifs d'acquisition vidéo envoient donc au serveur des métadonnées contextuelles MC associées à la séquence vidéo qu'ils enregistrent, comprenant notamment la position des dispositifs d'acquisition, mais également d'autres données relatives au dispositif telles que, par exemple, son orientation, son angle de vision ou certains paramètres de mise au point. En effet, ces dispositifs sont souvent équipés de boussoles, qui permettent de fournir des informations utiles (comme l'orientation) pouvant caractériser le point de vue. Ces métadonnées contextuelles pourraient également contenir d'autres informations non liées à la localisation du dispositif, telles qu'un identifiant du vidéaste, une référence à l'événement filmé, etc. On notera que ces métadonnées contextuelles MC peuvent être envoyées seules au serveur, ou conjointement avec le flux vidéo auquel elles sont associées. Un utilisateur, qui, depuis son domicile, souhaite suivre en direct ces Jeux Olympiques, peut accéder à un service internet (auquel il peut avoir préalablement souscrit) au moyen d'un terminal multimédia (par exemple un terminal mobile, une tablette, un smartphone, un ordinateur, un décodeur TV...), et sélectionner plus précisément l'événement qui l'intéresse (par exemple, l'épreuve du marathon). Dans le cadre de ce service web, on propose alors à l'utilisateur une liste de cibles potentielles qu'il peut suivre plus précisément, au sein de cette épreuve du marathon. Par exemple, on propose à l'utilisateur de choisir l'un quelconque des athlètes participant à cette épreuve. On suppose, dans le cadre de l'invention, que chacun de ces coureurs est équipé d'un module communicant GPS, apte à transmettre à chaque instant au serveur les données de géolocalisation du coureur considéré.

Le terminal de l'utilisateur adresse donc une requête Req de visualisation au serveur de l'invention, indiquant qu'il souhaite suivre l'évolution du coureur portant le dossard n°17. Le serveur va alors s'efforcer de sélectionner 10, parmi l'ensemble des vidéos en temps réel à sa disposition, la ou les vidéos offrant le point de vue le plus pertinent sur le coureur n°17. Pour ce faire, au cours d'une première étape ID1, le serveur sélectionne, parmi l'ensemble des flux vidéo en temps réel à sa disposition, ceux qui concernent des événements se déroulant dans la même zone géographique que la cible (coureur n°17). Plus précisément, le serveur compare la position de la cible, qu'il connaît grâce aux données de géolocalisation GL associées qu'il reçoit, et la position des dispositifs d'acquisition des différents flux vidéos. Cette position est déterminée à partir des métadonnées contextuelles MC, par exemple sous la forme de coordonnées de latitude et de longitude GPS (et éventuellement d'altitude). On définit un critère de proximité, sous la forme d'un seuil : à l'issue de l'étape ID1, le serveur sélectionne donc l'ensemble des flux vidéo pour lesquels la distance entre la position de la caméra et la position du coureur n°17 est inférieure à ce seuil. On notera que la valeur de ce seuil peut être configurée, dans le cadre du service proposé, en fonction du type d'événement considéré, et de la nature de la cible. Par exemple, dans le cas du marathon, on sélectionne tous les flux vidéo acquis par des caméras disposées dans un périmètre d'un kilomètre autour du coureur n°17.

On notera que, dans le cas où le serveur gère plusieurs événements géographiquement éloignés les uns des autres, les flux vidéos peuvent être classés, au sein du serveur, en fonction de la zone géographique dans laquelle ils se déroulent. Par exemple, le serveur peut gérer, d'une part, les épreuves sportives des Jeux Olympiques, et d'autre part, un festival se déroulant dans une autre région. On peut donc demander à l'utilisateur de choisir l'événement qui l'intéresse (le festival ou l'une des épreuves des Jeux Olympiques). De cette façon, au cours de l'étape ID1, le serveur n'analyse pas l'ensemble des flux vidéo qu'il gère, mais seulement ceux qui ont été classés comme étant associés à 2 996 714 14 l'événement choisi par l'utilisateur, afin d'identifier le ou les flux vidéo appartenant à la même zone géographique que la cible choisie. Au cours d'une deuxième étape 1D2, le serveur restreint sa sélection de flux vidéos, en prenant en compte l'orientation des caméras, afin de ne conserver 5 qu'un sous-ensemble de flux vidéos capturés par des caméras proches de la cible et orientées vers la cible. Cette orientation de la caméra est définie par l'angle a d'orientation de la caméra par rapport au nord, et éventuellement par rapport à l'axe z des altitudes. Cet angle a, compris entre 0° et 360°, est généralement donné par un compas 10 numérique dont est équipé le dispositif d'acquisition vidéo, et qui est dirigé selon l'axe de la lentille de la caméra. Par exemple, on considère que la caméra permet de filmer tout ce qui se trouve dans un secteur angulaire d'angle 6, centré sur l'axe principal de la caméra, qui présente un angle a d'orientation par rapport au nord. Grâce à la 15 connaissance de la position de la caméra et de la cible, on peut déterminer si la cible se trouve dans ce secteur angulaire couvert par la caméra. Au cours d'une troisième étape ID3, le serveur raffine ensuite la sélection de flux vidéo obtenue à l'issue de l'étape ID2 précédente, en tenant compte de l'angle de vision 6 véritable de la caméra. Cet angle de vision représente la 20 portion d'espace vue par la caméra. Plus l'angle de vision est étroit, plus les zones éloignées seront filmées de près. Cet angle de vision 6 dépend par exemple du type de dispositif d'acquisition vidéo considéré, et est calculé à partir de propriétés de la caméra et de ses lentilles, pour un niveau de zoom donné ; il peut être déterminé à partir 25 des métadonnées contextuelles MC. A l'issue de la troisième étape ID3, le serveur a donc restreint la sélection à l'ensemble de flux vidéo couvrant la zone géographique de la cible, et dont l'orientation et l'angle de vision de la caméra sont tels que le flux vidéo couvre bien la cible. 30 Lors d'une quatrième étape ID4, le serveur peut encore raffiner cette sélection en tenant compte des paramètres de mise au point des caméras, obtenus à partir des métadonnées contextuelles MC. Ainsi, à partir de la distance focale de la lentille de la caméra, on peut déterminer quels sont les objets situés dans le champ de la caméra qui sont flous (par exemple situés trop près de la caméra), et quels sont ceux sur lesquels est effectuée la mise au point, et qui seront donc nets. En effet, un flux vidéo offrant une représentation floue du coureur n°17 n'offrirait pas un contenu suffisamment pertinent à l'utilisateur, et doit donc être écarté lors de la sélection par le serveur. A l'issue de la quatrième étape 1D4, le serveur a donc identifié un ou plusieurs flux vidéo sur lesquels figure le coureur n°17, et ce, de façon nette. On notera que les étapes référencées 1D2, 1D3 et 1D4 sont des étapes optionnelles, offrant des optimisations de la sélection de flux vidéo, et pourraient ne pas être (toutes) mises en oeuvre, dans un mode de fonctionnement sous-optimal du procédé de l'invention. On notera que d'autres étapes de raffinement de la sélection pourraient également être mises en oeuvre, afin, par exemple : - de tenir compte de la distance maximale au delà de laquelle un objet ne peut plus être reconnu par un observateur, afin d'écarter les flux vidéos sur lesquels la cible apparaîtrait trop éloignée pour être reconnaissable ; - de tenir compte de la qualité de l'image du flux vidéo (en privilégiant par exemple les vidéos présentant la meilleure résolution, ou les meilleurs conditions de luminosité ou de contraste (éviter les contre-jours, les vidéos trop sombres... )) ; - de tenir compte d'éventuels obstacles naturels (prise en compte du relief du terrain) ou artificiels (présence d'immeubles) susceptibles de se dresser dans le champ de vision de la caméra entre la cible et la caméra - de tenir compte de la taille de la cible pour pouvoir sélectionner les vidéos présentant une partie significative de la cible ; - de tenir compte d'une préférence utilisateur de représentation de la cible (par exemple, plan large ou rapproché), ce qui permet de moduler la notion de seuil lors de l'étape ID1. A l'issue de ces différentes étapes d'identification du ou des flux vidéo pertinents par rapport à la requête de visualisation de l'utilisateur, regroupées dans une phase référencée 10 sur la figure 1, le serveur détermine donc au cours d'une étape référencée SEL s'il existe au moins un flux vidéo en temps réel répondant au besoin de l'utilisateur, i.e. offrant un point de vue pertinent sur le coureur n°17. Dans la négative, le serveur envoie au terminal de l'utilisateur un message d'erreur ERR, lui indiquant qu'il n'existe aucune vidéo disponible pour le coureur n°17. L'utilisateur peut être conjointement invité à sélectionner une autre cible parmi la liste de cibles potentielles. S'il maintient son choix de suivre l'évolution du coureur n°17, le serveur peut réitérer l'opération de sélection 10 à l'issue d'une temporisation prédéterminée, afin de vérifier si l'évolution de la position du coureur n°17 et des métadonnées contextuelles des différentes caméras permet désormais de répondre favorablement à la demande de l'utilisateur. Dans l'affirmative, le ou les flux vidéo offrant le meilleur point de vue sur le coureur n°17 sont envoyés au terminal de l'utilisateur. Cet envoi peut être effectué directement par le serveur ayant opéré la sélection 10, dans l'hypothèse où ce dernier a reçu les flux vidéo des différents dispositifs d'acquisition vidéo, conjointement avec les métadonnées contextuelles MC associées. Il peut également être effectué par un serveur vidéo dédié à la réception des flux vidéo en provenance des différentes caméras, et à leur retransmission vers les terminaux d'utilisateur. Dans ce cas, cet envoi est déclenché par l'émission d'un ordre de transfert, depuis le serveur ayant opéré la sélection 10 vers ce serveur vidéo : un tel ordre de transfert contient un identifiant du ou des flux vidéo sélectionnés et à adresser à l'utilisateur. On présente désormais, en relation avec les figures 2A à 2C, un exemple de réalisation de l'invention, dans le cadre précité de l'épreuve du marathon olympique. Par souci de simplification, on considère le cas où seuls deux vidéastes référencés A et B filment cette course. Ces deux vidéastes A et B sont placés en des points différents du parcours. Ils sont équipés chacun d'un dispositif d'acquisition vidéo présentant des moyens de géolocalisation et des moyens de communication, de sorte que chacun de ces dispositifs d'acquisition transmet à un serveur 20 les métadonnées contextuelles MCA, MCB associées au flux vidéo en cours d'acquisition. Les métadonnées contextuelles MCA, MCB peuvent être transmises seules au serveur 20, ou en association avec le flux vidéo en cours d'acquisition. Dans le cas où les métadonnées contextuelles sont transmises seules, le flux vidéo peut être envoyé, à la demande, au serveur 20 ou à un serveur vidéo dédié, sur requête du serveur 20, lorsque ce dernier détecte que le flux vidéo répond à un besoin exprimé par un utilisateur du service de l'invention. Dans l'exemple de la figure 2A, le coureur n°17 se trouve dans le champ de vision de la caméra du cinéaste A. Ce coureur n°17 est par ailleurs équipé de moyens de géolocalisation (par exemple selon le système GPS ou Galileo), et de moyens de communication, de sorte qu'il transmet au serveur 20 ses données de géolocalisation GL : cette transmission peut se faire à intervalles de temps prédéterminés (par exemple toutes les secondes), ou sur détection d'un changement de position du coureur n°17 (lorsque ce dernier est à l'arrêt, avant le début de la course, il n'est pas forcément nécessaire de rafraîchir sa position auprès du serveur 20). Comme illustré par la figure 2B, un utilisateur 21, qui souhaite suivre à distance cette épreuve de marathon, envoie au serveur 20 une requête de visualisation Req précisant quelle est la cible qui l'intéresse, au cours d'une étape référencée 22. Comme décrit précédemment, cette cible peut être choisie au sein d'une liste de cibles potentielles proposée à l'utilisateur 21 dans le cadre du service web de l'invention. L'envoi de cette requête se fait au moyen d'un terminal dont dispose l'utilisateur 21, qui peut être de toute nature (terminal mobile, tablette, PDA (pour « Personal Digital Assistant », assistant numérique personnel), ordinateur, décodeur TV,...). Sur réception de la requête de visualisation Req, le serveur 20 met en oeuvre les étapes de sélection 10 décrites précédemment en relation avec la figure 1.

Par exemple, lors d'une étape ID1, il détermine, à partir des données de géolocalisation GL du coureur n°17 et des métadonnées contextuelles MCA et MCB des caméras A et B, que les deux vidéastes sont tous deux suffisamment proches du coureur n°17 (les distances séparant les caméras A et B du coureur n°17 sont toutes deux inférieures au seuil prédéterminé pour cet événement), mais lors d'une étape 1D2, il détermine que la caméra B n'est pas orientée vers le coureur n°17, de sorte que le flux vidéo acquis par le vidéaste B ne répond pas au besoin de l'utilisateur 21. L'orientation de la caméra A quant à elle est telle que le coureur n°17 se trouve bien dans le champ de vision de la caméra.

Le serveur 20 transmet alors, au cours d'une étape référencée 23, la Vidéo A à l'utilisateur 21. Dans une variante de réalisation, le serveur 20 envoie une requête de flux vidéo à la caméra A et, sur réception du flux, le fait suivre à l'utilisateur 21.

La figure 2C présente la même scène que celle de la figure 2B, mais à un instant ultérieur. Le coureur n°17 a poursuivi sa course, de sorte qu'il est sorti du champ de vision de la caméra A pour entrer dans celui de la caméra B. Le serveur 20 détecte ce changement, lors d'un rafraîchissement de la sélection 10 du ou des flux vidéo répondant à la requête Req de l'utilisateur 21. En effet, après avoir répondu à la requête Req de l'utilisateur 21 en lui envoyant la Vidéo A (étape référencée 23), le serveur 20 vérifie que la vidéo A répond toujours au besoin de l'utilisateur : - soit à intervalles de temps régulier ; - soit sur détection d'un changement important dans la position de la cible (par exemple, supérieur à un seuil prédéterminé) à partir des données de géolocalisation GL, soit sur détection d'une modification substantielle des métadonnées contextuelles MCA et MCB des caméras A et B.

Dans un cas comme dans l'autre, le serveur 20 réitère les étapes 1D1 à 1D4 de l'opération de sélection 10 pour identifier un éventuel nouveau flux vidéo répondant mieux au besoin de l'utilisateur 21. En l'occurrence, le serveur 20 détermine que le coureur n°17 n'est plus dans le champ de la caméra A, mais qu'il apparaît en revanche sur le flux vidéo capté par la caméra B. Au cours d'une étape référencée 24, il envoie donc à l'utilisateur 21 le flux Vidéo B, qui offre, à cet instant, le point de vue le plus pertinent sur le coureur n°17 que l'utilisateur a choisi comme point d'intérêt. Bien que cela ne soit pas illustré sur les figures 2A à 2C, on notera que si, à un instant donné, le coureur n°17 apparaît simultanément sur les flux vidéo acquis par les caméras A et B, le serveur 20 peut transmettre ces deux vidéos A et B à l'utilisateur 21, comme répondant toutes deux à son besoin. A titre de variante, il peut opérer une sélection en se fondant sur un autre critère, tel que la qualité du flux vidéo, ou la pérennité de la sélection (par exemple, le serveur 20 détecte que le coureur n°17 vient d'entrer dans le champ de la caméra B et que, compte tenu d'une estimation de son déplacement, on peut supposer qu'il va rester plus longtemps dans le champ de la caméra B que de la caméra A). Bien que cela ne soit pas illustré sur les figures 2A à 2C, l'utilisateur 21 peut également indiquer dans sa requête de visualisation Req, qu'il est intéressé par deux points d'intérêt distincts, à savoir le coureur n°17 et le coureur n°23 par exemple. Dans ce cas, le serveur 20 recherche en priorité un flux vidéo sur lequel ces deux coureurs apparaissent simultanément. Si un tel flux vidéo n'existe pas, le serveur 20 sélectionne indépendamment les flux vidéo sur lesquels apparaissent chacune des deux cibles, pour les proposer à l'utilisateur 21.

Le procédé de traitement de flux vidéo de l'invention permet donc d'offrir aux utilisateurs un enrichissement du direct télévisé : en effet, il permet d'offrir à chaque téléspectateur une expérience personnalisée, en fonction de son ou ses point(s) d'intérêt, et représente donc une opportunité pour les diffuseurs d'événements tels que les chaînes TV.

Il présente également une application avantageuse dans le domaine du suivi de cibles par vidéo-surveillance, par exemple dans le domaine militaire ou pénitentiaire. Ainsi, dans le cadre d'un transfert de prisonnier sur un parcours équipé de caméras de vidéo-surveillance, le procédé de l'invention permet d'offrir en permanence à la personne en charge du suivi du transfert la vidéo offrant le meilleur point de vue sur le prisonnier transféré. Il n'est donc plus nécessaire d'observer simultanément plusieurs écrans offrant chacune la vue d'une caméra de vidéo-surveillance, pour surveiller le parcours du prisonnier. Grâce à l'invention, il suffit de surveiller un écran unique, sur lequel le serveur 20 envoie toujours la vidéo la plus pertinente, à savoir celle sur laquelle on voit le mieux le prisonnier. Cela nécessite bien sûr que ce prisonnier, ou le véhicule dans lequel s'opère le transfert, soit équipé de moyens de géolocalisation aptes à communiquer leur position au serveur 20. On présente finalement, en relation avec la figure 3, la structure simplifiée d'un dispositif de traitement de flux vidéo mettant en oeuvre un procédé de traitement de flux vidéo tel que décrit précédemment. Une plateforme de service telle qu'illustrée en figure 3 comprend une mémoire 31 comprenant une mémoire tampon, une unité de traitement 32, équipée par exemple d'un microprocesseur pP, et pilotée par le programme d'ordinateur 33, mettant en oeuvre le procédé de codage selon l'invention.

A l'initialisation, les instructions de code du programme d'ordinateur 33 sont par exemple chargées dans une mémoire RAM avant d'être exécutées par le processeur de l'unité de traitement 32. L'unité de traitement 32 reçoit des données de géolocalisation GL associées à une pluralité de cibles potentielles et des métadonnées contextuelles MC associées à un ensemble de flux vidéo en temps réel. Elle reçoit également une requête de visualisation Req en provenance d'un utilisateur, indiquant la ou les cible(s) que l'utilisateur souhaite suivre. Le microprocesseur de l'unité de traitement 32 met en oeuvre les étapes du procédé décrit précédemment, selon les instructions du programme d'ordinateur 33, pour sélectionner le flux vidéo offrant le contenu le plus pertinent par rapport à la cible choisie par l'utilisateur. Il délivre une réponse REP adressée à l'utilisateur, qui peut consister en un message d'erreur si aucun flux vidéo pertinent n'est disponible, ou en une séquence vidéo qu'il a sélectionnée. Pour cela, le dispositif de traitement de flux vidéo comprend, outre la mémoire tampon 31, des moyens de réception d'au moins une métadonnée contextuelle MC associée à au moins un flux vidéo en temps réel, des moyens de réception, pour une liste d'au moins une cible potentielle, de données de géolocalisation GL associées à ladite au moins une cible potentielle, et des moyens de sélection d'au moins un flux vidéo contenant ladite au moins une cible choisie tenant compte d'un critère de proximité desdites données de géolocalisation de ladite au moins une cible choisie et de ladite au moins une métadonnée contextuelle associée audit au moins un flux vidéo sélectionné. Ces moyens sont pilotés par le microprocesseur de l'unité de traitement 32.

Claims (13)

1. REVENDICATIONS1. Procédé de traitement de flux vidéo, mettant en oeuvre, sur réception d'une requête de visualisation (Req) d'au moins une cible (17) choisie par un utilisateur (21), une sélection (10) d'au moins un flux vidéo contenant ladite au moins une cible choisie, caractérisé en ce qu'il comprend des étapes de : - réception d'au moins une métadonnée contextuelle (MC ; MCA, MCB) associée à au moins un flux vidéo en temps réel ; - pour une liste d'au moins une cible potentielle, réception de données de géolocalisation (GL) associées à ladite au moins une cible potentielle, ladite au moins une cible choisie par ledit utilisateur étant choisie au sein de ladite liste d'au moins une cible potentielle, et en ce que ladite sélection (10) d'au moins un flux vidéo contenant ladite au moins une cible choisie tient compte d'un critère de proximité desdites données de géolocalisation de ladite au moins une cible choisie et de ladite au moins une métadonnée contextuelle associée audit au moins un flux vidéo sélectionné.
2. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend également une étape de transmission (23, 24) dudit au moins un flux vidéo sélectionné à un dispositif émetteur de ladite requête de visualisation.
3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite étape de réception de données de géolocalisation associées à ladite au moins une cible potentielle est itérée périodiquement et/ou en fonction d'un déplacement de ladite au moins une cible potentielle.
4. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite étape de réception d'au moins une métadonnée contextuelle associée à au moins un flux vidéo en temps réel est itérée périodiquement et/ou en fonction d'un déplacement d'un dispositif d'acquisition dudit flux vidéo associé.
5. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite étape de sélection (10) est mise en oeuvre périodiquement et/ou en cas de modification desdites données de géolocalisation de ladite au moins une cible choisie ou de ladite au moins une métadonnée contextuelle associée audit au moins un flux vidéo sélectionné.
6. 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite au moins une métadonnée contextuelle (MC ; MCA, MCB) appartient au groupe comprenant : - une position d'un dispositif d'acquisition dudit flux vidéo associé ; - une orientation dudit dispositif d'acquisition ; - un angle de vision dudit dispositif d'acquisition ; - un paramètre de mise au point dudit dispositif d'acquisition.
7. 7. Procédé selon la revendication 6, caractérisé en ce que ladite étape de sélection (10) comprend une première sous-étape d'identification (ID1) dudit ou desdits au moins un flux vidéo pour le(s)quel(s) une distance entre ladite position dudit dispositif d'acquisition dudit flux vidéo et une position de ladite au moins une cible choisie est inférieure à un seuil prédéterminé, ladite première sous-étape d'identification délivrant un premier sous-ensemble d'au moins un flux vidéo.
8. 8. Procédé selon la revendication 7, caractérisé en ce que ladite étape de sélection comprend également une deuxième sous-étape d'identification (ID2), au sein dudit premier sous-ensemble d'au moins un flux vidéo, dudit ou desdits au moins un flux vidéo pour le(s)quel(s) ledit dispositif d'acquisition dudit flux vidéo est orienté vers ladite au moins une cible choisie, ladite deuxième sous-étape d'identification délivrant un deuxième sous-ensemble d'au moins un flux vidéo.
9. 9. Procédé selon la revendication 8, caractérisé en ce que ladite étape de sélection comprend également une troisième sous-étape d'identification (ID3), au sein dudit deuxième sous-ensemble d'au moins un flux vidéo, dudit ou desdits au moins un flux vidéo pour le(s)quel(s) ledit angle de vision dudit dispositif d'acquisition dudit flux vidéo couvre ladite au moins une cible choisie, ladite troisième sous-étape d'identification délivrant un troisième sous-ensemble d'au moins un flux vidéo.
10. 10. Procédé selon la revendication 9, caractérisé en ce que ladite étape de sélection comprend également une quatrième sous-étape d'identification (ID4), au sein dudit troisième sous-ensemble d'au moins un flux vidéo, dudit ou desdits au moins un flux vidéo dans le(s)quel(s) une représentation de ladite au moins une cible choisie satisfait au moins un critère de qualité prédéterminé.
11. 11. Procédé selon la revendication 1, caractérisé en ce qu'il comprend également une étape de transmission d'un message d'erreur (ERR) à un dispositif émetteur de ladite requête de visualisation si aucun desdits flux vidéo ne satisfait ledit critère de proximité.
12. 12. Dispositif de traitement de flux vidéo, comprenant des moyens aptes à sélectionner au moins un flux vidéo (REP) contenant au moins une cible choisie par un utilisateur, sur réception d'une requête de visualisation (Req) de ladite au moins une cible choisie, caractérisé en ce qu'il comprend : - des moyens de réception d'au moins une métadonnée contextuelle (MC) associée à au moins un flux vidéo en temps réel ; - des moyens de réception, pour une liste d'au moins une cible potentielle, de données de géolocalisation (GL) associées à ladite au moins une cible potentielle, ladite au moins une cible choisie par ledit utilisateur étant choisie au sein de ladite liste d'au moins une cible potentielle, et en ce que lesdits moyens aptes à sélectionner au moins un flux vidéo (REP) contenant ladite au moins une cible choisie tiennent compte d'un critère de proximité desdites données de géolocalisation de ladite au moins une cible choisie et de ladite au moins une métadonnée contextuelle associée audit au moins un flux vidéo sélectionné.
13. 13. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon la revendication 1 lorsque ce programme est exécuté par un processeur.