METHOD FOR MANAGING THE TRANSMISSION OF MULTIMEDIA CONTENT AND DEVICE FOR PERFORMING THE SAFE METHOD

Description

Domaine et contexte de l'invention

[0001] The present invention relates to the field of data distribution on a telecommunications network. In particular, it relates to the distribution of multimedia content (audio and / or video, subtitles, data, etc.), and especially to real-time distribution.

[0002] The world of digital television distribution (or broadcast) has undergone significant changes in recent years. Traditional distribution, carried out dynamically via pay-TV operators (e.g., digital packages and / or Internet Service Providers (ISPs)) for linear television (ADSL (Asymmetric Digital Subscriber Line), Satellite, Cable, IPTV, Fiber, Digital Terrestrial Television (DTT), etc.), has been complemented by new audiovisual services such as Video On Demand (VOD) and Catch-Up TV (or Replay).

[0003] The design of increasingly powerful and mobile devices, the growing demand for location-independent content consumption ("TV everywhere"), and the development of network infrastructures offering ever-increasing bandwidth have led to the emergence of a new market that does not require ownership of the access network to users, called Over-The-Top (OTT) services. The OTT market operates on so-called unmanaged networks (i.e., with unguaranteed bandwidth and Quality of Service (QoS)). These multi-screen OTT services are provided by distribution / redistribution companies such as television broadcasters and telecom operators.

[0004] Distribution infrastructures are thus now doubled, one for traditional broadcast and one (at least) for OTT distribution.

[0005] 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), and MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH). All these protocols are based on the concept of HTTP Adaptive Streaming (HAS).

[0006] Multi-screen content distribution typically uses a video distribution headend comprising a video encoding unit that receives input content to be encoded and delivers encoded streams, known as "elementary streams," to a formatting unit (sometimes called a "packager"). Input content is encoded according to a plurality of encoding profiles (a profile being defined, for example, with codec, resolution, and bitrate parameters).

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

[0008] These manifests and associated segments are provided by the formatting unit to a content server, then stored on content delivery networks, called "CDNs" (from the English "Content Delivery Network"), providing caching capabilities that improve the quality of services, and minimize access times and latency for viewing content by reading terminals.

[0009] A video playback terminal for content distributed in dynamic mode (for example configured within a user device such as a smartphone, tablet or any other type of computer), in other words dynamic or "live" video content (as opposed to static content, such as VOD content), will typically be configured to play this content using the information contained in the manifest associated with the content.

[0010] The implementation of "live" multimedia content playback, that is, content distributed dynamically, based on the associated manifest, presents limitations, however, with regard to certain new use cases involving switching from one live content item currently being played to a second live content item. Indeed, existing mechanisms for switching from one multimedia content item to another do not satisfactorily handle these new use cases. The document entitled "Technologies under Consideration for DASH" 123. MPEG Meeting, No. 17812, XP030197563, describes various technologies considered for the DASH protocol specification for chaining MPDs for accessing a second multimedia content item (Mid-Roll Ads). The document "[CAPCO] Proposal: MPD chaining for pre / mid rolls", by Iraj Sodagar et al., 113.MPEG Meeting describes a proposed method for chaining MPDs to handle "Pre-Roll" and "Mid-Roll" use cases. The document "eDASH: Server-based Ad Insertion based on DASH-IF," from Qualcomm Incorporated, vol. SA WG4, no. 1, Bratislava, Slovakia, describes an ad insertion method using DASH technology.

[0011] The invention aims to improve the situation.

[0012] According to a first aspect, a multimedia content management method is proposed as defined by the claims. The method comprises, in one or more embodiments: obtaining a first set of content description metadata describing a first multimedia content distributed in dynamic mode; and upon reading in the first set of metadata redirection data 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 distributed in dynamic mode, the first and second sets of metadata being manifests in "Dynamic adaptive streaming over HTTP" (Hypertext Transfer Protocol), DASH format.

[0013] The proposed method advantageously allows the use of redirection data to switch from a first multimedia content distributed in dynamic mode to a second multimedia content distributed in dynamic mode, based on a single set of content description metadata in which the redirection data is inserted.

[0014] For example, within the framework of the third edition of the ISO / IEC 23009-1 specification ("Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats"), which allows the use of redirection data in the form of an "xlink" insertable into a time-slot container of a manifest (which corresponds to a set of content description metadata), an xlink cannot be used to perform a read switch from one dynamically distributed piece of content to a second dynamically distributed piece of content. The proposed method modifies the use of xlinks by inserting into the resolution of such a link a read of time-synchronization data for accessing the second dynamically distributed piece of content.

[0015] Thus, the proposed method advantageously allows the insertion into the resolution of redirection data, that is to say, into obtaining the data to which the redirection gives access, of access to time synchronization data for access to the second content distributed in dynamic mode.

[0016] This allows, in the case of xlink links specified in the DASH standard, to considerably broaden 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 the manifest during reading for access to the contents.

[0017] The proposed method is particularly well-suited, though not exclusively, for the playback, by a terminal playback device, of multimedia content distributed live according to a scheme such as MPEG DASH, HLS, HDS, MSS, or HAS. However, it is also suitable for the playback of multimedia content distributed live according to any scheme in which this playback is performed using sets of content description metadata corresponding to live multimedia content.

[0018] The proposed method can advantageously be implemented in any device configured for the playback of multimedia content, based on a set of metadata describing multimedia content, for example in accordance with the MPEG DASH, HLS, HDS, MSS, or HAS standards, such as, but not limited to, 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 time synchronization for access to the second multimedia content distributed in dynamic mode can be read, in the second set of content description metadata, in a time interval description container relating to the second multimedia content.

[0021] In one or more embodiments, the data relating to a time synchronization for access to the second multimedia content distributed in dynamic mode may include data indicating a timestamp of availability of the second multimedia content.

[0022] In one or more embodiments, the data relating to time synchronization for access to the second multimedia content distributed in dynamic mode may include data indicating accessibility information for segments of the second multimedia content.

[0023] In one or more embodiments, the time synchronization data for accessing the second multimedia content distributed in dynamic mode may correspond, in whole or in part, to time synchronization data provided under a root element of the second metadata set.

[0024] In one or more embodiments, the time synchronization data for accessing the second dynamically distributed media content may include data indicating the availability timestamp of the first segment of the second content, data indicating a common duration used in defining bitrates associated with the second content, and data indicating the generation timestamp of the second metadata set and its publication on a media content distribution network. In one or more embodiments, this data may further include one or more of the following: data indicating a distribution type for the second content, data indicating the generation timestamp of the oldest still-available segment of the second content, clock data, and data indicating the duration of a smaller time-shift buffer used for the second content.

