FR3124344A1 - Method for managing access to content downloaded in adaptive download mode. - Google Patents

Abstract

Method for managing access to content being downloaded in adaptive download mode. The invention relates to a method for managing access to content (C1) by a multimedia stream playback terminal (DEC), the content being received in the form of video segments available according to several possible formats defined in a file file (MF1), the description file (MF1) of the content (C1) being renewable upon request sent from the reading terminal (DEC), characterized in that the transmission of the renewal request is triggered upon receipt of event data included in the content (C1) being downloaded and in that, following receipt of the renewed description file MF1(MF2), the method comprises a step of accessing the segments defined in the description renewed. Figure 4.

Description

Method for managing access to content downloaded in adaptive download mode.

The invention relates to the fields of telecommunications.

The subject of the method is a method for managing access to content downloaded in adaptive download mode. The invention is particularly aimed at managing access to secondary content during the reading of a main content by a reading terminal, the first content and the second content being downloaded in adaptive download mode.

A main or secondary content here refers to all multimedia content capable of being transmitted in adaptive download mode; such content is for example so-called real-time (or in English “live”) content, video on demand VOD, TVOD, etc.

The reading terminal targets any terminal capable of receiving content downloaded in adaptive download mode. Such a terminal is for example a digital television decoder. Such a terminal can integrate a screen or be connected to a restitution terminal such as a television for the restitution of the content.

Prior art

Access to multimedia content, such as “live” content or video on demand, is possible today for most playback terminals. The reading terminal generally sends a request to a server, indicating the chosen content and receives in return a flow of digital data relating to this content. The received content is then rendered.

The distribution of digital content is often based on client-server protocols of the HTTP (Hyper Text Transport Protocol) family. In particular, the downloading in progressive mode of digital content, also called streaming, makes it possible to transport and restore the data in real time, that is to say that the digital data is transmitted on the network and restored by the terminal as and as they arrive. The reading terminal receives and stores part of the digital data in a buffer memory before restoring it. This distribution mode is particularly useful when the bit rate available to the user is not guaranteed for the real-time transfer of the video, depending for example on the fluctuation of the available bandwidth. Indeed, such a fluctuation can induce a variation in latency over time, called jitter, or in English “jitter”.

It is recalled that latency is defined, in a data transmission network, as the time required for a data packet to pass from the source to the destination through the network, i.e. the data transmission delay. In order to compensate for the harmful effects of jitter for the user, it is known to place a buffer memory in the terminal for restoring the data streams received, in which a certain number of packets are stored. of data, before the start of their return to the user. This jitter buffer therefore induces a detectable delay at the start of the restitution of the stream.

Adaptive progressive downloading, in English HTTP Adaptive Streaming, abbreviated HAS, also makes it possible to broadcast and receive data according to different qualities corresponding for example to different encoding bit rates. These different qualities are described in a parameter file available for download on a data server. When the reading terminal wishes to access a content, this description file makes it possible to select the correct format for the content to be consumed according to the available bandwidth or the storage and decoding capacities of the client terminal. This type of technique makes it possible in particular to take into account variations in bandwidth on the link between the client terminal and the content server.

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 of the ISO/ IEC. These methods propose to send to the playback terminal one or more intermediate description files, also called documents or manifests, containing the addresses of the different segments with different qualities of the multimedia content.

Thus, the MPEG-DASH standard (for English “Dynamic Adaptive Streaming over HTTP”, in French “Dynamic adaptive streaming over HTTP”) is an audiovisual format standard for broadcasting on the Internet. It is based on the preparation of the content in different presentations of variable quality and speed, cut into short segments (of the order of a few seconds), also called “chunks”. Each of these segments is made available individually by means of an exchange protocol. The protocol mainly targeted is the HTTP protocol, but other protocols (eg FTP) can also be used. Segment organization and associated settings are published in a manifest in XML format.

