FR3096210A1 - A method of transmitting digital content having several versions accessible from a content server to a playback terminal. - Google Patents

Abstract

The invention relates to a method for transmitting content to a rendering terminal (8) via a communication network, the content (C1) being accessible from a content server in several versions associated with qualities. respective rendering, a given version respectively comprising several segments of the content, characterized in that it comprises the following steps in a device (DI) inserted between the content server and the rendering terminal a first reception step during of which the intermediate device receives from the content server several versions of the same content; a second step of receiving a request for access to a given version of the content; and a step of transmitting, to the rendering terminal, segments associated with the version of the content requested during the second reception step. FIGURE 1

Description

Method for transmitting digital content with several versions accessible from a content server to a rendering terminal.

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

Specifically, multiple versions of the content are available; the invention relates to a method for transmitting digital content having several versions accessible from a content server to a rendering terminal.

Content versions, also called content representations, are associated with respective rendering qualities.

State of the art

With the generalization of high-speed wireless communication and the proliferation of personal equipment of the smart phone or tablet type, the consumption of digital multimedia content, in particular video and/or audio, has increased sharply. Indeed, access to digital content from an Internet type network is possible today, for most of these personal devices, in particular when they belong to a local communication network, such as a home network.

The distribution of digital content on the Internet is often based on client-server protocols of the HTTP (Hyper Text Transfer Protocol) family. In particular, downloading in progressive mode, called progressive adaptive downloading (in English "http Adaptive Streaming" or HAS), of digital content, also called streaming, makes it possible to transport and consume data in real time, i.e. say that digital data is transmitted over the network and returned by the terminal as it arrives. The client terminal, i.e. the personal equipment, receives and stores part of the digital data in a buffer memory before restoring it. 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 (HAS) also makes it possible to broadcast and receive data according to different qualities, also called representations or versions, corresponding for example to different 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 client terminal wishes to access a content, this description file makes it possible to select the correct format for the content to be consumed, in particular 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 client 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 the client one or more intermediate description files, also called documents or manifests, containing the addresses of different segments at different encoding qualities of the multimedia content.

Thus, the MPEG-DASH standard (for English “Dynamic Adaptive Streaming over HTTP”, in French “Dynamic adaptive streaming over HTTP”) is an audiovisual format standard for broadcasting on the Internet. It is based on the preparation of the content in different presentations of variable quality and bit rate, cut into short time segments (of the order of a few seconds), also called “chunks”, or segments. Each of these segments is made available individually by means of an exchange protocol. The protocol mainly targeted is the HTTP protocol, but other protocols (eg FTP) can also be used. The organization of the segments and the associated parameters 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 segments, and, depending on the filling of its reception buffer, chooses, for the next segment to load , a quality/version whose bit rate:
- ensures the best possible quality, and,
- allows a reception time compatible with the uninterrupted rendering of the content on the client terminal.

Thus, to adapt to varying network conditions, particularly in terms of bandwidth, existing adaptive download solutions allow the client terminal to switch from one version of the content encoded at a certain bit rate, to another encoded at a other speed, 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 client terminal, each segment must reach the 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 rendering terminal must therefore find a compromise between the overall quality of the content, and its uninterrupted rendering, by carefully selecting the next segment to be downloaded, from 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.

