Method for distributing multimedia content, and corresponding encapsulator, system and computer program

Abstract

The invention relates to a method for distributing multimedia content, implemented in an encapsulator (321, 322) of a distribution network intended to implement at least two encapsulators, the method involving the following steps: - obtaining the multimedia content; - obtaining at least one session identifier representative of at least one identifier associated with the multimedia content and / or at least one object identifier representative of at least one identifier associated with at least one file representative of the multimedia content; - generating a transport stream comprising transport packets constructed from the multimedia content, the transport packets bearing a header specific to a relevant transport protocol, the header comprising at least one session identification field bearing the at least one session identifier and / or at least one object identification field bearing the at least one object identifier.

Description

[0001] DESCRIPTION

[0002] TITLE: Method for distributing multimedia content, encapsulates, system and corresponding computer program.

[0003] 1. Technical field

[0004] The field of the invention is that of the distribution of multimedia content.

[0005] More specifically, the invention proposes a solution allowing a user to access multimedia content even in the event of a failure of equipment in the distribution network.

[0006] The invention applies in particular, but not exclusively, to the distribution of OTT (“Over The Top”) type services.

[0007] The invention applies in particular to the classic Internet network, as well as to mobile networks (for example 3GPP), terrestrial (for example according to the DVB-T, DVB-T2 or ATSC standard), satellite (for example according to the DVB-S or DVB-S2 standard) or others.

[0008] 2. Prior art

[0009] Below, in relation to Figure 1, we present a classic chain for the distribution of multimedia content from a source to an end user.

[0010] Thus, a first block 11 is considered delivering at least one multimedia content. Such a block comprises a content source 111 delivering at least one multimedia content. Such multimedia content may be formed by one or more binary files 112. The format of the binary file(s) may follow different encoding formats, for example: ISOBMFF (“ISO Base Media File Format”), DASH (“Dynamic Adaptive Streaming over HTTP”), MPU (“Media Processing Unit”), HLS (“HTTP Live Streaming”), TS (“Transport Stream”), etc.

[0011] Multimedia content, or the corresponding binary files 112, may in particular be hosted by a CDN (“Content Delivery Network”) infrastructure. In this case, users’ clients can obtain content “on demand”.

[0012] Alternatively, the media content, or the corresponding binary files 112, may be pushed directly into the distribution network.

[0013] The distribution chain may in particular carry multimedia content from the source 111 to the end user 13 by means of unicast, multicast or broadcast links.

[0014] When the content is provided to the distribution chain through a unicast link (i.e. the content is intended for a single user), the encapsulation of the content, i.e. the decomposition of the content into transport packets, can be implemented by the first block 11, for example at the head-end of the network. The technologies used for the transport of the transport packets are conventionally of the type: IP / TCP / HTTP, IP / UDP / (TS, QUIC, etc.). As soon as the same multimedia content is consumed by several users, in particular at the same time (“concurrent consumption” of the content), the use of unicast links leads to overconsumption of the bandwidth of the distribution network. In order to avoid such overconsumption, multicast or broadcast links are used by the network to distribute the content between the source 111 and the end users 131, 132, 133, as illustrated in FIG. 2.

[0015] When the content is provided to the distribution chain through multicast or broadcast links (i.e. the content is intended for several users), the distribution chain may include an entity dedicated to encapsulating the content, called an “IP encapsulator” 12. Such an encapsulator 12 may in particular decompose the content in the form of IP transport packets. The technologies used for transporting transport packets are conventionally of the IP / UDP(RTP) type, on which different multimedia content delivery protocols exist: FLUTE, ROUTE, MMT, QUIC multicast, HLS, etc.

[0016] Figure 2 also illustrates an example of the different protocols that can be used for the distribution of content in a distribution network. Note that one or more protocols can be supported, depending on the nature of the transmission chains (cable, terrestrial, mobile, satellite, etc.) and the associated standards (3GPP, ATSC, DVB, etc.).

[0017] Similarly, transmission chains can be hybrid, mixing unicast, multicast and broadcast links as well as protocols between a content source 111 and the final consumer client 13.

[0018] At the other end of the distribution chain is the consumer / end client block 13, which is used to deliver the multimedia content to the user. The content to be delivered can be reconstructed from the received transport packets.

[0019] As mentioned earlier, when content is delivered to the distribution chain over a unicast link, the transport packets can be delivered using an IP / TCP / HTTP protocol. In this case, in the event of a failure at the encapsulation level, the retransmission of transport packets is provided by the TCP protocol.

[0020] Conversely, the retransmission of transport packets in the event of a failure at the encapsulation level is not provided for by the UDP protocol. There is therefore no mechanism allowing the user 13 to reconstruct the content in the event of an encapsulator failure when the content is delivered to the distribution chain through multicast and broadcast links. A first solution would be to use error correcting codes (FEC). However, such a solution does not provide protection against such failures (breakdown, unavailability of the encapsulator) given the time duration of the interruption. A second solution would be to use a restorative feedback loop. However, such a solution is difficult to implement. Indeed, in several deployment scenarios (for example, DVB-NIP - DVB Native IP Broadcasting), such a loop does not exist.Furthermore, it is not desirable for users to switch en masse to the unicast link, which would generate a peak in network throughput and excessive bandwidth consumption.

