EP3942838A1

EP3942838A1 - Method for managing the broadcasting of multimedia content, and device for carrying out said method

Info

Publication number: EP3942838A1
Application number: EP20728105.6A
Authority: EP
Inventors: Eric Toullec; Lucas Gregory; Jean LE FEUVRE
Original assignee: Ateme SA; Institut Mines Telecom IMT
Current assignee: Ateme SA; Institut Mines Telecom IMT
Priority date: 2019-03-18
Filing date: 2020-03-17
Publication date: 2022-01-26
Also published as: FR3094166B1; US20220191584A1; WO2020188219A1; FR3094166A1; US11831944B2

Abstract

Disclosed is a method for managing multimedia content, involving: obtaining a first set of content description metadata describing a first multimedia content broadcast in dynamic mode; and upon reading, in the first set of metadata, data redirecting to a section of a second set of content description metadata, reading, in the section of the second set of metadata, data relating to a time synchronization for accessing a second multimedia content broadcast in dynamic mode.

Description

Title of the invention: Multimedia content management method and device for implementing the method

Field and context of the invention

The present invention relates to the field of data distribution over a telecommunications network. In particular, it relates to the distribution of multimedia content (audio and / or video, subtitles, data, etc.), and in particular to the distribution in real time.

[0002] The world of distribution or distribution (in English, "broadcast") of digital television has undergone real changes in recent years. A traditional distribution carried out in dynamic mode via pay television operators (e.g. digital packages and / or Internet access providers (ISPs)) for so-called linear television (ADSL (standing for Asymmetric Digital Subscriber Line) , Satellite, Cable, IPTV, Fiber, Digital Terrestrial Television (TNT), etc.), new audiovisual services have been added such as video on demand (VOD, standing for “Video On Demand”), or Catch-Up TV (“Catch-Up TV” or “Replay”).

The design of new terminals increasingly powerful and more mobile, the growing demand for consumption of content independent of the location of the consumer (in English "TV everywhere"), as well as the development of network infrastructure offering ever more bandwidth, have led to the emergence of a new market that does not require owning the access network to users, and called over-the-air service (OTT, from English

“Over-The-Top”). The OTT market operates on so-called unmanaged networks (i.e. with uninsured bandwidth and quality of service (in English QoS, for "Quality of Service"). These multi-screen OTT services are provided by distribution / redistribution companies such as television content broadcasters and telecom operators.

[0004] The distribution infrastructures are thus now doubled, one for the

traditional broadcast and one (at least) for OTT distribution.

[0005] In order to address multi-screen content distribution services, various

protocols have been developed: Apple HLS (HTTP Live Streaming), Microsoft Smooth Streaming (MSS), Adobe HTTP Dynamic Streaming (HDS), MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH). All these protocols are based on the concept of adaptive streaming http (in English H AS, for "HTTP Adaptive

Streaming ”). The distribution of multi-screen content typically uses a video distribution network head comprising a video encoding unit which receives as input content to be encoded and delivers to a formatting unit (sometimes referred to in English as "packager ") Encoded streams known as" elementary streams ". A content received as input is encoded according to a plurality of encoding profiles (a profile being for example defined with coded, resolution and bit rate parameters).

[0007] The encoded streams (elementary streams) delivered by the video encoding unit are split within the shaping unit into at least two sequences of successive segments, respectively audio and video, the segments generally being of fixed duration (typically a few seconds), the format of which depends on the protocol chosen (for example MPEG2-TS, MP4, etc.). For each content, a set of metadata relating to multimedia content, sometimes called a media presentation container (from the English “Media Presentation Description”, or MPD) or “manifest” (from the English “manifest” ), is also generated by the formatting unit, for example in the form of a file, for example in XML format, indicating the characteristics of each profile and the available segments corresponding to the content.

[0008] These manifests and the associated segments are supplied by the formatting unit to a content server, then stored on content distribution networks, called “CDN” (standing for “Content Delivery Network”) , providing caching capacities which make it possible to improve the quality of the services, and to minimize the access times and the latency for the visualization of contents by reading terminals.

[0009] A terminal for video playback of content distributed in dynamic mode (by

example configured within user equipment such as a smartphone, tablet or any other type of computer), in other words dynamic video content, or “live” (as opposed to static type content, such as, for example, VOD content), will typically be configured to play this content using the information contained in the manifest associated with the content.

The implementation of a playback of multimedia content "live", that is to say distributed in dynamic mode, on the basis of the associated manifesto, however, presents limitations, in view of certain new cases of use involving a switch from a first live content being read to a second live content. In fact, the existing mechanisms for switching from a first multimedia content to a second multimedia content do not allow these new use cases to be satisfactorily managed.

[0011] The invention aims to improve the situation.

[0012] According to a first aspect, a method for managing multimedia content is proposed.

The method comprises, in one or more embodiments: obtaining a first a set of content description metadata describing a first multimedia content distributed in dynamic mode; and on reading from the first set of redirection data metadata to a section of a second set of content description metadata, reading from the section of the second metadata set data relating to time synchronization for access to a second multimedia content distributed in dynamic mode.

[0013] The proposed method advantageously makes it possible to use redirection data to perform a switch from a first multimedia content distributed in dynamic mode to a second multimedia content distributed in dynamic mode, on the basis of a single set of metadata from Description of the content in which the redirect data is inserted.

[0014] For example, in the context of the third edition of the ISO / IEC specification

23009-1 (“Information technology - Dynamic adaptive streaming over http (DASH) - Part 1: Media presentation description and segment formats”), which provides for the possibility of using redirection data in the form of an “xlink »Insertable in a timeslot container of a manifest (which corresponds to a set of content description metadata), an xlink cannot be used to perform a read failover of a first content distributed in dynamic mode to a second content distributed in dynamic mode. The proposed method provides for modifying the use of xlink links by including in the resolution of such a link a time synchronization data read for access to the second content distributed in dynamic mode.

[0015] Thus, the proposed method advantageously makes it possible to insert in the resolution of redirection data, that is to say, in obtaining the data to which the re direction gives access, access to synchronization data temporal for access to the second content distributed in dynamic mode.

[0016] This makes it possible, in the case of xlink links specified in the DASH standard, to considerably expand the use cases of this type of link, by benefiting more widely from the advantages they provide, in particular in that they allow a switch in reading between two contents, possibly both distributed in dynamic mode, without changing manifest during reading for access to the contents.

The proposed method is particularly suitable, although in a non-limiting manner, for the reading, by a reading terminal equipment, of multimedia contents distributed live according to an MPEG DASH, HLS, HDS, MSS or HAS type scheme. . But it is also suitable for reading multimedia contents distributed live according to any scheme in which this reading is performed using sets of content description metadata corresponding to multimedia contents distributed live. [0018] The proposed method could advantageously be implemented in any device configured for reading multimedia content, on the basis of a set of multimedia content description metadata, for example in accordance with the MPEG DASH, HLS, standards. HDS, MSS, or HAS, such as, without limitation, any computer, smartphone, user equipment, video player, video playback terminal, tablet, etc.

[0019] In one or more embodiments, the second set of content description metadata may describe the second multimedia content distributed in dynamic mode.

[0020] In one or more embodiments, the data relating to a synchronization

Temporalization for accessing the dynamically distributed second media content can be read, in the second set of content description metadata, in a time slot description container relating to the second media content.

[0021] In one or more embodiments, the data relating to a synchronization

The timing for accessing the dynamically distributed second media content may include data indicating an availability timestamp of the second media content.

[0022] In one or more embodiments, the data relating to a synchronization

The timing for accessing the dynamically distributed second media content may include data indicative of accessibility information of segments of the second media content.

[0023] In one or more embodiments, the data relating to a synchronization

Temporalization for access to the second multimedia content distributed in dynamic mode may correspond, in whole or in part, to data relating to a temporal synchronization provided under a root element of the second set of metadata.

In one or more embodiments, the first and second sets of metadata are manifests in the “Dynamic adaptive streaming over HTTP” (Hypertext Transfer Protocol), DASH format.

