Brevet FR3020911A1 — publié le 20151113

- 1 - La présente invention concerne le domaine technique de transmission des données vidéo pour la diffusion en continu sur boîtier décodeur. État de la technique: Les procédés de vidéo à la demande sont connus dans l'état de la technique: ils permettent d'utiliser des boîtiers décodeurs TV pour afficher sur les différents appareils numériques (téléviseurs, tablettes notamment) une interface graphique leur permettant de choisir un programme (film, série notamment) parmi un catalogue donné, pour envoyer une requête relative à ce programme à une source de contenu donnée et pour réceptionner et visionner les données vidéos relatives à ce programme via un téléchargement et une lecture de diffusion en continu par le boîtier décodeur TV. Ces boîtiers permettent donc à leurs utilisateurs de visionner des films et des séries en se basant sur un seul type de protocole de 15 communication d'échange client-serveur du type pair à pair. Les systèmes de vidéo à la demande utilisent de plus en plus la technologie de l'échange de fichiers pair à pair. Ce procédé fonctionne de la façon suivante: un utilisateur, qui correspond à un pair récepteur, recherche, par le biais 20 d'applications logicielles P2P déployées sur le boîtier, une vidéo sur un réseau de communications Internet. Un autre utilisateur, qui possède le contenu recherché, partage cette ressource avec le pair récepteur à travers le même type d'applications logicielles, il s'agit d'un pair émetteur. Ainsi, l'échange du fichier peut s'effectuer directement entre ces pairs. 25 Les systèmes de vidéo à la demande tels que décrits précédemment ne sont compatibles qu'avec ce seul type de protocole pour la recherche de sources à partir desquelles les données vidéos sont transférées, ce qui peut limiter le débit de téléchargement de données et donc augmenter le temps nécessaire au 30 téléchargement du vidéo, et peut occasionner de fréquentes interruptions de lecture du vidéo pour la mise en mémoire tampon des données. En élargissant le nombre de protocoles compatibles pour les sources, le nombre de sources et de données vidéo mises à disposition serait de ce fait augmenté, ce qui permettrait - 2 - un système de téléchargement et de lecture de vidéo diffusé en continu plus performant. La présente invention est destinée à pallier à ces inconvénients en proposant un procédé de diffusion en continu de vidéos caractérisé en ce qu'il télécharge simultanément et parallèlement des données vidéos auprès des sources indexées sur un serveur central, chacune utilisant différents types de protocoles de transmission des données comme HTTP - Hypertext Transfer Protocol, FTP - File Transfer Protocol, P2P - Pair à Pair, ce qui augmente le débit de téléchargement du fait de l'augmentation du nombre de sources, réduit le temps de téléchargement et diminue les interruptions lors de la diffusion en continu des vidéos. L'invention propose également un dispositif basé sur un boîtier récepteur de 15 données compatible avec lesdits protocoles de transmission des données. Description de l'invention La présente invention concerne un procédé destiné à télécharger de façon 20 simultanée des données vidéos pour la diffusion en continu à partir de sources de protocoles de transmission des données de type HTTP - Hypertext Transfer Protocol, FTP - File Transfer Protocol, P2P - Pair à Pair, indexées et disponibles sur un serveur central. L'invention comprend également un dispositif basé sur un boîtier récepteur de données vidéos. 25 Le terme "diffusion en continu" utilisé dans la présente description désigne la lecture de flux vidéo en continu (également appelée streaming) et/ou la lecture de données vidéo à partir du moyen de stockage du boîtier. 30 Le terme "protocole" utilisé au long de la présente description correspond aux protocoles HTTP Hypertext Transfer Protocol, FTP - File Transfer Protocol et/ ou P2P - Pair à Pair, cette liste étant non limitative. - 3 - Le boîtier (1) récepteur de données selon l'invention est composé de moyens de connexion internet filaires (notamment câble RJ45) et non filaires (notamment WiFi et données cellulaires du type 3G et/ou 4G, liste non limitative), des modules de traitement, une mémoire tampon, un moyen de réception et un moyen de stockage des données vidéos et un moyen de visionnage destiné à la lecture de vidéos diffusées en continu reconstitués à partir de ces données . Les moyens de connexion internet filaires et non filaires permettent d'établir une connexion avec le serveur central. Les modules de traitement permettent de déployer une interface graphique sur différents appareils numériques du type téléviseurs et/ou tablettes, liste non limitative. L'interface graphique permet aux utilisateurs d'effectuer une requête relative à un programme (film, série notamment), de leur donner accès à la liste des sources établie par le serveur central sur la base de cette requête, puis de confirmer ou non le choix du programme. Les modules de traitement sont compatibles avec les différents protocoles de transmission des données de type HTTP - Hypertext Transfer Protocol, FTP - File Transfer Protocol, P2P - Pairs à Pair. Les dessins annexés illustrent l'invention: La figure 1 représente la demande d'identification du boîtier (1) décodeur auprès du serveur (3) central, et, dans le cas où l'identification est réalisée, la mise à jour 25 automatique du module du boîtier (1). La figure 2 représente l'envoi des informations du boîtier (1) au serveur (3) central, ainsi que la centralisation desdites informations dans une base de données (6). Ces informations sont relatives notamment au nombre de lecture de données (2) 30 vidéos, ainsi qu'à l'état matériel dudit boîtier (1) (évalué à l'aide de capteurs, caméras, entre autres moyens de détection et de mesure). - 4 - La figure 3 représente la récupération par le boîtier (1) de la liste des sources des données vidéos établie par le serveur (3) central, lorsque l'identification du boîtier (1) décodeur auprès du serveur (3) central est réalisée. La figure 4 représente la récupération par le boîtier (1) de la liste (5) des sources (4) des données (2) vidéos établie par le serveur (3) central. La figure 5 représente les requêtes relatives à un programme (film, série notamment) réalisées simultanément et parallèlement auprès de différentes sources (4), chacune de ces sources (4) utilisant différents types de protocoles de transmission des données tels que HTTP - Hypertext Transfer Protocol (7), FTP File Transfer Protocol (8), P2P - Pair à Pair (9), cette liste n'étant pas exhaustive, ainsi que les réponses relatives à ces requêtes, notamment le téléchargement simultané et parallèle des données (2) vidéos par le boîtier (1). Dans une réalisation, lors de l'identification d'au moins un boîtier (1) décodeur auprès du serveur (3) central piloté à distance, le boîtier (1) est autorisé à accéder aux sources (4) indexées par ce serveur (3). L'identification du boîtier (1) décodeur se fait de manière automatique lors de la requête pour l'accès à la liste (5) des sources (4) indexées. Une fois l'identification réalisée et le boîtier (1) décodeur reconnu par le serveur (3) central, celui-ci (3) effectue des mises à jour automatiques sur le module et sur le matériel dudit boîtier (1). Le boîtier (1) décodeur envoie au serveur (3) des informations relatives notamment au nombre de lecture de données (2) vidéos, ainsi que sur l'état matériel dudit boîtier (1) (évalué à l'aide de capteurs, caméras, entre autres moyens de détection et de mesure. Ces échanges permettent la centralisation desdites informations dans une base de données (6). Ces informations sont nécessaires à la maintenance du matériel et du module en question et au test des sources (4) indexées par le serveur (3). Cette base de données (6) permet également au serveur (3) de réaliser des tests sur les sources (4) indexées, lorsque le serveur (3) détecte un nombre important - 5 - de signalements d'erreurs par les boîtiers (1) décodeurs auprès de cette source (4). Les sources (4) contenant des erreurs signalées par lesdits boîtiers (1) sont remplacés par d'autres. Le serveur (3) central réalise également des tests auprès du boîtier (1) décodeur selon l'invention afin de vérifier la mémoire disponible sur le moyen de stockage . Lorsque le résultat du test indique que la capacité maximale de stockage est atteinte ou que l'espace disponible restant est insuffisant pour assurer la lecture des données (2) vidéo, les données (2) vidéos inutilisées sont supprimées, sur la base des informations transmises par le boîtier (1) au serveur (3). Parallèlement à la mise à jour, le boîtier (1) accède à la liste (5) indexée des noms desdites sources (4) située sur le serveur (3) central; ces sources (4) sont agencées par ordre décroissant d'importance de bande passante disponible. 15 Dans l'étape suivante, le boîtier (1) établit une communication avec au moins une source (4) indexée sur le serveur (3) central. A partir du moment où cette communication est effectuée, des tests sur les sources (4) sont réalisés avant la diffusion en continu. Si le résultat du test indique que la ou les sources (4) ne 20 fonctionnent pas, le boîtier (1) enregistre cette information, puis il met fin à cette communication. Il établit ensuite une communication avec la source suivante présente dans la liste et recommence le processus de test, indépendamment du type de protocole selon lequel la source est lisible: il est ainsi possible que, dans n'importe quel ordre, le boîtier (1) communique avec des sources (4) de type 25 HTTP (7) et FTP (8). Tant que les résultats des tests indiquent des sources (4) corrompues, le boîtier (1) poursuit les tests sur les différentes sources (4) présentes dans la liste (5). Dans le cas où il n'existe pas d'autre source (4), un message d'erreur est généré; 30 dans le cas où le résultat du test atteste de la validité de la source (4), ces données (2) vidéos sont transmises sur le moyen de lecture du boîtier (1). - 6 - Dans l'étape de lecture des données (2) vidéo diffusées en continu, le moyen de visionnage du boîtier (1) décodeur séquence les données (2) vidéo, c'est-à-dire qu'il assemble les morceaux de vidéo téléchargés à partir des indexations effectuées par le serveur (3) central et transforme ces morceaux en flux vidéo destiné à être lu directement par le boîtier (1) sur l'appareil numérique (téléviseur, tablette...). Puis, les séquences de données (2) sont réceptionnées sur la mémoire tampon. La lecture du flux vidéo se fait "bit par bit", simultanément et parallèlement au téléchargement des morceaux "bits" suivants, dès la présence du premier morceau "bit" dans la mémoire tampon. Ainsi, les données (2) vidéo de chacune des sources (4) de différents protocoles indexées sur un serveur (3) central sont téléchargées simultanément et parallèlement. Le dispositif et le procédé selon l'invention fournissent donc un moyen de téléchargement et de lecture simultané de flux vidéo à partir de sources (4) présentes sur Internet et indexées sur un serveur (3) central, interopérable et compatible avec les différents protocoles de communication existants. REVENDICATIONS1) Procédé de diffusion en continu de vidéo caractérisé en ce qu'il télécharge simultanément et parallèlement des données (2) vidéos auprès de sources (4) indexées sur un serveur (3) central, chacune de ces sources (4) utilisant différents types de protocoles de transmission des données selon les étapes suivantes: a) L'étape de communication et d'identification automatique entre le boîtier (1) et un serveur (3) central piloté à distance; b) L'étape de la communication entre le boîtier (1) et au moins une source (4) indexée sur le serveur (3) central; c) L'étape de réception par le boîtier (1) de façon simultanée des données (2) vidéo transférées par le biais de protocoles de transmission des données, notamment HTTP - Hypertext Transfer 15 Protocol (7), FTP - File Transfer Protocol (8), P2P - Pair à Pair (9); d) L'étape de lecture des données (2) vidéo diffusées en continu. 2) Procédé selon la revendication 1, caractérisé en ce que l'identification du boîtier (1) décodeur sur le serveur (3) central est réalisée automatiquement 20 lors de la requête relative à la liste (5) des sources (4) indexées. 3) Procédé selon la revendication 1, caractérisé en ce que l'identification du boîtier (1) décodeur sur le serveur (3) central conditionne la mise à jour du module du boîtier (1). 25 4) Procédé selon la revendication 1, caractérisé en ce que l'identification du boîtier (1) décodeur sur le serveur (3) central conditionne le téléchargement par le boîtier (1) de la liste (5) des sources (4) des données (2) vidéos établie par le serveur (3) central. 30 5) Procédé selon la revendication 1, caractérisé en ce que les sources (4) indexées sur le serveur (3) central sont agencées par ordre décroissant d'importance de bande passante disponible.- 8 - 6) Procédé selon la revendication 1, caractérisé en ce que le boîtier (1), lorsqu'il entre en communication avec une source (4) qui ne fonctionne pas, met fin à la communication avec cette source (4), puis établit une communication avec la source (4) suivante sur la liste (5) de sources (4), indépendamment du type de protocole. 7) Procédé selon la revendication 1, caractérisé en ce que la lecture vidéo débute dès lors que le premier morceau "bit" de vidéo est présent en mémoire tampon. 8) Procédé selon les revendications 1 et 3, caractérisé en ce que la lecture vidéo est réalisée simultanément et parallèlement au téléchargement des morceaux "bits" suivants de ladite vidéo. 9) Boîtier récepteur des données vidéos caractérisé en ce qu'il comprend : a) des moyens de connexion internet filaire, notamment port et câble RJ45; b) des moyens de connexion internet non filaire, notamment Wi-Fi et données cellulaires; c) des modules de traitement; d) une mémoire tampon; e) un moyen de réception de données (2) vidéo; f) un moyen de stockage; g) un moyen de visionnage de vidéos diffusées en continu. 10)Boîtier selon la revendication 6, caractérisé en ce qu'il est compatible avec les différents protocoles de transmission des données, notamment HTTP - Hypertext Transfer Protocol (7), FTP - File Transfer Protocol (8), P2P - Pair à Pair (9).