method for managing access to description files associated with content broadcast in real time.

Abstract

TITLE: Method for managing access to description files associated with content broadcast in real time. The invention relates to a method for managing access to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being downloaded via a communication link (LI1) and read by a segment reading device (STB), the reading requiring the reception, from a communication network, of description files of a first type, a command interface being accessible during the reading, the execution of a command from the interface requiring the reception of a description file of a second type, characterized in that it comprises the reception, following a request for access to content, of both a description file of the second type and successive description files of the first type;and in that the second type description file received is supplemented over time by at least a portion of the first type description files received successively. Figure for the abbreviation: Figure 1;

Description

Title of the invention: Method for managing access to description files associated with content broadcast in real time. technical field

[0001] The field of the invention is that of managing access to description files associated with multimedia content broadcast in real time.

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

[0003] It should be noted that the segment addresses are included in a description file. A description file in the context of adaptive progressive downloading is a file that includes, among other things, the IP addresses of the segments to be downloaded and read by a reading device. In other words, a description file describes segments in the form of IP addresses, and it is up to the reading device to access these segments via an Internet network.

[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 indicating the selected multimedia content (video and / or audio). The playback device then receives a digital data stream related to this content. In 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, and then displayed in the form of a corresponding video display.

[0007] The distribution of digital content over the Internet is often based on client-server protocols of the HTTP (Hyper Text Transport Protocol) family. In particular, the progressive downloading (HTTP Adaptive Streaming, abbreviated HAS) of digital content, also called Adaptive streaming allows for the transmission and playback of data in real time. This means that digital data is transmitted over the network and played back by the playback device as it arrives. Upon receiving 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 insufficient for real-time video transmission.

[0008] Adaptive progressive downloading also allows data to be transmitted and received at 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 playback device retrieves and receives at regular intervals, generally every two seconds, successive description files, hereafter referred to as description files of a first type, 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 of short duration 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 bitrate is selected from among the available bitrates based on the available bandwidth or the storage and decoding capabilities of the reading device. This type of technique makes it possible to take into account bandwidth variations on the link between the client reading device and the content server.

[0012] In addition to content playback, some playback devices offer a function known to those skilled in the art as "Start Over" (or "rewind" or "return to beginning") which allows a user watching live-streamed content (a live channel) to replay a portion of the live broadcast; this function allows, in particular, the playback of content from its beginning. For example, if a live-streamed film starts at 9:00 PM and the user accesses the corresponding live stream by switching to the channel at 9:40 PM, the user can request, by selecting a command related to the rewind function, that playback of the content resume, for example, from the beginning of the film. In this case, the user switches from a live-streaming mode to a rewind mode.

[0013] In this catch-up mode, a command interface offers the possibility of selecting one or more commands that modify the current reading of the content broadcast in real time. These commands allow, for example, pausing playback, or performing a time jump to replay the content from a previous reading point, thus enabling delayed playback.

[0014] When content is being played and the catch-up function is not available, the description files received successively, referred to hereafter as first-type description files, are those described above. However, when the catch-up function is available, the playback device receives specific description files successively from the start of content playback. These second-type description files describe not just the last sixty seconds, but a longer 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] Such a second-type description file, describing for example the last four hours, is two hundred and forty (240) times larger than a conventional description file. Specifically, a first-type description file has a size of approximately 12 KB (description of 30 two-second segments) and a second-type description file has a size of approximately 2.8 MB (description of 7200 two-second segments).

[0016] Just like the first type of description file, the second type of description file is downloaded periodically, for example, every two seconds. Due to its enormous size, the periodic transmission of the second type of description file requires enormous bandwidth on the network, which can impair the quality of service when the content is displayed, especially for households with low-speed internet connections such as ADSL; furthermore, such description files require excessive processing times (parsing times), which can impair normal content playback if the processing capacity of the playback device is low; this can cause image freezes that are unbearable for a user.

[0017] The invention improves the situation. The invention

