WO2020193754A1 - Procédé de diffusion de contenus en streaming dans un réseau pair à pair - Google Patents

Procédé de diffusion de contenus en streaming dans un réseau pair à pair Download PDF

Info

Publication number
WO2020193754A1
WO2020193754A1 PCT/EP2020/058709 EP2020058709W WO2020193754A1 WO 2020193754 A1 WO2020193754 A1 WO 2020193754A1 EP 2020058709 W EP2020058709 W EP 2020058709W WO 2020193754 A1 WO2020193754 A1 WO 2020193754A1
Authority
WO
WIPO (PCT)
Prior art keywords
segment
segments
peer
reader
function
Prior art date
Application number
PCT/EP2020/058709
Other languages
English (en)
Inventor
Hiba YOUSEF
Paul-Louis AGENEAU
Axel DELMAS
Original Assignee
Streamroot
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 filed Critical Streamroot
Priority to SG11202110647QA priority Critical patent/SG11202110647QA/en
Priority to JP2021556863A priority patent/JP7059509B1/ja
Priority to EP20713032.9A priority patent/EP3949434A1/fr
Priority to AU2020245087A priority patent/AU2020245087B2/en
Priority to CA3135076A priority patent/CA3135076C/fr
Priority to KR1020217035076A priority patent/KR102472155B1/ko
Publication of WO2020193754A1 publication Critical patent/WO2020193754A1/fr

Links

Classifications

    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9005—Buffering arrangements using dynamic buffer space allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/104—Signalling gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions

