FR3114719A1 - Method for managing the reading of digital content within a multimedia content player terminal connected to a rendering device - Google Patents

Abstract

Method for managing the reading of digital content within a multimedia content player terminal connected to a playback device The invention relates to a method for managing the reading of digital content (C1) downloaded from a content server (SRV) via a communication network, the content comprising several segments, characterized in that it comprises the following steps: A prior step of obtaining a history of the variation of the bandwidth which has been available on the network over a past period of time; A step of receiving segments of the downloaded content and storing the received segments in a buffer memory; A step for determining a start time for reading the received data based on the bandwidth variation history obtained during the previous step. Figure 1

Description

Method for managing the reading of digital content within a multimedia content player terminal connected to a rendering device

The field of the invention is that of digital multimedia content, namely digital audio and/or video content.

More specifically, the invention relates to a method for managing the playback of digital content within a multimedia content player terminal connected to a playback device.

The rendering device is a device capable of rendering multimedia content. This restitution device has at least two data sources.

A data source targets a device capable of providing content to be rendered on the rendering terminal. The content reader terminal is a data source. Other data sources are for example a game console, hard drive, computer, etc.

A data source can be connected to the rendering device via a port such as an HDMI connection port, a USB port, etc.

It will be seen in an exemplary embodiment described below that the multimedia content player terminal chosen to illustrate the invention is a digital television decoder (set top box in English); The decoder referred to here is capable of requesting access to a content having several qualities available. Such content is, for example, content used in an adaptive progressive downloading (HAS) context in which the content is divided into segments, each segment being available according to several encoding bit rates associated with respective restitution qualities.

State of the art

Access to multimedia content, such as television or video on demand, from an Internet type network, is possible today, for most multimedia content playback terminals.

The reading terminal, for example a decoder, generally sends a request to a server indicating a chosen multimedia content. The decoder receives in return the requested multimedia content. In the context of a local communication network, such a request passes through a network access gateway, for example a residential/domestic gateway.

The reading terminal is suitable for receiving these digital contents in the form of multimedia data and for requesting a restitution on a restitution device. This restitution consists in supplying at the level of the reading terminal the digital content to the restitution terminal in a form accessible to the user. For example, received data corresponding to a video are generally decoded by the content playback device, then restored at the level of the restitution terminal in the form of a display of the corresponding video with its associated soundtrack. In the following, for the sake of simplicity, we will assimilate the digital content to a video and the restitution by the terminal, or consumption by the user of the terminal, to a visualization on the screen of the terminal.

The distribution of digital content on the Internet is often based on client-server protocols of the HTTP (Hyper Text Transport Protocol) family. In particular, downloading digital content in progressive mode, also called streaming, makes it possible to transport and consume data in real time, i.e. the digital data is transmitted over the network and decoded by the playback terminal. as they arrive. The reading terminal receives and stores part of the digital data in a buffer memory before commanding the restitution to the restitution terminal. This distribution mode is particularly useful when the bit rate available to the user is not guaranteed for the real-time transfer of the video.

Adaptive progressive downloading, in English HTTP Adaptive Streaming, abbreviated HAS, also makes it possible to broadcast and receive data according to different image qualities corresponding for example to different encoding bit rates. These different qualities are described in a parameter file available for download on a data server, for example a content server. When the content playback terminal wishes to access content, this description file makes it possible to select an image quality for the content to be consumed according to the available bandwidth or the storage and decoding capacities of the client terminal. This type of technique makes it possible in particular to take into account variations in bandwidth on the link between the playback terminal and the content server.

There are several technical solutions to facilitate the distribution of such streaming content, such as the proprietary solutions Microsoft® Smooth Streaming, Apple® HLS, Adobe® HTTP Dynamic Streaming or the MPEG-DASH standard of the ISO/ IEC which will be described below. These methods propose to send to the playback terminal one or more intermediate description files, also called documents or manifests, containing the addresses of the different segments with different qualities of the multimedia content.

