Management of the provision of multimedia content segment addresses

Abstract

The invention relates to a method for managing the provision of manifests associated with segments of a segmented content item, the manifests, referred to as first manifests, comprising content segment addresses and being transmitted consecutively in succession with a view to being played back by a playback device (STB), characterized in that it comprises, during the transmission of the content item in real time, a step of receiving, from a playback device, a command to carry out a time hop in the content item in order to play back the content item from a time earlier than the current playback time, the receiving step triggering a step of transmission of a second manifest comprising addresses of segments to be played back at said earlier time, supplemented with some of the addresses of segments of the content item that have already been transmitted.

Description

[0001] DESCRIPTION

[0002] TITLE: Management of the provision of addresses of segments of multimedia content

[0003] Technical field

[0004] The field of the invention is that of managing the provision of segment addresses of multimedia content to a content playback device.

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

[0006] State of the art

[0007] When accessing content, a playback device typically sends a request to a server, indicating the selected content; 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 passes through the network access gateway, for example the residential gateway.

[0008] The playback device is adapted to receive digital content in the form of multimedia data and to request playback of this content on a playback device. The received data corresponding to a video is generally decoded, then played back in the form of a display of the corresponding video with its associated soundtrack. In the following, for the sake of simplification, the digital content will be considered a video and the playback by the playback device, or consumption by the user of the playback device, will be considered a display on the screen of the playback device.

[0009] The distribution of digital content on the Internet is often based on client-server protocols from the HTTP (Hyper Text Transport Protocol) family. In particular, progressive downloading of digital content, also called streaming, allows data to be transported and consumed in real time, i.e., the digital data is transmitted over the network and played back by the playback device as it arrives. The playback device receives and stores part of the digital data in a buffer before playing it back. This distribution method is particularly useful when the user's bandwidth is not guaranteed for real-time video transfer.

[0010] Adaptive progressive downloading, or HTTP Adaptive Streaming, abbreviated to HAS, also makes it possible to broadcast and receive data in different qualities, corresponding for example to different bit rates. These different qualities are described in a description file, called a "description file" by those skilled in the art, available for download on a data server, for example a content server. When the client playback device wishes to access content, this description file makes it possible to select the right format for the content to be consumed based on the available bandwidth or the storage and decoding capacities of the client playback device. This type of technique makes it possible in particular to take into account bandwidth variations on the link between the client playback device and the content server.

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

[0012] A function called Start Over (or "catch-up" or "return to the beginning") allows a user watching content broadcast in real time (Live channel) to select a playback moment in a given time window; this function allows content to be replayed from its beginning. A time window is particularly useful for so-called "live" digital content, i.e., content corresponding to real-time television programs, which, by nature, do not have a predefined duration or end date. In this case, the playback device receives a command to perform a time jump in the content to play the content, for example a television program, from a time prior to the current playback time. For example, if a film starts at 9:00 p.m. and the user switches to the channel at 9:40 p.m., the user can request that the content playback resume from the beginning of the film by activating the so-called catch-up mode.In this case, we move from a real-time reading mode to a catch-up mode.

[0013] When this user accesses the Live stream broadcast in http Adaptive Streaming (HAS), the playback device retrieves at regular intervals, generally every two seconds, a description file which generally describes the last sixty seconds of the stream (30 segments of 2 seconds) by providing segment addresses corresponding to these last sixty seconds. We can then decide to store a certain part of the stream in a buffer memory (here up to 60 seconds maximum). The video segments are short because we want to be as close as possible to the real Live. This is also why we retrieve the description file every two seconds and limit the buffer depth generally around fifteen seconds.

[0014] When switching to the so-called catch-up mode, i.e. on-demand playback mode, the description file that is retrieved no longer describes the last sixty seconds but a time window of several hours, for example the last four hours (in the case where we want to be able to access the last 4 hours of the Live channel). The size of the description file is therefore multiplied by two hundred and forty (240) and the reading time (or parsing time for those skilled in the art) of the description file, most of the time in XML format, becomes a real problem. Indeed, it is necessary to retrieve, as when reading the stream in real time, the description file periodically every two seconds and at each retrieval to browse the entire description file which includes a very large number of video and audio segment addresses.

