FR 3021833 A1 20151204 FR 1401264 A 20140527 - 1 - La présente invention concerne le domaine technique de vérification de l'intégrité de données vidéo et de sa source dans le cadre de systèmes de vidéo à la demande basés sur l'utilisation de boîtiers décodeurs TV de type "Set Top Box". État de la technique: Il existe dans l'état de la technique des procédés de pair-à-pair (P2P) pour échanger et partager des contenus vidéo entre différents utilisateurs. Ce procédé est de plus en plus utilisé dans le cadre de systèmes de vidéo à la demande (P2P-vod), afin de réaliser une diffusion de flux vidéo en continu (streaming); dans ces systèmes, les utilisateurs sont à la fois récepteurs et émetteurs (clients et fournisseurs). 15 De tels systèmes nécessitent une maintenance pour la mise à jour des sources proposant le contenu vidéo: par exemple, en cas de connexion à une source corrompue, l'utilisateur doit prendre l'initiative de signaler l'erreur au fournisseur de contenu pour procéder à la suppression ou au remplacement de la source; de même, il n'est pas possible de détecter lorsqu'un flux vidéo est corrompu, ou 20 contient une image de mauvaise qualité; enfin, ces systèmes ne permettent pas d'attester de la qualité et de la véracité du contenu de la vidéo par rapport au nom ou à la description des données vidéo, ce qui fait que l'utilisateur n'est pas certain d'accéder à la ressource souhaitée. 25 Ces incertitudes entraînent pour l'utilisateur des défauts de fiabilité et de sécurité au moment où il réalise une requête relative à un flux vidéo diffusé en continu, plus communément appelée streaming. Le manque de fiabilité et de qualité de la source présente sur le serveur engendre un besoin de test qui permettrait de vérifier le contenu de la source et d'en informer l'administrateur du système, et de 30 trier les contenus pour les rendre indisponibles aux autres utilisateurs. La présente invention a donc pour but de résoudre les problèmes techniques mentionnés ci-dessus, en proposant un procédé de vérification automatique des 3021833 - 2 - sources et de données de flux vidéo diffusées en continu dans le cadre d'un système de vidéo à la demande ainsi que la mise à jour automatique desdites sources, et la génération d'alertes lorsque le résultat d'une telle vérification indique des anomalies. 5 DESCRIPTION DE L'INVENTION La présente invention concerne un procédé de vérification de l'état de sources indexées sur un serveur central, ainsi que des données de flux vidéo contenues dans ces sources, notamment pour la diffusion en continu dans le cadre d'un système de vidéo à la demande. Il permet au serveur central d'identifier les sources à remplacer, lorsqu'un seuil de nombre de boîtier signalant une même anomalie sur une même source est atteint. Le nombre nécessaire de boîtiers décodeurs indiquant un défaut de fonctionnement de la source déterminée ou un 15 dysfonctionnement des données vidéo présentes dans cette source est paramétré sur une console d'administration. Ce procédé permet également de mettre à jour automatiquement la liste des sources (actualisation de la liste d'URL REST) présente sur le serveur centrai L'invention est accompagnée d'un système permettant la mise en oeuvre du procédé. 20 Le système est composé d'un serveur central, d'une console d'administration et d'au moins un boîtier décodeur. La console d'administration comprend des moyens d'affichage et de traitement 25 d'alerte. L'alerte est générée lorsque le résultat des tests pour la vérification des sources et des données indique des erreurs et/ou dysfonctionnements. Les dessins annexés illustrent l'invention: 30 La figure 1 illustre le diagramme d'action qui représente la communication (connexion) (1) entre le boîtier décodeur et le serveur central, puis l'accès (2) du boîtier décodeur à la liste de sources, la sélection (3) de la source par l'utilisateur et la requête (4) auprès de la source pour télécharger (5) les données. Elle 3021833 - 3 - représente également l'élaboration d'un rapport d'erreurs des sources défaillantes par le boîtier décodeur, lorsque ses données ne sont pas lisibles, et par conséquence l'envoi (6) de ce rapport d'erreur au serveur central. 5 La figure 2 illustre le diagramme d'action qui représente l'identification (7) du boîtier décodeur auprès du serveur central lorsqu'une communication (connexion) (1) entre eux est établie, ainsi que la réception (8), sous forme d'alerte, par le serveur central d'au moins un rapport d'erreur établi par le boîtier décodeur, lorsqu'il repère une source défaillante et/ou des erreurs auprès des données i.o vidéo, puis l'enregistrement dudit rapport (9) dans la base de données hébergées dans le serveur central. Elle représente également des tests (batch test) (10) réalisées par le serveur central auprès de la source repéré comme défaillante, ainsi que l'actualisation (12) de la liste de sources en supprimant (11) la source défaillante. 15 La figure 3 illustre le diagramme d'action qui représente la lecture (13) frame (trame en français) bit par bit des données vidéos téléchargées par le boîtier (17) décodeur et le déclenchement, en parallèle, des différents tests pour analyser (14) ces données. Elle représente également la réalisation et l'enregistrement d'un 20 rapport des erreurs (15) dans le moyen de stockage du boîtier, lors de l'analyse (14) des données, ainsi que l'envoi dudit rapport (16) au serveur central. La figure 4 représente le transfert des informations, notamment les rapports d'erreurs du boîtier (17) décodeur vers le serveur (18) central, ainsi que l'accès 25 par l'administrateur du système auxdites informations par le biais de consultations réalisées sur la console d'administration (19). Elle représente également l'envoie des alertes au boîtier (17) décodeur par la console d'administration (19). Le boîtier (17) décodeur du système selon l'invention comprend des moyens pour 30 réceptionner et émettre les données des sources indexées sur le serveur (18) central, un moyen de stockage pour enregistrer de telles données, ainsi que d'au moins une liaison filaire (port Ethernet, au moins un port USB, port HDMI) avec les différents appareils multimédia (téléviseurs, tablettes et smartphones notamment), 3021833 -4- une communication sans fil (données cellulaires/ Wi-Fi) avec le serveur (18) central et les sources. Un autre composant du système selon l'invention est un serveur (18) central sur 5 lequel est déployé un module de traitement de lot, dit batch test. L'autre composant du système selon l'invention est la console d'administration (19) qui comprend des moyens d'affichage et de traitement d'alerte, l'alerte étant générée lorsque les résultats des tests indiquent au moins une anomalie, des erreurs et/ou dysfonctionnements. Ce système met en oeuvre le procédé décrit par la suite. Dans un premier temps, la communication (connexion) (1) sans fil (données 15 cellulaires / Wi-Fi) est mise en oeuvre entre le boîtier (17) décodeur et le serveur (18) central, cette communication (1) permettant l'accès (2) aux sources indexées. Cette étape est importante pour ensuite pouvoir assurer une communication pair à pair (P2P) efficiente entre le boîtier (17) décodeur et les sources. Les sources sont agencées et une liste en format catalogue est générée sur le serveur (18) central. 20 Cette liste en URL REST, appelée indexation des fichiers, est composée de données vidéos qui ont été rendus disponibles par ces sources pour la diffusion en continu. Ensuite, le boîtier (17) accède à une source en se connectant sur une URL 25 indexée sur le serveur (18) central. Le boîtier (17) réalise donc des requêtes (4) auprès de la source. Dans l'hypothèse où la requête (4) obtient une réponse, les données sont transmises (5) directement de la source au moyen de stockage du boîtier (17), par 30 le biais de la communication pair à pair. Dans l'hypothèse où la requête (4) n'obtient pas de réponse, le boîtier (17) envoie (6) un rapport d'erreurs au serveur (18) central pour que la source défaillante, 3021833 - 5 - notamment inaccessible, soit identifiée et répertoriée dans les bases de données dudit serveur (18). Parallèlement, le serveur (18) central envoie une instruction au boîtier (17) concerné pour qu'il se connecte à l'URL suivante dans l'indexation. 5 Puis, les données téléchargées (5) par morceaux bits, dite frame bit par bit, de la source au moyen de stockage du boîtier (17) sont analysées (14) de la façon suivante: le boîtier (17) lit (13) les données vidéo téléchargées (5) et réalise simultanément une analyse (14) du cryptage des données vidéo, analyse (14) du son, réalise une estimation (14) du temps d'accès à la source (ping) et analyse (14) la qualité de la transmission du flux vidéo diffusé en continu, entre autres, sur la base d'algorithmes; le boîtier (17) réalise un rapport contenant les erreurs constatées issues d'une telle analyse (14) et puis enregistre (15) ledit rapport dans le moyen de stockage du boîtier (17). Lorsque le boîtier (17) établie une communication avec le serveur (18) central, puis il (17) est identifié (7) par le même (18), le boîtier (17) décodeur envoie les rapports (6) - (16) contenant des erreurs sur la source et/ou sur les données vidéos au serveur (18) central, puis des alertes sont générées et affichées sur la console d'administration (19). Au moins trois types d'erreurs donnent lieu au signalement d'une alerte: - L'impossibilité de lecture des données; - La mauvaise qualité de l'image; - La mauvaise qualité de la transmission. Préférentiellement, la source répertoriée dans le rapport d'erreurs est remplacée lorsqu'elle a fait l'objet d'un nombre défini de signalements par les boîtiers (17). Ainsi, le serveur (18) met en oeuvre un processus de vérification des alertes (10) par le biais de son module de traitement de lots (batch test). Le seuil à partir duquel le traitement de lots (batch test) est déclenché est fixé manuellement ou automatiquement par le biais d'une console d'administration (19). 3021833 - 6 - Par la suite, si les résultats du traitement de lots (batch test) (10) confirment les alertes émises par les boîtiers (17), le serveur (18) central met à jour (12) le contenu de la liste de sources et envoie une alerte à la console d'administration. s Parallèlement, le serveur (18) central envoie une instruction au boîtier (17) concerné pour qu'il se connecte à la source suivante dans la liste d'URL, et supprime I'URL défectueuse de la liste (11), procédant ainsi à l'actualisation (12) desdites sources. 2.0 Le système et le procédé selon l'invention permettent donc de résoudre les problèmes qui parasitent la diffusion en continu par la vérification et la mise à jour des sources et des contenus des sources. En outre, ils permettent la génération d'alarmes lorsque le résultat d'actualisation des contenus vidéo indique notamment des erreurs et dysfonctionnements. REVENDICATIONS: 1) Procédé de vérification des sources et des données vidéo afférentes pour la diffusion en continu caractérisé en ce qu'il comprend les étapes suivantes: a) Une communication (1) sans fil, type données cellulaires ou Wi-Fi, entre le serveur (18) central et le boîtier (17) décodeur pour assurer une communication pair à pair (P2P) entre le boîtier (17) décodeur et les sources indexées sur une liste d'URL contenant les données vidéo pour la diffusion en continu; b) L'identification des sources défaillantes à partir de réponses des requêtes (4) réalisées par le boîtier (17) auprès de différentes sources; c) Élaboration d'un rapport d'erreur sur les sources défaillantes par le boîtier (17). 15 d) La lecture (13) et l'analyse (14) des données vidéo téléchargées par le boîtier (17) sur son moyen de stockage; e) La réalisation par le boîtier (17) décodeur d'un rapport d'erreurs sur les données transmises (5) de la source au moyen de stockage du boîtier (17); f) L'envoie des rapports d'erreurs (6) - (16) sur la source et/ou sur les 20 données vidéo au serveur (18) central ; g) L'enregistrement des rapports d'erreurs (6) - (16) dans les bases de données du serveur central; h) La suppression (11) ou le remplacement des sources défaillante(s) et/ou fournissant des données erronées et/ou défectueuses; 25 i) L'actualisation (12) de la liste des sources d'URL Rest; j) La génération d'alertes 2) Procédé selon la revendication 1, caractérisé en ce que lorsqu'une défaillance de source est répertoriée, le serveur (18) central envoie parallèlement une 30 instruction au boîtier (17) afin qu'il se connecte à la prochaine source dans l'ordre de priorité établi. 3021833 - 8 - 3) Procédé selon la revendication 1, caractérisé en ce que le boîtier (17) réalise en parallèle.la lecture (13) frame bit par bit des données vidéo téléchargées sur son moyen de stockage et des différents tests pour analyser (14) telles données. 5 4) Procédé selon les revendications 1 et 3, caractérisé en ce que l'analyse (14) des données vidéo téléchargées par le boîtier (17) sur son moyen de stockage comprend notamment: a) une analyse (14) du cryptage des données vidéo, b) une analyse (14) du son, c) une estimation (14) du temps d'accès à la source (ping) d) une analyse (14) la qualité de la transmission du flux vidéo diffusé en continu sur la base d'algorithmes 5) Procédé selon la revendication 1, caractérisé en ce que le seuil de nombre de boîtiers (17) signalant une même source défaillante est fixé manuellement ou automatiquement sur la console d'administration (19). 6) Procédé selon les revendications 1 et 5, caractérisé en ce que la vérification des alertes d'erreur sur des sources répertoriées comme défaillantes est réalisé par un module de traitement de lots "batch test" (10) déployé par le serveur (18) central. 7) Procédé selon la revendication 1, caractérisé en ce que les alertes sont affichées sur le moyen d'affichage des consoles d'administration (19). 8) Système pour mettre en oeuvre ledit procédé caractérisé en ce qu'il comporte: a) un serveur (18) central sur lequel est déployé un module de traitement de lots (10); b) une console d'administration (19) comprenant des moyens d'affichage et de traitement d'alerte; c) au moins un boîtier (17) décodeur comprenant: d) des moyens pour réceptionner et émettre des données provenant de sources indexées sur le serveur (18) central, 3021833 - 9 - e) un moyen de stockage pour enregistrer de telles données, f) au moins une liaison filaire, type port Ethernet, port USB, port HDMI, avec les différents appareils multimédia type téléviseurs, tablettes et smartphones notamment, s g) une communication sans fil, type données cellulaires ou Wi-Fi, avec le serveur (18) et les sources.