[0021] Therefore, the classic redundancy schemes ("active-standby" or "active-active") inherited from the Internet do not meet the need, since they involve an interruption, even brief, in the transport flow of the content provided to the final consumer.

[0022] There is therefore a need for a new solution that can deliver multimedia content to a user even in the event of an encapsulator failure, without disruption to the end user.

[0023] 3. Statement of the invention

[0024] The invention proposes a solution in the form of a method for distributing multimedia content, implemented in an encapsulator of a distribution network intended to implement at least two encapsulators, implementing the following steps: obtaining said multimedia content, obtaining at least one session identifier representative of at least one identifier associated with said multimedia content and / or at least one object identifier representative of at least one identifier associated with at least one file representative of said multimedia content, generating a transport stream comprising transport packets constructed from said multimedia content, said transport packets carrying a header specific to a transport protocol considered, said header comprising at least one session identification field carrying said at least one session identifier and / or at least one object identification field carrying said at least one object identifier.

[0025] An encapsulator according to the invention can thus generate a transport stream comprising transport packets carrying a particular header, i.e. the values ​​carried by certain fields are constructed from the multimedia content to be distributed. The values ​​carried by these fields of the transport packet header are therefore deterministic.

[0026] In this way, when several encapsulators are provided in the distribution network, each encapsulator generates a transport stream whose values ​​carried by certain fields of the transport packet header are constructed from the same multimedia content to be distributed.

[0027] The different transport streams thus generated are therefore identical, or substantially identical, for the end user. It is thus possible to switch from one transport stream to another in the event of an encapsulator failure, without disruption to the user.

[0028] In a particular embodiment, said at least one identifier associated with said multimedia content, also called "session fingerprint", belongs to the group comprising: a type of said multimedia content, at least one part of a name of at least one file representative of said multimedia content, metadata associated with said at least one file, a combination of at least two pieces of information from said type, said at least one part of a name, and said metadata.

[0029] According to a first example, said type of said multimedia content is obtained from an HTTP message received from a content server distributing said content.

[0030] According to a second example, said type of said multimedia content is obtained from an analysis of said at least one file representative of said multimedia content.

[0031] According to a third example, said type of said multimedia content is obtained from the reception of signaling data.

[0032] The session fingerprint may be constructed by the wrapper. Alternatively, the session fingerprint may be constructed by another entity, e.g., the content server distributing said media content, and received by the wrapper.

[0033] Such a session fingerprint makes it possible to uniquely identify the multimedia content in question.

[0034] In a particular embodiment, said session identifier belongs to the group comprising: said at least one identifier associated with said multimedia content. In this case, the session identifier corresponds to the session fingerprint; a function of said at least one identifier associated with said multimedia content. In this case, the session identifier is obtained by applying a function to the session fingerprint, for example a hash function. In other words, there is a computational correspondence between the session identifier and the identifier associated with said multimedia content; a value. In this case, the session identifier corresponds for example to an index (1, 2, 3, or M, N, etc.). In other words, there is a static correspondence between the session identifier and the identifier associated with said multimedia content.

[0035] The session identifier may be constructed by the wrapper. Alternatively, the session identifier may be constructed by another entity, e.g., the content server distributing said media content, and received by the wrapper.

[0036] In a particular embodiment, said at least one identifier associated with said at least one file, also called "object fingerprint" belongs to the group comprising: at least one part of a name of said at least one file, at least one part of a binary content of said at least one file, metadata associated with said at least one file, a combination of at least two pieces of information among said at least one part of a name, said at least one part of a binary content and said metadata.

[0037] The object fingerprint may be constructed by the wrapper. Alternatively, the object fingerprint may be constructed by another entity, e.g., the content server distributing said media content, and received by the wrapper.

[0038] In a particular embodiment, said object identifier belongs to the group comprising: said at least one identifier associated with said at least one file. In this case, the object identifier corresponds to the object fingerprint; a function of said at least one identifier associated with said at least one file. In this case, the object identifier is obtained by applying a function to the object fingerprint, for example a hash function. In other words, there is a computational correspondence between the object identifier and the identifier associated with said at least one file; a value. In this case, the object identifier corresponds for example to an index (1, 2, 3, or M, N, etc.). In other words, there is a static correspondence between the object identifier and the identifier associated with said at least one file.

[0039] The object identifier may be constructed by the wrapper. Alternatively, the object identifier may be constructed by another entity, e.g., the content server distributing said media content, and received by the wrapper.

[0040] In particular, said metadata may be transported inside (“inband”) or outside (“outband”) said file representing said multimedia content. For example, such metadata is generated by the content server and may be used by the end client for rendering the multimedia content.

[0041] In a particular embodiment, said transport protocol belongs to the group comprising: the FLUTE protocol, the ROUTE protocol, the M MT protocol, the QUIC multicast protocol, the NORM protocol, the HLS protocol.

[0042] In particular, the format of said at least one file belongs to the group comprising:

[0043] - ISOBMFF

[0044] - DASH

[0045] - MPU

[0046] - HLS

[0047] In another embodiment, the invention relates to a corresponding encapsulator. Such an encapsulator is particularly suitable for implementing the method for distributing multimedia content described above. Such an encapsulator may of course have the various characteristics relating to the method according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this encapsulator are the same as those of the method and are not detailed further.