[0015] One solution could be to reduce the time window, for example, to two hours instead of four. In this case, the service provided to the user is significantly degraded because there is no guarantee of being able to return, for example, to the beginning of the film they are watching.

[0016] The invention improves the situation.

[0017] The invention The invention relates to a method for managing the supply of description files associated with segments of segmented content, the description files, called first description files, comprising addresses of segments of the content and being transmitted successively one after the other for reading by a reading device, characterized in that it comprises, during the transmission of the content in real time, a step of receiving a command to perform a time jump in the content to read the content from a time prior to the current reading time, the reception step triggering a step of transmitting a second description file comprising addresses of segments to be read at said previous time, supplemented by a part of the addresses of segments of the content having already been transmitted.

[0018] The invention makes it possible, when a time jump request is requested, to transmit not a complete description file comprising all the segment addresses that have been broadcast as in the prior art but a subset of segment addresses from the complete description file. In other words, the description file transmitted is incomplete and only comprises a part of the segment addresses that will be judiciously chosen as will be seen below.

[0019] It is understood that the description file created is greatly reduced in size compared to that of the prior art because it ultimately only contains segment addresses to be read, just as for a conventional reading, and at best a few other segment addresses as will be seen in the rest of the description. It will indeed be seen in the description which follows that the description file created according to the invention describes only a few minutes (three minutes for example) of description of the segments whereas a complete description file can describe hours for example four hours.

[0020] Also, the recovery time of a segment in the description file which is the subject of the invention is rapid due to the very small number of segment addresses included in the second description file received; the transmission time over the network of such a description file is also advantageous in terms of bandwidth because of its reduced size.

[0021] According to a first embodiment of the method, the address part includes segment addresses transmitted in the last description file, called the first description file, in connection with the real-time reading. This mode allows a return to live without delay because it avoids requiring the first description file linked to the return to live.

[0022] According to a second particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous one, the segment address part includes segments chosen from the first segments of the content. Just like the previous mode, this mode allows, from the current reading time, in catch-up mode, to request a restart from the beginning without delay because the addresses of these segments are present in the second description file. It will be seen below that the segments chosen from the first segments target the oldest segments accessible in the proposed time window. For example, if the catch-up mode allows to return to a time window of a few hours, for example four hours in the past, the oldest segments are the oldest segments in this four-hour time window.

[0023] When the address portion includes both addresses referred to in the first mode and addresses referred to in the second mode, a progress bar (or timeline) may be rendered in order to situate the current reading moment in time and allow selection of an earlier or later reading moment in this progress bar and to continue reading from the selected moment.

[0024] According to yet a third particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous ones, the second description file is updated over time; in particular, the latest segment addresses associated with the stream transmitted in real time are updated. Each update allows a return to the stream transmitted in real time without requiring receiving a request for access to the first description file for access to the content broadcast in real time.

[0025] According to a fourth particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous ones, a selection, in the second description file, of one of the last segment addresses results in a transmission of a first description file, in place of the second description file. This fourth mode allows an automatic return to the real-time reading mode. This mode allows a return to the normal mode and therefore a return to the first description files which are smaller in size than the second description file.

[0026] According to a fifth particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous ones, the previous instant is selected in a given time window, and the part of the other addresses of segments of the content having been transmitted comes from this time window.

[0027] In a variant of this fifth mode, the time window has a fixed duration. This mode is useful when the content does not have a predefined start time; this is the case for most content transmitted in real time, as explained below.

[0028] When the content has a defined start time, we can then provide a time window whose duration varies over time depending on the start time of the content in question.

