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 real-time broadcast content. The invention relates to a method for managing access to description files associated with real-time broadcast content, the description files comprising access addresses to segments capable of being downloaded and read by a segment reader (STB), the reading requiring the reception, from a communication network, of description files of a first type (MNFc) or a second type (MNFl), a command interface (INT) being accessible during the reading, the execution of a command (<< >>) of the interface requiring the reception of a description file of the second type (MNFl), characterized in that it comprises an initial reading performed by means of description files of the first type (MNFc), and in that during the reading,A request to access the second type description file (MNFl) is transmitted if a command is selected; reading then continues using second type description files received from the network. See Figure 5 for the abbreviation.

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 particularly relates to segmented content, the segments being accessible according to several formats associated with respective sizes in bytes having more or less impact on the bandwidth of the network on which the content is downloaded. The invention particularly relates to content downloaded according to a technique called adaptive progressive downloading, or HAS, or any other downloading techniques using the same principle.

[0003] Clarification that the segment addresses are included in a description file. A description file in the context of an adaptive progressive download is a file including, among other things, IP addresses of the segments to be downloaded and read by a reading device.

[0004] The reading device targets all data processing devices equipped with processors and capable of receiving segments from a network, decoding the received segments and requesting restitution of the decoded segments. State of the art

[0005] When accessing multimedia content, a playback device sends a request to a content server indicating the multimedia content (video and / or audio) chosen. The playback device receives in return a digital data stream relating to this content. In the context of a local communication network, such a request may pass through a network access gateway, for example a residential gateway.

[0006] The received data is then decoded by the playback device and then rendered in the form of a display of the corresponding video with its associated soundtrack.

[0007] The distribution of digital content on the Internet is often based on client-server protocols of the HTTP family (from the English "Hyper Text Transport Protocol"). In particular, the progressive mode downloading of digital content, also called streaming, makes it possible to transport and read data in real time, that is to say that the digital data is transmitted over the network and restored by the reading device as it arrives. Following reception of the stream, the reading device stores received data in a buffer memory (buffer in English) before restoring it. This distribution method is particularly useful when the user's available bandwidth is not guaranteed for real-time video transfer.

[0008] Adaptive progressive downloading, in English HTTP Adaptive Streaming, abbreviated to HAS, also makes it possible to broadcast and receive data according to different qualities corresponding for example to different respective encoding rates. These different qualities are described in a description file, also called "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 at regular intervals, generally every two seconds, successive description files, hereinafter called description files of a first type, each of 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.

[0010] Note that the video segments are chosen to be 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 we limit the buffer depth generally to around fifteen seconds.

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

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

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

[0014] In order to replay the content, unlike the case referred to above in which only real-time reading is possible, when the catch-up mode is available, the The playback device receives, from the start of playback of the content, a specific description file, hereinafter called a second-type description file, which describes a large part of the segments that have already been broadcast. This second-type description file does not only describe the last sixty seconds but a larger time window of several hours, for example the last four hours so as to be able to replay the content from a time within the four-hour time window. Such a description file describing, for example, the last four hours is two hundred and forty (240) times larger than a conventional description file. Concretely, a first-type description file has a size of around 12 kB (description of 30 2-second segments) and a second-type description file has a size of around 2.8 MB (description of 7200 2-second segments).

[0015] Just like the first type description file, this second type description file is downloaded periodically, for example every two seconds.

[0016] Due to its enormous size, the periodic transmission of the second type description file requires enormous bandwidth on the network, especially for homes equipped with an internet line with low bandwidth such as an ADSL line; in addition, such description files require excessive processing times (parsing times) which can alter the normal reading of the content and cause image freezes which are unbearable for a user.

[0017] The invention improves the situation. The invention

[0018] For this purpose, 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 and 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, a command interface being accessible during the reading, the execution of a command from the interface requiring reception of a description file of the second type, characterized in that it comprises an initial reading carried out by means of description files of the first type, in that during the reading, a request for access to the description file of the second type is transmitted if a command is selected, the reading continuing by means of description files of the second type received from the network.

[0019] According to the invention, although the reading interface offers commands requiring a description file of the second type, reading begins with description files of the first type; it is only after selecting a description command the interface that the second type description file is transmitted and used for reading the segments by the reading device.

[0020] The invention delays the instant of transmission of this second type description file after selection or execution of a command; that is to say at a time when there is a desire to modify the reading of the stream in real time. In the best case, no command is selected for example because a user viewing the content has no intention of selection at all and therefore of executing a command from the interface; in this case the gain in bandwidth is maximum.

