EP3281411A1 - Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair - Google Patents

Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair

Info

Publication number
EP3281411A1
EP3281411A1 EP16721873.4A EP16721873A EP3281411A1 EP 3281411 A1 EP3281411 A1 EP 3281411A1 EP 16721873 A EP16721873 A EP 16721873A EP 3281411 A1 EP3281411 A1 EP 3281411A1
Authority
EP
European Patent Office
Prior art keywords
segments
converted
buffer memory
segment
peer
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.)
Withdrawn
Application number
EP16721873.4A
Other languages
German (de)
English (en)
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
Publication of EP3281411A1 publication Critical patent/EP3281411A1/fr
Withdrawn legal-status Critical Current

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

Definitions

  • the present invention relates to streaming.
  • Streaming refers to a technique for reading a "live” audio or video stream, that is, as it is retrieved from the Internet. by a customer equipment. It is opposed to downloading, which requires the recovery of all data from the audio or video content before you can read it.
  • the storage of the content is temporary and partial, the data being downloaded continuously to a buffer of the client (typically RAM), analyzed on the fly by its processor and quickly transferred to an output interface ( screen and / or speakers) and replaced by new data.
  • a buffer of the client typically RAM
  • an output interface screen and / or speakers
  • the content is made available on a streaming server.
  • the client wishing to access it sends a request to retrieve the first segments (segment is a block of data content, usually corresponding to a few seconds of reading).
  • segment is a block of data content, usually corresponding to a few seconds of reading.
  • playback starts.
  • the stream download continues to continuously feed the buffer with the rest of the content.
  • P2P peer-to-peer
  • each client acts as a server for other clients: we talk about peers.
  • a peer who has started reading the content will retransmit to others the segments he has already received, and so on, hence a facility regardless of the number of interested customers.
  • This strategy is described in the international application WO 2012/154287.
  • the segments converted into video streams fill a buffer (a buffer) video for reading. So we end up having to store the data twice, which can quickly saturate the cache, and cause slowdowns and inconvenience for the user. This is even more problematic in the case of VOD, "Video On Demand” ie video on demand, or video delayed (as opposed to “live streaming” which will be described later), in which it It is desirable to maximize the size of the P2P cache so as to increase the chances that the caches of two peers overlap and that exchanges are possible.
  • the present invention improves the situation by providing an innovative P2P streaming data management method, in particular VOD, which is optimal in terms of the efficiency of the content broadcast, the congestion of the peer buffers, and the simplicity algorithmic.
  • the present invention thus relates to a method of continuously reading on a client equipment a content broadcast within a peer-to-peer network of client equipment, said content consisting of a sequence of segments, the equipment client comprising a first buffer store temporarily storing at least one raw segment of said content, each raw segment being in a format adapted for transfer within the peer-to-peer network, the method being characterized in that it comprises the implemented by data processing means of the equipment of steps of:
  • Step (a) comprises the prior request of said raw segment to the other peer-to-peer network client equipment
  • Step (a) comprises receiving said raw segment from a content server connected to the peer-to-peer network if it could not be fully recovered from another peer-to-peer network equipment;
  • Said raw segment format is not adapted for reading on the equipment, and said converted segment format is not adapted for transfer within the peer-to-peer network;
  • the raw segments are encapsulated in Javascript, and the converted segments are encapsulated in a player via an HTML5 video tag or a Flash module;
  • the minimum number and the maximum number of converted segments arranged upstream of a reading point of said content are such that the second buffer memory contains between 5 and 100 seconds, preferably between 15 and 60 seconds, of upstream segments;
  • the maximum number of converted segments disposed downstream of a reading point of said content is such that the second buffer memory contains less than 30 seconds, preferably less than 20 seconds, preferably less than 10 seconds, of downstream segments;
  • the method comprises:
  • the method comprising the implementation of step (a) in case of a negative result of the first verification, and the implementation of step (c) in the event of a negative result of the second verification;
  • the first periodicity is at least ten times higher than the second periodicity
  • the second periodicity is such that the time interval between two implementations of the second verification is less than the content duration corresponding to the maximum number of downstream segments stored in the second buffer memory
  • the data processing means of the equipment are configured to maximize the number of raw segments stored in the first buffer memory.
  • a client equipment of a peer-to-peer network of client equipment is proposed, characterized in that it comprises
  • a first buffer store temporarily storing at least one raw segment of a content consisting of a sequence of segments, each raw segment being in a format adapted for transfer within the peer-to-peer network;
  • a second buffer store temporarily storing at least one converted segment of said content, each converted segment corresponding to a raw segment converted into a format adapted for reading on the equipment; data processing means configured by the implementation of:
  • a module for converting a raw segment of the first buffer memory, and for storing said converted segment in the second buffer memory
  • a read module from the second buffer memory of at least one fragment of a converted segment disposed at a reading point of said content
  • a module for deleting said second buffer memory from at least one converted segment disposed downstream of said reading point the conversion and deletion modules being configured so that the second buffer memory stores a number between a minimum number and a maximum number of converted segments disposed upstream of said reading point, and a number less than or equal to a maximum number of converted segments disposed downstream of said read point.
  • the invention relates respectively to a computer program product comprising code instructions for the execution of a method according to the first aspect of the invention for continuously reading on a client equipment a content broadcast within a peer-to-peer network of client equipment, when said program is executed on a computer; and computer-readable storage means on which a computer program product comprises code instructions for executing a method according to the first aspect of the invention for streaming on a client equipment of a content distributed within a peer-to-peer network of client equipment.
  • FIG. 1 represents an architecture for implementing the method according to the invention
  • FIG. 2 illustrates an example of use of buffers in an embodiment of the method according to the invention
  • Figures 3a and 3b are flow charts respectively illustrating a preferred embodiment of steps (a) and (c) of the method according to the invention.
  • Network 1 is here a large-scale telecommunications network and in particular the Internet.
  • This network 1 comprises a peer-to-peer network 10 of client equipment 1 1, 12.
  • Each client equipment 1 1, 12 is typically a personal computer equipment such as a smartphone, a PC, a tablet, etc.
  • the network 1 having data processing means 1 10 such as a processor, an interface for reading the content, and having two buffers M1 and M2 (also called “buffer"), typically two zones a random access memory, each of which can store (in a different manner as we will see) all or part of the content temporarily (temporarily, it is understood that the segments are deleted from this memory shortly after they have been read: they are not stored in the long term as is the case for a direct download). As it will be seen later, in the preferred case of reading via a browser, all the segments are typically deleted (ie the buffers reset) at the latest when closing the browser or the tab in which the video is played.
  • data processing means 1 10 such as a processor
  • M1 and M2 also called “buffer”
  • the first buffer M1 is called "peer-to-peer cache”. It stores the segments in a "raw” format. By raw segments is meant in a format adapted for transfer within the peer-to-peer network 10 (we will see how later), but unsuitable for reading on the equipment 1 1.
  • the second buffer memory M2 is called "video buffer”. It stores the segments in a format called “converted”. By converted segments is meant converted from raw segments in a format suitable for reading on the equipment 1 1, but unsuitable for transfer within the peer-to-peer network 10.
  • the equipment 1 1, 12 are “peers” (also called “nodes") of the peer-to-peer network 10.
  • customer equipment 1 1, 12 of a peer-to-peer network 10 is meant equipment connected in the network 1 by a peer-to-peer network protocol.
  • client software can for example be integrated with a web browser, a mobile application, or any other embedded software (for example a player of an internet access box or a multimedia box, ie a "Set-top box”), for the use of peer-to-peer.
  • a peer-to-peer network is a decentralized subnet within network 1, in which data can be transferred directly between two client devices 1 1, 12 of the network 10, without passing through a central server. It allows all client devices 1 1, 12 to play both the role of client and server.
  • the peers 1 1, 12 are thus defined as "seeders” (in French “sowers”, that is to say data providers) and / or “leechers” (in French “leechers", c that is, data receivers).
  • Said content which is in particular audio or video content, that is to say a medium of a certain duration, consists of a sequence of segments (called “list of read “in English” playlist ”) stored on data storage means of a server 2 connected to the peer-to-peer network 10.
  • the segments have a predetermined length, typically one or two seconds of the content, but it can go from a fraction of a second to ten seconds. All segments of a given content are generally the same length.
  • the server 2 is a content server, advantageously present in the network 1 and connected to the peer-to-peer network 10.
  • it is one (or more) servers of the Internet network 1 setting up provision segments of various contents according to a given streaming protocol.
  • HLS HTTP Live Streaming
  • the segments are "ts" files, listed in a "m3u8" playlist file.
  • HLS involves the MPEG2 format for the content.
  • DASH Smooth streaming
  • HDS high-Res streaming protocol
  • the raw segments are encapsulated for example in JavaScript, so as to allow peer exchange of these segments via a WebRTC type API.
  • Server 2 is the primary source of the segments, since initially no peer has the content (before a first transfer from server 2 to this peer 1 1, 12).
  • the contents are either originally stored in their entirety on the server 2 (case of the aforementioned VOD), or generated in real time (case of live streaming, or live streaming), and in the latter case the list of segments that constitutes them evolves dynamically.
  • Live Streaming offers real-time broadcasting of content related to "live” events, such as concerts, conferences, sports parts of video games, etc., which are going on simultaneously.
  • a content broadcast in live streaming is indeed generated as the associated event unfolds.
  • Such content can be broadcast with a slight delay, that the user wants the lowest possible. This delay is typically of the order of one minute, but can go down to about twenty seconds.
  • the sequence of segments is thus dynamic, that is to say that it is set to day regularly. Whenever a new segment is generated it is added at the end of the sequence, and the first segment of the (oldest) sequence is deleted. All others shift according to a rolling mechanism that can be related to a FIFO list.
  • the first (oldest) segment of the list can be the one at the play point, in other words the "live” segment (and thus the segments are removed from the playlist as soon as they are read ), or a segment "passed” if the content server agrees to read the content with delay (some platforms offer live streaming with up to 2 hours late), this is called the DVR ("Digital video recorder").
  • the present method is implemented in a context of VOD or DVR.
  • the tracker 3 presents data processing means and storage means. It coordinates the exchanges between peers 1 1, 12 (by controlling the client software implemented by each of the client equipment 1 1, 12), but it is not directly involved in the data transfer and does not have a copy of the file.
  • the tracker 3 receives (on request or push) from the server 2 a "manifest" file for each of the contents.
  • This manifest file is a description of the content (in XML format for most streaming protocols except HLS), and contains the list of segments.
  • the tracker 3 analyzes the manifest (parsing, i.e. parsing) so as to extract the list of segments.
  • the manifest is usually replayed at regular intervals so as to allow the playlist to be updated (remember that as the content is constantly being generated live new segments enter the playlist and others leave it when they have become too old and have passed the point of reading).
  • a skeleton of manifest (ie without the list of segments) is provided along with temporal indications (including a time stamp, in English "timestamp") making it possible to determine when each new segment is sent, which allows the tracker 3 (and the client equipment 1 1, 12) to complete this skeleton and update it on its own.
  • the tracker 3 For each manifest (obtained complete or whose playlist has been automatically completed), the tracker 3 performs a "hash", that is to say implements a hash function so as to obtain an imprint of the manifest, which constitutes a signature of the content to which the manifest is associated. It should be noted that the hash can be implemented on the address of the manifest (its URL, "Uniform Resource Locator"), which is interesting since a URL remains constant even if the manifest changes regularly (because of the live streaming ).
  • the focus is on a client device 11 that is, if necessary, retrieving the content from other equipment 12 and / or the server 2, that is to say that the first buffer M1 already stores at least one raw segment, if possible a subsequence of the sequence constituting the content.
  • the process then begins with the implementation by the processing means 110 of the equipment of a conversion step (a) in a format adapted for reading on the equipment 11 of at least one raw segment of the first buffer M1.
  • This step consists in transforming the raw segment into a converted segment, which can be read by the reader of the equipment 1 1 unlike the first.
  • the client equipment 1 1 is typically ready to read the content continuously after a minimum period of segment preloading in the second buffer memory M2 (the preloaded segments being most often recovered in the first buffer M1 from the server 2), for example ten seconds (or ten segments of a second).
  • the reader is the integrated reader of an HTML5-compatible browser, and the conversion consists of injecting the video data of the segment using the Media Source Extension API of the browser, after which they are stored in the second memory buffer M2 and are no longer accessible.
  • an ⁇ video> tag HTML5 then allows to offer controls on the integrated player (playback, pause, fast forward, etc.), in the manner of what offers a user control interface.
  • the raw version of the segment is kept in the first buffer M1 so as to still allow sharing in the network 10.
  • the present method is not limited to the use of HTML5 tag coupled to the network.
  • API Media Source Extension and that we could for example use a Flash module, see a module integrated natively in any reader.
  • the reader can be the integrated one of a mobile application (for example natively compatible Object-C, C ++, etc.). In all the cases will be the problem of the non-accessibility of the data once they have been injected into the reader.
  • the choice of the segment to be converted is such that the second buffer M2 stores a minimal number of converted segments disposed upstream of a reading point of said content.
  • upstream we mean future segments, that is to say which are arranged in the content later (from a temporal point of view) at the point of reading, ie which have not yet been read, and of preferably the s m / "+ next consecutive segments of the sequence of segments constituting the content, min + s being said minimum number of segments upstream.
  • upstream segments we speak of upstream segments to designate these converted segments disposed upstream of the reading point.
  • this minimum number of upstream segments is expressed in read time. For example, if it is defined that the second buffer must contain a minimum time of upstream segments of 15s (advantageously 10s, or even 5s in a particularly optimized management), then in the case of segments of one second the minimum number of upstream segments to be stored by the second memory is fifteen.
  • the missing segment (s) are (all or part) recovered from server 2.
  • the number of upstream segments stored by the second cache M2 also respects a maximum number s max + .
  • the number of these upstream segments is between two extremal values. The idea is to reduce the media buffer (the second buffer M2) to a reduced area around the reading point.
  • the present method proposes with reference to Figure 2 to decouple the two M1 and M2 buffers by maximizing the first (so as to facilitate exchanges within the peer-to-peer network 10 ensuring greater availability of data) and minimizing the first (since the data it contains can not In this case, it is useless to put too much upstream data in the second buffer M2, especially if we know that these data are already in the first buffer M1.
  • the equipment 1 1 implements a step (b) of reading by the processing means 1 10 (usually on the fly) from the second buffer memory M2 of at least one fragment of the segment converted disposed at said reading point.
  • the read fragment is restored on an output interface of the equipment 1 1.
  • the reading point shifts in real time to the upstream segments.
  • the associated raw segment (the deleted converted segment) is temporarily stored in the first buffer memory M1, so to keep the maximum amount of data in it.
  • the data processing means of the equipment 1 10 are advantageously configured to maximize the number of raw segments stored in the first buffer memory M1.
  • the data processing means of the equipment 1 10 are advantageously configured to maximize the number of raw segments stored in the first buffer memory M1.
  • the VOD it is possible to keep between 100 and 150 MB of content in the first buffer memory M1. This corresponds to about 15-20 min of 1 Mbps content (a fairly standard bitrate in online video).
  • the highest bit rates are commonly 3.5Mbps for a site that offers high definition, or even higher than 12-15 Mbps for "4K" (Ultra High Definition) content, and bit rates are necessarily much higher. higher (> 12-15 Mbit / s with current encodings).
  • steps (a) and (c) are each repeated at regular intervals. More specifically, tests are performed at regular intervals on the numbers of upstream and downstream converted segments so as to check if one is in the predetermined intervals.
  • step (a) and / or step (c) are implemented. More concretely, the method comprises:
  • the second check at a second periodicity that the second buffer M2 stores a number less than said maximum number of converted segments disposed downstream of said reading point.
  • the first check consists in verifying the presence in the second buffer memory M2 of an acceptable number of upstream converted segments
  • the second checking consists in checking for the presence of an acceptable number in the second buffer M2 downstream segments.
  • the method thus comprises the implementation of step (a) in the event of a negative result of the first verification (ie if there are not enough upstream segments), and the implementation of the step ( c) in case of a negative result of the second verification (ie if there are too many downstream segments).
  • steps (a) and (c) are implemented more or less regularly according to the test results.
  • the data processing means 1 10 block the implementation of the step (a) as long as this excess of segments has not resorbed. This will indeed be the case as soon as the reading point has advanced as a result of reading progress.
  • Step (b) will be considered as continuous implementation so that the reading is never interrupted for the convenience of the user.
  • FIG. 3a shows the case of step (a), that is to say of the first verification, which is advantageously implemented at a first periodicity of approximately every 100 ms (ie the first check is carried out works about ten times a second). If a segment is missing in the second buffer memory M2, the data processing means 1 10 verify whether the segment is in the first buffer memory M1, and where appropriate implements step (a). Otherwise, the segment is previously fully or partially recovered from the content server 2. A hash test is set if necessary (if the segment comes all or part of the peer-to-peer network 10) to check the integrity of a raw segment before converting it.
  • Figure 3b shows the case of step (c), that is to say of the second verification, which is advantageously implemented recurrently but much rarer than the first verification, ie at least ten times less often, a hundred times less often (in other words, the first periodicity is ten or a hundred times smaller than the second periodicity). It is indeed important that the first verification be done very often to avoid the risk of no longer upstream segments and that the user should wait (so-called "rebuffering"), while an excess of downstream segments does not have unfortunate consequences for the user (in addition to overconsumption of memory).
  • the second periodicity is such that the duration between two second checks is less than the duration corresponding to the maximum number of converted segments downstream in the second buffer M2, preferably about equal, is typically 10s. Indeed, insofar as the number of downstream segments is only growing, a too low periodicity of the second verification would make that the downstream segments of the second memory M2 would not be sufficiently often purged and that their number would be on average much higher. at the maximum acceptable value. On the contrary, a too high frequency of the second verification is useless and consumes resources of the data processing means 1 1.
  • the first and / or the second verification are also implemented for each "interval", that is to say as explained each continuous subsequence of segments.
  • the reading point is not in this range, it is because it is a dead interval (the existence of which is caused for example by a manual return from the user to a point past and distant content, to review a particular detail, or a jump in the future, resulting in recovery from the first buffer M1 associated segments since the periodicity of the first verification is much lower than that of the second verification) , all of the converted segments of the latter are thus advantageously removed from the second buffer memory M2.
  • step (c) is implemented, and thus the oldest converted segments of such so that the second buffer memory M2 stores a maximum number of converted segments disposed downstream of a reading point of said content.
  • the invention relates to the client equipment 1 1 for implementing the present method of reading a content.
  • This equipment 1 1 comprises as explained:
  • a first buffer memory M1 temporarily storing at least one raw segment of a content consisting of a sequence of segments, each raw segment being in a format adapted for the transfer within the peer-to-peer network (and advantageously unsuitable for reading on equipment 1 1);
  • a second buffer M2 temporarily storing at least one converted segment of said content, each converted segment corresponding to a raw segment converted into a format adapted for reading on the equipment 1 1 (and in particular unsuitable for the transfer within the peer-to-peer network 10); and - data processing means 1 10.
  • the data processing means 1 typically a processor, are configured by the implementation of:
  • a read module from the second buffer M2 of at least one fragment of a converted segment disposed at a reading point of said content
  • a module for deleting said second buffer memory M2 from at least one converted segment disposed downstream of said read point the conversion and deletion modules being configured so that the second buffer memory M2 stores as explained a number between a minimum number and a maximum number of converted segments disposed upstream of said reading point, and a number less than or equal to a maximum number of converted segments disposed downstream of said reading point.
  • the invention relates to a computer program product comprising code instructions for the execution (on data processing means, in particular those of the client equipment 1 1) of a method according to the first aspect of the invention for continuously reading on a client device 1 1 a content broadcast within a peer-to-peer network 10 of client equipment 1 1, 12, as well as storage means readable by a computer equipment (for example a memory of this client equipment 1 1) on which this computer program product is found.

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

Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair
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.
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 données doivent être conservées dans un format spécifique adapté (typiquement en Javascript si l'on utilise l'API WebRTC), 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é 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 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.
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. 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, 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 œuvre par des moyens de traitement de données de l'équipement d'étapes de :
(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 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 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.
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 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 ;
• 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, 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 ;
· 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
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 œuvre de l'étape (a) en cas de résultat négatif de la première vérification, et la mise en œuvre de l'étape (c) en cas de résultat 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 œuvre 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 ;
• 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.
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, 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 la lecture sur l'équipement ; - des moyens de traitement de données configurés par la mise en œuvre 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 deuxième mémoire tampon ;
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 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 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 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 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
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 œuvre du 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 l'invention.
DESCRIPTION DETAILLEE Architecture 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 1 1 , 12. Chaque équipement client 1 1 , 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 1 10 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, 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 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 comment plus tard), mais inadapté pour la lecture sur l'équipement 1 1 .
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 1 1 , mais inadapté pour le transfert au sein du réseau pair-à-pair 10.
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 manuellement le point de lecture dans la vidéo, par exemple de sorte à revenir en arrière.
Comme expliqué dans l'introduction, les équipements 1 1 , 12 sont des « pairs » (appelés également « nœuds ») du réseau pair-à-pair 10.
Par « équipements client 1 1 , 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 œuvre un programme particulier (logiciel client), qui peut être par exemple intégré à un navigateur web, une application mobile, ou tout autre logiciel embarqué (par exemple un player d'un boîtier d'accès à internet ou d'un boîtier 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 être transférées directement entre deux équipements client 1 1 , 12 du réseau 10, sans transiter par un serveur central. Il permet ainsi à tous les équipements client 1 1 , 12 de jouer à la fois le rôle de client et serveur. Les pairs 1 1 , 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 », 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 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 (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 DASH, Smooth streaming, ou HDS. Les segments bruts sont encapsulés par 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 serveur 2 vers ce pair 1 1 , 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 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 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) 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 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 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 (« enregistreur vidéo numérique »).
De façon préférée, le présent procédé est mis en œuvre dans un contexte de VOD ou de DVR.
Est également avantageusement connecté au réseau pair-à-pair 10 un 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 1 1 , 12 (en contrôlant le logiciel client mis en œuvre par chacun des équipements client 1 1 , 12), mais il n'est pas directement impliqué dans le transfert de données et ne possède pas de copie du fichier.
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. 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 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 au tracker 3 (et aux équipements clients 1 1 , 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 œuvre une fonction de hachage de sorte à obtenir une empreinte du manifeste, qui constitue une signature du contenu auquel le manifeste est associé. Il est à noter que le hash peut être mis en œuvre 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).
Lecture
Dans la suite de la présente description, on se focalise sur un équipement client 1 1 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 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 œuvre par les moyens de traitement 1 10 de l'équipement d'une étape (a) de conversion dans un format adapté pour la lecture sur l'équipement 1 1 d'au moins un segment brut de la première mémoire tampon M1 . Cette étape consiste à transformer le segment brut en un segment converti, qui pourra être lu par le lecteur de l'équipement 1 1 contrairement au premier.
L'équipement client 1 1 est typiquement prêt à lire en continu le contenu 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 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 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 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 M2 stocke un nombre minimal de segments convertis disposés en amont d'un 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 sm/„+ prochains segments consécutifs de la séquence de segments constituant le contenu, smin+ é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 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 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 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 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 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 M1 .
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 soixante segments d'une seconde) est avantageusement choisie comme durée maximale amont. De façon le plus souvent simultanée, l'équipement 1 1 met en œuvre une étape (b) de lecture par les moyens de traitement 1 10 (en général à la volée) 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 1 1 . 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 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 smax. 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 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 10s de segments aval est largement suffisant. Il n'est 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 1 1. Par ailleurs le segment brut associé (au segment converti supprimé) est conservé temporairement dans la première mémoire tampon M1 , de sorte à garder le 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 1 10 sont avantageusement configurés pour maximiser le nombre de segments bruts stockés dans la première mémoire tampon M1. A titre d'exemple, dans le cas de la VOD on peut garder entre 100 et 150 Mo de contenu dans la première mémoire tampon M1. Cela correspond à environ 15-20 mn de contenu à 1 Mbit/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 Mbit/s avec les encodages actuels).
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 de première mémoire tampon M1 comparable à celle qu'on peut avoir en VOD pour le DVR). Récurrence
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 œuvre à 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 œuvre l'étape (a) et/ou l'étape (c). Plus concrètement, le procédé comprend :
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 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 segments aval. Le procédé comprend ainsi la mise en œuvre 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 œuvre 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 œuvre de façon plus ou moins régulière en fonction des résultats des 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 1 10 bloquent la mise en œuvre 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 dès le point de lecture aura avancé suite à la progression de la lecture.
On considérera l'étape (b) comme mise en œuvre 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 œuvre à une première périodicité d'environ toutes les 100ms (i.e. la première vérification est mise en œuvre 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 1 10 vérifient si le segment est dans la première mémoire tampon M1 , et le cas échéant met en œuvre l'étape (a). Sinon, le segment est préalablement tout ou partiellement récupéré depuis le serveur de contenu 2. Un test de « hash » est mis en œuvre 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 œuvre de façon récurrente mais 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 « 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, 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 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 1 1 .
La première et/ou la deuxième vérification sont par ailleurs mises en œuvre pour chaque « intervalle », c'est-à-dire comme expliqué chaque sous-séquence continue de segments.
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 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 l'intervalle visible sur la figure 2), alors on met en œuvre 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. Equipement et produit programme d'ordinateur
Selon un deuxième aspect, l'invention concerne l'équipement client 1 1 pour la mise en œuvre du présent procédé de lecture d'un contenu.
Cet équipement 1 1 comprend comme expliqué :
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 1 1 ) ;
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 1 1 (et en particulier inadapté pour le transfert au sein du réseau pair-à-pair 10) ; et - des moyens de traitement de données 1 10.
Les moyens de traitement de données 1 10, typiquement un processeur, sont configuré par la mise en œuvre 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 ;
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 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 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 moyens de traitement de données, en particulier ceux de l'équipement client 1 1 ) d'un procédé selon le premier aspect de l'invention de lecture en continu sur un équipement client 1 1 d'un contenu diffusé au sein d'un réseau pair à pair 10 d'équipements clients 1 1 , 12, ainsi que des moyens de stockage lisibles par un équipement informatique (par exemple une mémoire de cet équipement client 1 1 ) sur lequel on trouve ce produit programme d'ordinateur.

Claims

REVENDICATIONS
1. Procédé de lecture en continu sur un équipement client (1 1 ) d'un contenu diffusé au sein d'un réseau pair à pair (10) d'équipements clients (1 1 , 12), ledit contenu étant constitué d'une séquence de segments, l'équipement client (1 1 ) 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 (1 10) de l'équipement (1 1 ) d'étapes de :
(a) Conversion dans un format adapté pour la lecture sur l'équipement (1 1 ) 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 (1 1 ), 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).
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 (1 1 ), et ledit format des segments converti n'est pas adapté pour le transfert au 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.
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 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 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 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 maximal de segments convertis disposés en aval dudit point de lecture ;
Le procédé comprenant la mise en œuvre de l'étape (a) en cas de résultat négatif de la première vérification, et la mise en œuvre de l'étape (c) en cas de résultat négatif de la deuxième vérification.
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 deuxième périodicité est telle que l'intervalle temporel entre deux mises en œuvre 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).
11. Procédé selon l'une des revendications 1 à 10, dans lequel les moyens de traitement de données de l'équipement (1 10) sont configurés pour maximiser le nombre de segments bruts stockés dans la première mémoire tampon (M1 ). 12. Equipement client (1 1 ) d'un réseau pair à pair (10) d'équipements clients (1 1 ,
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 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 (1 1 ) ;
- des moyens de traitement de données (1 10) configurés par la mise en œuvre 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) ;
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 de lecture, 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 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 à 1 1 de lecture en continu sur un équipement client (1 1 ) d'un contenu diffusé au sein d'un réseau pair à pair (10) d'équipements clients (1 1 , 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 pour l'exécution d'un procédé selon l'une des revendications 1 à 1 1 de lecture en continu sur équipement client (1 1 ) d'un contenu diffusé au sein d'un réseau pair à pair (1 d'équipements clients (1 1 , 12).
EP16721873.4A 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 Withdrawn EP3281411A1 (fr)

Applications Claiming Priority (2)

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
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

Publications (1)

Publication Number Publication Date
EP3281411A1 true EP3281411A1 (fr) 2018-02-14

Family

ID=54783686

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16721873.4A Withdrawn 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

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
WO2018154698A1 (fr) * 2017-02-24 2018-08-30 株式会社日立製作所 Stockage de fichiers, stockage d'objets et système de stockage
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

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008511233A (ja) * 2004-08-27 2008-04-10 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ マルチメディアコンテンツの配信方法
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
CA2824723A1 (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
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
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
US8554938B2 (en) * 2010-08-31 2013-10-08 Millind Mittal Web browser proxy-client video system and method
EP2613543B1 (fr) * 2010-09-01 2017-01-11 Electronics And Telecommunications Research Institute Procédé et dispositif pour fournir des contenus en utilisant un flux adaptatif http
WO2012032502A1 (fr) * 2010-09-10 2012-03-15 Nokia Corporation 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
WO2012153173A2 (fr) * 2011-01-29 2012-11-15 Redthorne Media, Llc Réseau privé superposé orienté vers le retour d'informations pour la distribution de contenus
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
CA2843766A1 (fr) * 2011-08-16 2013-02-21 Destiny Software Productions Inc. Rendu video base sur un script
CN103002274B (zh) * 2011-09-16 2016-05-18 腾讯科技（深圳）有限公司 一种基于离线下载的移动多媒体实时转码播放系统及方法
CN104488246B (zh) * 2012-07-10 2018-11-02 Vid拓展公司 质量驱动串流
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
WO2015171835A1 (fr) * 2014-05-06 2015-11-12 Tivo 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

Also Published As

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

Similar Documents

Publication Publication Date Title
WO2016162639A1 (fr) Procédé de lecture en continu sur un équipement client d&#39;un contenu diffusé au sein d&#39;un réseau pair à pair
EP3949434A1 (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
WO2015071464A1 (fr) Procede et systeme de pre-telechargement de video a la demande
EP3378232B1 (fr) Procédé de traitement de données codées, procédé de réception de données codées, dispositifs, et programmes d&#39;ordinateurs associés
FR2991474A1 (fr) Technique de communication dans un reseau de communication centre sur les informations
EP3205067B1 (fr) Diffusion de contenus en streaming dans un réseau pair à pair
FR3054765B1 (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
WO2020259911A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d&#39;un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d&#39;ordinateur correspondants
FR3109046A1 (fr) Procédé de gestion d’un flux audio lu de manière synchronisée sur une horloge de référence
FR3105686A1 (fr) Equipement décodeur à double liaison audio
EP3092777B1 (fr) Procede de traitement d&#39;erreur de restitution d&#39;un contenu numerique
FR3138020A1 (fr) Streaming vidéo adaptatif hybride amélioré
EP4184922A1 (fr) Procédé de gestion de l&#39; accès à un contenu multimédia
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
FR3079099A1 (fr) Procede de diffusion d&#39;un contenu
FR3135857A1 (fr) Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.
WO2020234030A1 (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
FR3031643A1 (fr) Procede de gestion et de fonctionnement protocolaire d&#39;un reseau de distribution de contenu
EP4373099A1 (fr) Procédé de gestion de l&#39;accès à une contenu a lecture d&#39;un contenu multimédia
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique en mode économiseur d&#39;écran
FR3019429A1 (fr) Procede et dispositif de controle d&#39;un telechargement de contenus multimedia
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.
EP3939330A1 (fr) Procédé de gestion du téléchargement d&#39;images associées à des sauts d&#39;images susceptibles d&#39;être realisés lors d&#39;une lecture accelerée d&#39;un contenu multimedia diffusé en continu
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20171106

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20200518

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20230428

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20230909