There are many services for viewing this digital content, such as streaming services (in French, streaming, or streaming), video on demand (VOD), delayed broadcast of television programs (Replay) , or Network PVR-type offers (for “Network Personal Video Recorder”, ie a digital content recording service performed by the content provider itself rather than at the end user's home).

A big problem with the use of HAS adaptive progressive downloading is that it is based on content transmission in point-to-point mode, which inevitably leads to a heavy load on content distribution platforms and a heavy load on the operator's network impacting the bandwidth offered by the operator on its network. More specifically, “LIVE” content broadcast using the HAS technique requires a single session for each user between the server and the multimedia terminal. This requires sizing content distribution servers accordingly and sometimes leads to service interruptions when "LIVE" content is in high demand (sporting event such as a football match, for example). The distribution of HAS content is well suited for on-demand content (VOD, Replay, etc.) but consumes a lot of network resources (server and bandwidth) for live content (“LIVE”).

There is therefore a need for a technique making it possible to reduce the consumption of network resources during the distribution of content according to the HAS technology, while maintaining an image quality at least as good as that provided by current techniques.

The Invention

The invention meets this need by proposing a method for transmitting content to a playback terminal via a communication network, the content being accessible from a content server in several versions associated with respective playback qualities. , a given version comprising respectively several segments of the content, characterized in that it comprises the following steps in a device interposed between the content server and the rendering terminal

- a first reception step during which the intermediate device receives several versions of the same content from the content server;

- a second step of receiving a request for access to a given version of the content;

- And a step of transmitting, to the restitution terminal, segments associated with the version of the content requested during the second reception step.

The transmission of requests for access to content from rendering terminals no longer takes place to the content server but to an intermediate device located between the content server and the rendering terminal. It will be seen below that the location of the intermediate device will be chosen as close as possible to the restitution terminal; in this way, the different versions of the digital content are located as close as possible to the user, implying the restitution terminal. The relocation of different versions of a content in the intermediate device makes it possible to considerably reduce the load on the content server because the communication is no longer in point-to-point mode between the content server and the rendering terminal as in the state of technique.

With the invention, the content server is limited to the transmission of versions of the same content to intermediate devices. The intermediate device is in charge of transmitting a version of the segments chosen judiciously for each playback terminal. Two embodiments will be described below for determining the versions (or qualities) of the segments to be transmitted; a first mode based on the HAS technology introduced previously and whose use requires a manifest file which will be described later; and a second mode based on another technology in which the receiving terminal comprises a receiving module capable of requesting, without using a manifest file, an increase, or a decrease, or a maintenance of the version of the segments to be transmitted from the intermediate device.

The location chosen for the intermediate device is ideally a device having a function of routing data streams to the restitution terminals and which is ideally capable of creating groups of subscriptions making it possible to bring together users wishing to access the same digital content by same time, especially "live" content such as a TV channel.

According to a first embodiment, the version chosen for at least the first time segment transmitted is a version chosen by default. This first mode aims to transmit first preference segments of a version having a low number of bytes and therefore associated with a low quality of reproduction. This first mode makes it possible to transmit the first segments fairly quickly, due to the small size, to the restitution terminal concerned, so that the first segment(s) are received before their scheduled time(s). ) restitution, respectively; the restitution is carried out in this case without problem. It will subsequently be seen that the version of the segments transmitted varies over time thereafter.

According to a second embodiment, which may be implemented alternatively or cumulatively with the previous one, the choice of the version of a later segment evolves according to data from the restitution terminal, said data being from a comparison between the transmission duration of a previously transmitted segment and the duration of the time segment. This second mode avoids the use of a manifest file defining several possible versions of the segments. In this second mode, the restitution terminal does not specify a precise value of a version but a trend, namely an increase, or a decrease, or a maintenance of the version for the future segments to be transmitted from the intermediate device.

According to a third embodiment, which may be implemented alternatively or cumulatively with the previous ones, the content received during the first reception step is content transmitted in multicast mode. This third embodiment takes advantage of the advantages of multicast content broadcasting while allowing, thanks to the presence of the intermediate device, to select the best version of the time segment to be transmitted to a playback terminal.

According to a fourth embodiment, which may be implemented alternatively or cumulatively with the previous ones, the reception step is followed by a step of storing in memory the segments received from the content server; in this fourth embodiment, the step of transmitting a time segment of a given version leads to the deletion in the memory of the intermediate device of the other versions of the transmitted segment. This second mode makes it possible to delete segments which have already been restored and thereby to increase the memory space available for storing other segments in the intermediate device.

According to a first material aspect, the invention relates to a computer program product comprising program code instructions for the implementation of a method for transmitting digital content according to the transmission method described above , when executed by a processor.

According to a second material aspect, the invention relates to a recording medium readable by a computer on which is recorded a computer program as described above.

According to a third material aspect, the invention relates to a device, called an intermediate device, capable of communicating with a content server and with rendering terminals via a communication network, a content being accessible from the content server in several versions , a given version comprising respectively several segments of the content,

including:

at. a first reception module capable of receiving several versions of the same content from the content server;

b. a second reception module able to receive a request for access to a given version of a content;

vs. a transmission module capable of transmitting, to the restitution terminal, segments associated with the version of the content requested during the second reception step.

According to a second functional aspect, the invention relates to a method of access by a playback terminal to digital content accessible from a device, called an intermediate device, several different versions of the content being accessible, a given version respectively comprising several segments content having respective durations, characterized in that it comprises the following steps

