process for managing the replay of content that has been broadcast in real time.

Abstract

TITLE: Method for managing the replay of content that has been broadcast in real time. The invention relates to a method for managing access, by a playback device (STB), to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created outside the playback device (STB), of being downloaded via a communication link and of being read by the playback device (STB), the real-time playback requiring reception, from the communication link, of network addresses of the last segments created, called real-time segments, characterized in that it comprises following a request for access to content, reception of both the addresses of real-time segments, and at least one network address of a description file (ad-MNF(i),ad-MNF(i+1),…), called a catch-up file, describing segments other than the real-time segments. Figure for the abstract: Figure 5

Description

Title of the invention: method for managing the replay of content that has been broadcast in real time. Technical field

[0001] The field of the invention is that of managing the replay of content that has been broadcast in real time. The invention relates in particular to managing access to description files during delayed playback of multimedia content.

[0002] The invention particularly relates to segmented content, the segments being accessible according to several formats associated with respective sizes in bytes having more or less impact on the bandwidth of the network from which the content is downloaded. The invention particularly relates to content downloaded according to a technique known as adaptive progressive downloading, or HAS, or any other downloading techniques using the same principle.

[0003] Clarification that the segment addresses are included in a description file. A description file in the context of an adaptive progressive download is a file including, among other things, network addresses (IP address or URL) of the segments to be downloaded and read by a reading device. In other words, a description file describes segments in the form of network addresses, it being up to the reading device to access these segments via a network, for example the Internet.

[0004] The reading device targets all data processing devices equipped with processors and capable of accessing content segments through a network, of receiving the segments from a network, of decoding the received segments and of requesting a restitution 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 indicating the multimedia content (video and / or audio) chosen. The playback device receives in return a stream of digital data relating to this content. In the context of a local communication network, such a request may pass through a network access gateway, for example a residential gateway.

[0006] The received data is then decoded by the reading device, then restored in the form of a display of the corresponding video.