There are several transport modes implementing the MPEG-DASH standard. Among these modes of transport, there is the mode of transport known under the name of CMAF-LL (Anglo-Saxon acronym for “Common Media Application Format – Low Latency”). In this CMAF-LL mode, media segments are divided into sub-segments. This mode is mainly used to reduce the time between preparing the content and displaying it on a rendering terminal. By dividing the segments into sub-segments, the reading terminal can ask the content (or broadcasting) server to transmit the sub-segments and display them on the rendering terminal without waiting for the entire segment to be completely available. This technique allows a significant reduction in the time between the preparation of the content and the display of it.

In addition, a current need is to personalize the content transmitted to the terminal. Content personalization is of particular interest in the field of advertising. For example, when the restitution terminal is mobile, there may be an interest in locating the terminal and transmitting an advertisement depending on the place where the terminal is located.

The personalization of the content can be carried out by dedicated equipment since the playback terminal is capable of regularly updating the video content description file. However, these successive updates of the description file can cause problems, in particular when the mode of transport is for example of the Low latency type (e.g. CMAF-LL), and when low latency is required. Indeed, the regular updates of the description file encroach on the bandwidth available on the network for the reception of the video segments. In addition, this increases the processing to be done by the reading terminal; these are delay generators. In this Low latency transport mode, the description file of a television program, in mode called DASH 'segmentNumber', is requested only once; in this configuration, throughout the reading of the content, the reading terminal bases itself on this description file to determine, autonomously, the next segments to be retrieved.

With CMAF-LL mode and description files in DASH 'segmentNumber' mode, playback customization is no longer possible during TV program playback because no description file is updated after sending the initial description file. However, it is desirable in certain cases to update the description file of the television program in order to be able to access personalized content when playing the television program, for example according to a user profile or the location of the terminal. of reading if the latter is mobile.

The invention improves the situation.

To this end, the invention relates to a method for managing access to content by a multimedia stream playback terminal, the content being received in the form of video segments available according to several possible formats defined in a description file , the content description file being renewable upon request sent from the reading terminal, characterized in that the transmission of the renewal request is triggered upon receipt of event data included in the content being downloaded and in that, following receipt of the renewed description file, the method comprises a step of accessing the segments defined in the renewed description file.

According to the invention, a request for renewal of the description file is only sent following the reception of characteristic event data received in connection with the content being played back. The description file renewal request is thus made at the appropriate time, that is to say, for example, when a characteristic event appears in the stream received, such as an event indicating that a sequence of one or more advertisements will take place. The renewal request is thus followed by receipt of a new description file allowing access to content other than the downloaded content, for example personalized content such as personalized advertising.

The proposed solution allows the reading terminal to delegate the personalization of a content, for example a LIVE content, outside the terminal while taking advantage of a mode of transport such as the CMAF-LL mode introduced above requiring the least possible description file renewal requests.

It should be specified here that event data, also called marker by those skilled in the art, refers to data that delimits temporal anchor points in a program. In addition to indicating the availability of content such as advertising content, markers can delimit content sequences (video sequence, advertising tunnel, advertising spots for example) by indicating a beginning of sequence or an end of sequence.

A description file includes access addresses to content segments.

According to a first embodiment, access addresses included in the renewed description file received relate to content other than the downloaded content. The reading of the downloaded content, called main content, is followed by a download of secondary content. This first mode makes it possible to receive secondary content distinct from the main content without requiring successive and periodic requests for manifest updates as in the prior art. Only a renewal request is necessary to access a new manifest and therefore to other content.

According to a second particular mode of implementation of the invention, which may be implemented alternatively or cumulatively with the previous mode, the event data is data representing a possibility of access to said other content. The event datum is chosen judiciously from among those having a link with a future rendering of content other than the content being downloaded, such as for example an event datum indicating that a sequence of one or more advertisements is going or can start.

