Classifications

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

Definitions

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

Landscapes

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

Applications Claiming Priority (2)

Publications (1)

Family

ID=54783686

Family Applications (1)

Country Status (4)

Families Citing this family (7)

Family Cites Families (35)

• 2015
  • 2015-04-07 FR FR1552976A patent/FR3034943B1/fr active Active
• 2016
  • 2016-04-07 EP EP16721873.4A patent/EP3281411A1/de not_active Withdrawn
  • 2016-04-07 WO PCT/FR2016/050797 patent/WO2016162639A1/fr active Application Filing
  • 2016-04-07 US US15/564,392 patent/US10341035B2/en active Active

Also Published As

Similar Documents

Legal Events