Method for managing the time-shifted playback of multimedia content that has been broadcast in real time

Abstract

The invention relates to a method for managing the transmission, to a playback device (STB), of manifest files (MNF1 / MNF2 / etc.) describing addresses of content segments, characterized in that the frequency of sending the manifest files varies over time.

Description

method for managing the delayed playback of multimedia content that has been broadcast in real time.

[0001] The field of the invention is that of managing the playback of multimedia content that has been broadcast in real time. The invention relates more specifically to managing the delayed playback of content that has been broadcast in real time.

[0002] The invention is particularly relevant to segmented content, where the segments are accessible in several formats associated with respective sizes in bytes, which have varying degrees of impact on the bandwidth of the network from which the content is downloaded. The invention is particularly relevant to content downloaded using a technique known as adaptive progressive download (APD), or any other downloading technique employing the same principle.

[0003] Note that segment addresses are included in a description file. In the context of adaptive progressive download, a description file contains, among other things, the network addresses (IP address or URL) of the segments to be downloaded and read by a playback device. In other words, a description file describes segments as network addresses, and it is up to the playback device to access these segments via a network, such as the internet.

[0004] The reading device refers to all data processing devices equipped with processors and capable of accessing content segments through a network, receiving segments from a network, decoding the received segments and requesting a rendering of the decoded segments for example on a screen integrated into the reading device or external to the reading device. State of the art

[0005] When accessing multimedia content, a playback device sends a request to a content server specifying the selected multimedia content (video and / or audio). The playback device then receives a digital data stream related to this content. Within a local communication network, such a request may pass through a network access gateway, such as a residential gateway.

[0006] The received data is then decoded by the reading device, and then displayed as the corresponding video.

[0007] The distribution of digital content over the internet is often based on client-server protocols from the HTTP (Hyper Text Transport Protocol) family. In particular, adaptive streaming (HTTP Adaptive Streaming, abbreviated HAS) of digital content allows for the real-time transmission and playback of data. This means that digital data is transmitted over the network and delivered to the playback device as it arrives. Upon receiving the stream, the playback device stores the received data in a buffer before delivering it. This distribution method is particularly useful when the user's available bandwidth is insufficient for real-time video transmission.

[0008] Adaptive progressive downloading also allows data to be sent and received at different qualities, corresponding, for example, to different respective encoding bitrates. These different qualities are described in a description file, also called a "Manifest" by those skilled in the art.

[0009] When a user accesses the Live stream broadcast in HTTP Adaptive Streaming (HAS), the playback device receives at regular intervals, generally every two seconds, successive description files, hereafter called real-time description files, which each generally describe the last sixty seconds of the stream (30 segments of 2 seconds) by providing IP addresses (Anglo-Saxon acronym for "Internet Protocol") of segments corresponding to these last sixty seconds.

[0010] In general, the video segments are chosen to be short in duration because we want to be as close as possible to the stream broadcast in real time, which those in the know also call a Live stream.

[0011] Note that an encoding bitrate is selected from the available bitrates based on the available bandwidth or the storage and decoding capabilities of the playback device. This type of technique allows for consideration of bandwidth variations on the link between the client playback device and the content server.

[0012] In addition to content playback, some playback devices offer a feature known as "Start Over" (also called "rewind" or "return to beginning") which allows a user watching live content to replay all or part of the broadcast. This feature allows users to restart content from the beginning. For example, if a live movie starts at 9:00 PM and the user accesses the live stream by switching to the channel at 9:40 PM, the user can select a command related to the rewind function to restart playback from the beginning of the movie. In this case, the device switches from real-time playback to delayed playback or rewind mode.

[0013] In this catch-up mode, a command interface allows users to select one or more commands that modify the current playback of the content being streamed in real time. These commands allow users, for example, to pause playback or to rewind to a previous viewing point, thus enabling delayed viewing.

[0014] When content is played and the catch-up function is not available, the description files received sequentially, referred to below as "real-time description files," are those described above. However, when the catch-up function is available, the playback device receives specific description files sequentially from the start of content playback, referred to below as "catch-up description files." These files describe not just the last sixty seconds, but a much larger time period, often several hours, for example, the last four hours, so that the content can be replayed from a point within that four-hour window.

[0015] In summary, a real-time description file targets segments to be read in real time; a catch-up description file targets segments that have been created but are older, their reading transforming real-time reading into delayed reading.