[0018] To this end, according to a first functional aspect, the invention relates to a method for managing access to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being downloaded via a communication link and read by a segment reading device, the reading requiring the reception, from a communication network, of description files of a first type, a command interface being accessible during the reading, the execution of a command from the interface requiring the reception of a description file of a second type, characterized this that it includes a receipt following a request for access to content, of both a second type description file and successive first type description files; and in that the second type description file received is supplemented over time by at least some of the first type description files received successively.

[0019] According to the invention, the second type description file is received at a given time and completed (or updated) by the reading device based on first type description files received successively after that time by the reading device.

[0020] The invention avoids, when commands require the receipt of a second type description file because the so-called catch-up function is available, receiving only second type files one after the other as in the prior art.

[0021] According to the invention, only one second-type description file could be transmitted initially and subsequently supplemented by segment descriptions from first-type description files received successively. However, the invention does not preclude the possibility of receiving several description files, for example at regular intervals, followed by groups of first-type description files, respectively.

[0022] Due to the transmission of a limited number of second type description files and the transmission of first type description files smaller in size bytes which will complement the second type description file, there is a huge gain in bandwidth on the network which carries the description files.

[0023] According to the invention, a second type description file is created outside the reading device, at the level of the content server or a server associated with this content server, and is kept up to date on the reading device.

[0024] According to a first embodiment of the method, if received files of a first type and a second type describe the same segments, the relevant segments are read from the received first-type description file. A management entity checks, upon receiving second-type description files, whether a simultaneously received first-type file describes identical segments. This method will essentially apply to the first segments to be read because, as will be seen below, the first segments to be read can be included in both the second-type file and a first-type file. This method avoids using a second-type description file to read the real-time stream because it is large in bytes and therefore takes longer to process. The rendering could be delayed and thus create a time lag with the live stream.

[0025] According to yet another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding one, an update is performed on the basis of all received first-type description files. The advantage of an update on the basis of all first-type description files is that the second-type description file is ultimately complete and can be reviewed from any segment that has already been distributed.

[0026] According to yet another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding ones, an update is performed on a portion of the received first-type description files. Due to the update of a portion of the first-type description files, the second-type description file is incomplete and therefore smaller than a conventional second-type description file; this method thus reduces the CPU processing load in the reading device, which reads the second-type description file more quickly.

[0027] According to yet another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding ones, the second-type description file describes a constant number of segments over a given time range; and an update of a given number of segment descriptions via a first-type description file results in the deletion of the same number of segment descriptions from among the first segments of the time range. The management entity thus manages the size of the second-type description file locally so that it remains constant.

[0028] According to yet another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding ones, several second-type description files are received successively at regular intervals; in this configuration, receiving a second-type description file results in the deletion of the description file of the current second type. Thanks to this method, the reading device does not store outdated second-type description files that would clutter the available memory space on this device.

[0029] According to yet another particular embodiment of the invention, which may be implemented alternatively or cumulatively with the preceding ones, the second type of received description file describes a number of segments over a given time range, and in that the time range increases over time. Thanks to this method, the time range associated with the segments accessible in replay mode increases and allows a user to replay a segment over a longer time range than when the time range is constant, for example, four hours.

[0030] According to a first material aspect, the invention relates to an entity for managing access to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being downloaded via a communication link and read by a segment reading device, reading requiring the reception, from a communication network, of description files of a first type, a command interface being accessible during reading, the execution of a command from the interface requiring the reception of a description file of a second type, characterized as comprising a processor configured to perform the following steps:

[0031] receive, following a request for access to content, both a second type description file and successive first type description files;

[0032] complete the second type description file received by at least part of the first type description files received successively.

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

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

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

[0036] 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 downloaded via a communication link and read by a segment reading device, the reading requiring a reception, from a communication network, of description files of a first type or of a second type, characterized in that it comprises a transmission, following a request for access to content, of a description file of the second type and the description files of the first type successively.