[0048] In another embodiment, the invention relates to a distribution system implementing at least two corresponding encapsulators, each delivering a transport stream, such that the headers of the transport packets of the different transport streams are identical.

[0049] In particular, such encapsulators can be located at distinct locations. The invention also relates to at least one computer program comprising instructions for implementing the method for distributing multimedia content described above, when this or these programs are executed by a processor, as well as at least one information medium readable by a computer comprising instructions of at least one computer program as mentioned above.

[0050] The method according to the invention can be implemented in various ways, in particular in wired form or in software form.

[0051] 4. List of figures

[0052] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which: Figure 1 illustrates an example of a distribution chain according to the prior art, Figure 2 illustrates an example of the different protocols that can be used in a distribution chain according to Figure 1, Figure 3 illustrates an example of a distribution chain according to a particular embodiment of the invention, Figure 4 illustrates an example of encapsulation of multimedia content in transport packets, Figure 5 illustrates the main steps implemented by an encapsulator according to an embodiment of the invention, Figure 6A, Figure 6B, and Figure 6C illustrate examples of session fingerprints and corresponding session identifiers,Figure 7A and Figure 7B illustrate examples of object fingerprints and corresponding object identifiers, Figure 8 illustrates an example of obtaining a session fingerprint from the HTTP header, Figure 9 illustrates an example of extending a session fingerprint by adding other information thereto, Figure 10 illustrates an example of determining an extended session fingerprint from a DASH manifest, Figure 11 illustrates an example of a "nested" structure of an ISOBMFF file, Figure 12 illustrates an example of extracting metadata from an ISOBMFF file for determining a session fingerprint, Figure 13 illustrates an example of extracting metadata from an ISOBMFF file for determining an object fingerprint, Figure 14 illustrates the simplified structure of a wrapper according to an embodiment of the invention.,

[0053] 5. Description of embodiments of the invention

[0054] 5.1 Background of the invention

[0055] The invention is placed in the context of the distribution of content through multicast or broadcast links (i.e. the content is intended for several users), according to which the multimedia content is encapsulated in transport packets for distribution to the different users.

[0056] Adding such an encapsulator to a distribution chain can introduce a point of failure that could impact the end user. To limit this risk, encapsulator redundancy is provided in the distribution chain. It is thus possible to switch from a first encapsulator generating a first transport stream to a second encapsulator generating a second transport stream, in the event of failure of the first encapsulator.

[0057] In particular, the invention seeks to prevent the switching from one transport stream to another transport stream from being visible to the user. In other words, a solution is sought for seamless switching for the user.

[0058] Figure 3 illustrates an example of a distribution chain according to an embodiment of the invention, using two encapsulators 321 and 322.

[0059] Such a distribution chain comprises several blocks communicating with each other, via IP links for example. It should be noted that the use of IP links does not restrict the invention to the classic Internet network, but also covers mobile networks (for example 3GPP), terrestrial networks (for example according to the DVB-T or ATSC standard), satellite networks (for example according to the DVB-S standard) or others.

[0060] Each encapsulator 321, 322 can receive the multimedia content delivered by the source 311, for example in the form of at least one file 312, in particular a binary file, and deliver a transport stream. The multimedia content can be real-time (“live”) or non-real-time (for example on demand - VOD “Video On Demand”). The format of the file(s) 312 can follow different encoding formats, for example ISOBMFF, DASH, MPU, HLS, etc.

[0061] For example, an encapsulator 321, 322 can connect to an entity of a CDN infrastructure to retrieve content hosted by this entity, then decompose the content thus obtained into transport packets to route it to at least one user 34.

[0062] Alternatively, an encapsulator 321, 322 may receive the content and then decompose the resulting content into transport packets for delivery to the user 34.

[0063] According to one embodiment of the invention, a switch 33 is provided to switch from one transport stream to another in the event of failure of one of the encapsulators 321, 322. The switch 33 can in particular route the transport stream that it receives to the user 34. In another embodiment, the switch 33 can be integrated into the equipment of the user 34. In this case, the transport streams generated by the different encapsulators can reach the user 34.

[0064] In order to enable such switching, the encapsulators 321, 322 of the distribution network can act identically. The transport streams generated by the different encapsulators can then be identical, or at least similar, at the transport protocol level, from the user's point of view. To achieve this objective, the transport packet shaping processes implemented in each encapsulator 321, 322 can be synchronized. Since the different encapsulators share the same content source, i.e. receive the same multimedia content, the inventors had the idea of ​​using the multimedia content as a synchronization reference, as described below.

[0065] Note that other external synchronization sources could be used to synchronize the different transport streams. However, the ingestion of the input content can suffer from variable delays depending on the encapsulators. It is therefore more efficient to synchronize on the multimedia content, coupled if necessary with an external time reference to synchronize the ingestion of the content.

[0066] It should also be noted that one or more transport protocols may be supported by the distribution chain, depending for example on the nature of the transmission (cable, terrestrial, mobile, satellite, etc.) and the associated standards (3GPP, ATSC, DVB, etc.). Similarly, distribution chains can be hybrid, mixing unicast, multicast and broadcast links as well as the protocols between a content source and the final consumer client.

