Optimized handling of manifest files for telecom clients receiving adaptive content over http (HAS)

Abstract

Method for managing access by a client (C) to content available on at least one server (S) through a telecommunications network (N), said content being temporally segmented into a sequence of data blocks, this method comprising a transmission by the server of a file (F) associating time segments with data block identifiers, as well as a selection of an action as a function of an interval between a current time and a time segment currently being displayed, among a generation by the client within the file of at least one block identifier associated with a time segment and a transmission of a request to the server to receive the file (F) again. Figure for the abstract: Fig. 1

Description

Title of the invention: Optimized management of manifest files for telecommunications clients receiving adaptive content over http (HAS) FIELD OF THE INVENTION

[0001] The present invention relates to the distribution of content, in particular audio-visual content, through telecommunications networks to end clients with a view to their production for users. It relates more particularly to the broadcasting of content temporally segmented into sequences of data blocks, or "chunks" in English, possibly in several resolutions. It applies in particular to broadcasting based on technologies such as HAS ("Http Adaptive Streaming").

[0002] In this type of technology, clients must retrieve files containing identifiers of the different blocks of data constituting the content they wish to access. These identifiers contain the data allowing the client to retrieve, individually, each block of data, possibly in the desired resolution.

[0003] When the content is being produced, for example because it is a live broadcast that is not finished at the time the user accesses it, the client must periodically retrieve this file in order to obtain the identifiers of the new content blocks produced.

[0004] When a delayed reading function is used, the client must be able to access data blocks corresponding to time segments in the past. Also, a long period of time must be represented in the file retrieved by the client, corresponding to a very large number of data blocks. Even if the file only contains identifiers of the data blocks, i.e. the information allowing the client to retrieve them, the size of the file can be considerable.

[0005] For example, if we want to allow users to go back 4 hours in the past in delayed reading, and if the data blocks correspond to time segments of 2 seconds, the file must contain 7200 identifiers per proposed resolution. Given the size of each identifier, we obtain a file of approximately 200 KB.

[0006] Regularly retrieving this file therefore creates congestion in the bandwidth between the content server and the client, and consequently, in the telecommunications network. It should be noted that, in certain commercially deployed systems, the file is retrieved at a rate corresponding to the production (and the consumption) of data blocks, i.e. once every two seconds, which therefore generates a data flow of approximately 6 MB / minute for each client. In addition, each request for the file places a strain on the server and uses its resources, at the risk of degrading its performance.

[0007] There is therefore a need to improve the current proposals of the state of the art, in order to minimize the occupation of this bandwidth for clients using a function of deferred reading of content available in sequence of data blocks. Summary of the invention

[0008] For these purposes, according to a first aspect, the present invention can be implemented by a method for managing access by a client to content available on at least one server through a telecommunications network, said content being temporally segmented into a sequence of data blocks, said method comprising a transmission by said server of a file associating time segments with data block identifiers, as well as a selection of an action as a function of an interval between a current time and a time segment currently being displayed, among a generation by said client within said file of at least one block identifier associated with a time segment and a transmission of a request to said server to receive said file again.

[0009] Thus, in the case where the content is accessed in deferred reading, the file referencing the data blocks is no longer retrieved from the data server, since the client will not immediately use the new data blocks produced by the server. This avoids using the resources of the server and the telecommunications networks.

[0010] According to preferred embodiments, the invention comprises one or more of the following features which can be used separately or in partial combination with each other or in total combination with each other: - said generation is carried out periodically, for a number of time segments corresponding to said period. Thus, the content of the file is kept synchronized with the production of the data blocks on the content server. - said period corresponds to a constant duration of said time segments. In this way, synchronization is as precise as possible. - the generated identifier is adapted to be determined by said client as not corresponding to said at least one server. - the method further comprises, when an identifier generated by the client within said file during preparation of a request for a data block is detected, a transmission of a request to said server to receive said file again. These embodiments make it possible not to modify the other software elements of the client, in particular the media content display application. In particular, they will automatically detect that an identifier contained in the file must be subject to special processing, in particular the recovery of the manifest file from the content server. - a position indicator is displayed to position said time segment currently being displayed according to the block identifiers present within said file. Thus, the user can at any time know the gap between what he is currently watching and the content produced by the content server. - this content may be live broadcast content, but it may apply to other kinds of multimedia content broadcasting.

[0011] Another aspect of the invention relates to a client comprising a processor configured to perform the steps of receiving a file from a content server, associating time segments with data block identifiers, as well as selecting an action based on an interval between a current time and a time segment currently being displayed by said client, among a generation within said file of at least one block identifier associated with a time segment and a transmission of a request to said server to receive said file again.

