FR3034943A1 - Procede de lecture en continu sur un equipement client d'un contenu diffuse au sein d'un reseau pair a pair - Google Patents

Procede de lecture en continu sur un equipement client d'un contenu diffuse au sein d'un reseau pair a pair Download PDF

Info

Publication number
FR3034943A1
FR3034943A1 FR1552976A FR1552976A FR3034943A1 FR 3034943 A1 FR3034943 A1 FR 3034943A1 FR 1552976 A FR1552976 A FR 1552976A FR 1552976 A FR1552976 A FR 1552976A FR 3034943 A1 FR3034943 A1 FR 3034943A1
Authority
FR
France
Prior art keywords
segments
buffer memory
converted
segment
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1552976A
Other languages
English (en)
Other versions
FR3034943B1 (fr
Inventor
Axel Delmas
Nikolay Rodionov
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Streamroot Inc
Original Assignee
Streamroot Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Streamroot Inc filed Critical Streamroot Inc
Priority to FR1552976A priority Critical patent/FR3034943B1/fr
Priority to EP16721873.4A priority patent/EP3281411A1/fr
Priority to PCT/FR2016/050797 priority patent/WO2016162639A1/fr
Priority to US15/564,392 priority patent/US10341035B2/en
Publication of FR3034943A1 publication Critical patent/FR3034943A1/fr
Application granted granted Critical
Publication of FR3034943B1 publication Critical patent/FR3034943B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/02—Arrangements for relaying broadcast information
    • H04H20/08—Arrangements for relaying broadcast information among terminal devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23113—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion involving housekeeping operations for stored content, e.g. prioritizing content for deletion because of storage space restrictions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/433—Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4335—Housekeeping operations, e.g. prioritizing content for deletion because of storage space restrictions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/632—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing using a connection between clients on a wide area network, e.g. setting up a peer-to-peer communication via Internet for retrieving video segments from the hard-disk of other client devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention concerne un 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 œuvre 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).

Description

1 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 <vidéo> 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.

Claims (14)

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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).
FR1552976A 2015-04-07 2015-04-07 Procede de lecture en continu sur un equipement client d'un contenu diffuse au sein d'un reseau pair a pair Active FR3034943B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1552976A FR3034943B1 (fr) 2015-04-07 2015-04-07 Procede de lecture en continu sur un equipement client d'un contenu diffuse au sein d'un reseau pair a pair
EP16721873.4A EP3281411A1 (fr) 2015-04-07 2016-04-07 Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair
PCT/FR2016/050797 WO2016162639A1 (fr) 2015-04-07 2016-04-07 Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair
US15/564,392 US10341035B2 (en) 2015-04-07 2016-04-07 Method for continuously playing, on a client device, a content broadcast within a peer-to-peer network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1552976A FR3034943B1 (fr) 2015-04-07 2015-04-07 Procede de lecture en continu sur un equipement client d'un contenu diffuse au sein d'un reseau pair a pair

Publications (2)

Publication Number Publication Date
FR3034943A1 true FR3034943A1 (fr) 2016-10-14
FR3034943B1 FR3034943B1 (fr) 2017-04-14

Family

ID=54783686

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1552976A Active FR3034943B1 (fr) 2015-04-07 2015-04-07 Procede de lecture en continu sur un equipement client d'un contenu diffuse au sein d'un reseau pair a pair

Country Status (4)