[0037] We will see later that a second type description file can be transmitted alone or simultaneously with a first type description file.

[0038] According to a particular embodiment of the second entity, the second type description file is transmitted after a given duration.

[0039] According to a particular embodiment of the second entity, which may be implemented alternatively or cumulatively with the previous one, the second type description file is transmitted after a given number of transmissions of first type description files.

[0040] The two preceding modes cover the fact that the description file of The second type of description file is not necessarily the first one transmitted after receiving the request to access the content being streamed; on the contrary, the second type of description file is transmitted later, either after a specified duration or after a specified number of first-type description files have been transmitted. Both methods assume that a user accessing the content does not generally require a review within the first few minutes. The specified duration or number of files mentioned above will be carefully chosen to account for the time a user takes before reviewing the content.

[0041] According to another material aspect, the invention relates to a management entity, called the second entity, for the transmission of description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being downloaded via a communication link and read by a segment reading device, the reading requiring the transmission, via a communication network, of description files of a first type or a second type, characterized in that it comprises a processor configured to perform the following steps:

[0042] receive a request to access content,

[0043] following the receipt of a command to access content, to transmit both a second type description file and first type description files successively.

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

[0045] According to another material aspect, the invention relates to a computer program suitable for implementation 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 process defined in connection with the second functional aspect.

[0046] Finally, according to another material aspect, the invention relates to a data carrier on which at least one series of program code instructions for the execution of a method for managing the transmission of description files has been stored.

[0047] 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 medium information 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 process in question.

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

[0049] [Fig. 1] 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;

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

[0051] [Fig.3] schematically illustrates the material structure of a reading device capable of reading real-time multimedia streams;

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

[0053] [Fig. 5] illustrates one embodiment of the process of the invention; this figure illustrates The communication between the reading device and the content server, and the type of description files transmitted, depend on the timing. In this mode, the second type of description file is transmitted first following a request to access content; the first type files are transmitted afterward.

[0054] [Fig.6] illustrates another embodiment that can be implemented alternatively either tively or cumulatively with the previous one; in this mode, the second type description file is transmitted after the transmission of a number of first type files.

[0055] [Fig.7] illustrates another mode in which the second type description file is transmitted several times, for example regularly; each transmission being followed by a transmission of first-type description files.

[0056] Detailed description of embodiments of the invention

[0057] Fig. 1 represents a computer system SYS in which a content distribution network called a CDN (Content Distribution Network) is implemented, from which content is transmitted to client devices or content playback devices and description files associated with multimedia content.

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

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

[0060] 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. The content in question is broadcast in mode multicast.

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

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

[0063] In our example, the STB reading device is located in a local area network (LAN) managed by a GTW home gateway. The LAN context is given as an example and could easily be transposed to a "best effort" type Internet network, a corporate network, etc. It will be seen later that the STB reading device includes a first management entity ENT1.

[0064] The GTW gateway is capable of communicating via a LU telecommunications network such as a WAN known to a person skilled in the art.

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

[0066] The CDN network consists of networked servers in 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 shown in [Fig. 1] to represent the CDN. In our example, the SRV content server is located in the wide area network (WAN).

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

[0068] 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 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 by means of an exchange protocol between the playback terminal and the multimedia content provider server. The primary protocol targeted 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 detail about this download method as it is irrelevant to the presentation of the invention.

[0069] An example of a description file or "manifest" (MPD) conforming to the MPEG-DASH standard and containing the description of content available in three different qualities (NI = 512 kb / s, N2 = 1024 kb / s, N3 = 2048 kb / s) of fragmented content is presented in Annex 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.

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

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

[0072] - etc.

[0073] In [Fig. 2], the SRV server is also equipped with at least one CPU2 processor and MEM2 memory for performing computer processing. The server is also equipped with a management entity ENT2, referred to as 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, in this case, to the STB reading device. The SRV server communicates with the GTW gateway via a WAN. The server includes, for communication with the WAN, a communication module referenced COM2 in [Fig. 3]. In the following discussion, we will focus primarily on the transmission of the description file rather than the transmission of the segments.