[0012] Another aspect of the invention relates to a computer program capable of being implemented on a web server, the program comprising code instructions which, when executed by a processor, carry out the steps of the method as previously defined.

[0013] Another aspect of the invention relates to a data medium on which at least one series of program code instructions has been stored for the execution of a method as previously defined.

[0014] Other characteristics and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of example and with reference to the appended drawings. BRIEF DESCRIPTION OF THE FIGURES

[0015] [Fig.l] illustrates a context for implementing a method according to embodiments of the invention,

[0016] [Fig.2] illustrates an example of functional architecture of a client according to an embodiment of the invention,

[0017] [Fig.3] illustrates an example of a human-machine interface for a client, according to embodiments of the invention.

[0018] DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

[0019] In [Fig. 1] is illustrated a WAN telecommunications network making it possible to route data streams representing audio-visual content, from a content server S to MOB, TV, ORD clients.

[0020] These contents can typically be content broadcast "live" (or "live streaming" in English), that is to say, the determination of which is updated over time. In general, these contents are broadcast at the time of their production.

[0021] This could, for example, be television content, such as IPTV (acronym for “Internet Protocol Television” in English), but other transmission methods are also possible.

[0022] The server is accessible to clients via one or more interconnected telecommunications networks, in particular an access network allowing clients to connect to a main WAN network (itself consisting of an interconnection of subnetworks) or "backbone" in English. This WAN network is commonly called the Internet.

[0023] The clients can be connected to a local area network, LAN, for example a wireless local area network, allowing them to access a gateway to the Internet access network. This wireless local area network, commonly called WLAN for "Wireless Local Area Network" in English, can comply with the Wi-Fi protocols, or wifi, as specified in the IEEE standards documents of the 802.11 family (or ISO / IEC 8802-11).

[0024] This LAN local area network can be an internal network in a home (home network), for example, allowing all the equipment, or clients, of a user or a family to be connected. The LAN local area network can also be an internal network of a company, allowing the equipment, or clients, of the different users of the company to be connected.

[0025] A gateway P can be provided to allow the connection of the local network LAN to the internet network, WAN.

[0026] Clients can be of different types, a common point being to have means allowing connection to the network. These are essentially radiocommunication components and electronic and computer components allowing the implementation of the protocol stacks necessary for the management of the protocols associated with the network and the reception and transmission of data packets.

[0027] Customers can also play audio-video content. This can then be displayed on a screen contained or associated with the customers, or via a projector, or via speakers, for example, in the case of purely audio content (radio, etc.).

[0028] The clients Cl, C2 can be of different types: computer (laptop or fixed), mobile communication terminal such as a “smartphone”, digital tablet, connected television, etc.

[0029] The television can be natively connected or through an associated device such as, for example, a TV stick connected to the television, generally via HDMI. An example of an external device communicating with a television is Chromecast. The Chromecast is a real-time multimedia streaming device (multimedia gateway) developed and marketed by Google. The device plugs into the HDMI port of a television and communicates, via Wi-Fi connection, with another device connected to the Internet (computer, smartphone, tablet, etc.), in order to display on the television the multimedia content received from an application compatible with Google Cast technology, from the Google Chrome browser on a computer, or from certain Android devices.

[0030] These different clients are also provided for the reception and processing of content data blocks.

[0031] In particular, they may have a software application (for example a browser) allowing access to web servers or others, which make it possible to make audio-video content available to the users of the clients. Thus, the various exchanges between the clients and the content servers S can be carried out in accordance with the protocols commonly used on the Internet network, in particular the HTTP protocol.

[0032] Dynamic Adaptive Streaming over HTTP (DASH or MPEG-DASH or HAS) is a standard format for audiovisual broadcasting on the Internet.

[0033] More generally, this distribution mode is typically called ABR for “Adaptive Bit Rate” in English.

[0034] This type of content is temporally segmented into a sequence of data blocks, or “chunks” in English. Each data block corresponds to a time segment.

[0035] At the same time segment, several blocks of data may be available, each corresponding to a given resolution.

[0036] Thus, a function deployed on an entity connected to the WAN network (for example the content server S) consists of dividing the content, as it is produced in the case of live content, into time segments and encoding each piece of content corresponding to this time segment into as many data blocks as there are resolutions that it is desired to make available to the different clients.

[0037] These time segments can correspond to very short durations, of the order of a few seconds (for example 2 seconds, or 10 seconds). As a result, a content consists of a very large number of data blocks.

[0038] The resolutions correspond to qualities of the video (and / or audio) content and consequently to different speeds on the telecommunications network.