According to a third particular mode of implementation of the invention, which may be implemented alternatively or cumulatively with the previous modes, said other content is personalized content based on a profile associated with the terminal. In this third mode, access addresses included in the renewed description file relate to personalized content that may be a function of a profile associated with the terminal. The invention thus facilitates access to personalized content without requiring regular access to manifest update requests which would be harmful in terms of available bandwidth on the network and in terms of computer processing carried out by the reading terminal.

According to a fourth particular mode of implementation of the invention, which can be implemented alternatively or cumulatively with the previous modes, the profile associated with the terminal takes into account a characteristic datum associated with the terminal.

A characteristic datum can be one of the following data:

- A location of the terminal;

- Data linked to a search history made by a user of the reading terminal; we are based here on the assumption that the search history can show an interest of a user for a particular field (viticulture, etc.)

• or any other characteristic data of the terminal (e.g.: small TV consumer, number of people in the household, etc.)

Note that profile data as event data is only one embodiment. The choice of personalized content can be decided by the server sending the content, taking into account considerations other than data related to the reading terminal. For example, a television channel may have, when receiving a request for renewal of the description file, to run a certain number of advertisements.

According to a hardware aspect, the invention relates to a management entity for managing access to content by a multimedia stream playback terminal, the content being received in the form of video segments available according to several possible formats defined in a description file, the content description file being renewable on request sent from the reading terminal, characterized in that it comprises, characterized in that it comprises

has. A transmission module capable of triggering the transmission of the renewal request upon receipt of event data included in the content being downloaded;

b. An access module capable of accessing, following receipt of the renewed description file, the segments defined in the renewed description file.

According to another material aspect, the invention relates to a terminal characterized in that it comprises a management entity as defined above.

According to another material aspect, the invention relates to a computer program capable of being implemented in a management entity as defined above, said program comprising code instructions which, when the program is executed, performs the steps defined in the method defined above.

According to another material aspect, the invention relates to a recording medium readable by a data processor on which is recorded a program comprising program code instructions for the execution of the steps of the method defined above.

Details here that the data carrier can 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 even a magnetic recording means, or a hard disk. On the other hand, the information medium can be a transmissible medium such as an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention can in particular be downloaded from an Internet-type network. Alternatively, the information carrier 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.

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

represents a computer system on which an embodiment of the method of the invention is illustrated.

is a schematic view of the circuits present in the reader terminal.

is a schematic view of the segments that make up the main content.

is a schematic view of the message exchanges according to one embodiment of the method of the invention.

Detailed description of an embodiment illustrating the invention:

We now present, in relation to the , a progressive download architecture based on the use of HAS adaptive streaming according to one embodiment of the invention. It should be specified here again that the invention is not limited to the HAS technology but extends to all other data downloading technologies.

The computer system SYS includes a multimedia stream playback terminal DEC, for example a decoder connected to a TV playback terminal such as a playback device.

In our example, the reading terminal DEC can be connected to a port of the TV restitution device or integrated into the reading terminal. In our example, for illustration purposes, we have chosen a system in which the decoder reading terminal DEC is connected via a port to the TV rendering device.

In our example, the reading terminal DEC is located in a local area network LAN controlled 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" Internet network, a corporate network, etc.

The GTW gateway is able to communicate via a telecommunications network such as a wide area network WAN known to those skilled in the art.

One or more digital content servers SRV is located according to this example in the wide area network WAN. The content server SRV receives, for example, digital television content channels from a broadcast television network (not shown), and/or videos on demand, and makes them available to client terminals, here the terminal of reading DEC.

It is common, in this client-server context, to use, to exchange data between the client terminal DEC and the content server SRV, an adaptive progressive downloading technique, in English "adaptive streaming", abbreviated as HAS based on the HTTP protocol. This type of technique makes it possible in particular to offer a good quality of content to the user by taking account of the variations in bandwidth which may occur on the link between the client terminal DEC and the service gateway GTW, and/or between this last and the content server SRV.