Country Link
US (1) US10341035B2 (fr)
EP (1) EP3281411A1 (fr)
FR (1) FR3034943B1 (fr)
WO (1) WO2016162639A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6725742B2 (ja) * 2017-02-24 2020-07-22 株式会社日立製作所 ファイルストレージ、オブジェクトストレージ、およびストレージシステム
FR3094597B1 (fr) * 2019-03-27 2021-06-11 Streamroot Procédé de diffusion de contenus en streaming dans un réseau pair à pair
CN110213604B (zh) * 2019-05-27 2021-08-20 北京奇艺世纪科技有限公司 直播视频的共享方法、系统和装置及计算机可读存储介质
EP3873097A1 (fr) 2020-02-28 2021-09-01 Streamroot Procédé de lecture d'un contenu diffusé dans un réseau sur le lecteur d'un dispositif client
EP3886451A1 (fr) * 2020-03-26 2021-09-29 Streamroot Procédé de lecture d'un contenu diffusé dans un réseau sur le lecteur d'un dispositif client
EP4016954B1 (fr) * 2020-12-18 2023-12-20 Streamroot Procédé pour commander une lecture de lecteur d'un flux de données en continu dans un réseau de poste à poste
US11818189B2 (en) * 2021-01-06 2023-11-14 Tencent America LLC Method and apparatus for media streaming

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006021909A1 (fr) * 2004-08-27 2006-03-02 Koninklijke Philips Electronics N.V. Methode de distribution de contenu multimedia
US20130044260A1 (en) * 2011-08-16 2013-02-21 Steven Erik VESTERGAARD Script-based video rendering
US20140019593A1 (en) * 2012-07-10 2014-01-16 Vid Scale, Inc. Quality-driven streaming

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8644674B2 (en) * 2012-06-01 2014-02-04 Limelight Networks, Inc. Control layer indexed playback
US8037506B2 (en) * 2006-03-03 2011-10-11 Verimatrix, Inc. Movie studio-based network distribution system and method
US20080256255A1 (en) * 2007-04-11 2008-10-16 Metro Enterprises, Inc. Process for streaming media data in a peer-to-peer network
US20090150480A1 (en) * 2007-12-08 2009-06-11 Xiyuan Xia Publishing Assets Of Dynamic Nature In UPnP Networks
CA2824751A1 (fr) * 2009-09-26 2011-03-31 Disternet Technology Inc. Systeme et procede de calcul informatise en micronuage
US9532092B1 (en) * 2009-12-30 2016-12-27 Akamai Technologies, Inc. Multiple bitrate format-agnostic streaming architecture
US8423606B1 (en) * 2010-04-27 2013-04-16 Adobe Systems Incorporated Data framing
US8918533B2 (en) * 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
FR2963523B1 (fr) * 2010-07-29 2012-09-07 Myriad France Telephone mobile comprenant un serveur de diffusion en flux avec des moyens d'activation du telechargement d'un fichier en vue de sa diffusion
FR2963525B1 (fr) * 2010-07-29 2012-09-07 Myriad France Telephone mobile comprenant un serveur de diffusion en flux avec des moyens de commande de la transformation d'un fichier avant sa diffusion
US8554938B2 (en) * 2010-08-31 2013-10-08 Millind Mittal Web browser proxy-client video system and method
WO2012030178A2 (fr) * 2010-09-01 2012-03-08 한국전자통신연구원 Procédé et dispositif pour fournir un flux de données de contenu
EP2614653A4 (fr) * 2010-09-10 2015-04-15 Nokia Corp Procédé et appareil de diffusion en continu adaptative
US20120265853A1 (en) * 2010-12-17 2012-10-18 Akamai Technologies, Inc. Format-agnostic streaming architecture using an http network for streaming
US9276997B2 (en) * 2011-01-14 2016-03-01 Millind Mittal Web browser proxy—client video system and method
JP2012151849A (ja) * 2011-01-19 2012-08-09 Nhn Business Platform Corp Ｐ２ｐ基盤のストリーミングサービスのデータストリームをパケット化するシステムおよび方法
US8464304B2 (en) * 2011-01-25 2013-06-11 Youtoo Technologies, LLC Content creation and distribution system
US20130031211A1 (en) * 2011-01-29 2013-01-31 Dustin Johnson Feedback oriented private overlay network for content distribution
KR102029326B1 (ko) 2011-02-28 2019-11-29 비트토렌트, 인크. 피어-투-피어 라이브 스트리밍
US8489760B2 (en) * 2011-03-31 2013-07-16 Juniper Networks, Inc. Media file storage format and adaptive delivery system
US9066115B1 (en) * 2011-07-29 2015-06-23 Arris Enterprises, Inc. Structuring dynamic advertisement breaks in video manifest files
CN103002274B (zh) * 2011-09-16 2016-05-18 腾讯科技（深圳）有限公司 一种基于离线下载的移动多媒体实时转码播放系统及方法
US9124947B2 (en) * 2013-09-04 2015-09-01 Arris Enterprises, Inc. Averting ad skipping in adaptive bit rate systems
US9244916B2 (en) * 2013-10-01 2016-01-26 Penthera Partners, Inc. Downloading media objects
EP3140994B1 (fr) * 2014-05-06 2022-03-16 TiVo Solutions Inc. Gestion de contenu multimédia en nuage
US10019517B2 (en) * 2014-05-06 2018-07-10 Tivo Solutions Inc. Managing media content upload groups
US9692800B2 (en) * 2014-06-11 2017-06-27 Google Inc. Enhanced streaming media playback
WO2015200613A1 (fr) * 2014-06-26 2015-12-30 Arris Enterprises, Inc. Commande adaptative de débit binaire côté serveur pour clients de lecture en flux continu http
US9894130B2 (en) * 2014-09-23 2018-02-13 Intel Corporation Video quality enhancement
US9578395B1 (en) * 2014-09-30 2017-02-21 Amazon Technologies, Inc. Embedded manifests for content streaming
US9838760B2 (en) * 2014-12-16 2017-12-05 Arizona Board Of Regents On Behalf Of Arizona State University Systems and methods for name-based segmented media acquisition and distribution framework on a network
US9769536B2 (en) * 2014-12-26 2017-09-19 System73, Inc. Method and system for adaptive virtual broadcasting of digital content

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006021909A1 (fr) * 2004-08-27 2006-03-02 Koninklijke Philips Electronics N.V. Methode de distribution de contenu multimedia
US20130044260A1 (en) * 2011-08-16 2013-02-21 Steven Erik VESTERGAARD Script-based video rendering
US20140019593A1 (en) * 2012-07-10 2014-01-16 Vid Scale, Inc. Quality-driven streaming