[0021] This results in a gain in bandwidth on the network which carries the description files and a gain in CPU processing until a command is selected due to the fact that the description file received until the command is selected is a file of the first type which is in our example smaller in byte size than the description file of the second type. Note that the invention could be applied to a file of the first type larger in size than a description file of the second type.

[0022] According to a first embodiment of the method, the reception of the second type files ceases after a given duration and is replaced by a reception of the first type description file. When it is found, following the execution of the command that no other command is selected for a given duration, the management entity again requests the reception of the first type description files. This mode makes it possible to reduce the CPU load as soon as possible without altering the user experience.

[0023] According to a second particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous one, the selection is followed by a transmission of a request for access to the description files of the second type and in that the selected command is executed after receiving a description file of the second type. This mode avoids executing a command while the description file of the second type allowing the execution of the command has not yet been received. According to a variant of this third mode, the selected command is executed after receiving the first description file of the second type.

[0024] According to yet a third particular embodiment of the invention, which may be implemented alternatively or cumulatively with the previous one, the command interface comprises commands, some of which result in a deferred reading of the content; in this configuration, the transmission of a request for access to the description file of the second type is carried out only for commands resulting in a deferred reading. This mode makes it possible to continue the transmission of the description files of the first type despite the selection of a command. This mode distinguishes between commands requiring a deferred reading or not.

[0025] According to a 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 and 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, a command interface being accessible during the reading, the execution of a command of the interface requiring reception of a description file of the second type, characterized in that it comprises a reading module capable of initially reading the content by means of description files of the first type, and capable of, during the reading, following a selection of a command, triggering a transmission of a request for access to the description file of the second type;playback continuing by means of description files of the second type received back from the network.;

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

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

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

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

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