- a reception step during which the rendering device receives a segment of a given version of the content from the intermediate device (DI);

- a second step of measuring the duration of transmission of the segment received and comparing it with the duration of the time segment,

- depending on the result of the measurement step, a transmission step or not, to the intermediate device, of a request for access to another version.

According to a fourth material aspect, the invention relates to a playback terminal comprising playback of digital content accessible from a device, called an intermediate device, several different versions of the content being accessible, a given version respectively comprising several segments of the content, characterized in that it comprises

- a reception module capable of receiving a segment of a given version of the content from the intermediate device;

- a measurement module able to measure the duration of transmission of the segment received and to compare the duration measured with the duration of the time segment,

- a transmission module capable of transmitting or not, to the intermediate device, a request for access to another version depending on the result of the measurement step.

According to a fifth material aspect, the invention relates to a computer program product comprising program code instructions for the implementation of an access method defined above, when it is executed by a processor .

According to a fourth material aspect, the invention relates to a recording medium readable by a computer on which is recorded a computer program defined above.

The intermediate device, the rendering device, and the aforementioned corresponding computer programs/recording media have at least the same advantages as those conferred by the transmission method according to the various embodiments of the present invention.

Brief description of figures

Other aims, characteristics and advantages of the invention will appear more clearly on reading the following description, given by way of a simple illustrative example, and not limiting, in relation to the figures, among which:

shows an internet progressive downloading architecture based on the use of adaptive progressive downloading according to the invention;

schematically illustrates the hardware structure of a playback device according to one embodiment of the invention;

schematically illustrates several versions of the same content according to one embodiment.

schematically illustrates the hardware structure of a playback device according to one embodiment of the invention;

illustrates an embodiment in which segments corresponding to a transmitted segment are deleted from the intermediate device to increase the memory space available in the intermediate device.

schematically illustrates another embodiment in a computer system comprising several intermediate devices.

Detailed description of the invention

We now present, in relation to FIG. 1, an example of a computer system in which the invention can be implemented.

This system comprises several restitution terminals: A terminal 3, for example a smart phone of the "Smartphone" type, a terminal 4, for example a laptop computer, and a terminal 8, for example an HDMI key connected to a television 5. These restitution terminals, also called client terminals, are in this example located in a local area network (LAN, 10) controlled by a home gateway 6. The context of the local area network is given by way of example and could easily be transposed to a Internet network of the "best effort" type, a corporate network, etc.

A digital content server 2 is located according to this example in the wide area network (WAN, 1). The content server 2 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 the prior art, the terminals 3, 4 and 8 can enter into communication with the content server 2 to receive one or more contents (films, documentaries, advertising sequences, etc.). In general, a terminal sends a request to a content server 2, indicating the chosen content and it receives in return a stream of digital data relating to this content. In the context of a local communication network, such a request passes through the network access gateway, for example the residential gateway.

The rendering terminal is suitable for receiving these digital contents in the form of multimedia data and for rendering them. This restitution consists of providing the terminal with the digital content in a form accessible to the user. For example, received data corresponding to a video are generally decoded, then restored at the terminal level in the form of a display of the corresponding video with its associated soundtrack.

It is common, in this client-server context, to use, to transmit the data to the client terminals 3, 4 and 8, an adaptive progressive downloading technique, in English “adaptive streaming”, abbreviated as HAS based on the HTTP protocol. . This type of technique makes it possible in particular to offer a good quality of content to the user by taking into account the variations in bandwidth which may occur on the link between the client terminal 3, 4 and 8 and the service gateway 6, or between the latter and the content server 2.

Conventionally, different qualities can be encoded for the same content of a channel, corresponding for example to different bitrates. 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 bit rate, sometimes also of version or representation. Each quality level is itself cut on the content server into time segments (“chunks”), these two words being used interchangeably throughout this document).

The description of these different qualities and the associated temporal segmentation, as well as the content segments, are described for 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, called a description file or 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.

These segments or “chunks” comprise a set of data representative of the content. In the example of a video, each “chunk” of the video notably comprises a first image called an “I” image, or intra, and one or more images which can be predicted from this I image by estimation/compensation of movement.