Definitions

  • the present invention relates to a method of broadcasting streaming content in a peer-to-peer network.
  • Streaming in French “continuous reading”
  • Streaming designates a technique of reading an audio or video stream “live”, that is to say as it is retrieved from the Internet. by customer equipment. It thus opposes downloading, which requires retrieving all of the data from the audio or video content before it can be read.
  • the storage of the content is temporary and partial, the data being continuously downloaded into a client's buffer memory (typically RAM), decoded on the fly, sent to an output interface (a screen and / or speakers) and replaced with new data.
  • a client's buffer memory typically RAM
  • decoded on the fly sent to an output interface (a screen and / or speakers) and replaced with new data.
  • content is made available on a streaming server.
  • the client wishing to access it sends a request to retrieve the first segments thereof (by segment is meant a block of content data, generally corresponding to a few seconds of reading).
  • segment is meant a block of content data, generally corresponding to a few seconds of reading.
  • P2P peer-to-peer
  • each client acts as a server for other clients: we are talking about peers.
  • a peer who has started reading the content can retransmit segments that it has already received to others, and so on, making it easier to distribute regardless of the number of interested customers.
  • This strategy is described for example in international application WO 2012/154287 and is satisfactory.
  • ABR Adaptive BitRate
  • ABR automatic variation of the quality of the recovered segments according to the "capacities" of a peer. More precisely, each segment is available at several quality levels corresponding to several bitrates, i.e. data rates. It is indeed understood that a segment of better quality has a better resolution, a lower compression, a greater number of images per second, etc., and is therefore larger than the same segment in a lower quality, and it is therefore necessary to support higher data rate.
  • the ABR aims to automatically determine for each segment the best quality that can be chosen, generally in view of two criteria which are the observed bandwidth and / or the filling rate of the buffer memory.
  • the algorithm judges that the estimated bandwidth is sufficient to support higher quality, then it will instruct the client to switch to it (or conversely to lower the quality if the bandwidth is too low).
  • the principle is to divide the buffer memory into different intervals, each interval corresponding to an increasingly high quality as the filling of the buffer memory increases (or more and less if it decreases) .
  • the ABR algorithms do not have a fundamental incompatibility to be used in a P2P streaming context, the problem is that the ABR algorithms were designed to work in a simple streaming scenario, i.e. with all segments retrieved on request from the content server.
  • P2P streaming performs “pre-buffering”, by downloading P2P segments into a dedicated P2P cache before the reader actually requests them.
  • the objective of P2P streaming is to solicit as little as possible (and as a last resort) the original content server: a direct request for a segment from this server is only made if there is a risk that there is no longer any of segments in the video buffer and playback is interrupted (“re-buffering”), otherwise there is maximum count on the P2P network.
  • the present invention improves the situation.
  • the present invention thus relates to a method for continuously reading on a player of a client equipment item of content broadcast within a peer-to-peer network of client equipment, said content consisting of a sequence of segments. available in a plurality of quality levels and said reader being adapted to choose the quality level of the segments in accordance with an adaptive rate control logic, ABR; the client equipment comprising a first buffer memory adapted to store segments in a format suitable for transfer within the peer-to-peer network, the method being characterized in that it comprises the implementation by processing means data of the stage equipment:
  • This method cleverly provides feedback to ABR's algorithm by adding an artificial delay to the response.
  • said ABR logic is defined by a first function making it possible to calculate a quality level in which said segment is required as a function of at least one parameter representative of a rate of reception of segments;
  • a second function makes it possible to calculate in step (a) said response time as a function of said at least one parameter representative of a rate of reception of segments;
  • the equipment further comprises a second buffer memory suitable for storing segments in a format suitable for reading by the reader, said segment being provided in step (b) in the second buffer memory;
  • said parameter representative of a segment reception rate is a filling level of the second buffer memory and / or a bandwidth
  • step (a) includes predicting a quality level in which the next segment will be required based on the calculated response time
  • the method comprises a step (c) of verifying said prediction of a quality level in which the next segment will be required;
  • the method includes learning the second function based on the predicted and actually required quality levels
  • step (a) comprising the modification of the response time calculated as a function of an estimated time necessary to finish retrieving the segment, the segment being provided in a manner complete in step (b) no earlier than the expiration of the modified response time.
  • the invention proposes equipment for the continuous reading on a player of content broadcast within a peer-to-peer network of client equipment, said content consisting of a sequence of segments available in a plurality of quality levels and said reader being adapted to choose the quality level of the segments in accordance with an adaptive rate control logic, ABR;
  • the client equipment comprising a first buffer memory adapted to store segments in a format suitable for transfer within the peer-to-peer network and data processing means, the equipment characterized in that the processing means of data are configured to, upon receipt of a request for a segment from the reader, respond to said segment from the first buffer memory upon expiration of a response time defined with respect to said reader ABR logic .
  • the invention proposes a computer program product comprising code instructions for the execution of a method according to the first aspect of broadcasting content by streaming in a peer-to-peer network of 'client equipment connected to a content server; and a storage means readable by a computer equipment on which a computer program product comprises code instructions for the execution of a method according to the first aspect of broadcasting content by streaming in a peer-to-peer network of 'client equipment connected to a content server.
  • Figure 1 shows an architecture for the implementation of the method according to the invention
  • Figure 2 illustrates a preferred embodiment 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 11, 12.
  • Each client equipment 11, 12 is typically personal computer equipment such as a smartphone, a PC, a tablet, etc. connected to the network 1, having data processing means 110 such as a processor, an interface for reading the content, and data storage means such as a random access memory and / or a mass memory.
  • Reading is implemented by a reader, that is to say an application executed by the data processing means 110, which can be of a varied nature, for example a dedicated application, an internet browser in particular compatible with HTML5, an operating system module, etc.
  • the reader implements a logic of adaptive regulation of the bitrate, ABR (Adaptive Bitrate), that is to say that said content to be read consists of a sequence of segments available in a plurality of qualities and that the reader is able to decide autonomously which quality to require, in accordance with this ABR logic.
  • ABR Adaptive Bitrate
  • the various qualities correspond to different rates, that is to say a variable volume of data per unit of time (and thus per segment). We understand, of course, that better quality content requires more throughput.
  • ABR logic in more detail later, it will only be understood that in the context of the present process it is not necessary for the ABR logic to be controllable or even known: the present process is completely universal and can be used adapt to any reader implementing any ABR logic based on any criteria.
  • the ABR logic is predefined and that the client software (see below) is only subject to it.
  • the equipment 11 (and more precisely its data storage means) have two buffer memories M1 and M2 (also called “Buffer”), typically two zones of a random access memory, each being able to store (in a different way as we will see) all or part of the content in a temporary way (by temporary, we mean that the segments are deleted from this memory shortly after they have been read: they are not stored long term as is the case with a direct download). For example, in the case of playback via a browser, all the segments are typically deleted (ie the buffers reinitialized) at the latest when the browser or the tab in which the video is played is closed at the latest.
  • Buffer typically two zones of a random access memory
  • the first buffer memory M1 is called a “peer-to-peer cache”. It stores the segments in a so-called “raw” format. By raw segments is meant in a format suitable for transfer within the peer-to-peer network 10, but unsuitable for reading on equipment 11.
  • the second buffer memory M2 is called a “video buffer”. It is controlled by the reader and stores the segments in a so-called “converted” format. By converted segments is meant converted from raw segments in a format suitable for reading (and in particular for the reader) on the equipment 11, but unsuitable for transfer within the peer-to-peer network 10, see more far.
  • the devices 11, 12 are “peers” (also called “nodes") of the peer-to-peer network 10.
  • client equipment 11, 12 of a peer-to-peer network 10 is meant equipment connected in the network 1 by a peer-to-peer network protocol.
  • the data processing means of each peer implement a particular program (client software, called “Peer-agent”, PA), which can for example be integrated into the reader (for example an extension of 'a web browser), be the object of a dedicated application, or even be incorporated into any other on-board software (for example a player of an Internet access box or a multimedia box, ie a "Set- top box ”), for peer-to-peer use.
  • client software called “Peer-agent”, PA
  • PA client software
  • the present method is mainly implemented through this client software.
  • peers 11, 12 are decentralized sub-network within the network 1, in which data can be transferred directly between two client devices 11, 12 network 10, without passing through a central server. It thus allows all the client equipment 11, 12 to play both the role of client and server.
  • the peers 11, 12 are thus defined as “seeders” (in French the “semeurs”, that is to say data providers) and / or “leechers” (in French the “sangsues”, c ' i.e. data recipients).
  • Said content which is in particular audio or video content, that is to say media of a certain duration, consists of a sequence of segments (called “playlist”, in English “playlist”) stored on data storage means of a server 2 connected to the peer-to-peer network 10, and as explained available in several quality levels.
  • the segments have a predetermined length, typically a second or two of the content, but it can range from a fraction of a second to ten seconds. All segments of a given content are generally the same length, which will be noted here on p.
  • Server 2 is a content server (called a CDN), advantageously present in network 1 and connected to peer-to-peer network 10.
  • CDN content server
  • internet 1 making the segments of various content available in accordance with a given streaming protocol.
  • Server 2 is the primary source of the segments, insofar as initially no peer has the content (before a first transfer from server 2 to this peer 11, 12).
  • the contents are either from the start stored in their entirety on server 2 (case of VOD previously mentioned), or generated in real time (case of live streaming, or live streaming), and in the latter case the list of segments that constitute them evolve dynamically.
  • Live Streaming (that is to say “live streaming”) proposes to broadcast in real time content associated with “live” events, for example concerts, conferences, sporting events, events. parts of video games, etc., which are being played simultaneously. Compared to the streaming of already fully existing content such as a film, content broadcast in Live streaming is indeed generated as the associated event unfolds.
  • such content can only be broadcast with a slight delay, which the user wants as low as possible.
  • This delay is typically of the order of one minute, but can drop to around twenty seconds.
  • the sequence of segments is thus dynamic, that is, it is updated regularly. Each time a new segment is generated it is added at the end of the sequence, and the first segment of the sequence (the oldest) is deleted. All the others shift according to a rolling mechanism that can be compared to a FIFO list.
  • the first segment of the list can be the one at the play point, in other words the “live” segment (and therefore the segments are deleted from the playlist as soon as they are played. ), or a "past" segment if the content server accepts that the content is read late (some platforms offer live streaming with up to 2 hours late), this is called the DVR (“Digital video recorder”).
  • the present method can be implemented in any context.
  • the tracker 3 presents data processing means and storage means. It coordinates the exchanges between peers 11, 12 (by controlling the client software implemented by each of the client equipment 11, 12), but it is not directly involved in the transfer of data and does not have a copy of the file.
  • ABR peer management server
  • ABR logic based respectively on the bandwidth (ie the observed data rate) and on the level of filling (either in value, ie in seconds or in number of segments, or in rate) of the second buffer memory M2 (possibly in combination).
  • the reader monitors the bandwidth and / or volume / fill rate of the second buffer memory M2, and makes decisions on whether or not to change the required segment quality level accordingly.
  • the ABR logic can be defined by means of a first function making it possible to calculate the quality level to be chosen (the bitrate) as a function of at least one parameter representative of a reception rate. of segments, see for example the curve as represented by FIG. 2 (left part, which represents the reader side, the right part illustrating the client software side).
  • said parameter representative of a segment reception rate is a monitored parameter, which can be any parameter illustrating the ability of the equipment 11 and / or the network 10 to receive the segments "sufficiently quickly".
  • the known ABR logics generally use as a parameter a filling level of the second buffer memory M2 and / or a bandwidth.
  • said first function is monotonic, in particular increasing, between a minimum quality value and a maximum quality value.
  • a preferred model is that of a piecewise, three-piece continuous function (connected at two singular points), with a first and third constant piece.
  • the bitrate is set equal to the minimum bitrate R min (in other words the buffer is dangerously empty, which is representative of difficulties in obtain segments, and then the quality is minimal to favor refilling);
  • bitrate is set equal to the maximum bitrate R m ax (the buffer is full so there is no risk in affording the maximum quality);
  • the present method proposes to control the ABR not by altering its logic, but by deceiving it by means of an added response delay before satisfying a request from the segment. Indeed, simply delaying the provision of a segment makes it possible to artificially limit the bandwidth and the filling level of the second buffer memory M2, and thus act on the expected quality of the segments.
  • a second function is defined allowing said response time as a function of said at least one parameter representative of a rate of reception of segments in the examples shown, it is therefore again the filling level of the second buffer memory M2) .
  • the second function is preferably built (or even learned, see below) from the first function, that is to say that we can map the ABR logic by means of the second function.
  • the second function is monotonic with respect to said at least one parameter representative of a rate of reception of segments, and generally (in particular in the case of an ABR logic based on the filling level of the second buffer memory M2 which will be developed below) the first and the second function have the same monotony with respect to said at least one parameter representative of a segment reception rate (in particular increasing).
  • the second function turns out most often similar to the first function of the ABR logic (again a continuous function by pieces to three pieces of which two extremal segments), see for example the corresponding curve which is represented on the right part of figure 2.
  • the second function is constructed with the same monotonicity as the first function, in particular a continuous function in pieces with three pieces connected via said two points.
  • the response time is set at a minimum value p m in, preferably zero, ie no time is added (in other words the buffer is dangerously empty, and we do not take any risk by directly providing the segments received);
  • the response time is set equal to a maximum value p m ax, preferably the length p of a segment (this makes it possible not to increase the filling rate even further of the video buffer, the P2P cache keeps the margin by providing a new segment only when a previous segment has been read in full);
  • the first and the second function have an inverse monotony with respect to said at least one parameter representative of a rate of reception of segments (that is to say that the second function is increasing when the first function is decreasing, and vice versa), this is notably the case if the ABR logic is based on the bandwidth (then the first function is increasing and the second function is decreasing).
  • the present method will not be limited to a given strategy for applying a response time, and those skilled in the art will know how to adapt the idea to the ABR logic, to the type of parameter monitored by the reader, to the behavior of the network. P2P, etc. In general, it will be understood that it suffices to construct a second function defining the response time from the first function defining the ABR logic.
  • a client device 11 which is, where appropriate, in the process of retrieving the content from other devices 12 and / or the server 2, that is to say that the first buffer memory M1 already stores at least one raw segment, in at least one quality level, if possible a sub-sequence of the sequence constituting the content.
  • the method then begins with the implementation by the processing means 110 of the equipment of a step (a) of receiving a request for a segment, in this case the next segment to be put in a second buffer memory.
  • M2 not necessarily the next segment to read, there are normally buffered advance segments.
  • Said request is received from the reader, and preferably defines the quality level in which the segment is required, i.e. the bitrate (by application of the ABR logic).
  • segment is at this stage at least partially available (i.e. at least one fragment) in the first buffer memory M1, in the quality required by the reader. If this segment / segment fragment was in another quality, it would have to be retrieved again, usually directly from content server 2 because time is running out.
  • step (a) then advantageously comprises the calculation of a response time defined with respect to said ABR logic of the reader, in particular as a function of a parameter monitored by the ABR logic (said at least one representative parameter a segment reception rate), preferably the filling level of the second buffer memory M2 and / or the bandwidth.
  • Step (a) includes, where appropriate, the "measurement" of said parameter representative of a segment reception rate.
  • the second function defining the response time is preferably increasing with said parameter representative of a flow rate of receiving segments between a minimum response time value and a maximum value.
  • step (a) includes modifying the response time calculated based on an estimated time needed to finish retrieving the segment.
  • a step (b) said required segment is provided in response to the request, from the first buffer memory M1, at the expiration of said response time.
  • provided at the expiration of said response time is meant such that the reader does not have it before the expiration of the response time (at best at the time of expiration, or even only after in certain cases , to see further).
  • the segment is transmitted suddenly when the response time expires, but it will be understood that it is quite possible to “stream” it within the device 1, ie to stream it. transmit from the first buffer memory M1 progressively (small end by small end) so that the last end is transmitted (at the earliest) when the response time expires (the response time is then a "transmission delay of the last bit of the segment ”).
  • the delivery can be broken up, one should not confuse sub-segments of a complete segment (which correspond to consecutive pieces of segment obtained from a completely downloaded segment) and an incomplete segment (in which only parts of the data, usually corresponding to disparate pieces, have been downloaded).
  • Only a completely available segment in the first buffer M1 can be provided (if necessary gradually) in response to the request (and not a fragment), so if the download took longer than expected, it The segment may not be fully available until the modified response time has expired.
  • the complete segment is provided at the earliest at the expiration of the modified response time (ie not before), but possibly after.
  • the complete segment is provided when both of the following conditions are true: the segment is completely available (its download is complete), and the modified response time has expired.
  • the segment is supplied to the second buffer memory M2, and as such step (b) can comprise the conversion into a format suitable for reading on the equipment 11 of said segment of the first M1 buffer.
  • This step consists of transforming the raw segment into a converted segment, which can be read by the reader of equipment 11 unlike the first.
  • the conversion consists of injecting the video data of the segment using the Media Source API browser extension
  • step (b) advantageously simultaneously comprises reading a previous segment stored in the second buffer memory M2, so that the segments "rotate”. The segment retrieved in step (b) will soon be read as well.
  • step (a) further comprises the prediction of a possible next ABR decision, ie the prediction of the quality level in which the next segment will be required (ie at the next occurrence of step (a )).
  • step (b) the filling level of the second memory M2 will have increased by p, that is to say the length of the segment.
  • the method may include a step (c), at the end of step (b), of verifying the prediction (where appropriate combined with a next occurrence of step (a)).
  • the ABR logic is restarted to calculate a “new” quality level required, ie the quality level required for the next segment, and a corresponding segment request will as such be sent to the client software. Verification is simply a comparison of the predicted quality level and the required practical level of quality for the next segment. Learning
  • the first function is known, and the second function can be preconstructed from this first function.
  • the first function may be poorly known or not known at all if the reader is completely closed.
  • step (c ) the prediction and the decision actually taken, ie the level of quality predicted and that actually required, which constitutes a learning loop.
  • the first or second function can be estimated by starting in particular from a default function, and by changing its parameters over time.
  • the first function can be parameterized via the values of the four parameters B m in, Rmin, B m ax and R max assuming a piecewise three-segment function
  • the second function can be parameterized via the values of the four parameters B m in, Pmin, B m ax and p max assuming a piecewise function with three segments (we therefore have a total of six variables).
  • the client software will probably calculate the response time imprecisely, which will lead to unanticipated ABR decisions and uncontrolled quality level change, but quickly the algorithm will improve and the ABR logic. will be completely mastered.
  • learning algorithms can be used, for example neural networks.
  • Certain factors can be used to invalidate the saved parameters and start again with empty parameters for a new learning phase.
  • the learned functions can be transmitted to other peers 12, for example via P2P messages, or to the peer management server 3.
  • Computer program equipment and products can be transmitted to other peers 12, for example via P2P messages, or to the peer management server 3.
  • the invention relates to the client equipment 11 for the implementation of the present method of reading a content, on a reader adapted to choose the level of quality of the segments in accordance with a logic of adaptive regulation of the bit rate. , ABR.
  • This equipment 11 comprises as explained:
  • a first buffer memory M1 temporarily storing at least one segment of a content consisting of a sequence of segments, each raw segment being in a format suitable for transfer within the peer-to-peer network 10;
  • a second buffer memory M2 temporarily storing at least one converted segment of said content, in a format suitable for reading by the reader;
  • the data processing means 110 are configured to implement, following the reception of a request for a segment, the supply (to the reader, typically by injection into the second buffer memory M2) of said segment into the first buffer memory M1 at the expiration of a response time defined with respect to said logic ABR of the reader.
  • 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 11) of a method according to the first aspect of the invention of streaming on client equipment 11 of content broadcast within a peer-to-peer network 10 of client equipment 11, 12, as well as storage means readable by computer equipment (for example a memory of this client equipment 11) on which this computer program product is found.

Abstract

La présente invention concerne un procédé de lecture en continu sur un lecteur d'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 disponibles dans une pluralité de niveaux de qualités et ledit lecteur étant adapté pour choisir le niveau de qualité des segments conformément à une logique de régulation adaptative du débit, ABR; l'équipement client (11) comprenant une première mémoire tampon (M1) adaptée pour stocker des segments 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) Réception d'une requête d'un segment depuis le lecteur; (b) Fourniture en réponse dudit segment depuis la première mémoire tampon (M1) à l'expiration d'un délai de réponse défini par rapport à ladite logique ABR du lecteur.

Description

Procédé de diffusion de contenus en streaming dans un réseau pair à pair
DOMAINE TECHNIQUE GENERAL
La présente invention concerne un procédé de diffusion d’un contenu en streaming dans 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), décodées à la volée, envoyé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 (buffer) 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 a 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 peut 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 par exemple dans la demande internationale WO 2012/154287 et apporte satisfaction.
Toutefois, la plupart des lecteurs mettent en œuvre une logique dite de débit adaptatif (en anglais « Adaptive BitRate », ABR) et cela s’avère poser des problèmes lorsqu’en combinaison avec le P2P.
L’idée générale de l’ABR est de permettre la variation automatique de la qualité des segments récupérés en fonction des « capacités » d’un pair. Plus précisément, chaque segment est disponible à plusieurs niveaux de qualité correspondant à plusieurs bitrates, i.e. débits de données. On comprend en effet qu’un segment de meilleure qualité a une résolution meilleure, une compression moindre, un plus grand nombre d’images par secondes, etc., et est donc plus volumineux que le même segment dans une moindre qualité, et il est donc nécessaire de soutenir un débit de données plus élevé.
L’ABR vise à déterminer automatiquement pour chaque segment la qualité la meilleure pouvant être choisie, généralement au vu de deux critères qui sont la bande-passante constatée et/ou le taux de remplissage de la mémoire tampon.
Dans le premier cas, si l’algorithme juge que la bande passante estimée est suffisante pour supporter une qualité supérieure, alors il va donner l’instruction au client de basculer sur celle-ci (ou à l’inverse de baisser la qualité si la bande passante est trop faible). Dans le second cas, le principe est de diviser la mémoire tampon en différents intervalles, chaque intervalle correspondant à une qualité de plus en plus élevée à mesure que le remplissage de la mémoire tampon augmente (ou de plus en plus faible s’il baisse).
Dans les deux cas, si les algorithmes ABR n’ont pas d’incompatibilité fondamentale à être utilisés dans un contexte de streaming P2P, le problème est que les algorithmes d’ABR ont été conçus pour fonctionner dans un scénario de streaming simple, i.e. avec tous les segments récupérés sur requête depuis le serveur de contenus.
Or, en pratique le streaming P2P effectue du « pré-buffering », en téléchargeant des segments en P2P dans un cache P2P dédié avant que le lecteur n’en fasse réellement la requête. En effet, l’objectif du streaming P2P est de solliciter le moins possible (et en dernier recours) le serveur de contenu d’origine : une requête directe d’un segment auprès de ce serveur n’est effectuée que s’il y a un risque qu’il n’y ait plus de segments dans le buffer vidéo et que la lecture s’interrompe (« re-buffering »), sinon on compte au maximum sur le réseau P2P.
On se retrouve ainsi du point de vue du lecteur avec des bandes- passantes apparentes extrêmement élevées, puisque des segments peuvent être chargés dans la mémoire tampon depuis le cache P2P une fraction de seconde après qu’ils ont été demandés. De surcroît le taux de remplissage du buffer vidéo est artificiellement élevé.
Cela provoque des décisions incontrôlées de l’ABR d’augmenter la qualité si la qualité courante n’est pas la qualité maximale, indépendamment de la capacité réelle du réseau, qualité qu’il ne pourra pas nécessairement supporter.
On se retrouve ainsi au mieux avec des oscillations instables de la qualité du flux, au pire avec des interruptions répétées de la lecture et des sollicitations nombreuses et inutiles du serveur de contenus.
Il serait souhaitable de pouvoir contrôler la logique d’ABR, mais malheureusement celle-ci est souvent propre au lecteur et peu accessible, et encore moins modifiable. Il serait ainsi souhaitable de disposer d’une manière de contrôler tout algorithme ABR dans un contexte de streaming P2P.
La présente invention vient améliorer la situation.
PRESENTATION DE L’INVENTION
La présente invention se rapporte ainsi à un procédé de lecture en continu sur un lecteur d’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 disponibles dans une pluralité de niveaux de qualités et ledit lecteur étant adapté pour choisir le niveau de qualité des segments conformément à une logique de régulation adaptative du débit, ABR ; l’équipement client comprenant une première mémoire tampon adaptée pour stocker des segments 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) Réception d’une requête d’un segment depuis le lecteur (b) Fourniture en réponse dudit segment depuis la première mémoire tampon à l’expiration d’un délai de réponse défini par rapport à ladite logique ABR du lecteur.
Cette méthode propose astucieusement un retour d’information à l’algorithme d’ABR par le biais de l’ajout d’un délai artificiel à la réponse.
Selon des caractéristiques avantageuses et non-limitatives :
• ladite logique ABR est définie par une première fonction permettant de calculer un niveau de qualité dans lequel ledit segment est requis en fonction d’au moins un paramètre représentatif d’un débit de réception de segments ;
• une deuxième fonction permet de calculer à l’étape (a) ledit délai de réponse en fonction dudit au moins un paramètre représentatif d’un débit de réception de segments ;
• la deuxième fonction est construite à partir de la première fonction ;
• la deuxième fonction est monotone par rapport audit au moins un paramètre représentatif d’un débit de réception de segments ;
• l’équipement comprend en outre une deuxième mémoire tampon adaptée pour stocker des segments dans un format adapté pour la lecture par le lecteur, ledit segment étant fourni à l’étape (b) dans la deuxième mémoire tampon ;
• ledit paramètre représentatif d’un débit de réception de segments est un niveau de remplissage de la deuxième mémoire tampon et/ou une bande-passante ;
• l’étape (a) comprend la prédiction d’un niveau de qualité dans lequel le prochain segment sera requis en fonction du délai de réponse calculé ;
• Le procédé comprend une étape (c) de vérification de ladite prédiction d’un niveau de qualité dans lequel le prochain segment sera requis ;
• Le procédé comprend l’apprentissage de la deuxième fonction sur la base des niveaux de qualité prédits et effectivement requis ;
• le segment requis est disponible de manière incomplète dans la première mémoire tampon, l’étape (a) comprenant la modification du délai de réponse calculé en fonction d’une durée estimée nécessaire pour finir de récupérer le segment, le segment étant fourni de manière complète à l’étape (b) au plus tôt à l’expiration du délai de réponse modifié. Selon un deuxième aspect, l’invention propose un équipement pour la lecture en continu sur un lecteur 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 disponibles dans une pluralité de niveaux de qualités et ledit lecteur étant adapté pour choisir le niveau de qualité des segments conformément à une logique de régulation adaptative du débit, ABR ; l’équipement client comprenant une première mémoire tampon adaptée pour stocker des segments dans un format adapté pour le transfert au sein du réseau pair-à-pair et des moyens de traitement de données, l’équipement caractérisé en ce que les moyens de traitement de données sont configurés pour, suite à la réception d’une requête d’un segment depuis le lecteur, fournir en réponse ledit segment depuis la première mémoire tampon à l’expiration d’un délai de réponse défini par rapport à ladite logique ABR du lecteur.
Selon un troisième et un quatrième aspect, l’invention propose un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de diffusion d’un contenu en streaming dans un réseau pair à pair d’équipements client connecté à un serveur de contenu ; 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 diffusion d’un contenu en streaming dans un réseau pair à pair d’équipements client connecté à un serveur de contenu.
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 mode de réalisation préféré 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 11 , 12. 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 de moyens de stockage de données tels qu’une mémoire vive et/ou une mémoire de masse.
La lecture est mise en œuvre par un lecteur, c’est-à-dire une application exécutée par les moyens de traitement de données 110, qui peut être de nature variée, par exemple une application dédiée, un navigateur internet en particulier compatible HTML5, un module du système d’exploitation, etc.
On supposera dans la suite de la description que le lecteur est « en l’état », c’est-à-dire qu’il n’est pas modifié pour la mise en œuvre du présent procédé, ni même pour du streaming P2P. En particulier, le lecteur met en œuvre une logique de régulation adaptative du débit, ABR (Adaptative Bitrate), c’est-à-dire que ledit contenu à lire est constitué d’une séquence de segments disponibles dans une pluralité de qualités et que le lecteur est capable de décider de manière autonome quelle qualité requérir, conformément à cette logique ABR. Les diverses qualités correspondent à des débits différents, c’est-à-dire un volume de données par unité de temps (et ainsi par segment) variable. On comprend naturellement qu’un contenu de meilleure qualité nécessite un débit plus important.
On reviendra plus en détail plus loin sur la notion de logique ABR, on comprendra seulement que dans le cadre du présent procédé il n’est pas nécessaire que la logique ABR soit contrôlable ni même connue : le présent procédé est complètement universel et peut s’adapter à n’importe quel lecteur mettant en œuvre n’importe quelle logique d’ABR sur la base de n’importe quel critère. On supposera que la logique d’ABR est prédéfinie et que le logiciel client (voir plus loin) ne fait que la subir.
Par ailleurs, l’équipement 11 (et plus précisément ses moyens de stockage de données) disposent 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). Par exemple, dans le cas 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, mais inadapté pour la lecture sur l’équipement 11.
La deuxième mémoire tampon M2 est appelée « buffer vidéo ». Elle est contrôlée par le lecteur et 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 (et en particulier pour le lecteur) sur l’équipement 11 , mais inadapté pour le transfert au sein du réseau pair-à-pair 10, voir plus loin.
Comme expliqué dans l’introduction, les équipements 11 , 12 sont des « pairs » (appelés également « nœuds ») 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 œuvre un programme particulier (logiciel client, appelé « Peer-agent », PA), qui peut être par exemple être intégré au lecteur (par exemple une extension d’un navigateur web), faire l’objet d’une application dédiée, voire être incorporé dans 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. Le présent procédé est principalement implémenté via ce logiciel client. Dans la suite de la présente description, on fera l’hypothèse d’un logiciel client en communication avec le lecteur de sorte à l’approvisionner en segments, mais fonctionnant de manière indépendante. Plus précisément, on comprend que le rôle du lecteur est la lecture en elle-même, i.e. le rendu des segments, alors que le rôle du logiciel client est simplement l’obtention des segments pour le lecteur, le logiciel client subissant le fonctionnement du lecteur et en particulier sa logique ABR.
Comme expliqué, 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 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 », 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, et comme expliqués disponibles en plusieurs niveaux de qualité. 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, qu’on notera ici p.
Le serveur 2 est un serveur de contenu (dit CDN), 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 H DS. Les segments bruts peuvent être échangés entre pairs via un protocole 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 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 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 »).
Le présent procédé peut être mis en œuvre dans n’importe quel contexte.
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 11 , 12 (en contrôlant le logiciel client mis en œuvre 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. ABR
Comme évoqué il y a deux types principaux de logiques ABR, basés respectivement sur la bande passante (i.e. le débit de données constaté) et sur le niveau de remplissage (soit en valeur, i.e. en secondes ou en nombre de segments, soit en taux) de la deuxième mémoire tampon M2 (éventuellement en combinaison). En d’autres termes, le lecteur monitore la bande-passante et/ou le volume/taux de remplissage de la deuxième mémoire tampon M2, et prend en conséquence des décisions de modification ou non du niveau de qualité des segments exigé.
Généralement, dans un cas comme l’autre on peut définir la logique ABR au moyen d’une première fonction permettant de calculer le niveau de qualité à choisir (le bitrate) en fonction d’au moins un paramètre représentatif d’un débit de réception de segments, voir par exemple la courbe telle que représentée par la figure 2 (partie gauche, qui représente le côté lecteur, la partie droite illustrant le côté logiciel client).
On comprend que ledit paramètre représentatif d’un débit de réception de segments est un paramètre surveillé, qui peut être n’importe quel paramètre illustrant la capacité de l’équipement 11 et/ou du réseau 10 à recevoir « suffisamment vite » les segments. Comme expliqué précédemment, les logiques ABR connues utilisent généralement comme paramètre un niveau de remplissage du la deuxième mémoire tampon M2 et/ou une bande passante.
Quel que soit le type de logique ABR, ladite première fonction est monotone, en particulier croissante, entre une valeur de qualité minimale et une valeur de qualité maximale. Un modèle préféré est celui d’une fonction continue par morceaux, à trois morceaux (connectés en deux points singuliers), dont un premier et un troisième morceaux constants.
Ainsi, dans l’exemple de la figure 2 (partie gauche), l’exemple d’une logique ABR basée sur le niveau de remplissage de la deuxième mémoire tampon M2 (exprimé en secondes) est représenté, et on voit que :
pour un niveau de remplissage inférieur ou égal à un seuil minimal Bmin, le bitrate est fixé égal au bitrate minimum Rmin (en d’autres termes le buffer est dangereusement vide, ce qui est représentatif de difficultés à obtenir des segments, et alors la qualité est minimale pour favoriser le re-remplissage) ;
pour un niveau de remplissage supérieur ou égal à un seuil maximal Bmax, le bitrate est fixé égal au bitrate maximum Rmax (le buffer est plein donc il n’y a pas de risque à se permettre la qualité maximale) ;
entre les deux, on a une courbe croissante, préférentiellement linéaire - dans l’exemple de la figure 2 elle est d’équation R=Rmin+(B- Bmin)*(Rmax-Rmin)/(Bmax-Bmin) - ce qui traduit que plus le buffer est plein plus la qualité peut être élevée.
Une courbe similaire est obtenue pour une logique ABR basée sur la bande-passante
Comme l’on verra plus loin, le présent procédé propose de contrôler l’ABR non pas en altérant sa logique, mais en la leurrant au moyen d’un délai de réponse rajouté avant de satisfaire une requête du segment. En effet, simplement retarder la fourniture d’un segment permet de limiter artificiellement la bande- passante et le niveau de remplissage de la deuxième mémoire tampon M2, et ainsi d’agir sur la qualité attendue des segments.
On définit pour cela une deuxième fonction permettant ledit délai de réponse en fonction dudit au moins un paramètre représentatif d’un débit de réception de segments dans les exemples représentés, c’est donc à nouveau le niveau de remplissage de la deuxième mémoire tampon M2).
La deuxième fonction est préférentiellement construite (voire apprise, voir plus loin) à partir de la première fonction, c’est-à-dire qu’on peut mapper la logique ABR au moyen de la deuxième fonction.
Ainsi, selon un mode de réalisation préféré la deuxième fonction est monotone par rapport audit au moins un paramètre représentatif d’un débit de réception de segments, et généralement (notamment dans le cas d’une logique ABR basée sur le niveau de remplissage de la deuxième mémoire tampon M2 qui sera développé ci-après) la première et la deuxième fonction ont la même monotonie par rapport audit au moins un paramètre représentatif d’un débit de réception de segments (en particulier croissante). En effet la deuxième fonction s’avère le plus souvent similaire à la première fonction de la logique ABR (à nouveau une fonction continue par morceaux à trois morceaux dont deux segments extrémaux), voir par exemple la courbe correspondante qui est représentée sur la partie droite de la figure 2.
Le mapping peut par exemple consister à prendre deux points de la première fonction, en particulier les points singuliers connectant les morceaux de coordonnées {Bmin, Rmin=fi (Bmin)} et {Bmax, Rmax=fi (Bmax)}, et construire la deuxième fonction sur la base des deux points correspondants {Bmin, Pmin=f2(Bmm)} et {Bmax, Pmax=f2(Bmax)}. De manière préférée on construit la deuxième fonction de même monotonie allure que la première fonction, en particulier une fonction continue par morceaux à trois morceaux connectés via lesdits deux points.
Dans l’exemple de la figure 2 partie droite, la deuxième fonction est ainsi construite de la sorte :
pour un niveau de remplissage inférieur ou égal au seuil minimal Bmin, le délai de réponse est fixé à une valeur minimale pmin, préférentiellement nulle, i.e. aucun délai n’est ajouté (en d’autres termes le buffer est dangereusement vide, et on ne prend pas de risque en fournissant directement les segments reçus) ;
pour un niveau de remplissage supérieur ou égal à un seuil maximal Bmax, le délai de réponse est fixé égal à une valeur maximale pmax, préférentiellement la longueur p d’un segment (ce permet de ne pas augmenter encore davantage le taux de remplissage du buffer vidéo, le cache P2P se garde de la marge en ne fournissant un nouveau segment que lorsqu’un segment précédent aura été lu en entier) ;
entre les deux, on a une courbe croissante, préférentiellement linéaire - dans l’exemple de la figure 2 elle est d’équation p= pmin+(B- Bmin)*(Pmax- Pmin)/(Bmax-Bmin) - ce qui traduit que plus le buffer est plein plus le délai de réponse peut être élevé de sorte à prévenir une hausse supplémentaire de ce taux de remplissage.
A noter qu’il est également possible que la première et la deuxième fonction aient une monotonie inverse par rapport audit au moins un paramètre représentatif d’un débit de réception de segments (c’est-à-dire que la deuxième fonction est croissante lorsque la première fonction est décroissante, et vice- versa), c’est notamment le cas si la logique ABR est basée sur la bande passante (alors la première fonction est croissante et la deuxième fonction est décroissante). Le présent procédé ne sera pas limité à une stratégie donnée d’application d’un délai de réponse, et l’homme du métier saura adapter l’idée à la logique ABR, au type de paramètre surveillé par le lecteur, au comportement du réseau P2P, etc. De façon générale, on comprendra qu’il suffit de construire une deuxième fonction définissant le délai de réponse à partir de la première fonction définissant la logique ABR.
Lecture
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 M1 stocke d’ores et déjà au moins un segment brut, dans au moins un niveau de qualité, 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 110 de l’équipement d’une étape (a) de réception d’une requête d’un segment, en l’espèce du prochain segment à mettre en deuxième mémoire tampon M2 (pas nécessairement le prochain segment à lire, il y a normalement des segments d’avance bufferisés). Ladite requête est reçue depuis le lecteur, et définit préférentiellement le niveau de qualité dans lequel le segment est requis, i.e. le bitrate (par application de la logique ABR).
On suppose que ledit segment est à ce stade au moins partiellement disponible (i.e. au moins un fragment) dans la première mémoire tampon M1 , dans la qualité requise par le lecteur. Si ce segment/fragment de segment était dans une autre qualité, il faudrait le récupérer à nouveau, généralement directement depuis le serveur de contenu 2 car on manque de temps.
Comme expliqué, l’étape (a) comprend alors avantageusement le calcul d’un délai de réponse défini par rapport à ladite logique ABR du lecteur, en particulier en fonction d’un paramètre surveillé par la logique ABR (ledit au moins un paramètre représentatif d’un débit de réception de segments), préférentiellement le niveau de remplissage de la deuxième mémoire tampon M2 et/ou la bande-passante. L’étape (a) comprend le cas échéant la « mesure » dudit paramètre représentatif d’un débit de réception de segments.
Comme expliqué, la deuxième fonction définissant le délai de réponse est préférentiellement croissante avec ledit paramètre représentatif d’un débit de réception de segments entre une valeur minimale de délai de réponse et une valeur maximale.
Dans le cas où c’est seulement un fragment du prochain segment qui a été récupéré (on dit que le segment est disponible de manière incomplète), de manière préférée le délai de réponse calculé est modifié selon la longueur du fragment de sorte à refléter le fait que seul un fragment du délai de réponse doit réellement être appliqué. En effet, on ne peut fournir à la deuxième mémoire tampon M2 que des segments complets et non des fragments, et l’idée est de fournir le segment de manière complète à l’issue d’un délai de réponse raccourci reflétant le fait qu’il y aura déjà implicitement un délai d’attente correspondant au temps pour compléter (finir de récupérer) ce segment dans la première mémoire tampon M1. Ainsi, l’étape (a) comprend la modification du délai de réponse calculé en fonction d’une durée estimée nécessaire pour finir de récupérer le segment.
Par exemple, on pourra appliquer la formule p’=p-tdw, où p’ est le délai de réponse modifié et tdw est la durée estimée nécessaire pour finir de récupérer le segment. Ainsi, l’attente du temps tdw plus l’application de p’ avant de fournir le segment complet est équivalent à l’application de p, de sorte que le délai global reste le même.
Dans une étape (b), ledit segment requis est fourni en réponse à la requête, depuis la première mémoire tampon M1 , à l’expiration dudit délai de réponse. Par « fourni à l’expiration dudit délai de réponse », on entend de telle sorte que le lecteur n’en dispose pas avant l’expiration du délai de réponse (au mieux au moment de l’expiration, voire seulement après dans certains cas, voir plus loin). Le plus souvent, le segment est transmis d’un coup au moment de l’expiration du délai de réponse, mais on comprendra qu’il est tout à fait possible de le « streamer » au sein de l’équipement 1 , i.e. de le transmettre depuis la première mémoire tampon M1 progressivement (petit bout par petit bout) de sorte que le dernier bout est transmis (au plus tôt) au moment de l’expiration du délai de réponse (le délai de réponse est alors un « délai de transmission du dernier bit du segment »). En effet, bien que seuls des segments complets sont lisibles, certains lecteurs peuvent accepter des sous-segments du segment. A noter qu’une telle transmission progressive ne change rien puisque tant que le segment n’est pas intégralement reçu il n’est pas disponible par le lecteur et donc pas considéré comme fourni, mais permet de faciliter des mesures de bande-passante. Dans le cas où seul un fragment du segment était disponible dans la première mémoire tampon M1 et où le délai de réponse a été modifié en fonction d’une durée estimée nécessaire pour finir de récupérer le segment, normalement le segment est également fourni à l’étape (b) à l’expiration du délai de réponse modifié. Comme expliqué, bien que la fourniture puisse être morcelée, il ne faut pas confondre des sous-segments d’un segment complet (qui correspondent à des morceaux consécutifs de segment obtenus à partir d’un segment complètement téléchargé) et un segment incomplet (dans lequel seules certaines parties de données, correspondant le plus souvent à des morceaux disparates, ont été téléchargées). Seul un segment disponible de manière complète dans la première mémoire tampon M1 peut être fourni (le cas échéant progressivement) en réponse à la requête (et pas un fragment), de sorte que le si le téléchargement a pris plus de temps de prévu, il est possible que le segment ne soit disponible de manière complète qu’après l’expiration du délai de réponse modifié. Ainsi, le segment complet est fourni au plus tôt à l’expiration du délai de réponse modifié (i.e. pas avant), mais possiblement après. En pratique, le segment complet est fourni lorsque les deux conditions suivantes sont vérifiées : le segment est disponible de manière complète (son téléchargement est terminé), et le délai de réponse modifié a expiré.
Dans tous les cas, de manière préférée, le segment est fourni à la deuxième mémoire tampon M2, et à ce titre l’étape (b) peut comprendre la conversion dans un format adapté pour la lecture sur l’équipement 11 dudit segment 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 11 contrairement au premier.
Par exemple, si le lecteur est le lecteur intégré d’un navigateur compatible HTML5, la conversion consiste en l’injection des données vidéo du segment grâce à l’API Media Source Extension du navigateur
Naturellement, l’étape (b) comprend avantageusement simultanément la lecture d’un segment précédent stocké dans la deuxième mémoire tampon M2, de sorte que les segments « tournent ». Le segment récupéré dans l’étape (b) sera bientôt lu à son tour.
On peut à présent répéter les étapes (a) et (b) tant que la lecture dure : l’application du délai stabilise l’ABR, et au pire, en cas de changement quand même du niveau de qualité requis par le lecteur du fait d’une nouvelle décision ABR, les segments seront à présent chargés depuis le réseau P2P conformément au nouveau niveau de qualité requis, de sorte que l’utilisateur n’aura aucune gêne.
Prédiction
De manière particulièrement préférée, l’étape (a) comprend en outre la prédiction d’une éventuelle prochaine décision ABR, i.e. la prédiction du niveau de qualité dans lequel le prochain segment sera requis (i.e. à la prochaine occurrence de l’étape (a)).
En effet, il est possible par application de la première fonction, de déterminer avant d’appliquer le délai de réponse calculé, si le niveau de qualité requis par l’ABR va changer.
On va supposer qu’un segment complet, de longueur p, a été fourni de sorte à faciliter les calculs. Ainsi, à l’issue de l’étape (b), le niveau de remplissage de la deuxième mémoire M2 aura augmenté de p, c’est-à-dire la longueur du segment. Par contre, le délai de réponse p s’est écoulé, et une durée identique du contenu de la deuxième mémoire M2 a été lue et supprimé, de sorte que le nouveau niveau de remplissage Bn peut être exprimé par rapport au précédent Bn- 1 (au moment de la dernière fourniture d’un segment) par la formule Bn=Bn-i + p - pn (on note qu’un calcul similaire peut être fait si le paramètre représentatif du débit de réception de segments est la bande-passante). Il suffit donc de calculer fi(Bn) pour prédire la prochaine décision d’ABR, et le cas échéant anticiper un changement de niveau de qualité et requérir les futurs segments dans le bon niveau de qualité (on parle de « pre-fetch »). Ainsi, la probabilité que l’utilisateur soit gêné est encore plus faible.
A noter que le procédé peut comprend une étape (c), à l’issue de l’étape (b), de vérification de la prédiction (le cas échant confondue avec une prochaine occurrence de l’étape (a)).
Plus précisément, la logique ABR est relancée pour calculer un « nouveau » niveau de qualité requis, i.e. le niveau de qualité requis pour le prochain segment, et une requête de segment correspondant va à ce titre être envoyée au logiciel client. La vérification consiste simplement à comparer le niveau de qualité prédit et le niveau de qualité en pratique requis, pour le prochain segment. Apprentissage
Selon un premier mode de réalisation, on suppose connue la première fonction, et la deuxième fonction peut être préconstruite à partir de cette première fonction.
Cependant dans d’autres cas, la première fonction peut être mal connue voire pas connue du tout si le lecteur est complètement fermé.
Alors, il est possible d’apprendre progressivement la première fonction et/ou la deuxième fonction, en se servant notamment de la prédiction de décision d’ABR comme moyen d’apprentissage : à chaque segment, on vient comparer à l’étape (c) la prédiction et la décision réellement prise, i.e. le niveau de qualité prédit et celui effectivement requis, ce qui constitue une boucle d’apprentissage.
On peut estimer la première ou la deuxième fonction en partant notamment d’une fonction par défaut, et en faisant évoluer ses paramètres au cours du temps. Par exemple, la première fonction peut être paramétrée via les valeurs des quatre paramètres Bmin, Rmin, Bmax et Rmax en supposant une fonction par morceaux à trois segments, et similairement la deuxième fonction peut être paramétrée via les valeurs des quatre paramètres Bmin, Pmin, Bmax et pmax en supposant une fonction par morceaux à trois segments (on a donc au total six variables).
Ainsi, sur les premiers segments du contenu le logiciel client va probablement calculer le délai de réponse manière imprécise, ce qui entraînera des décisions ABR imprévues et changement de niveau de qualité non maîtrisées, mais rapidement l’algorithme va s’améliorer et la logique ABR sera complètement maîtrisée.
Des algorithmes d’apprentissage peuvent notamment être utilisés, par exemple des réseaux de neurones.
A noter que les données sur la base desquelles l'apprentissage est fait peuvent être conservées entre sessions pour éliminer ou limiter les problèmes liés à la phase d'apprentissage lors des sessions subséquentes.
Certains facteurs, comme par exemple un changement sur le numéro de version du lecteur, peuvent être utilisés pour invalider les paramètres sauvegardés et repartir sur des paramètres vierges pour une nouvelle phase d'apprentissage.
Alternativement/en supplément, les fonctions apprises peuvent être transmis à d'autres pairs 12, par exemple via des messages P2P, ou au serveur de gestion de pairs 3. Equipement et produit programme d’ordinateur
Selon un deuxième aspect, l’invention concerne l’équipement client 11 pour la mise en œuvre du présent procédé de lecture d’un contenu, sur un lecteur adapté pour choisir le niveau de qualité des segments conformément à une logique de régulation adaptative du débit, ABR.
Cet équipement 11 comprend comme expliqué :
Une première mémoire tampon M1 stockant de façon temporaire au moins un segment 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, dans un format adapté pour la lecture par le lecteur ; et
des moyens de traitement de données 110.
Les moyens de traitement de données 110, typiquement un processeur, sont configuré pour implémenter, suite à la réception d’une requête d’un segment, la fourniture (au lecteur, typiquement par injection dans la deuxième mémoire tampon M2) dudit segment dans la première mémoire tampon M1 à l’expiration d’un délai de réponse défini par rapport à ladite logique ABR du lecteur.
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 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) sur lequel on trouve ce produit programme d’ordinateur.