Thus, the MPEG-DASH standard (for English "Dynamic Adaptive Streaming over HTTP", in French "diffusion in dynamic adaptive content over HTTP") is a standard for audiovisual broadcasting format on the Internet. This standard is based on the preparation of the content in different presentations of variable quality and encoding rates, cut into short segments (of the order of a few seconds), also called “chunks”. Each of these segments is made available by means of an exchange protocol. The protocol mainly targeted is the HTTP protocol, but other protocols (eg FTP) can also be used. Segment organization and associated settings are published in a manifest in XML format.

The principle underlying this standard is that the MPEG-DASH client makes an estimate of the bandwidth available for the reception of the segments, and, according to the filling of its reception buffer, chooses, for the next segment to be loaded, a representation whose encoding rate ensures the best possible image quality, and allows a reception time compatible with the uninterrupted restitution of the content on a restitution device.

Thus, to adapt to the variation in network conditions, particularly in terms of bandwidth, existing adaptive download solutions allow the playback terminal to switch from one version of the content encoded at a certain bit rate, to another encoded at another flow, during the download. Indeed, each version of the content is divided into segments of the same duration. To allow continuous playback of the content on the terminal, each segment must reach the playback terminal before its scheduled playback time. The perceived quality associated with a segment increases with the size of the segment, expressed in bits, but at the same time, larger segments require more transmission time, and therefore present an increased risk of not being received in time for continuous playback of content.

The reading terminal must therefore find a compromise between the overall quality of the content, and its uninterrupted reproduction, by carefully selecting the next segment to be downloaded, among the various encoding rates offered. To do this, there are different algorithms for selecting the quality of the content according to the available bandwidth, which can present more or less aggressive strategies, or more or less secure.