The transport mode is for example the CMAF_LL mode introduced above. In this mode, segments are cut into “sub-segments”. To simplify the exploded view, we will speak of segments instead of “sub-segments”.

The represents an architecture of a reading terminal DEC, for example a decoder.

The decoder DEC conventionally comprises memories MEM associated with a processor CPU. The memories can be ROM (Read Only Memory) or RAM (Random Access Memory) or Flash.

The decoder DEC includes a buffer memory also called cache memory or buffer by those skilled in the art.

The decoder DEC can transmit content to be restored to the TV restitution device via a communication module COM1. This module CO1 is for example an HDMI link.

The DEC decoder communicates with the GTW 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 mode in question is referenced CMO1 on the .

These communications are possible via a COM1 communication module and a COM2 communication module, respectively.

The DEC decoder includes an adaptive progressive downloading module HAS capable of requesting a progressive downloading of one of the contents at one of the qualities proposed in a description file. This description file can be downloaded and saved for example in the memories MEM of the decoder DEC or can be found externally.

The decoder DEC further comprises a management module MNG whose function will be explained below.

The DEC decoder can also contain other modules such as a hard disk (not shown) for storing video segments, a content access control module, a module for processing commands received from the smartphone, etc.

Classically, as will be seen with reference to the , different qualities can be encoded for the same content of a channel, corresponding for example to different encoding bitrates. More generally, we will speak of quality to refer to a certain resolution of the digital content (spatial, temporal resolution, level of quality associated with the video and/or audio compression) with a certain encoding bit rate. Each quality level is itself cut on the content server into time segments (or “segments” of content, in English “chunks”, these three words being used interchangeably throughout this document).

The description of these different qualities and the associated temporal segmentation, as well as the content segments, is accessible by the client terminal and made available to it via their Internet addresses. Internet addresses identify segments on a network. Such an address may be an identifier of the URI type (Anglo Saxon acronym for “Universal Resource Identifier”) known to those skilled in the art. All of these parameters (qualities, segment addresses, etc.) are generally grouped together in a parameter file, known as a description file or “MNF manifest”. It should be noted that this parameter file can be a computer file or a set of information descriptive of the content, accessible at a certain address.

In a context of progressive adaptive downloading, the DEC terminal can adapt its requests to receive and decode the content requested by the user at the quality that best suits him. For example, if we consider a content available at the following three qualities 416 kb/s (kilobits per second), 680 kb/s (N2), and 1200 kb/s (N3). Suppose also that the DEC reading terminal has a bandwidth of 5000 kb/s. in this configuration, the DEC reading terminal can request the content at any rate below this limit, for example 1200 kb/s.

In general, with reference to the , we note “Ci@Nj” the content number i with the quality Nj (for example the j-th level Nj of quality described in the description file).

The number of encoding bit rates available per segment varies according to the playback terminal used. On the , for example a main content C1 comprises five available encoding rates N1-N5.

In our example, the system further includes an ENC encoder and a GMF manifest generator. The role of the ENC encoder is to encode digital content in order to obtain several segments and several representations for each segment. In our example, the ENC encoder also adds EVT event data to segments.

The encoded content and EVT event data is passed to the GMF manifest generator which generates URIs for each segment created.

In the example shown, the encoder ENC and the manifest generator GMF form a content provider referenced FCNT.

Segments, event data and manifests are transmitted by the content provider FCNT to an EQ device. This EQ equipment is a server in our example.

Note that the EQ equipment and the SRV server could have formed a single server.

In our example, the reading terminal DEC is a client terminal and can as such enter into communication with the content server SRV to receive one or more contents (films, documentaries, advertising sequences, etc.). The DEC reading terminal can also communicate with the EQ equipment as will be explained below.

In our example, to view a content, the DEC terminal obtains an address of the MNF description file of a main content (for example, C1) desired. In the following, we will assume that this file is a manifest type file according to the MPEG-DASH standard and we will refer indifferently, depending on the context, to the expression “description file” or “manifest”.