[0031] [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;

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

[0033] [Fig.3] schematically illustrates the hardware structure of a reading device capable of reading multimedia streams in real time;

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

[0035] [Fig.5] illustrates an embodiment of the method of the invention; this figure illustrates the communication between the reading device and the content server and the type of description files transmitted as a function of time.

[0036] [Fig.6] illustrates a possible variant of the previous mode described with reference to [Fig.5].

[0037] Detailed description of embodiments of the invention

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

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

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

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

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

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

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

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

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

[0047] 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 [Fig.l] to represent the CDN. The SRV content server is located, in our example, in the wide area network WAN.

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

[0049] 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 the content in different representations of variable quality and bitrate, divided into short segments (of the order of a few seconds), also called “chunks” by those skilled in the art. Each of these segments is made available individually by means of an exchange protocol between the rendering terminal and the multimedia content provider server. The main targeted protocol is the HTTP protocol, but other protocols (for example FTP) can also be used.The organization of the segments and the associated parameters are published in a description file in XML format. We will not go into further details of this download method because it is of no interest for the presentation of the invention.

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

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

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

[0053] - etc.

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

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

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

[0057] The STB reading device communicates with the gateway via an Ethernet module for local wired communication or via a WiFi type radio module for local wireless communication with the GTW residential gateway. The module in question is referenced CM011 in [Fig.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 a playback in catch-up mode as explained below.

[0059] We now present, in relation to [Fig.4], a schematic view of a main content Cl divided 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 here- below, 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 download: there are in fact many algorithms for making this choice, whose strategies are more or less secure or aggressive. However, we recall 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. On this basis, the HAS download module evaluates whether, depending on the size of the segment and the time taken to retrieve it, the network conditions allow downloading the next segment at a higher encoding rate.Some algorithms rely on a gradual increase in the quality level of downloaded content segments; others propose riskier approaches, with jumps in the encoding bitrate levels of successive segments.

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

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

[0063] In a normal operating mode, not illustrated in [Fig.4], the HAS module performs the downloading, for example, of successive segments Cil@N1 (i.e. the first time segment at an encoding rate of 400 kb / s), then C12@N3 (i.e. the second time segment at an encoding rate of 1200 kb / s), then C13@N3 (i.e. the third time segment at an encoding rate of 1200 kb / s), etc.

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

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

[0066] It sometimes happens that we miss the start of a television program (film, series, etc.). A function called "play from start" or "catch-up" (also called "Start Over" or "Restart" by those skilled in the art) allows us 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 switch from a playback mode for real-time (or live) content to a delayed playback mode.

[0067] 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 sixty 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. It is also for this reason that we retrieve the description file every 2 seconds and that we limit the buffer depth generally around 15 seconds.

[0068] A command interface (“” II) allows you to act on the current reading of the content. Commands allow you to activate the catch-up mode (or start over).

[0069] In order to ensure execution of a command from the command interface, the description file that is retrieved no longer describes the last sixty seconds but a time window much longer than sixty seconds. The time window may concern the last four hours; in this case, if the content can be reread from a time located within the time window.

[0070] This description file describing the last four hours is transmitted periodically (generally every two seconds) regardless of whether catch-up mode is used or not.

[0071] In the following, the description files describing the last few seconds (for example 60 seconds) will be referred to as “first-type description files” and will be referenced MNFc and the description files describing a few hours (for example the last four hours) as “second-type description files” and will be referenced MNF1. It is understood here that the size of the second-type description file is larger than the size of the first-type description file.

[0072] According to the invention, the initial reading is carried out by default using description files of the first type MNFc. Then, during reading, the file type varies when a command is selected on the command interface; playback then continues using description files of the second type MNF1 received from the network.

[0073] [Fig.5] illustrates an embodiment of the method of the invention. In this [Fig.5], two vertical axes are represented corresponding respectively to two entities, namely the first entity ENT1 present on the STB playback device and the second entity ENT2 present on the SRV server. [Fig.5] illustrates the data exchanges which take place between the STB playback device and the content server. To the right of the two axes, a frame is represented to show which commands are available via an INT command interface throughout playback. There are commands such as - a rewind command " " " - a Pause command " II " - a fast forward command " " " (this command can be used while playback is already delayed).

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

[0075] Executing the commands given as examples above results in delayed playback of the content currently being broadcast. These commands therefore require a description of segments that are not included in the first-type files that concern the latest segments produced related to real-time broadcasting. The first entity ENT1 will therefore be responsible for retrieving second-type description files to be able to execute the commands correctly.

[0076] The steps of an embodiment may be as follows; it is assumed that the command interface comprises commands resulting in deferred reading and therefore requiring description files of the second type.

[0077] During a first step, the first entity ENT1 requires ACC access to content.

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

[0079] During a third step, the second entity ENT2 requires the transmission, in our example at regular intervals (for example every 2 seconds), of the description files of the first type MNFc (“c” designates the files of the first “short” type). The different files are obviously different because they describe different segments.

[0080] Please note that the regularity of sending the description file is not essential. Other ways of transmitting the file can be considered.

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

[0082] The STB decoder receives the command “. The first entity ENT1 receives the command.

[0083] At this stage, the STB reading device does not have the description file of the second type and therefore does not have the addresses of the requested segments linked to the time jumps resulting from the “rewind” command.

[0084] In our example, following the selection of the command, the first entity ENT1 transmits a request for access to the description files of the second type.

[0085] The SRV server receives the request and transmits description files of the second type MLF1 successively in place of the files of the first type MLFc.

[0086] The first entity ENT1 receives in return the description files of the second type MNF1 (1 designates the file type “1” for long).

[0087] Once the first description file of the second type MNF11 has been received, the processor of the STB reading device executes the backtracking command " " " and can access the requested segments by consulting the successively received files MNF11 / MNF12 / etc.

[0088] According to a variant, the first entity can execute the command not upon receipt of the first file but upon receipt of another description file.

[0089] The embodiment described above may be subject to variations.

[0090] According to another variant, with reference to [Fig.6], the execution time EX of the command is chosen judiciously. In our example, the first entity ENT1, after receiving the selection of the command ", delays the execution of the command for a delay period. This delay allows the first entity ENT1 to transmit a request for access to the second type description files MNF1, to receive the second type description files in question and to execute the return command to a segment located in the interval of four hours preceding the current reading time.

[0091] According to a variant of the mode described above, with reference to [Fig.6], the reception of files of the second type ceases after a given duration T, for example following selection or execution of the command, and is replaced by a new reception of description files of the first type.

[0092] The first entity ENT1 or the second entity ENT2 can be indifferently at the origin of the replacement command.

[0093] As described above, the duration T defined above can have as initial instant the execution EX of the command as shown in [Fig.6].

[0094] According to a sub-variant, receipt of a new command during the duration T resets a duration T.

[0095] 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.). APPENDIX 1: Exempt from manfet file <MPO ymîriS xsi^^^p / Awwf.^.Of^'SSÛ1 'XMLSca-èWW" winsteum snpsgDASH sshemsLMPD 201V xxi.fÆ^&e'ïaLsscâks^ s MPD:2Û11 QASH-^PtlxM' ^pe^d^s^te' p?«l§ôfe«^m:mpe§:desh ssîetetetetetee 2Ô1 1S ^RsjpmxeMailxs > <H"0'' rfiîrfs$’yp<^"vteecJm^ < Your sister > HYTF: / / servant»» / < / B-as^J SU. > <;■'— &rtw 0 ? and WATER <^gn«8^e> < -wurc^ML'»: ÏÜ SsecJ 12 WCXJ ^ / 5^^5.3⁄4^ x*Seg*W'to «Ma$i»»*1SS < Segfli e» s te RL «^gà«*C 1 KXP 1 .sï^M XM C : 5te?ke ? ^iptete „,. <S^mçn?UsL> <! ■ Cf < $?w 5sxHt2^L®XO5$^580ÈWClJt$2^fcfê^^ s SealUl SS and S^s^^UFA. * 1 „S t ».J ü^S…. xvSeqm^n^sî.'' < ■■- ■ Cs#«êw C? ^W04>faith ”> < Sï§ew4ga«ï> ^l^tiaUmxse <Sî.-Qf?ïeîXLe; «y «am»7 SS îRL st^XteWOJ^S., «* ■ CswM^s' C? â ÂR®§ïZ$:p '•■■> < I«Son s waRteL-"K C2U5^;„^X^WC2„5i2kWj^Sl.R^?47 > <S$§à'-eMbSi omwswi SS cS^ts^URL "-« .'.'Re^e' !SbsM C&n^wQ è^»RWL'ij- -> «SesmentBase» ^UR^IL«T2;..i5w,.5 <XSdWO...t824id^^ <Se$ment8èse> <$e^^^UAL wswX'CteJ§24tevL W^^^ te- Cmtene C£ à -e <S^mentSase> < teteteæMteu «? T2..4 Sssc^SGâk WC <fs»qrs«®ns.^ tesftetewwte' a'H ' temsdteteQI 2Sl^Sti...l.îW <rs..... tex ' ' test VP'

Claims

Claims

1. 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 and read by a segment reading device (STB), the reading requiring reception, from a communication network, of description files of a first type (MNFc) or of a second type (MNF1), a command interface (INT) being accessible during the reading, the execution of a command (" ") of the interface requiring reception of a description file of the second type (MNF1), characterized in that it comprises an initial reading carried out by means of description files of the first type (MNFc), and in that during the reading, a request for access to the description file of the second type (MNF1) is transmitted if a command is selected,playback continuing using description files of the second type received from the network.,

2. Management method according to claim 1, characterized in that the reception of the files of the second type (MNF1) ceases after a given duration (T) and is replaced by a reception of the description file of the first type (MNFc)

3. Management method according to claim 1 or 2, characterized in that the selection is followed by a transmission of a request for access to the description files of the second type and in that the selected command is executed after receipt of a description file of the second type.

4. Management method according to claim 3, characterized in that the selected command is executed after receiving the first description file of the second type received.

5. Management method according to claim 1 or 2, characterized in that the command interface comprises commands some of which result in deferred reading of the content and in that the transmission of a request for access to the description file of the second type is carried out only for commands resulting in deferred reading.

6. Management entity (ENT1) for access to description files associated with content broadcast in real time, the description files comprising access addresses to segments capable of being downloaded

7.

8.

9. and to be read by a segment reading device (STB), the reading requiring reception, from a communication network, of description files of a first type (MNFc) or of a second type (MNF1), a command interface (INT) being accessible during the reading, the execution of a command (" ") of the interface requiring reception of a description file of the second type (MNF1), characterized in that it comprises a reading module capable of initially reading the content by means of description files of the first type (MNFc), and capable of, during the reading, following selection of a command, triggering a transmission of a request for access to the description file of the second type; the reading continuing by means of description files of the second type (MNF1) received in return from the network. Reading device (STB) comprising a management entity (ENT1) as defined in claim 6. Computer program capable of being implemented on a management entity (ENT) as defined in claim 6, the program comprising code instructions which, when executed by a processor, performs the steps of the method defined in claim 1. Data carrier on which at least one series of program code instructions for executing a method according to claim 1 has been stored.

Images