The consumption of digital content in adaptive progressive download (HAS) tends to become more democratic. It is used in particular by many streaming services (in French, streaming in continuous mode, or streaming), but also by certain TV decoders, or set-top-boxes, which use it to access delinearized content, such as video on demand (VOD), delayed broadcast of television programs (Replay), or even Network PVR-type offers (for "Network Personal Video Recorder", i.e. a digital content recording service, performed by the content provider itself rather than at the end user's home).

In addition, other devices such as real-time media player devices also access digital content in progressive adaptive download mode for real-time (or Live) television content. This is the case, for example, of the Chromecast® device developed by Google®, or the CléTV® from Orange®.

Such devices typically plug into a TV's HDMI port and act as a data source for the TV. These devices communicate, by Wi-Fi® connection, with another device of the domestic communication network connected to an extended communication network of the Internet type (residential gateway, computer, smart phone of the smartphone type, tablet, etc.), in order to restore, on the playback device, in this case a television, the multimedia content received by a compatible software application. These devices will be referred to below under the generic designation of HDMI Key.

Such devices can also be used to access video-on-demand type content, or to display personal content stored in the home network, such as a video of the last vacation or the last family event, on the television.

In a local area network, several devices share the available bandwidth more or less equally. This results in a large share of users (about 10-15%) who regularly have problems playing content on Live streams because the bandwidth they have is limited and is used by other services (Youtube, Netflix , IPTV, download, …).

Consequently, when playing content, if the bandwidth drops sharply, the client terminal does not have time to adapt and the playback of the content deteriorates for a few seconds before being able to switch to segments of lesser quality. Degradation is a pixelation of the image or a black image on the screen.

The invention improves the situation.

To this end, according to a functional aspect, the invention relates to a method for managing the reading of digital content downloaded from a content server via a communication network, the content comprising several segments, characterized in that it includes the following steps

A preliminary step of obtaining a history of the variation in bandwidth that has been available on the network over a past period of time;

A step of receiving segments of the downloaded content and storing the segments received in a buffer memory;

A step for determining a start time for reading the received data based on the bandwidth variation history obtained during the previous step.

The solution applies to any type of downloadable content, in particular downloadable content in the form of segments associated with different respective encoding bitrates as will be explained below.

Knowing the historical bandwidth that has been available over a past period helps to estimate future bandwidth. Indeed, we see that within the same household, habits of access to content are repeated periodically and these habits make access to the history of the household relevant.

The invention makes it possible to download a sufficient part of the content into the buffer memory in such a way as to ensure a continuous restitution of the content without degradation of the quality of the restitution. The invention in particular avoids a pixelation of the images or even a reproduction of a black screen for a few seconds.

The solution is of particular interest to “live” content. Indeed, unlike on-demand content (replay, NPVR (Anglo-Saxon acronym for "Network Personal Video Recorder" or VOD (Anglo-Saxon acronym for "video on Demand"), "live" or "stream Live" require that too many segments not be stored in the buffer memory of the client terminal so as not to introduce too many time gaps between the live stream, for example a live broadcast (e.g. sports competition), and what is The invention thus offers a good balance between the storage depth of the buffer memory while ensuring the smallest possible time lag between the Live content, for example a program broadcast live and what is rendered on the screen.

According to a first particular mode of implementation of the invention, the content comprises several segments associated with several respective encoding rates. In this configuration, the method includes receiving segment data and storing the received segments in the buffer memory; followed by a step of calculating an estimated download time of the content remaining to be downloaded taking into account a bandwidth from the history, a playback time of the content and an encoding bit rate chosen from the encoding bit rates available, the start time being chosen such that the estimated download duration of the content remaining to be downloaded is less than or equal to the duration of the content to be read. This first mode targets content accessible in the form of segments, each segment being available at different encoding rates. The chosen encoding bitrate can be one of the available bitrates.

According to a second particular mode of implementation of the invention, which may be implemented alternatively or cumulatively with the previous mode, the encoding rate chosen from among the available encoding rates is the maximum available encoding rate. In this second mode, the encoding rate chosen is the highest rate in kb/s. In this way, as the encoding bitrate actually sectioned by the playback terminal varies, and it rarely caps on the maximum value of the encoding bitrate, the calculation of the download time of the remaining content calculated on the basis of 'a maximum encoding bitrate represents a maximum duration. This maximum duration is then compared to the playback duration of the content. The result of these calculations is a start time which guarantees downloading of the remaining part to be downloaded before the end of the reading of the content. The reading takes place in this case without degradation.

According to yet another third particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding modes, the estimated network bit rate is the average network bit rate calculated over the given past period. This third mode offers a simple flow rate calculation; It therefore requires few physical and/or software resources in the stream reading terminal.

Bandwidth variation is an increase or decrease in bandwidth. According to yet another particular fourth mode of implementation of the invention, which may be implemented alternatively or cumulatively with the previous modes, distinct start times are predefined respectively. This fourth mode relies solely on history to determine the start time and does not require obtaining the content playback time and selecting an encoding bitrate. This mode therefore requires, like the previous mode, few physical and/or software resources in the stream reading terminal.

According to a material aspect, the invention relates to an entity for managing the reading of digital content downloaded from a content server via a communication network, the content comprising several segments accessible from a content server, characterized in that that he understands

A module for obtaining capable of obtaining a history of the variation of the bandwidth which has been available on the network over a past period of time;

A reception module capable of receiving the segments of the downloaded content and storing the segments received in a buffer memory;

A determination module capable of determining a start time for reading the received data based on the history of the bandwidth variation obtained during the previous step.

According to another material aspect, the invention relates to a multimedia content player terminal comprising an entity as defined above.

According to another material aspect, the invention relates to a computer program capable of being implemented on a multimedia content player terminal, the program comprising code instructions which, when it is executed by a processor, performs the process steps defined in the process defined above.

According to another material aspect, the invention relates to a data medium on which has been stored at least one series of program code instructions for the execution of a method as defined above.

The data medium can be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a RAM memory, a ROM memory, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means such as a hard disk. . On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention can in particular be downloaded from an Internet-type network. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.

Finally, it should be noted here that, in this text, the term "module" or "entity" can correspond both to a software component and to a hardware component or a set of hardware and software components, a corresponding software component itself to one or more computer programs or sub-programs or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware (or hardware) assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).

The invention will be better understood on reading the following description, given by way of example and made with reference to the appended drawings in which:

FIG. 1 represents a progressive downloading architecture on the Internet based on the use of adaptive streaming according to the invention;

FIG. 2 schematically illustrates the hardware structure of a real-time multimedia stream player terminal incorporating a management entity according to one embodiment of the invention;

FIG. 3 presents the main elements of the reader terminal as well as a schematic view of the different segments of a main content;

Figure 4 presents a history of the bandwidth over a given past period on which the calculation of the instant of reading of the content will be based.

FIG. 5 presents a view of the data exchanges between the content server and the key according to one embodiment of the invention.

Detailed description of embodiments of the invention.

We now present, in relation to FIG. 1, a progressive downloading architecture based on the use of HAS adaptive streaming according to one embodiment of the invention. It should be specified again here that the invention is not limited to HAS technology but extends to all other data download technologies.

The computer system SYS comprises a multimedia stream player terminal CLTV, for example an HDMI key connected to a TV reproduction terminal such as a television set.

In our example, the terminal CLTV is connected to a port of the television set TV and is therefore a data source for the television set TV.

In our example, the CLTV terminal is located in a local area network LAN controlled by a GTW home gateway. The context of the local network is given as an example and could easily be transposed to a "best effort" Internet network, a corporate network, etc.

The gateway GTW is able to communicate via a telecommunications network RES such as a wide area network WAN known to those skilled in the art.

A digital content server SRV is located according to this example in the wide area network WAN but it could either be located in the local area network LAN, for example in the home gateway GTW or any other equipment capable of hosting such a content server.

The content server SRV receives, for example, digital television content channels from a broadcast television network, not shown, and/or videos on demand, and makes them available to client terminals.

In our example, the reading terminal CLTV is a client terminal and can as such enter into communication with the content server SRV to receive one or more contents (films, documentaries, advertising sequences, etc.).

It is common, in this client-server context, to use, to exchange data between the CLTV client terminal and the SRV server, an adaptive progressive downloading technique, in English "adaptive streaming", abbreviated as HAS based on the protocol HTTP. This type of technique makes it possible in particular to offer good quality content to the user by taking account of the variations in bandwidth which may occur on the link between the CLTV client terminal and the GTW service gateway, and/or between this last and the content server SRV.

Conventionally, as will be seen with reference to FIG. 3, different qualities can be encoded for the same content of a string, corresponding for example to different encoding bit rates. More generally, we will speak of quality to refer to a certain resolution of the digital content (spatial, temporal resolution, level of quality associated with video and/or audio compression) with a certain encoding bit rate. Each quality level is itself cut on the content server into time segments (or “segments” of content, in English “chunks”, these three words being used interchangeably throughout this document).

The description of these different qualities and the associated temporal segmentation, as well as the content segments, is accessible by the client terminal and made available to it via their Internet addresses (URI: Universal Resource Identifier). All of these parameters (qualities, segment addresses, etc.) are generally grouped together in a parameter file, known as a description file or “MNF manifest”. It should be noted that this parameter file can be a computer file or a set of information descriptive of the content, accessible at a certain address.

In a context of progressive adaptive downloading, the CLTV terminal can adapt its requests to receive and decode the content requested by the user at the quality that best suits him. In our example, the contents are available, from weakest to strongest, at 416 kb/s (kilobits per second) speeds (Resolution 1, or level 1, noted (N1), 680 kb/s (N2), 1200 kb /s (N3); in this configuration, if the CLTV client terminal has a bandwidth of 5000 kb/s, it can request the content at any rate below this limit, for example 1200 kb/s. In general, “Ci@Nj” denotes the content number i with the quality j (for example the j-th quality level Nj described in the description file).

The number of encoding bitrates available per segment varies according to the playback terminal used. In FIG. 3, the content C1 comprises six encoding bit rates per segment, namely, from lowest to highest, 416 kb/s, 680 kb/s, 1200 kb/s, 1600 kb/s, 2100 kb/s and 5000 kbps.

The GTW service gateway is in this example a home gateway which ensures the routing of data between the wide area network WAN and the local area network LAN, manages the digital contents by ensuring in particular their reception from the network and the transmission to the reader terminal CLTV.

In this example, to view content, the CLTV terminal first interrogates the GTW service gateway to obtain an address of the MNF description file of the desired content (for example, C1). The GTW service gateway responds by providing the CLTV terminal with the address of the MNF description file. In the following, we will assume that this file is a file of the manifest type according to the MPEG-DASH standard (denoted "C.mpd") and we will refer indifferently, depending on the context, to the expression "description file" or " manifest".

Alternatively, this file can be retrieved directly from a local Internet server or external to the local network, or already be on the service gateway or on the terminal at the time of the request.

An example of a manifest file (MPD) compliant with the MPEG-DASH standard and comprising the description of content available in three different qualities (512 kb/s, 1024 kb/s, 2048 kb/s) of segmented content is presented in appendix 1 This simplified manifest file describes digital content in an XML syntax (from the English “eXtended Markup Language”), comprising a list of content in the form of segments conventionally described between an opening tag (<SegmentList>) and a closing tag ( </SegmentList>). Cutting into segments makes it possible in particular to adapt finely to fluctuations in bandwidth. Each segment corresponds to a certain duration (“duration” field) with several quality levels and makes it possible to generate their addresses (URL – Uniform Resource Locator). This generation is done in this example using the elements "BaseURL" ("HTTP://server.com") which indicates the address of the content server and "SegmentURL" which lists the complementary parts of the addresses of the different segments :

- "C1_512kb_1.mp4" for the first segment of the "C1" content at 512 kilobits per second ("kb") in MPEG-4 format ("mp4"),

- “C1_512kb_2.mp4” for the second segment,

- etc.

Once it has the segment addresses corresponding to the desired content, the GTW service gateway proceeds to obtain the segments via a download to these addresses. It should be noted that this download takes place here, traditionally, through an HTTP URL, but could also take place through a universal address (URI) describing another protocol (dvb://monsegmentdecontent for example).

The CLTV key is used to display a television program on the TV screen. Subsequently, this television program is referred to as content C1. Such C1 content is described in an MNF manifest file.

As a variant, it will be noted that the content C1 can be a television program broadcast on a deferred basis, or a video on demand, or a personal video of the user, or any other multimedia content of fixed duration, for which the invention applies. also applies.

The content segments obtained by the GTW residential gateway are, for example, transmitted via WiFi® to the CLTV key, which controls their display on the TV screen, for restitution to the user.

FIG. 2 represents an architecture of a reading terminal, in our example a CLTV key according to one embodiment of the invention.

The key CLTV conventionally comprises memories M associated with a processor CPU. The memories can be ROM (Read Only Memory) or RAM (Random Access Memory) or Flash.

The CLTV key includes a buffer memory also called cache memory or buffer by those skilled in the art

The CLTV key communicates with the local LAN network and the wide area Internet network WAN via the WIFI module for local wireless communication with the GTW residential gateway or another communication terminal of the local LAN network, for example the smartphone 3.

The CLTV key includes an adaptive progressive download module HAS capable of requesting a progressive download of one of the contents at one of the qualities offered in an MNF description file. This MNF description file can be saved for example in the memories M of the CLTV key or can be located outside.

The CLTV key further comprises a management mode MNG whose function will be explained below.

The CLTV key can also contain other modules such as a hard disk not shown for storing video segments, a content access control module, a module for processing commands received from the smartphone.

The CLTV key is connected to a TV set via an HDMI 1 link.

We now present, in relation to FIG. 3, the main elements of a CLTV key and a schematic view of a main content C1 stored in the content server SRV in the form of segments. More precisely, the HAS content server exposes a video C1 in the form of segments or "chunks" C1i@Nj encoded at different encoding rates Nj, where the index i designates a temporal identifier of the "chunk" C1i@Nj.

According to the prior art, the HAS download module of the CLTV key is responsible for recovering “chunks” from the HAS content server by choosing the video quality Nj according to the available network resource. The way in which the HAS download module chooses the encoding bit rate of the next video segment to be downloaded is not described here in more detail: there are in fact numerous algorithms allowing this choice to be made, the strategies of which are more or less safe or aggressive. It is recalled however that, most often, the general principle of such algorithms is based on the downloading of a first segment at the lowest encoding rate proposed in the manifest file, and on the evaluation of the recovery time of this first segment. Based on this, the HAS download module evaluates whether, depending on the size of the segment and the time taken to retrieve it, the network conditions allow the next segment to be downloaded at a higher encoding rate. Some algorithms rely on gradually increasing the quality level of downloaded content segments; others propose more risky approaches, with jumps in the levels of encoding bitrates of successive segments.

In the classic case, if a video “chunk” lasts 3 seconds, the recovery of the “chunk” by the HAS download module must not exceed 3 seconds, in order to allow uninterrupted restitution of the content by the CLTV key. It is therefore appropriate for the HAS download module to operate the best compromise between a restitution quality, and therefore an encoding bit rate, as high as possible, and the download time of the segment, which must be sufficiently low to allow a continuous playback on the TV set.

In the embodiment illustrated in FIG. 3, the HAS download module controls the download of a segment at the optimal encoding rate as described in more detail below.

Firstly, the HAS module retrieves the MNF manifest file which corresponds to the video content C1 in order to discover the available segments of the video content C1, and the various associated video qualities Nj. In the example of figure 3, the content C1 is for example offered in the form of segments of duration 3s, with a first encoding rate N1 = 416 kb/s, a second encoding rate N2 = 680 kb/s, a third encoding rate N3 = 1200 kb/s, etc.

In a normal operating mode, not illustrated in FIG. 3, the HAS module operates the downloading, for example, of successive segments C11@N1 (i.e. the first time segment at an encoding rate of 416 kb/s), then C12 @N3 (i.e. the second time segment at an encoding rate of 1600 kb/s), then C13@N3 (i.e. the third time segment at an encoding rate of 1200 kb/s), etc.

The various segments downloaded by the download module HAS are transmitted to an interface module INT for their restitution to the user on the television screen TV. The INT module manages the interface with the television set TV, through which it obtains, for example, information on the possible interactions of the user with the television set TV (action on the television remote control, for example by pressing the volume key or a channel change key), and by which it can control the display on the television screen TV of a requested content, for example a television channel or a navigation interface concomitantly.

The algorithm implemented by the HAS download module to determine which segment at which encoding bitrate should be downloaded in normal operating mode can be one of the already existing algorithms of the prior art. This algorithm will therefore not be described here in more detail.

According to the invention, the instant of starting the reading of the content is determined based on a history of the network speeds which have been available over a past period of time. The management module MNG will determine the quantity of data to be stored in the buffer memory before triggering the reading of the content.

Indeed, in order to ensure continuous playback of the LIVE content, when the user wishes to view it at the best possible quality, the digital stream reader will first pause the rendering of the content and fill its buffer memory. (or “buffer”) with the time segments of the LIVE content at an encoding rate higher than the encoding rate determined according to the availability of bandwidth.

This buffer filling phase is done as long as the stream reader has not stored enough content, or time segments, in memory to then ensure smooth playback.

Once the stream reader has buffered, or stored, enough time segments of the content, the stream reader then enters a deferred rendering phase, i.e., in playback mode of the content. This delayed rendering occurs in conjunction with the buffering of subsequent time segments of the content.

Thus, during playback, the buffered video is consumed and time segments representative of the streamed video are continued to download, so as to continue to fill the buffer until the history-based start time. as explained below.

Figure 4 illustrates a history showing the variation in available bandwidth over a given past period, in particular Thursday, September 10, 2020 and Friday, September 11, 2020. This history is illustrated in the form of a graph having the time t as the abscissa and the ordered the value of the bandwidth BP.

A first embodiment may consist of defining the start time, or the buffer occupancy rate, based on the variation of the past bandwidth over a given past period.

A variation of the bandwidth can consist of an increase or a decrease in the bandwidth.

In our example, for the two types of variation, two respective playback start times are predefined. A start time is set when bandwidth is likely to increase; similarly, a start time is set when the bandwidth is likely to decrease. In our example, the start takes place when the buffer reaches a given occupancy rate by downloaded segments. These two percentages are for example 20% and 60%, respectively.

Note that the variation can be obtained in several ways known to those skilled in the art, for example by calculating a slope of a straight line over a given duration or the slope of a tangent obtained by calculating the derivative.

More specifically, in the event that the probable bandwidth drops, it is necessary to store in the buffer memory a significant part of the video content to be rendered. With reference to figure 4, this case arises for example if the content is accessed on Thursday at 9 p.m. Indeed, the graph illustrated in Figure 4 shows that the bandwidth drops after 9 p.m. (an arrow F1 indicates the decrease in bandwidth). In this case, the management module MNG downloads for example 60% of the video content before triggering the reading of the content.

In the event that the probable bandwidth will grow, it is not necessary to store a significant part of the video content to be rendered. With reference to figure 4, this case arises for example if the content is accessed on Friday at 9 p.m. Indeed, the graph shown in Figure 4 shows that the bandwidth increased after 9 p.m. on Friday at the same time (an arrow F2 indicates the increase in bandwidth). The management module downloads 20% of the video content before triggering its playback on Friday at 9 p.m.

FIG. 5 illustrates a second embodiment for calculating the start time of the reading of the content C1 based on the history illustrated in FIG. 4. This second mode can be implemented alternatively or cumulatively with the previous mode of achievement.

Figure 5 shows two axes associated with the content server from which C1 and the CLTV key are downloaded, as well as the data exchanges taking place between these two devices.

During a first step ET1, the key CLTV requires access to the content C1 from the server SRV.

At time T0, during a second step ET2, after receiving the request, the server SRV successively downloads segments (C11@N1, C12@N5, C13@N6, C14@N6, etc.) C1 according to the technique described above of adaptive downloading.

The segments are successively received by the CLTV key and are stored in the buffer memory of the CLTV key.

The management entity MNG determines, during the downloading of the content C1, the instant T1 of starting the reading of the downloaded content. According to the invention, the start of the reading of the content takes place when the expected download duration of the content remaining to be downloaded is less than or equal to the duration of the content to be read.

The system will therefore determine from the history what the probable available bandwidth will be in the minutes or hours to come.

In this second mode, the download time is calculated taking into account

- the past bandwidth Dmoy, for example an average as explained above,

- Dlct.C1 content playback duration,

- and also an encoding bitrate of the segments to be downloaded chosen from the encoding bitrates available in the manifest.

In this mode, the management module MNG calculates an estimated value of the network throughput Dmoy which has been available over a past period. The past period is preferably chosen judiciously, for example the previous week at the same time.

The duration of this past period is also chosen judiciously. For example, this duration starts at the time of access to the content until, for example, the switching off of the television set TV on the same day, in particular when the duration of the content cannot be known in advance.

If the duration of the content to be rendered is known in advance; this is the case for example of on-demand content such as VOD content (Anglo-Saxon acronym for Video On Demand) the duration of the past period can be the duration of the content to be read. For example, if the user accesses VOD content with a duration of 2 hours on a Friday at 9 p.m.; in our example, the past period corresponds to Friday of the previous week and the duration of the past period corresponds to the duration of the VOD content to render, namely two hours.

In our example, the estimated value is an average value of the network speeds that have been available over this past period. The use of an average is only one example of implementing the invention; another flow could have been calculated instead of the average flow, for example based on a calculation of the median, a range or quartiles, or any equivalent statistical formulas.

Not knowing the future network bitrate and a fortiori the future encoding bitrates selected by the CLTV key, the maximum encoding bitrate of the manifest can be selected for the calculation of the start time; indeed, the maximum encoding bitrate is the one that will consume the most bandwidth.

The calculation of this content playback start time can be as follows, without being limited to this:

At time T1, it is considered that a part C1a of the content has been received and stored in buffer memory.

The complementary part C1b of C1 (C1= C1a+C1b) is the remaining part to download.

The quantity of remaining segments to download C1b is given by the formula:

C1b = Davg X Dtch.C1b,

Dtch.C1b being the duration available to download C1b

When the start of the reading takes place at T1, there will remain the entire duration Dlct.C1 of reading the content C1 to download the remaining part C1b. The following condition must therefore be met to ensure that the content will be played without degradation:

Dtch.C1b ≤ Dlct.C1

either :

C1b / Davg ≤ Dlct.C1

DlctC1 corresponding to the total playback time of content C1.

In our example, we want the playback to be uninterrupted. An embodiment will be described hereinafter with interruption.

The quantity of segments remaining to be downloaded C1b corresponds to the quantity of total segments of C1 minus the quantity of segments already downloaded C1a.

As a quantity of data received corresponds to the download time multiplied by the encoding rate used, we can write that

C1b = (Dtch.C1 – Dtch.C1a) X From

Either

C1b = (Dtch.C1b) X From

With From = content encoding bitrate chosen from the list of bitrates included in the manifest.

And

Dtch.C1 = total content download time C1

Several encoding bitrates are defined in the manifest. The encoding bit rate requiring a longer transmission time is that of better quality, namely the maximum encoding bit rate Demax 5000 kb/s in our example. In our example, we therefore choose this maximum value for the calculation of the start time of reading, i.e.:

De = Demax.

We then arrive at the following condition for starting the reading of C1

Dlct.C1

The reading of C1 can therefore begin at T1 when the duration Dtch.C1a has reached the following condition is verified:

Dtch.C1a (1- ) X Dlct.C1

In our example, we choose

T1=(1- ) X Dlct.C1

Once the reading of the content C1 has started at the instant T1, T1 verifying the previous condition, the downloading of the segments of the complementary content C2a is carried out conventionally as explained above according to the HAS technique.

Let's take two examples. We consider :

- content lasting 2h28 (148 min),

- associated with a manifest including a maximum video encoding rate Demax equal to 5000 kb/s,

- and a network speed estimated at 4Mb/s over a judiciously calculated past period.

In this configuration, playback will begin at

T1= (1-4000/5000)*148 = 29.6 mins

The download of C1a will then have taken 29.6 minutes.

If the estimated network speed is 2 Mb/s:

Playback cannot start until (1-2000/5000)*148 = 88.8 minutes after downloading starts.

The download of C1a will then have taken 88.8 minutes.

The embodiment described above has the advantage of ensuring reading without degradation. Another more risky variant may consist in taking not the maximum encoding rate but an intermediate encoding rate. For example, using the manifest example described above, the received encoding bitrate could have been 1600 kb/s or 2100 kb/s.

FIG. 5 shows the duration Dtlc.C1a for downloading C1a, the duration for downloading C1b, namely Dtcl.C1b. In this figure, we see that the download time of C1b, namely Dtcl.C1b, is ultimately less than the Dlct.C1 playback time of the content C1. Indeed, the downloaded segments relating to C1b were not all associated with the maximum rate Demax.

Annex 1

Claims (8)

Method for managing the reading of digital content (C1) downloaded from a content server (SRV) via a communication network (RES), the content comprising several segments, characterized in that it comprises the following steps:
A preliminary step of obtaining a history of the variation of the bandwidth that has been available on the network (RES) over a past period of time;
A step of receiving segments of the downloaded content and storing the segments received in a buffer memory;
A step of determining a start time for reading the data received based on the history of the bandwidth variation obtained during the prior step. Management method according to claim 1, characterized in that the content comprises several segments associated with several respective encoding bit rates, and in that the reception step is followed by a step of calculating an estimated download time of the content remaining to be downloaded, taking into account a bandwidth from the history, a content playback time and an encoding bit rate chosen from among the available encoding bit rates, the start time being chosen such that the estimated download time of the content remaining to be downloaded is less than or equal to the duration of the content to be played. Management method according to Claim 2, characterized in that the encoding rate chosen from among the available encoding rates is the maximum available encoding rate. Management method according to Claim 2, characterized in that the estimated network bit rate is the average network bit rate calculated over the given past period. Management method according to Claim 1, characterized in that the variation of the bandwidth comprises an increase or a decrease in the bandwidth, in that distinct start times are predefined respectively. Management entity (MNG) for reading digital content downloaded from a content server via a communication network, the content comprising several segments accessible from a content server, characterized in that it comprises
an obtaining module capable of obtaining a history of the variation of the bandwidth which has been available on the network over a past period of time;
A reception module capable of receiving the segments of the downloaded content and storing the segments received in a buffer memory;
A determination module capable of determining a start time for the reading of the data received based on the history of the variation of the passband obtained during the preliminary step. Multimedia content player terminal (CLTV) comprising an entity as defined in claim 6. Computer program capable of being implemented on a multimedia content player terminal as defined in claim 7, the program comprising code instructions which, when executed by a processor, carry out the steps of the method defined in one of claims 1 to 5.