[0025] In one or more embodiments, the data relating to a synchronization

temporalization for access to the second multimedia content distributed in dynamic mode may include data indicating an availability timestamp of a first segment of the second content, data indicating a common duration used in the definition of rates associated with the second content and data indicating a timestamp of generation of the second set of metadata and its publication on a multimedia content distribution network. In one or more embodiments, this data may further include one or more several of data indicating a distribution type of the second content, data indicating a generation timestamp of a segment of the second oldest content still available, clock data and data indicating a duration of a smaller buffer time offset used for the second content.

[0026] According to a second aspect, there is proposed a content reading device

multimedia, comprising a processor and memory operatively coupled to the processor, wherein the processor is configured to implement the method proposed according to one or more embodiments.

[0027] According to another aspect, there is proposed a method for managing multimedia content, comprising: obtaining a first set of content description metadata describing a first multimedia content distributed in dynamic mode; and on reading from the first set of redirection data metadata to a section of a second set of content description metadata, reading from the section of the second metadata set data relating to time synchronization for access to a second multimedia content distributed in dynamic mode corresponding to the second set of content description metadata.

According to another aspect, there is provided a method for managing multimedia content, comprising: reading, on the basis of a redirection link in a first set of content description metadata describing a first multimedia content distributed in dynamic mode, in a predefined section of a second set of content description metadata, data relating to time synchronization for access to a second multimedia content distributed in dynamic mode corresponding to the second set of content description metadata.

According to another aspect, there is proposed a set of content description metadata describing multimedia content distributed in dynamic mode, comprising, in a container describing a time interval, data relating to a time synchronization for the access to multimedia content.

According to another aspect, there is proposed a manifesto in DASH format describing multimedia content distributed in dynamic mode, comprising, in a container of the “Period” type, data relating to a time synchronization for access to the multimedia content. .

According to another aspect, there is proposed a computer program, loadable into a memory associated with a processor, and comprising portions of code for the implementation of the method proposed according to one or more embodiments during the 'execution of said program by the processor, as well as a set of data representing, for example by compression or encoding, said program computer.

Another aspect relates to a non-transient storage medium for a computer executable program, comprising a set of data representing one or more programs, said one or more programs comprising instructions for, during the execution of said one. or several programs by a computer comprising a processing unit operatively coupled to memory means and to an input / output interface module, leading the computer to manage multimedia content according to one or more embodiments of the proposed method. Brief description of the drawings

Other features and advantages of the present invention will become apparent in the following descriptions of non-limiting embodiments, with reference to the accompanying drawings, in which:

Fig 1

[0034] [fig.l]

illustrates an example of a distribution infrastructure according to one or more embodiments.

Fig. 2a

[0035] [fig.2a]

illustrates an example set of content description metadata (or manifesto).

Fig. 2b

[0036] [fig.2b]

illustrates an example set of content description metadata (or manifesto).

Fig. 3

[0037] [fig.3]

presents the method of calculating the segment to be downloaded in the case of multimedia content distributed in dynamic mode.

Fig. 4

[0038] [fig.4]

illustrates the method proposed according to one or more embodiments.

Fig. 5

[0039] [fig.5]

illustrates the method proposed according to one or more embodiments.

Fig. 6a

[0040] [fig.6a]

illustrates an example set of content description metadata (or manifest).

Fig. 6b

[0041] [fig.6b]

illustrates an example set of content description metadata (or manifesto).

Fig. 6c

[0042] [fig.6c]

illustrates an example set of content description metadata (or manifesto).

Fig. 6d

[0043] [fig.6d]

is a timing diagram illustrating a drop-out from a first live content to a second live content.

Fig. 7

[0044] [fig.7]

illustrates an example of device architecture for implementing the proposed method according to one or more embodiments.

detailed description

In the detailed description below of embodiments of the method,

many specific details are presented to provide a more complete understanding. Nevertheless, those skilled in the art can appreciate that embodiments can be practiced without these specific details. In other cases, well-known characteristics are not described in detail to avoid unnecessarily complicating the description.

The present description refers to functions, engines, units, modules, platforms, and diagram illustrations of methods and devices according to one or more embodiments. Each of the functions, motors, modules, platforms, units and diagrams described can be implemented in hardware, software (including in the form of on-board software ("firmware"), or "middleware"), microcode, or any combination of these. In the case of implementation in software form, functions, motors, units, modules and / or diagram illustrations can be implemented by computer program instructions or software code, which can be stored or transmitted on a computer readable medium, including a non-transient medium, or a medium loaded in the memory of a generic, specific computer, or of any other apparatus or programmable data processing device to produce a machine, in such a way that computer program instructions or software code executed on the computer or device or programmable data processing device, constitute means of implementing these functions.

[0047] The embodiments of a computer readable medium include, but are not limited to, computer storage media and communication media, including any medium facilitating the transfer of a computer program from a location to another. By “computer storage medium (s)” is meant any physical medium that can be accessed by a computer. Examples of computer storage media include, but are not limited to, flash memory disks or components or any other flash memory devices (eg, USB keys, memory sticks, memory sticks, key disks) , CD-ROMs or other optical data storage devices, DVDs, magnetic disk data storage devices or other magnetic data storage devices, data memory components, RAM, ROM, EEPROM, memory cards (“smart cards”), memories of the SSD (“Solid State Drive”) type, and any other form of support that can be used to transport or store or memorize data or data structures which can be read by a processor. 'computer.

[0048] In addition, various forms of computer readable medium can transmit or carry instructions to a computer, such as a router, a gateway, a server, or any data transmission equipment, whether it is wired transmission (by coaxial cable, optical fiber, telephone wires, DSL cable, or Ethernet cable), wireless (by infrared, radio, cellular, microwave), or virtualized transmission equipment (virtual router, virtual gateway, end of virtual tunnel, virtual firewall). The instructions may, depending on the embodiments, include code of any computer programming language or computer program element, such as, without limitation, assembly languages, C, C ++, Visual Basic, HyperText Markup Language (HTML), Extensible Markup Language (XML), HyperText Transfer Protocol (HTTP), Hypertext Preprocessor (PHP), SQL, MySQL, Java, JavaScript, JavaScript Object Notation (JSON), Python, and bash scripting.

In addition, the terms "in particular", "for example", "example", "typically" are used in the present description to denote examples or illustrations of nonlimiting embodiments, which do not necessarily correspond to preferred or advantageous embodiments over other possible aspects or embodiments.