[0067] To make the transport flows output from the different encapsulators in the distribution chain similar, at the transport protocol level (above the IP / UDP layers), one embodiment of the invention proposes to make the encapsulation deterministic and synchronous. The invention thus proposes a solution allowing certain fields of the transport protocol headers to be aligned, i.e. identical for the same transported object.

[0068] As illustrated in Figure 4, encapsulation consists of breaking down the content (for example transmitted in the form of at least one binary file 312) into a set of transport packets and adding a header specific to the transport protocol considered.

[0069] Encapsulation is quite constrained, notably by the size of the IP packet (MTU, “Maximum Transmission Unit”).

[0070] If the size of a transport packet is the same between two encapsulators, the decomposition is the same, as are most of the header fields. Therefore, it is a matter of constraining the remaining fields in order to have identical or similar headers.

[0071] Among the different transport protocols considered (FLUTE, ROUTE, MMT, QUIC multicast, NORM, HLS, etc.), the inventors identified two header fields that can be constrained: a session identification field and an object identification field.

[0072] Typically, a session identifier can be used to distinguish signaling, audio, video, subtitle, etc. components in multimedia content. An object identifier is used within a given session to identify a specific file. Indeed, the content can be transmitted in a non-monolithic manner by a succession of small content files, each representing a fragment of the content. Alternatively, the content can be transmitted as a data stream.

[0073] For example, the encapsulators of a pair implement the same transport protocol (where a pair comprises a first encapsulator—for example, the encapsulator 321—and a second encapsulator redundant to the first encapsulator—for example, the encapsulator 322). In this case, the headers of the transport packets are identical because they cover the same protocol. Alternatively, the encapsulators of a pair implement different transport protocols. In this case, the headers of the transport packets are not strictly identical at the bit level since they cover two different protocols. They are, however, similar because the session identifier values, carried by the session identification field, and the object identifier values, carried by the object identification field, are identical.

[0074] In the context of a hybrid network, several pairs of encapsulators can be chained together sequentially in the distribution network. For example, the two encapsulators of a first pair implement the same transport protocol, such as ROUTE, and can be followed in the distribution network by a second pair of encapsulators implementing the same transport protocol, such as FLUTE. Alternatively, the encapsulators of the same pair implement different transport protocols.

[0075] 5.2 Description of a particular embodiment

[0076] 5.2.1 General principle

[0077] Figure 5 illustrates the main steps implemented by an encapsulator according to an embodiment of the invention, for example the encapsulator 321 of Figure 3.

[0078] During a first step 51, the encapsulator obtains the multimedia content to be distributed, for example in the form of at least one binary file or a data stream. As indicated above, the content may optionally be transmitted in a block, or in the form of a plurality of files each representing a fragment of the content. For example, the encapsulator may connect to an entity of a CDN infrastructure to retrieve the content hosted by this entity. Alternatively, the encapsulator 321 may receive the content from a content server.

[0079] During a second step 52, the encpasulator 321 obtains at least one session identifier representative of at least one identifier associated with said multimedia content (“session fingerprint”) and / or at least one object identifier representative of at least one identifier associated with said at least one file (“object fingerprint”).

[0080] During a third step 53, the encoder 321 generates a transport stream comprising transport packets constructed from the multimedia content, such that the transport packets carry a header specific to a transport protocol considered, with said at least one session identifier in the session identification field and said at least one object identifier in the object identification field of the header.

[0081] As explained above, such steps make it possible to construct a transport stream in a deterministic manner. The steps of Figure 5 can in particular be implemented by at least one other encapsulator in the distribution chain, for example the encapsulator 322 of Figure 3, which has the same multimedia content as input. In this way, at least two substantially identical transport streams are generated, and the switch 33 can switch from one to the other in the event of failure of one of the encapsulators.

[0082] Note that the transport protocol considered is not necessarily identical between the different encapsulators of the same pair, or of successive pairs.

[0083] Below are some examples for determining a session identifier based on the media content. As already mentioned, such an identifier can be determined by the encapsulator, or by another entity (belonging to the distribution network or not) and transmitted to the encapsulator.

[0084] In particular, such a session identifier is representative of at least one identifier associated with the multimedia content, also called a session fingerprint.

[0085] One option is to use the content type ("MIME type"), e.g. audio, video, subtitle, etc., as a session fingerprint.

[0086] According to one example, such a type may be retrieved during ingestion between the content source and the wrapper, for example in HTTP exchanges. Alternatively, an analysis of the media content (e.g., of at least one binary file) after reception at the wrapper, the reception of signaling data, or other techniques may also allow the content type to be extracted.

[0087] As illustrated in Figure 6A, the session fingerprint is for example “video / mp4” for a video component, and / or “audio / mp4” for an audio component. The session identifier representative of the session fingerprint “video / mp4” is for example a value M, and the session identifier representative of the session fingerprint “audio / mp4” is for example a value N.