[0016] Such a catch-up description file, describing, for example, the last four hours, is two hundred and forty (240) times larger than a standard description file because it includes all the network addresses of all the segments created in the last four hours. Specifically, a real-time description file is approximately 12 KB (describing thirty (30) two-second segments) and a catch-up description file is approximately 2.8 Megabytes (describing seven thousand two hundred (7200) two-second segments).

[0017] Just like the real-time description file, the catch-up description file is downloaded periodically, for example, every two seconds. Due to its enormous size, the periodic transmission of the catch-up description file requires significant network bandwidth, which can degrade the quality of service during content playback, especially for households with slow internet connections such as ADSL. Furthermore, such catch-up description files require excessive processing time (what experts call parsing time), which can disrupt normal content playback if the playback device has limited processing power. This can result in unbearable image freezes for the user.

[0018] Parsing a large description file on a reading device such as a smartphone or tablet is very fast because these devices have powerful processing capabilities thanks to their high-performance processors. However, parsing the same description file on less powerful reading devices (often called "low-cost" devices) takes a long time because their processors are very limited.

[0019] In practice, on some playback devices, particularly low-cost models, parsing a four-hour description file takes one second. During this one second, the various CPU cores are fully utilized. Since the description file is retrieved at intervals equal to the segment durations, the CPU is therefore fully utilized for one second every two seconds (for comparison, on a PC, parsing the same description file takes approximately 7ms). It is therefore very difficult to display a graphical interface on a low-cost playback device when reading a stream with a description file of a certain size in bytes. Indeed, when the CPU is fully utilized, the developers observed that the graphical interface becomes completely frozen.

[0020] These problems impair the user experience even though the user has not selected a command resulting in delayed playback and does not intend to replay the broadcast content.

[0021] The invention improves the situation. The invention

[0022] To this end, according to a first functional aspect, the invention relates to a method for managing the transmission, to a reading device, of description files describing addresses of content segments, characterized in that the periodicity of sending the description files varies over time.

[0023] According to the invention, for example when it is detected that reading the tags or other information from a description file requires too much time, and that this can generate a significant load on the processor for a relatively long period (several hundred milliseconds), the times of transmission of the description files are modified; this modification results in a variation of the periodicity of transmission of the description files; the periodicity can thus be decreased or increased and adapt, for example, to an excessive consumption of the processor in the reading device.

[0024] The description files concerned include description files describing segments that have already been broadcast allowing access to the content on a delayed basis, but also description files describing segments broadcast in real time allowing access to the latest segments produced on the server.

[0025] According to a particular embodiment of the invention, the periodicity is modified following the receipt of data from the reading device. This embodiment addresses a case where the periodicity depends on a device external to the server in which the process is implemented; this external device is, for example, the reading device.

[0026] According to one possible variant of this mode, the data represents a processor load on the reading device from which the data originates. This variant protects the reading device against excessive processor consumption.

[0027] According to yet another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous one, the data is representative of user activity in relation to the reading device. This embodiment assumes user inactivity and therefore a low probability that a user will access a segment later.

[0028] According to yet another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding ones, the sending frequency is established beforehand based on a processor load prediction. This method avoids dependence on an external real-time device; in this method, the process is implemented based, for example, on a history related to the use of a device external to the server, such as the reading device.

[0029] According to another material aspect, the invention relates to a transmission management entity, intended for a reading device, of description files describing addresses of content segments, characterized in that it includes a module for modifying the periodicity of sending the description files.

[0030] According to another material aspect, the invention relates to a server comprising a management entity, called the second management entity, as defined above.

[0031] According to another material aspect, the invention relates to a computer program suitable for implementation on a management entity as defined above, the program comprising code instructions which, when executed by a processor, carries out the steps of the management process defined above.

[0032] According to another material aspect, the invention relates to a data carrier on which at least one series of program code instructions has been stored for the execution of a management process as defined above.

[0033] According to a second functional aspect, the invention relates to a method for managing access to description files describing content that has been broadcast on a delayed basis, the description including addresses of content segments, characterized in that it includes a step of transmitting data capable of requiring a modification of the transmission times of the description files.

[0034] According to a material aspect linked to the second functional aspect, the invention relates to an entity for managing access to description files describing content that has been broadcast on a delayed basis, the description including addresses of content segments, characterized in that it includes a data transmission module capable of requiring a modification of the transmission times of the description files.