[0029] According to a material aspect, the invention relates to an entity for managing the supply of description files associated with segments of segmented content, the description files, called first description files, comprising addresses of segments of the content and being transmitted successively one after the other for reading by a reading device, characterized in that it comprises a microprocessor configured to, during the transmission of the content in real time, carry out a step of receiving a command to perform a time jump in the content to read the content from a time prior to the current reading time, this reception step triggering a step of transmitting a second description file comprising addresses of segments to be read at said previous time, supplemented by a part of the addresses of segments of the content having already been transmitted.

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

[0031] 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, carries out the steps of the management method defined above.

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

[0033] The medium in question may be any entity or device capable of storing the program. For example, the 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. Furthermore, the 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.

[0034] 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:

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

[0036] [Fig 2] schematically illustrates the hardware structure of a server capable of transmitting description files;

[0037] [Fig 3] schematically illustrates the hardware structure of a playback device capable of playing multimedia streams in real time;

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

[0039] [Fig 5] illustrates the reading state at a given time when the catch-up mode is executed; we will see in particular that during this mode, the management entity implements an algorithm to generate a description file specific to the catch-up reading mode.

[0040] [Fig 6] illustrates the state of the reading at a different time than that described with reference to figure 5 and still during the reading in catch-up mode. [Fig 7] schematically illustrates a time window implemented in which the said part of the other segment addresses of the content having been transmitted comes from, adding to the segment addresses to be read at the said previous time to ultimately form a second description file.

[0041] [Fig 8] illustrates steps of one embodiment.

[0042] Detailed description of embodiments of the invention

[0043] Figure 1 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 playback devices and description files associated with the multimedia content.

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

[0045] The reading device is for example a digital reading device.

[0046] The multimedia content referred to here is video content corresponding, for example, to a television channel on which television programs are broadcast with a start time corresponding to a scheduled broadcast time and an end time. The content in question is broadcast in multicast mode.

[0047] The STB playback device is connected to a TV playback terminal such as a television.

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

[0049] In our example, the STB playback device is located in a LAN (Local Area Network) managed by a GTW home gateway. The LAN context is given as an example and could easily be transposed to a best effort Internet network, a corporate network, etc.

[0050] The GTW gateway is capable of communicating via a LI1 telecommunications network such as a WAN known to those skilled in the art. 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.

[0051] 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 description of the invention, a single SRV content server will be shown in Figure 1 to represent the CDN. The SRV content server is located, in our example, in the wide area network WAN.

[0052] 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, in this case the STB playback device.

[0053] CNT content is made available in unicast mode in a given format. Such CNT 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 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 playback terminal and the multimedia content provider server. The main targeted protocol is HTTP, 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.

[0054] Figure 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 first entity, capable of managing the transmission of content and the description file associated with the content of the SRV server to one or more reading devices. The SRV server communicates with the GTW gateway via WAN network. The server includes, for communication with the WAN network, a communication module referenced COM2 in Figure 3. We will mainly focus in the following on the transmission of the description file rather than the transmission of the segments.

[0055] Figure 3 represents an architecture of an STB reading device. This STB device typically comprises 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.

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

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

[0058] The STB playback device comprises a streaming mode download entity (not shown) capable of managing the downloading of segments of the content. The STB playback 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 playback in catch-up mode as explained below.

[0059] We now present, in relation to Figure 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 segments Cli@Nj encoded at different encoding rates Nj, where the index i designates a temporal identifier of the segment Cli@Nj.

[0060] 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 how the HAS download module chooses the encoding rate of the next video segment to be downloaded: there are in fact many algorithms for making this choice, whose strategies are more or less secure or aggressive. However, it should be remembered that, most often, the general principle of such algorithms is based on downloading a first segment at the lowest encoding rate proposed in the description file, and on evaluating the retrieval time of this first segment.Based on this, the HAS download module assesses whether, based on the segment size and the time taken to retrieve it, 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 rate levels of successive segments.

[0061] 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 segment download time, which must be sufficiently low to allow continuous playback on the TV set.

[0062] First, the HAS module retrieves the description file corresponding 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 in Figure 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.