[0074] Figure 3 represents the 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.

[0075] The STB reading 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.

[0076] 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. The module in question is referenced as CMO11 in [Fig.2].

[0077] The STB playback device includes a streaming-mode download module HAS (not shown) capable of managing the downloading of content segments. The STB playback device also includes a management entity ENT1, referred to as the second management entity in the suite, capable of reading a description file specifically constructed during catch-up playback as explained below. The download module HAS and the first entity ENT1 may form a single entity, in which case the HAS module is integrated into the first entity ENT1, or they may be separate.

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

[0079] The HAS download module, referred to below as the classic download mode, 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. The method by which the HAS download module selects the encoding bitrate of the next video segment to be downloaded is not described in detail here. It should be noted that, most often, the general principle of such algorithms is based on downloading a first 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, depending on 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 bitrates of successive segments.

[0080] In the typical case, if a video segment lasts three seconds, the retrieval 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. Therefore, the HAS download module must strike the best compromise between the highest possible playback quality, and thus the highest possible encoding bitrate, and the segment download time, which must be sufficiently short to allow continuous playback on the TV.

[0081] Initially, 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 associated video qualities Nj. In the example of [Fig.4], the content Cl is offered, for example, as segments of duration 3s, with a first encoding bitrate NI = 400 kb / s, a second encoding bitrate N2 = 800 kb / s, a third encoding bitrate N3 = 1200 kb / s, etc.

[0082] In a normal operating mode, not illustrated in [Fig.4], the HAS module operates the download, for example, of successive segments C1@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.

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

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

[0085] It sometimes happens that you miss the beginning of a television program (movie, series, etc.). A function called "play from the beginning" or "catch-up" (also called "Start Over" or "Restart" by those skilled in the art) allows you to resume the program currently being broadcast at any time from a point earlier than the current time; for example, playback can be restarted from the beginning. For example, 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, the viewing mode switches from real-time content to delayed viewing.

[0086] When this user accesses a live stream broadcast in real time (live content) using HTTP Adaptive Streaming (HAS), the STB playback device, meaning the HAS entity installed on this device, generally retrieves a description file every 2 seconds, hereinafter referred to as the first-type description file, which typically describes the last sixty seconds of the stream (30 two-second segments). It is then possible to decide to store a certain portion of the stream in memory (buffer) (up to a maximum of 60 seconds); the video segments are short because the aim is to be as close as possible to the actual live stream, i.e., the filmed event, for example, a football match. It is also for this reason that the description file is retrieved every two seconds and that the buffer depth is generally limited to around fifteen seconds in order to avoid excessive lag between the Football match and its replay on a screen.

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

[0088] In order to ensure the execution of a command from the command interface, for example the "go back" command, the retrieved description file no longer describes the last sixty seconds but a time window much larger than sixty seconds. This time window could cover the last four hours; in this case, the content can be read from any point within the time window.

[0089] This description file, called the second type description file, describing the last four hours, is transmitted periodically (usually every two seconds) regardless of whether the catch-up mode is used or not.

[0090] A first type description file will be referenced MNFc (the index "c" designating a "short" description file) and a second type description file will be referenced MNF1 (the index "1" designating a "long" description file).

[0091] It is therefore understood here that the size of the description file of the second type is greater than the size of the description file of the first type.

[0092] According to the invention, when access to the content is requested, the server transmits in return a second type description file MNF1 and first type files MNFc; the first entity ENT1, after receiving the second type description file MNF1, is responsible for updating the received second type description file with all or part of the first type description files received successively.

[0093] In Figures 5 to 7 described below, in order to distinguish between first and second type description files, the stream carrying second type description files will be represented with an arrow with a greater thickness than the streams carrying first type MNFc description files.