Terminals 3, 4 and 8 have their own characteristics in terms of decoding capability, display, etc. In a context of progressive adaptive downloading, they can adapt their requests to receive and decode the content requested by the user at the quality that suits them best. In our example, if the content is available at bit rates of 512 kb/s (kilobits per second) (Resolution 1, or level 1, denoted D1), 1024 kb/s (D2), 2048 kb/s (D3) and the client terminal has a bandwidth of 3000 kb/s, it can request the content at any rate below this limit, for example 2048 kb/s. In general, “Ci@Dj” denotes the content number i with the quality j (for example the j-th quality level Dj described in the description file).

The service gateway 6 is in this example a home gateway which ensures the routing of data between the extended network 1 and the local network 10, manages the digital contents by ensuring in particular their reception from the network and their decoding thanks to a reader of multimedia stream (not shown), also called a decoder which is assumed here to be integrated into client terminals 3, 4 and 8.

In this example, to view content with the HAS technique, the terminal 3, 4 or 8 first interrogates the service gateway 6 to obtain an address of the description document 7 of the desired content (for example, C1). The service gateway 6 responds by providing the terminal with the address of the description file 7. In what follows, it will be assumed that this file is a manifest type file according to the MPEG-DASH standard (denoted “C.mpd”) and will refer interchangeably, 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) conforming to the MPEG-DASH standard and comprising the description of content available in three different qualities (D1 = 512 kb/s, D2 = 1024 kb/s, D3 = 2048 kb/s) of content segments 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 service gateway 6 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 terminals 3, 4 or the television set 5, for example via its connection to an HDMI key 8 by plugging into its HDMI port, are used to reproduce digital content such as a television program broadcast live ("live") or in deferred, video on demand, etc. Subsequently, this television program is referred to as content C1. Such C1 content is described in a manifest 7 file.

In one example, a user wishes to view multimedia content, such as a television program, on his television set 5 connected to an HDMI key 8. The HDMI key 8 is connected via WiFi® directly to the residential gateway 6. Alternatively, the HDMI key 8 could also be connected via WiFi® to another nomadic peripheral of the home network, for example to the laptop computer 4 or to the smart telephone 3, via which it could access the extended communication network 1.

The HDMI key 8 can also be controlled by the user by means of the smartphone 3, on which a software application for controlling the HDMI key 8 is installed.

The content segments obtained by the residential gateway 6 are for example transmitted via WiFi® to the HDMI key 8, which controls their display on the television screen 5, for restitution to the user after decoding by a multimedia stream player 9 .

FIG. 2 represents an architecture of a playback device according to one embodiment of the invention. This device conventionally comprises memories M associated with a processor CPU. The memories can be of the ROM ( Read Only Memory ) or RAM ( Random Access Memory ) type, or else Flash. In the embodiment, the rendering device comprises an HAS adaptive progressive downloading module, capable of requesting a progressive downloading of one of the contents at one of the qualities offered in a description file 7. In a second mode of realization, it will be seen that this HAS module can be replaced by a reception module.

The description file 7 can be recorded for example in the memories M of the multimedia stream player 9 or can be located outside.

The playback device can also contain other modules (not shown) such as a hard disk for storing video segments, a content access control module, a module for processing commands received from a tablet, a Smartphone, or a remote control, thanks to which the user can control its operation, etc.

It will be noted that the term module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more programs or computer 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. .).

As indicated previously, in the prior art, the client terminals 3, 4 and 8 can enter into communication with the content server 2 to receive one or more contents (films, documentaries, advertising sequences, etc.). In general, a terminal sends a request to a content server, indicating the chosen content and it receives in return a stream of digital data relating to this content. A big problem with the use of HAS technology is that it is based on point-to-point connections which inevitably lead to a heavy load on the content server and on the operator's network as explained above. Unlike "LIVE" content broadcast in multicast, the associated data streams of which are replicated as close as possible to the consumer, content broadcast in HAS requires a single session for each user. This requires sizing content distribution servers accordingly.

To solve this problem, the system of the invention comprises a device DI, called in the following intermediate device, which is inserted on the network between the content server 2 and the rendering terminal(s) 3, 4 and 8. will see below in several embodiments that the system can include one or more intermediate devices.

According to the invention, the transmission of a digital content according to the invention takes place in two phases.

The intermediate device DI receives from the content server 2, during a first phase, several versions of the same content, the versions being respectively associated with respective restitution qualities.