[0063] In a normal operating mode, not illustrated in Figure 4, the HAS module performs the downloading, 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. The different segments downloaded by the HAS download module are then transmitted to a display module AFF capable of requesting a display on a screen of the television TV.

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

[0065] Sometimes you miss the start of a television program (film, series, etc.). A function called "play from beginning" or "catch-up" (also called "Start Over" or "Restart" by those skilled in the art) allows you to resume, at any time, the program currently being broadcast at a time prior to the current time; for example, the playback of 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 playback of the content resume from the beginning of the film. In this case, we therefore move from a playback mode with real-time (or live) content to an on-demand playback mode.

[0066] When this user accesses a Live stream broadcast live 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 which generally describes the last 60 seconds of the stream (30 segments of 2 seconds). We can then decide to buffer a certain part of the stream (up to 60 seconds maximum); the video segments are short because we want to be as close as possible to the real Live. This is also why we retrieve the description file every 2 seconds and limit the buffer depth generally around 15 seconds.

[0067] In the state of the art, when switching to catch-up mode (or start over), the description file that is retrieved no longer describes the last sixty seconds but a time window much greater than sixty seconds. The time window can concern the last four hours; in this case, if we can replay the content from a moment located in the time window. The size of the description file is therefore multiplied by two hundred and forty (240) and the parsing time of the XML file becomes a real problem. Indeed, it is necessary to retrieve, as when reading the Live stream, this description file periodically every 2 seconds and at each retrieval browse (or parse) the entire description file which includes a very large number of tags describing video and audio segments.

[0068] The method of the invention comprises, during the broadcasting of the content in real time, a step of receiving from the reading device a command to perform a time jump in the content to read the content from a time prior to the current reading time, the reception step triggering a step of transmitting a second description file comprising addresses of segments to be read at said prior time, supplemented by a part of the other addresses of segments of the content having been transmitted.

[0069] We will see later that according to a variant, the previous instant is selected in a given time window preceding the current instant. We will also see that the address part is chosen in this time window.

[0070] In other words, when the catch-up function is activated, the ENT2 management entity installed on the server creates a description file specific to the catch-up reading mode including not only the addresses of segments to be read corresponding to the desired reading time but also part of the other segment addresses of the content having been transmitted throughout the given time range, for example the last four hours.

[0071] The size of the description file thus created is therefore reduced because the description file does not include all the addresses of the segments of the time range considered, i.e. the past four hours, but only a part of these addresses. Once the description file has been received by the reading device, the first entity ENT1 accesses the description file constructed according to the invention, and continues reading in catch-up mode from the reading time specified beforehand from which a resumption of reading is desired (for example 2hl7mn30sec in the past).

[0072] According to one embodiment, the SRV server will construct a description file which includes

[0073] - A first part MNFm (m is an integer) including addresses of segments to be read corresponding to the desired reading time; this part describes the 60 seconds of content corresponding to the desired reading time (between 2hl8mn30sec and 2hl7mn30 sec); this section is similar to a description file received during normal reading of the content;

[0074] - and at least a second part (AD11 / AD21; AD12 / AD22).

[0075] The second part, which can be written ADli / AD2j (i and j being integers), can be subject to variations described below.

[0076] According to a first variant, the second ADli part includes a set of segment addresses associated with the oldest sixty seconds of segments available in the time window (or time range) considered; in our example, this ADli part corresponds to the segments which were transmitted approximately four hours ago. This variant allows us to go back in time as much as possible.

[0077] In a second variant, the second AD2j part includes a set of AD2 segment addresses corresponding to the live stream, in our example, the most recent 60 seconds of video segments. The presence of this second AD2j part in the second description file is advantageous because it allows a return to live without delay.

[0078] According to a third variant, the second part combines the first and second variants. Here, the description file created specifically for the catch-up mode includes the segment addresses to be read at the selected time, and two parts ADI and AD2 as described above.

[0079] Since the time window for playing the content in catch-up mode is fixed in our example, each ADli / MNFn / AD2j part is updated when playing in catch-up mode.