[0039] The qualities available in ABR can vary depending on the video streaming platform used, but in general and currently, common qualities include: - Very low quality: Often suitable for users with very slow or unstable internet connections, this quality can have a resolution of 240p and a bitrate of 200 kbps. - Low quality: This quality is suitable for more stable but still relatively slow internet connections, with a resolution of 360p and a bitrate of 400-700 kbps. - Standard quality: This quality is suitable for most Internet connections, with a resolution of 480p or 720p and a bit rate of 800 kbps to 2 Mbps. - High quality: This quality is suitable for fast and reliable internet connections, with a resolution of 1080p and a speed of 2-5 Mbps. - Very high quality: this quality is suitable for very fast Internet connections, with a resolution of 4K and a speed of more than 10 Mbps.

[0040] It is important to note that the available qualities may vary depending on the user and network bandwidth capabilities, as well as the quality and complexity of the video content being streamed, and the performance level of the encoders.

[0041] Since the data blocks correspond to very short time segments, the transmission of the content can be reactively adapted to the conditions of the telecommunications network, by switching from one resolution to another for the following time segment(s) depending on the bandwidth available on the network.

[0042] A file may be provided to associate the time segments into which the content is temporally segmented with data block identifiers.

[0043] This file can therefore match a segment with several data block identifiers, when several resolutions are available. The file allows clients to be informed of the available resolutions and thus to be able to select a resolution based on the perceived quality of the display of the content during the time segments (this quality depending in particular on the bandwidth available on the WAN, LAN networks).

[0044] This file is commonly called a “manifest” or “manifest” in English.

[0045] Different formats of such "manifest" files can be used. They can, for example, be in XML format. The ISO / IEC 23009 standard finalized at the end of 2011 defines the manifest format as well as that of data blocks based on MPEG container formats: ISO Base Media File Format (ISO / IEC 14496-12) and MPEG-2 Transport Stream (ISO / IEC 13818-1), and gives indications for the definition of other block formats.

[0046] Data block identifiers can also take several forms. They typically include an address, or some other "locator," to determine how to download the identified data block.

[0047] In the context of a HAS-type implementation based on the http protocol, this identifier can be a URI (“Uniform Resource Identifier”). This is a short string of characters identifying a resource on a physical or abstract network, and whose syntax complies with an Internet standard established for the World Wide Web (RFC 3986).

[0048] According to this embodiment, the clients then include means (in particular a TCP / IP protocol stack with appropriate application layers) for downloading the data blocks identified by URIs by means of HTTP (“HyperText Transfer Protocol”) or possibly FTP (“File Transfer Protocol”) requests.

[0049] [Fig. 2] illustrates an example of a functional architecture of a client according to an embodiment of a method described. Also represented are a content server S and a telecommunications network N. This telecommunications network may correspond to the Internet network, WAN, of [Fig. 1] or to an interconnection of several networks, for example of this Internet network and a local area network LAN. To the extent that the method described is independent of the link between the content server S and the client C, this network N will not be described in more detail.

[0050] In the illustrative example of [Fig.2], the client C comprises a CHAS application client adapted for the implementation of the different mechanisms and protocols making it possible to implement the HAS mechanism.

[0051] The CHAS client (and therefore, more generally, the client C) has the means to download the data blocks from the content server S in order to produce them (i.e. display them in the case of multimedia content, in particular video) on a viewing interface (screen, projector, etc.) by means of a display application, or “player” in English, PLR.

[0052] The client C is therefore adapted to construct requests from the “manifest” file, F, by incorporating a data block identifier, and to transmit these requests to the server S in order to trigger the downloading of the blocks identified in the requests.

[0053] The recovered data blocks can be decoded, on the fly, by a DEC decoder then stored in a BUF memory where they can be consumed by the PLR display application.

[0054] This mechanism being well known to those skilled in the art, and well described in the scientific and technical literature, it will not be described further in the present Description.

[0055] [Fig.3] illustrates an example of a human-machine interface that can correspond to a client C. The PLR display application can display the multimedia content corresponding to the data blocks decoded and consumed from the BUF memory in a ZI zone of a screen, for example.

[0056] The PLR application may also display an area Z2 representing a time axis, in which a position indicator Z3 may be represented. The position of the indicator Z3 in the time axis Z2 corresponds to the time position of the time segment associated with the data block currently being displayed, within the content.

[0057] In the case where the client displays live content in real time (i.e. without time lag), the indicator Z3 is positioned at the right end of the zone Z2, corresponding to the present time.

[0058] A position further to the left corresponds to the activation of a time-shifted playback function (or "start over"). This function allows the user to shift the display to earlier time segments: they can thus view content produced in the past. This function allows them to review certain segments, catch up on content if they missed the beginning, etc.