By "server" or "platform" is meant in the present description any point of service (virtualized or not) or device operating data processing, one or more databases, and / or communication functions of data. For example, and without limitation, the term "server" or the term "platform" may refer to a physical processor operably coupled with associated communication, database and data storage functions, or refer to a network, group, set or complex of processors and storage equipment associated data and networking, as well as an operating system and one or more database system (s) and application software in support of the services and functions provided by the server. A computing device can be configured to send and receive signals, by wireless and / or wired transmission network (s), or can be configured for processing and / or storage of data or signals, and can therefore operate as a server. Thus, equipment configured to operate as a server can include, by way of non-limiting examples, dedicated rack-mounted servers, desktops, laptops, service gateways (sometimes referred to as "boxes" or " residential gateway ”), multimedia decoders (sometimes called“ set-top boxes ”), integrated equipment combining various functionalities, such as two or more of the functionalities mentioned above. Servers can vary widely in their configuration or capabilities, but a server will typically include one or more central processing unit (s) and memory. A server can also include one or more mass memory equipment (s), one or more power supply (s), one or more wireless and / or wired network interface (s), one or more several input / output interface (s), one or more operating system (s), such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, or an equivalent.

By multimedia content is meant in the present description any audio and / or video content, subtitles, data, audiovisual, music, sound, image and interactive graphical interface, and any combination of these types of content.

The terms "network" and "communication network" as used in the present description refer to one or more data links which can couple or connect equipment, possibly virtualized, so as to allow the transport of data. between computer systems and / or modules and / or other electronic devices or equipment, such as between a server and a client device or other types of devices, including between wireless devices coupled or connected by a wireless network, for example. A network can also include a mass memory to store data, such as a NAS (in English "network attached storage" in English, a SAN (in English "storage area network"), or any other form of media readable by a computer. or by a machine, for example. A network may include, in whole or in part, the Internet network, one or more local area networks (or LANs), one or more WAN type networks (in English "Wide area networks"), wired type connections, wireless, cellular, or any combination of these different networks. Similarly, subnets may use different architectures or be compliant or compatible with different protocols, and interoperate with larger networks. Different types of equipment can be used to make different architectures or different protocols interoperable. For example, a router can be used to provide a communications link or a data link between two LANs that would otherwise be separate and independent.

The terms "operably coupled", "coupled", "mounted", "connected" and their various variants and forms used in the present description refer to couplings, connections, assemblies, which can be direct or indirect , and include in particular connections between electronic equipment or between portions of such equipment which allow operations and functions as described in the present description. In addition, the terms “connected” and “coupled” are not limited to physical or mechanical connections or couplings. For example, an operative coupling may include one or more wired connection (s) and / or one or more wireless connection (s) between two or more devices that allow simplex and / or duplex communication links. between the equipment or portions of the equipment. In another example, an operational coupling or connection may include a wired and / or wireless link coupling to enable data communications between a server of the proposed system and other equipment of the system.

The terms “application” or “application program” (AP) and their variants (“app”, “webapp”, etc.) as used in the present description correspond to any tool which functions and is operated by means of from a computer, to provide or execute one or more function (s) or task (s) for a user or another application program. To interact with and control an application program, a user interface may be provided on the equipment on which the application program is implemented. For example, a graphical user interface (GUI) can be generated and displayed on a user equipment screen, or an audio user interface can be played back to the user using a loudspeaker. , headphones or audio output.

The terms "multimedia content" as used in the present description correspond to any content of audio and / or video or audiovisual type.

In the present description, the terms “real-time” distribution, “linear mode” distribution, “linear TV mode” distribution, “dynamic mode” distribution and “live” or “live mode” distribution are used interchangeably to denote the dynamic mode or type distribution (in English "live" or "dynamic" mode) of multimedia content in a distribution system. distribution of content to terminals, including in particular the distribution of the content as it is generated, as opposed to the distribution of previously generated content, on a user's access request (distribution on access request or distribution in "static" mode or type (in English, "static"), such as, for example, content recorded on a server, and made available to users by a video on demand (VOD) service .

In the present description, the terms “live content” refer to content, for example of multimedia type, distributed, for example according to an OTT distribution mode, in dynamic mode (as opposed to the static distribution mode). Live content will typically be generated by a television channel, or by any type of television media, and may also be broadcast over a multimedia content distribution network, in addition to being made available on content servers in a distribution system. OTT.

In the present description, the terms "terminal", "user equipment",

"Reader", "reading device", "reading terminal" and "video player" are used interchangeably to designate any type of device, implemented by one or more software, one or more hardware, or a combination of one or more software and one or more hardware, configured to use multimedia content distributed according to a multi-screen distribution protocol, in particular for loading and playing the content. The terms “client” and “video playback client” are also used interchangeably to refer to any type of device, software and / or hardware, or any function or set of functions, implemented by software and / or hardware within a device, configured to use multimedia content distributed according to a multi-screen distribution protocol, in particular by loading the content from a server and playing the content.

Figure 1 illustrates an example of the architecture of a distribution system (1) of

multimedia content, in which the proposed method can be implemented. FIG. 1 shows a video distribution network head (2) comprising a video encoding unit (4) which receives as input content to be encoded (“contribution”) (3), and delivers to a formatting unit (5) (“packager”) encoded streams known as “elementary streams”. As illustrated in FIG. 1, a content received as input is encoded according to a plurality of encoding profiles (a profile being for example defined with parameters of coding, resolution and bit rate). The use of a plurality of encoding profiles has at least two advantages: First of all, a plurality of profiles makes it possible to address reading terminals with the characteristics (coded supported, screen resolution, decoding power ) different. In addition, it offers the video players of these terminals the possibility of adapting according to the available network bandwidth. Indeed, the reader of a client (of a terminal) can be configured. to seek to achieve the encoding profile corresponding to the highest bit rate, as a function of the bandwidth measurements that it continuously performs.

The encoded streams (elementary streams) delivered by the video encoding unit (4) to

the shaping unit are cut into two sequences of successive segments, respectively audio and video, which are generally of fixed duration (typically a few seconds) by the shaping unit (5), the format of which depends the chosen protocol (for example MPEG2-TS, MP4, etc.). For each content, a set of metadata relating to multimedia content, or "manifest", is also generated by the formatting unit. This is typically a file, for example in XML format, indicating the characteristics of each profile and the available segments corresponding to the content.

These manifests and the associated segments are provided by the formatting unit (5) to a content server (6) (“Origin Server” in FIG. 1), then stored on content distribution servers (8a, 8b), called "CDN" (from the English "Content Delivery Network"), providing caching capabilities that improve the quality of services provided to users, and minimize access times and latency for viewing content by reading terminals.

The contents stored in the CDN servers (8a, 8b) are accessible in read mode to user terminals (10a, 10b, 10c), through a service platform (7) for the distribution of the contents. The clients installed in the terminals (10a, 10b, 10c) can access the content stored on the CDN servers via one or more data communication networks, such as for example the Internet network (9), as illustrated in the figure.

FIG. 2a illustrates an example of XML file content corresponding to a

manifest using the DASH (or MPEG-DASH) format. One such manifesto presents a tree structure of nested XML containers, as shown in Figure 2a. Although this description provides examples of embodiments based on the DASH format specified in the third edition of ISO / IEC 23009-1 "Information Technology - Dynamic adaptive streaming over HTTP

(DASH) - Part 1: Media presentation description and segment formats ”, those skilled in the art can realize that the proposed methods are not limited to a particular type or format of manifest (or set of descriptive metadata of multimedia content (s), and that they apply to all types of manifests, such as manifests using other OTT protocols and distribution formats, such as for example the HLS, MSS and HDS protocols and formats mentioned above -above.

[0064] The DASH manifesto illustrated in FIG. 2a has a hierarchical structure

organized according to the following tree structure:

A root element of the document (from the English Media Presentation Description, MPD) contains the attributes applicable to all the elements of the document (the other elements being sometimes called “child” elements).

The root "MPD" can, in addition to the "child" elements, define values

attributes, including the following attributes that relate to the distribution of live content:

[0067] The "type" attribute defines the type of content distribution: "static" for

content distributed in static mode (typically content distributed according to a Video on Demand (VOD) service) and “dynamic” for content distributed in dynamic mode.

The "AvailabilityStartTime" attribute, relating to the distribution mode

dynamic, defines the date (for example in the format coordinated universal time (in English "UTC", for "Coordinated Universal Time")) of availability of the first segment generated for the current service. This information can be used to indicate the start time of the service, so that it can be used by a reading terminal as a time anchor point for the start of the service.

The "PublishTime" attribute indicates a date of generation of the manifesto and of its publication on the CDN network. This information makes it possible to record different versions of the same manifesto corresponding to successive publications, in order to detect changes that have occurred from one publication to another.

[0070] The "AvailabilityEndTime" attribute indicates a generation date of the oldest segment still available.

[0071] The "MinimumUpdatePeriod" attribute defines the shortest period between

potential changes in the MPD. The value of this attribute can be used by the content reader terminal to configure a frequency with which it downloads the manifest, being informed that the manifest will be updated by the formatting unit at least at the frequency indicated by this attribute.

The "MinBufferTime" attribute, mandatory in the example format illustrated in Figure 2a, defines a common duration used in the definition of the bit rates of the representations.

[0073] The "TimeShiftBufferDepth" attribute defines the duration of the smallest time offset buffer for all representations of the manifest, ensuring the availability of segments for dynamic type distributions. Its value indicates the time period in the past for which the content associated with the manifest, distributed dynamically, is available on the CDN server. This value can for example be equal to 1 minute, in which case the player can go back to the past (“live” content) for one minute, or retrieve a minute of live content if the user uses the “pause” function. To stop playing live content.

The “SuggestedPresentationDelay” attribute defines a fixed time offset which can be applied when presenting each access unit. This setting allows you to squeeze as close as possible to the live content boundary, to ensure that all playback terminals that play the same live content will play it in the same location. For example, we can configure the playback so as to go back 4 seconds in the past to give ourselves a margin of safety in relation to the course of the live content.

[0075] The "UTCTiming" attribute provides a common clock between the formatting unit and the reading terminal (or video player). It allows you to indicate to the terminal a way to retrieve a clock synchronized with the content server.

[0076] "Child" elements, in the form of containers possibly nested one inside the other, can also be included in the manifesto to specify the files accessible through the manifesto. With reference to FIG. 2a, these “child” elements can be:

A “Period” type element, describing a time interval, whether or not bounded in time. One or more attributes can be provided for an element of type "Period", among which an attribute ("id") identifying the period

("Id =" PO "" in Figure 2), a period start time attribute ("start") ("start =" PTOS "" in Figure 2), and an attribute ("duration") of period duration (not present for an open period, that is to say not yet terminated). The value of the period start time attribute (0 seconds in the example shown in Figure 2a) can be combined with the value of the "availabilityStartTime" element described above)

Each child element of the "Period" type can itself contain elements.

children. For example, as illustrated in FIG. 2a, an element of type “Period” can contain two child elements of type “AdaptationSet” each corresponding to a type of content.

The element of type "AdaptationSet" is a container which makes it possible to describe available content according to their type. It makes it possible to group together elements concerning the same component of multimedia content such as audio, video or subtitles, but encoded with parameters (bitrates, resolutions, frame rate (in English "framerate"), rate of different sampling rates. In the example of Figure 2, only one encoding profile is available, and this profile is described for its video component (contentType = "video" id = "0" maxLrameRate = "25"

For example, a video player can quickly obtain the video encoding profile parameters used for encoding the content described in the illustrated manifesto. in figure 2: bandwidth, video encoder parameters, frame rate, resolution, frame format, etc. ("Bandwidth =" 4000000 "codecs =" hevl.2.4.L120.90 "frameRate =" 25 "height =" 1080 "id =" vl "sar =" l: l "width =" 1920 "").

[0080] Encoding parameters can be provided by the element "Representation", which allows to precisely describe the encoding parameters and access to a component of the media.

FIG. 3 illustrates an example of a method for reading live content by a video playback client (or a video player). The illustrated method uses some of the information described above for the example manifesto illustrated in Figure 2a to determine the data segment to download for each "AdaptationSet" of the current period, and thus allow the client to hang on. content to read.

[0082] The playback of live content put in MPEG-DASH format is mainly linear.

When connecting to the content server, the client first retrieves the manifest containing information specific to the content distributed in dynamic mode (“live”), then begins reading at the location of the content corresponding to the current time. (in order to follow an event taking place in real time (or live)). To do this, it determines the current period by calculating the time elapsed since the "availabilityStartTime" value indicated in the manifest, then determines the number of the "live" segment in this period by the same means.

Referring to Figure 3, in one or more embodiments, the client obtains (50) a manifest corresponding to the live content to be played, then synchronizes (51) (52) with a multimedia content server via the 'intermediate the value of the attribute "UTCtiming" indicated in the manifest.

[0084] From the "availabilityStartTime" attribute and the current time

("CurrentTime"), the client can then determine (53) the elapsed time fe () since the start of the live media content. As discussed above, depending on the encoding conditions, a delay ("PresentationTimeOffset") may be applied (54) to the transmission of the multimedia content in order to allow time for the encoder to encode the segments, which leads to the determination of a time fc () defined by fe ()

- PresentationTimeOffset. Finally, depending on the size of the segments ("segment duration") defined in the manifesto, and a time scale parameter

(“TimeScale”), an index (57) fi () or a timestamp (56) (“TimeStamp”) ft () of the current time segment can be calculated, depending on the type of segment (55). From this information, the client can obtain (58) a download address (for example a URL (standing for “Uniform Resource Locator”)), then download the current time segment of the multimedia content. An index of the current hour segment could for example be obtained by dividing the value fc () by the duration of a segment (in English "segment duration") divided by the time scale value ("Timescale"): fi () = fc () / (segment duration / timescale). A timestamp of the current time segment can for example be obtained by dividing the value fc () by the time scale value (“timescale”): ft () = fc () / timescale.

The values described above are provided by the broadcaster to the customer by

through the manifesto. The content provider can further influence the behavior of the customer through other means than the manifesto that the customer downloads, such as inserting signage into a data segment. Thus, the insertion of a specific marker (for example in the form of a "box") identified by a predetermined tag makes it possible to communicate control messages to the customer. For example, inserting an "emsg" box in a data segment indicates to the customer that they must immediately reload the manifest. Thus, a client configured to play an MP4 or MPEG2 TS file (from English

"Transport Stream") will browse (in English, "parse") this file (in its ar borescent form) to detect all the information present, including in particular the signaling information of manifest loading request (for example indicated by an "emsg" sign). It is thus possible to signal an unforeseen event which must be taken into account as soon as possible by overriding the value of the "minimumUpdatePeriod" attribute, which is more suitable for incremental changes to the manifesto.

Several scenarios may however interrupt the logic of broadcasting an event in dynamic mode described above and illustrated in FIG. 3, for example when the client switches to multimedia content other than that being read. (corresponding to a so-called "main" manifesto) is wanted. These interruptions in the playback of live multimedia content may for example correspond to the insertion of targeted advertisements, to events also taking place in real time such as, for example, a regional dropout, or even to the broadcasting of a message from alert.

[0087] The context around the scenario of inserting targeted advertisements is the

following: During an advertising break in content distributed in dynamic mode ("live" content), default advertisements are present in the initial data stream, that is to say corresponding to the live content being played . The content provider may decide to redirect customers to targeted advertisements based on their respective profiles. To do this, the current period indicated in the current manifest (corresponding to the live content being played) can be closed, and a new period of a duration equal to that of the initial advertisement can be inserted in the current manifesto, under the form of a time interval description container (“Period” in the case of a container of a manifest in DASH format). This time interval description container can contain re direction data (for example indicated in an xml file by a redirection link of the type "xlink", for "XML Linking Language", type specified in the recommendation W3C "W3C XLINK XML Linking Language (XLink) Version 1.1, W3C Recom mendation") to an advertising server which, depending on a profile of the client's user, will return a new manifest allowing access to advertisements adapted to this user. The client will read the content described by the “Period” description container of this new manifest for the duration of the period defined by the container. At the end of this period, the client will return to the current manifest in which the advertisement period will also have been closed and a new live period inserted in the form of another time slot description container.

The regional dropout scenario can be encountered when a television channel broadcasts in real time national television news which then drop off at fixed times on regional television news, such as for example the television channel France 3 This use case is similar to that of advertisements because the duration of the release is known in advance. On the other hand, we can imagine regional dropouts of varying durations depending on the region.

[0090] With regard to the scenarios for broadcasting alerts, the regulations provide for devices to allow alert messages to be broadcast by interrupting current programs. These messages can be pre-recorded and therefore of known duration or be produced in real time. In the latter case, the duration of the interruption is not known in advance.

However, it turns out that the cases of switching from a first live content to a second live content without knowledge of the duration of the interruption in reading the first live content cannot be correctly managed, as explained below.

In fact, these toggles between multimedia contents are caused by the use of flow switching orders, called "splicing", coming from equipment located upstream of the audio / video encoder. Upon receipt of these orders, the formatting unit modifies the current manifest (corresponding to the live content being played) to notify the client of a change.

Among these flow switching orders, the switching order to another flow ("splice out") indicates to the customer that he must switch from a primary flow to a conditional flow, and the order of Splice in indicates to the client that it should revert to the primary stream.

Switching from a live primary stream to a live secondary stream (the two streams being distributed in dynamic mode), known as a "live-live switch", has drawbacks which are detailed below.

The DASH standard provides a mechanism for switching between 2 live content, called manifest chaining (in English, "manifest chaining"), which consists in forcing the DASH client to accompany the switch from a first live content to a second live content by switching to a new manifesto, from a first manifesto. This mechanism thus requires the reader to switch to a secondary manifesto, different from the manifesto in use by the client (called “primary” manifesto or “current” manifesto), for the implementation of a switchover of a first live stream corresponding to the primary manifest, to a second live stream, to which the secondary manifest corresponds. However, switching from a first manifesto to a second manifesto has some drawbacks, from the point of view of continuity between successive periods (it is impossible to signal the continuity of periods using manifest chaining as specified), from the point of view of view of Digital Right Management (DRM) (as the manifest URL changes when switching, the DASH client should store the original period to determine that the same DRM configuration can be used, which is enough binding from the point of view of the DASH client), and from the point of view of the management of the authentication tokens of the CDN server (as the manifest URL changes during the switchover, the DASH client should store the period d 'origin and the URL after redirection in order to determine that the same URL is used and therefore not to redo the authentication step with the CDN, which is quite restrictive from the point of view of the DASH client). In addition, during this switchover, the reader loses knowledge of the primary manifesto, making it complicated, if not impossible, to return to the first live stream at the end of the switchover period (for example when the alert ends. in the case of an alert broadcast mentioned above).

For the management of a switch from a first content to a second content, it is possible to use redirection data (to data corresponding to the second content) inserted in the manifest, for example under an element defining a time interval (not necessarily bounded) relating to the second content. In the case of a manifest in DASH format, an "xlink" type redirection link can thus be inserted in a "Period" type container, as illustrated in Figure 2b. The ISO / IEC 23009-1 specification "Information Technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats" defines the insertion of xlink-type redirect links in a manifest in DASH format.

FIG. 2b thus illustrates an example of a manifest in DASH format after insertion of a period pointing to another content in the form of a container of the "Period" type comprising an xlink link pointing to another manifest corresponding to this other content (in particular in that it contains information allowing access to this other content). The manifesto illustrated in FIG. 2b comprises three periods, each in the form of a container of the “Period” type: a first period “PO”, which corresponds to a period of a first live content, which begins at time 0 and which lasts 2 minutes and 18 seconds: "<Period id =" P0 "start =" PT0S "dur ation =" PT2M18S ">".

After 2 minutes and 18 seconds, a toggle order (splice) is received and the manifest is updated accordingly: the current period is closed and the duration attribute ("duration =" PT2M18S "") added in the manifesto. A second period ("PI") corresponding to a second content, of duration 30s (corresponding for example to the duration of a second content of one or more advertisements), begins at the instant T0 + the duration of the period PO (2minutes and 18 seconds) (start = "PT138S"). The xlink link (xlink: actuate = "onLoad" xlink: href = "http: // ..."

xmlns: xlink = http: //www.w3.org/1999/xlink in the example shown in Figure 2b), inserted as an additional attribute of the PI “Period” container, allows access to this second content: “< Period id = "Pl" start = "PT138S" duration = "PT30S" xlink: actuate = "onLoad" xlink: href = "http: // ..."

xmlns: xlink = "http://www.w3.org/1999/xlink"> ". On reading this xlink link, the client will resolve the link, i.e. access the URL indicated by the link (in the example shown in the property "" xlink: href = "http: //. .. "

xmlns: xlink = http: //www.w3.org/1999/xlink ”) to download a second manifesto containing data relating to access to the second content, then extract from this second manifest one or more periods, in the form one or more “Period” containers. Thus, the customer will use the redirection to get information relating to this new PI period via the information accessible by the xlink link.

A third period (container "Period" "P2") corresponds to the return to the initial content following the interruption of the period P1. In the example of FIG. 2b, this period corresponds to the first live content and n ' therefore has no specified duration:

"<Period id =" P2 "start =" PT168S ">".

[0100] However, a problem has been identified which would prevent the smooth running of a live-live switch (from a first live content with which is associated a first manifesto to a second live content with which is associated a second manifesto) which uses would read a redirection mechanism (eg xlink type redirection link) to signal the target of the toggle as specified in the ISO / IEC 23009-1 specification mentioned above. Indeed, the time synchronization information necessary for the client to obtain the segments of the second live content will be present at the level of the root element of the second manifest (MPD element in the DASH format), as described above in connection with FIGS. 2a and 2b, but not at the level of each container defining a time interval (not necessarily limited) relating to the second content. The ISO / IEC 23009-1 standard specifies that the resolution of an xlink link inserted in a time slot description container (defining a period), i.e. the download of the manifest at the address indicated by the xlink link and extracting the period (s) (time interval containers) from this manifest, must return not the full manifest, but only the period (s) concerned (multiple periods from the remote manifest (second manifest) which can be substituted by resolution of the xlink link at a period of the initial manifesto (first manifesto)). Thus, the resolution of an xlink redirection link inserted in a time interval description container ("Period") as specified in the ISO / IEC 23009-1 standard, does not allow the client to obtain information. contained in the remote manifest to which the link points other than the information contained in a timeslot description container of that remote manifest. In particular, the standard does not provide that the client can obtain elements specified by the standard as having to be included under the root (PDM) of the remote manifest. The consequence of this limitation of the standard is that from a single period of live content (from only the information provided in a time interval definition container (for example of type

"Period")), a client is not able to know when the stream (corresponding to the second content) started, and therefore cannot determine which segments are available for the second live content (for example by using the method described above in connection with Figure 3).

[0101] Also, as they are currently specified, xlinks type redirection links make it possible to cover the case of a dropout from a first live content to a second non-live content (for example of vod type), to return to live content, i.e. a live->vod-> live switchover sequence, but not the case of a live-live switch-over, including a drop-out from a first live content to a second live content, to eventually return to the first live content. This is because resolving an xlink type redirect allows the DASH client to get one or more periods (a time slot description container) of manifest, not a full manifest. This does not pose a problem when the failover targets a second non-live content, for which the client does not need to obtain data to determine when the corresponding stream started, in order to determine which are the available segments, since the start and duration of non-live content are predetermined. On the other hand, the timing information allowing to calculate the progress of the second live content, which is only present as discussed above at the root level (MPD) of the second manifesto, and not at the level of the elements of this second manifesto defining time periods, are not accessible to the client when the baseline is carried out.

[0102] FIG. 4 illustrates the method proposed according to one or more embodiments. This method can be implemented by any device comprising a processor and a memory, and configured for its implementation, such as, for example, a multimedia content player, a terminal, a device running a DASH client or a client configured for receive and play multimedia content using any other OTT multimedia content distribution protocol, or user equipment (smartphone, tablet, computer, etc.) equipped with a multimedia content player.

[0103] In one or more embodiments, the device configured for the implementation of the method can be configured to obtain a first set of content description metadata describing a first multimedia content distributed in dynamic mode (for example, for a DASH client, a first manifest in the DASH protocol format, for example in the form of an XML file). The first set of metadata can describe a first multimedia content distributed in dynamic mode, for example by means of metadata relating to a first multimedia content distributed in dynamic mode included in the first set.

[0104] The device can further be configured to read the first set of data.

tadata, and for, on reading from the first metadata set of redirect data to a section of a second set of content description metadata, read (61) from the section of the second set of metadata data relating to a time synchronization for access to a second multimedia content distributed in dynamic mode.

[0105] Typically, the second set of content description metadata will correspond to the second multimedia content distributed in dynamic mode. For example, this second set to describe the second content, for example by means of metadata relating to the second content included in the second set.

[0106] Thus, the redirection data used in a first manifesto make it possible to cause a device, while reading this first manifesto, to obtain the data contained in a specific section of a second manifesto, in the course of the reading of the first manifesto, that is to say without changing the current manifesto in reading.

This possibility of being able to retrieve data in another manifesto, without however changing manifesto during reading, has several advantages: from the point of view of continuity between successive periods, the manifesto remaining the same, only the content of the failover period is replaced. It is therefore possible to indicate the continuity of periods. From the point of view of DRM management, the manifest URL remaining the same when switching, it is possible for the device (player) to optimize the DRM configuration when returning to the main stream. From the point of view of the management of CDN authentication tokens, the manifest URL remaining the same during the switch, it is possible for the player to continue using the same CDN authentication token during the switching. back to the main stream.

[0108] It is therefore particularly advantageous to use redirection data to perform a switch from a first content to a second content, including in the case where the first and second content are distributed in dynamic mode (case where the first content is live content, and the second content is also live content).

[0109] In one or more embodiments, the data relating to a synchronization

The temporalization for accessing the dynamically distributed second media content is read from the second set of content description metadata into a time slot description container relating to the second media content.

[0110] In one or more embodiments, the data relating to a synchronization

The timing for accessing the dynamically distributed second media content includes data indicating an availability timestamp of the second media content.

[0111] In one or more embodiments, the data relating to a synchronization

The timing for accessing the dynamically distributed second media content includes data indicative of accessibility information of segments of the second media content.

[0112] In one or more embodiments, the data relating to a synchronization

Temporalization for access to the second multimedia content distributed in dynamic mode correspond, in whole or in part, to data relating to a temporal synchronization provided under a root element of the second set of metadata.

[0113] In one or more embodiments, the data relating to a synchronization

timing for accessing the dynamically distributed second media content includes data indicating an availability timestamp of a first segment of the second content, data indicating a common duration used in defining rates associated with the second content, and data indicating a generation timestamp of the second set of metadata and its publication on a multimedia content distribution network. In one or more embodiments, this data may further comprise one or more among data indicating a distribution type of the second content, data indicating a generation timestamp of a segment of the second oldest content still available, clock data and data indicating a duration of a smaller buffer of time offset used for the second content. For example, in the case of a DASH manifesto, the time synchronization data inserted in a “Period” container (which can be read by a DASH client when resolving an xlink type redirection link) can include at minus the following: availabilityStartTime, minBufferTime, and publishTime.

As explained above, the switching from a first content to a second content can be managed at the level of a first manifesto relating to the first content (currently being read) by the use of a redirection link. to a second manifest relating to the second content, for example signaled by a redirection link of the type "xlink" for the DASH format. The live-live switch, in the case where the first and second contents are distributed in dynamic mode, can thus take place without changing the manifesto.

[0115] As specified by ISO / IEC 23009-1 ^3rd edition, the redirection link to a second manifesto xlink point type to a section of the second manifesto, and not towards the entire second manifesto. Thus, the client who resolves an xlink embedded in container defining a time interval (a "Period") of the first manifest, obtains an address of the second manifest (based on the information provided by the link), then downloads the section of the second manifesto relating to the "Period", that is to say to the time interval defined in the first manifesto. Thus, the client downloads into the second manifest information contained in a time slot description container indicated by the redirect link, which is the time slot of the container of the first manifest which includes the redirect link (by xlink example).

The time synchronization information necessary for access to the second content for the time interval considered being available only at the root of the second manifesto, which root is not read by the client during the resolution. of an xlink link, in one or more embodiments, it is proposed to include in the time slot description container of the second manifest (which the client comes to read when it resolves the redirect link) information time synchronization for access to the second content. A live live failover, the first multimedia content distributed dynamically to the second multimedia content distributed dynamically and may advantageously be performed using a redirect link, particularly in the context of the ISO / IEC 23009-1 ^3rd edition using xlink type redirect.

[0117] In the embodiments using a redirection mechanism to a second multimedia content distributed in dynamic mode, the device, browsing the first set of metadata, will be able to read redirection data to a section of a second set of description metadata of multimedia content (s) for access to the data of a second multimedia content distributed in dynamic mode. The device can be configured to, on reading these redirection data, read in the section of the second set of metadata of descriptions of multimedia content (s) data relating to a time synchronization for access to the second multimedia content distributed in dynamic mode. These data relating to the time synchronization can advantageously be used by the device for access to the second live content, thus overcoming the absence of timing information, in particular making it possible to calculate the progress of the second live content, at the level the time interval description container (of the element ("Period")) of the second metadata set, container to which an xlink-type redirection link inserted in a time interval description container of the first all will point (as specified by ISO / IEC 23009-1 ^3rd edition).

[0118] Thus, the proposed method advantageously allows, within the framework of the ISO / IEC 23009-1 standard, the use of a redirection link of the xlink type to perform a live live baseline, that is to say a read switch from a first multimedia content distributed in dynamic mode to a second multimedia content distributed in dynamic mode, by inserting in a time interval description container of a second manifesto that the client will come to read during the resolution an xlink link inserted in a time slot description container of a first manifesto, time synchronization data for access to the second content distributed in dynamic mode.

[0119] In one or more embodiments, the device may furthermore obtain an update of the first set of content description metadata upon the expiration of a period of time corresponding to the duration of the second multimedia content. live, in order to possibly switch back to the first live content once the playback period for the second live content has expired.

[0120] In one or more embodiments, the data relating to a synchronization

temporalization for access to the second multimedia content distributed in dynamic mode can be inserted in a section of the second set of multimedia content description metadata to which the redirect link inserted in the first set of metadata points, from such that this data is read (as the data of the section of the second set) when the link is resolved by a device being read from the first set of metadata. In one or more embodiments, the section of the second set of multimedia content description metadata in which data relating to a time synchronization for access to the second multimedia content distributed in dynamic mode is inserted corresponds to a time slot description container relating to the second multimedia content . For example, it may be a container corresponding to the “Period” attribute or element (described above) in a manifesto of format specified by the ISO / IEC 23009-1 standard. Thus, these data can be advantageously taken into account during a linear reading by the device of the time interval description container of the second manifest, on reading of redirection information inserted in an interval description container of time of the first manifesto.

[0121] In one or more embodiments, the timing data inserted in the section of the second manifesto can be grouped together within a specific container, for example entitled “LivePeriod”, and identified in the manifest by corresponding tags ( “LivePeriod” for the start of the container, and “/ LivePeriod” for the end of the container), for example according to XML syntax. An example of a LivePeriod container as proposed in one or more embodiments is illustrated by FIG. 6C.

[0122] In one or more embodiments, the data relating to a synchronization

The timing for accessing the dynamically distributed second media content may include data indicating an availability timestamp of the second media content. For example, this data can include time synchronization information that will allow the client to know when the live stream corresponding to the second content has started.

[0123] In one or more embodiments, the data relating to a synchronization

The timing for accessing the dynamically distributed second media content may include data indicative of accessibility information of segments of the second media content. For example, this data can include time synchronization information which will allow the client to know which segments corresponding to the second content are currently accessible.

In one or more embodiments, the types of data relating to a time synchronization for access to the second multimedia content distributed in dynamic mode may correspond to at least some of the types of data relating to a time synchronization provided under a root element of the second set of metadata.

[0125] For example, the syntax of the DASH manifests could be enriched by inserting a copy of the time information necessary for the DASH client to hook the current flow and which is provided at the root of the second manifest, in a new container (or item) added to the time interval description item (container) level for the second live content.

[0126] In one or more embodiments, the data relating to a synchronization

timing for accessing the dynamically distributed second multimedia content may include data indicating a type of the second content, and at least one of data indicating an availability timestamp of a first segment of the second content, data indicating a generation timestamp of a segment of the second oldest content still available, and data indicating a common duration used in defining rates associated with the second content, clock data, and data indicating a duration of 'a smaller time shift buffer used for the second content.

[0127] For example, using the DASH format, a new element (for example

called "LivePeriod") can be added at the level of the "Period" element, and include time information that will allow the receiver to know when this stream started and which segments are currently accessible. In one embodiment, the new “LivePeriod” element may contain elements among the elements “type”, “availabilityStartTime”, “publishTime”, “availabilityEndTime”,

“MinimumUpdatePeriod”, “minBufferTime”, “timeShiftBufferDepth” and

"UTCTiming" to tell the receiver that this is a live stream, when that stream started, and which segments are currently accessible.

[0128] In one embodiment where a switch from a first live content to a second live content is operated on resolution of an xlink link in a manifest in DASH format, the type of content will be dynamic (distribution in dynamic mode for live content) (type = dynamic), and the proposed new element may contain at least the elements “availabilityStartTime”, “publishTime” and “minBufferTime”, according to the DASH specification (ISO / IEC 23009-1), section 5.3. 1.2 table 5.1, which specifies that the following elements are mandatory in dynamic mode: availabili tyStartTime, minBufferTime and publishTime. The other elements may not be present among the data relating to a time synchronization inserted in the section of the second manifesto which will be read by the client during the resolution of redirection data read in a first manifesto. The same is true for the <LivePeriod> syntax element, which may not be present in one or more embodiments.

[0129] In one or more embodiments, the data relating to a synchronization

temporal nization inserted in the section of the second manifesto that will be read by the client during the resolution of redirect data read in a first manifesto will include the data specified as mandatory, by the applicable standard, for access to content distributed in mode dynamic in the whole of corresponding tadata.

[0130] FIG. 5 illustrates an exemplary implementation of the method proposed according to one or more embodiments.

[0131] Thus, as previously, a DASH client wishing to play a video sequence distributed in dynamic mode (or current live stream) first makes a request to a content distribution network (CDN) (401) in order to '' get (402) the manifest (set of description metadata) of the current live stream, providing authentication information. The CDN performs a client authentication procedure and, if successful, returns a token (in English,

"Token") and redirects it to a network address (for example a URL) to which the current manifest (corresponding to the current live stream) is accessible to the client. The DASH 200 client can thus hook up to the current live stream (403). In order to be able to correctly hook up to the current live stream, the DASH client determines, from the information contained in the current manifesto, for example by using the method illustrated in figure 3, the segment that it must download according to the time current and the time elapsed to hang on to the current stream, for example by determining an index of this segment or a timestamp as described above.

[0132] Once the DASH client is hooked to the current stream (404), it reads continuously

(404, kb) this current flow, in the absence of a client splice out request.

[0133] When the packager receives a "splice out" order (404, ok), the

packager inserts a signal requiring a switch (“box Emsg”) in the last data segment of the current live stream (405) before the switchover date. This "box" is used to indicate to the DASH 407 (400) client that it must immediately reload the current manifest associated with the current live stream. At the same time, and before reloading the current manifest, the packager deletes the period

("SUP_PERIOD_CUR_LIVE") of the current live stream and insert the period (s) of the secondary live stream (INS_PERIOD_SEC_LIVE_XLINK) by

through an "xlink" link. An "xlink" link allows you to indicate a target of the toggle to the manifest. When using an "xlink" link, a period is returned replacing the current period of the manifest containing the "xlink" link.

In order to insert the period of the secondary live stream, a child element of the MPD, called "LivePeriod", is added in the "Period" element of the secondary manifest that the DASH client will read when the xlink link is resolved. , so that the DASH client can hook the secondary live stream to the current time. For this, the “LivePeriod” element is composed of attributes making it possible to come and calculate the segment of the current period that the reader 407 (400) must recover in order to hook the live stream to take place without the appearance of a time delay. This calculation is equivalent to that presented previously in Figure 3. The attributes of the child element “LivePeriod” can be, in one or more embodiments: type = “dynamic”;

availabilityStartTime; publishTime; availabilityEndTime; minimumUpdatePeriod; minBufferTime; timeShiftBufferDepth and UTCTiming.

[0135] When reloading the current manifest 408, the DASH client 407 will thus load the "xlink" link and resolve the link, that is to say access the data to which the link points. From these data, the reader will calculate and determine the segment of the current period to be recovered in order to hook without temporal delay to the live stream to condare (409).

[0136] If the duration of the secondary live stream is unknown, "410 kb", the player continues playing the secondary live stream as long as no "splice in" command is requested.

[0137] On arrival of a "splice in" request, ie a request to return to the current live stream, an "Emsg box" (411) in the last data segment of the secondary live stream before the changeover date is entered by the packager. As before, the purpose of this "box" is to indicate to the DASH 412 client that he must reload the current manifest.

At the same time, and before reloading the current manifest, the packager deletes the period ("period") of the secondary live stream and comes to insert the period of the current live stream (412) via the information (attributes ) of the current manifest always available at the root of the MPD. When reloading the current manifest (415), the DASH client 412 (407; 400) hooks up to the current live stream without time delay.

[0139] Without the preceding provisions, that is to say a “LivePeriod” child element, it is not possible, when using an “xlink” link, to wait for a live stream to occur because the information allowing the calculation of the segment to download to hook the secondary live stream to the current time is not available in an "xlink" link. Indeed, as explained above and illustrated in Figure 3, the calculation to determine the segment to download uses information (attributes) that are available only at the root of the manifest. When using an "xlink", the period of the main video stream / sequence is replaced by the period (s) attainable by the "xlink" link, and corresponding to another video sequence, such as advertising for example. . The child element "Period" allowing the replacement of one period by another does not have attributes that allow the calculation of the segment to download in order to catch a video sequence that takes place in real time.

[0140] Figures 6a, 6b and 6c illustrate manifests using an indication of re

direction for inserting VOD content into a live stream (figure 6a), and for dropping off to a secondary live stream from a main live stream (figures 6b and 6c).

[0141] Referring to FIG. 6a, the period PO is the initial period of the live content, it starts at T0 and its duration corresponds to the time before the splice out. The PI period is the dropout period, its duration is fixed and known in advance, it is inserted into the manifest at the same time as the return to live period in order to allow the player to preload the segments. The resolution of the xlink makes it possible to obtain the information related to this period in order to substitute them for that present in the manifest. The period P2 is the period of return to the initial content, it starts at the sum of the durations of the previous periods and its duration is not known.

[0142] Figure 6b provides an illustration of an exemplary first manifesto including a redirect link pointing to a section of a second manifesto, and Figure 6c an exemplary second manifesto improved according to the proposed method.

[0143] With reference to FIG. 6b, the period PO is the initial period of the live content, it starts at T0 and its duration corresponds to the time before the splice out, as described previously in connection with FIG. 6a.

[0144] Unlike the manifesto illustrated in FIG. 6a, the period PI of the manifesto illustrated in FIG. 6b is a dropout period corresponding to live content which we do not know when it started. The example redirect link from the first manifest shown in Figure 6b (xlink: actuate = "onLoad" xlink: href = "http: // ..." xmlns: xlink = http: //www.w3.org/ 1999 / xlink) included in the time slot description container <Period id = "Pl" start = "PT10H00M00S" xlink: actuate = "onLoad" xlink: href = "http: // ..." xmlns: xlink = "http://www.w3.org/1999/xlink"> <AdaptationSet id = "0" contentType = "video" ...> </AdaptationSet> <AdaptationSet id = "l"

contentType = "audio" ...> </AdaptationSet>, </Period>, can for example point to the second manifesto shown in figure 6c.

[0145] With reference to FIG. 6c, the resolution of the redirection link (xlink) to read the second manifesto to which it points makes it possible to obtain the timing information (of time synchronization) related to the period defined by the container " Period ”of the second manifest (shown in fig. 6b) in which the redirect link is inserted. In order to allow the client to access the segments of the content to which the second manifest corresponds, a new container (new element ("LivePeriod")) is added at the level of the time interval description container (of the element "Period ") To which the redirect link (xlink) of the first manifest (fig. 6b) points:" LivePeriod type = "dynamic" availabilityS- tartTime = "2019-03-01T14: 00: 00Z" publishTime = "2019-03- 01T14: 00: 00Z "minimu- mUpdatePeriod =" PT10S "minBufferTime =" PT2S "timeShiftBufferDepth =" PT10S "UTCTiming =” urn: mpeg: dash: utc: http-ntp: 2014 ”/>. It includes the time information that will allow the receiver to know when this flow started and what are currently accessible segments. FIG. 6c illustrates an example of a proposed container (“LivePeriod”) comprising the following types of data: type; availabili- tyStartTime; publishTime; minimumUpdatePeriod; minBufferTime; timeShiftBuf- ferDepth; UTCTiming, with sample values for each of these data types.

[0146] Those skilled in the art will understand that, although these examples and illustrations correspond to the standard of document ISO / IEC 23009-1, these examples and illustrations are not limiting, and the proposed method can be implemented in 'other frameworks, in particular within the framework of other standards, and / or using different formats and syntaxes.

[0147] FIG. 6d is a time diagram illustrating a dropout livel to live 2 then return to live 1 carried out according to one or more embodiments.

[0148] In the initial state, the manifest contains only one period corresponding to the primary live stream. When a splice out order arrives, the packager performs the following operations: Inserting an ‘emsg ’box in the last data segment of the main stream before the switchover date. This box will indicate to the DASH client that he must immediately reload the manifest. Removed the main live period from the manifesto and added the secondary live period with the xlink link. Resolving this xlink will allow the DASH client to obtain the information about the period (s) of the sub stream and begin decoding.

[0149] As the duration of the secondary live stream is not known, the DASH client continues to play this stream until it receives further information.

[0150] When a splice in order arrives, the packager performs the following operations:

Insertion of an emsg ’box in the last data segment of the secondary stream before the toggle date. This box will indicate to the DASH customer that he must immediately reload the manifest. Removal of the secondary live period from the manifesto and insertion of the primary live period. The DASH client already has the information about the primary stream and can therefore resume decoding.

[0151] This phase of returning to the main live requires that the splicing orders be synchronized between the main packager and the secondary.

[0152] Return to primary stream: In the case of a switch to a secondary live stream, the client must start reading as soon as the switch is signaled. However, if the client is shifted in time compared to the course of the live (time shift), it will wait until the end of the current period before switching. He will therefore not be able to access the start of the secondary live stream. This phenomenon is not acceptable, in particular for rockers of the alert type. This problem can be solved by inserting an 'emsg' box in the video segment preceding the toggle. This box will tell the DASH client that he must reload the manifest immediately, regardless of the value of the minimumUpdatePeriod attribute. At the same time, the packager will have removed the main live period from the manifest, leaving only the secondary live period with the xlink. When reloading the manifest, the DASH client will therefore have no choice but to start on the period of the secondary stream, regardless of its read position in the time shift buffer. The same mechanism will be used to force DASH clients to return to the main stream. The packager will insert an emsg box, remove the period of the secondary live stream from the manifesto and add a period corresponding to the main live stream.

[0153] Thus, the proposed method advantageously opens up the possibility of using xlink type links in a system using the DASH standard to switch from a first content distributed in dynamic mode to a second content also distributed in dynamic mode. . This makes it possible to obtain a new mode for switching from a first content distributed in dynamic mode to a second content also distributed in dynamic mode, while benefiting, within the framework of this shifting, from the advantages that this mode provides ( in particular in terms of continuity between successive periods, management of DRMs and management of authentication, as discussed above). These advantages may be lacking in other methods of switching from a first content distributed dynamically to a second content also distributed dynamically, for example methods based on a change of manifesto.

[0154] FIG. 7 illustrates an example of the architecture of a device for playing multimedia content distributed in dynamic mode for the implementation of the proposed method.

[0155] Referring to Figure 7, the device 500 comprises a controller 501, operably coupled to an input interface 502 and to a memory 504, which drives a multimedia content playback unit 503.

[0156] The input interface 502 is configured to receive from a content server, data segments (audio and / or video segments) corresponding to multimedia content distributed in dynamic mode, as well as sets of metadata corresponding to these contents.

[0157] The controller 501 is configured to drive the content reading unit

multimedia 503 for the implementation of one or more embodiments of the proposed method.

[0158] The device 500 may be a computer, a computer network, an electronic component, or another device comprising a processor operatively coupled to a memory, as well as, depending on the embodiment chosen, a unit. storage medium, and other associated hardware elements such as a network interface and a media drive for reading and writing to removable storage media (not shown in the figure). The removable storage medium can be, for example, a compact disc (CD), a digital video / versatile disc (DVD), a flash disc, a USB stick, etc. Depending on the embodiment, the memory, the data storage unit or the removable storage medium contains instructions which, when executed by the controller 501, cause this controller 501 to perform or control the interface parts of it. input 502, playback of multimedia contents 503 and / or data processing of the examples of implementation of the proposed method described herein. The controller 501 can be a component implementing a processor or a computing unit for the playback of multimedia contents according to the proposed method and the control of the units 502, 503 and 504 of the device 500.

[0159] In addition, the device 500 can be implemented in software form, such as

described above, or in hardware form, such as an application specific integrated circuit (ASIC), or in the form of a combination of hardware and software elements, such as for example a software program intended to be loaded and executed on a component FPGA (Field Programmable Gâte Array) type.

Industrial application

[0160] Depending on the embodiment chosen, certain acts, actions, events or functions of each of the methods described in this document may be carried out or occur in a different order from that in which they have been described, or may be added, merged or not to be done or not to happen, as the case may be. Further, in some embodiments, certain acts, actions or events are performed or occur concurrently and not sequentially.

[0161] Although described through a number of detailed exemplary embodiments, the proposed control method and the device for implementing an embodiment of the method include various variants, modifications and improvements which will appear. obviously to those skilled in the art, it being understood that these different variants, modifications and improvements form part of the scope of the invention, as defined by the claims which follow. In addition, different aspects and characteristics described above can be implemented together, or separately, or substituted for each other, and all the different combinations and sub-combinations of aspects and characteristics are part of the package. scope of the invention. In addition, some systems and equipment described above may not incorporate all of the modules and functions described for the preferred embodiments.

Claims

[Claim 1] Method for managing multimedia contents, comprising:

obtain a first set of content description metadata describing a first multimedia content distributed in the mode

dynamic; and

on reading from the first set of data metadata redirecting to a section of a second set of content description metadata, read from the section of the second set of metadata data relating to time synchronization for access to a second multimedia content distributed in dynamic mode.

[Claim 2] The method of claim 1, wherein the second set of content description metadata describes the second media content distributed dynamically.

[Claim 3] A method according to any one of the preceding claims, in which the data relating to a time synchronization for the access to the second multimedia content distributed in dynamic mode is read, in the second set of content description metadata, in a time slot description container relating to the second multimedia content.

[Claim 4] A method according to any preceding claim, wherein the data relating to time synchronization for access to the second media content distributed dynamically includes data indicating an availability timestamp of the second media content.

[Claim 5] A method according to any preceding claim, wherein the data relating to timing synchronization for access to the second media content distributed dynamically comprises data indicating accessibility information of segments of the second media content. .

[Claim 6] A method according to any preceding claim, wherein the data relating to a time synchronization for access to the second multimedia content distributed in dynamic mode corresponds to data relating to a time synchronization provided under a root element of the. second set of metadata.

[Claim 7] A method according to any preceding claim, wherein the data relating to a time synchronization for accessing the dynamically distributed second media content includes data indicating an availability timestamp of a first segment of the second content, data indicating a common duration used in defining bit rates associated with the second content, and data indicating a timestamp generating the second set of metadata and publishing it on a multimedia content distribution network.

[Claim 8] A method according to any preceding claim, wherein the first and second sets of metadata are manifests in "Dynamic adaptive streaming over HTTP" format,

DASH.

[Claim 9] A multimedia content playback device, comprising a processor and memory operably coupled to the processor, wherein the processor is configured to implement a method according to any of claims 1 to 8.

[Claim 10] A computer program, loadable into a memory associated with a processor, and comprising portions of code for implementing the steps of a method according to any one of claims 1 to 8 during the execution of said program by the processor.

[Claim 11] A set of data representing, for example by way of communication

pressure or encoding, a computer program according to claim 10.