Once the reading terminal DEC has the segment addresses corresponding to the desired content, the terminal DEC proceeds to obtain the segments by downloading to these addresses. It should be noted that this download takes place here, traditionally, through an HTTP URL, but could also take place through a universal address (URI) describing another protocol (dvb://monsegmentdecontent for example).

When the DEC decoder receives the segments, the segments are then reproduced on the screen of the TV restitution device.

In our example, because the transport mode used is CMAF-LL, the digital content targeted is Live content; however, the invention applies to other modes of transport and other types of content; the main content C1 may be a television program broadcast on a deferred basis, or a video on demand, or a personal video of the user, or any other equivalent multimedia content.

We will see below that the purpose of the invention is to insert a reading of a secondary content during the reading of a main content. Secondary content is of the same type as primary content in that it is formed from HAS segments.

In the embodiment described below, the main content is for example a television program, and the secondary content is for example advertising content. The goal in our example is to insert the advertising content when possible, when playing the main content C1. More specifically, the goal is to insert personalized C2 advertising content into the main C1 content. Personalized advertising content means advertising content adapted to the profile of the reading terminal.

The content server SRV stores the content C1 in the form of segments. More specifically, the HAS content server exposes a video C1 in the form of segments or “chunks” C1i@Nj encoded at different encoding bit rates Nj, where the index i designates a temporal identifier of the “chunk” C1i@Nj as explained above.

The HAS download module of the decoder DEC is responsible for recovering “chunks” from the HAS content server by choosing the video quality Nj as a function of the available network resource. We will not describe here in more detail the way in which the HAS download module chooses the encoding bit rate of the next video segment to be downloaded: there are indeed many algorithms allowing this choice to be made. However, it should be recalled that, most often, the general principle of such algorithms is based on the downloading of a first segment at the lowest encoding rate proposed in the manifest file, and on the evaluation of the recovery time of this first segment. Based on this, the HAS download module evaluates whether, depending on the size of the segment and the time taken to retrieve it, the network conditions allow the next segment to be downloaded at a higher encoding rate. Some algorithms rely on gradually increasing the quality level of downloaded content segments; others propose more risky approaches, with jumps in the levels of encoding bitrates of successive segments.

In the classic case, if a video "chunk" lasts "n" seconds, the recovery of the "chunk" by the HAS download module must not exceed "n seconds", in order to allow uninterrupted restitution of the content by the decoder DEC. It is therefore appropriate for the HAS download module to operate the best compromise between a restitution quality, and therefore an encoding bit rate, as high as possible, and the download time of the segment, which must be sufficiently low to allow a continuous playback on the TV playback device.

In the example shown, the transport mode used is the CMAF-LL mode in which the segments are divided into sub-segments. This mode allows you to download sub-segments even before having received the entire segment. This mode provides a significant end-to-end latency reduction.

As indicated above, for the purpose of simplifying the description of the invention, the term segment will be used to designate a “sub-segment”.

The HAS downloading module present on the reading terminal DEC controls the downloading of a segment at the optimal encoding bit rate as described in more detail below.

Firstly, the HAS module retrieves the manifest file MNF1 which corresponds to the video content C1 in order to discover the available segments of the video content C1, and the various associated video qualities Nj. In the example of the , the main content C1 is for example offered in the form of segments of duration 2s, with a first encoding rate N1 = 416 kb/s, a second encoding rate N2 = 680 kb/s, a third encoding rate N3 = 1200 kbps, etc.

In a normal operating mode, the HAS module performs the downloading, for example, of successive segments C11@N1 (i.e. the first time segment at an encoding rate of 416 kb/s), then C12@N2 (i.e. the second segment at an encoding rate of 680 kb/s), then C13@N3 (i.e. the third time segment at an encoding rate of 1200 kb/s), etc.

According to the invention, the instant of request for access to a new description file is triggered following the receipt of event data transmitted with segments of the content being downloaded.

In other words, upon receipt of specific event data, the MNG management module triggers the transmission of a request to renew the manifest of the content being downloaded.

In response to the renewal request, the DEC reader terminal receives either a personalized manifesto if there is one; otherwise, the reading terminal receives a renewed but not personalized manifest. Receiving a custom manifest then allows access to custom content.

A personalized manifest associated with the content being downloaded consists for example of including in this manifest URI addresses of a given content, called secondary content, such as an advertisement for example according to the profile associated with the restitution terminal.

It is clear that access to content and personalized content requires at best only an initial manifest and a renewal of manifest.

More generally, considering a C1 main content and several disjoint C2n secondary content to be inserted into the main content (n is an integer designating a particular secondary content), “n” manifest renewal requests will be made upon detection of event data respective. Note that disjoint content is content that is not read successively.

In what follows, a single personalized content C21 is considered; however, the invention applies in the same way to any number of personalized contents to be inserted into the main content.

It should be noted here that personalized content can include several “sub-contents”. The “sub-contents” are for example advertisements to be read successively.

The represents a sequence of steps illustrating a first embodiment of the method of the invention. This mode concerns the insertion of advertising content during the rendering of content.

For example, the user of the DEC terminal is considered to be a wine lover.

In the mode described below, the main content is a video and the secondary content to be inserted into the main content is an advertisement. According to a possible variant, the secondary content could also be several consecutive advertisements.

The embodiment comprises two phases PH1 and PH2.

During a first phase PH1, in our example, a so-called secondary content C2 is transmitted, by a content provider FCNT, to the content server SRV and stored on the content server in the form of segments C2i@Nj. This secondary content concerns, for example, an advertisement on a given theme, for example Bordeaux wines.

In our example, the manifest MF2 associated with the secondary content C2 is transmitted, by a content provider FCNT, to the equipment EQ and stored on the equipment.

At this stage, the manifest MF2 is known to the equipment EQ and the segments of the secondary content C2 are stored on the content server SRV.

During a second phase PH2, the content provider FCNT transmits a so-called “live” content C1 to the content server SRV, time data EVT associated with the content C1.

The content provider FCNT also transmits the manifest MF1 associated with the content C1 to the equipment EQ which stores the manifest MF1.

At this point, the two manifests MF1 and MF2 are created and stored on the EQ equipment. In the following, the goal for the EQ equipment is to include the data from the MF2 manifest in the M1 manifest. We will see that the insertion of the data from the manifest MF2 into the manifest MF1 is carried out according to the profile of the restitution terminal. This insertion step can be performed during the first phase PH1 or during the second phase PH2.

Suppose now that a user wants to access the main content C1.

The user selects the main content C1 via a graphical interface (not shown) displayed on the TV rendering device or via equipment associated with the playback terminal (eg: remote control).

Following the selection, the reading terminal DEC requires access to the main content C1. This main content is for example a television program transmitted in “live” mode. The access request REQ(C1) to the main content C1 is transmitted from the reading terminal DEC to the equipment EQ to obtain the manifest MF1 associated with the main content C1.

Following the request, in our example, the reading terminal DEC receives from the equipment EQ a manifesto MF1 linked to the main content C1. The reading terminal DEC can access the different segments of the main content C1 thanks to the addresses stored in the manifest MF1; the reading terminal DEC transmits for this purpose requests GET(C1i@Nj) successively to the content server SRV.

Following reception of the first segment C11@Nj, the reading device DEC accesses the various segments C1i@Nj by selecting respective image qualities Nj as a function of the current bandwidth available as explained above in connection with the mode adaptive download.

During the transmission of the various segments of the main content C1 which follows the reception of the access requests, the server SRV transmits to the reading terminal DEC event data EVT which accompanies all or part of the segments.

In our example, we will be interested in an event data item named “AdSrvCall”. The invention is not limited to this event data but extends to any other event data conducive to a renewal of manifesto and therefore to a possible personalization of the content to be restored.

It is assumed that at a given instant, during the downloading of the data segments, the reading terminal receives the “AdSerCall” event datum.

In our example, upon receipt of this AdServCall event data, the reading terminal DEC, implying the management module MNG present in the reading terminal, triggers the transmission of an R-MF1 renewal request of the manifest MF1 to EQ equipment. This access request is for an R-MF renewal of the MF1 manifesto. It should be noted here that the access request does not specify any particular content.

Upon receipt of the request for access to the manifest, more specifically to an update of the manifest associated with the main content, the equipment EQ checks whether a personalized secondary content is available for the reading terminal DEC. For example, the EQ equipment can have access to a correspondence table in which a user profile is stored for reading terminal identifiers or delegate this processing to another equipment (e.g. AdServer). A user profile provides information on user preferences, a family profile (age of family members). Thanks to this table, it suffices for the equipment EQ to recover an identifier of the reading terminal DEC and to check whether secondary content corresponds to this identifier and therefore to the user profile.

Continuing the example above, the EQ equipment checks whether secondary content, advertisements in our example, relates to the winery. If so, the equipment EQ transmits, in response to the manifest renewal request MF1, a new manifest MF1(MF2) including data extracted from the manifest MF2 associated with the secondary content C2 loaded during the first phase PH1, an advertisement in our example, in relation to wines. If not, the equipment sends the MF1 Manifest in response to the renewal request without modification.

Following receipt of the new manifest MF1 associated with the content C1, assuming that the new manifest has been personalized and that it therefore includes data relating to the second manifest MF2, the reading terminal DEC requires successive accesses to the various segments C2i@ Nj secondary content. Without the case where the renewed manifest does not include data related to the C2 secondary content, in this case it accesses non-personalized main content and downloads the segments in adaptive streaming mode as explained above.

Finally, let us point out here that, in this text, the term "module" or "entity" can correspond both to a software component and 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 (or hardware) assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).