[0088] Each content type is thus assigned a unique session fingerprint, and consequently a unique session identifier shared by the different encapsulators in the distribution chain. In other words, according to this embodiment, all the encapsulators in the distribution chain will assign the same session identifier (for example the value M) to a particular content type (for example to the video content associated with the session fingerprint "video / mp4"). This first option based on the use of a content type only can work when the multimedia content only includes components of distinct types (audio, video,

[0089] However, this first option may not be sufficient to guarantee the uniqueness of the session identifier when the content contains several components of the same type (for example, several audio components with different languages, or video components using different codecs or different resolutions).

[0090] In addition to or as an alternative to the first option, other information about the media content can be used to construct the session fingerprint. For example, the name of at least one binary file representative of the content, or part of it (obtained via patterns), can be used. Other metadata intrinsic to the file type, such as the language used (for audio and subtitles), the codec, and / or the resolution can be used.

[0091] For example, as illustrated in Figure 6B, a first session fingerprint is associated with the type “video / mp4”, with the name “video-720p-l.mp4” and the resolution “720p”, and a second session fingerprint is associated with the type “video / mp4”, with the name “video-1080p-l.mp4” and the resolution “1080p”. The session identifier representative of the first session fingerprint is for example a value M, and the session identifier representative of the second session fingerprint is for example a value N.

[0092] This allows the construction, for each multimedia content, of a unique fingerprint for the session, to which a unique session identifier can be associated.

[0093] Obtaining the session ID from the session fingerprint can be done in various ways.

[0094] As a first example, this matching can be done statically, for example by assigning a value or index to each session fingerprint. In particular, each broadcast standard defines a set of supported languages, codecs, resolutions, etc., which results in a countable number of session fingerprints. If the size of the session identifier allows listing all possible session fingerprints, then a deterministic and unique session identifier can be guaranteed.

[0095] According to a particular embodiment, the range of values ​​of the session identifier can be broken down into sub-ranges to facilitate the classification of the fingerprints. For example, the session fingerprints corresponding to video components are assigned to such a range of values, those corresponding to audio components to such another range of values, etc. According to a second example, the correspondence can also be done computationally, for example by applying a function to the session fingerprint. Such a function is for example a hash function, or any other function making it possible to link the session fingerprint to the session identifier.

[0096] In particular, the function may be chosen to validate the adequacy between the size of the session identifier and the collision resistance of the (hash) function.

[0097] Figure 6C illustrates these first two examples.

[0098] In a third example, the session ID is directly the session fingerprint.

[0099] It is important to note that multimedia content can have dynamic behavior characterized by periods, especially for real-time (live) content. It is therefore desirable to carefully select the information used to build the session fingerprint (file name, codecs, language, resolution, etc.) so as not to change the session identifier unnecessarily. For example, if the codec is likely to change during distribution, it is preferable not to add the codec to the session fingerprint.

[0100] We now describe some examples for determining an object identifier, this time based on at least one file (i.e., a fragment of the content rather than the entire content). As already indicated, such an object identifier can be determined by the wrapper, or by another entity (belonging to the distribution network or not) and transmitted to the wrapper.

[0101] In particular, such an object identifier is representative of at least one identifier associated with at least one file, also called an object fingerprint.

[0102] A first option is to use the name of at least one binary file representative of the content, or part of it (e.g. obtained via patterns) to determine the object fingerprint.

[0103] In addition or as an alternative to the first option, it is possible to use at least part of the binary content of the file to determine the object fingerprint and / or metadata.

[0104] Obtaining the object ID from the object fingerprint can be done in various ways, for example by applying a function to the object fingerprint or by extracting it according to a pattern (regex).

[0105] In the example illustrated in Figure 7A, the object fingerprint corresponds to the file name (“video-720p-l.mp4”, “video-720p-2.mp4”, “video-720p-3.mp4”). A common pattern is identified: “video-720p-$.mp4”. The object identifier can be constructed from the differences from this common pattern. Thus, the object identifier associated with the object fingerprint “video-720p-l.mp4” is for example M+1, the object identifier associated with the object fingerprint “video-720p-2.mp4” is for example M+2, and the object identifier associated with the object fingerprint “video-720p-3.mp4” is for example M+3.

[0106] The advantage of a solution based on the file name (or part of the name) is that it is agnostic with respect to the type of content obtained as input to the wrapper. In addition, it offers the possibility of using a regular increment for object identifiers (for example +1), especially if the files corresponding to temporal fragments of the content are numbered successively. There is nevertheless a constraint on the content source in order to differentiate the name of the file associated with each object / fragment of the multimedia content, to guarantee the uniqueness of the object identifiers.

[0107] Alternatively, a function may be applied to the object fingerprint to determine the object identifier. Such a function is, for example, a hash function, or any other function that allows the object fingerprint to be linked to the object identifier.

[0108] Such a function can be applied to at least part of the file name, or to at least part of the file content itself. Again, the solution remains agnostic to the content type. The file content-based solution may require receiving the entire file before applying the hash function, which may induce higher processing latency.

[0109] According to yet another variant, illustrated in Figure 7B, the object fingerprint can be constructed from metadata associated with at least one file representative of the multimedia content. It is thus possible to constrain the object identifier on the metadata associated with a fragment of the multimedia content, for example by linking the object identifier to identifiers of the format of the file representative of the content (ISOBMFF, DASH, MPU, etc.). The technique is then dependent on the input format of the file on the encapsulator. Determining the object identifier may require, according to one embodiment, the prior reception of the metadata, which may result in processing latency. Nevertheless, by selecting certain metadata in the original format of the file representative of the content, it is possible to guarantee both uniqueness and a possible regular increment constraint for the object identifiers.

[0110] The mapping between session / object identifiers and session / object fingerprints associated with each transport protocol is detailed below for the ROUTE protocol. Similarly, mappings could be established for other transport protocols, such as FLUTE, MMT, QUIC Multicast, NORM, HLS, etc.

[0111] 5.2.2 Implementation for the ROUTE protocol

[0112] An example of implementation of the invention is presented below when the transport protocol used is the ROUTE protocol.

[0113] A. Reminders

[0114] The ROUTE transport protocol is described in the ATSC A / 331 document and in the RFC 9223 document. It is notably used in the following broadcasting standards: ATSC 3.0, DVB-MABR, DVB-NIP. It allows the transport of any type of file, real-time or not, such as DASH multimedia segments, HLS, OMA-BCAST program guide files, etc.

[0115] At the protocol layer, the ROUTE protocol operates on the IP / UDP (and potentially RTP) layers. The ROUTE protocol derives from the LCT (RFC 5651), ALC (RFC 5775) and FLUTE (RFC 6726) protocols. The encapsulation header thus includes an LCT header followed by a header for the use of error correcting codes (FEC). This is followed by the payload of the packet, including part of the binary file to be encapsulated.

[0116] The structure of the header of a ROUTE packet is recalled in the table below:

[0117] The details of the LCT header are shown in the table below:

[0118] The ROUTE protocol is based on the use of the TSI (Transport Session Identifier) ​​and TOI (Transport Object Identifier) ​​fields - fields 'S' = '1' and 'O' = '01' - and sets their size to 32 bits - field 'H' = '0'.

[0119] B. Examples of implementation of the invention

[0120] According to one embodiment of the invention, it is proposed to use respectively the TSI field to carry the session identifier and the TOI field to carry the object identifier, as defined previously. These fields are currently on 32 bits, they can carry approximately 4.295 billion distinct identifier values. The value "0" is often used specifically in the ATSC and DVB standards, so it is possible to choose not to use this value.

[0121] B.1 Session identification

[0122] Regarding the session identifier, and therefore the value carried by the TSI field, all the techniques described previously can be implemented to determine a session fingerprint associated with the multimedia content.

[0123] Some techniques based on the type of media content or the name of the file(s) representing the media content for determining a session fingerprint are called "agnostic".

[0124] For example, if the session fingerprint is obtained from the type of the content or from a name of at least one file representative of the content, the session fingerprint can be determined directly during the exchange between the content source (311) and the IP encapsulator (321) by the HTTP header as illustrated in Figure 8.

[0125] If such a session fingerprint is insufficient to guarantee the uniqueness of the session identifier, it is possible to "extend" the session fingerprint by adding other information. This can be done in a way agnostic to the file format (DASH format, HLS, etc.), for example by using naming rules to uniquely identify sessions from the source. For example, files associated with a component of the same type are named according to the same pattern. Thus, in the example illustrated in Figure 9, a file corresponding to a first audio component is named "TS-49410_l_audio_l-118631644" and a file corresponding to a second audio component is named "TS-49410_l_audio_2-118631644". The associated pattern is therefore "TS-49410_l_audio_$-118631644".It is thus possible to use a regular increment for session identifiers (for example +1), in particular if the files corresponding to components of the same type are numbered successively.

[0126] In this case, as before, the session fingerprint, and therefore the session ID, can be determined from the HTTP headers.

[0127] Other techniques for determining a session fingerprint are called "non-agnostic". For example, such techniques are based on the use, in the session fingerprint, of metadata (codecs, languages, resolutions, etc.) specific to the format of the file(s) representing the multimedia content.

[0128] This metadata can be transported inside (“inband”) or outside (“outband”) of the file(s) representing the multimedia content, from the source 311 to the encapsulator 321, 322.

[0129] Outband metadata is, for example, manifests for the DASH format or playlists for the HLS format. They are provided in parallel to the end client, either by the same distribution technique as the multimedia content (a dedicated session of the transport protocol, here ROUTE), or by another technique (for example, made available via a unicast link).

[0130] As illustrated in Figure 10, if we consider the DASH format, the manifest carries metadata in its different parts.

[0131] These metadata are for example: in the “AdaptationSet” part of the DASH manifest: “contentType”, “id”, “mimeType”, “lang”, “maxHeight”, “minHeight”, “maxWidth”, “minWidth”, in the “Role” part: “value”, in the “Representation” part: “codecs”, “id”, “width”, “height”.

[0132] It is then sufficient to extract at least one of the mentioned metadata to determine the session fingerprint, possibly by combining this information with other information such as a component type or a file name.

[0133] Note that since this metadata is provided in parallel with the files representing the multimedia content, it is possible to determine a priori the session fingerprints, and corresponding session identifiers, even before the encapsulator has received these files. In this case, the session fingerprint can be determined in particular by the content source.

[0134] Inband metadata is inserted into the file(s) representing the multimedia content. It is therefore necessary to receive the file, or at least the part including this metadata, before being able to determine the session fingerprint, and consequently the session identifier.

[0135] Considering the DASH format again, we note that the multimedia content can be divided into so-called "initialization" and "segment" files.

[0136] The metadata used to determine the session fingerprint can in this case be based solely on the initialization file, while ensuring a unique session identifier. Furthermore, it should be noted that various file formats representing multimedia content (e.g., DASH, MPU, etc.) are aligned with the ISOBMFF format, which describes the organization of the binary file(s) representing the multimedia content. The structure of a file in ISOBMFF format, as described in the ISO IEC 14496-12 standard, is organized in a stack of boxes. The nested structure of a file (in ISOBMFF, DASH, MPU, etc.) is for example illustrated in Figure 11. There are mandatory boxes and other optional boxes, depending on the format. By analyzing these boxes, metadata can be extracted that can be used to determine a session fingerprint.

[0137] For example, this metadata is: ftyp > compatible_brands track > mdia > mdhd > languagestring track > mdia > hdlr > handler track > mdia > minf > stbl > stsd (sub-box specific to each content type).

[0138] It is then sufficient to extract at least one of the mentioned metadata to determine the session fingerprint, possibly by combining this information with other information such as a component type or a file name.

[0139] Figure 12 illustrates in particular the extraction of the “handler” metadata.

[0140] Once the session fingerprint is obtained, the corresponding session identifier can be determined, to be entered in the TSI field.

[0141] For example, a hash function is applied to the obtained session fingerprint, yielding the session ID. Considering the ROUTE protocol, the session ID value must be at most 32 bits long.

[0142] Alternatively, the possible session fingerprints are counted, and each session fingerprint is assigned a value, intended to be inserted into the TSI field. A static list can thus be defined, by the encapsulator or by a third party entity, belonging or not to the distribution chain. For example, to limit the number of session fingerprints, it is possible to list the metadata values ​​supported by the target distribution standard.

[0143] For example, for ATSC 3.0, the list of currently supported codecs are: video: "hevl", "hev2", "hvcl", "hvc2", "Ihvl" or "lhel", audio: "ac-4", "mhml" or "mhm2".

[0144] B.2 Object identification

[0145] Concerning the object identifier, and therefore the value carried by the TOI field, all the techniques described previously can be implemented to determine an object fingerprint associated with a file representative of the multimedia content.

[0146] Some techniques based on the name or binary content of the file(s) representing the multimedia content for determining an object fingerprint are called "agnostic".

[0147] In particular, the determination of an object identifier by applying a pattern to an object fingerprint corresponding to the name (or part of the name) of a file representative of the multimedia content is similar to that described in the “session identifier” section for the ROUTE protocol.

[0148] Similarly, determining an object identifier by applying a function (e.g., a hash function) to an object fingerprint corresponding to a binary content of a file is similar to that described in the "session identifier" section for the ROUTE protocol. It should also be noted that the ROUTE protocol defines several content delivery modes: "file," "entity," "unsigned package," "signed package." This delivery mode may have an impact on the value of the TOI field.

[0149] As with session fingerprinting, other techniques for determining an object fingerprint are called "non-agnostic." For example, such techniques are based on the use, to construct the object fingerprint, of metadata (codecs, languages, resolutions, etc.) specific to the format of the file(s) representing the multimedia content.

[0150] This metadata can be transported inside (“inband”) or outside (“outband”) the binary file, from the source 311 to the wrapper 321, 322.

[0151] In the "outband" case, it is desirable to generate metadata for each object in parallel. However, this can be costly in terms of network capacity.

[0152] In the "inband" case, this metadata can be extracted in a similar way to that described in the "session identifier" section for formats based on the ISOBMFF standard. It should be noted that in the case of the DASH format, the metadata used to determine the object fingerprint can be based solely on the segment files.

[0153] For example, this metadata for the object fingerprint is: moof > mfhd > sequence_number sidx > referenced_size sidx > subsegment_duration

[0154] It is then sufficient to extract at least one of the mentioned metadata to determine the object fingerprint, possibly by combining this information with other information such as a file name.

[0155] Figure 13 illustrates in particular the extraction of the “sequence_number” metadata. Once the object fingerprint has been obtained, the corresponding object identifier can be determined, to be entered in the TOL field.

[0156] For example, a hash function is applied to the obtained object fingerprint, yielding the object identifier. Considering the ROUTE protocol, the object identifier value must be at most 32 bits long.

[0157] Alternatively, the possible object fingerprints are counted, and each object fingerprint is assigned a value, to be inserted into the TOI field.

[0158] 5.2.3 Implementation for the FLUTE protocol

[0159] An example of implementation of the invention is presented below when the transport protocol used is the FLUTE protocol.

[0160] Like the ROUTE protocol, the FLUTE protocol allows the transport of any type of file, real-time or not, and operates at the protocol level on the IP / UDP (and potentially RTP) layers. Although older, it is still used in several broadcast standards: 3GPP, DVB-MABR.

[0161] There are two versions of the FLUTE protocol based on standardized RFC documents: RFC 3926 for version 1 and RFC 6726 for version 2. The broadcast standards cited above use version 1.

[0162] FLUTE version 1 derives from the LCT (RFC 3451) and ALC (RFC 3450) protocols; while version

[0163] 2 derives from the LCT (RFC 5651), ALC (RFC 5775) protocols.

[0164] Regardless of the version, the encapsulation header thus includes an LCT header followed by a header for the use of error correcting codes (FEC). This is followed by the payload of the packet, including part of the binary file to be encapsulated.

[0165] The structure of the header of a FLUTE packet is recalled in the table below:

[0166] The detail of the LCT header for version 1 is shown below:

[0167] Session Identifier") and TOI ("Transport Object Identifier") - fields 'S' = '1' and 'O' 1= '00' but does not fix their size, which can therefore be greater than or equal to 32 bits. Similar to the ROUTE protocol, the TSI field can be used to carry a session identifier and the TOI field can be used to carry an object identifier.

[0168] The session ID and / or object ID can be determined as described above.

[0169] Implementation examples for the ROUTE and FLUTE protocols have been described above. As mentioned, a similar technique can be adopted for other protocols, such as MMT, QUIC Multicast, NORM, HLS, etc.

[0170] 5.3 Simplified structure of an encapsulator

[0171] Finally, in relation to Figure 14, we present the simplified structure of an encapsulator according to at least one embodiment described above.

[0172] Such an encapsulator comprises at least one memory 141 comprising a buffer memory, at least one processing unit 142, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program 143, implementing steps of the method for distributing multimedia content according to at least one embodiment of the invention.

[0173] At initialization, the code instructions of the computer program 143 are for example loaded into a RAM memory before being executed by the processor of the processing unit.

[0174] 142.

[0175] The processor of the processing unit 142 implements steps of the method for distributing multimedia content described previously, according to the instructions of the computer program.

[0176] 143, to: obtain said multimedia content, obtain at least one session identifier representative of at least one identifier associated with said multimedia content and / or at least one object identifier representative of at least one identifier associated with at least one file representative of said multimedia content, generate a transport stream comprising transport packets constructed from said multimedia content, said transport packets carrying a header specific to a transport protocol considered, said header comprising at least one session identification field carrying said at least one session identifier and / or at least one object identification field carrying said at least one object identifier.

Claims

CLAIMS 1. Method for distributing multimedia content, implemented in an encapsulator (321, 322) of a distribution network intended to implement at least two encapsulators, characterized in that it implements the following steps: - obtaining (51) said multimedia content, - obtaining (52) at least one session identifier representative of at least one identifier associated with said multimedia content and / or at least one object identifier representative of at least one identifier associated with at least one file representative of said multimedia content, - generation (53) of a transport stream comprising transport packets constructed from said multimedia content, said transport packets carrying a header specific to a transport protocol considered, said header comprising at least one session identification field carrying said at least one session identifier and / or at least one object identification field carrying said at least one object identifier.

2. Method according to claim 1, characterized in that said at least one identifier associated with said multimedia content belongs to the group comprising: - a type of said multimedia content, - at least part of a name of said at least one file representative of said multimedia content, - metadata associated with at least one file representing said multimedia content, - a combination of at least two pieces of information from among said type, said at least one part of a name, and said metadata.

3. Method according to any one of the preceding claims, characterized in that said session identifier belongs to the group comprising: - said at least one identifier associated with said multimedia content, - a function of said at least one identifier associated with said multimedia content, - a value.

4. Method according to any one of the preceding claims, characterized in that said at least one identifier associated with said at least one file belongs to the group comprising: - at least part of a name of said at least one file, - at least part of a binary content of said at least one file, - metadata associated with at least one file, - a combination of at least two pieces of information among said at least one part of a name, said at least one part of a binary content and said metadata.

5. Method according to any one of the preceding claims, characterized in that said object identifier belongs to the group comprising: - said at least one identifier associated with said at least one file, - a function of said at least one identifier associated with said at least one file, - a value.

6. Method according to any one of the preceding claims, characterized in that said transport protocol belongs to the group comprising: - the FLUTE protocol, - the ROUTE protocol, - the M MT protocol, - the QUIC multicast protocol, - the NORM protocol, - the HLS protocol.

7. Method according to any one of the preceding claims, characterized in that said transport protocol considered is the FLUTE protocol or the ROUTE protocol, and in that said session identification field is the “Transport Session Identifier” field of the LCT header, and said object identification field is the “Transport Object Identifier” field of the LCT header.

8. Encapsulator of a distribution network intended to implement at least two encapsulators for the distribution of multimedia content, comprising at least one processor configured to: - obtain said multimedia content, - obtain at least one session identifier representative of at least one identifier associated with said multimedia content and / or at least one object identifier representative of at least one identifier associated with at least one file representative of said multimedia content, - generating a transport stream comprising transport packets constructed from said multimedia content, said transport packets carrying a header specific to a transport protocol considered, said header comprising at least one session identification field carrying said at least one session identifier and / or at least one object identification field carrying said at least one object identifier.

9. Distribution system implementing at least two encapsulators according to claim 8, each delivering a transport stream, such that said at least one session identification field and / or said at least one object identification field of the different transport streams are aligned.

10. System according to claim 9, characterized in that said encapsulators implement different transport protocols.

11. A computer program comprising program code instructions for implementing a method according to any one of claims 1 to 7, when said program is executed on a computer.

Images