Brevet FR3034943A1 — publié le 20161014

DOMAINE TECHNIQUE GENERAL La présente invention concerne le streaming. Plus précisément, elle concerne un procédé de lecture en continu d'un contenu diffusé au sein d'un réseau pair à pair. ETAT DE L'ART Le « streaming » (en français « lecture en continu »), désigne une technique de lecture d'un flux audio ou vidéo « en direct », c'est-à-dire au fur et à mesure qu'il est récupéré depuis Internet par un équipement client. Elle s'oppose ainsi au téléchargement, qui nécessite de récupérer l'ensemble des données du contenu audio ou vidéo avant de pouvoir le lire. Dans le cas du streaming, le stockage du contenu est provisoire et partiel, les données étant téléchargées en continu dans une mémoire tampon du client (typiquement la mémoire vive), analysées à la volée par son processeur et rapidement transférées vers une interface de sortie (un écran et/ou des enceintes) puis remplacées par de nouvelles données. De façon traditionnelle, le contenu est mis à disposition sur un serveur de streaming. Le client souhaitant y accéder envoie une requête pour en récupérer les premiers segments (par segment, on entend un bloc des données du contenu, généralement correspondant à quelques secondes de lecture). Lorsqu'il y a suffisamment de données dans la mémoire tampon pour permettre de lire le début du contenu, la lecture 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. On constate néanmoins que cette approche à ses limites si un grand nombre de clients souhaitent lire le même contenu simultanément : le serveur se retrouve saturé, dans l'incapacité de fournir le contenu à un débit suffisant pour que la lecture soit fluide, et des saccades apparaissent. Il a récemment été proposé une stratégie alternative basée sur le « peer-to- peer » (P2P, en français pair-à-pair), dans laquelle chaque client agit comme un serveur pour d'autres clients : on parle de pairs. Un pair qui a commencé la lecture du contenu va retransmettre à d'autres les segments qu'il a déjà reçus, et ainsi de suite, d'où une facilité de diffusion quel que soit le nombre de clients intéressés. Cette stratégie est décrite dans la demande internationale WO 2012/154287. 3034943 2 Toutefois, bien que le P2P soit extrêmement efficace pour le téléchargement des fichiers, des difficultés apparaissent lorsqu'il est utilisé pour le streaming. Une contrainte porte sur le fait que pour être échangées en P2P, les 5 données doivent être conservées dans un format spécifique adapté (typiquement en Javascript si l'on utilise l'API VVebRTC), format qui n'est pas lisible en l'état par les lecteurs vidéo. Ainsi, grâce à une API telle que Media Source Extension, les segments P2P sont convertis en un flux vidéo. Cette technique apporte satisfaction, mais la Demanderesse a constaté 10 qu'elle s'avérait lourde. En effet, les segments convertis en flux vidéo remplissent un buffer (une mémoire tampon) vidéo pour lecture. On se retrouve donc à devoir stocker deux fois les données, ce qui peut rapidement saturer la mémoire cache, et entraîner des ralentissements et des désagréments pour l'utilisateur. Cela est d'autant plus 15 problématique dans le cas de la VOD, « Video On Demand » i.e. vidéo à la demande, ou de la vidéo en temps différé (par opposition au « live streaming » qui sera décrit plus loin), dans lequel il est souhaitable de maximiser la taille du cache P2P de sorte à augmenter les chances que les caches de deux pairs se recoupent et que des échanges soient possibles. 20 La présente invention vient améliorer la situation en proposant une méthode innovante de gestion des données en streaming P2P, en particulier VOD, qui est optimale en termes d'efficacité de la diffusion du contenu, d'encombrement des mémoires tampons des pairs, et de simplicité algorithmique. 25 PRESENTATION DE L'INVENTION La présente invention se rapporte ainsi à un procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair d'équipements clients, ledit contenu étant constitué d'une séquence de segments, 30 l'équipement client comprenant une première mémoire tampon stockant de façon temporaire au moins un segment brut dudit contenu, chaque segment brut étant dans un format adapté pour le transfert au sein du réseau pair-à-pair, le procédé étant caractérisé en ce qu'il comprend la mise en oeuvre par des moyens de traitement de données de l'équipement d'étapes de : 3034943 3 (a) Conversion dans un format adapté pour la lecture sur l'équipement d'au moins un segment brut de la première mémoire tampon, et stockage dudit segment converti dans une deuxième mémoire tampon de l'équipement, de sorte que la deuxième mémoire tampon stocke un nombre compris entre un 5 nombre minimal et un nombre maximal de segments convertis disposés en amont d'un point de lecture dudit contenu ; (b) Lecture depuis la deuxième mémoire tampon d'au moins un fragment du segment converti disposé au niveau dudit point de lecture ; (c) Suppression de ladite deuxième mémoire tampon d'au moins un segment 10 converti disposé en aval dudit point de lecture, de sorte que la deuxième mémoire tampon stocke un nombre inférieur ou égal à un nombre maximal de segments convertis disposés en aval d'un point de lecture dudit contenu, le segment brut associé étant conservé temporairement dans la première mémoire tampon. 15 Selon d'autres caractéristiques avantageuses et non limitatives : - l'étape (a) comprend la requête préalable dudit segment brut auprès des autres équipements clients du réseau pair à pair ; - l'étape (a) comprend la réception dudit segment brut depuis un serveur de 20 contenu connecté au réseau pair-à-pair s'il n'a pas pu être récupéré intégralement depuis un autre équipement du réseau pair-à-pair ; - ledit format des segments brut n'est pas adapté pour la lecture sur l'équipement, et ledit format des segments converti n'est pas adapté pour le transfert au sein du réseau pair-à-pair ; 25 - les segments bruts sont encapsulés en Javascript, et les segments convertis sont encapsulés dans un lecteur via une balise vidéo HTML5 ou un module Flash ; - le nombre minimal et le nombre maximal de segments convertis disposés en amont d'un point de lecture dudit contenu sont tels que la deuxième mémoire tampon contient entre 5 et 100 secondes, de préférence entre 15 et 60 secondes, 30 de segments amont ; - le nombre maximal de segments convertis disposés en aval d'un point de lecture dudit contenu est tel que la deuxième mémoire tampon contient moins de 30 secondes, de préférence moins de 20 secondes, de préférence moins de 10 secondes, de segments aval ; 3034943 4 - le procédé comprend : La première vérification à une première périodicité que la deuxième mémoire tampon stocke un nombre supérieur audit nombre minimal de segments convertis disposés en amont dudit point de lecture ; et/ou 5 La deuxième vérification à une deuxième périodicité que la deuxième mémoire tampon stocke un nombre inférieur audit nombre maximal de segments convertis disposés en aval dudit point de lecture ; Le procédé comprenant la mise en oeuvre de l'étape (a) en cas de résultat négatif de la première vérification, et la mise en oeuvre de l'étape (c) en cas de résultat 10 négatif de la deuxième vérification ; - la première périodicité est au moins dix fois supérieure à la deuxième périodicité ; - la deuxième périodicité est telle que l'intervalle temporel entre deux mises en oeuvre de la deuxième vérification est inférieure à la durée de contenu 15 correspondant au nombre maximal de segments aval stockés dans la deuxième mémoire tampon ; - les moyens de traitement de données de l'équipement sont configurés pour maximiser le nombre de segments bruts stockés dans la première mémoire tampon. 20 Selon un deuxième aspect, est proposé un équipement client d'un réseau pair à pair d'équipements clients, caractérisé en ce qu'il comprend Une première mémoire tampon stockant de façon temporaire au moins un segment brut d'un contenu constitué d'une séquence de segments, 25 chaque segment brut étant dans un format adapté pour le transfert au sein du réseau pair-à-pair ; Une deuxième mémoire tampon stockant de façon temporaire au moins un segment converti dudit contenu, chaque segment converti correspondant à un segment brut converti dans un format adapté pour 30 la lecture sur l'équipement ; des moyens de traitement de données configurés par la mise en oeuvre de : o un module de conversion d'un segment brut de la première mémoire tampon, et de stockage dudit segment converti dans la 35 deuxième mémoire tampon ; 3034943 5 o un module de lecture depuis la deuxième mémoire tampon d'au moins un fragment d'un segment converti disposé au niveau d'un point de lecture dudit contenu ; o un module de suppression de ladite deuxième mémoire tampon 5 d'au moins un segment converti disposé en aval dudit point de lecture, les modules de conversion et de suppression étant configurés de sorte que la deuxième mémoire tampon stocke un nombre compris entre un nombre minimal et un nombre maximal de segments convertis disposés en amont dudit point de 10 lecture, et un nombre inférieur ou égal à un nombre maximal de segments convertis disposés en aval dudit point de lecture. Selon un troisième et un quatrième aspect, l'invention concerne respectivement un produit programme d'ordinateur comprenant des instructions de 15 code pour l'exécution d'un procédé selon le premier aspect de l'invention de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair d'équipements clients, lorsque ledit programme est exécuté sur un ordinateur ; et un moyen de stockage lisible par un équipement informatique sur lequel un produit programme d'ordinateur comprend des instructions de code pour 20 l'exécution d'un procédé selon le premier aspect de l'invention de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair d'équipements clients. PRESENTATION DES FIGURES 25 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 description sera donnée en référence aux figures annexées dont : la figure 1 représente une architecture pour la mise en oeuvre du 30 procédé selon l'invention ; la figure 2 illustre un exemple d'utilisation de mémoires tampon dans un mode de réalisation du procédé selon l'invention ; les figures 3a et 3b sont des logigrammes illustrant respectivement un mode de réalisation préféré des étapes (a) et (c) du procédé selon 35 l'invention. 3034943 6 DESCRIPTION DETAILLEE Architecture 5 En référence à la figure 1, l'invention propose un procédé de lecture en continu d'un contenu diffusé au sein d'un réseau 1 tel que représenté. Le réseau 1 est ici un réseau de télécommunications à grande échelle et en particulier Internet. Ce réseau 1 comprend un réseau pair-à-pair 10 d'équipements client 11, 12. 10 Chaque équipement client 11, 12 est typiquement un équipement informatique personnel tel qu'un smartphone, un PC, une tablette, etc. connectée au réseau 1, disposant de moyens de traitement de données 110 tels qu'un processeur, d'une interface pour la lecture du contenu, et disposant de deux mémoires tampon M1 et M2 (appelées également « buffer »), typiquement deux zones d'une mémoire vive, 15 chacune pouvant stocker (d'une façon différente comme l'on va voir) tout ou partie du contenu de façon temporaire (par temporaire, on entend que les segments sont supprimés de cette mémoire peu de temps après qu'ils aient été lus : il ne sont pas stockés à long terme comme c'est le cas pour un téléchargement direct). Comme l'on verra plus tard, dans le cas préféré d'une lecture via un navigateur, tous les 20 segments sont typiquement supprimés (i.e. les mémoires tampon réinitialisées) au plus tard lorsque l'on ferme le navigateur ou l'onglet dans lequel la vidéo est jouée. La première mémoire tampon M1 est appelée « cache pair-à-pair ». Elle stocke les segments sous un format dit « brut ». Par segments bruts, on entend sous un format adapté pour le transfert au sein du réseau pair-à-pair 10 (on verra 25 comment plus tard), mais inadapté pour la lecture sur l'équipement 11. La deuxième mémoire tampon M2 est appelée « buffer vidéo ». Elle stocke les segments sous un format dit « converti ». Par segments convertis, on entend convertis depuis des segments bruts sous un format adapté pour la lecture sur l'équipement 11, mais inadapté pour le transfert au sein du réseau pair-à-pair 10. 30 Comme l'on voit sur la figure 2 qui sera décrite plus loin, même si l'ensemble des segments bruts (respectivement des segments convertis) forment de façon préférée un intervalle unique (i.e. ces segments sont consécutifs et formant une sous-séquence de la séquence de segments constituant le contenu), il peut y avoir des intervalles disjoints si par exemple l'utilisateur déplace 3034943 7 manuellement le point de lecture dans la vidéo, par exemple de sorte à revenir en arrière. Comme expliqué dans l'introduction, les équipements 11, 12 sont des 5 « pairs » (appelés également « noeuds ») du réseau pair-à-pair 10. Par « équipements client 11, 12 d'un réseau pair-à-pair 10 » on entend des équipements connectés dans le réseau 1 par un protocole réseau pair-à-pair. En d'autres termes, les moyens de traitement de données de chaque pair mettent en oeuvre un programme particulier (logiciel client), qui peut être par exemple intégré 10 à un navigateur web, une application mobile, ou tout autre logiciel embarqué (par exemple un player d'un boitier d'accès à internet ou d'un boitier multimédia, i.e. une « Set-top box »), pour l'utilisation du pair-à-pair. En effet, un réseau pair-à-pair, ou « peer-to-peer » ou encore P2P, est un sous-réseau décentralisé au sein du réseau 1, dans lequel des données peuvent 15 être transférées directement entre deux équipements client 11, 12 du réseau 10, sans transiter par un serveur central. Il permet ainsi à tous les équipements client 11, 12 de jouer à la fois le rôle de client et serveur. Les pairs 11, 12 sont ainsi définis comme des « seeders » (en français les « semeurs », c'est-à-dire des fournisseurs de données) et/ou des « leechers » (en français les « sangsues », 20 c'est-à-dire des receveurs de données). Ledit contenu, qui est en particulier un contenu audio ou vidéo, c'est-à-dire un média d'une certaine durée, est constitué d'une séquence de segments (dite « liste de lecture », en anglais « playlist ») stockés sur des moyens de stockage de données d'un serveur 2 connecté au réseau pair-à-pair 10. Les segments ont une 25 longueur prédéterminée, typiquement une ou deux secondes du contenu, mais elle peut aller d'une fraction de seconde à une dizaine de secondes. Tous les segments d'un contenu donné ont généralement la même longueur. Le serveur 2 est un serveur de contenu, avantageusement présent dans le réseau 1 et connecté au réseau pair-à-pairs 10. En d'autres termes, il s'agit d'un 30 (ou plusieurs) serveurs du réseau internet 1 mettant à disposition les segments de divers contenus conformément à un protocole de streaming donné. On citera par exemple l'exemple de HLS (« HTTP Live Streaming »), dans lequel les segments sont des fichiers « ts », listés dans un fichier playlist « m3u8 ». HLS implique le format MPEG2 pour le contenu. On citera également les protocoles de streaming 35 DASH, Smooth streaming, ou HDS. Les segments bruts sont encapsulés par 3034943 8 exemple en JavaScript, de sorte à permettre l'échange entre pairs de ces segments via une API de type WebRTC. Le serveur 2 est la source primaire des segments, dans la mesure où initialement aucun pair ne dispose du contenu (avant un premier transfert du 5 serveur 2 vers ce pair 11, 12). Les contenus sont soit dès l'origine stockés dans leur intégralité sur le serveur 2 (cas de la VOD précédemment évoqué), soit générés en temps réel (cas du live streaming, ou streaming en direct), et dans ce dernier cas la liste de segments qui les constitue évolue dynamiquement. Le « Live Streaming » (c'est-à-dire le « streaming en direct ») propose de 10 diffuser en temps réel des contenus associés à des événements « en live », par exemple des concerts, des conférences, des rencontres sportives, des parties de jeux vidéo, etc., qui sont en train de se dérouler simultanément. Par rapport au streaming d'un contenu déjà intégralement existant tel qu'un film, un contenu diffusé en Live streaming est en effet généré au fur et à mesure que l'événement 15 associé se déroule. Techniquement, comme dans le cas d'un direct à la télévision, un tel contenu ne peut être diffusé qu'avec un léger retard, que l'utilisateur souhaite le plus faible possible. Ce retard est typiquement de l'ordre d'une minute, mais peut descendre jusqu'à une vingtaine de secondes. Ceci fait qu'une liste de lecture de seulement une poignée de segments (tout au plus quelques dizaines) 20 est disponible à chaque instant, les segments de cette liste étant renouvelés dynamiquement selon un roulement : au fur et à mesure que l'événement se déroule des nouveaux segments sont créés, « vieillissent », sont reçus et lus par les clients (à l'issu du retard prévu), et enfin sortent de la liste. Dans ce dernier cas (live streaming), le contenu doit plutôt être vu comme 25 un flux en continu. La séquence de segments est ainsi dynamique, c'est-à-dire qu'elle est mise à jour régulièrement. A chaque fois qu'un nouveau segment est généré il est ajouté en fin de la séquence, et le premier segment de la séquence (le plus ancien) est supprimé. Tous les autres se décalent selon un mécanisme de roulement que l'on peut apparenter à une liste FIFO. Le premier segment de la 30 liste (le plus ancien) peut être celui au niveau du point de lecture, en d'autres termes le segment « en direct » (et donc les segments sont supprimés de la liste de lecture dès qu'ils sont lus), ou un segment « passé » si le serveur de contenu accepte qu'on lise le contenu avec du retard (certaines plateformes proposent du live streaming avec jusqu'à 2h de retard), c'est ce que l'on appelle le DVR 35 (« enregistreur vidéo numérique »). 3034943 9 De façon préférée, le présent procédé est mis en oeuvre dans un contexte de VOD ou de DVR. Est également avantageusement connecté au réseau pair-à-pair 10 un 5 serveur de gestion de pairs 3 appelé « tracker ». Le tracker 3 présente des moyens de traitement de données et des moyens de stockage. Il coordonne les échanges entre pairs 11, 12 (en contrôlant le logiciel client mis en oeuvre par chacun des équipements client 11, 12), mais il n'est pas directement impliqué dans le transfert de données et ne possède pas de copie du fichier. 10 En revanche, il communique avec le serveur de contenu 2. Pour chacun des contenus stockés sur ce serveur 2, le tracker 3 reçoit (sur requête ou par push) du serveur 2 un fichier « manifeste » pour chacun des contenus. Ce fichier manifeste est un descriptif du contenu (au format XML pour la plupart des protocoles de streaming sauf HLS), et contient notamment la liste des segments. 15 Le tracker 3 analyse alors le manifeste (par « parsing », i.e. analyse syntaxique) de sorte à extraire la liste des segments. Dans le cas du live streaming, le manifeste est en général réémis à intervalle réguliers de sorte à permettre une mise à jour de la liste de lecture (on rappelle que comme le contenu est généré en direct en permanence des segments 20 nouveaux entrent la liste de lecture et d'autres la quittent quand ils sont devenus trop anciens et ont dépassé le point de lecture). Alternativement, est fourni un squelette de manifeste (c'est-à-dire sans la liste des segments) accompagné d'indications temporelles (dont un horodatage, en anglais « timestamp ») permettant de déterminer quand chaque nouveau segment est émis, ce qui permet 25 au tracker 3 (et aux équipements clients 11, 12) de compléter ce squelette et de le mettre à jour tout seul. Pour chaque manifeste (obtenu complet ou dont la liste de lecture a été automatiquement complétée), le tracker 3 réalise un « hash », c'est-à-dire met en oeuvre une fonction de hachage de sorte à obtenir une empreinte du manifeste, qui 30 constitue une signature du contenu auquel le manifeste est associé. Il est à noter que le hash peut être mis en oeuvre sur l'adresse du manifeste (son URL, « Uniform Resource Locator »), ce qui est intéressant puisque une URL reste constante même si le manifeste change régulièrement (du fait du live streaming). 35 Lecture 3034943 10 Dans la suite de la présente description, on se focalise sur un équipement client 11 qui est le cas échéant en train de récupérer le contenu depuis d'autres équipements 12 et/ou le serveur 2, c'est-à-dire que la première mémoire tampon 5 M1 stocke d'ors et déjà au moins un segment brut, si possible une sous-séquence de la séquence constituant le contenu. Le procédé commence alors par la mise en oeuvre par les moyens de traitement 110 de l'équipement d'une étape (a) de conversion dans un format 10 adapté pour la lecture sur l'équipement 11 d'au moins un segment brut de la première mémoire tampon Ml. Cette étape consiste à transformer le segment brut en un segment converti, qui pourra être lu par le lecteur de l'équipement 11 contrairement au premier. L'équipement client 11 est typiquement prêt à lire en continu le contenu 15 après une durée minimale de préchargement de segments dans la deuxième mémoire tampon M2 (les segments préchargés étant le plus souvent récupérés dans la première mémoire tampon M1 depuis le serveur 2), par exemple dix secondes (soit dix segments d'une seconde). De façon préférée, le lecteur est le lecteur intégré d'un navigateur 20 compatible HTML5, et la conversion consiste en l'injection des données vidéo du segment grâce à l'API Media Source Extension du navigateur, après quoi elles sont stockées dans la deuxième mémoire tampon M2 et ne sont plus accessibles. Dans le cas du navigateur, une balise HTML5 permet alors d'offrir des contrôles sur le lecteur intégré (lecture, pause, avance rapide, etc.), à la manière 25 de ce qu'offre une interface de contrôle utilisateur. C'est pourquoi la version brute du segment est conservée dans la première mémoire tampon M1 de sorte à permettre toujours son partage dans le réseau 10. On note que le présent procédé n'est pas limité à l'utilisation de balise HTML5 couplée à l'API Media Source Extension, et qu'on pourra par exemple utiliser un 30 module Flash, voir un module intégré nativement dans tout lecteur. Par exemple, le lecteur peut être celui intégré d'une application mobile (par exemple compatible nativement Object-C, C++, etc.). Dans tous les cas se posera le problème de la non-accessibilité des données une fois qu'elles ont été injectées dans le lecteur. Le choix du segment à convertir est tel que la deuxième mémoire tampon 35 M2 stocke un nombre minimal de segments convertis disposés en amont d'un 3034943 11 point de lecture dudit contenu. Par « amont » on entend des segments futurs, c'est-à-dire qui sont disposés dans le contenu postérieurement (d'un point de vue temporel) au point de lecture, i.e. qui n'ont pas encore été lus, et de façon préférée les smin, prochains segments consécutifs de la séquence de segments constituant 5 le contenu, sm,n, étant ledit nombre minimal de segments amonts. Dans la suite de la présente description, on parle de segments amont pour désigner ces segments convertis disposés en amont du point de lecture. Ainsi, de façon préférée, ce nombre minimal de segments amont s'exprime en temps de lecture. Par exemple, si l'on définit que la deuxième mémoire tampon 10 doit contenir un temps minimal de segments amont de 15s (avantageusement 10s, voire 5s dans une gestion particulièrement optimisée), alors dans le cas de segments d'une seconde le nombre minimal de segments amont devant être stockés par la deuxième mémoire est quinze. Si la première mémoire M1 ne contient pas suffisamment de segments 15 bruts pour respecter ce nombre minimal (i.e. si les segments n'ont pas été suffisamment rapidement récupérés depuis d'autres équipements 12), alors le ou les segments manquants sont (tout ou partiellement) récupérés depuis le serveur 2. De façon plus inhabituelle, le nombre de segments amont stockés par la 20 deuxième mémoire cache M2 respecte également un nombre maximal smax+. Ainsi, le nombre de ces segments amont est compris entre deux valeurs extrémales. L'idée est de réduire le buffer média (la deuxième mémoire tampon M2) à une zone réduite située autour du point de lecture. Ainsi, contrairement à ce qui pouvait se faire dans l'art antérieur où chaque segment brut était converti, ce qui entraînait 25 la nécessité de mobiliser deux fois la taille du cache P2P, le présent procédé propose en référence à la figure 2 de découpler les deux mémoires tampons M1 et M2 en maximisant la première (de sorte à faciliter les échanges au sein du réseau pair-à-pair 10 en assurant une disponibilité plus grande des données) et en minimisant la première (puisque les données qu'elle contient ne peuvent plus être 30 partagées. Il est ainsi inutile de mettre trop de données amont dans la deuxième mémoire tampon M2, a fortiori si l'on sait que ces données sont déjà dans la première mémoire tampon Ml. En exprimant ce nombre minimal de segments amont en temps de lecture, une durée entre 100s et 40s, avantageusement environ 60s (soit par exemple 3034943 12 soixante segments d'une seconde) est avantageusement choisie comme durée maximale amont. De façon le plus souvent simultanée, l'équipement 11 met en oeuvre une étape (b) de lecture par les moyens de traitement 110 (en général à la volée) 5 depuis la deuxième mémoire tampon M2 d'au moins un fragment du segment converti disposé au niveau dudit point de lecture. Le fragment lu est restitué sur une interface de sortie de l'équipement 11. Le point de lecture se décale ainsi en temps réel vers les segments amont. Cela entraîne une étape (c) de suppression de ladite deuxième mémoire 10 tampon M2 d'au moins un segment converti disposé en aval dudit point de lecture (par opposition à en amont, en d'autres termes dans les segments déjà lus), de sorte que la deuxième mémoire tampon M2 stocke un nombre maximal sm'_ de segments convertis disposés en aval d'un point de lecture dudit contenu. En effet, il n'est pas nécessaire de garder les segments convertis après lecture, à moins 15 que l'utilisateur décide d'interrompre la lecture et de revenir une poignée de secondes en arrière (par exemple si l'utilisateur a été dérangé par un bruit). Dans la suite de la présente description, on parle de segments aval pour désigner ces segments convertis disposés en aval du point de lecture. Un temps maximal de 30s, voire 20s, voire même lOs de segments aval est largement suffisant. Il n'est 20 pas nécessaire qu'il y ait un nombre minimal de segments aval. Cela permet de minimiser encore la taille de la deuxième mémoire tampon M2 de sorte à maximiser les performances de l'équipement 11. Par ailleurs le segment brut associé (au segment converti supprimé) est conservé temporairement dans la première mémoire tampon Ml, de sorte à garder le 25 maximum de données dans celle-ci. De façon générale, on comprendra que les moyens de traitement de données de l'équipement 110 sont avantageusement configurés pour maximiser le nombre de segments bruts stockés dans la première mémoire tampon Ml. A titre d'exemple, dans le cas de la VOD on peut garder entre 100 et 150 Mo de contenu 30 dans la première mémoire tampon Ml. Cela correspond à environ 15-20 mn de contenu à 1Mbit/s (un débit assez standard dans la vidéo en ligne). Les débits les plus élevés sont couramment de 3.5Mbit/s pour un site qui propose de la haute définition, voire supérieurs à 12-15 Mbit/s pour des contenus en « 4K» (Ultra haute définition), et les débits sont nécessairement beaucoup plus élevés (>12-15 35 Mbit/s avec les encodages actuels). 3034943 13 Pour le Live streaming, le contenu existant à chaque instant est assez court du fait du roulement et on stocke beaucoup moins de segments bruts dans la première mémoire cache M1 (20Mo environ), mais cette taille va probablement augmenter pour les débits élevés (environ 50Mo, et même repasser sur une taille 5 de première mémoire tampon M1 comparable à celle qu'on peut avoir en VOD pour le DVR). Récurrence 10 En référence aux figures 3a et 3b, les étapes (a) et (c) sont chacune répétées à intervalles réguliers. Plus précisément, on met en oeuvre à intervalles réguliers des tests sur les nombres de segments convertis amont et aval de sorte à vérifier si on est dans les intervalles prédéterminés. Dans le cas négatif on met en oeuvre l'étape (a) et/ou l'étape (c). Plus concrètement, le procédé comprend : 15 La première vérification à une première périodicité que la deuxième mémoire tampon M2 stocke un nombre supérieur au nombre minimal de segments convertis disposés en amont dudit point de lecture ; et/ou La deuxième vérification à une deuxième périodicité que la deuxième mémoire tampon M2 stocke un nombre inférieur audit nombre maximal 20 de segments convertis disposés en aval dudit point de lecture. En d'autres termes, la première vérification consiste en la vérification de la présence dans la deuxième mémoire tampon M2 d'un nombre acceptable de segments convertis amont, et la deuxième vérification consiste en la vérification de la présence d'un nombre acceptable dans la deuxième mémoire tampon M2 de 25 segments aval. Le procédé comprend ainsi la mise en oeuvre de l'étape (a) en cas de résultat négatif de la première vérification (i.e. s'il n'y a pas assez de segments amont), et la mise en oeuvre de l'étape (c) en cas de résultat négatif de la deuxième vérification (i.e. s'il y a trop de segments aval). Ainsi, les étapes (a) et (c) sont mise en oeuvre de façon plus ou moins régulière en fonction des résultats des 30 tests. On note que si la deuxième vérification révèle que la deuxième mémoire tampon M2 stocke un nombre supérieur au nombre maximal de segments convertis disposés en amont dudit point de lecture, alors justement les moyens de traitement de données 110 bloquent la mise en oeuvre de l'étape (a) tant que cet excès de segments ne s'est pas résorbés. Ce sera en effet naturellement le cas 35 dès le point de lecture aura avancé suite à la progression de la lecture. 3034943 14 On considèrera l'étape (b) comme mise en oeuvre en continu de sorte à ce que la lecture ne soit jamais interrompue, pour le confort de l'utilisateur. La figure 3a montre le cas de l'étape (a), c'est-à-dire de la première vérification, qui est avantageusement mise en oeuvre à une première périodicité 5 d'environ toutes les 100ms (i.e. la première vérification est mise en oeuvre environ dix fois par seconde). Si il manque un segment dans la deuxième mémoire tampon M2, les moyens de traitement de données 110 vérifient si le segment est dans la première mémoire tampon Ml, et le cas échéant met en oeuvre l'étape (a). Sinon, le segment est préalablement tout ou partiellement récupéré depuis le serveur de 10 contenu 2. Un test de « hash » est mis en oeuvre le cas échéant (si le segment vient tout ou partiellement du réseau pair-à-pair 10) pour vérifier l'intégrité d'un segment brut avant de le convertir. La figure 3b montre le cas de l'étape (c), c'est-à-dire de la deuxième vérification, qui est avantageusement mise en oeuvre de façon récurrente mais 15 bien plus rare que la première vérification, i.e. au moins dix fois moins souvent, voire cent fois moins souvent (en d'autres termes, la première périodicité est dix voire cent fois plus petite que la deuxième périodicité). Il est en effet important que la première vérification soit effectuée très souvent pour éviter le risque qu'il n'y ait plus de segments amont et que l'utilisateur doive patienter (ce que l'on appelle le 20 « rebuffering »), alors qu'un excès de segments aval n'a pas de conséquences fâcheuses pour l'utilisateur (outre qu'une surconsommation de mémoire). Typiquement, la deuxième périodicité est telle que la durée entre deux deuxièmes vérifications est inférieure à la durée correspondant au nombre maximal de segments convertis avals dans la deuxième mémoire tampon M2, 25 avantageusement environ égale, soit typiquement 10s. En effet, dans la mesure où le nombre de segments aval ne fait que croître, une périodicité trop faible de la deuxième vérification ferait que les segments avals de la deuxième mémoire M2 ne seraient pas suffisamment souvent purgés et que leur nombre serait en moyenne bien supérieur à la valeur maximale acceptable. Au contraire une 30 fréquence trop élevée de la deuxième vérification ne sert à rien et consomme des ressources des moyens de traitement de données 11. La première et/ou la deuxième vérification sont par ailleurs mises en oeuvre pour chaque « intervalle », c'est-à-dire comme expliqué chaque sous-séquence continue de segments. 3034943 15 Si le point de lecture n'est pas dans cet intervalle, c'est qu'il s'agit d'un intervalle mort (dont l'existence est par exemple causée soit par un retour manuel de la part de l'utilisateur à un point passé et distant du contenu, pour revoir un détail particulier, soit à un saut dans le futur, entraînant la récupération depuis la 5 première mémoire tampon M1 des segments associés puisque la périodicité de la première vérification est très inférieure à celle de la deuxième vérification), l'ensemble des segments convertis de ce dernier sont ainsi avantageusement supprimés de la deuxième mémoire tampon M2. Si le point de lecture est dans cet intervalle (intervalle « actif » tel que 10 l'intervalle visible sur la figure 2), alors on met en oeuvre l'étape (c), et ainsi sont supprimés les segments convertis les plus anciens de telle sorte que la que la deuxième mémoire tampon M2 stocke un nombre maximal de segments convertis disposés en aval d'un point de lecture dudit contenu. 15 Equipement et produit programme d'ordinateur Selon un deuxième aspect, l'invention concerne l'équipement client 11 pour la mise en oeuvre du présent procédé de lecture d'un contenu. Cet équipement 11 comprend comme expliqué : 20 Une première mémoire tampon M1 stockant de façon temporaire au moins un segment brut d'un contenu constitué d'une séquence de segments, chaque segment brut étant dans un format adapté pour le transfert au sein du réseau pair-à-pair 10 (et avantageusement inadapté pour la lecture sur l'équipement 11) ; 25 Une deuxième mémoire tampon M2 stockant de façon temporaire au moins un segment converti dudit contenu, chaque segment converti correspondant à un segment brut converti dans un format adapté pour la lecture sur l'équipement 11 (et en particulier inadapté pour le transfert au sein du réseau pair-à-pair 10) ; et 30 des moyens de traitement de données 110. Les moyens de traitement de données 110, typiquement un processeur, sont configuré par la mise en oeuvre de : o un module de conversion d'un segment brut de la première mémoire tampon Ml, et de stockage dudit segment converti 35 dans la deuxième mémoire tampon M2; 3034943 16 o un module de lecture depuis la deuxième mémoire tampon M2 d'au moins un fragment d'un segment converti disposé au niveau d'un point de lecture dudit contenu ; o un module de suppression de ladite deuxième mémoire tampon 5 M2 d'au moins un segment converti disposé en aval dudit point de lecture, les modules de conversion et de suppression étant configurés de sorte que la deuxième mémoire tampon M2 stocke comme expliqué un nombre compris entre un nombre minimal et un nombre maximal de segments convertis disposés en 10 amont dudit point de lecture, et un nombre inférieur ou égal à un nombre maximal de segments convertis disposés en aval dudit point de lecture. Selon d'autres aspects aspect, l'invention concerne un produit programme d'ordinateur comprenant des instructions de code pour l'exécution (sur des 15 moyens de traitement de données, en particulier ceux de l'équipement client 11) d'un procédé selon le premier aspect de l'invention de lecture en continu sur un équipement client 11 d'un contenu diffusé au sein d'un réseau pair à pair 10 d'équipements clients 11, 12, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple une mémoire de cet équipement client 11) 20 sur lequel on trouve ce produit programme d'ordinateur. REVENDICATIONS1. Procédé de lecture en continu sur un équipement client (11) d'un contenu diffusé au sein d'un réseau pair à pair (10) d'équipements clients (11, 12), ledit contenu étant constitué d'une séquence de segments, l'équipement client (11) comprenant une première mémoire tampon (M1) stockant de façon temporaire au moins un segment brut dudit contenu, chaque segment brut étant dans un format adapté pour le transfert au sein du réseau pair-à-pair (10), le procédé étant caractérisé en ce qu'il comprend la mise en oeuvre par des moyens de traitement de données (110) de l'équipement (11) d'étapes de : (a) Conversion dans un format adapté pour la lecture sur l'équipement (11) d'au moins un segment brut de la première mémoire tampon (M1), et stockage dudit segment converti dans une deuxième mémoire tampon (M2) de l'équipement (11), de sorte que la deuxième mémoire tampon (M2) stocke un nombre compris entre un nombre minimal et un nombre maximal de segments convertis disposés en amont d'un point de lecture dudit contenu ; (b) Lecture depuis la deuxième mémoire tampon (M2) d'au moins un fragment du segment converti disposé au niveau dudit point de lecture ; (c) Suppression de ladite deuxième mémoire tampon (M2) d'au moins un segment converti disposé en aval dudit point de lecture, de sorte que la deuxième mémoire tampon (M2) stocke un nombre inférieur ou égal à un nombre maximal de segments convertis disposés en aval d'un point de lecture dudit contenu, le segment brut associé étant conservé temporairement dans la première mémoire tampon (M1). 2. Procédé selon la revendication 1, dans lequel l'étape (a) comprend la requête préalable dudit segment brut auprès des autres équipements clients (12) du réseau pair à pair (10). 3. Procédé selon la revendication 2, dans lequel l'étape (a) comprend la réception dudit segment brut depuis un serveur de contenu (2) connecté au réseau pair-à-pair (10) s'il n'a pas pu être récupéré intégralement depuis un autre équipement (12) du réseau pair-à-pair (10). 3034943 18 4. Procédé selon l'une des revendications 1 à 3, dans lequel ledit format des segments bruts n'est pas adapté pour la lecture sur l'équipement (11), et ledit format des segments converti n'est pas adapté pour le transfert au 5 sein du réseau pair-à-pair (10). 5. Procédé selon la revendication 4, dans lequel les segments bruts sont encapsulés en Javascript, et les segments convertis sont encapsulés dans un lecteur via une balise vidéo HTML5 ou un module Flash. 10 6. Procédé selon l'une des revendications 1 à 5, dans lequel le nombre minimal et le nombre maximal de segments convertis disposés en amont d'un point de lecture dudit contenu sont tels que la deuxième mémoire tampon (M2) contient entre 5 et 100 secondes, de préférence entre 15 et 60 secondes, de 15 segments amont. 7. Procédé selon l'une des revendications 1 à 6, dans lequel le nombre maximal de segments convertis disposés en aval d'un point de lecture dudit contenu est tel que la deuxième mémoire tampon (M2) contient moins de 30 20 secondes, de préférence moins de 20 secondes, de préférence moins de 10 secondes, de segments aval. 8. Procédé selon l'une des revendications 1 à 7, comprenant : La première vérification à une première périodicité que la deuxième 25 mémoire tampon (M2) stocke un nombre supérieur audit nombre minimal de segments convertis disposés en amont dudit point de lecture ; et/ou La deuxième vérification à une deuxième périodicité que la deuxième mémoire tampon (M2) stocke un nombre inférieur audit nombre 30 maximal de segments convertis disposés en aval dudit point de lecture ; Le procédé comprenant la mise en oeuvre de l'étape (a) en cas de résultat négatif de la première vérification, et la mise en oeuvre de l'étape (c) en cas de résultat négatif de la deuxième vérification. 3034943 19 9. Procédé selon la revendication 8, dans lequel la première périodicité est au moins dix fois supérieure à la deuxième périodicité. 10. Procédé selon l'une des revendications 8 et 9, dans lequel la 5 deuxième périodicité est telle que l'intervalle temporel entre deux mises en oeuvre de la deuxième vérification est inférieure à la durée de contenu correspondant au nombre maximal de segments aval stockés dans la deuxième mémoire tampon (M2). 10 11. Procédé selon l'une des revendications 1 à 10, dans lequel les moyens de traitement de données de l'équipement (110) sont configurés pour maximiser le nombre de segments bruts stockés dans la première mémoire tampon (M1). 15 12. Equipement client (11) d'un réseau pair à pair (10) d'équipements clients (11, 12), caractérisé en ce qu'il comprend Une première mémoire tampon (M1) stockant de façon temporaire au moins un segment brut d'un contenu constitué d'une séquence de segments, chaque segment brut étant dans un format adapté pour le 20 transfert au sein du réseau pair-à-pair (10) ; Une deuxième mémoire tampon (M2) stockant de façon temporaire au moins un segment converti dudit contenu, chaque segment converti correspondant à un segment brut converti dans un format adapté pour la lecture sur l'équipement (11) ; 25 des moyens de traitement de données (110) configurés par la mise en oeuvre de : o un module de conversion d'un segment brut de la première mémoire tampon (M1), et de stockage dudit segment converti dans la deuxième mémoire tampon (M2) ; 30 o un module de lecture depuis la deuxième mémoire tampon (M2) d'au moins un fragment d'un segment converti disposé au niveau d'un point de lecture dudit contenu ; o un module de suppression de ladite deuxième mémoire tampon (M2) d'au moins un segment converti disposé en aval dudit point 35 de lecture, 3034943 20 les modules de conversion et de suppression étant configurés de sorte que la deuxième mémoire tampon (M2) stocke un nombre compris entre un nombre minimal et un nombre maximal de segments convertis disposés en amont dudit point de lecture, et un nombre inférieur ou égal à un nombre maximal de segments 5 convertis disposés en aval dudit point de lecture. 13. Produit programme d'ordinateur comprenant des instructions de code pour l'exécution d'un procédé selon l'une des revendications 1 à 11 de lecture en continu sur un équipement client (11) d'un contenu diffusé au sein d'un 10 réseau pair à pair (10) d'équipements clients (11, 12), lorsque ledit programme est exécuté sur un ordinateur. 14. Moyen de stockage lisible par un équipement informatique sur lequel un produit programme d'ordinateur comprend des instructions de code 15 pour l'exécution d'un procédé selon l'une des revendications 1 à 11 de lecture en continu sur un équipement client (11) d'un contenu diffusé au sein d'un réseau pair à pair (10) d'équipements clients (11, 12).