FR 3067897 A1 20181221 FR 1755328 A 20170614 PROCEDE D'EVALUATION DE L'EXPERIENCE UTILISATEUR LORS DE LA LECTURE D'UN CONTENU VIDEO SUR UN TERMINAL MOBILE DOMAINE TECHNIQUE GENERAL La présente invention concerne le streaming de contenus vidéo, et en particulier un procédé d'évaluation de l'expérience utilisateur lors de la lecture sur un terminal mobile connecté à un réseau étendu d'un contenu vidéo diffusé depuis ledit réseau. ETAT DE L'ART On appelle « Over-the-top » (OTT, en français « service par contournement ») un service de fourniture de contenus multimédia sur Internet (tel que Youtube pour la vidéo) sans la participation d'un opérateur (fournisseur d'accès Internet) dans le contrôle ou la distribution. L'opérateur distribuant le contenu chez l'utilisateur peut être au courant du contenu des paquets IP circulant sur son réseau, mais n'est pas responsable, ni en mesure de contrôler la restitution de ces contenus. A ce titre un incident au niveau d'une plateforme OTT peut impacter la Qualité de Service/d'Expérience (QoS/QoE) chez l'utilisateur (par exemple pour une vidéo : saccades, lenteur de chargement, baisse de résolution, etc.) sans que l'opérateur y soit pour quelque chose, alors que c'est ce dernier qui va être le plus facilement blâmé par l'utilisateur. De surcroit, les fournisseurs de services OTT représentent une proportion conséquente du trafic internet mondial et utilisent leurs propres interfaces et algorithmes de gestion de la bande passante, ce qui a des répercussions globales et que les opérateurs ne peuvent que subir. Fort de ce contexte, il y a une demande forte pour une solution permettant de monitorer industriellement l'expérience utilisateur pour les services OTT, notamment vidéo du fait de la forte bande passante consommée et de la faible robustesse (QoE très facilement dégradée), et tout particulièrement sur terminal mobile. Ainsi, en ce qui concerne Youtube par exemple, Google (propriétaire de Youtube) a mis à disposition dans le SDK d'Android une API Youtube permettant d'analyser le trafic vidéo en temps réel sur terminal mobile. Cette API permet de lancer une vidéo Youtube depuis une application dédiée, et de récupérer diverses informations exclusivement délivrées par cette API. Les résolutions auditées peuvent soit être figée (ex : forcer la 2 résolution en 720p) ou libres (l'API sélectionne automatiquement les paramétrages vidéo en fonction des conditions du test). Cette solution est facile à mettre en oeuvre, fournit des métriques fiables et préétablies appelées indicateurs clé de performance (KPI, de anglais « key performance 5 indicator »), mais elle ne permet pas de monitorer l'application réelle fournie au grand public et de prendre en compte ses évolutions. Plus précisément, on voit le problème à évaluer la qualité d'un service sur la base d'indicateurs de performance fournis par le service lui-même. Dans le but d'être plus objectif, il a été proposé de monitorer le trafic vidéo 10 directement depuis des traces applicatives. L'idée est de « capturer » le trafic vidéo sur un terminal mobile pendant un visionnage d'une vidéo Youtube, puis l'analyser ensuite a posteriori grâce à des outils de post-traitements. Cependant, Youtube a introduit le protocole https (trafic encrypté) sur ses vidéos depuis 2013, ce qui empêche l'interception du trafic vidéo pour les versions plus récentes 15 de l'application ou dans le cas d'une lecture sur navigateur et ne permet donc pas une représentativité à jour de l'expérience utilisateur. On constate donc qu'aujourd'hui il n'existe pas d'autre solution que l'utilisation de l'API officielle pour monitorer Youtube. Il serait par conséquent souhaitable de disposer d'une nouvelle solution permettant de monitorer en temps réel le trafic vidéo sur n'importe 20 quelle version de l'application Youtube (ou toute autre application d'un service OTT vidéo) de sorte à réaliser une mesure exhaustive et fiable de la véritable expérience utilisateur, et ce sans matériel spécifique ou onéreux. PRESENTATION DE L'INVENTION 25 Selon un premier aspect, la présente invention se rapporte donc à un procédé d'évaluation de l'expérience utilisateur lors de la lecture, sur un terminal mobile connecté à un réseau étendu, d'un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau, le procédé étant caractérisé en ce qu'il comprend la mise en oeuvre d'étapes 30 de : (a) Restitution en continu dudit contenu vidéo par des moyens de traitement de données du terminal mobile, et affichage par des moyens d'affichage du terminal dans une interface dudit fournisseur de services ; (b) Extraction par les moyens de traitement de données d'une pluralité 35 d'images dudit contenu tel qu'affiché par les moyens d'affichage du terminal ; 3 (c) Analyse de ladite pluralité d'images extraites de sorte à déterminer au moins un paramètre représentatif de la qualité d'expérience utilisateur. Selon d'autres caractéristiques avantageuses et non limitatives : 5 - chacune de la pluralité d'images est extraite à l'étape (b) par capture d'écran ; - le terminal est connecté à un boitier de test comprenant des moyens de traitement de données, les étapes (a) et (b) étant mises en oeuvre sous le contrôle des moyens de traitement de données du boitier de test, l'étape (b) comprenant en outre l'envoi desdites images extraites aux moyens de traitement de données du boitier de test pour mise en 10 oeuvre de l'étape (c) ; - l'interface dudit fournisseur de services comprend une barre de lecture affichée pardessus le contenu, l'étape (c) comprenant l'identification de ladite barre de lecture dans lesdites images extraites ; - ladite barre de lecture représente l'état d'avancement de la lecture et l'état de 15 remplissage d'un buffer ; - l'étape (c) comprend la détermination dans chaque image à partir de la barre de lecture de : - une coordonnée d'état d'avancement de la lecture, - une coordonnée d'état de remplissage du buffer ; 20 - un paramètre représentatif de la qualité d'expérience utilisateur déterminé à l'étape (c) est un pourcentage de lecture du contenu et/ou un pourcentage de bufferisation du contenu ; - ladite pluralité d'images dudit contenu est extraite à une fréquence prédéterminée lors de l'étape (b) ; 25 - au moins un paramètre représentatif de la qualité d'expérience utilisateur déterminé à l'étape (c) est un paramètre de format du contenu, en particulier une résolution ou un nombre d'images par seconde ; - l'étape (c) comprend pour un ensemble de coordonnées prédéterminées de l'image la comparaison de la couleur du pixel correspondant de l'image avec une couleur attendue 30 de sorte à déterminer un sous-ensemble dudit ensemble formé des cordonnées telles que la couleur du pixel correspondant coïncide avec la couleur attendue ; - différents n-uplets de valeurs possibles du ou des paramètres de format de l'image sont chacun associé avec un sous-ensemble donné dudit ensemble de coordonnées prédéterminé, l'étape (c) comprend l'identification des valeurs du ou des paramètres de 35 format d'image associées avec le sous-ensemble déterminé. 4 Selon un deuxième aspect, l'invention concerne un boitier de test pour l'évaluation de l'expérience utilisateur lors de la lecture, sur un terminal mobile connecté au boitier et à un réseau étendu, d'un contenu vidéo diffusé par un fournisseur de contenus depuis 5 ledit réseau, le boitier de test étant caractérisé en ce qu'il comprend des moyens de traitement de données configurés pour : - Commander à des moyens de traitement de données du terminal mobile la restitution en continu dudit contenu vidéo et l'affichage par des moyens d'affichage du terminal dans une interface dudit fournisseur de services ; 10 - Commander auxdits moyens de traitement de données du terminal l'extraction d'une pluralité d'images dudit contenu tel qu'affiché par les moyens d'affichage du terminal ; - Analyser ladite pluralité d'images extraites de sorte à déterminer au moins un paramètre représentatif de la qualité d'expérience utilisateur. 15 Selon un troisième aspect, l'invention concerne un terminal mobile connecté à un réseau étendu, caractérisé en ce qu'il comprend des moyens d'affichage et des moyens de traitement de données configurés pour : - Restituer en continu un contenu vidéo diffusé par un fournisseur de contenus 20 depuis ledit réseau, et l'afficher sur les moyens d'affichage dans une interface dudit fournisseur de services ; - extraire une pluralité d'images dudit contenu tel qu'affiché par les moyens d'affichage ; - Analyser ladite pluralité d'images extraites de sorte à déterminer au moins un 25 paramètre représentatif de la qualité d'expérience utilisateur. Selon un quatrième et un cinquième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention d'évaluation de l'expérience utilisateur lors 30 de la lecture sur un terminal mobile connecté à un réseau étendu d'un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau ; et des moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon le premier aspect de l'invention d'évaluation de l'expérience utilisateur lors de la lecture sur un terminal 35 mobile connecté à un réseau étendu d'un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau. 5 PRESENTATION DES FIGURES D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d'un mode de réalisation préférentiel. Cette 5 description sera donnée en référence aux dessins annexés dans lesquels : - la figure 1 représente une architecture dans laquelle est mis en oeuvre le procédé selon l'invention ; - la figure 2 représente un exemple d'affichage du contenu représentant une interface comprenant une barre de lecture ; 10 - les figures 3a et 3b représentent deux exemples d'affichage d'un contenu avec des paramètres de format de contenu différents. DESCRIPTION DETAILLEE 15 Evaluation de l'expérience utilisateur Le présent procédé est un procédé d'évaluation de l'expérience utilisateur lors de la lecture d'un contenu vidéo. Comme l'on verra, le contenu vidéo monitoré peut être un contenu au hasard, ou un contenu de référence (adapté au test) prédéfini. 20 Par évaluation de l'expérience utilisateur, on entend détermination d'au moins un paramètre représentatif de la qualité d'expérience (QoE) utilisateur, c'est-à-dire au moins une métrique représentative du ressenti utilisateur, généralement appelée KPI. Les principaux KPIs explorés pour un service de fourniture de contenus vidéo sont les suivants : 25 - Délai d'affichage de la première image ; - Etat du buffer ; - Historisation des rebufferisations ; - Résolution et codec affichés à l'écran. 30 On verra dans la suite de la description l'exemple de ces KPls, mais l'homme du métier saura utiliser tout autre paramètre représentatif de la QoE de son choix. Architecture 35 En référence à la figure 1, le présent procédé est mis en oeuvre tout ou partiellement sur un terminal mobile 1 connecté à un réseau étendu 20 tel qu'internet. Il 6 peut y être connecté en particulier sans fil, par exemple via une connexion à un réseau VVi-Fi ou à un réseau de téléphonie mobile en particulier de type UMTS ou LTE. Le terminal mobile 1 comprend des moyens de traitement de données 11 (par exemple un processeur et/ou un coprocesseur graphique), des moyens d'affichage 13 5 (généralement un écran en particulier tactile, mais on peut imaginer un pico-projecteur) et le plus souvent des moyens de stockage de données 12 (une mémoire), comprenant préférentiellement une mémoire vive, pour le stockage temporaire des données traitées (mémoire RAM, « Random-Access Memory ») et une mémoire de masse pour le stockage à plus long terme (par exemple de type flash). La mémoire vive est souvent 10 utilisée comme mémoire tampon, ou « buffer », pour le pré-chargement des données du contenu. Le terminal 1 est typiquement un smartphone ou une tablette tactile. Le terminal mobile 1 peut être ou non « rooté », c'est-à-dire configuré de sorte à donner des privilèges étendus à l'utilisateur, lui permettant de modifier de façon avancée le système d'exploitation du terminal et de réaliser des actions impossibles avec le même 15 terminal non-routé. Selon un premier mode de réalisation, le terminal 1 est rooté, ce qui lui permet de mettre en oeuvre tout le présent de procédé. Selon un deuxième mode de réalisation, le terminal 1 n'est pas rooté, ce qui ne lui permet pas de réaliser toutes les étapes du présent procédé comme l'on verra. Dans un 20 tel cas, le terminal 1 est préférentiellement connecté à un boitier de test 10 tel que visible sur la figure 1, et comportant ses propres moyens de traitement de données. Le boitier 10 est préférentiellement un mini-PC connecté filairement au terminal 1, adapté pour contrôler les moyens de traitement de données 11 du terminal 1 et échanger des données avec lui. 25 Le contenu vidéo dont la lecture est monitorée est diffusé par un fournisseur de contenus (tel que Youtube) depuis ledit réseau 20. Cela signifie qu'il est hébergé par un serveur 2 du réseau 20, le servant sous forme de flux, c'est-à-dire une séquence de segments. 30 Lecture du contenu Le procédé commence par une étape (a) de lecture effective du contenu par le terminal 1. Plus précisément, l'étape (a) comprend la restitution en continu dudit contenu vidéo par des moyens de traitement de données 11 du terminal mobile 1, et l'affichage 35 par des moyens d'affichage 13 du terminal 1 dans une interface dudit fournisseur de services. 7 Ici il s'agit bien d'une lecture « en continu », c'est-à-dire que le contenu est reçu et restitué à la volée. Il s'agit de « streaming », et non de téléchargement (qui implique la récupération complète du contenu avant sa lecture). On comprendra aisément qu'il n'y a en effet pas d'intérêt à monitorer la lecture d'un contenu téléchargé puisqu'au moment de 5 la lecture il est intégralement disponible de façon locale (dans la mémoire 12) et donc que la QoE ne peut pas être dégradée. Par restitution, on entend le traitement des données reçues depuis le réseau 20 de sorte à générer un signal vidéo interprétable par les moyens d'affichage 13. Plus précisément, le contenu est comme expliqué généralement reçu sous forme de flux de 10 segments, i.e. des blocs des données du contenu, généralement correspondant à quelques secondes de lecture, souvent chiffrés et/ou compressés. Ce flux doit donc être décodé pour reconstituer les données réelles du contenu, et les lire. Dans le présent cas d'espèce, comme expliqué le contenu est mis à disposition sur le serveur 2 du fournisseur (conformément à un protocole de streaming donné, par 15 exemple http, ou https pour Youtube). Le terminal 1 souhaitant accéder au contenu envoie une requête pour en récupérer une petite partie, à l'endroit du contenu où il souhaite commencer la lecture (typiquement le début). Les segments reçus en réponse sont placés en mémoire tampon (c'est ce que l'on appelle la « bufferisation », la « rebufferisation » étant une nouvelle bufferisation mise en oeuvre si la lecture s'arrête 20 faute de segments d'avance). Lorsqu'il y a suffisamment de données dans le buffer pour permettre de commencer la lecture, celle-ci démarre. En arrière-plan, le téléchargement du flux se poursuit afin d'alimenter sans cesse la mémoire tampon avec la suite du contenu. Le signal vidéo généré par la restitution est transmis aux moyens d'affichage 13 de 25 sorte à afficher le contenu. En d'autres termes, la vidéo se lit effectivement et apparait à l'écran (si les moyens 13 consistent en un écran). L'affichage est dans une interface dudit fournisseur de services. Cela signifie que le contenu n'est pas affiché « tel quel » mais intégré dans l'interface, laquelle est rendue nécessaire du fait que sur la plupart des terminaux mobiles récents (smartphones et 30 tablettes), l'écran sert d'organe de contrôle principale (hormis un ou deux boutons, pas de clavier/souris distincts). Plus précisément, l'interface peut être constituée d'éléments d'interface comme des boutons de contrôle, des informations sur le contenu, des menus, etc., et en particulier une barre de lecture qui sera décrite en plus en détail). La disposition de cette interface est décidée par le fournisseur du contenu. 35 Dans un premier mode de réalisation, le contenu est affiché plein écran et des éléments de l'interface sont incrustées dans l'image lorsqu'elle affichée (les éléments sont 8 superposés et « recouvrent » une partie de la zone d'affichage et donc du contenu). Un exemple d'un tel affichage d'un contenu dans l'interface est représenté par la figure 2. Dans un deuxième mode de réalisation, le contenu est affiché dans une fenêtre, c'est-à-dire qu'une zone (généralement noire) entoure le contenu, et les éléments 5 d'interface sont disposés dans cette zone noire. Aucune partie du contenu n'est alors masquée mais la zone d'affichage a une taille réduite. A noter que l'interface est généralement « masquable » quelques secondes après le début de la lecture si l'utilisateur souhaite un affichage plein écran du contenu (elle réapparait dès que l'on touche l'écran/appuie sur une touche). Dans la mise en oeuvre du 10 présent procédé, on peut soit désactiver ce masquage automatique de sorte que l'interface reste tout le temps visible, soit dans le cas d'utilisation d'un boitier de test 10 ou d'un terminal 1 rooté peut être généré en permanence un signal représentatif d'un « appui » sur l'écran (comme si un utilisateur touchait l'écran en permanence) ou toute autre stimulation, ce qui empêche le masquage d'avoir lieu (et l'interface reste à l'écran). 15 Cette étape (a) est préférentiellement mise en oeuvre dans une application du terminal 1, en particulier une application dédiée mise à disposition par le fournisseur du contenu (par exemple l'application Youtube), qui s'occuper donc de l'incrustation de l'interface et sa gestion associée (notamment mise en oeuvre des actions associés aux boutons de contrôle de l'interface). Alternativement, l'étape (a) peut être mise en oeuvre 20 dans un navigateur web (par exemple sur le site internet du fournisseur du contenu). Dans une étape (b) est extraite par les moyens de traitement de données 11 une pluralité d'images dudit contenu tel qu'affiché par les moyens d'affichage 13 du terminal 1. L'étape (b) est en pratique concomitante avec l'étape (a) puisque ces images sont 25 préférentiellement extraites sur toute la durée de lecture et d'affichage du contenu, en temps réel. La fréquence de mise en oeuvre d'extraction d'image est appelée fréquence d'échantillonnage. Elle peut être fixe (par exemple toutes les 5 secondes), ou bien mobile (extraction d'une image à chaque téléchargement d'un burst de données du contenu par 30 le terminal 1). Une possibilité de mise en oeuvre est d'utiliser la fonction capture d'écran qui est généralement intégrée dans la plupart des systèmes d'exploitation des terminaux mobiles. Normalement, une capture d'écran est commandée par une action de l'utilisateur sur l'écran ou les touches du terminal 1 (par exemple appuyer sur deux boutons 35 simultanément ordonne aux moyens de traitement de données 11 d'effectuer la capture d'écran et de stocker l'image obtenue dans le dossier photos) ou via commande interne 9 au terminal (adb par exemple), c'est pourquoi il est nécessaire de rooter le terminal 1 ou d'utiliser un autre équipement tel que le boitier de test 10 pour générer les commandes adéquates pour le système d'exploitation et récupérer les images. L'homme du métier saura accomplir cela. 5 Dans le mode de réalisation préféré avec un boitier de test 10, les étapes (a) et (b) mise en oeuvre sous le contrôle des moyens de traitement de données du boitier de test 10 (en d'autres termes le boitier de test ordonne la lecture du contenu, ordonne la réalisation les captures d'écran, et télécharge les images obtenues). 10 Dans une étape (c) ladite pluralité d'images extraites est analysée de sorte à déterminer au moins un paramètre représentatif de la qualité d'expérience utilisateur (KPI), soit par les moyens de traitement de données 11 du terminal 1 s'il est rooté, soit par le boitier de test 10 s'il y a (l'étape (b) comprenant alors en outre l'envoi desdites images extraites aux moyens de traitement de données du boitier de test 10 pour mise en 15 oeuvre de l'étape (c)). L'idée est de mettre en oeuvre un ou plusieurs algorithmes de traitement d'images de sorte à extraire des informations de chacun des images extraites et d'en déduire lesdits KPIs. Ainsi, un monitoring véridique de la QoE peut être réalisé dans la mesure où les 20 données d'entrée de l'algorithme de détermination du KPIs sont constituées du contenu tel qu'affiché. Plus précisément, le présent procédé d'évaluation de l'expérience utilisateur « vit » la lecture du contenu exactement de la même façon que n'importe quel utilisateur. De plus, dans la mesure où l'on travaille sur les images de sortie et non les données du flux, il n'y a aucun besoin d'intercepter ou de manipuler des données avant affichage du 25 contenu. Le présent procédé est donc universel en ce qu'il peut être appliqué à n'importe quelle façon d'afficher du contenu (navigateur, application dédiée de n'importe quelle version, etc.) Plusieurs exemples d'algorithmes de traitement d'images permettant de déterminer divers KPIs vont être à présent décrits. 30 ler exemple : détermination de l'état de la lecture et de l'état du buffer Comme expliqué, l'interface dudit fournisseur de services comprend préférentiellement une barre de lecture affichée par-dessus le contenu. Ladite barre de 35 lecture représente typiquement l'état d'avancement de la lecture et l'état de remplissage d'un buffer. 10 Plus précisément, comme l'on voit sur la figure 2 déjà évoquée, la barre de lecture est composée de trois parties : une partie gauche en rouge, une partie centrale en blanc, et une partie à droite en gris (on notera que des couleurs alternatives peuvent bien évidement être choisies). 5 Durant toute la lecture, les parties rouge et blanche ne font que se déplacer vers la droite, jusqu'à ce que la partie rouge occupe toute la barre. La partie rouge représente la partie déjà lue du contenu et représente ainsi l'état d'avancement de la lecture. La partie blanche représente la partie non encore lue mais déjà bufferisée, elle représente ainsi l'état de remplissage du buffer (on considère que le buffer est rempli lorsque le contenu 10 est entièrement bufferisé, i.e. pré-chargé). La partie grise représente le reste du contenu encore ni lu ni bufferisé. L'étape (c) comprend l'identification de ladite barre de lecture dans lesdites images extraites (et des diverses parties). Il suffit pour cela de calibrer l'algorithme en fonction de l'interface à monitorer, et 15 d'exploiter les éléments suivants : - Ordonnée de la barre de lecture : Y lecteur - Coordonnées de début et fin du contenu : (X debut video, Y lecture) et (X fin_video, Y lecteur) - Coordonnées d'état d'avancement de la lecture : (X lecture, Y lecture) 20 - Coordonnées d'état du buffer : (X buffer, Y lecteur) et (X fin video, Y lecteur) Ces coordonnées s'identifient simplement par analyse d'image connaissant les couleurs. De plus Y lecture, X debut video et X fin video sont constants (définis par l'interface) et peuvent être prédéterminés. A partir de là, les abscisses X lecture et 25 X buffer peuvent être simplement retrouvés par intersection avec Y lecture comme l'on voit sur la figure 2. Plus précisément, chaque pixel parcouru le long de la ligne de lecture permet par analyse de la couleur du pixel d'identifier si la coordonnée courante fait partie de la partie déjà lue ou de la partie bufferisée. X lecture et X buffer sont ainsi déterminés dès lors que le pixel courant ne présente plus la caractéristique de chaque élément 30 (exemple des couleurs rouge et blanc). Les KPIs monitorés peuvent ainsi être calculés (dans chaque image) comme suit : - Pourcentage courant de lecture du contenu %_lecture : (X lecture - X debut video)/(X fin_video-X debut video) - Etat courant de la lecture : %_lecture*Durée vidéo 35 - Pourcentage courant de bufferisation (i.e. de disponibilité dans le buffer) du contenu %_buffer: (X buffer-X debut video)/(X fin_video-X debut video) 11 - Etat courant du buffer : %_buffer*Durée_vidéo On peut alors obtenir pour chacun de ces KPI une courbe au cours du temps représentant leur évolution, et obtenir de nombreuses informations (ou autres KPIs). Par exemple : 5 - Le temps de première image est le temps pour que le pourcentage courant de lecture dépasse zéro. - L'état d'avancement de la lecture devrait normalement être la fonction identité du temps à une constante près correspondant à la bufferisation initiale (en d'autres termes %_lecture(t)*Durée_vidéo=t+c, où c est le temps pour pré-bufferiser le 10 début du contenu, i.e. le temps de première image évoqué juste avant). Si ce n'est pas le cas, c'est que la lecture s'est arrêtée à un moment donné pour rebufferisation (on peut ainsi les identifier). - L'état de remplissage du buffer devrait être au moins aussi croissant que l'état de lecture : si la bufferisation est plus lente que la lecture (en d'autres termes que 15 l'avance diminue), un arrêt de lecture pour rebufferisation devrait normalement survenir imminem ment. - La vitesse de bufferisation est représentative du débit de réception des données par le terminal 1. 20 2e exemple : identification de paramètres de format de l'image Un ou plusieurs paramètres représentatifs de la qualité d'expérience utilisateur peuvent également être des paramètres de format de l'image tels que la résolution de l'image en cours de lecture (144p, 240p, 360p, 480p, 720p, 1080p, 1440p, etc.), le 25 nombre d'images par secondes (15 fps, 30 fps, 60 fps, etc.) ou encore le codec. En effet, de façon classique le format d'image est choisi automatiquement par l'application en fonction de la bande-passante disponible, i.e. le format de la meilleure qualité possible (sans saccades ou ralentissement) est automatiquement choisi. Par exemple, si le débit chute, la résolution va baisser pour dégrader le moins possible la QoE : il vaut mieux une 30 image de mauvaise qualité qu'une lecture non fluide. On notera que dans certaines interfaces la résolution, le nombre d'images par seconde et/ou le codec sont directement affichés à un ou plusieurs emplacements prédéterminés, qui peuvent être analysés de sorte à récupérer cette(ces) information(s). Alternativement, en référence aux figures 3a et 3b, la caractérisation de ces 35 paramètres peut être réalisée sur le principe des empreintes, dites « fingerprints » : chaque format de contenu vidéo ainsi lu et affiché peut être identifié grâce à un réseau 12 d'empreintes calibré au préalable, représentées par des coordonnées à examiner sur l'écran du terminal (en d'autres termes un ensemble de (couples de) coordonnées prédéterminées de l'image est défini). L'idée est d'intégrer à chaque version d'un contenu vidéo (correspondant aux 5 différents formats du contenu, i.e. combinaisons de résolutions/nombre d'images par seconde) des motifs prédéterminés, par exemple des textes différentiables (ABCD et ABCE dans les exemples des figures 3a et 3b). De la même manière que pour le calcul de l'état de la lecture ou du buffer, la correspondance d'empreintes (« fingerprints matching ») est réalisée pour chaque pixel 10 de chaque empreinte par la comparaison de la couleur du pixel attendue (noir dans le présent exemple) avec la couleur réellement présente (dans le présent exemple, noir si correspondance, ou gris foncé si non correspondance). En fonction des résultats on obtient un sous-ensemble de l'ensemble des empreintes, formé des empreintes pour lesquelles il y a correspondance (i.e. le sous-ensemble des cordonnées telles que la 15 couleur du pixel correspondant coïncide avec la couleur attendue) et de là une « signature ». Avec n empreintes, on a donc 2n sous-ensembles possibles et donc 2n signatures. Si par exemple, dans la figure 3a, il y a une correspondance sur les dix empreintes (le sous-ensemble est égal à l'ensemble), alors qu'il n'y a une correspondance que sur les 20 huit premières dans la figure 3b (le sous-ensemble ne contient que les huit premiers couples de coordonnées). Si on exprime une non-correspondance par un bit « 0 » et une correspondance par le bit « 1 », la signature de l'image de la figure 3a est 1111111111 alors que la signature de l'image de la figure 3b est 1111111100. On peut alors associer (par exemple dans une base de données de référence 25 stockée sur des moyens de stockage du terminal 1 ou du boitier de test 10) différents n- uplets de valeurs possibles du ou des paramètres de format de l'image, i.e. des combinaisons de valeurs des paramètres (par exemple une valeur de résolution avec une valeur de nombre d'images par secondes), chacune avec un sous-ensemble donné dudit ensemble de coordonnées prédéterminé, c'est-à-dire une signature, par exemple 30 720p/60fps pour la signature 1111111111 et 1080p/60fps pour la signature 1111111100. L'étape (c) comprend ainsi l'identification des valeurs du ou des paramètres de format d'image associées avec le sous-ensemble déterminé 35 13 Evaluation de l'expérience utilisateur en continu Le présent procédé d'évaluation de l'expérience utilisateur peut être mis en oeuvre de façon ponctuelle, mais de façon préférée et en particulier lorsque le procédé est mis en 5 oeuvre sous le contrôle d'un boitier de test 10, du monitoring plus complexe peut être réalisé. En particulier, le boitier 10 peut automatiser un protocole de test comprenant une pluralité d'occurrences du procédé. Par exemple il peut être mis en oeuvre de façon répété, avec un intervalle de 10 temps prédéterminé entre deux itérations, et le cas échéant un nombre maximal ou une durée maximale de test. Alternativement ou en complément, une playlist de contenus peut être disponible de sorte à évaluer de l'expérience utilisateur lors de la lecture de chacun de ces contenus. Les différents KPIs déterminés lors des occurrences successives du procédé 15 peuvent être historisées et mise dans un format particulier, par exemple un tableau où chaque ligne correspond à une occurrence du procédé. Les données de sortie ainsi compilées peuvent être par exemple envoyées une fois par jour sur un serveur pour consultation des résultats. 20 Equipement Selon un deuxième et un troisième aspect, l'invention concerne un boitier de test 10 connecté au terminal 1 ou directement un terminal mobile 1 (par exemple s'il est rooté) pour la mise en oeuvre du procédé selon le premier aspect. 25 Le terminal mobile 1 comprend des moyens d'affichage 13 et des moyens de traitement de données 11, et en particulier des moyens de stockage de données (comprenant en particulier un mémoire vive pour stocker un buffer). Le boitier de test 10 comprend comme expliqué des moyens de traitement de données configurés pour : 30 - Commander à des moyens de traitement de données 11 du terminal mobile 1 la restitution en continu dudit contenu vidéo et l'affichage par des moyens d'affichage 13 du terminal 1 dans une interface dudit fournisseur de services ; - Commander auxdits moyens de traitement de données 11 du terminal 1 l'extraction d'une pluralité d'images dudit contenu tel qu'affiché par les moyens 35 d'affichage 13 du terminal 1 (et commander le transfert desdites images du terminal 1 vers le boitier 10) ; 14 - Analyser ladite pluralité d'images extraites de sorte à déterminer au moins un paramètre représentatif de la qualité d'expérience utilisateur. Le terminal mobile 1, si c'est lui qui met en oeuvre le procédé, comprend des 5 moyens de traitement de données 11 configurés pour : - Restituer en continu un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau 20, et l'afficher sur les moyens d'affichage 13 dans une interface dudit fournisseur de services ; - extraire une pluralité d'images dudit contenu tel qu'affiché par les moyens 10 d'affichage 13; - Analyser ladite pluralité d'images extraites de sorte à déterminer au moins un paramètre représentatif de la qualité d'expérience utilisateur. Produit programme d'ordinateur 15 Selon un quatrième et un cinquième aspects, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (en particulier via les moyens de traitement du boitier 10 et/ou du terminal 1) du procédé d'évaluation de l'expérience utilisateur lors de la lecture sur un terminal mobile 1 connecté 20 à un réseau étendu 20 d'un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau 20, ainsi que des moyens de stockage lisibles par un équipement informatique (notamment des moyens de stockage de données du boitier 10 et/ou du terminal 1) sur lequel on trouve ce produit programme d'ordinateur. REVENDICATIONS1. Procédé d'évaluation de l'expérience utilisateur lors de la lecture, sur un terminal mobile (1) connecté à un réseau étendu (20), d'un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau (20), le procédé étant caractérisé en ce qu'il comprend la mise en oeuvre d'étapes de : (a) Restitution en continu dudit contenu vidéo par des moyens de traitement de données (11) du terminal mobile (1), et affichage par des moyens d'affichage (13) du terminal (1) dans une interface dudit fournisseur de services ; (b) Extraction par les moyens de traitement de données (11) d'une pluralité d'images dudit contenu tel qu'affiché par les moyens d'affichage (13) du terminal (1) ; (c) Analyse de ladite pluralité d'images extraites de sorte à déterminer au moins un paramètre représentatif de la qualité d'expérience utilisateur. 2. Procédé selon la revendication 1, dans laquelle chacune de la pluralité d'images est extraite à l'étape (b) par capture d'écran. 3. Procédé selon l'une des revendications 1 et 2, dans lequel le terminal (1) est connecté à un boitier de test (10) comprenant des moyens de traitement de données, les étapes (a) et (b) étant mises en oeuvre sous le contrôle des moyens de traitement de données du boitier de test (10), l'étape (b) comprenant en outre l'envoi desdites images extraites aux moyens de traitement de données du boitier de test (10) pour mise en oeuvre de l'étape (c). 4. Procédé selon l'une des revendications 1 à 3, dans laquelle l'interface dudit fournisseur de services comprend une barre de lecture affichée par- dessus le contenu, l'étape (c) comprenant l'identification de ladite barre de lecture dans lesdites images extraites. 5. Procédé selon la revendication 4, dans lequel ladite barre de lecture représente l'état d'avancement de la lecture et l'état de remplissage d'un buffer. 16 6. Procédé selon la revendication 5, dans lequel l'étape (c) comprend la détermination dans chaque image à partir de la barre de lecture de : - une coordonnée d'état d'avancement de la lecture, - une coordonnée d'état de remplissage du buffer. 5 7. Procédé selon la revendication 6, dans lequel un paramètre représentatif de la qualité d'expérience utilisateur déterminé à l'étape (c) est un pourcentage de lecture du contenu et/ou un pourcentage de bufferisation du contenu. 10 8. Procédé selon l'une des revendications 1 à 7, dans lequel ladite pluralité d'images dudit contenu est extraite à une fréquence prédéterminée lors de l'étape (b). 9. Procédé selon l'une des revendications 1 à 8, dans lequel au moins 15 un paramètre représentatif de la qualité d'expérience utilisateur déterminé à l'étape (c) est un paramètre de format du contenu, en particulier une résolution ou un nombre d'images par seconde. 10. Procédé selon la revendication 9, dans lequel l'étape (c) comprend 20 pour un ensemble de coordonnées prédéterminées de l'image la comparaison de la couleur du pixel correspondant de l'image avec une couleur attendue de sorte à déterminer un sous-ensemble dudit ensemble formé des cordonnées telles que la couleur du pixel correspondant coïncide avec la couleur attendue. 25 11. Procédé selon la revendication 10, dans lequel différentes n-uplets de valeurs possibles du ou des paramètres de format de l'image sont chacun associé avec un sous-ensemble donné dudit ensemble de coordonnées prédéterminé, l'étape (c) comprend l'identification des valeurs du ou des paramètres de format d'image associées avec le sous-ensemble déterminé. 30 12. Boitier de test (10) pour l'évaluation de l'expérience utilisateur lors de la lecture, sur un terminal mobile (1) connecté au boitier (10) et à un réseau étendu (20), d'un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau (20), le boitier de test étant caractérisé en ce qu'il comprend des moyens de traitement de 35 données configurés pour : 17 - Commander à des moyens de traitement de données (11) du terminal mobile (1) la restitution en continu dudit contenu vidéo et l'affichage par des moyens d'affichage (13) du terminal (1) dans une interface dudit fournisseur de services ; - Commander auxdits moyens de traitement de données (11) du terminal (1) 5 l'extraction d'une pluralité d'images dudit contenu tel qu'affiché par les moyens d'affichage (13) du terminal (1) ; - Analyser ladite pluralité d'images extraites de sorte à déterminer au moins un paramètre représentatif de la qualité d'expérience utilisateur. 10 13. Terminal mobile (1) connecté à un réseau étendu (20), caractérisé en ce qu'il comprend des moyens d'affichage (13) et des moyens de traitement de données (11) configurés pour : - Restituer en continu un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau (20), et l'afficher sur les moyens d'affichage (13) dans une 15 interface dudit fournisseur de services ; - extraire une pluralité d'images dudit contenu tel qu'affiché par les moyens d'affichage (13) ; - Analyser ladite pluralité d'images extraites de sorte à déterminer au moins un paramètre représentatif de la qualité d'expérience utilisateur. 20 14. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 11 d'évaluation de l'expérience utilisateur lors de la lecture sur un terminal mobile (1) connecté à un réseau étendu (20) d'un contenu vidéo diffusé par un fournisseur de contenus depuis ledit 25 réseau (20), lorsque ledit programme est exécuté par un ordinateur. 15. Moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d'ordinateur comprend des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 11 d'évaluation de 30 l'expérience utilisateur lors de la lecture sur un terminal mobile (1) connecté à un réseau étendu (20) d'un contenu vidéo diffusé par un fournisseur de contenus depuis ledit réseau (20).