[0035] According to another material aspect related to the second functional aspect, the invention relates to a reading device comprising a management entity as defined above in connection with the second functional aspect. The reading device includes a processor capable of executing the following steps of the process defined above with reference to the second functional aspect.

[0036] According to another material aspect linked to the second functional aspect, the invention relates to a computer program suitable for implementation on a management entity as defined above, the program comprising code instructions which, when executed by a processor, carries out the steps of the process defined in connection with the second functional aspect.

[0037] According to another material aspect linked to the second functional aspect, the invention relates to a data carrier on which at least one series of program code instructions has been stored for the execution of a process defined above in connection with the second functional aspect.

[0038] The media referred to above can be any entity or device capable of storing the program. For example, a medium can include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard drive. On the other hand, an information medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means. The program according to the invention can, in particular, be uploaded to a network such as the Internet. Alternatively, the information medium can 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.

[0039] The invention will be better understood upon reading the following description, given by way of example and with reference to the accompanying drawings in which:

[0040] represents a progressive download architecture on the Internet based on the use of adaptive streaming according to an embodiment of the process of the invention;

[0041] illustrates schematically the hardware structure of a server capable of transmitting description files;

[0042] schematically illustrates the physical structure of a reading device capable of reading multimedia streams in real time;

[0043] illustrates content and the segments available for multimedia content.

[0044] illustrates one embodiment of the process of the invention; this figure illustrates the communication between the reading device and the content server; this shows a modification of the periodicity of emission of the description files.

[0045] Detailed description of embodiments of the invention

[0046] Larepresents an SYS computer system in which a content distribution network called CDN (Content Distribution Network) is implemented by the person skilled in the art, from which content is transmitted to client devices or content reading devices and description files associated with multimedia content.

[0047] In our example, the SYS system comprises a single STB reading device. However, the invention applies to any number of reading devices.

[0048] The STB reading device is, for example, a digital reading device such as a decoder.

[0049] The multimedia content referred to here is video content corresponding, for example, to a television channel on which so-called live television programs are broadcast, that is to say, broadcast in real time.

[0050] In our example, the STB playback device is connected to a TV output terminal such as a television. The STB playback device could also be integrated into a TV output device.

[0051] In our example, the STB playback device is connected to a port on the TV playback device.

[0052] In our example, the STB reading device is located in a local area network (LAN) managed by a GTW home gateway. We will see later that the STB reading device includes a first management entity, ENT1.

[0053] The GTW gateway is capable of communicating via an LI1 communication link which can be a telecommunications network such as a WAN known to a person skilled in the art.

[0054] The SYS computer system implements a content distribution network called CDN (Content Distribution Network) by those skilled in the art, from which content is transmitted to client devices or STB content playback devices.

[0055] The CDN consists of networked servers within the wide area network; these servers cooperate to make multimedia content available to users in unicast mode. To simplify the description of the invention, a single SRV content server will be represented to depict the CDN. In our example, the SRV content server is located within the wide area network.

[0056] The SRV content server, for example, receives digital television content channels from a broadcast television network (not shown), and makes them available in real time to client terminals, here the STB playback device.

[0057] C1 multimedia content is, for example, content downloaded using adaptive streaming. The MPEG-DASH standard (for "Dynamic Adaptive Streaming over HTTP") is a standard for audiovisual streaming formats over the Internet. This standard is based on preparing content in different representations of varying quality and bitrate, divided into short segments (on the order of a few seconds), also called "chunks" by those skilled in the art. Each of these segments is made available individually via an exchange protocol between the playback device and the multimedia content provider's server. The primary protocol is HTTP, but other protocols (e.g., FTP) can also be used. The organization of the segments and their associated parameters are published in a description file in XML format.We will not go into further detail about this download method as it is irrelevant to the presentation of the invention.