[0094] Figure 5 illustrates an embodiment of the method of the invention. Figure 5 shows two vertical axes corresponding respectively to two entities: the first entity, ENT1, present on the STB reading device, and the second entity, ENT2, present on the SRV server. Figure 5 illustrates the data exchanges that take place between the STB reading device and the SRV content server.

[0095] To the right of the two axes, a frame is shown to indicate which commands are available via an INT command interface throughout the reading process. These include commands such as - a return command " " - a Pause command "II" - a fast forward command « » « (this command cannot be used while playback is already delayed)

[0096] Note that in this [Fig. 5] only some of the messages useful for understanding the invention are illustrated. For example, after receiving a description file, the STB reading device generally requires access to the segments described in that received description file; we have chosen not to show these access messages as they are not relevant to the disclosure of the invention.

[0097] Executing the commands given as examples above results in a delayed playback of the currently being broadcast live content. 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 being played.

[0098] Commands whose execution results in delayed reading of content require a description of segments that have been broadcast in the past; a first-type file that only describes the most recently produced segments related to real-time broadcasting is therefore insufficient. The first entity ENT1 will thus be responsible for retrieving at least one second-type description file, MNF11, in order to execute a command correctly.

[0099] The steps of an embodiment are as follows; it is assumed here that the command interface includes at least one command resulting in a deferred reading and therefore requiring description files of the second type; it is also assumed that the user accesses a "Live" channel at 10 AM and that the program in question started at 9 AM, therefore one hour ago.

[0100] In a first step, the first entity ENT1 requires ACC access to multimedia content.

[0101] In a second step, the SRV server and therefore the second entity ENT2 receives the request.

[0102] In a third step, according to one embodiment, the second entity ENT2 systematically requires the initial transmission of a first description file of the second type MNF11 describing both the segments relating to the Live and the segments that have been broadcast since the start of the program four hours ago.

[0103] During this step, in our example, the SRV server can also transmit, independently of the second type description file, a first type description file describing the segments relating to the Live.

[0104] If received files of a first type and a second type are received and describe the same segments, the segments concerned are preferably read from the base of the received first type description file, in order to save time.

[0105] Suppose that only the second type description file MNF11 is transmitted initially, this file including the description of the segments produced on the server linked to the content being broadcast in real time; In this case, the first segments are read using this second type description file MNF11.

[0106] The second entity ENT2 then successively transmits first-type description files MNFc2, MNFc3, ..., MNFci (the index "i" designating the i-th description file). The STB reading device receives these first-type description files MNFc2, MNFc3, ..., MNFci and reads them one after the other to access the segments.

[0107] In our example, following each receipt of a first-type description file, the second-type description file MNF11 is updated to include the received segment addresses.

[0108] It is understood that at this stage, due to the updating of the second type description file over time, a request to execute a stream replay command can be carried out successfully thanks to this updated second type description file.

[0109] According to one embodiment, the second type description file MNF11 describes a constant number of segments over a given time range, for example a number of segments whose reading covers four hours of broadcast; in this configuration, an update of a given number of segment descriptions via a first type description file results in the deletion of the same number of segment descriptions from among the first segments of the time range.

[0110] According to another possible variant of this mode, the second-type description file MNF11 can also be updated without size limit. In this configuration, the time window for accessing past segments increases over time; initially four hours in our example, this duration increases.

[0111] With reference to this other variant, it will nevertheless be possible to set a maximum size so as not to overload the servers storing the contents.

[0112] In our example, the description files of the first type, MNFc, are transmitted at regular intervals (for example, every 2 seconds). Note that in our example, the different files are obviously different because they describe different segments.

[0113] Note that the regularity of sending the description file is not essential; other ways of transmitting the file may be considered.

[0114] As seen previously, the first MNF11 second-type description file is supplemented by the IP addresses of the segments described in the successively received first-type description files. The first second-type description file supplemented by the MNFci description file becomes MNF12; The The first description file of the second type MNF12, supplemented by the description file MNFc2, becomes MNF13, and so on.