Claims (9)

Method for managing access to content (C1) by a multimedia stream playback terminal (DEC), the content being received in the form of video segments available according to several possible formats defined in a description file (MF1), the description file (MF1) of the content (C1) being renewable on request transmitted from the reading terminal (DEC), characterized in that the transmission of the renewal request is triggered upon receipt of an event datum included in the content (C1) being downloaded and in that, following reception of the renewed description file MF1(MF2), the method comprises a step of accessing the segments defined in the renewed description file. Management method according to claim 1, characterized in that a description file includes access addresses to segments of a content, and in that access addresses included in the renewed description file received relate to content other than downloaded content. Management method according to Claim 2, characterized in that the event data is data representing a possibility of access to said other content. Management method according to Claim 2 or 3, characterized in that the said other content is personalized content according to a profile associated with the terminal. Management method according to Claim 4, characterized in that the profile associated with the terminal takes account of characteristic data associated with the terminal. Management entity (MNG) for managing access to content (C1) by a multimedia stream playback terminal (DEC), the content being received in the form of video segments available according to several possible formats defined in a description file (MF1), the description file (MF1) of the content (C1) being renewable upon request sent from the reading terminal (DEC), characterized in that it comprises

1. A transmission module capable of triggering the transmission of the renewal request upon receipt of event data included in the content being downloaded;
2. An access module capable of accessing, following receipt of the renewed description file, the segments defined in the renewed description file.

Terminal (DEC) characterized in that it comprises a management entity (MNG) as defined in claim 5. A computer program capable of being implemented in a management entity as defined in claim 6, said program comprising code instructions which, when the program is executed, performs the step defined in claim 1. Recording medium readable by a data processor on which is recorded a program comprising program code instructions for the execution of the steps of the method defined in one of claims 1 to 5.