[0025] According to a second aspect, a multimedia content reading device is proposed, comprising a processor and a memory operationally coupled to the processor, in which the processor is configured for the implementation of the proposed process according to one or more embodiments.

[0026] According to another aspect, a multimedia content management process is proposed, comprising: obtaining a first set of content description metadata describing a first multimedia content distributed 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 access to a second multimedia content distributed in dynamic mode corresponding to the second set of content description metadata.

[0027] According to another aspect, a multimedia content management process is proposed, 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 a time synchronization for access to a second multimedia content distributed in dynamic mode corresponding to the second set of content description metadata.

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

[0029] According to another aspect, a manifest in DASH format is proposed describing multimedia content distributed in dynamic mode, including, in a container of type "Period", data relating to a temporal synchronization for access to the multimedia content.

[0030] According to another aspect, a computer program is proposed, which can be loaded into a memory associated with a processor, and which includes portions of code for the implementation of the proposed process 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 means of compression or encoding, said computer program.

[0031] Another aspect concerns 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 to, when the said one or more programs are executed by a computer comprising a processing unit operationally coupled to memory means and an input / output interface module, lead the computer to manage multimedia content according to one or more embodiments of the proposed process. Brève description des dessins

[0032] Other features and advantages of the present invention will become apparent from the following description of non-limiting exemplary embodiments, with reference to the accompanying drawings, in which: Fig. 1 [ fig.1 ] illustrates an example of a distribution infrastructure according to one or more embodiments. Fig. 2a [ fig.2a ] illustrates an example of a set of content description metadata (or manifest). Fig. 2b [ fig.2b ] illustrates an example of a set of content description metadata (or manifest). Fig. 3 [ fig.3 ] presents the method for calculating the segment to be downloaded in the case of multimedia content distributed in dynamic mode. Fig. 4 [ fig.4 ] illustrates the proposed process according to one or more embodiments. Fig. 5 [ fig.5 ] illustrates the proposed process according to one or more embodiments. Fig. 6a [ fig.6a ] illustrates an example of a set of content description metadata (or manifest). Fig. 6b [ fig.6b ] illustrates an example of a set of content description metadata (or manifest). Fig. 6c [ fig.6c ] illustrates an example of a set of content description metadata (or manifest). Fig. 6d [ fig.6d ] is a time diagram illustrating a dropout from one live piece of content to a second live piece of content. Fig. 7 [ fig.7 ] illustrates an example of device architecture for implementing the proposed process according to one or more embodiments. Description détaillée

[0033] In the detailed description of process embodiments that follows, numerous specific details are presented to provide a more complete understanding. Nevertheless, those skilled in the art can recognize that some embodiments can be implemented without these specific details. In other cases, well-known features are not described in detail to avoid unnecessarily complicating the description.

[0034] This 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, engines, modules, platforms, units, and diagrams described can be implemented in hardware, software (including embedded software (“firmware”), or “middleware”), microcode, or any combination thereof.In the case of implementation in software form, functions, motors, units, modules and / or diagram illustrations may be implemented by computer program instructions or software code, which may be stored or transmitted on a computer-readable medium, including non-transient media, or media loaded into the memory of a generic, specific computer, or any other programmable data processing apparatus or device to produce a machine, such that the computer program instructions or software code executed on the computer or the programmable data processing apparatus or device constitute means of implementing these functions.

[0035] The embodiments of a computer-readable medium include, but are not limited to, computer storage media and communication media, including any medium that facilitates the transfer of a computer program from one location to another. "Computer storage media" means 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 (e.g., USB flash drives, 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”), SSD (“Solid State Drive”) type memories, and any other form of media usable for transporting, storing, or remembering data or data structures that can be read by a computer processor.

[0036] Furthermore, various forms of computer-readable media can transmit or carry instructions to a computer, such as a router, gateway, server, or any data transmission equipment, whether wired (via coaxial cable, fiber optic cable, telephone lines, DSL cable, or Ethernet cable), wireless (via infrared, radio, cellular, microwave), or virtualized transmission equipment (virtual router, virtual gateway, virtual tunnel endpoint, virtual firewall). The instructions may, depending on the embodiment, include code in any computer programming language or computer program element, such as, without limitation, assembly language, 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.

[0037] Furthermore, the terms "notably", "for example", "example", "typically" are used in this description to refer to examples or illustrations of non-limiting embodiments, which do not necessarily correspond to preferred or advantageous embodiments compared to other aspects or possible embodiments.

[0038] In this description, "server" or "platform" means any service point (virtualized or not) or device that performs data processing, one or more databases, and / or data communication functions. For example, and without limitation, the term "server" or "platform" may refer to a physical processor operationally coupled with associated communication, database, and data storage functions, or to a network, group, set, or complex of processors and associated data storage and networking equipment, as well as an operating system and one or more database systems and application software supporting the services and functions provided by the server.A computing device can be configured to send and receive signals via wireless and / or wired transmission networks, or it can be configured for data or signal processing and / or storage, and thus can function as a server. Examples of equipment configured to operate as a server include, but are not limited to, rack-mounted dedicated servers, desktop computers, laptops, service gateways (sometimes called "boxes" or "home gateways"), set-top boxes, and integrated devices combining various functionalities, such as two or more of the functionalities mentioned above. Servers can vary greatly in their configuration or capabilities, but a server will typically include one or more central processing units (CPUs) and memory.A server may also include one or more mass storage devices, one or more power supplies, one or more wireless and / or wired network interfaces, one or more input / output interfaces, one or more operating systems, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, or an equivalent.

[0039] Multimedia content, as used in this description, means any audio and / or video content, subtitles, data, audiovisual content, music, sound, image and interactive graphical interface, and any combination of these types of content.

[0040] The terms "network" and "communication network" as used in this description refer to one or more data links that can couple or connect equipment, possibly virtualized, to enable the transport of electronic 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 may also include mass storage for storing data, such as a NAS (network attached storage), a SAN (storage area network), or any other form of media readable by a computer or machine, for example.A network can include, in whole or in part, the Internet, one or more local area networks (LANs), one or more wide area networks (WANs), wired connections, wireless connections, cellular connections, or any combination of these different networks. Similarly, subnets can 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 protocols interoperable. For example, a router can be used to provide a communication or data link between two LANs that would otherwise be separate and independent.