[0059] The position of the indicator Z3 allows it to be given an indication of the offset of the display in relation to the live display.

[0060] Also, the interface may be provided to allow it to move (for example by means of a remote control) the position of this indicator Z3 within the time axis Z2, in order to determine a new time offset of the display. Such a command then triggers the downloading of the data blocks associated with the time segments of the content corresponding to the new position of the indicator Z3.

[0061] In order to position the indicator Z3 within the time axis Z2, the PLR display application can be based on the file F.

[0062] This in fact contains all the data block / time segment associations. Knowing the data block currently being displayed, it can therefore directly deduce its time position based on the identifiers present in the file F (corresponding to as many time segments) and determine the position of the indicator Z3 within the time axis Z2 which corresponds to all the time segments available in this file F.

[0063] The method described essentially concerns the recovery of the file F, and its construction. This construction of the file F is preferably carried out so that the existing mechanisms relating to its use for the recovery of the blocks of data can be implemented without modification. Thus, an advantage achieved is not having to modify the PLR application which can be compliant with the state of the art.

[0064] In the state of the art, the file F is retrieved regularly from the server S. Typically this retrieval takes place in time synchronization with the consumption of the data blocks by the PLR display application: thus, if the data blocks correspond to 2-second segments, then the file F is retrieved every 2 seconds from the server S. In this way, the display of the indicator Z3 is correctly positioned relative to a time line Z2 which actually corresponds to the segments available for the content on the server S, therefore to the “real time” of the live broadcast.

[0065] We have seen, however, that such an embodiment can lead to numerous disadvantages, in particular those linked to the congestion of the link between the server S and the client C, and to the necessary processing generated by these transmissions on the server S.

[0066] According to the proposed method, depending on a time interval between the current time and the segment being played, the client selects an action from: - a generation of one or more data block identifiers (associated with a time segment), and - a transmission of a request to the server S to receive the file F.

[0067] Thus, according to this method, the recovery of the file F is only implemented in one branch of the alternative. From then on, the file F is updated on the server S by inserting data block identifiers for each new time segment, but this file is no longer recovered (or transmitted) to the client C.

[0068] In the other branch, instead of retrieving the file F, it is completed locally, without exchange via the telecommunications network N.

[0069] Also, in this other branch, identifiers are deleted in order to keep a constant number of identifiers in the file F, corresponding to a time window within which the user can navigate in time to shift the reading of the content.