[0080] The index "n" indicates the description file currently being read;

[0081] The index “i” denotes the i-th update of the first ADI part;

[0082] The index “j” denotes the j-th update of the AD2 part; m,i,j being integers.

[0083] An embodiment of the method of the invention will now be described with reference to Figures 5, 6 and 7.

[0084] Figures 5 and 6 illustrate the reading state at two distinct times TA and TA' (TA'>TA), respectively during a reading phase in catch-up mode. In Figures 5 and 6, the number of description files used is very limited so as to explain the invention simply.

[0085] In each figure 5 and 6, a first LIV time axis is represented corresponding to a reading of content transmitted in real time (or direct) and a second axis dedicated to the so-called RTP catch-up mode.

[0086] When playing the real-time content LIV, up to a current time TC, four description files MNF1-MNF4 are received successively by the playback device STB.

[0087] Referring to Figure 5, it is assumed that at the current time TC, the "catch-up" mode RTP, described above, is activated and that an earlier time TA at the current time (TA<TC) est sélectionné pour poursuivre la lecture en mode rattrapage. Un saut temporel (TC-> TA), in a time window described with reference to Figure 7, is then executed so as to resume reading at this previous instant TA.

[0088] According to the invention, following activation of the RTP catch-up mode described above, at time TC, the second entity ENT2 present on the server creates a description file AD11 / MNF2 / AD21, called the second description file, specific to this so-called catch-up reading mode which includes not only

[0089] - the segment addresses to be read corresponding to the TA instant as for the reading of live content, i.e. 60 seconds of content,

[0090] - but also at least one other set of segment addresses, here two sets of addresses AD11 and AD21 in accordance with the third variant described above.

[0091] This second description file specific to the so-called catch-up mode can be noted ADli / MNFn / AD2j; it is updated over time with a time interval similar to that used for the live stream.

[0092] Figure 6 illustrates the status of the catch-up reading at another later time TA' (TA'>TA). At this time TA', the server transmits a description file AD12 / MNF3 / AD22.

[0093] In this figure 6, we also see that the description files linked to the live stream continue to be transmitted in parallel. In our example, an MNF5 description file was transmitted in connection with the live stream. At each update, the segment addresses to be read are updated; the ADli and / or AD2j parts, depending on the chosen variant, are also updated to respect the chosen time window for going back in the content. As the time window corresponds to a limited time interval, the progress of the reading results in a modification of the interval limits.

[0094] Figure 7 illustrates the FT time window related to catch-up reading mode.

[0095] The FT time window is very useful for so-called "live" digital content, i.e., content corresponding to real-time television programs; in fact, this content does not, by nature, have a predefined duration or end date. When the catch-up mode is executed, for example, at time TCI, a segment can be selected in this FT window; similarly, if the catch-up mode is executed, for example, at time TC2, a segment can be selected in this FT window, which is shifted in time by a duration equal to TC2-TC1 ("-" is the mathematical sign corresponding to subtraction).

[0096] The time window is preferably of fixed duration. However, the duration of this time window can vary depending on the use case.

[0097] Figure 8 illustrates another embodiment illustrating the possibility of returning to live after a phase in catch-up mode.

[0098] This figure 8 includes two axes representative of an STB reading device and the CNT content server and the message exchanges between these two devices.

[0099] The method comprises a first LIV phase of playing content transmitted in real time, a second RTP phase of playing the content in catch-up mode and a third LIV phase of returning to real time.

[0100] During the first phase LIV, the playback device STB transmits a request REQ1 to access content. In return, the content server SRV transmits MNFl-MNFn description files at regular intervals in our example, for example every 2 seconds.

[0101] At a given time, the RTP catch-up mode is activated ACT. A reading time "TA" prior to the current time "TC" (TA <TC) est sélectionné de manière à relire le contenu depuis l'instant de lecture sélectionné. On suppose que l'instant TA correspond à l'instant auquel a été transmis antérieurement le fichier de description MNF2 en liaison avec le contenu diffusé en temps réal.