[0041] The terms "operationally coupled," "coupled," "mounted," "connected," and their various forms used in this description refer to couplings, connections, and mountings, which may be direct or indirect, and include, in particular, connections between electronic equipment or between portions of such equipment that enable operations and functions as described herein. Furthermore, the terms "connected" and "coupled" are not limited to physical or mechanical connections or couplings. For example, operational coupling may include one or more wired and / or wireless connections between two or more pieces of equipment that enable simplex and / or duplex communication links between the equipment or portions thereof.In another example, an operational coupling or connection may include a wired and / or wireless link coupling to enable data communications between a server in the proposed system and other equipment in the system.

[0042] The terms "application" or "application program" (AP) and their variants ("app," "webapp," etc.) as used in this description refer to any tool that functions and is operated by means of a computer to provide or perform one or more functions or tasks 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) may be generated and displayed on a screen of the user's equipment, or an audio user interface may be provided to the user using a speaker, headphones, or audio output.

[0043] The term “multimedia content” as used in this description refers to any audio and / or video or audiovisual content.

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

[0045] In this description, the term "live content" refers to content, such as multimedia content, distributed dynamically (as opposed to static distribution) via an OTT distribution model. Live content is typically generated by a television channel or other television media outlet and may also be broadcast over a multimedia content delivery network, in addition to being made available on content servers within an OTT distribution system.

[0046] In this description, the terms "terminal", "user equipment", "player", "playback device", "playback terminal" and "video player" are used interchangeably to refer to any type of device, implemented by one or more software programs, one or more hardware programs, or a combination of one or more software programs and one or more hardware programs, configured to use multimedia content distributed according to a multi-screen distribution protocol, including loading and playing 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, including loading content from a server and playing content.

[0047] There figure 1 illustrates an example of a multimedia content distribution system architecture (1), in which the proposed method can be implemented. figure 1 shows a video distribution network headend (2) comprising a video encoding unit (4) which receives input content to be encoded ("contribution") (3), and delivers encoded streams, called "elementary streams," to a packaging unit (5) ("packager"). As illustrated in the figure 1 Incoming content is encoded using multiple encoding profiles (a profile being defined, for example, by codec, resolution, and bitrate parameters). Using multiple encoding profiles offers at least two advantages: First, multiple profiles allow playback devices with different characteristics (supported codecs, screen resolution, decoding power) to be addressed. Furthermore, it allows the video players on these devices to adapt to the available network bandwidth. Indeed, a client's player (on a device) can be configured to attempt to use the encoding profile corresponding to the highest bitrate, based on its continuous bandwidth measurements.

[0048] The encoded streams (elementary streams) delivered by the video encoding unit (4) to the formatting unit are split into two sequences of successive segments, audio and video respectively, which are generally of fixed duration (typically a few seconds) by the formatting unit (5), whose format depends on the chosen protocol (e.g., MPEG2-TS, MP4, etc.). For each piece of content, a set of metadata relating to the 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.

[0049] These manifests and associated segments are provided by the formatting unit (5) to a content server (6) ("Origin Server" on the figure 1 ), then stored on content delivery 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.

[0050] The content stored on the CDN servers (8a, 8b) is accessible for reading by user terminals (10a, 10b, 10c) via a service platform (7) for content distribution. Clients installed on the terminals (10a, 10b, 10c) can access the content stored on the CDN servers via one or more data communication networks, such as the Internet (9), as illustrated in the figure.

[0051] There figure 2a illustrates an example of XML file content corresponding to a manifest using the DASH (or MPEG-DASH) format. A manifest of this type presents a tree of nested XML containers, as illustrated by the 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 see that the proposed methods are not limited to a particular type or format of manifest (or set of metadata describing multimedia content(s)), and that they apply to all types of manifest, such as manifests using other OTT distribution protocols and formats, such as the HLS, MSS and HDS protocols and formats mentioned above.

[0052] The DASH manifesto illustrated on the figure 2a presents a hierarchical structure organized according to the following tree: 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 sometimes being called "child" elements).

[0053] The root "MPD" can, in addition to "child" elements, define attribute values, among which the following attributes are related to the distribution of live content: The "type" attribute defines the type of content distribution: "static" for content distributed in static mode (typically content distributed via a Video On Demand (VOD) service) and "dynamic" for content distributed in dynamic mode.

[0054] The "AvailabilityStartTime" attribute, related to the dynamic distribution mode, defines the date (for example, in Coordinated Universal Time (UTC) format) when the first generated segment for the current service becomes available. This information can be used to indicate the service's start time, so that a reading terminal can use it as a temporal anchor point for the service's commencement.

[0055] The "PublishTime" attribute indicates the generation date of the manifest and its publication on the CDN. This information allows for the recording of different versions of the same manifest corresponding to successive publications, in order to detect changes that have occurred between publications.

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

[0057] The "MinimumUpdatePeriod" attribute defines the shortest period between potential changes in the MPD. The value of this attribute can be used by the content reading terminal to configure a frequency at which it downloads the manifest, knowing that the manifest will be updated by the formatting unit at least at the frequency specified by this attribute.

[0058] The "MinBufferTime" attribute, mandatory in the example format illustrated by the Figure 2a , defines a common duration used in defining the performance rates.

[0059] The "TimeShiftBufferDepth" attribute defines the duration of the smallest time-shift buffer for all manifest representations, ensuring segment availability for dynamically distributed content. Its value indicates the period in the past for which the manifest-associated content, distributed dynamically, is available on the CDN server. This value could, for example, be 1 minute, in which case the player could rewind to a minute of "live" content, or retrieve a minute of live content if the user pauses the live content.

[0060] The "SuggestedPresentationDelay" attribute defines a fixed time delay that can be applied when presenting each access unit. This setting allows you to align as closely as possible with the endpoint of the live content, ensuring that all devices playing the same live content will read it from the same point. For example, you can configure playback to rewind 4 seconds to provide a safety margin relative to the live content flow.

[0061] The "UTCTTiming" attribute provides a common clock between the formatting unit and the playback terminal (or video player). It allows the terminal to be instructed on how to retrieve a clock synchronized with the content server.

[0062] "Child" elements, in the form of containers possibly nested within each other, can also be included in the manifest to specify the files accessible through the manifest. With reference to the figure 2a These "child" elements can be:

[0063] A "Period" type element describing a time interval, bounded or unbounded. One or more attributes can be provided for a "Period" type element, including a period identification attribute ("id") ("id="P0"" on the figure 2a ), a period start time attribute ('start="PTOS"' on the figure 2a ), and a period duration attribute ("duration") (not present for an open period, i.e., one not yet finished). The value of the period start time attribute (0 seconds in the example shown on the figure 2a (can be combined with the value of the "availabilityStartTime" element described above)

[0064] Each child element of type "Period" can itself contain child elements. For example, as illustrated on the figure 2a , an element of type “Period” can contain two child elements of type “AdaptationSet” each corresponding to a type of content.

[0065] The "AdaptationSet" element is a container that allows you to describe available content based on its type. It allows you to group elements related to the same component of multimedia content—audio, video, or subtitles—but encoded with different parameters (bitrates, resolutions, frame rates, sample rates). In the example of the figure 2a Only one encoding profile is available, and this profile is described for its video component (contentType="video" id="0" maxFrameRate="25" maxHeight="1080" maxWidth="1920" mimeType="video / mp4" minFrameRate="25" minHeight="1080" minWidth="1920" par="16:9" segmentAlignment="true" startWithSAP="1") and for its audio component (contentType="audio" id="1" lang="und" mimeType="audio / mp4" segmentAlignment="true" startWithSAP="1"). A video player can thus, for example, quickly obtain the video encoding profile settings used for encoding the content described in the manifest shown on the figure 2a : bandwidth, video encoder settings, frame rate, resolution, image format, etc. ("bandwidth="4000000" codecs="hev1.2.4.L120.90" frameRate="25" height=" 1080" id="v1" sar=" 1:1" width="1920"").

[0066] Encoding parameters can be provided by the "Representation" element, which allows for a precise description of the encoding and access parameters for a component of the media.

[0067] There figure 3 illustrates an example of a method for playing live content using a video playback client (or video player). The illustrated method uses some of the information described above for the example manifest shown on the figure 2a to determine the data segment to download for each "AdaptationSet" of the current period, and thus allow the client to latch onto the content to read.

[0068] The playback of live content in MPEG-DASH format is primarily linear. Upon connecting to the content server, the client first retrieves the manifest containing information specific to the dynamically distributed ("live") content, then begins playback at the point in the content corresponding to the current time (in order to follow a real-time (or live) event). To do this, it determines the current period by calculating the time elapsed since the "availabilityStartTime" value indicated in the manifest, and then determines the number of the "live" segment within that period using the same method.

[0069] With reference to the figure 3 In one or more embodiments, the client obtains (50) a manifest corresponding to the live content to be read, then synchronizes (51) (52) with a multimedia content server via the value of the "UTCtiming" attribute indicated in the manifest.

[0070] 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") can be applied (54) to the transmission of the media content to allow the encoder time to encode the segments, which leads to the determination of a time fc() defined by fe() - PresentationTimeOffset. Finally, depending on the segment size ("segment duration") defined in the manifest, and a timescale parameter ("TimeScale"), an index (57) fi() or a timestamp (56) ("TimeStamp") ft() of the current time segment can be calculated, depending on the segment type (55).From this information, the client can obtain (58) a download address (for example, a URL (Uniform Resource Locator)), and then download the current-hour segment of the multimedia content. An index of the current-hour segment can, for example, be obtained by dividing the value of fc() by the segment duration divided by the timescale value: fi()=fc() / (segment duration / timescale). A timestamp of the current-hour segment can, for example, be obtained by dividing the value of fc() by the timescale value: ft()=fc() / timescale.

[0071] The values ​​described above are provided by the content provider to the client via the manifest. The content provider can also influence client behavior through means other than the manifest that the client downloads, notably by inserting signaling into a data segment. For example, inserting a specific marker (such as a "box") identified by a predetermined tag allows the provider to communicate control messages to the client. For instance, inserting an "emsg" box into a data segment can instruct the client to immediately reload the manifest.Thus, a client configured to play an MP4 or MPEG2 TS (Transport Stream) file will parse this file (in its tree structure) to detect all the information it contains, including manifest load request signaling information (for example, signaled by "emsg"). This makes it possible to signal an unexpected event that must be addressed as soon as possible, bypassing the "minimumUpdatePeriod" attribute, which is better suited for incremental manifest updates.

[0072] Several scenarios, however, can disrupt the dynamic event dissemination logic described above and illustrated by the figure 3 For example, when a switch to multimedia content other than the one currently being played (corresponding to a so-called "main" manifest) is desired. These interruptions to live multimedia playback can, for example, correspond to the insertion of targeted advertisements, real-time events such as a regional broadcast interruption, or the broadcast of an alert message.

[0073] The context surrounding the scenario of targeted ad insertion is as follows: During an ad break in dynamically distributed content ("live" content), default ads are present in the initial data stream, corresponding to the live content currently being played. The content provider can decide to redirect customers to targeted ads based on their respective profiles. To do this, the current period specified in the current manifest (corresponding to the live content being played) can be closed, and a new period equal in duration to that of the initial ad can be inserted into the current manifest as a time interval description container ("Period" in the case of a DASH manifest container).

[0074] This time-interval description container can contain redirection data (for example, signaled in an XML file by a redirection link of type "xlink," for "XML Linking Language," a type specified in the W3C Recommendation "W3C XLINK XML Linking Language (XLink) Version 1.1, W3C Recommendation") to an ad server. Based on the client's user profile, the ad server will return a new manifest allowing access to ads tailored to that user. The client will read the content described by the time-interval description container ("Period") 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 advertising period will also have ended, and a new live period will be inserted as another time-interval description container.

[0075] The scenario of regional broadcasts can occur when a television channel broadcasts national news programs in real time, which then switch to regional news programs at fixed times, as is the case with France 3. This use case is similar to that of commercials because the duration of the regional break is known in advance. However, one can imagine regional breaks of varying lengths depending on the region.

[0076] Regarding alert broadcasting scenarios, regulations provide for mechanisms that allow alert messages to be disseminated by interrupting ongoing programs. These messages can be pre-recorded and therefore of known duration, or generated in real time. In the latter case, the duration of the interruption is not known in advance.

[0077] However, it turns out that scenarios involving switching from one live content to a second live content without knowing the duration of the interruption in playback of the first live content cannot be properly managed, as explained below.

[0078] Indeed, these switches between multimedia content are triggered by the use of stream switching commands, called " splicing ", originating from equipment located upstream of the audio / video encoder. Upon receiving these commands, the formatting unit modifies the current manifest (corresponding to the live content being played) to signal a change to the client.

[0079] Among these flow switching orders, the switching order to another flow (" splice out " indicates to the customer that it must switch from a primary flow to a secondary flow, and the return switchover order (" splice in " indicates to the customer that they must return to the primary flow.

[0080] The switchover from a primary live stream to a secondary live stream (both streams being distributed dynamically), known as "switchover" live-live " presents disadvantages which are detailed below.

[0081] The DASH standard includes a mechanism for switching between two live streams, called manifest chaining. This mechanism requires the DASH client to switch from one live stream to another to a new manifest, based on the first. This forces the player to switch to a secondary manifest, different from the manifest currently being used by the client (called the "primary" or "current" manifest), to implement the switch from the first live stream, corresponding to the primary manifest, to the second live stream, which corresponds to the secondary manifest.However, switching from a first manifest to a second manifest 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 DRM (Digital Rights Management) management (as the manifest URL changes during the switchover, the DASH client would have to store the original period in order to determine that the same DRM configuration can be used, which is quite restrictive from the DASH client's point of view), and from the point of view of managing CDN server authentication tokens (as the manifest URL changes during the switchover, the DASH client would have to store the original period and the URL after redirection in order to determine that the same URL is used and therefore not repeat the authentication step with the CDN, which is quite restrictive from the DASH client's point of view).In addition, during this switchover the reader loses knowledge of the primary manifest, making it complicated, or even impossible, to return to the first live stream at the end of the switchover period (for example at the end of the broadcast of the alert in the case of a broadcast of an alert mentioned above).

[0082] It is possible to use redirection data (to data corresponding to the second piece of content) inserted in the manifest to manage a switch from one piece of content to another. This data can be used, for example, under an element defining a time interval (not necessarily bounded) relative to the second piece of content. In the case of a manifest in DASH format, a redirection link of type "xlink" can thus be inserted into a container of type "Period", as illustrated in the example. 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 an xlink type redirection link in a manifest in DASH format.

[0083] There figure 2b This illustrates an example of a manifest in DASH format after the insertion of a period pointing to other content in the form of a "Period" container containing an xlink pointing to another manifest corresponding to that other content (specifically, in that it contains information allowing access to that other content). The manifest illustrated in the figure 2b comprises three periods, each in the form of a container of type "Period": a first period "P0", which corresponds to a period of first live content, which starts at time 0 and lasts 2 minutes and 18 seconds: <period id="P0" start="PT0S" duration="PT2M18S">"

[0084] After 2 minutes and 18 seconds, a splice command is received and the manifest is updated accordingly: the current period is closed and the duration attribute ("duration="PT2M18S"") is added to the manifest. A second period ("P1") corresponding to a second piece of content, with a duration of 30 seconds (corresponding, for example, to the duration of a second piece of content in one or more advertisements), begins at time T0 + the duration of period P0 (2 minutes and 18 seconds) ("start="PT138S"). The xlink (xlink:actuate="onLoad" xlink:href="http: / / ..." xmlns:xlink=http: / / www.w3.org / 1999 / xlink in the example shown on the figure 2b ), inserted as an additional attribute of the "Period" container P1, allows access to this second content: " <period id="P1" start="PT138S" duration="PT30S" xlink:actuate="onLoad" xlink:href="http: / / ..." xmlns:xlink="http: / / www.w3.org / 1999 / xlink">Upon reading this xlink, the client will resolve the link, that is, access the URL indicated by the link (in the example illustrated in the property "xlink:href="http: / / ..." xmlns:xlink=http: / / www.w3.org / 1999 / xlink") to download a second manifest containing data relating to access to the second content, then extract one or more periods from this second manifest, in the form of one or more "Period" containers. Thus, the client will use the redirection to retrieve information relating to this new period P1 via the information accessible through the xlink.

[0085] A third period (container "Period" "P2") corresponds to the return to the initial content following the interruption of period P1. In the example of the figure 2b This period corresponds to the first live content and therefore has no specified duration: <period id="P2" start="PT168S">"

[0086] However, a problem has been identified that would prevent the proper execution of a live-to-live failover (from a first live piece of content associated with a first manifest to a second live piece of content associated with a second manifest) that uses a redirection mechanism (for example, an xlink redirection link) to signal the failover target as specified in the ISO / IEC 23009-1 specification mentioned above. Indeed, the time synchronization information required by the client to obtain the segments of the second live piece of content will be present at the root element of the second manifest (MPD element in the DASH format), as described above in relation to the figure 2a And 2b , but not at the level of each container defining a time interval (not necessarily bounded) relative to the second content. The ISO / IEC 23009-1 standard specifies that resolving an xlink inserted in a time interval description container (defining a period), that is, downloading the manifest to the address indicated by the xlink and extracting the period(s) (time interval containers) from this manifest, must return not the complete manifest, but only the period(s) concerned (several periods of the remote manifest (second manifest) can be substituted by resolving the xlink for a period of the initial manifest (first manifest)).Thus, resolving an xlink redirection inserted within a Period container, as specified in ISO / IEC 23009-1, does not allow the client to obtain information contained in the remote manifest to which the link points, other than the information contained within a Period container of that remote manifest. In particular, the standard does not allow the client to obtain elements specified by the standard as being included under the root (MPD) 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 (e.g. 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 (e.g. using the process described above in connection with the . figure 3 ).

[0087] Also, as currently specified, xlinks redirect links can handle the case of a dropout from a first live piece of content to a second non-live piece of content (for example, a VOD), and then back to live content—a live->VOD->live switchover sequence—but not the case of a live-to-live switchover, which involves a dropout from a first live piece of content to a second live piece of content, and possibly back to the first live piece of content. This is because resolving an xlink redirect link allows the DASH client to obtain one or more periods (a time interval description container) of the manifest, and not a complete manifest.This doesn't pose a problem when the failover targets a second non-live content stream, for which the client doesn't need data to determine when the corresponding stream started in order to identify available segments, since the start and duration of the non-live content are predetermined. However, the timing information needed to calculate the progress of the second live content stream, which, as discussed above, is only present at the root level (MPD) of the second manifest and not at the level of the elements within that manifest that define time periods, is not accessible to the client when the failover is performed.

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

[0089] In one or more embodiments, the device configured for implementing the method can be configured to obtain a first set of content description metadata describing a first dynamically distributed multimedia content item (for example, for a DASH client, a first manifest in DASH protocol format, for example as an XML file). The first set of metadata can describe a first dynamically distributed multimedia content item, for example, through metadata relating to a first dynamically distributed multimedia content item included in the first set.

[0090] The device can also be configured to read the first set of metadata, and, upon reading in the first set of metadata of redirection data to a section of a second set of content description metadata, to read (61) in the section of the second set of metadata of time synchronization data for access to a second dynamically distributed multimedia content.

[0091] Typically, the second set of content description metadata will correspond to the second dynamically distributed media item. For example, this second set might describe the second item, perhaps through metadata related to that item included in the second set.

[0092] Thus, the redirection data used in a first manifest allows a device, while reading this first manifest, to obtain the data contained in a specific section of a second manifest, while reading the first manifest, that is, without changing the manifest currently being read.

[0093] This ability to retrieve data from another manifest, without switching manifests during playback, offers several advantages: From a continuity perspective, since the manifest remains the same, only the content of the failover period is replaced. This allows for seamless period tracking. From a DRM management perspective, since the manifest URL remains the same during the failover, the player can optimize its DRM configuration when returning to the main stream. From a CDN authentication token management perspective, since the manifest URL remains the same during the failover, the player can continue using the same CDN authentication token when returning to the main stream.

[0094] It is therefore particularly interesting to use redirection data to switch from a first piece of content to a second piece of content, including in the case where the first and second pieces of content are distributed dynamically (case where the first piece of content is live content, and the second piece of content is also live content).

[0095] In one or more embodiments, the data relating to a time synchronization for access to the second multimedia content distributed in dynamic mode are read, in the second set of content description metadata, in a time interval description container relating to the second multimedia content.

[0096] In one or more embodiments, the time synchronization data for accessing the second multimedia content distributed in dynamic mode includes data indicating a timestamp of availability of the second multimedia content.

[0097] In one or more embodiments, the time synchronization data for accessing the second multimedia content distributed in dynamic mode includes data indicating accessibility information for segments of the second multimedia content.

[0098] In one or more embodiments, the time synchronization data for accessing the second multimedia content distributed in dynamic mode corresponds, in whole or in part, to time synchronization data provided under a root element of the second set of metadata.

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

[0100] As explained above, switching from one piece of content to another can be managed at the level of a first manifest for the first piece of content (currently being played) by using a redirect link to a second manifest for the second piece of content, for example, indicated by an "xlink" redirect link for the DASH format. Live-to-live switching, in cases where the first and second pieces of content are distributed dynamically, can therefore occur without changing the manifest.

[0101] As specified by ISO / IEC 23009-1, 3rd edition, a redirect link to a second manifest of type xlink points to a section of that second manifest, not to the entire second manifest. Thus, a client resolving an xlink embedded in a 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) and then downloads the section of the second manifest relevant to the "Period," that is, the time interval defined in the first manifest. Therefore, the client downloads into the second manifest information contained in a time interval description container indicated by the redirect link, which corresponds to the time interval of the first manifest's container that includes the redirect link (e.g., xlink).

[0102] Since the time synchronization information required to access the second piece of content for the given time interval is only available at the root of the second manifest, which is not read by the client when resolving an xlink, in one or more embodiments, it is proposed to include time synchronization information for accessing the second piece of content in the time interval description container of the second manifest (which the client reads when resolving the redirect link). A live switchover from the first dynamically distributed multimedia piece of content to the second dynamically distributed multimedia piece of content can thus be advantageously performed using a redirect link, particularly within the framework of the ISO / IEC 23009-1 3rd edition standard, using an xlink redirect.

[0103] In embodiments using a redirection mechanism to a second dynamically distributed multimedia content, the device, after processing the first set of metadata, can read redirection data to a section of a second multimedia content description metadata set for accessing the data of a second dynamically distributed multimedia content. The device can be configured to, upon reading this redirection data, read from the section of the second multimedia content description metadata set data relating to time synchronization for accessing the second dynamically distributed multimedia content.This time synchronization data can be advantageously used by the device for accessing the second live content, thus compensating for the lack of timing information, in particular allowing the calculation of the progress of the second live content, at the level of the time interval description container (of the element (“Period”)) of the second set of metadata, container to which a redirection link of type xlink inserted in a time interval description container of the first set will point (as specified by the ISO / IEC 23009-1 3rd edition standard).

[0104] Thus, the proposed method advantageously allows, within the framework of the ISO / IEC 23009-1 standard, the use of an xlink type redirection link to perform a live live switchover, that is to say a switchover in reading from a first multimedia content distributed in dynamic mode to a second multimedia content distributed in dynamic mode, by inserting into a time interval description container of a second manifest which the client will read when resolving an xlink inserted in a time interval description container of a first manifest, time synchronization data for access to the second content distributed in dynamic mode.

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

[0106] In one or more embodiments, time-synchronization data for accessing the second dynamically distributed multimedia content may be inserted into a section of the second multimedia content description metadata set to which the redirection link inserted in the first metadata set points, such that this data is read (as data from the second section) when the link is resolved by a device reading the first metadata set. In one or more embodiments, the section of the second multimedia content description metadata set into which time-synchronization data for accessing the second dynamically distributed multimedia content is inserted corresponds to a time-interval description container for the second multimedia content.This could be, for example, a container corresponding to the attribute or element "Period" (described above) in a manifest of a format specified by the ISO / IEC 23009-1 standard. Thus, this data can be advantageously taken into account during a linear reading by the device of the time interval description container of the second manifest, upon reading a redirection information inserted in a time interval description container of the first manifest.

[0107] In one or more embodiments, the timing data inserted in the second manifest section can be grouped within a specific container, for example, named "LivePeriod", and identified in the manifest by corresponding tags ("LivePeriod" for the beginning 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 the figure 6C .

[0108] In one or more embodiments, the time synchronization data for accessing the second dynamically distributed media content may include data indicating the availability timestamp of the second media content. For example, this data may include time synchronization information that allows the client to know when the live stream corresponding to the second content began.

[0109] In one or more embodiments, the time synchronization data for accessing the second dynamically distributed media content may include data indicating the accessibility of segments of the second media content. For example, this data may include time synchronization information that allows the client to know which segments of the second content are currently accessible.

[0110] In one or more embodiments, the time-synchronization data types for accessing the second dynamically distributed multimedia content may correspond to at least some of the time-synchronization data types provided under a root element of the second metadata set.

[0111] For example, the syntax of DASH manifests can be enriched by inserting a copy of the time information needed by the DASH client to hook into the current stream, which is provided at the root of the second manifest, into a new container (or element) added at the level of the time interval description element (container) for the second live content.

[0112] In one or more embodiments, the time-synchronization data for accessing the second dynamically distributed media content may include data indicating a type of the second content, and at least one of the following: data indicating an availability timestamp of a first segment of the second content, data indicating a generation timestamp of the oldest still available segment of the second content, and data indicating a common duration used in defining bitrates associated with the second content, clock data, and data indicating the duration of a smaller time-shift buffer used for the second content.

[0113] For example, using the DASH format, a new element (for example, named "LivePeriod") can be added to the "Period" element, containing time information that allows the receiver to know when the stream started and which segments are currently accessible. In one embodiment, the new "LivePeriod" element could contain elements from among "type", "availabilityStartTime", "publishTime", "availabilityEndTime", "minimumUpdatePeriod", "minBufferTime", "timeShiftBufferDepth", and "UTCTiming" to indicate to the receiver that it is a live stream, when the stream started, and which segments are currently accessible.

[0114] In an embodiment where a switch from one live content piece to a second live content piece is performed upon resolution of an xlink in a DASH manifest, the content type will be dynamic (dynamic distribution for live content) (type=dynamic), and the new element offered may contain at least the elements "availabilityStartTime", "publishTime", and "minBufferTime", in accordance with 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: availabilityStartTime, minBufferTime, and publishTime. The other elements may not be present among the time synchronization data inserted in the section of the second manifest that will be read by the client when resolving redirection data read from the first manifest. The same applies to the syntax element. <liveperiod>which may not be present in one or more embodiments.

[0115] In one or more embodiments, the time synchronization data inserted in the section of the second manifest that will be read by the client when resolving redirection data read from a first manifest will include the data specified as mandatory, by the applicable standard, for access to dynamically distributed content in the corresponding metadata set.

[0116] There figure 5 illustrates an example of implementing the proposed process according to one or more embodiments.

[0117] Thus, as before, a DASH client wishing to play a dynamically distributed video sequence (or current live stream) first makes a request to a content delivery network (CDN) (401) to obtain (402) the manifest (a set of descriptive metadata) of the current live stream, providing authentication information. The CDN performs a client authentication procedure and, if successful, returns a token and redirects the client to a network address (e.g., a URL) where the current manifest (corresponding to the current live stream) is accessible. The DASH 200 client can then connect to the current live stream (403). In order to correctly connect to the current live stream, the DASH client determines, from the information contained in the current manifest, for example, using the process illustrated by the figure 3 , the segment it needs to download according to the current time and the time elapsed to reconnect to the current stream, for example by determining an index of this segment or a timestamp as described above.

[0118] Once the DASH client is hooked into the current stream (404), it continuously reads (404, kB) this current stream, in the absence of a client "splice out" switchover command request.

[0119] When the packager receives a "splice out" command (404, OK), it inserts a failover signal ("box Emsg") into the last data segment of the current live stream (405) before the failover date. This "box" instructs the DASH 407 (400) client to immediately reload the current manifest associated with the current live stream. Simultaneously, and before reloading the current manifest, the packager removes the period ("SUP_PERIOD_CUR_LIVE") from the current live stream and inserts the period(s) from the secondary live stream ("INS_PERIOD_SEC_LIVE_XLINK") via an "xlink." An "xlink" specifies a failover target in the manifest. When an "xlink" is used, a period is returned to replace the current period in the manifest containing the "xlink."

[0120] To insert the period of the secondary live stream, a child element of the MPD, called "LivePeriod," is added to the "Period" element of the secondary manifest that the DASH client will read when resolving the xlink, so that the DASH client can hook the secondary live stream to the current time. To achieve this, the "LivePeriod" element is composed of attributes that calculate the segment of the current period that the 407 (400) reader must retrieve to hook the secondary live stream without introducing a time delay. This calculation is equivalent to the one presented previously in the... 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.

[0121] During the reloading of the current manifest (408), the DASH client (407) will load the "xlink" and resolve the link, meaning it accesses the data to which the link points. From this data, the reader will calculate and determine the segment of the current period to retrieve in order to connect to the secondary live stream without any time delay (409).

[0122] If the duration of the secondary live stream is unknown, "410 kB", the player continues to play the secondary live stream until a "splice in" command is requested.

[0123] When a "splice in" request arrives—that is, a request to return to the current live stream—the packager inserts an "Emsg box" (411) into the last data segment of the secondary live stream before the switchover date. As before, this box informs the DASH 412 client that it must reload the current manifest.

[0124] Simultaneously, and before the current manifest is reloaded, the packager removes the period from the secondary live stream and inserts the period from the current live stream (412) using the attributes of the current manifest, which are always available at the root of the MPD. When the current manifest is reloaded (415), the DASH 412 client (407; 400) reconnects to the current live stream without any time delay.

[0125] Without the aforementioned provisions, namely a "LivePeriod" child element, it is not possible to wait for a secondary live stream when using an "xlink" link because the information needed to calculate the segment to download in order to connect to the secondary live stream at the current time is not available in an "xlink". Indeed, as explained and illustrated previously figure 3 The calculation used to determine the segment to download uses information (attributes) that is only available in the root of the manifest. When using an "xlink," the period of the main video stream / sequence is replaced by the period(s) reachable by the "xlink," corresponding to another video sequence, such as an advertisement. The child element "Period," which allows the replacement of one period with another, does not have attributes that enable the calculation of the segment to download in order to hook into a real-time video sequence.

[0126] THE figures 6a , 6b And 6c illustrate manifests using a redirection instruction for inserting VOD content into a live stream ( figure 6a ), and for switching to a secondary live stream from a main live stream ( figures 6b And 6c ).

[0127] With reference to the figure 6a Period P0 is the initial period of the live content; it starts at T0 and its duration corresponds to the time before the splice out. Period P1 is the dropout period; its duration is fixed and known in advance. It is inserted into the manifest along with the return-to-live period to allow the player to preload the segments. The xlink resolution allows the information related to this period to be obtained and substituted for the information present in the manifest. Period P2 is the return-to-initial content period; it starts at the sum of the durations of the preceding periods and its duration is unknown.

[0128] There figure 6b provides an illustration of an example of a first manifest including a redirect link pointing to a section of a second manifest, and the figure 6c an example of a second manifesto improved according to the proposed method.

[0129] With reference to the figure 6b The period P0 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 relation to the figure 6a .

[0130] Unlike the illustrated manifesto on the figure 6a , period P1 of the illustrated manifesto on the figure 6b is a period of disconnection corresponding to live content whose start time is unknown. The example of the redirect link from the first manifest illustrated on the figure 6b (xlink:actuate="onLoad" xlink:href="http: / / ..." xmlns:xlink=http: / / www.w3.org / 1999 / xlink) included in the time interval description container <period id="P1" start="PT10H00M00S" xlink:actuate="onLoad" xlink:href="http: / / ..." xmlns:xlink="http: / / www.w3.org / 1999 / xlink"> <adaptationset id="0" contenttype="video" ...> < / adaptationset> <adaptationset id="1" contenttype="audio" ...> < / adaptationset> , < / period> , can, for example, point to the second illustrated manifesto on the figure 6c .

[0131] With reference to the figure 6c Resolving the redirection link (xlink) to read the second manifest it points to allows obtaining the timing information (time synchronization) related to the period defined by the "Period" container of the second manifest (illustrated on the fig. 6b ) in which the redirect link is inserted. In order to allow the client to access the content segments corresponding to the second manifest, a new container (new element ("LivePeriod")) is added at the time interval description container level (of the "Period" element) to which the redirect link (xlink) of the first manifest ( fig. 6b ) point: " <LivePeriod type="dynamic" availabilityStartTime="2019-03-01T14:00:00Z" publishTime="2019-03-01T14:00:00Z " minimumUpdatePeriod="PT10S" minBufferTime="PT2S" timeShiftBufferDepth="PT10S" UTCTiming=" urn:mpeg:dash:utc:http-ntp:2014" / > It includes timing information that allows the receiver to know when the stream started and which segments are currently accessible. figure 6c illustrates an example of a proposed container (“LivePeriod”) comprising the following data types: type; availabilityStartTime; publishTime; minimumUpdatePeriod; minBufferTime; timeShiftBufferDepth; UTCTiming, with example values ​​for each of these data types.

[0132] Those skilled in the art will understand that, although these examples and illustrations conform to the standard of ISO / IEC 23009-1, they are not exhaustive, and the proposed process can be implemented in other contexts, particularly within other standards, and / or using different formats and syntaxes.

[0133] There figure 6d is a time diagram illustrating a dropout from live1 to live 2 and then back to live 1 carried out according to one or more modes of implementation.

[0134] Initially, the manifest contains only one period corresponding to the primary live stream. Upon receiving a splice out command, the packager performs the following operations: It inserts an 'emsg' box into the last data segment of the primary stream before the switchover date. This box instructs the DASH client to immediately reload the manifest. It then removes the primary live stream period from the manifest and inserts the secondary live stream period using the xlink. Resolving this xlink allows the DASH client to obtain information about the period(s) of the secondary stream and begin decoding.

[0135] Since the duration of the secondary live stream is unknown, the DASH client continues to read this stream until it receives further information.

[0136] Upon receiving a splice-in command, the packager performs the following operations: It inserts an 'emsg' box into the last data segment of the secondary stream before the switchover date. This box instructs the DASH client to immediately reload the manifest. It then removes the secondary live stream period from the manifest and inserts the primary live stream period. The DASH client now has the information about the primary stream and can therefore resume decoding.

[0137] This return-to-main live phase requires that splicing commands be synchronized between the main and secondary packagers.

[0138] Return to the primary stream: When switching to a secondary live stream, the client should begin playback as soon as the switchover is signaled. However, if the client is time-shifted relative to the live stream, it will wait for the current period to end before switching. Therefore, it will not be able to access the beginning of the secondary live stream. This is unacceptable, especially for alert-type switches. This problem can be resolved by inserting an 'emsg' box in the video segment preceding the switchover. This box will instruct the DASH client to reload the manifest immediately, regardless of the value of the minimumUpdatePeriod attribute. Simultaneously, the packager will have removed the primary live stream period from the manifest, leaving only the secondary live stream period with the xlink.When the manifest is reloaded, the DASH client will have no choice but to start on the secondary stream's period, regardless of its read position in the time-shift buffer. The same mechanism will be used to force DASH clients back to the primary stream. The packager will insert an `emsg` box, remove the secondary live stream's period from the manifest, and add a period corresponding to the primary live stream.

[0139] Thus, the proposed method advantageously opens up the possibility of using xlinks in a system using the DASH standard to perform a failover from one dynamically distributed piece of content to a second, also dynamically distributed, piece of content. This provides a new way to perform a failover from one dynamically distributed piece of content to another, while benefiting from the advantages that this method offers (particularly in terms of continuity between successive periods, DRM management, and authentication management, as discussed above). These advantages may be lacking in other methods for failing over from one dynamically distributed piece of content to another, such as methods based on a manifest change.

[0140] There figure 7 illustrates an example of the architecture of a device for reading multimedia content distributed in dynamic mode for the implementation of the proposed process.

[0141] With reference to the figure 7 The device 500 includes a controller 501, operationally coupled to an input interface 502 and a memory 504, which drives a multimedia content playback unit 503.

[0142] The 502 input interface 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 metadata sets corresponding to this content.

[0143] The 501 controller is configured to drive the 503 multimedia content reading unit for the implementation of one or more embodiments of the proposed process.

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

[0145] In addition, the 500 device can be implemented in software form, as described above, or in hardware form, as an application-specific integrated circuit (ASIC), or as a combination of hardware and software elements, such as a software program intended to be loaded and executed on an FPGA (Field Programmable Gate Array) component.< / liveperiod> < / period> < / period> < / period>

Claims

1. A method for managing multimedia contents, comprising: Obtaining (60) a first set of content description metadata describing a first multimedia content delivered in dynamic mode; and upon reading, from the first set of metadata, redirect data for redirecting to a section of a second set of content description metadata, reading (61), from the section of the second set of metadata, data relative to a temporal synchronization of the access to a second multimedia content delivered in dynamic mode, wherein the first and second sets of metadata are manifests in DASH format, DASH standing for dynamic adaptive streaming over HTTP.

2. The method as claimed in claim 1, wherein the second set of content description metadata describes the second multimedia content delivered in dynamic mode.

3. The method as claimed in either one of the preceding claims, wherein the data relative to a temporal synchronization for the access to the second multimedia content delivered in dynamic mode are read, from the second set of content description metadata, from a time-interval description container relative to the second multimedia content.

4. The method as claimed in any one of the preceding claims, wherein the data relative to a temporal synchronization for the access to the second multimedia content delivered in dynamic mode comprise data indicating a timestamp of availability of the second multimedia content.

5. The method as claimed in any one of the preceding claims, wherein the data relative to a temporal synchronization for the access to the second multimedia content delivered in dynamic mode comprise data indicating information on accessibility of segments of the second multimedia content.

6. The method as claimed in any one of the preceding claims, wherein the data relative to a temporal synchronization for the access to the second multimedia content delivered in dynamic mode correspond to data relative to a temporal synchronization that are provided in a root element of the second set of metadata.

7. The method as claimed in any one of the preceding claims, wherein the data relative to a temporal synchronization for the access to the second multimedia content delivered in dynamic mode comprise data indicating a timestamp of availability of a first segment of the second content, data indicating a common duration used in the definition of bit rates associated with the second content and data indicating a timestamp of generation of the second set of metadata and of its publication on a multimedia content delivery network.

8. A device (500) for playing multimedia content, comprising a processor (501) and a memory (504) that is operationally coupled to the processor (501), wherein the processor is configured to implement a method as claimed in any one of claims 1 to 7.

9. A computer program, which is loadable into a memory associated with a processor, and which comprises segments of code for implementing the steps of a method as claimed in any one of claims 1 to 7 on the execution of said program by the processor.

10. A data set representing, for example in compressed or encoded form, a computer program as claimed in claim 9.