Claims

REVENDICATIONS
1. Procédé de lecture en continu sur un lecteur d’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 disponibles dans une pluralité de niveaux de qualités et ledit lecteur étant adapté pour choisir le niveau de qualité des segments conformément à une logique de régulation adaptative du débit, ABR ; l’équipement client (11) comprenant une première mémoire tampon (M1) adaptée pour stocker des segments 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) Réception d’une requête d’un segment depuis le lecteur
(b) Fourniture en réponse dudit segment depuis la première mémoire tampon (M1) à l’expiration d’un délai de réponse défini par rapport à ladite logique ABR du lecteur.
2. Procédé selon la revendication 1 , dans lequel ladite logique ABR est définie par une première fonction permettant de calculer un niveau de qualité dans lequel ledit segment est requis en fonction d’au moins un paramètre représentatif d’un débit de réception de segments.
3. Procédé selon la revendication 2, dans lequel une deuxième fonction permet de calculer à l’étape (a) ledit délai de réponse en fonction dudit au moins un paramètre représentatif d’un débit de réception de segments.
4. Procédé selon la revendication 3, dans lequel la deuxième fonction est construite à partir de la première fonction.
5. Procédé selon l’une des revendications 3 et 4, dans lequel la deuxième fonction est monotone par rapport audit au moins un paramètre représentatif d’un débit de réception de segments.
6. Procédé selon l’une des revendications 1 à 5, dans lequel l’équipement (11) comprend en outre une deuxième mémoire tampon (M2) adaptée pour stocker des segments dans un format adapté pour la lecture par le lecteur, ledit segment étant fourni à l’étape (b) dans la deuxième mémoire tampon (M2).
7. Procédé selon l’une des revendications 2 à 5 et la revendication 6 en combinaison, dans laquelle ledit paramètre représentatif d’un débit de réception de segments est un niveau de remplissage de la deuxième mémoire tampon (M2) et/ou une bande-passante.
8. Procédé selon l’une des revendications 1 à 7, dans lequel l’étape (a) comprend la prédiction d’un niveau de qualité dans lequel le prochain segment sera requis en fonction du délai de réponse calculé.
9. Procédé selon la revendication 8, comprenant une étape (c) de vérification de ladite prédiction d’un niveau de qualité dans lequel le prochain segment sera requis.
10. Procédé selon la revendication 9, comprenant l’apprentissage de la deuxième fonction sur la base des niveaux de qualité prédits et effectivement requis.
11. Procédé selon l’une des revendications 1 à 10, dans lequel le segment requis est disponible de manière incomplète dans la première mémoire tampon (M1), l’étape (a) comprenant la modification du délai de réponse calculé en fonction d’une durée estimée nécessaire pour finir de récupérer le segment, le segment étant fourni de manière complète à l’étape (b) au plus tôt à l’expiration du délai de réponse modifié.
12. Equipement (11) pour la lecture en continu sur un lecteur 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 disponibles dans une pluralité de niveaux de qualités et ledit lecteur étant adapté pour choisir le niveau de qualité des segments conformément à une logique de régulation adaptative du débit, ABR ; l’équipement client (11) comprenant une première mémoire tampon (M1) adaptée pour stocker des segments dans un format adapté pour le transfert au sein du réseau pair-à-pair (10) et des moyens de traitement de données (110), l’équipement (11) caractérisé en ce que les moyens de traitement de données (110) sont configurés pour, suite à la réception d’une requête d’un segment depuis le lecteur, fournir en réponse ledit segment depuis la première mémoire tampon (M1) à l’expiration d’un délai de réponse défini par rapport à ladite logique ABR du lecteur.
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 diffusion d’un contenu en streaming dans un réseau pair à pair (10) d’équipements client (11 , 12, 13) connecté à un serveur de contenu (2), lorsque ledit programme est exécuté par 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 à 11 de diffusion d’un contenu en streaming dans un réseau pair à pair (10) d’équipements client (11 , 12, 13) connecté à un serveur de contenu (2).
PCT/EP2020/058709 2019-03-27 2020-03-27 Procédé de diffusion de contenus en streaming dans un réseau pair à pair WO2020193754A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
SG11202110647QA SG11202110647QA (en) 2019-03-27 2020-03-27 Method to stream contents in a peer-to-peer network
JP2021556863A JP7059509B1 (ja) 2019-03-27 2020-03-27 ピア・トゥ・ピアネットワークにおけるストリーミングコンテンツの配信方法
EP20713032.9A EP3949434A1 (fr) 2019-03-27 2020-03-27 Procédé de diffusion de contenus en streaming dans un réseau pair à pair
AU2020245087A AU2020245087B2 (en) 2019-03-27 2020-03-27 Method for broadcasting streaming content in a peer-to-peer network
CA3135076A CA3135076C (fr) 2019-03-27 2020-03-27 Procede de diffusion de contenus en streaming dans un reseau pair a pair
KR1020217035076A KR102472155B1 (ko) 2019-03-27 2020-03-27 피어 투 피어(Peer to peer, P2P) 네트워크에서 스트리밍 콘텐츠를 방송하는 방법

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR1903195 2019-03-27
FR1903195A FR3094597B1 (fr) 2019-03-27 2019-03-27 Procédé de diffusion de contenus en streaming dans un réseau pair à pair