[0102] Data representing the activation and the TA reading time are transmitted by the STB reading device to the server and are received by the SRV server. These data can be conveyed by means of a single message or two separate messages.

[0103] Upon receipt of the data representing an activation and the selected reading time TA which corresponds to the segments described in the description file MNF2, the SRV server creates a specific description file AD11 / MNF2 / AD21 called the second description file. The second description file is for example the one described with reference to the third variant described above.

[0104] During this RTP phase, the SRV server transmits regular updates of the second description files, namely AD12 / MNF2 / AD22 and AD13 / MNF2 / AD23. In our example, the updates take into account the temporal displacement of the fixed time window, four hours in our example; for example, the part AD11 becomes AD12 during the update, then AD22, and so on.

[0105] Next, it is assumed that a segment address SEL(AD23) is selected from the set AD23 described above included in the second description file. The SEL selection is transmitted by the STB playback device to the SRV server. This selection results in an automatic transmission by the SRV server of a first description file MNF10, instead of the second description file of the type ADli / MNFn / AD2j, for a return to the stream transmitted live. The server then continues the transmission of the first description files, namely MNF11, etc. In other words, a selection of a segment address in the second description file corresponding to an address that will be transmitted by the server for the playback of the stream broadcast live is interpreted by the server as a desire to return to the real-time playback mode instead of the catch-up mode.

[0106] We have seen previously in connection with the second variant that the second description file can include two parts of addresses, one targeting the oldest segments, the other targeting the most recent, namely the segments currently being broadcast in real time. These two parts and the times of the associated segments make it possible to construct a progress bar (or timeline) in order to situate the current reading time in time and allow a selection of an earlier or later reading time in this progress bar and to continue reading from the selected time.

[0107] 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.)

Claims

CLAIMS . Method for managing the supply of description files associated with segments of segmented content, the description files, called first description files, comprising addresses of segments of the content and being transmitted successively one after the other for reading by a reading device (STB), characterized in that it comprises, during the transmission of the content in real time, a step of receiving (ACT+TA) a command to perform a time jump in the content to read the content from a time prior (TA) to the current reading time (TC), the reception step triggering a step of transmitting a second description file comprising addresses of segments to be read at said previous time, supplemented by a part of the addresses of segments of the content having already been transmitted.Management method according to claim 1, characterized in that the address part includes segment addresses transmitted in the last description file, called the first description file, in connection with the real-time reading. . Management method according to claim 1 or 2, characterized in that the segment address part includes segments chosen from the first segments of the content. . Management method according to claim 1 or 3, characterized in that the second description file is updated over time, and in that the last segment addresses associated with the stream transmitted in real time are updated. . Management method according to claim 2 or 4, characterized in that a selection, in the second description file, of one of the last segment addresses results in a transmission of a first description file, in place of the second description file. .Management method according to claim 1, characterized in that the previous instant (TA) is selected in a given time window (FT), and in that said part of the other addresses of segments of the content having been transmitted comes from this time window. Management method according to claim 1, characterized in that the time window has a fixed duration. Management entity (ENT) for the supply of description files associated with segments of segmented content, the description files, called first description files, comprising addresses of segments of the content and being transmitted successively one after the other for reading by a reading device, characterized in that it comprises a microprocessor configured to, during the transmission of the content in real time, carry out a step of receiving a command to perform a time jump in the content to read the content from a time prior to the current reading time, this reception step triggering a step of transmitting a second description file comprising addresses of segments to be read at said previous time, supplemented by a part of the addresses of segments of the content having already been transmitted.Reader terminal (STB) comprising a management entity (ENT) as defined in claim 8. Computer program capable of being implemented on a management entity (ENT) as defined in claim 8, the program comprising code instructions which, when executed by a processor, performs the steps of the method defined in claim 1. Data medium on which at least one series of program code instructions has been stored for the execution of a method according to claim 1.

Images