[0070] The time interval makes it possible to determine whether there is delayed or live reading by comparing the time segment currently being displayed and a current time which can come from the internal clock and is representative of the production of the live data blocks on the server S (It is assumed that the client's clock is synchronized with that of the server).

[0071] If the time interval is zero (or below a certain threshold), then this means that the display is live (or as close to live as possible). If the interval is not zero (or above this threshold), then this means that the reading (or display) is delayed (or "playback").

[0072] The method is based on the idea that if the reading (and display) of the data blocks is delayed compared to the current time, corresponding to the live, then the data blocks close to the current time are not consumed soon by the PLR display application. Also, it is considered that the recovery of the identifiers of these blocks is not an immediate need and can be postponed to the future.

[0073] It is further noted that the content of file F varies only very gradually. If this file corresponds to 4 hours of content, for example, and the time segments correspond to durations of 2 seconds, it can easily be calculated that between two productions of a block of data, the file remains constant at 99.987% (the replacement of the oldest identifier by a new identifier representing a proportion of 0.013%).

[0074] It is therefore submitted that the transmission of this file F each time a new block of data is produced by the server S is counterproductive.

[0075] In the situation of deferred reading, it is therefore proposed that the data blocks can be generated locally, using data not retrieved from the server S. This data can be arbitrary.

[0076] In other words, for each segment to be inserted into the file F, corresponding to a new time segment, an arbitrary value (or more generally “not retrieved from the server S”) can be associated as a data block identifier.

[0077] For any insertion of one or more identifiers in the file, the same number of identifiers are deleted in order to keep the number of identifiers in the file F constant. Insertions are made at the end of the file (corresponding to the most recent time segments) and deletions are made at the beginning of the file (corresponding to the oldest time segments).

[0078] Consequently, the number of data block identifiers within the file always corresponds to the number of time segments into which the content is actually segmented by the server S at the current time. Therefore, the PLR display application can rely on the information contained in the “manifest” file F to position the indicator Z3 on the timeline Z2.

[0079] The mechanism is therefore transparent from the point of view of the PLR display application in this regard.

[0080] In order to synchronize the indicator Z3 with the production of the data blocks on the server S, the generation of the identifier(s) is done by the client periodically, for a number of segments corresponding to this period (i.e. the time lapse between two generations). In other words, if the client generates block identifiers every x seconds, then it generates identifiers corresponding to a time interval of x seconds, in order to maintain synchronization.

[0081] Preferably, this period corresponds to a constant duration which is that of the time segments. In other words, in this embodiment, each time a block of data is consumed by the PLR display application, a new identifier is generated and inserted into the file F. In this way, the position of the indicator Z3 is always as close as possible to reality.

[0082] In the illustrative example of [Fig.2], the file F can thus be provided both by a conventional module M1 adapted to retrieve this file from the server S, and by a module M2 adapted to locally generate identifiers and to insert them within this file F in order to update it regularly.

[0083] The identifier generated by the client is adapted to be determined, or detected, by this same client as not corresponding to the content server S. In particular, it may be an identifier not corresponding to the identifier field corresponding to the server. It may be an identifier whose value is known by the client so that it can be immediately detected.

[0084] It is understood that over time the client accesses the identifiers of data blocks of the file F in a chronological order if the use performs a linear reading of the content.

[0085] After a certain time during this reading process, the client accesses an identifier generated by the client. Since this identifier is not provided by the content server S, it does not allow the corresponding data block to be retrieved.

[0086] The client C can however directly detect this situation, as previously indicated. According to one embodiment, when such an identifier is detected during the preparation of a request to retrieve a data block, the client transmits a request to receive the file F again.

[0087] This file F has been updated in parallel. Receiving the file F thus makes it possible to synchronize the information available on the client with that available on the server S. The client can then continue by transmitting requests in data blocks based on the updated file F.

[0088] If the display application continues to operate in deferred reading mode, the described method will continue to generate identifiers locally, rather than retrieving the file F from the server, until the display arrives at the last time segment retrieved from the server S, and the same retrieval process is then implemented.

[0089] Thus, the number of times the F file is retrieved, in the case of delayed reading, is drastically reduced, which makes it possible to significantly reduce consumption and relieve the content servers, without impacting the user experience.

[0090] As we saw previously, when the display is live, or close to live, the time interval between the current time and the time segment currently being played is zero or low (less than a threshold). In this case, the file F can be recovered at each consumption of a block of data, (therefore, in general, at each generation of a block of data by the server S), in accordance with the mechanism of the state of the art.

[0091] According to the proposed method, the client selects the most appropriate action at each iteration, i.e. each time the file F must be updated. In this way, an optimum compromise is achieved between minimizing bandwidth consumption on the network N and obtaining the expected QoS quality of service for the users of the client C. The client C thus implements optimized management of the manifest files.

[0092] Of course, the present invention is not limited to the examples and the embodiment described and shown, but is defined by the claims. It is in particular susceptible of numerous variants accessible to those skilled in the art.

Claims

Claims

1. Method for managing access by a client (C) to content available on at least one server (S) through a telecommunications network (N), said content being temporally segmented into a sequence of data blocks, said method comprising a transmission by said server of a file (F) associating time segments with data block identifiers, as well as a selection of an action as a function of an interval between a current time and a time segment currently being displayed, among a generation by said client within said file of at least one block identifier associated with a time segment and a transmission of a request to said server to receive said file (F) again.

2. Method according to the preceding claim, in which said generation is carried out periodically, for a number of time segments corresponding to said period.

3. Method according to the preceding claim, in which said period corresponds to a constant duration of said time segments.

4. Method according to one of claims 1 or 2, in which the generated identifier is adapted to be determined by said client as not corresponding to said at least one server.

5. Method according to one of the preceding claims, further comprising, when an identifier generated by the client within said file during preparation of a request for a data block is detected, a transmission of a request to said server to receive said file again.

6. Method according to one of the preceding claims, in which a position indicator (Z3) is displayed to position said time segment currently being displayed according to the block identifiers present within said file.

7. A method according to any preceding claim, wherein said content is live broadcast content.

8. Client (C) comprising a processor configured to carry out the steps of receiving a file (F) from a content server, associating time segments with data block identifiers, as well as selecting an action based on an interval between a current time and a time segment currently being displayed by said client, from a generation within said file of at least one associated block identifier to a time segment and a transmission of a request to said server to receive said file (F) again.

9. A computer program capable of being implemented on a multimedia stream playback terminal, the program comprising code instructions which, when executed by a processor, performs the steps of the method defined in claims 1 to 7.

10. Data carrier on which at least one series of program code instructions has been stored for executing a method according to one of claims 1 to 7.

Images