[0007] The distribution of digital content on the Internet is often based on client-server protocols of the HTTP family (from the English “Hyper Text Transport Protocol"). In particular, progressive downloading (HTTP Adaptive Streaming, abbreviated to HAS) of digital content, also called "Adaptive Streaming", allows data to be transported and read in real time, i.e. the digital data is transmitted over the network and played back by the playback device as it arrives. Following reception of the stream, the playback device stores the received data in a buffer before playing it back. This distribution method is particularly useful when the user's available bandwidth is not guaranteed for real-time video transfer.

[0008] Adaptive progressive downloading also makes it possible to broadcast and receive data in different qualities corresponding, for example, to different respective encoding rates. 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 reading device receives at regular intervals, generally every two seconds, successive description files, hereinafter called real-time description files, each of which generally describes the last sixty seconds of the stream (30 segments of 2 seconds) by providing IP addresses (an acronym for "Internet Protocol") of segments corresponding to these last sixty seconds.

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

[0011] Note that an encoding rate is selected from the available rates depending on the available bandwidth or the storage and decoding capacities of the playback device. This type of technique makes it possible to take into account bandwidth variations on the link between the client playback device and the content server.

[0012] In addition to playing content, some playback devices offer a function called "Start Over" by those skilled in the art (or "catch-up" or "return to the beginning") which allows a user watching content broadcast in real time (Live channel) to replay part of the content that was broadcast Live; this function allows in particular to replay content from its beginning. For example, if a film broadcast in real time starts at 9:00 p.m. and if the user accesses the corresponding Live stream by zapping on the channel at 9:40 p.m., the user can request, by selecting a command linked to the so-called catch-up function, that the playback of the content resumes for example from the beginning of the film. In this case, we switch from a real-time playback mode to a catch-up mode.

[0013] In this catch-up mode, a command interface offers the possibility of selecting one or more commands which modify the current playback of the content broadcast in real time. These commands allow, for example, to interrupt playback, or to make a time jump to replay the content from a previous playback time and therefore to play the content later.

[0014] When a content is read and the so-called catch-up function is not offered, in this case the description files received successively, hereinafter called "real-time description files", are those described above. On the other hand, when the so-called catch-up function is available, the reading device receives from the start of the reading of the content specific description files successively, hereinafter called "catch-up description files", which describe not the last sixty seconds but a larger time range very often of several hours, for example the last four hours, so as to be able to replay the content from an instant situated in the four-hour time 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 conventional description file because it includes all the network addresses of all the segments created over the last four hours. Concretely, a real-time description file has a size of the order of 12 kB (description of 30 segments of 2 seconds) and a catch-up description file has a size of the order of 2.8 MB (description of 7200 segments of 2 seconds).

[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 enormous bandwidth on the network, which can affect the quality of service when rendering the content, especially for homes equipped with an internet line with low bandwidth, such as an ADSL line. In addition, such catch-up description files require excessive processing times (which those skilled in the art call parsing times), which can affect normal playback of the content if the processing capacity of the playback device is low-performance. This then results in image freezes that are unbearable for a user.

[0018] These problems impair the user experience even though the user has not selected a command that results in replay and may not intend to replay the broadcast content.

[0019] The invention improves the situation. The invention

[0020] For this purpose, according to a first functional aspect, the invention relates to a method for managing access, by a reading device, to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created outside the reading device, of being downloaded via a communication link and of being read by the reading device, the real-time reading requiring reception, from the communication link, of network addresses of the last segments created, called real-time segments, characterized in that it comprises following a request for access to content, reception of both the addresses of real-time segments, and at least one network address of a description file, called a catch-up file, describing segments other than the real-time segments.

[0021] According to the invention, following a request for access to the content in catch-up mode, the reading device receives a description file comprising catch-up description file network addresses. The use of description file network addresses instead of description files reduces the size of the data to be transmitted, thus reducing the bandwidth occupied during the transmission of data relating to the segments to be read in catch-up mode. In addition, reading an address is much faster than a description file; the reading device is therefore not slowed down when it reads the description files received during the reading of the content in real time.

[0022] According to a particular embodiment of the invention, following the reception of several catch-up files, the reading device accesses a catch-up file as soon as a command to access a segment concerns a segment described in a received catch-up file. The reading device receiving a description file including the network addresses of the catch-up files can thus access a segment in deferred mode at any time.

[0023] According to yet another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous ones, the real-time segments and said at least one catch-up file address are included in the same description file. This mode allows the entity responsible for creating the description files to simplify the creation by creating only a single file including the segments associated with catch-up files and the real-time segments.

[0024] According to a first material aspect, the invention relates to an entity for managing access, by a reading device, to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created outside the reading device, of being downloaded via a communication link and of being read by the reading device, the reading in real time real requiring reception, from a communications network, of network addresses of the last segments created, called real-time segments, characterized in that it comprises a processor configured to carry out, following a request for access to content, reception of both real-time segment addresses and at least one network address of a description file, called a catch-up file, describing segments other than the so-called real-time segments.

[0025] According to another material aspect, the invention relates to a reading device comprising a management entity as defined above.

[0026] According to another material aspect, the invention relates to a computer program capable of being implemented on a management entity as defined above, the program comprising code instructions which, when executed by a processor, carry out the steps of the management method defined above.

[0027] According to another material aspect, 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 management method as defined above.

[0028] According to a second functional aspect, the invention relates to a method for managing the transmission of description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created and of being transmitted via a communication link to a reading device, the real-time reading on the reading device requiring a transmission, via the communication link, of network addresses of the last segments created, called real-time segments, characterized in that it comprises, following a request for access to content, a transmission of both the addresses of real-time segments, and at least one network address of a description file, called a catch-up file, describing segments other than the so-called real-time segments.

[0029] We will see later that a catch-up description file can be transmitted alone or simultaneously with a real-time description file.

[0030] According to a particular embodiment of the second entity, the catch-up description file is transmitted after a given duration.

[0031] According to a particular embodiment of the second entity, which may be implemented alternatively or cumulatively with the previous one, the catch-up description file is transmitted after a given number of transmissions of real-time description files.

[0032] The two preceding modes cover the fact that the catch-up description file is not necessarily the first description file transmitted following receipt of the request for access to the content currently being broadcast; on the contrary, the catch-up description file is transmitted later, either after a given duration, or after a given number of real-time description files transmitted. These two Modes assume that a user accessing content does not generally require replaying within the first few minutes. The given duration or number of times referred to above will be chosen judiciously to take into account the time a user takes before replaying content.

[0033] According to another material aspect, the invention relates to an entity for managing the transmission of description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created and of being transmitted via a communication link to a reading device, the real-time reading on the reading device requiring a transmission, via the communication link, of network addresses of the last segments created, called real-time segments, characterized in that it comprises a processor configured to carry out, following a request for access to a content, a transmission of both real-time segment addresses and at least one description file network address, called a catch-up file, describing segments other than the so-called real-time segments.

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

[0035] According to another material aspect, the invention relates to a computer program capable of being implemented on a second management entity as defined above, the program comprising code instructions which, when executed by a processor, carries out the steps of the method defined in connection with the second functional aspect.

[0036] Finally, according to another material aspect, 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 for managing the transmission of description files.

[0037] The media referred to above may be any entity or device capable of storing the program. For example, a medium may comprise 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 disk. On the other hand, an information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention may in particular be downloaded from a network such as the Internet. Alternatively, the information medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.

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

[0039] [Fig. 1] represents an Internet progressive download architecture based on the use of adaptive streaming according to an embodiment of the method of the invention;

[0040] [Fig.2] schematically illustrates the hardware structure of a server capable of transmit description files;

[0041] [Fig.3] schematically illustrates the hardware structure of a reading device able to play media streams in real time;

[0042] [Fig.4] illustrates content and the segments available for that content.

[0043] [Fig.5] illustrates an embodiment of the method of the invention; this figure illustrates communication between the playback device and the content server; this figure shows a transmission of catch-up file addresses.

[0044] Detailed description of embodiments of the invention

[0045] [Fig.l] represents a computer system SYS in which a content distribution network called CDN (Content Distribution Network) is implemented by those skilled in the art from which content is transmitted to client devices or content reading devices and description files associated with the multimedia content.

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

[0047] The reading device is for example a digital reading device such as a decoder.

[0048] 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, i.e. broadcast in real time.

[0049] In our example, the STB playback device is connected to a TV playback terminal such as a television.

[0050] In our example, the STB playback device is connected to a port of the TV playback device; the STB playback device and the TV playback device could also form a single device.

[0051] In our example, the reading device STB is located in a local area network LAN (English acronym for "Local Area Network") managed by a home gateway GTW. The context of the local network is given as an example and could easily be transposed to a "best effort" type Internet network, a corporate network, etc. We will see later that the reading device STB comprises a first management entity ENT1.

[0052] The GTW gateway is capable of communicating via a communication link LU which may be a telecommunications network such as a wide area network WAN known to those skilled in the art.

[0053] 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.

[0054] The CDN network consists of servers connected in a network in the wide area network; these servers cooperate in order to make multimedia contents available to users in unicast mode. In order to simplify the presentation of the invention, a single SRV content server will be shown in [Fig.l] to represent the CDN. The SRV content server is located, in our example, in the wide area network WAN.

[0055] The SRV content server receives, for example, 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.

[0056] The Cl contents are made available in unicast mode in a given format. Such Cl content is, for example, content downloaded in adaptive streaming mode. The MPEG-DASH standard (for “Dynamic Adaptive Streaming over HTTP”) is a standard for audiovisual broadcasting formats on the Internet; this standard is based on the preparation of the content in different representations of variable quality and bitrate, divided into short segments (of the order of a few seconds), also called “chunks” by those skilled in the art. Each of these segments is made available individually by means of an exchange protocol between the rendering terminal and the multimedia content provider server. The protocol mainly targeted is the HTTP protocol, but other protocols (for example FTP) can also be used.The organization of the segments and the associated parameters are published in a description file in XML format. We will not go into further details of this download method because it is of no interest for the presentation of the invention.

[0057] An example of a description file or “manifest” (MPD) compliant with the MPEG-DASH standard and comprising the description of contents available in three different qualities (NI = 512 kb / s, N2 = 1024 kb / s, N3 = 2048 kb / s) of fragmented contents is presented in Appendix 1. This simplified description file describes digital contents in an XML syntax (from the English “eXtended Markup Language”), comprising a list of contents in the form of segments conventionally described between an opening tag ( <segmentlist>) and a closing tag (< / segmentlist>). Segmenting allows for finely adapting to bandwidth fluctuations. Each segment corresponds to a certain duration (field "duration") with several quality levels and allows their addresses (URL - Uniform Resource Locator) to be generated. This generation is done in this example using the "BaseURL" elements ("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:

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

[0059] - “Cl_512kb_2.mp4” for the second fragment,

[0060] - etc.

[0061] [Fig.2] the SRV server is also equipped with at least one CPU2 processor and MEM2 memories for performing computer processing. The server is also equipped with a management entity ENT2, called the second management entity, capable of managing the transmission of content and the description file associated with the content from the SRV server to one or more reading devices, here to the reading device STB. The SRV server communicates with the GTW gateway via WAN network. The server comprises, for communication with the WAN network, a communication module referenced COM2 in [Fig.3]. In the following, we will mainly focus on the transmission of the description file rather than the transmission of the segments.

[0062] [Fig. 3] represents an architecture of an STB reading device. This STB device conventionally comprises memories MEM1 associated with a processor CPU1. The memories can be of the ROM (Read Only Memory) or RAM (Random Access Memory) type or even Flash.

[0063] The STB playback device can transmit content to be played back to the TV playback device via a COM 12 communication module. This COM 12 module is, for example, an HDMI link.

[0064] The STB reading device communicates with the gateway via an Ethernet module for local wired communication or via a WiFi type radio module for local wireless communication with the GTW residential gateway. The module in question is referenced C0M11 in [Fig.2].

[0065] The STB reading device comprises a HAS streaming mode download module (not shown) capable of managing the downloading of segments of the content. The STB reading device also comprises a management entity ENT1, referred to as the second management entity in the following, capable of reading a description file constructed specifically during a reading in catch-up mode as explained below. The HAS download module and the first entity ENT1 may form only one entity, in which case the HAS module is integrated into the first entity ENT1, or be separated from each other.

[0066] We now present, in relation to [Fig.4], a schematic view of a main content Cl cut into segments and stored in the content server SRV. More precisely, the content server HAS exposes a video Cl in the form of Cli@Nj segments encoded at different encoding rates Nj, where the index i denotes a temporal identifier of the Cli@Nj segment.

[0067] The HAS download module, called classic download mode below, of the STB playback device is responsible for retrieving the segments from the HAS content server by choosing the video quality Nj according to the available network resource. We will not describe here in more detail the way in which the HAS download module chooses the encoding rate of the next video segment to be downloaded. It should be noted 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 description file, and on the evaluation of the retrieval time of this first segment. On this basis, the HAS download module evaluates whether, according to 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 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.

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

[0069] Firstly, the HAS module retrieves the description file which corresponds to the video content Cl in order to discover the available segments of the video content Cl, and the different video qualities Nj associated with it. In the example of [Fig.4], the content Cl is for example proposed in the form of segments of duration 3s, with a first encoding rate NI = 400 kb / s, a second encoding rate N2 = 800 kb / s, a third encoding rate N3 = 1200 kb / s, etc.

[0070] In a normal operating mode, not illustrated in [Fig.4], the HAS module performs the downloading, for example, of successive segments Cil@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.

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

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

[0073] It sometimes happens that the beginning of a television program (film, series, etc.) broadcast in real time is missed. A function called "play from beginning" or "catch-up" (also called "Start Over" or "Restart" by those skilled in the art) allows the program currently being broadcast to be resumed at any time at a time prior to the current time; for example, the content can be resumed from its beginning. For example, if a film starts at 9:00 p.m. and the user switches to the channel at 9:40 p.m., they can request that the content be resumed from the beginning of the film. In this case, the user therefore switches from a real-time content playback mode to a delayed playback mode.

[0074] When this user accesses a Live stream broadcast in real time (Live content) in http Adaptive Streaming (HAS), the STB playback device, meaning the HAS entity installed on this device, generally retrieves every 2 seconds a description file, hereinafter called the real-time description file, which generally describes the last sixty seconds of the stream (30 segments of 2 seconds). We can then decide to store in memory (buffer) a certain part of the stream (up to 60 seconds maximum therefore); the video segments are of short duration because we want to be as close as possible to the real Live, that is to say to the filmed event, for example a Football match. It is also for this reason that we retrieve the description file every two seconds and that we limit the buffer depth generally around fifteen seconds in order not to cause too great a lag between the Football match and its restitution on a screen.

[0075] A command interface (the symbols most often present on a remote control are " " " for rewind, " " " for fast forward and " II " for the Pause command) allows you to act on the current playback of the Live content. Commands in particular allow you to activate the catch-up mode (or start over).

[0076] In order to ensure execution of a command from the command interface, for example the "rewind" command, the description file that is retrieved no longer describes the last sixty seconds but a time window greater than sixty seconds. The time window in question may concern the last four hours of broadcasting; in this case, the content can be replayed from a time located within the four-hour time window. In our example, the server automatically records the content broadcast live over a sliding time range of four hours. During this time window FT, the content is recorded; due to the sliding of the time window, the segments recorded at a given time that are no longer within the sliding time window at a later time are erased.

[0077] In the following, we will call “Real-time file” the description file, describing the last segments produced on the server in connection with the real-time reading of the content.

[0078] Description files describing segments that have already been broadcast and allowing segments to be replayed later will also be called “catch-up files”.

[0079] According to the invention, when access is requested to the content, the server transmits in return a current description file including both the network addresses of the segments to be read linked to the real-time broadcasting of the content and network addresses of catch-up description files describing segments having been created before the access request allowing the content to be read later.

[0080] The network addresses of the segments linked to the catch-up are not included in the current description file; The description file transmitted to the reading device STB includes addresses of catch-up description files. It is up to the first entity ENT1 to download these catch-up files subsequently and to access the segments using the network addresses included in the catch-up description files when a reading in catch-up mode is subsequently desired.

[0081] [Fig.5] illustrates an embodiment of the method of the invention. In this [Fig.5], two vertical axes are represented corresponding respectively to two entities, namely the first entity ENT1 present on the reading device STB and the second entity ENT2 present on the server SRV. [Fig.5] illustrates the data exchanges which take place between the reading device STB and the content server SRV.

[0082] Let us specify here that commands are available via a command interface (not shown in the figures) throughout the reading. There are commands such as - a return command " " " - a Pause “II” command - a fast forward command " " " (this command can only be used when playback is already delayed)

[0083] Note that in this [Fig.5], only a portion of the messages useful for understanding the invention are illustrated. For example, after receipt of a description file by the STB reading device, the latter in principle requires access to the segments described in this received description file; we have chosen not to show these access messages because they are of no interest for the presentation of the invention.

[0084] Executing the commands given as examples above results in delayed playback of the Live content currently being broadcast. The interface may of course include other commands that do not have such an impact on the current playback; such a command is, for example, a command to display information about the content currently playing.

[0085] Commands whose execution results in a delayed replay of the content from a chosen playback time require a description of segments that have been broadcast in the past; a real-time description file that only describes the last segments produced linked to the real-time broadcast is therefore not sufficient; the first entity ENT1 will therefore be responsible for retrieving at least one catch-up description file to be able to execute a command correctly. To do this, the first entity ENT1, when it receives a description file including catch-up description file network addresses, performs the following steps:

[0086] - the first entity ENT1 browses the last current description file received MNFtr,

[0087] - the first entity ENT1 identifies the address of the catch-up description file which includes a description of the segments that correspond to the time of playback chosen for delayed playback,

[0088] - the first entity ENT1 requires, thanks to the network addresses of the files of catch-up, a download of the catch-up description file(s)

[0089] - the first entity ENT1 receives in return the catch-up file(s),

[0090] - and the first entity ENT1 then downloads the relevant content segments to the basis of the catch-up files describing the network addresses of the segments.

[0091] The steps of one embodiment are as follows; it is assumed here that the command interface comprises at least one command causing delayed reading and therefore requiring catch-up description files; it is also assumed that the user accesses a “Live” channel at 10 a.m. and that the program in question started at 9 a.m., therefore one hour ago.

[0092] Until receipt of the ACC access request by the SRV server sent from the STB reading device at a time te, with reference to [Fig.5], several description files, namely in our example:

[0093] MNF1,MNF2, ..., MNF(i), MNF(i+l),..., MNFtr

[0094] (the “tr” index referring to a real-time description file)

[0095] are created in connection with content segments and accessible from network addresses ad-MNFl,ad-MNF2, ..., ad-MNF(i), ad-MNF(i+l),..., respectively; description files targeting segments that have already been created in the time range of four hours T preceding the current time te will be referenced MNFT in the figure.

[0096] During a first step, at time te, the first entity ENT1 requests R-ACC access to multimedia content.

[0097] During a second step, the SRV server and therefore the second entity ENT2 receives the R-ACC access request.

[0098] During a third step, according to one embodiment, the second entity ENT2 requires the transmission of a description file including both - network addresses ad-MNF(i), ad-MNF(i+l),..., of respective description files MNFi, MNF(i+l), etc. including a description of the segments broadcast in the time window T preceding the instant te, i.e. for four hours; these files are called catch-up description files in the following; - as well as the description of the last MNFtr segments, called real-time segments, produced by the server intended to be read by the STB reading device in connection with the content.

[0099] According to the invention, the description of segments of the catch-up files created over a period T, four hours in our example, are therefore provided in the form of network addresses (for example URLs) in order to reduce the size of the description files transmitted successively.

[0100] According to a possible variant of the invention, two description files could be transmitted separately; a first comprising the catch-up files, namely the addresses of catch-up description files (MNF(i),MNF(i+l), ...) up to the last catch-up file created which precedes the real-time file MNFtr; and a second comprising the last description file MNFtr including the last segments created linked to real-time reading.

[0101] The SRV server creates, in our example every 2 seconds, a description file namely - MNF(i) at time ti - MNF(i+l) at time ti + 2 sec. - Etc.

[0102] Suppose that at a given time tacc, the user accesses the content.

[0103] The STB reading device receives in return description files as defined above, namely a description file including addresses of catch-up description files and real-time segments. Assuming that the instant ti corresponds to four hours preceding the instant tacc, the STB reading device successively receives the following description files:

[0104] Ad-MNF(i),...,MNFtr at time t(i)

[0105] Ad-MNF(i+l),...,MNFtr at time t(i+l) i.e. two seconds later in our example

[0106] Ad-MNF(i+2),...,MNFtr at time t(i+2) i.e. four seconds later in our example

[0107] And so on.

[0108] At this stage, the STB reading device may request a reread using the addresses of catch-up files included in the received description file.

[0109] Note that the MNFtr real-time description files received successively are different. However, for reasons of simplification of the presentation, the latter are always referenced MNFtr in this text.

[0110] With reference to [Fig.5], it is assumed that at a time “tr”, a user selects the rewind command “ “” on his remote control and selects a replay time from which a replay, or delayed playback, is desired.

[0111] The first entity ENT1 receives the command and requests its execution by the processor.

[0112] At this stage, the first entity ENT1 is aware of the time linked to the rereading and determines the address Ad-MNF(j) of the relevant catch-up description file MNF(j) among the addresses of catch-up description files received which are necessary for the rereading of the content from this time.

[0113] Once the address of the catch-up file has been identified, the first entity ENT1 requests a download of the catch-up file MNF(j) from the SRV server; for this, the first entity ENT1 includes the address ad-MNF(j) in the request.

[0114] The server receives the address ad-MNF(j), and downloads the corresponding catch-up file MNF(j). In our example, the server also transmits all or part of the following catch-up files MNF(j+l), etc. The transmission can be carried out indifferently catch-up file by catch-up file one after the other, or by group of catch-up files.

[0115] Following receipt of the catch-up file MNF(j), the first entity can access the segments using the network addresses included in the file.

[0116] At this stage, the first entity ENT receives the segments and manages the restitution of these segments; the first entity ENT1 requests from the HAS download module a download of the description files successively and accesses the segments. Reading is carried out at this stage in deferred time compared to the real-time broadcast which continues.

[0117] Downloading of the catch-up files then continues in the same manner until a command to stop the delayed reading is received.

[0118] Finally, let us also specify here that the term “entity” can correspond to a software component as well as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or, more generally, to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.). ANNfXB 1; exempt from msmfest file <MR3 ?ww.vÿ3 XMLSctwjaJMîamse* Wew <ete^p®$:OAStex^ WD &0U" <$i:scnemsi,<x.afcùn-'DASH sc-e^a,MPO:20' ; OASH WD^W lypes'eynamîc" æw«\w e3^:pjî> hîe swriiw20 i ; "> xAeps'ewsteW: te'C'CrcîteetaWsvrr w$h ■ * * Dite " Wgte.. -7^ s*3« w SAM * Wte^îte h :. W)W > <SteS <teal>HTrP:.the^^^ s.# Gcoaw € î a & î »5 ■> ^Se^eeWîW < It is wsw> subKieUM =«”£ LJ Sw;„§ 1 £ WQ J> i 2WLdesh ^&K,WS^US$ îWi»' 50' > <Sew«teWL msteieW * JLtetes. J esp4'7te x'Segmw&W. ewliW — <f- - CiWesfe C J x W»?<Wè '■'> < tewsWtesse > ^ramuxvsw^w <texŸ$mete&s^e> < S^gjïse aliter dus^«!>■" S Ote ^SW'rwteteL mJteteXJW <ite^ teS^R>entL:$î> the" Cwersetei e WteteOte »> <texsee'teàï<3se> <îteW>?stœ seés-€SUtea=m.JS^^ venteuse» * and tel »« dsate Wtete Ote «S^w^niWLmsdte^^^^b J^07»,v, ^teteo^tel :te> ^s- O â Âhteoteste —> Wte^ee;Seae> < All <te s^ftete^Lte’ ïfi^t8«se> «sS^weatuf^LQ^t^jLmpA^ cSegments ;$?> te" Cff»wC2 4 statesKitete5 -'> 'Stexss're'breast^î. -' 'tereWete x xiïWMateCOSsSteJOWCOJ^i^ < / Segment'*' - ck *from Ote ee\ '^i « <'^dWt^L10teiW j <teHste. Six*$5YmBtl^> < * ■ Can»w LS to ïteteteLW? «■> <SegrnsBî&.ïse> breasttests ewwURLtetelJSssteJ^^ do you knowBX? <tete> < Segre e tel «si ternie«W1 Ote *SegB>e«euRL meœote'CL JOOiWt „J ■ > <:$eOtesate;LSte xOJtemetetete «WD>< / tete> < / teal>

Claims

Claims

1. Method for managing access, by a reading device (STB), to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created outside the reading device (STB), of being downloaded via a communication link (LU) and of being read by the reading device (STB), the real-time reading requiring reception, from the communication link, of network addresses of the last segments created, called real-time segments, characterized in that it comprises following a request for access to content, reception of both the addresses of real-time segments, and at least one network address of a description file (ad-MNF(i),ad-MNF(i+l),...), called a catch-up file, describing segments other than the real-time segments.

2. Management method according to claim 1, characterized in that, following the reception of several catch-up files, the reading device accesses a catch-up file as soon as a segment access command concerns a segment described in a received catch-up file.

3. Management method according to claim 1, characterized in that the real-time segments and said at least one catch-up file address are included in the same description file.

4. Management entity (ENT1) for access, by a reading device (STB), to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created outside the reading device (STB), of being downloaded via a communication link and of being read by the reading device (STB), the real-time reading requiring reception, from the communication link, of network addresses of the last segments created, called real-time segments, characterized in that it comprises a processor configured to carry out, following a request for access to content, a reception of both real-time segment addresses, and at least one network address of a description file, called a catch-up file, describing segments other than the so-called real-time segments.

5. Reading device (STB) comprising a management entity (ENT1) as defined in claim 4.

6. Computer program capable of being implemented on a management entity (ENT1) as defined in claim 4, the program comprising code instructions which, when executed by a processor, performs the method steps defined in claim i

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

8. Method for managing the transmission of description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created and of being transmitted via a communication link to a reading device (STB), the real-time reading on the reading device requiring a transmission, via the communication link, of network addresses of the last segments created, called real-time segments, characterized in that it comprises, following a request for access to content, a transmission of both the addresses of real-time segments, and at least one network address of a description file, called a catch-up file, describing segments other than the so-called real-time segments.

9. Management entity (ENT2) for the transmission of description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being created and of being transmitted via a communication link to a reading device (STB), the real-time reading on the reading device requiring a transmission, via the communication link, of network addresses of the last segments created, called real-time segments, characterized in that it comprises a processor configured to carry out, following a request for access to content, a transmission of both real-time segment addresses and at least one description file network address, called a catch-up file, describing segments other than the so-called real-time segments.

10. Content server (SRV) characterized in that it comprises an entity (ENT2) as defined in claim 9.

11. Computer program capable of being implemented on a management entity (ENT) as defined in claim 9, the program comprising code instructions which, when executed by a processor, performs the steps of the method defined in claim e

12. O. Data carrier on which at least one series of program code instructions for executing a method has been stored according to claim 8.

Images