During a second phase, the intermediate device DI provides the version of the content to the rendering terminal that is most suited to the environment of the rendering terminal.

Two embodiments will be described below. A first mode will be described in which the reception module installed in the rendering terminal is an HAS adaptive progressive download module as described above, and in which a manifest file is used. A second mode will be described in which the module is a receive mode that does not use a manifest file as will be explained below. In this second mode, to determine the version of the subsequent segments, the reception module measures the transmission time of a segment from the content server 2 to the restitution terminal concerned and then compares this reception time with the duration of the segment. Depending on the result, the terminal requests, from the intermediate device to which it is connected, another version for the following segments or a maintenance of the version.

According to the first embodiment, the adaptive progressive download module HAS present in the restitution terminal requests the intermediate device DI to progressively download one of the contents to one of the qualities offered in a description file 7.

In the following, in order to simplify the presentation, a single digital content C1 will be considered to illustrate an access. The invention is not limited to this example but, on the contrary, extends to an indeterminate number of contents.

In general, a content corresponds to a set of segments C1i@Dj encoded at different encoding rates Dj, where the index i designates a temporal identifier, or position, of the "chunk" C1i@Dj in the digital content .

During the first phase, the digital content server 2 transmits different versions of the same digital content, the versions being associated with different versions of the digital content considered. More precisely, in our example, with reference to FIG. 1, the content server 2 transmits a first version C1/500 of the digital content; this first version with D1 equal to 500kb/s of the digital content includes a set of segments C1i@D1 encoded at a first encoding rate D1, where the index i designates a temporal identifier, or position, of the “chunk” C1i@ D1.

Referring to Figure 1, the content server 2 also transmits in the same way a second version C1/1000, a third version C1/2000, a fourth version C1/3000 and a fifth version C1/5000 of this same content C1 .

The set of segments transmitted is illustrated in FIG. 3. This set is represented in the form of a matrix C1i@Dj, Dj corresponding to the encoding rate and the index i designates a temporal identifier, or position, of the segment C1i@Dj in C1 content.

More specifically, the intermediate device DI receives and stores one or even several matrices depending on the number of contents Ck to be stored. In this configuration the different matrices will be Cki@Dj, the index k designating a particular content.

In an example illustrated below in relation to FIG. 3, the content C1 is for example offered in the form of segments of duration 2s, with a first encoding rate D1 = 500 kb/s, a second encoding rate D2 = 1000 kb/s, a third encoding rate D3 = 2000 kb/s, etc.

The intermediate device DI receives all the segments described above. Also, in our example, the intermediate device DI stores the manifest file described above and forwards it to a rendering terminal upon receiving a request to access the content associated with the manifest.

In this example, a user wishes to view digital content C1, such as a video, on his television 5 connected to an HDMI key 8.

In order to view a video, during a first step ET1, an access request REQ(C1) to the content C1 is transmitted by the terminal 8 to the intermediate device DI. In our example, this request goes through gateway 6.

During a second step, an access request REQ'(C1), identical or not to the request transmitted in the first step, is transmitted to the content server 2 which downloads in return different versions of the content into the intermediate device DI . This step can also be preceded by a verification step during which the restitution terminal verifies whether the requested content is already being transmitted to another restitution terminal, in which case the intermediate device DI does not carry out the second step but instead requires the intermediate device DI to transmit the content to the terminal 8.

It should be noted that the request transmitted in the first step could have been transmitted directly to the content server 2. This request may or may not pass through the intermediate device DI.

Note also that the order of execution of the first two steps is irrelevant. In other words, the downloading of the content in the intermediate device DI can also be done before reception of an access request or after reception of the access request.

During a third step, the intermediate device DI transmits in response to this request a data stream representative of the chosen content.

As indicated previously, the intermediate device DI exposes the content C1 in the form of segments, or “chunks” C1 _i @Dj encoded at different encoding bit rates Dj, where the index i designates a temporal identifier, or position, of the “chunk » C1 _i @Dj.

The intermediate device DI then transmits segments at a rate Dj. We will see below that the first segments are transmitted with a low bit rate, 500 kb/s in our example.

This data stream is recovered by the HAS module of the restitution terminal, for example the HDMI key 8 which controls the restitution on the television set 5 for viewing by the user.