[0115] With reference to [Fig.5], it is assumed that at a time T1, a user selects the "back" command on his remote control.

[0116] The STB decoder receives the command ". The first entity ENT1 receives the command and requests its execution by the processor. The HAS download module can then access the requested segments.

[0117] [Fig.6] illustrates another embodiment which can be carried out in association or in combination with the embodiment described in connection with [Fig.5].

[0118] In this [Fig. 6], the same two vertical axes described with reference to [Fig. 5] are shown, corresponding respectively to two entities: the first entity, ENT1, present on the STB reading device, and the second entity, ENT2, present on the SRV server. [Fig. 6] also illustrates the data exchanges that take place between the STB reading device and the SRV content server. To the right of the two axes, a frame is shown to indicate which commands are available via an INT command interface throughout the reading process. These include commands such as

[0119] - a return command « « »

[0120] - a Pause command "II"

[0121] - a fast-forward command « » « (this command cannot be used then (that the reading is already delayed)

[0122] In this mode, unlike the mode described in [Fig.5], the second type description file initially received is received later, for example after a given time following the ACC access request or after a transmission of a given number of first type files.

[0123] In this mode, the SRV server delays the transmission of the second-type description file either after a specified duration or after a specified number of first-type description files have been transmitted. Both modes assume that a user accessing the content does not generally require a review within the first few minutes. The specified duration or number of files mentioned above will be judiciously chosen to account for the time a user takes before reviewing content.

[0124] In our example, with reference to [Fig. 5], the second type file MNF11 is transmitted after the third first type description file MNFc3. In our example, this second type file is transmitted at the same time as the fourth first type file MNFc4; however, these two files could also have been transmitted one after the other.

[0125] Upon receipt, the first entity ENT1 stores the description file of the second type MNF11 in anticipation of a possible request to execute a command to reread the content from a previous time. The first entity ENT1 also continues reading the segments at the base of the first received file of type MNFc4, and so on.

[0126] Figure 7 illustrates another embodiment which can be carried out in association or in combination with the embodiments described above in connection with Figures 5 and 6.

[0127] In this mode, several second-type description files MNFll / ...MNFi / MNFj / ... (where i and j are integers and j > i) are received successively at regular intervals. Transmissions of first-type description files are interspersed between the second-type description file transmissions.

[0128] In addition, in this mode, receiving a second type description file MNFlj results in the deletion of the second current description file MNFlj used by the first entity ENT1; following the deletion, the last second type file received MNFlj is updated by the various first type description files MNFci (i=1,2,4, etc.) received subsequently and is used for a possible rereading of the content.

[0129] As seen previously, a description file of a second type MNFli is updated by description files of a first type MNFci (i=l,2,4, etc.) received subsequently in succession.

[0130] Finally, let us also clarify here that the term "entity" 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 a set of functions as described for the modules concerned. Similarly, 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; free from msmfest file <MR3 ?ww.vÿ3 XMLSctwjaJMîamse* xmsW^:QA$H;$dwîsa WD &0U" «cscnsmæLücafcùe-'DASH sc-e^a,MPO:20' ; OASH WD^W lypes'eynamîc" æw«\w e3^:pjî> hîe swriiw20 i ; "> «^pewttw ^te'csKier&te&vr^ wmeTypstev^^ w$h ■ * * 024 " Wgte.. -7^ s*3« w SAM * Wte^îte h :. W&* > <SteS <teal>HTrP:.the^^^ s.# GcnAW € î e & î »5 ■> «Segment &s§e> < It is wsw> souKieUM =«”£ LJ Sw;„§ 1 £ WQ J> i 3#tjW! <;See liar-' ^&K,WS^US$ PiOfcS W 50' > <â«^waURL msteieW * JL Sites. J wsteaa 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^^ fan” * and tel »« dsate Wtete Ote «S^w^niWLmsdte^^^^b J^07»,v, ^teteo^tel :te> ^s- O â Afteteteste - > Wte^ee;Seae> < seoteeU^l-” ïfi^t8«se> «sS^weatuf^LQ^t^jLmpA^ cSegments ;$?> the" CorawC2 4 testOteOte "> 'Stexss're'tete^î. -' 'tereWete x xiïWMateCOSsSteJOWCOJ^i^ < / Segment'*' - ck *the îwO'tete ee\ '^i « <'^dWt^L10243⁄4j ^ptete., < * ■ Can»w LS à ^tetetetete «■> <SegrnsBî&.ïse> tetetietetee < / Segmenter» <Segree tel s$| pymte tetei Ote ^Segf^euRL .J te$4^> < ■ > <.$egsYifentl:sr> x^temetetete «WD>< / teal>

Claims

Claims

1. Method for managing access to description files (MNFc, MNFl) associated with content broadcast in real time, the description files comprising access addresses to segments capable of being downloaded via a communication link (LU) and of being read by a segment reading device (STB), the reading requiring reception, from a communication network, of description files of a first type (MNFc), a command interface being accessible during the reading, the execution of a command of the interface requiring reception of a description file of a second type (MNF1), the method being characterized in that it comprises reception, following a request for access to content, of both a description file of the second type and successive description files of the first type;and in that the received second type description file is supplemented over time by at least part of the successively received first type description files.;

2. Management method according to claim 1, characterized in that if received files of a first type and a second type describe the same segments, the segments concerned are read from the base of the received first type description file.

3. Management method according to claim 1, characterized in that several second-type description files are received successively at regular intervals and in that reception of a second-type description file results in deletion of the current second-type description file.

4. Management method according to claim 1, characterized in that an update is carried out on the basis of all the first type description files received.

5. Management method according to claim 1, characterized in that an update is carried out on the basis of a part of the first type description files received.

6. Management method according to claim 1, characterized in that the second type description file describes a constant number of segments over a given time range, and in that an update of a given number of segment descriptions via a first type description file results in a deletion in the second type description file of the same number of segment descriptions. segments among the first segments of the time range.

7. Management method according to claim 1, characterized in that the received second type description file describes a number of segments over a given time range, and in that the time range increases over time.

8. Management entity (ENT1) for access to description files (MNFc, MNFl) associated with content broadcast in real time, the description files comprising access addresses to segments capable of being downloaded via a communication link and of being read by a segment reading device (STB), the reading requiring reception, from a communication network, of description files of a first type (MNFc), a command interface being accessible during the reading, the execution of a command from the interface requiring reception of a description file of a second type (MNF1), characterized in that it comprises a processor configured to carry out the following steps: a. receiving, following a request for access to content, both a description file of the second type (MNG1) and successive description files of the first type (MNFcl, MNFc2, etc.); b.supplement the second type description file (MNF1) received with at least part of the first type description files (MNFc) received successively.

9. Reading device (STB) comprising a management entity (ENT1) as defined in claim 8.

10. 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 i

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

12. 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 downloaded via a communication link and to be read by a segment reading device, the reading requiring reception, from a communication network, of description files of a first type or of a second type, the method being characterized in that it comprises a transmission, following a request for access to content, of a description file of the second type and the description files of the first type successively.

13. Method for managing the transmission of description files according to claim 12, characterized in that the description file of the second type is transmitted after a given duration.

14. Method for managing the transmission of description files according to claim 12, characterized in that the description file of the second type is transmitted after a given number of transmissions of description files of the first type.

15. 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 downloaded via a communication link and of being read by a segment reading device, the reading requiring transmission, via a communication network, of description files of a first type or of a second type, characterized in that it comprises a processor configured to carry out the following steps a. receiving a request for access to content, b. following the reception of a command for access to content, transmitting a description file of the second type and description files of the first type successively.

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

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

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

Images