Publications (1)

Publication Number Publication Date
WO2020193754A1 true WO2020193754A1 (fr) 2020-10-01

Family

ID=67262682

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2020/058709 WO2020193754A1 (fr) 2019-03-27 2020-03-27 Procédé de diffusion de contenus en streaming dans un réseau pair à pair

Country Status (9)

Country Link
US (3) US11128685B2 (fr)
EP (1) EP3949434A1 (fr)
JP (1) JP7059509B1 (fr)
KR (1) KR102472155B1 (fr)
AU (1) AU2020245087B2 (fr)
CA (1) CA3135076C (fr)
FR (1) FR3094597B1 (fr)
SG (1) SG11202110647QA (fr)
WO (1) WO2020193754A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021170594A1 (fr) * 2020-02-28 2021-09-02 Streamroot Procédé de lecture sur un lecteur d'un dispositif client d'un contenu diffusé en continu dans un réseau
CN114666609A (zh) * 2022-03-31 2022-06-24 北京奇艺世纪科技有限公司 视频数据下载方法、装置、电子设备及存储介质
US20220334746A1 (en) * 2021-04-14 2022-10-20 SK Hynix Inc. Storage device and operating method thereof

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3094597B1 (fr) 2019-03-27 2021-06-11 Streamroot Procédé de diffusion de contenus en streaming dans un réseau pair à pair
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
EP4080892A1 (fr) * 2021-04-20 2022-10-26 Streamroot Procédé de lecture d'un contenu diffusé dans un réseau sur le lecteur d'un dispositif client
EP4080891A1 (fr) * 2021-04-20 2022-10-26 Streamroot Procédé de lecture d'un contenu diffusé dans un réseau sur le lecteur d'un dispositif client
US11652876B2 (en) * 2021-07-22 2023-05-16 Rovi Guides, Inc. Assisted delivery service for networks
US11805169B2 (en) 2021-09-16 2023-10-31 Apple Inc. Content delivery network data sharing between mobile devices
EP4300916A1 (fr) * 2022-06-27 2024-01-03 Streamroot Dispositif de commande pour commander un joueur dans un réseau de poste à poste

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110255535A1 (en) * 2006-09-14 2011-10-20 Opentv, Inc. Method and systems for data transmission
US20120254456A1 (en) * 2011-03-31 2012-10-04 Juniper Networks, Inc. Media file storage format and adaptive delivery 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
WO2012154287A2 (fr) 2011-02-28 2012-11-15 Bittorrent, Inc. Diffusion en flux continu en direct poste à poste
US20150067722A1 (en) * 2013-09-04 2015-03-05 Arris Enterprises, Inc. Averting Ad Skipping in Adaptive Bit Rate Systems
US20150341812A1 (en) * 2003-08-29 2015-11-26 Ineoquest Technologies, Inc. Video quality monitoring
WO2015191177A1 (fr) * 2014-06-11 2015-12-17 Google Inc. Lecture de média de diffusion en continu améliorée
US20160285939A1 (en) * 2015-03-25 2016-09-29 Amazon Technologies, Inc. Determining initial bit rate for adaptive bit rate video playback
WO2016199098A1 (fr) * 2015-06-12 2016-12-15 Ericsson Ab Système et procédé pour gérer une distribution de débit binaire abr en réponse à des caractéristiques de mémoire tampon vidéo d'un client
US20180138998A1 (en) * 2015-04-07 2018-05-17 Axel DELMAS Method for continuously playing, on a client device, a content broadcast within a peer-to-peer network
US20180288458A1 (en) * 2017-03-31 2018-10-04 Intel Corporation Methods and apparatus for adaptive video transmission based on channel capacity

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2618328C (fr) * 2005-08-12 2015-12-15 Nokia Siemens Networks Gmbh & Co. Kg Systeme de transmission en continu de video a la demande flexible et multisource pour une communaute d'abonnes entre homologues
JP5529177B2 (ja) * 2011-01-19 2014-06-25 ネイバー ビジネス プラットフォーム コーポレーション Ｐ２ｐ基盤のストリーミングサービスでバッファリングを行うシステムおよび方法、並びにクライアントでバッファリングを処理するアプリケーションを配布するシステム
US8964977B2 (en) 2011-09-01 2015-02-24 Sonic Ip, Inc. Systems and methods for saving encoded media streamed using adaptive bitrate streaming
US8949440B2 (en) 2012-07-19 2015-02-03 Alcatel Lucent System and method for adaptive rate determination in mobile video streaming
EP2833640A1 (fr) * 2013-08-02 2015-02-04 British Telecommunications public limited company Mise en mémoire cache vidéo
US9699236B2 (en) 2013-12-17 2017-07-04 At&T Intellectual Property I, L.P. System and method of adaptive bit-rate streaming
US9769536B2 (en) * 2014-12-26 2017-09-19 System73, Inc. Method and system for adaptive virtual broadcasting of digital content
US9756112B2 (en) * 2015-02-11 2017-09-05 At&T Intellectual Property I, L.P. Method and system for managing service quality according to network status predictions
US9641578B2 (en) 2015-04-02 2017-05-02 Arris Enterprises, Inc. Minimizing unicast bandwidth in an adaptive bit rate system
WO2017063189A1 (fr) * 2015-10-16 2017-04-20 Qualcomm Incorporated Signalisation d'échéance de diffusion de données multimédias en continu
US20170272783A1 (en) 2016-03-16 2017-09-21 Telefonaktiebolaget Lm Ericsson (Publ) Architecture for interconnected set-top boxes
US11366909B2 (en) * 2016-06-10 2022-06-21 OneTrust, LLC Data processing and scanning systems for assessing vendor risk
US10728305B2 (en) * 2018-07-24 2020-07-28 At&T Intellectual Property I, L.P. Adaptive bitrate streaming techniques
US11509703B2 (en) * 2018-09-26 2022-11-22 Vmware, Inc. System and method for widescale adaptive bitrate selection
US11622140B2 (en) * 2018-12-19 2023-04-04 Yahoo Assets Llc Selective streaming of video segments based on buffer data and download rate range
FR3094164B1 (fr) * 2019-03-22 2021-10-29 Streamroot Procédé d’obtention d’un segment de données par un dispositif client apte à communiquer avec une pluralité de réseaux de diffusion de contenu
FR3094597B1 (fr) 2019-03-27 2021-06-11 Streamroot Procédé de diffusion de contenus en streaming dans un réseau pair à pair

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150341812A1 (en) * 2003-08-29 2015-11-26 Ineoquest Technologies, Inc. Video quality monitoring
US20110255535A1 (en) * 2006-09-14 2011-10-20 Opentv, Inc. Method and systems for data transmission
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
WO2012154287A2 (fr) 2011-02-28 2012-11-15 Bittorrent, Inc. Diffusion en flux continu en direct poste à poste
US20120254456A1 (en) * 2011-03-31 2012-10-04 Juniper Networks, Inc. Media file storage format and adaptive delivery system
US20150067722A1 (en) * 2013-09-04 2015-03-05 Arris Enterprises, Inc. Averting Ad Skipping in Adaptive Bit Rate Systems
WO2015191177A1 (fr) * 2014-06-11 2015-12-17 Google Inc. Lecture de média de diffusion en continu améliorée
US20160285939A1 (en) * 2015-03-25 2016-09-29 Amazon Technologies, Inc. Determining initial bit rate for adaptive bit rate video playback
US20180138998A1 (en) * 2015-04-07 2018-05-17 Axel DELMAS Method for continuously playing, on a client device, a content broadcast within a peer-to-peer network
WO2016199098A1 (fr) * 2015-06-12 2016-12-15 Ericsson Ab Système et procédé pour gérer une distribution de débit binaire abr en réponse à des caractéristiques de mémoire tampon vidéo d'un client
US20180288458A1 (en) * 2017-03-31 2018-10-04 Intel Corporation Methods and apparatus for adaptive video transmission based on channel capacity

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021170594A1 (fr) * 2020-02-28 2021-09-02 Streamroot Procédé de lecture sur un lecteur d'un dispositif client d'un contenu diffusé en continu dans un réseau
US11426655B2 (en) 2020-02-28 2022-08-30 Streamroot Method for playing on a player of a client device a content streamed in a network
US11925862B2 (en) 2020-02-28 2024-03-12 Streamroot Method for playing on a player of a client device a content streamed in a network
US20220334746A1 (en) * 2021-04-14 2022-10-20 SK Hynix Inc. Storage device and operating method thereof
US11836370B2 (en) * 2021-04-14 2023-12-05 SK Hynix Inc. Storage device and operating method thereof
CN114666609A (zh) * 2022-03-31 2022-06-24 北京奇艺世纪科技有限公司 视频数据下载方法、装置、电子设备及存储介质