In general, a HAS module is responsible for recovering the time segments from the intermediate device DI by choosing the video quality Dj according to the available network resource as explained above. We will not describe here in more detail the way in which the HAS client module chooses the encoding rate of the next video segment to be downloaded: there are in fact many algorithms allowing this choice to be made, the strategies of which are more or less secure. 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, and on the evaluation of the recovery time of this first segment. . Based on this, the HAS client module evaluates whether, given 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 a classic case, if a video time segment lasts 2 seconds, the recovery of the segment by the HAS module must not exceed 2 seconds in order to allow restitution without interruption of the content. It is therefore appropriate for the HAS 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 restitution in continuously on the TV 5 for example.

During a fifth step ET5, the HAS module of the restitution terminal 8 retrieves the manifest file 7 in order to discover the available segments of the video content C1, and the various associated video qualities Dj.

In an example, not illustrated, the HAS module operates during a sixth step ET6 the downloading, for example, of successive segments C1 ₁ @D1 (i.e. the first time segment at an encoding rate of 500 kb/s), then C1 ₂ @D3 (i.e. the second time segment at an encoding rate of 2000 kb/s), then C1 ₃ @D3 (i.e. the third time segment at an encoding rate of 2000 kb/s), etc.

The various segments downloaded by the HAS client module are transmitted to the television set 5 via the HDMI key 8 for example for their restitution to the user.

The algorithm implemented by the HAS client module to determine which segment at which encoding bitrate should be downloaded 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 a possible variant, the content server transmits the segments in multicast mode. This mode takes advantage of the advantages of multicast content distribution while allowing, thanks to the intermediate device DI, to adapt the content to each client. This variant therefore consists in replicating the video segments, preferably as close as possible to the playback terminals, in order to reduce the load on the content server and on the communication network; and keep the adaptation of the content to the constraints of the access network at the level of the restitution terminals.

According to a second embodiment which can be used alone or in combination with the first embodiment, a reception module can be used instead of the HAS adaptive progressive download module. In our example, unlike the HAS module, the receiving module does not have a manifest file. In order to determine the version of the segments to be downloaded, the reception module measures the retrieval time of a segment from the content server and compares this retrieval time to the duration of the time segment; and depending on the result of the comparison, the reception module decides to request a modification (reduction or increase) of the quality of restitution of the segments, implied by the version of the subsequent segments.

Note that in our example, maintaining a version does not require the transmission of a request to the intermediate device, only the increase and decrease of the version requires a request to the intermediate device DI.

The intermediate device DI is ideally a router capable of routing data streams to the restitution terminals and capable of forming groups of users (implying restitution terminals or local networks) to which the same digital content can be transmitted ; In this configuration, in order to receive digital content such as live or “live” content, one or more users subscribe to a group on the intermediate device DI. The rendering terminals of the same group will then download, from the intermediate device DI, the content segments of different qualities.

The intermediate device DI is responsible for replicating the segments to the different users of the same group who have requested access to the same content and transmits the segments with a version requested by the reception module(s) concerned as indicated above.

Also, when the content is “Live” content, the intermediate device DI stores a few seconds of content in a buffer memory so as to be able to replicate the time segments to the various rendering terminals and distribute the optimum qualities according to the needs of the terminals of restitution. This storage of segments in a buffer memory is necessary to supply the segments to the rendering terminal, the latter also storing for a few seconds in a buffer memory the segments that it is going to render. For example, on a “TV Key” type decoder, viewing “live” content requires the storage of video segments over about fifteen seconds. This storage in a buffer memory in the restitution terminal makes it possible to manage the possible disturbances of flow on the network.

According to a variant, the implementation of the method of the invention is conditional on the reception of a minimum number of requests for access to the same content.

With reference to FIG. 5, the reception of a request for access to a time segment of a given version, for example C1N@D1000, leads to the deletion of the other versions of the same segment from the memory of the intermediate device, namely C1N@D500, C1N@D2000, C1N@D3000, and C1N@D5000. This feature saves memory space in the intermediate device DI upon receipt of a request for access to a segment.

FIG. 6 illustrates another embodiment including two intermediate devices DI1 and DI2. This other mode can be used alone or in combination with one of the embodiments described above. We choose here to illustrate this third mode by using the second mode described above, i.e. the one using a reception module that does not have a manifest file as a device. In this third mode, the intermediate devices DI1 and DI2 are connected to local networks 10-1 and 10-2, respectively. The local network 10-1 comprises a single restitution terminal TRM, the local network 10-2 comprises several restitution terminals TRM1-TRM5.