Also Published As

Publication number Publication date
WO2016162639A1 (fr) 2016-10-13
US20180138998A1 (en) 2018-05-17
EP3281411A1 (fr) 2018-02-14
US10341035B2 (en) 2019-07-02
FR3034943B1 (fr) 2017-04-14

Similar Documents

Publication Publication Date Title
FR3034943A1 (fr) Procede de lecture en continu sur un equipement client d&#39;un contenu diffuse au sein d&#39;un reseau pair a pair
WO2020193754A1 (fr) Procédé de diffusion de contenus en streaming dans un réseau pair à pair
EP3156920B1 (fr) Procédé de diffusion d&#39;un contenu dans un réseau informatique
FR3023665A1 (fr) Procede et dispositif d&#39;enregistrement a distance de programmes video.
EP2332332A1 (fr) Procede et dispositif de redirection d&#39;une requete de controle d&#39;un flux de donnees
EP2856719B1 (fr) Technique de communication dans un réseau de communication centré sur les informations
EP1617591A1 (fr) Procédé et serveur de référencement de diffusion poste à poste de fichiers demandés par téléchargement à ce serveur
FR3067544A1 (fr) Procede et dispositif de telechargement de contenu audiovisuel
EP3205067B1 (fr) Diffusion de contenus en streaming dans un réseau pair à pair
FR3005386A1 (fr) Procede et dispositif de fourniture d’une partie deja diffusee d’un flux multimedia, terminal utilisateur, programme d’ordinateur et medium de stockage correspondants
FR3109046A1 (fr) Procédé de gestion d’un flux audio lu de manière synchronisée sur une horloge de référence
EP3840335A1 (fr) Reception d&#39;un contenu numerique en mode truque
EP3092777B1 (fr) Procede de traitement d&#39;erreur de restitution d&#39;un contenu numerique
FR3054765A1 (fr) Procede pour la lecture sur un equipement d&#39;un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
FR3138020A1 (fr) Streaming vidéo adaptatif hybride amélioré
EP4184922A1 (fr) Procédé de gestion de l&#39; accès à un contenu multimédia
FR3079099A1 (fr) Procede de diffusion d&#39;un contenu
WO2016110583A1 (fr) Procede de gestion et de fonctionnement protocolaire d&#39;un reseau de distribution de contenu
EP2604019B1 (fr) Procédé pour ralentir, voire éliminer, la propagation illégale d&#39;un contenu vidéo protégé et diffusé en streaming dans un réseau pair à pair
FR3019429A1 (fr) Procede et dispositif de controle d&#39;un telechargement de contenus multimedia
EP3973714A1 (fr) Restitution d&#39;un contenu en arrière-plan ou sous forme d&#39;incrustation dans le cadre d&#39;un téléchargement progressif adaptatif de type has
EP2553900B1 (fr) Transmission de flux de données adaptable
FR3124672A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu numérique en mode économiseur d’écran
FR3093605A1 (fr) Procédé de navigation accélérée dans un contenu numérique obtenu par téléchargement progressif adaptatif (HAS), gestionnaire, lecteur de flux multimédia et programme d’ordinateur correspondants.
FR3079705A1 (fr) Communication par video conference

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20161014

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9