Also Published As

Publication number Publication date
CA3135076C (fr) 2022-06-14
JP7059509B1 (ja) 2022-04-26
US20220021719A1 (en) 2022-01-20
US11689596B2 (en) 2023-06-27
US11128685B2 (en) 2021-09-21
SG11202110647QA (en) 2021-10-28
FR3094597B1 (fr) 2021-06-11
US20200351317A1 (en) 2020-11-05
AU2020245087B2 (en) 2021-12-09
EP3949434A1 (fr) 2022-02-09
JP2022524639A (ja) 2022-05-09
FR3094597A1 (fr) 2020-10-02
KR102472155B1 (ko) 2022-11-28
CA3135076A1 (fr) 2020-10-01
AU2020245087A1 (en) 2021-11-04
KR20210135338A (ko) 2021-11-12
US20230336600A1 (en) 2023-10-19

Similar Documents

Publication Publication Date Title
EP3949434A1 (fr) Procédé de diffusion de contenus en streaming dans un réseau pair à pair
WO2016162639A1 (fr) Procédé de lecture en continu sur un équipement client d'un contenu diffusé au sein d'un réseau pair à pair
KR102521753B1 (ko) 네트워크에서 스트리밍되는 콘텐츠를 클라이언트 디바이스의 플레이어에서 재생하기 위한 방법
WO2020259911A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d'un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d'ordinateur correspondants
KR20220158275A (ko) 네트워크에서 스트리밍되는 콘텐츠를 클라이언트 디바이스의 플레이어에서 재생하기 위한 방법
WO2021089942A1 (fr) Procédé de gestion de zapping de contenus multimédias numériques obtenu par téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d'ordinateur correspondants
EP3205067B1 (fr) Diffusion de contenus en streaming dans un réseau pair à pair
EP3926929B1 (fr) Procédé de gestion de la lecture d'un contenu numérique au sein d'un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
WO2021209706A1 (fr) Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau
WO2023208688A1 (fr) Gestion de la restitution d'un contenu multimédia
FR3114719A1 (fr) Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
EP4109905A1 (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.
EP4066512A1 (fr) Procédé de gestion d'une liste de contenus accessibles au zapping, les contenus numériques étant téléchargeables en mode de téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d'ordinateur correspondants
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
EP3840391A1 (fr) Gestion de la restitution d'un contenu multimédia et d'une interface de navigation sur un écran
FR3019429A1 (fr) Procede et dispositif de controle d'un telechargement de contenus multimedia
FR3135857A1 (fr) Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
FR3114720A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu tenant compte de la qualité du signal échangé entre le terminal client et le point d’accès au réseau
FR3093603A1 (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.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20713032

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021556863

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 3135076

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20217035076

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2020713032

Country of ref document: EP

Effective date: 20211027

ENP Entry into the national phase

Ref document number: 2020245087

Country of ref document: AU

Date of ref document: 20200327

Kind code of ref document: A