[0058] An example of a description file or "manifest" (MPD) conforming to the MPEG-DASH standard and containing a description of content available in three different qualities (N1 = 512 kb / s, N2 = 1024 kb / s, N3 = 2048 kb / s) of fragmented content is presented in Appendix 1. This simplified description file describes digital content in an XML (Extended Markup Language) syntax, comprising a list of content in the form of segments classically described between an opening tag ( <segmentlist>) and a closing tag (< / segmentlist>Segmentation allows for fine-tuning to bandwidth fluctuations. Each segment corresponds to a specific duration (the "duration" field) with several quality levels and allows for the generation of its addresses (URLs – Uniform Resource Locators). In this example, this generation is done using the "BaseURL" element ("HTTP: / server.com"), which indicates the content server address, and the "SegmentURL," which lists the additional parts of the addresses for the different segments.

[0059] - “C1_512kb_1.mp4” for the first fragment of the “C1” content at 512 kilobits per second (“kb”) in MPEG-4 (“mp4”) format,

[0060] - "C1_512kb_2.mp4" for the second fragment,

[0061] - etc.

[0062] The SRV server is also equipped with at least one CPU2 processor and MEM2 memory for data processing. The server also includes a management entity, ENT2, also known as the second management entity, capable of handling the transmission of content and its associated description file from the SRV server to one or more reading devices, in this case, the STB reading device. The SRV server communicates with the GTW gateway via a WAN. The server includes a communication module, labeled COM2, for WAN communication. In the following discussion, we will focus primarily on the transmission of the description file rather than the transmission of the segments.

[0063] This represents the architecture of an STB reading device. This STB device typically includes MEM1 memories associated with a CPU1 processor. The memories can be of the ROM (Read Only Memory) or RAM (Random Access Memory) type, or even Flash.

[0064] The STB playback device can transmit content to be displayed to the TV playback device via a COM12 communication module. This COM12 module is, for example, an HDMI connection.

[0065] The STB reading device communicates with the gateway via an Ethernet module for wired local communication or via a WiFi radio module for wireless local communication with the GTW residential gateway. This module is referenced as COM11 on the diagram.

[0066] The STB reading device includes a streaming-mode download module HAS (not shown) capable of handling the download of description files and the download of content segments described in the received description files. The STB reading device also includes a management entity ENT1, referred to as the first management entity hereafter, capable of reading a description file specifically constructed during a catch-up reading, as explained below. The download module HAS and the first entity ENT1 can be a single entity, in which case the HAS module is integrated into the first entity ENT1, or they can be separate entities.

[0067] We now present, in relation to this, a schematic view of a main content C1 divided into segments and stored in the SRV content server. More precisely, the HAS content server exposes a video C1 in the form of C1i@Nj segments encoded at different encoding rates Nj, where the index i designates a temporal identifier of the C1i@Nj segment.

[0068] The HAS download module, referred to as the classic download mode below, of the STB playback device is responsible for retrieving segments from the HAS content server, selecting the video quality Nj based on available network resources. We will not describe in detail here how the HAS download module chooses the encoding bitrate for the next video segment to be downloaded. It is worth noting that, most often, the general principle of such algorithms relies on downloading an initial segment at the lowest encoding bitrate offered in the description file, and then evaluating the retrieval time of this first segment. Based on this, the HAS download module assesses whether, considering the size of the segment and the time taken to retrieve it, the network conditions allow the subsequent segment to be downloaded at a higher encoding bitrate.Some algorithms rely on a gradual increase in the quality level of downloaded content segments; others propose riskier approaches, with jumps in the encoding bitrate levels of successive segments.

[0069] In a typical scenario, if a video segment lasts three seconds, the HAS download module must not retrieve the segment in more than three seconds to allow for uninterrupted playback of the content by the STB playback device. Therefore, the HAS download module must strike the best possible balance between playback quality, and thus the highest possible encoding bitrate, and the segment download time, which must be short enough to allow continuous playback on the TV.

[0070] Initially, the HAS module retrieves the description file corresponding to the C1 video content in order to discover the available segments of the C1 video content, and the different associated video qualities Nj. In the example shown, the C1 content is offered as 3-second segments, with a first encoding bitrate N1 = 400 kb / s, a second encoding bitrate N2 = 800 kb / s, a third encoding bitrate N3 = 1200 kb / s, etc.

[0071] In a normal operating mode, not illustrated on the, the HAS module operates the download for example, of successive segments C11@N1 (i.e. the first time segment at an encoding rate of 400 kb / s), then C12@N3 (i.e. the second time segment at an encoding rate of 1200 kb / s), then C13@N3 (i.e. the third time segment at an encoding rate of 1200 kb / s), etc.

[0072] The various segments downloaded by the HAS download module are then transmitted to a display module capable of requesting a display on the TV.

[0073] The algorithm implemented by the HAS download module to determine which segment at which encoding rate should be downloaded in normal operating mode may be one of the existing prior art algorithms. Therefore, this algorithm will not be described in further detail here.

[0074] Sometimes, you might miss the beginning of a live television program (movie, series, etc.). A feature called "start over" or "restart" (also known as "Start Over" or "Restart" by those in the know) allows you to resume the program at any time from a point earlier than the current one; for example, you can restart playback from the beginning. For instance, if a movie starts at 9:00 PM and the user changes the channel at 9:40 PM, they can request that playback resume from the beginning of the movie. In this case, you switch from watching the content in real time to watching it on demand.

[0075] When a user accesses a live stream broadcast in real time (live content) using HTTP Adaptive Streaming (HAS), the STB playback device—meaning the HAS component installed on that device—generally retrieves a description file, hereafter referred to as the real-time description file, every two seconds. This file typically describes the last sixty seconds of the stream (30 two-second segments). A portion of the stream (up to a maximum of 60 seconds) can then be stored in memory (buffered). The video segments are short because the goal is to be as close as possible to the actual live event, such as a football match. This is also why the description file is retrieved every two seconds and the buffer depth is generally limited to around fifteen seconds to avoid excessive lag between the football match and its display on a screen.

[0076] A control interface (the symbols most often found on a remote control are "<<" for rewind, ">>" for fast forward, and "II" for pause) allows you to control the current playback of live content. Specific controls allow you to activate catch-up (or start over) mode.

[0077] To ensure the execution of a command from the command interface, such as the rewind command, the retrieved description file no longer describes the last sixty seconds but a time window larger than sixty seconds. This time window can encompass several hours, for example, the last four hours of broadcast; in this case, the content can be replayed from any point within the four-hour time window. In our example, the server automatically records the live streamed content over a sliding time range, for example, four hours. During this time window, the content is recorded; due to the sliding of the time window, in our example, segments recorded at a given time that are no longer within the sliding time window at a later time are deleted.

[0078] In the following, the description file, which describes the latest segments produced on the server in connection with the real-time reading of the content, will be referred to as the "Real-Time File" (MNFtr). This file corresponds to a network address referenced as Ad-MNFtr.

[0079] We will also call "catch-up files" the description files describing segments that have already been broadcast and allowing to replay segments on delay.

[0080] The catch-up file is a description file that describes the segments that have been broadcast and are accessible on delay; generally, access to the segments over a fixed time range is made possible by the broadcaster, for example over a four-hour period preceding the current broadcast time.

[0081] According to the invention, the ENT2 management entity associated with the broadcast server modifies the sending frequency of the description files. This modification is performed following the receipt of data from the reading device. The data is, for example, data representing the power consumption level of the PRO1 processor present on the STB reading device.

[0082] Figure 6 illustrates one embodiment of the method of the invention. This embodiment relies on catch-up description files because these files require significant processor power consumption on the reading device. However, the invention could also be based on a real-time description file.

[0083] Figure 6 shows two vertical axes corresponding respectively to two entities, namely the first entity ENT1 present on the STB reading device and the second entity ENT2 present on the SRV server.

[0084] Figure 6 illustrates the data exchanges that take place between the STB reading device and the SRV content server.

[0085] Note that in Figure 6, only some of the messages relevant to understanding the invention are illustrated. For example, after receiving a description file, the STB reading device typically requires access to the segments described in that file; we have chosen not to show these access messages as they are irrelevant to the explanation of the invention.

[0086] Commands whose execution results in a delayed replay of the content from a chosen reading point prior to the current point require a description of segments that have been broadcast in the past; a real-time description file that only describes the latest produced segments related to real-time broadcasting is therefore insufficient;

[0087] Figure 6 illustrates a first phase of transmission of description files PH1 and a second phase PH2 of transmission of description files, the transmission periods being different during each phase.

[0088] The first phase PH1 includes the production of description files MNF1,MNF2,…,MNF(i), describing segments.

[0089] During this first phase, the description files are transmitted at regular intervals T1. In our example, this time interval is 2 seconds.

[0090] During this first phase, the first entity ENT1 is able to trigger a transmission of data DAT1 / DAT2 to the second entity ENT2.

[0091] The transmission of this DAT1 / DAT2 data triggers the second phase PH2. This second phase PH2 comprises several steps.

[0092] In our example, let's assume that at a given moment, the first entity ENT1 detects, during a first step referenced RD-MNF>T, that the reading (parsing) time of a received description file exceeds a given duration T. This duration T is, for example, the duration T1, which is 2 seconds in our example.

[0093] During a second step of this second phase PH2, following detection, the first entity ENT1 transmits a first data DAT1 to the SRV server; the second entity ENT2 receives the data DAT1 and processes it TRT.

[0094] The TRT process involves the second entity, ENT2, modifying the frequency at which the description files are sent. In our example, the second entity, ENT2, decreases the sending frequency. This decrease results in fewer description files received per tempo unit, and consequently, a reduction in the processor load on the STB reading device.

[0095] In a third step, according to one embodiment, the second entity ENT2 transmits the MNF(j) / MNF(j+1) / MNF(j+2) / etc. files with the modified periodicity; the description files are transmitted at regular intervals T2.

[0096] In a fourth step, the STB reading device receives the description files at the modified periodicity as explained above.

[0097] We then assume that the first entity ENT1 is detected in a later step, referenced as RD-MNF <T, que la durée de lecture d’un fichier de description reçu devient inférieure à une durée T donnée., soit la durée T1 dans notre exemple.

[0098] In this case, during a subsequent step following detection, the first entity ENT1 transmits a second data point DAT2 to the SRV server; the second entity ENT2 receives the DAT2 data and processes it TRT. The processing consists of reducing the frequency of sending the description files; the description files are again transmitted at regular intervals T1, as in the first phase PH1.

[0099] The embodiment described above may be subject to variants which may be implemented in isolation or in combination.

[0100] The triggering of this DAT1 / DAT2 data can have several origins:

[0101] - A processor load greater than a given load;

[0102] - Detection of inactivity by a user of the STB reading device; the inactivity making a replay action from the beginning unlikely;

[0103] - An explicit request from a user of the STB reading device,

[0104] - Etc.

[0105] Finally, it should be noted here that the term "entity" or "module" can refer to a software component, a hardware component, or a set of hardware and software components. A software component itself corresponds to one or more computer programs or subprograms, or more generally, to any element of a program capable of implementing a function or set of functions as described for the modules in question. Similarly, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or set of functions for the module in question (integrated circuit, smart card, memory card, etc.).

[0106] We should also specify that a periodicity of sending or trabslussuion refers to periodic transmissions, for example a period of 2 seconds, or quasi-periodic transmissions, for example a period of 2 seconds plus or minus a few hundredths of a second, to indicate a measurement uncertainty that may be due to the more or less precise measurement of a measuring instrument.

Claims

Method for managing the transmission to a reading device (STB) of description files (MNF1 / MNF2 / etc.) describing content segment addresses, characterized in that the periodicity of sending the description files varies over time. Management method according to claim 1, characterized in that the periodicity is modified following the receipt of data from the reading device. Management method according to claim 2, characterized in that the data is data representative of a processor load of the reading device from which the data originates. Management method according to claim 1, characterized in that the data is data representative of a user activity in relation to the reading device. Management method according to claim 1, characterized in that the sending periodicity is established beforehand based on a processor load prediction. Entity for managing data transmission (ENT2), to a reading device (STB), of description files describing addresses of content segments, characterized in that it includes a module for modifying the periodicity of sending the description files. Content server (SRV) characterized in that it comprises an entity (ENT2) as defined in claim 6. Computer program capable of being implemented on a management entity (ENT2) as defined in claim 6, the program comprising code instructions which, when executed by a processor, carries out the steps of the process defined in claim 1. Data carrier on which at least one series of program code instructions for the execution of a method according to claim 1 has been stored. A method for managing access to description files describing content that has been broadcast on a delayed basis, the description including addresses of content segments, characterized in that it includes a step of transmitting data capable of requiring a modification of the transmission times of the description files. .Entity for managing access to description files describing content that has been broadcast on a delayed basis, the description including addresses of content segments, characterized in that it includes a data transmission module capable of requesting a modification of the transmission times of the description files. Reading device (STB) comprising a management entity (ENT1) as defined in claim 11. Computer program capable of being implemented on a management entity (ENT1) as defined in claim 11, the program comprising code instructions which, when executed by a processor, carries out the steps of the process defined in claim 10. Data carrier on which at least one series of program code instructions for the execution of a method according to claim 10 has been stored.

Images