Several versions of the same content C1 is transmitted in multicast mode from the content server 2 to the intermediate devices DI1 and DI2.

If the content is real time or “live” content, the intermediate devices DI1 and DI2 store the segments received in multicast mode in a buffer memory so as to store a few seconds of “LIVE” video and to replicate the time segments to the different terminals.

It is assumed here that the terminal TRM of the local network 10-1 and the terminals TRM1-TRM5 of the local network 10-2 require access to the content C1.

In our example, after receiving the access request, not being aware of the needs in terms of playback quality of the playback terminals, the intermediate device DI transmits to the terminal TRM by default a video segment of a version associated with low flow. Following reception, the TRM terminal measures the recovery time for this segment and checks that the segment recovery time does not exceed the duration of the segment. Depending on the result, the reception module of the restitution terminal transmits or not a message to the intermediate device requesting greater quality, a reduction in quality or even maintenance of the received quality.

It should be noted that the restitution terminals require the segment versions from the intermediate device to which it is connected.

In the example using a receiver module, the RTP/RTCP over UDP protocols can be used. In this case, the segments can be transmitted by means of UDP message; the version modification requests are transmitted by the rendering terminals by means of respective RTSPs.

APPENDIX 1: sample manifest file

Claims (12)

Method for transmitting content to a playback terminal (8) via a communication network, the content (C1) being accessible from a content server in several versions associated with respective playback qualities, a given version respectively comprising several content segments, characterized in that it comprises the following steps in a device (DI) inserted between the content server and the rendering terminal

• a first reception step during which the intermediate device receives several versions of the same content from the content server;
• a second step of receiving a request for access to a given version of the content;
• and a step of transmitting, to the restitution terminal, segments associated with the version of the content requested during the second reception step.

Transmission method according to Claim 1, characterized in that the version chosen for at least the first time segment transmitted is a version chosen by default. Transmission method according to Claim 2, characterized in that the choice of the version of a subsequent segment evolves as a function of data coming from the restitution terminal, the said data coming from a comparison between the transmission duration of a previously transmitted segment and the duration of the time segment. Transmission method according to Claim 1, characterized in that the content received during the first reception step is a content transmitted in multicast mode. Method of transmission according to claim 1, characterized in that the reception step is followed by a step of storing in memory the segments received from the content server, and in that the step of transmitting a time segment d a given version causes the other versions of the transmitted segment to be deleted. Computer program product comprising program code instructions for implementing a method for transmitting digital content according to any one of claims 1 to 5, when executed by a processor. A computer-readable recording medium on which a computer program according to claim 6 is recorded. Device (DI), called intermediate device, capable of communicating with a content server (2) and with rendering terminals (3,4,8) via a communication network, a content (C1) being accessible from the content under several versions, a given version comprising respectively several segments of the content,
including:

1. a first reception module during which the intermediate device receives several versions of the same content from the content server;
2. a second reception module able to receive a request for access to a given version of a content;
3. a transmission module capable of transmitting, to the restitution terminal, segments associated with the version of the content requested during the second reception step.

Method of access by a rendering terminal to digital content accessible from a device (DI), called intermediate device, several different versions of the content being accessible, a given version respectively comprising several segments of the content having respective durations, characterized in that that it includes the following steps

• a reception step during which the rendering device (8) receives a segment of a given version of the content from the intermediate device (DI);
• a second step of measuring the duration of transmission of the segment received and comparing it with the duration of the time segment,
• depending on the result of the measurement step, a step of transmitting or not, to the intermediate device (DI), a request for access to another version.

Restitution terminal comprising restitution of digital content accessible from a device (DI), called intermediate device, several different versions of the content being accessible, a given version respectively comprising several segments of the content having respective durations, characterized in that it understand

• a receiving module capable of receiving a segment of a given version of the content from the intermediate device (DI);
• a measurement module able to measure the duration of transmission of the segment received and to compare the duration measured with the duration of the time segment,
• a transmission module capable of transmitting or not, intended for the intermediate device, a request for access to another version depending on the result of the measurement step.

Computer program product comprising program code instructions for implementing a method for transmitting digital content according to claim 9, when executed by a processor. A computer-readable recording medium on which a computer program according to claim 11 is recorded.