EP4320871A1

EP4320871A1 - Methods and devices for inserting an event into a transport flow, for monitoring, managing and receiving the transport flow, and computer program all corresponding thereto

Info

Publication number: EP4320871A1
Application number: EP22721337.8A
Authority: EP
Inventors: David Vincent
Original assignee: Telediffusion de France ets Public de Diffusion; Enensys Technologies SA
Current assignee: Telediffusion de France ets Public de Diffusion; Enensys Technologies SA
Priority date: 2021-04-09
Filing date: 2022-04-07
Publication date: 2024-02-14
Also published as: FR3121809A1; WO2022214586A1; FR3121809B1

Abstract

Methods and devices for inserting an event into a transport flow, for monitoring, managing and receiving the transport flow, and computer program all corresponding thereto. The invention relates to a method for monitoring a transport flow at the output of an equipment of a broadcast network, implementing at least one iteration of the following steps: - obtaining (61) the transport flow delivered by said equipment, - detecting (62) a current event packet associated with content carried by said transport flow, said event packet carrying a synchronization header comprising: - reference time information defined with respect to a reference clock of said content; - a desired delay between said current event packet and a reference packet of said content identified based on said reference time information, - determining (63) an offset between an actual position of said current event packet in said transport flow and a desired position of said current event packet in said transport flow, determined based on said reference time information and on said desired delay, called processing offset.

Description

DESCRIPTION

TITLE: Methods and devices for inserting an event into a transport stream, monitoring, managing and receiving the transport stream, and corresponding computer program.

1. Field of the invention

The field of the invention is that of broadcasting information, in particular television services, in a broadcasting network.

More specifically, the invention relates to the broadcasting of events, making it possible to trigger actions linked to content broadcast in the broadcasting network, for example video content.

In particular, the invention proposes a solution making it possible to improve the synchronization of an event with the content to which it relates, in particular at the level of a receiver.

The invention applies in particular, but not exclusively, to the broadcasting of a transport stream according to the DVB-T or DVB-T2 standards (in English "Digital Video Broadcasting - Terrestrial"), DVB-S or DVB-S2 (in English "Digital Video Broadcasting - Satellite"), or DVB-C (in English "Digital Video Broadcasting - Cable").

2. Prior Art

Today there are solutions that make it possible to benefit from interactive services with the programs of the television channels.

In particular, it is possible to transmit, in a transport stream carrying one or more contents, information related to one or more application(s) intended to be executed by a receiver, in particular allowing the receiver to benefit from additional content.

2.1 Events

Such information includes in particular events, making it possible to trigger actions linked to these applications.

These events can be used to allow synchronization between interactive data and the video and/or audio components of transport stream content, for example to synchronize the display of graphic elements in addition to a video (for example a “pop-up”), replacing an advertisement with targeted advertising, inserting a subtitle or replacing it with another, etc.

These events are for example of the "Stream Event" or SE type, in the DSM-CC format (for "Digital Storage Media Command and Control"), as defined in the ISO/IEC 13818-6 standard: "Information technology - Generic coding of moving pictures and associated audio information - Part 6: Extensions for DSM-CC”.) These events can be received by receivers compatible with HbbTV (Hybrid Broadcast Broadband TV) standards, also called hybrid or connected receivers, which represent the vast majority of connectable televisions on the market today.

Thus, the HbbTV standard, as defined in the technical specification ETSI TS 102796 VI.4.1, describes the signalling, transport and signaling of such interactive applications intended to be executed by a hybrid receiver, and in particular of events associated with such apps. Examples of applications are presented in particular in the technical specification ETSI TS 102 809 (VI.3.1): “Digital Video Broadcasting (DVB); Signaling and carriage of interactive applications and services in Hybrid Broadcast/Broadband environments”.

2.2 Inserting an event into a transport stream

The insertion of an event into a transport stream, for example an MPEG-TS stream (standing for “Moving Picture Experts Group—Transport Stream”), is described below.

Conventionally, a first encoder of a network head receives source data as input and delivers a first MPEG-TS stream as output. A second encoder receives other source data as input and delivers a second MPEG-TS stream as output. Such encoders can also receive commands in SCTE 104 format and convert them to SCTE 35 format.

Each "elementary" MPEG-TS stream (i.e. from an encoder) is composed of a set of transport packets (TS), including audio, video and/or subtitle packets, etc. These different packets carry time information defined with respect to a reference clock associated with the “elementary” MPEG-TS stream, for example a clock signal PCR (in English “program clock reference”) or TEMI (in English “Timed External Media Information”), For example, a video packet carries a PTS (“Presentation Time Stamp”) and/or DTS (“Decoding Time Stamp”) value corresponding to a time of presentation and/or decoding of a image coded in this video packet, with respect to the reference clock associated with the “elementary” MPEG-TS stream.

The "elementary" MPEG-TS streams obtained at the output of the various coders can be multiplexed by a multiplexer of the network head. At the output of the multiplexer, a “global” MPEG-TS stream is therefore obtained encapsulating several “elementary” MPEG-TS streams, in which all the TS packets are mixed.

In particular, at least one event can be defined in relation to an "elementary" MPEG-TS stream (for example an off-hook order, a graphic element to be added to an image of the content carried by the "elementary" MPEG-TS stream, etc). Such an event, for example an event in SCTE 35 format obtained at the output of the encoder, can in particular be converted into “Stream Event”, as described in patent application WO2019/011655. In particular, this patent application proposes using the time information obtained from an SCTE 35 type command, for example, to position an event in a transport stream and establish a fine synchronization between the event and a point of reference of the "elementary" MPEG-TS stream.

Such an event can be inserted in the form of an event packet in the MPEG-TS stream, in a relative manner with respect to a reference packet of the “elementary” MPEG-TS stream. Such an event packet is therefore a TS packet.

FIG. 1 illustrates an example of MPEG-TS stream 11 received by a receiver. The TS packets 111, 112, and 113 are for example useful packets of an “elementary” MPEG-TS stream. Event packet 110 may carry an event relating to the “elementary” MPEG-TS stream. For example, the event packet is a TS packet carrying a Stream Event in DSM-CC format defining one or more actions related to the content carried by the “elementary” MPEG-TS stream.

Conventionally, an “insertion pre-roll” is defined for an event, corresponding to a desired delay between the insertion of the command and a point in the elementary MPEG-TS stream signaled by the event. This positioning in advance allows the receivers to prepare the actions to be carried out when receiving the event. An early reception implies that the insertion pre-roll value is known by the receiver.

According to the example illustrated in FIG. 1, such an insertion pre-roll 12 corresponds to a desired delay, conventionally expressed in milliseconds, between the position of the event packet 110 in the MPEG-TS stream and the position of a reference packet 111 of the “elementary” MPEG-TS stream in the MPEG-TS stream. For example, the desired position for inserting the event packet 110 into the MPEG-TS stream can be of the order of 100 ms before the reference packet 100 corresponding to the first packet of a target image identified by its PTS value. , based on the reference clock serving as a reference for the PTS used.

However, it can be seen in FIG. 1 that there is an offset 13 between the actual position of the event packet 110 in the MPEG-TS stream (which corresponds for example to the time of reception, by the receiver of the MPEG-TS stream 11, of the first byte of event packet 110) and the desired position of event packet 110 relative to reference packet 111 (referenced 114).

Such an insertion offset therefore corresponds to an undesired offset between the target and actual insertion positions of the event packet in the MPEG-TS stream.

This shift can be caused by operations performed on the MPEG-TS stream: insertion of the "stream event", multiplexing, transcoding, remultiplexing (which can modify the scheduling of TS packets), use of an error correcting code (FEC or “Forward Error Correction”) in equipment, etc.

In particular, the structure of the broadcast network and/or the nature of the equipment traversed by the MPEG-TS stream may introduce a lag between the FlbbTV components (for example of the Stream Event type) and video (or audio, subtitle, etc. ) of an MPEG-TS stream. For example, a transcoder may introduce a delay of several seconds. Similarly, using error-correcting code can add hundreds of milliseconds of latency.

In particular, such a shift can change if the broadcast network is changed over time.

Moreover, such a shift may be different from one subnet to another. For example, for the same content broadcast in DTT and satellite, the delay may be different for the two broadcast modes, since they do not use the same network structure and do not use the same equipment.

Moreover, an additional delay can also be introduced by the receiver between the display of a reference image and the reception of the event defined from this reference image at the level of the FlbbTV application. This offset may vary from one receiver model to another.

A disadvantage linked to this or these offsets is the desynchronization between the event and the “elementary” MPEG-TS stream to which it relates, at the level of a receiver.

Indeed, the PTS/DTS and SCTE commands are not accessible by an FlbbTV application. Events according to the FlbbTV standard therefore do not carry a time reference, such as a presentation instant (PTS) or a decoding instant (DTS), which would allow fine synchronization, at receiver level, of the event (or more generally of the FlbbTV component) with a video (or audio, subtitle, etc.) component of the “elementary” MPEG-TS stream to which it relates. In other words, a receiver has no information between the event and the component of the “elementary” MPEG-TS stream with which it is associated.

Even if an event has been inserted into the MPEG-TS stream to ensure synchronization between the event and the component to which it relates, as described in patent application WO2019/011655 for example, the synchronization may be altered. by the offset(s) introduced by the broadcast network or the receiver. There is therefore a need for a new technique making it possible to improve the synchronization between an event and the component of the transport stream to which it relates, at the level of a receiver.

3. Disclosure of Invention

The invention proposes, in at least one embodiment, a solution not having all the drawbacks of the prior art, in the form of a method for monitoring a transport stream at the output of an equipment of a broadcast network. For example, such equipment, called equipment to be monitored, can be a multiplexer, a gateway, a transcoder, etc.

According to the invention, such a method implements at least one iteration of the following steps: obtaining the transport stream delivered by said equipment, detection of a current event packet associated with a content carried by the transport stream, the event packet carrying a synchronization header comprising: reference time information defined with respect to a reference clock of said content; a desired delay between said current event packet and a reference packet of said content identified from said reference time information, determining an offset between an actual position of said current event packet in said transport stream, and a desired position of said current event packet in said transport stream, determined from said reference time information and from said desired delay, called processing offset.

The proposed solution thus makes it possible to measure, during the broadcast of the transport stream in the broadcast network, an offset introduced by at least one piece of equipment of the broadcast network, for example a multiplexer, a broadcast gateway, a transcoder, etc. . It is thus possible to compensate for this offset before continuing to broadcast the transport stream in the network or to inform the other devices of the broadcasting network. It is also possible to take this offset into account when inserting subsequent event packets into the transport stream.

In particular, the equipment to be monitored can be equipment placed at the end of the broadcast network (for example a broadcast gateway), so as to determine the offset introduced by the whole of the broadcast network.

To do this, at least one current event packet carrying specific information is detected in the transport stream at the output of the equipment to be monitored. Thanks to this specific information, it is possible to determine a desired, or theoretical, position of the current event packet in the transport stream with respect to a reference point of the content. He is it is also possible to measure the actual position of the current event packet in the transport stream at the output of the equipment to be monitored with respect to this reference point, and to determine an offset between the actual position of the current packet and its desired position in the transport stream. This lag, introduced in particular by the processing of the transport stream up to the equipment to be monitored, is hereinafter called “processing lag”.

Knowing this processing lag, different actions can be executed.

For example, this processing offset can be: stored in a memory of the monitoring device, transmitted to at least one other piece of equipment in the broadcasting network (event insertion device, service platform storing the different offset values, etc. ), directly or by modifying a field of the synchronization header of the current event packet, used to correct the position of the current event packet in the transport stream, so that the desired position of the current event packet and its real position coincides; used to insert at least one next event packet into the transport stream, at a position such that the desired position of the next event packet and its actual position coincide, etc.

In this way, it is possible to improve the synchronization between an event packet and the reference point of the content to which it relates, in particular at the level of a receiver receiving the data stream.

Such steps can in particular be implemented in a device for monitoring a transport stream. The invention therefore also relates to a corresponding monitoring device.

Such a monitoring device, also called SE monitoring, is in particular suitable for implementing the monitoring method described above. It could of course include the different characteristics relating to the monitoring method according to the embodiment of the invention, which can be combined or taken separately. For example, such a device can be integrated with an event insertion device, with a gateway or with any other equipment of the broadcasting network.

The invention also relates to a method for inserting an event into a transport stream intended to be broadcast in a broadcast network.

According to the invention, such a method implements the following steps: obtaining said transport stream, inserting, into said transport stream, at least one current event packet associated with a content carried by said transport stream, said current event packet carrying a synchronization header comprising: information reference time defined with respect to a reference clock of said content; a desired delay between said current event packet and a reference packet of said content identified from said reference time information, said current event packet being inserted into said transport stream at a position defined from the position of said reference packet and said desired delay.

The proposed solution thus makes it possible to insert, in the transport stream, particular event packets, which can be used to measure an offset introduced by the broadcasting network.

In particular, an event packet according to the invention carries reference time information defined with respect to a reference clock of the content, for example a PTS value associated with a reference image of the content defined with respect to a signal of clock embedded in the content (a PCR, a TEMI, etc.). Such an event packet also carries a desired delay between the current event packet and a reference packet of the content identified from the reference time information, for example the packet carrying the reference image. Such a desired delay corresponds for example to an insertion pre-roll.

Thanks to this specific information, it is possible to determine a desired, or theoretical, position of the current packet in the transport stream with respect to a reference point of the content. It is also possible to measure the real position of the current packet in the transport stream with respect to this reference point, at the output of a broadcast network device, and to determine the processing lag between the real position of the current packet and its desired position in the transport stream.

Such steps can in particular be implemented in a device for inserting an event into a transport stream. The invention therefore also relates to a device for inserting a corresponding event.

Such a device for inserting an event into a transport stream, also called inserter SE, is in particular suitable for implementing the method for inserting an event described above. It may of course include the different characteristics relating to the insertion process of an event according to one embodiment of the invention, which can be combined or taken separately.

For example, such a device can be integrated into a multiplexer or any other equipment of the broadcasting network.

The invention also relates to a method for managing a transport stream broadcast in a broadcast network.

According to the invention, such a method implements the following steps: obtaining at least one shift among: o at least one shift between a real position of a current event packet in said transport stream, at the output of equipment of the broadcasting network, and a desired position of said current event packet in said transport stream, called processing offset, o an offset determined according to a type of receiver intended to receive said transport stream, called reception offset, said current event packet being associated with a content carried by said transport stream, and carrying a synchronization header comprising: reference time information defined with respect to a reference clock of said content; a desired delay between said current event packet and a reference packet of said content identified from said reference time information, said desired position being determined from said reference time information and said desired delay, transmission, at least another equipment of said broadcasting network, of said at least one shift obtained, or of a global shift determined from said at least one shift obtained.

The proposed solution thus makes it possible to collect in the same equipment, for example a service platform, at least one offset value linked to the use of at least one equipment of the broadcasting network or of the receiver.

In this way, it is possible to centralize the shift value(s) obtained, possibly to average the shift value(s) obtained, possibly to determine a global shift value from the (averaged) shift value(s) obtained, and to inform at least one device of the broadcast network, for example the inserter SE. It is thus possible to improve the precision of insertion of the events in the transport stream, and therefore the synchronization of the events with the contents/components to which they relate, in particular at the level of the receiver.

The invention also relates to a corresponding service platform.

Such a service platform, for example of the AdsReach ^® type as developed by the company ENENSYS TECHNOLOGIES ^® , is in particular suitable for implementing the management method described above. It could of course include the different characteristics relating to the management method according to one embodiment of the invention, which can be combined or taken separately.

The invention also relates to a method for receiving a transport stream broadcast in a broadcasting network.

According to the invention, such a method implements the following steps: reception of a transport stream carrying at least one current event packet associated with a content carried by said transport stream, said current event packet carrying a synchronization header comprising: o reference time information defined with respect to a reference clock of said content, o a desired or actual delay between said current event packet and a reference packet of said content identified from said time information of reference, synchronization of an event carried by payload data of said current event packet with a reference point (for example a reference image) associated with said reference time information, taking into account a determined waiting period from said synchronization header of said current event packet.

The proposed solution thus makes it possible, at the level of a receiver, to synchronize an event with the content to which it relates.

The invention also relates to a corresponding receiver.

Such a receiver is in particular suitable for implementing the reception method described above. It could of course include the different characteristics relating to the reception method according to one embodiment of the invention, which can be combined or taken separately. In particular, such a receiver is a hybrid receiver, compatible with the HbbTV standard.

The invention also relates to a corresponding system, comprising at least one inserter SE and one monitoring SE (possibly combined with the inserter SE). Preferably, such a system also comprises a service platform making it possible to store the various offsets and a receiver according to the invention.

The various methods according to at least one embodiment of the invention can be implemented in various ways, in particular in hardware form and/or in software form.

For example, at least one step of the methods described above can be implemented: on a reprogrammable calculation machine (a computer, a processor for example DSP (in English “Digital Signal Processor”), a microcontroller, etc.) executing a program comprising a sequence of instructions, on a dedicated calculation machine (for example a set of logic gates such as an FPGA (in English “Field Programmable Gate Array”) or an ASIC (in English “Application-Specific Integrated Circuit”) , or any other hardware module).

Consequently, an embodiment of the invention also aims to protect one or more computer programs comprising instructions adapted to the implementation of the methods described above when this or these programs are executed by a processor, as well as at least one computer-readable information carrier comprising instructions of at least one computer program as mentioned above.

4. List of Figures

Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given by way of a simple illustrative and non-limiting example, and the appended drawings, among which:

[Fig 1] Figure 1 illustrates an example of an MPEG-TS stream received by a receiver;

[Fig 2] Figure 2 illustrates an example of a broadcast network in which the invention can be implemented;

[FIG 3] FIG. 3 presents the main steps implemented by a device for inserting an event according to one embodiment of the invention;

[Fig 4] Figure 4 illustrates the structure of a measurement event packet according to one embodiment of the invention;

[Fig 5] Figure 5 illustrates the structure of a payload event packet according to one embodiment of the invention;

[FIG 6] FIG. 6 presents the main steps implemented by a device for monitoring a transport stream at the output of equipment of the broadcasting network according to one embodiment of the invention;

[FIG 7] FIG. 7 presents the main steps implemented by a service platform according to one embodiment of the invention; [Fig 8] Figure 8 shows the main steps implemented by a receiver according to one embodiment of the invention;

[Fig 9] Figure 9 illustrates an example of a broadcast network implementing a transcoder; [Fig 10] FIG. 10 illustrates an example of implementation of synchronization at the head end of the network according to a particular embodiment;

[FIG 11] FIG. 11 illustrates the simplified structure of an inserter SE, of a monitoring SE, of a service platform, or of a receiver according to one embodiment of the invention.

5. Description of embodiments of the invention

5.1 General principle

As already indicated in relation to the prior art, there is conventionally, at the end of the broadcasting chain (at the level of the last equipment of the broadcasting network or of a receiver), a lag between the real position of an event and its desired position, defined relative to a reference point of the content to which the event relates.

Such a shift can be made up of several shifts originating from: all the variations introduced by the broadcasting network (transport, (re)multiplexing, transcoding, etc. the delay in processing the event and decoding the stream of transport by the receiver.

The general principle of the invention is based on the determination of at least one of these offsets, and the compensation of this or these offsets.

The proposed solution thus makes it possible to synchronize, or to maintain synchronization, of an event with a reference point of a content, carried by a transport stream, signaled by this event. It can in particular be used to ensure the synchronization of events of the content substitution type (for example in HbbTV), display of banners, in particular L-shaped (in English “L-Banner”), etc.

According to at least one embodiment, the proposed solution makes it possible to: determine an offset (possibly an average offset) between a desired date/position of the event, and an actual date/position of insertion of the event, for example at the end of the broadcast chain (at the level of the last equipment of the broadcast network

- also called end equipment - or a receiver), and/or continuously measure this offset value and automatically adapt the correction for inserting the event into the transport stream according to the evolution of the network , and or address several sub-networks with different offsets (since they do not use the same network structure and not the same equipment) and/or receivers with different characteristics, and therefore adapt the synchronization by compensating for the offsets introduced by the network and/or the receiver, and this even if the delays vary from one part of the network to another or from one receiver to another, and/or taking into account the synchronization deviations as far as the receiver.

5.2 Description of main equipment

A. General Architecture

The operation of the various modules implemented by the invention is presented below, for the transmission of event packets of the “Stream Event” type in the DSM-CC format in a transport stream in the MPEG-TS format. Of course, the invention is not limited to this type of event or transport stream formats.

In order to illustrate the invention, we place ourselves in the context of the broadcast network of FIG. 2, implementing: a network head 21, comprising at least one encoder 211 and a multiplexer 212, taking as input at least one content to be broadcast (for example a service A) and outputting a transport stream TS, and two broadcasting sub-networks, broadcasting the transport stream TS to receivers 24, 25, comprising: o a first sub-network of satellite broadcasting 22 implementing a satellite 221, a multiplexer 222 and a gateway 223, o a second terrestrial broadcasting sub-network 23 implementing a gateway 231.

The receiver 24 receives for example the transport stream broadcast by the first satellite broadcasting sub-network 22, and the receiver 25 receives the transport stream broadcast by the second terrestrial broadcasting sub-network 23.

The transport stream can be composed of several contents, each content embedding its own reference clock.

Of course, such a network structure is purely illustrative.

According to an advantageous embodiment, in order to maintain optimal synchronization from the insertion of the event until its use, the proposed solution can use several modules making it possible to estimate the variations introduced and to correct them: - an event insertion device 213, also called SE inserter, inserting event packets SE into the transport stream TS coming from the multiplexer 222, and

- at least one device for monitoring a transport stream at the output of broadcast network equipment, also called SE monitoring (for example integrated into the event insertion device 213 and configured to monitor the transport stream at the output of the multiplexer 222, or located at another place in the network and configured to monitor the transport stream at the output of a gateway, a transcoder, etc., of the network); in the example illustrated in FIG. 2, the gateways 223 and 231 are each equipped with a monitoring device 2231 and 2311.

Optionally, a service platform 26 can also be provided to collect or supply information on the various equipment items of the network and on the receivers.

Finally, a specific application can be executed by receivers 24 and 25.

The use of some of these modules (in particular the use of several monitoring devices, of a service platform, or of specific applications at the level of the receivers) is optional, in particular if the precision of the desired synchronization is low.

B. Device for inserting an event into a transport stream (SE Inserter)

In relation to FIG. 3, the main steps implemented by the device for inserting an event 213, also called inserter SE, are presented. The inserter SE can be dedicated equipment or a software module embedded in another equipment, for example in the encoder 211 or the multiplexer 212 of the network head.

Such a device makes it possible to insert event packets into the transport stream

Thus, during a first step 31, the inserter SE obtains a transport stream. At the first iteration, the transport stream carries no event packets. On subsequent iterations, the transport stream may optionally carry one or more event packets inserted during a previous iteration.

For example, the inserter SE takes as input the transport stream from the multiplexer 212, carrying one or more contents, or directly a transport stream from the encoder 211, generally carrying a single content, and delivers as output the transport stream carrying at least one current event packet associated with content. Optionally, it takes as input information making it possible to identify a reference point in the content (message of SCTE 35 type, watermark, etc.).

Subsequently, for the sake of simplification, it is considered that the transport stream carries a single content (for example the service A). Similar steps can be implemented for each content carried by the transport stream. The inserter SE generates at least one event packet from a content reference point (eg service A) carried by the transport stream.

More precisely, such a current event packet carries a synchronization header comprising: reference time information defined with respect to a reference clock of the content; a desired delay between the current event packet and a reference packet of the content identified from the reference time information.

For example, if the reference point is a reference image, the reference time information corresponds to a restitution date (for example a PTS value) of the reference image of the content carried by the transport stream, in reference to a reference clock (for example a PCR or TEMI clock) embedded in the content, and the reference packet is for example the first packet encoding the reference image. In particular, the reference image is an IDR (Instantaneous Decoder Refresh) image.

During a second step 32, the inserter SE inserts the current event packet into the transport stream, at a position defined from the position of the reference packet and the desired delay. The inserter SE therefore seeks to ensure, during the insertion, the synchronization of the event packet with the content to which it relates.

According to a first embodiment, a current event packet can be a measurement event packet inserted by the inserter SE to measure the offset(s) introduced by the various equipment items of the network.

According to a second embodiment, a current event packet can be a payload event packet carrying payload data associated with the event.

These two embodiments, described in more detail below, can be combined. For example, measurement event packets can be inserted at the beginning of the transport stream broadcast to determine the offsets to be corrected, then useful event packets can be inserted during the transport stream broadcast to maintain the synchronization.

The transport stream into which at least one current event packet has been inserted can then be broadcast in the broadcast network, or returned to the input of the multiplexer 212.

As described below, the current event packet inserted into the transport stream can be used by one or more monitoring devices distributed in the broadcast network to measure the offset(s) introduced by the network, called processing offsets. The processing offset(s) obtained may optionally be transmitted to the inserter SE 213, directly or via another device, for example the services gateway 26, so that it modifies the position of the current event packet in the transport stream to compensate for the processing lag(s), or that it can insert a next event packet into the transport stream in anticipation of that processing lag.

Thus, according to a particular embodiment, the inserter SE 213 obtains during a step 33 a processing offset D1 between a real position of the current event packet in the transport stream, at the output of a device to be monitored of the broadcast network (for example the multiplexer 212, the gateway 231, the gateway, 223, etc.), and a desired position of the current event packet in the transport stream, determined from the reference time information and the desired time.

The inserter SE can in particular determine this offset value itself (for example if it has a monitoring device), or receive this offset value from a network monitoring device (for example the monitoring SEs 2231 or 2311), directly or via the service platform 26, for example in the form of notifications.

Obtaining this processing shift by the inserter SE 213 makes it possible in particular to correct the position of the current event packet in the transport stream, or to insert a following event packet in the transport stream at a desired position. , so as to compensate for a processing offset introduced by at least one network device (multiplexer 212, gateway 223, gateway 231, etc.).

This shift can in particular be transmitted to another piece of equipment in the broadcast network, for example to the service platform 26.

In particular, the inserter SE 213 can determine an "average" processing offset upon receipt of several processing offset values from the same monitoring device, or directly receive an "average" processing offset.

According to a particular embodiment, the inserter SE 213 can also implement the reception 34 of a reception offset D2 determined as a function of a type of receiver intended to receive the transport stream.

For example, the characteristics of different receivers according to their type (for example according to their brand, their model) can be determined during laboratory tests and stored in a database. Such a database can be accessible to the inserter SE 213, directly or via the services platform 26. In this way, it is also possible to estimate the offset introduced by the receiver between the display of the reference image and the reception of the event packet, at the level of the HbbTV application for example, and to compensate for this offset.

Note that these steps for obtaining a processing offset 33 or a reception offset 34 are optional, and can be implemented independently of one another.

The inserter SE thus has the possibility of receiving notifications from the service platform or from a network monitoring device, carrying at least one processing offset or reception offset value.

The offset(s) obtained, possibly averaged, can be used by the inserter SE to modify the position of the current event packet in the transport stream and/or to insert a following event packet into the transport stream at a position making it possible to ensure synchronization between the event and the reference point to which it refers, by compensating for the offset(s) obtained. In particular, a following event packet can be a “classic” event packet, in DSM-CC format for example, not carrying a synchronization header. It can in particular be associated with a content distinct from the current event packet.

For example, the inserter SE integrates a value of processing offset or reception offset during the insertion of an event packet by adding the value received to the initially planned offset during the insertion. This is intended to achieve correct synchronization of the event packet at broadcast time by compensating for network actions on the position of the event packet relative to the reference point with which it is synchronized.

This feedback loop can be permanent, which makes it possible to maintain synchronization even if certain parameters of the broadcasting network are modified, or implemented occasionally (for example during the installation of the network, when adding a new equipment in the network, at regular time intervals (once a week, once a month, etc.), when a loss of synchronization is detected, etc.

In summary, the inserter SE can execute at least one action among: inserting at least one event packet (measurement event packet, useful event packet synchronized with the content to which it relates); correct the synchronization during the insertion of an event packet, by compensating for the delays in processing and/or reception; etc

C. Event Packages As noted above, different event packets can be used to measure the offset(s) and improve synchronization.

Thus, according to a first embodiment, a current event packet can be a measurement event packet inserted by the inserter SE to measure the offset(s) introduced by at least one network device. In this case, the inserter SE takes as input the transport stream coming from the multiplexer 212, or from the encoder 211, and delivers as output a transport stream carrying at least one measurement event packet.

For example, the inserter SE selects an image in the content, called the reference image. This image can be selected randomly. The inserter SE reads the PTS value associated with this reference image, and stores it in the “reference time information” field of the synchronization header of the measurement event packet. The inserter SE inserts the measurement event packet just before the first packet carrying the reference image, called the reference packet, and stores a zero value in the “desired delay” field. Alternatively, the inserter SE replaces a stuffing packet in the transport stream with the measurement event packet, and stores in the "desired delay" field a value corresponding to the number of TS packets using the same reference clock (i.e. associated with the same content) between the padding packet replaced by the measurement event packet and the first packet carrying the reference image.

It is noted for this purpose that this shift or delay can be calculated in number of packets TS based on the clock used for the reference time information. For example, the offset is calculated in number of TS packets belonging to the same content. Alternatively, the offset can be calculated in number of TS packets belonging to the transport stream. In this case, if the increment of the clock value between two TS packets belonging to the same content is X ms, this value can be divided by the number of TS packets of the transport stream between two TS packets belonging to a same content. The use of all packets of the transport stream is therefore more precise, because each packet corresponds to a shorter duration.

The time conversion can be performed by multiplying the number of gap packets by the transmission duration of a TS packet.

The transmission duration of a packet can be calculated by counting the number of packets in the transport stream between two packets carrying a value of the same reference clock (PCR or TEMI for example).

In particular, a measurement event packet carries a synchronization identifier, allowing other network equipment or receivers to detect that it is a packet used for synchronization. FIG. 4 illustrates an example of the structure of such a measurement event packet, comprising an SE_H header 41 (“SE header”), and a useful part SE_P 42 (“SE payload”). The useful part 42 comprises only a synchronization header, for example carrying three fields: a SYNC field 421, for example on 4 bytes, carrying a synchronization identifier making it possible to identify that the event packet is used for synchronization. It can contain for example the value “ARSC” coded in ascii; a field D 422 (“Delai”, or “Delay ms”), for example on 2 bytes, carrying a desired delay between the measurement event packet and a content reference packet, identified from the time information reference (the reference packet being for example the first packet carrying the reference image whose PTS value is present in the PTS field 423); such a delay or offset is expressed in particular in time (for example in milliseconds or in nanoseconds) to be able to be used by the receivers, a PTS field 423, for example over 5 bytes, carrying reference time information defined with respect to a reference clock embedded in the content (for example the PTS value of the reference image).

Such a useful event packet can be used by the successive devices of the network to measure the shift(s), introduced by the various devices of the network, between the actual position of the useful event packet (Stream Event) and its desired position.

In particular, such a measurement event packet carries a packet identifier (PID, in English “Packet Identifier”) indicating that it is of the event packet type, or a ghost PID. Conventionally, a phantom PID is not referenced in any flow description table (PAT, PMT). It is therefore only interpretable by equipment that has been specifically configured to use it, and ignored by other equipment.

In particular, the inserter SE uses the same PID for the event packet and the payload packets of a content. In this way, we are freed from potential problems of implementation of certain equipment. For example, if a device uses one queue per PID as input, the processing of the queues may be different. If the event packet and the useful packets of the same content carry the same PID, they are processed in the same way by the equipment, which makes it possible to ensure an accurate measurement of the delay.

According to a second embodiment, a current event packet can be a payload event packet carrying payload data associated with an event. In this case, the inserter SE takes as input the transport stream from the multiplexer 212, or the content from the encoder 211, and a information making it possible to select a reference image in the content (SCTE 35 type message, watermark, etc.), and outputs a transport stream carrying at least one useful event packet. For example, the inserter OS selects a content reference image.

According to this second embodiment, the inserter SE inserts, into the transport stream, at least one useful event packet synchronized with the content to which it relates.

According to a first variant, the reference image can be identified from an SCTE 35 type message. Indeed, the inserter SE can receive on its input the transport stream coming from the multiplexer 212 and SCTE example of the “time-signal” or “splice insert” type) containing PTSs that reference images. Such SCTE messages 35 can be sent in pre-roll, for example a few seconds before the image that they reference. Synchronization can be performed when converting SCTE messages into event packets, using the PTS value of the reference picture and the PCR of the content.

According to a second variant, the reference image can be identified from a watermark carried by the reference image. In this case, the inserter SE seeks to detect, in the content, an image bearing a watermark known to the inserter SE (“video fingerprint”). This variant makes it possible to dispense with SCTE messages 35, but requires knowledge of the watermarks associated with the images to be detected. It may also be necessary to add storage in buffer memory (also called “buffering”) of the transport stream, in order to allow insertion of a useful event packet upstream of a reference image.

The inserter SE reads the PTS value associated with this reference image, and stores it in the “reference time information” field of the synchronization header of the useful event packet.

The inserter SE inserts the useful event packet taking into account the desired delay between the useful event packet and the reference packet (value chosen by the inserter SE, insertion pre-roll value, or value measured at a previous iteration for example).

In particular, such a useful event packet carries a synchronization identifier, allowing the other network equipment or the receivers to detect that it is a packet used for synchronization.

FIG. 5 illustrates an example of the structure of such a useful event packet, comprising an SE_H header 51 (“SE header”), and a useful part SE_P 52 (“SE payload”). The useful part 52 comprises a synchronization header and useful data 525, for example private data describing the event.

The synchronization header includes for example four fields: a SYNC field 521, for example on 4 bytes, carrying a synchronization identifier making it possible to identify that the event packet is used for synchronization. It can contain for example the value “ARSU” coded in ascii; an Ins control. pos. 522, for example on 2 bytes, carrying a desired delay between the useful event packet and a reference packet of the content identified from the reference time information (the reference packet being for example the first packet carrying the reference image whose PTS value is present in the PTS field 524). Such a delay or offset is expressed in particular in time (for example in milliseconds or in nanoseconds) to be able to be used by the receivers, a PTS field 524, for example over 5 bytes, carrying reference time information defined with respect to a reference clock embedded in the content (for example the PTS value of the reference image), possibly a field G 523 ("gap"), for example on 2 bytes, carrying a measured offset value between the desired position of the useful event packet (determined from the Ins. Pos. field) and its actual position in the transport stream. Such a delay or shift is expressed in particular in time (for example in milliseconds or in nanoseconds) to be able to be used by the receivers. In particular, if the event packet is inserted at the right place in the transport stream (i.e. its actual position coincides with its desired position), the value of this field is equal to 0.

In particular, the values of the Ins fields. pos. 522 and G 523 can be updated throughout the broadcast chain, for example by monitoring devices, and used by the receiver to correct synchronization.

A useful event packet can be used by the successive devices of the network to measure the offset(s), introduced by the various devices of the network, between the actual position of the useful event packet (Stream Event) and its desired position.

In particular, at a receiver, a useful event packet may include, in the Ins field. Pos., an offset value in milliseconds between the reception of the useful event packet (actual position of the event packet) and the actual position of the display of the reference image signaled by the event packet (position of the reference package). Knowledge of this value notably enables the receivers to delay the launching of an action upon receipt of the useful event packet. As already indicated, for the offset measurement, this value can be expressed in TS packets. On the other hand, it can be converted into time (for example millisecond or nanosecond) to be used by a receiver.

D. Monitoring device (SE monitoring)

As indicated above, certain broadcast network equipment, for example the inserter SE 213 and/or the gateway 223 of the first broadcast sub-network, and/or the gateway 231 of the second broadcast sub-network, etc.), can cooperate with a monitoring device, making it possible to determine the processing delay introduced by this equipment or by the network up to this equipment. For example, as illustrated in connection with Figure 2, the gateway 223 is monitored by the monitoring device 2231, and the gateway 231 is monitored by the monitoring device 2311. Other network equipment could also be monitored by a device surveillance, in particular equipment which modifies the transport stream by modifying the scheduling of the packets (multiplexer, transcoder for example).

In relation to FIG. 6, the main steps implemented by a monitoring device, also called SE monitoring, are presented. The monitoring SE can be dedicated equipment or a software module embedded by another equipment (for example the inserter SE 213 and/or the gateway 223 and/or the gateway 231).

During a first step 61, the SE monitoring obtains a transport stream delivered by the equipment to be monitored (i.e. the transport stream at the output of the equipment to be monitored, denoted TS+SE), carrying at least one packet current event.

During a following step 62, the monitoring SE searches, in the transport stream, for event packets bearing a synchronization header (measurement event packet(s) and/or event packet(s) useful). For example, the monitoring SE reads the SYNC field 421, 521 of an event packet and detects that it is an event packet used for synchronization.

As already described, such a current event packet, previously inserted by the inserter SE 213, is associated with content carried by the transport stream (for example, service A) and carries a synchronization header comprising: time information reference defined with respect to a reference clock of the content; a desired delay between the current event packet and a reference packet of the content identified from the reference time information,

From the information present in the synchronization header, the SE monitoring can determine 63 an offset between a real position of the current event packet in the flow of transport, and a desired position of the current event packet in the transport stream, called processing offset.

If we take the example illustrated in FIG. 1, the reference time information makes it possible to identify the reference packet 111. The desired delay between the current event packet 110 and the reference packet is defined by the pre -roll 12, and sets the desired position 114 of the current event packet in the transport stream. The offset between the actual position of the current event packet 110 and its desired position 114 corresponds to processing offset 13 (D1).

For example, if the current event packet detected is a useful event packet, the monitoring SE extracts the value of the PTS field 524, carrying the reference time information, and the value of the Ins field. pos. 522, carrying the desired delay between the useful event packet and a reference packet of the content identified from the reference time information.

The monitoring SE then seeks the position of the reference packet in the transport stream, i.e. the position of the packet (for example a video packet) containing the PTS value of the PTS field 524.

From the position of the reference packet and the value of the Ins field. pos. 522, the SE monitoring determines the desired (i.e. theoretical) position of the event packet, and the difference in number of TS packets between the actual position of the event packet and its desired position.

This deviation, corresponding to the processing offset, can optionally be stored in field G 523 of the synchronization header of the event packet, as described below.

The SE monitoring can transmit the processing offset thus determined to at least one other piece of equipment in the broadcasting network, for example in the form of a notification: to the SE inserter 213, to the service platform 26, to a piece of equipment downstream of the broadcast network, etc.

In this way, it is possible to inform the other devices on the network of the offset introduced by the device to be monitored in order to compensate for this offset value. Such compensation for the processing lag can be implemented: upstream of the equipment to be monitored, or in the equipment to be monitored, so that the event is synchronized with the content to which it relates in the transport stream at the output of the equipment to be monitored, or downstream of the equipment to be monitored, so as to correct the synchronization of the event in equipment downstream of the broadcast network.

According to a particular embodiment, the monitoring SE updates the synchronization header with the processing offset thus determined. For example, the value of the G field 523 is updated by replacing it with the processing offset D1. In this way, it is possible to inform the other equipment on the network of the processing lag introduced by the equipment at to watch. In particular, a CRC (for “Cyclic Redundancy Check”) can be recalculated for the event packet thus updated. Note that this update does not modify the position of the packets in the transport stream and therefore does not impact the values of the reference clock.

According to another embodiment, the SE monitoring implements a step of modifying the position of the current event packet in the transport stream taking account of the processing lag, and a step of transmitting the modified transport stream. In this way, it is possible to compensate for the processing lag before continuing to broadcast the transport stream.

For example, if the current event packet is a useful event packet, the monitoring OS reads the value of the Ins field. pos. 522, carrying the desired delay between the useful event packet and a reference packet of the content identified from the reference time information, and the PCR value of the event packet.

The monitoring SE then seeks the reference packet serving as a reference to find the insertion point (for example the first packet carrying the reference image whose PTS value is present in the PTS field 524).

The monitoring SE can then move the event packet to insert it at the desired position with respect to the PCR value. To carry out this movement, the monitoring SE has a buffer memory. For example, a buffer of 1 second makes it possible to catch up with delays of 1 second at most. This modification requires an adjustment of the PCRs of the transport stream. In particular, the monitoring SE can only move the event packet an integer number of TS packets. If the offset value it receives is in ms, it converts this value to the number of TS packets.

In particular, the monitoring SE can implement a step of removing the synchronization header from the current event packet before the transmission of the modified transport stream, in particular if the current event packet is of the event packet type useful. Indeed, once the current event packet is correctly positioned in the transport stream to compensate for the processing lag, it is no longer necessary to keep the synchronization header of the current event packet. In this way, the offset compensation to improve the synchronization of an event with the content to which it relates is transparent for the receivers receiving the transport stream, and compatible with current hybrid receivers.

According to a particular embodiment, the processing offset is an average offset obtained at the end of at least two iterations of the steps of detecting a current event packet and determining an offset between a real position of the current event packet in the transport stream, and a desired position. As already indicated, one or more monitoring SEs can be provided in the broadcast network (a monitoring SE integrated into the inserter SE, or a monitoring SE at the level of a single gateway, or a monitoring SE at the level of each gateway distribution, or a monitoring SE integrated into the inserter SE and a monitoring SE at the level of each distribution gateway, etc.).

In this case, each monitoring SE can use the specific information carried by an event packet to perform at least one action among: determining the desired position of an event packet with respect to a content reference point at which the event relates; determining the actual position of the event packet relative to the content reference point to which the event relates; determining the offset between the actual and desired positions; storing the determined offset or position(s); send the offset or the position(s) determined to another equipment of the broadcasting network, for example to the service platform 26 (for example via an IP connection) and/or to the inserter SE 213 ; update the synchronization header of the event packet (for example the G 523 field of a useful event packet), which can be transmitted to the following equipment in the broadcast chain and this up to the receivers (and therefore used by the receiver for synchronization); modifying the position of the current event packet in the transport stream to compensate for the offset, replacing the event packet as close as possible to its desired insertion position; etc

It is also noted that in the event of a significant delay in the event packets, a reference packet (i.e. containing for example a PTS value sought in the content) may be received before the event packet which references it. It is therefore desirable to also keep in memory the last PTS values received and their position in the transport stream (i.e. position of the reference packets and PTS contained in these reference packets). Similarly, it may be desirable to set up a buffering of the transport stream in order to be able to modify the position of the event packet in the transport stream, even if the insertion position has passed with respect to the reception of the packet. of event.

E. Service platform According to a particular embodiment, the proposed solution implements a service platform, for example the internet service platform 26 illustrated in FIG. 2, making it possible in particular to receive and store the various processing and/or reception offset values, and transmit them to the equipment concerned.

Such a service platform can in particular be configured to communicate with the inserter SE 213, with one or more monitoring SEs 223, 231, with one or more receivers 24, 25, etc.

In relation to FIG. 7, the main steps implemented by the service platform 26 are presented.

During a first step 71, the service platform 26 obtains at least one offset from among: o at least one offset between a real position of a current event packet in the transport stream, at the output of a device of the broadcasting network, and a desired position of the current event packet in the transport stream (processing offset), o an offset determined according to a type of receiver intended to receive said transport stream (reception offset) .

For example, obtaining at least one processing offset (D1) implements the reception of at least one offset determined by an SE monitoring.

In other words, at least one monitoring SE present in the broadcasting network determines a processing offset at the output of a network device, and transmits this processing offset to the service platform 26. If several offset values of processing are received for the same equipment to be monitored, the service platform can determine an average shift associated with this equipment.

Obtaining a reception offset (D2) implements for example the reading of a database storing the characteristics of the various receivers according to their type. For example, the service platform can identify the type of receiver from a request sent by the receiver and received by the service platform. In particular, the platform can use the user agent (in English “user agent” or UA) of an http request sent by the receiver to recognize the receiver. For example, filtering is applied to the UAs to determine the receiver type.

During a following step 72, the service platform transmits the processing and/or reception offset(s) obtained, possibly averaged, to at least one other piece of equipment of the broadcast network. As a variant, the service platform can transmit an overall offset determined from the processing and/or reception offset(s) obtained, possibly averaged. In particular, if processing offset values are received for equipment belonging to different sub-networks (for example a first processing offset value linked to the gateway 223 of the first sub-network 22, and a second offset value linked to the gateway 231 of the second sub-network 23), the gateway transmits to the inserter SE 213 the largest processing offset value, making it possible to compensate for all the delays induced by the various sub-networks. An example is presented next.

The service platform can therefore perform at least one action in connection with the receivers, among: storing reception offsets (i.e. delays linked to the receivers or synchronization information) per type of receiver; identify a type of receiver, for example by using the UA in the http request; transmit to the receiver the reception offset determined according to the type of receiver (i.e. delay to be used to maintain synchronization or synchronization information), for example via an HbbTV application; receive network delay information sent by the receivers; etc

The service platform can also perform at least one action in connection with the other equipment of the broadcast network, among: storing processing offsets (i.e. delays measured in the network, determined by the monitoring SE(s) and the inserter SE) ; determining average processing delays/lags; calculate the minimum look-ahead delay for the insertion of the event packet to compensate for all the delays induced by the different subnets, in the case of a network with several subnets, so that the event packet can be used in all subnets; notify the various network devices (in particular the Inserter SE) of the processing and/or reception offset(s) to be applied to optimize synchronization; etc

F. Receiver

The proposed solution can be implemented in hybrid receivers, notably supporting the HbbTV standard. Such receivers are in particular suitable for receiving packets classic events, in particular SE packets in DSM-CC format as defined in the aforementioned ISO/IEC 13818-6 standard.

According to a particular embodiment, such receivers can implement a software module, denoted SDK, which can be integrated into an HbbTV application intended to be executed on the receivers. In this case, the receivers are suitable for receiving event packets according to the invention, carrying a synchronization header as described above. Such a software module can in particular be used to improve the synchronization on the receiver.

In particular, for the HbbTV application to be able to synchronize an event with the content to which it relates, it can either receive an event synchronized with the content, or receive an event in advance as well as the delay between this event and the synchronization point .

In the first case, the implementation of the software module is not necessary since the synchronization is carried out upstream. In the second case, the implementation of the software module makes it possible to use the information carried by an event packet to synchronize the event with the content at the level of the receiver. In this second case, to perform the synchronization, the software module uses the date of receipt of the event packet, the information carried by the synchronization header of the event packet, and, if available, the information related to the receiver (allowing to compensate for the reception offset).

Thus, FIG. 8 illustrates the main steps implemented by a receiver according to the invention.

Such a receiver implements the reception 81 of a transport stream carrying at least one current event packet associated with a content carried by the transport stream, the current event packet carrying a synchronization header comprising: o a reference time information defined with respect to a reference clock of said content, o a desired or actual delay between the current event packet and a reference packet of the content identified from the reference time information.

In particular, if the event packet is a useful packet in which the synchronization header has been updated, the delay stored in the Ins. pos. may be the actual delay between the current event packet and the reference packet.

During a following step, the receiver synchronizes 82 the event carried by payload data of the current event packet with a reference point associated with the reference time information, taking into account a waiting period determined from the synchronization header of the current event packet. The preceding steps make it possible to compensate for the processing offset(s) linked to the equipment of the broadcasting network.

Optionally, to compensate for the reception offset linked to the type of receiver, the receiver implements a step of obtaining a reception offset, received for example from the service platform. The receiver, or the software module, can thus communicate with the platform to obtain the reception time linked to the type of receiver.

In this case, the timeout also takes this reception delay into account.

In other words, the receiver can perform a resynchronization of an event with the content to which it relates, for example the display of a video, by using the processing and/or reception offset values obtained in the event packets and/or via the service platform.

In particular, it is possible to filter, at the level of a receiver, the synchronization headers. In this case, only the useful part is uploaded to the HbbTV application, and that at the right time. In this way, the synchronization operation can be transparent for the HbbTV application.

The software module, executed on the receiver, can thus implement at least one action among: subscribing, with the receiver, to the reception of event packets present in the transport stream; obtain receiver type information via an http request to the service platform, including reception offset. This value is notably linked to the decoding delay of the content (for example a video) in the receiver and to the delay for reporting events to the HbbTV middleware; extract information from the synchronization header when an event packet is received, making it possible to synchronize the event with the content to which it relates; determine a delay between the reception of an event packet and the notification of the HbbTV application. This value corresponds to the resynchronization in the receiver. The waiting delay is for example equal to the sum of the pre-roll value, of the delay/delay added by the network (processing offset), of the delay/delay added in the receiver (reception offset). For this, the software module can use the value of field G 523 of the synchronization header, which carries a value processing offset linked to the broadcasting network (delay or advance of the event packet) and possibly the reception offset value linked to the receiver; at the end of the waiting period, notifying the HbbTV application with the payload data of the event packet; send to the service platform the offset information carried by the event packets to allow the surveillance / monitoring of the broadcast network; etc

G. Transcoder

In the case where the transport stream passes through equipment of the transcoder type, it should be noted that the structure of the transport stream can be modified: the transcoder can change the values of the reference clock embedded in the content (and therefore the reference time information, for example the PTS) and/or modify the position of the reference images in the transport stream.

FIG. 9 illustrates an example of a broadcast network implementing a transcoder, comprising: a network head 91, comprising at least one encoder 911 and a multiplexer 912, taking as input at least one content to be broadcast (for example a service A) and outputting a transport stream TS, and a terrestrial broadcasting sub-network 92, broadcasting the transport stream TS to a receiver 93, implementing a transcoder 921.

The network head also implements a first inserter SE 913 as described above.

In the event of modification of the reference clock of a content, if the transcoder 921 is able to keep the SCTE packets 35 and to correct the PTS values to bring them into conformity with the new reference clock, then an equipment upstream of the transcoder will be able to delete the previously inserted event packet(s) and perform a new insertion using the modified SCTE commands.

If the passage delay in the transcoder is fixed and known, it is possible to have a processing offset applied to all the event packets of the transport stream, by equipment downstream of the transcoder. Event packets can either be moved in the transport stream to anticipate this processing offset, or their synchronization header can be updated with this new processing offset value. The synchronization header PTS values must also be updated. If the transcoder changes neither the clocks nor the structure of the transport stream (the reference image is kept) then the previously inserted event packets remain valid.

If the transcoder changes the entire structure of the transport stream, synchronization between an event packet and the content it relates to is usually lost. In this case, a second inserter SE 922 can be provided downstream of the transcoder 921. Synchronization can then be maintained by determining a watermark of at least one reference image at the level of the network head by the first SE inserter 913. The second inserter SE 922 can receive the watermark(s) from the first inserter SE 913 and search for the corresponding images in the transport stream. When the pictures are found, the second inserter SE 922 can reconstruct the event packets as previously described in connection with the inserter SE 213 and insert them into the transport stream.

Note that this embodiment requires buffering the transport stream to allow the insertion of event packets at the requested position.

5.3 Examples of implementation

A few examples of implementation of the invention are presented below.

A. Head-end synchronization

According to a first example, illustrated in FIG. 10, the only aim is to measure the shift introduced between an event packet and the content to which it relates at the head end.

To do this, it is considered that the network head comprises, in a conventional manner, an encoder 100 and a multiplexer 101. The network head also comprises a monitoring SE 102 and an inserter SE 103 according to one embodiment of the invention.

The monitoring SE 102 and the inserter SE 103 can be hosted on the same equipment or on separate equipment.

As illustrated in FIG. 10, the multiplexer 101 receives content, for example video streams, coming from different coders, in particular from the coder 100. Such content can contain SCTE commands 35. It multiplexes the video streams, and thus multiplexes it. constructed is sent in the form of a transport stream as input to the monitoring SE 102 and to the broadcasting equipment.

If it does not detect any event packet in the transport stream (for example it does not detect any synchronization header or synchronization identifier in the SYNC field), the monitoring SE 102 does not perform any processing on the transport stream and forwards it to inserter SE 103.

If an SCTE command is detected, it can be transformed into a useful event packet by the inserter OS. The inserter SE 103 can thus construct a useful event packet from the SCTE command and of the video stream to which it relates, and send back the transport stream and the event packet at the input of the multiplexer 101. The multiplexer 101 takes the event packet thus constructed and adds it to its output multiplex . As a reminder, an SCTE 35 command is conventionally sent N seconds in advance with respect to the reference image. The SCTE has therefore been passed for N seconds when the reference image in turn passes through the multiplexer.

If it detects an event packet in the transport stream (for example it detects a synchronization header or a synchronization identifier in the SYNC field), the SE monitoring 102 estimates the offset induced by the insertion loop and the multiplexer 101. It then notifies the inserter SE 103 with the calculated value (directly or via a service platform).

The inserter SE 103 can thus correct this offset by anticipating or delaying the insertion of the following event packets.

For more robustness, the value used to compensate for the offset can be averaged over time.

As a variant or in addition, the inserter SE 103 can construct a measurement event packet from a video stream carried by the transport stream, and return the transport stream and the event packet to the input of the multiplexer 101 The multiplexer 101 takes the event packet thus constructed and adds it to its output multiplex.

For example, the inserter SE 103 replaces, in the transport stream, stuffing packets with measurement event packets and updates the "desired delay" field (D 422 for example) with the offset between a packet of reference (containing the reference time information, of the PTS type for example) and the stuffing packet replaced by the measurement event packet.

Such a measurement can be performed periodically so that the headend can self-adapt to potential variations in delay when inserting event packets.

According to this first example, the synchronization is therefore only implemented at the head end.

B. Same delay across the entire network

According to a second example, it is considered that the transport stream which arrives at all the transmitters of the network contains the same offset between the desired position and the actual position of the event packet, with respect to the content to which it relates.

For example, a monitoring SE measures this offset value at the end of the network equipment (for example a broadcasting gateway) and notifies this offset value to the inserter SE, directly or via a service platform. The value obtained by the inserter OS is used to anticipate the insertion of subsequent event packets. This anticipation of the insertion makes it possible to compensate for the delay induced by the network. Optionally, the synchronization header of event packets can be removed once the network-induced delay has been compensated.

If the offset measurement is continuous, then the inserter SE can adapt the insertion anticipation automatically so that the synchronization is optimal.

C. Different delays on subnets

According to a third example, a broadcast network is considered comprising a network head supplying at least two sub-networks with different processing and/or equipment.

The proposed solution makes it possible to prevent an event packet from being delayed on a sub-network, and arriving too late at the level of certain receivers to achieve synchronization.

It is considered according to this example that each sub-network is equipped with a monitoring SE, monitoring for example the end equipment of the sub-network. The monitoring SEs of each sub-network can send their measured processing offset value to the inserter SE of the network head, or to a service platform. The inserter OS or service platform determines the longest processing offset value. This value is used by the inserter OS to insert the following event packets, in order to anticipate this offset.

The OS monitoring of a subnet can modify the headers of the event packets that it receives to register there the advance of insertion of the event packet for the subnet that it follows. The software module of the receiver can in particular use these values to improve synchronization.

For example, if three subnets are used and induce the following delays between the desired position and the actual position of an event packet: subnet 1: 150 ms, subnet 2: 50 ms, subnet 3: 700 ms, then the inserter OS can insert event packets 700 ms before their desired insert position.

The monitoring SEs present in each sub-network can insert the following values in the "desired delay" field (D 422 or Ins. Pos. 522 for example) of event packets: sub-network 1: 550 ms (ie 700 ms - 150 ms), subnet 2: 650 ms (ie 700 ms - 50 ms), subnet 3: 0 ms. The software module of the receiver waits during the waiting times defined above before triggering an action (display of a pop-up for example) synchronized with the content to which it relates. Note that this part of the synchronization does not require the receiver to be connected.

If the receiver is connected, the software module can further improve the synchronization by taking into account the reception offset linked to the type of receiver. For example, the software module can ask a service platform if the receiver on which it is running induces an additional offset (advance or delay). The value of this reception offset is then used by the software module to resynchronize the actions.

5.4 Matching Devices

Finally, in relation to FIG. 11, the simplified structure of an inserter SE, of a monitoring SE, of a service platform or of a receiver according to one embodiment of the invention is presented.

An SE inserter according to one embodiment of the invention comprises a memory lllli (comprising for example a buffer memory) and a processing unit 1112 | (equipped for example with at least one processor, FPGA, or DSP), controlled or pre-programmed by an application or a computer program 1113| implementing the method of inserting an event according to one embodiment of the invention.

On initialization, the computer program code instructions 1113| are for example loaded into a RAM memory before being executed by the processing unit 1112 |. The processing unit 1112| implements the steps of the method of inserting an event into a transport stream described previously, according to the instructions of the computer program 1113|. To do this, according to one embodiment, the processing unit 1112 | is configured to: obtain the transport stream, insert, into the transport stream, at least one current event packet associated with a content carried by the transport stream, the current event packet carrying a synchronization header comprising: reference time information defined with respect to a reference clock of said content; a desired delay between said current event packet and a reference packet of said content identified from said reference time information, the current event packet being inserted into the transport stream at a position defined from the position of the reference package and the desired time frame. A monitoring SE according to one embodiment of the invention comprises a memory 1111M (comprising for example a buffer memory) and a processing unit 1112M (equipped for example with at least one processor, FPGA, or DSP), controlled or pre -programmed by an application or a computer program 1113M implementing the method for monitoring a transport stream at the output of equipment of a broadcasting network according to one embodiment of the invention.

On initialization, the code instructions of the computer program 1113M are for example loaded into a RAM memory before being executed by the processing unit 1112M. The processing unit 1112M implements the steps of the method of monitoring described previously, according to the instructions of the computer program 1113M · To do this, according to one embodiment, the processing unit 1112M is configured to: obtain a transport stream delivered by the equipment to be monitored, detect a packet current event associated with a content carried by the transport stream, the event packet carrying a synchronization header comprising: reference time information defined with respect to a reference clock of said content; a desired delay between said current event packet and a reference packet of said content identified from said reference time information, determining an offset between an actual position of the current event packet in the transport stream, and a desired position said current event packet in the transport stream, determined from the reference time information and the desired delay (processing offset).

A service platform according to one embodiment of the invention comprises a memory 1112p (comprising for example a buffer memory) and a processing unit 1112p (equipped for example with at least one processor, FPGA, or DSP), controlled or pre-programmed by an application or a computer program 1113p implementing the method for managing a transport stream according to one embodiment of the invention.

On initialization, the code instructions of the computer program 1113p are for example loaded into a RAM memory before being executed by the processing unit 1112p. The processing unit 1112p implements the steps of the method for managing a transport stream described previously, according to the instructions of the computer program 1113p. To do this, according to one embodiment, the processing unit 1112p is configured to: obtain at least one offset among: o at least one offset between an actual position of a current event packet in the transport stream, at the output of a broadcast network device, and a desired position of the current event packet in the transport stream ( processing offset), o an offset determined according to a type of receiver intended to receive the transport stream (reception offset), the current event packet being associated with a content carried by the transport stream, and carrying a synchronization header comprising: reference time information defined with respect to a reference clock of the content; a desired delay between the current event packet and a reference packet of the content identified from the reference time information, the desired position being determined from said reference time information and from said desired delay, transmitting, to at at least one other piece of equipment of the broadcast network, said at least one offset obtained, or a global offset determined from said at least one offset obtained.

A receiver according to one embodiment of the invention comprises an IIIIR memory (comprising for example a buffer memory) and an 1112R processing unit (equipped for example with at least one processor, FPGA, or DSP), driven or pre-controlled. programmed by an application or a computer program 1113R implementing the method for receiving a transport stream according to one embodiment of the invention.

On initialization, the code instructions of the computer program 1113R are for example loaded into a RAM memory before being executed by the processing unit 1112R. The processing unit 1112R implements the steps of the method for receiving a transport stream described previously, according to the instructions of the computer program 1113R. To do this, according to one embodiment, the processing unit 1112R is configured to: receive a transport stream carrying at least one current event packet associated with a content carried by the transport stream, the event packet stream carrying a synchronization header comprising: o reference time information defined with respect to a content reference clock, o a desired or actual delay between the current event packet and a content reference packet identified from the reference time information, synchronizing an event carried by payload data of the current event packet with a reference point associated with the reference time information, taking into account a waiting period determined from the synchronization header of the packet d current event.

Claims

1. Method for monitoring a transport stream at the output of equipment of a broadcasting network, characterized in that said method implements at least one iteration of the following steps:

- obtaining (61) the transport stream delivered by said equipment,

- detection (62) of a current event packet associated with a content carried by said transport stream, said event packet carrying a synchronization header comprising:

• reference time information defined in relation to a reference clock of said content,

• a desired delay between said current event packet and a reference packet of said content identified from said reference time information,

- determination (63) of an offset between an actual position of said current event packet in said transport stream, and a desired position of said current event packet in said transport stream, determined from said reference time information and said desired delay, called processing offset.

2. Method according to claim 1, characterized in that it comprises a step of transmitting said processing offset to at least one other device of said broadcast network.

3. Method according to any one of claims 1 and 2, characterized in that it comprises a step of updating said synchronization header with said processing offset.

4. Method according to any one of claims 1 to 3, characterized in that it comprises a step of modifying the position of said current event packet in said transport stream taking into account said processing offset and a step of transmitting said modified transport stream.

5. Method according to claim 4, characterized in that it comprises a step of removing said synchronization header from said current event packet, prior to said transmission of the modified transport stream.

6. Method according to any one of claims 1 to 5, characterized in that said processing offset is an average offset obtained after at least two iterations.

7. Method for inserting an event into a transport stream intended to be broadcast in a broadcast network, characterized in that it implements the following steps:

- obtaining (31) said transport stream, - insertion (32), in said transport stream, of at least one current event packet associated with content carried by said transport stream, said current event packet carrying a synchronization header comprising:

• reference time information defined with respect to a reference clock of said content;

• a desired delay between said current event packet and a reference packet of said content identified from said reference time information, said current event packet being inserted into said transport stream at a position defined from the position said reference packet and said desired delay.

8. Method according to claim 7, characterized in that it implements at least one step of obtaining (33) a shift between a real position of said current event packet in said transport stream, at the output of equipment of the broadcasting network, and a desired position of said current event packet in said transport stream, determined on the basis of said reference time information and of said desired delay, called processing offset.

9. Method according to any one of claims 7 and 8, characterized in that it implements the reception (34) of an offset determined according to a type of receiver intended to receive said transport stream, said reception delay.

10. Method according to any one of claims 8 and 9, characterized in that it implements a step of modifying the position of said current event packet in said transport stream taking into account said processing offset according to claim 8 and/or said receive offset according to claim 9.

11. Method according to any one of claims 8 to 10, characterized in that it implements a step of inserting a next event packet into said transport stream taking into account said processing offset according to claim 8 and/or said receive offset according to claim 9.

12. Method for managing a transport stream broadcast in a broadcast network, characterized in that it implements the following steps:

- obtaining (71) at least one shift among:

• at least one offset between a real position of a current event packet in said transport stream, at the output of equipment of the broadcast network, and a desired position of said current event packet in said transport stream, said processing lag, • an offset determined according to a type of receiver intended to receive said transport stream, called reception offset, said current event packet being associated with a content carried by said transport stream, and carrying a synchronization header comprising :

• a desired delay between said current event packet and a reference packet of said content identified from said reference time information, said desired position being determined from said reference time information and said desired delay,

- transmission (72), to at least one other device of said broadcasting network, of said at least one shift obtained, or of a global shift determined from said at least one shift obtained.

13. Method for receiving a transport stream broadcast in a broadcast network, characterized in that it implements the following steps:

- reception (81) of a transport stream carrying at least one current event packet associated with content carried by said transport stream, said current event packet carrying a synchronization header comprising:

• a desired or actual delay between said current event packet and a reference packet of said content identified from said reference time information,

- synchronization (82) of an event carried by payload data of said current event packet with a reference point associated with said reference time information, taking into account a waiting period determined from said synchronization header of said current event packet.

14. Method according to claim 13, characterized in that it comprises a step of obtaining an offset determined as a function of a type of receiver receiving said transport stream, called reception offset, and in that said delay also takes into account said reception delay.

15. Method according to any one of claims 1 to 14, characterized in that said reference time information corresponds to a date of restitution of a reference image of said content and in that said reference packet carries said reference image .

16. Method according to any one of claims 1 to 15, characterized in that said transport stream is in MPEG-TS format, and in that said current event packet is a “Stream Event” in DSM-CC format. .

17. Device for monitoring a transport stream at the output of equipment of a broadcasting network, characterized in that it comprises a reprogrammable calculation machine or a dedicated calculation machine, configured for:

- obtain the transport stream delivered by said equipment,

- detecting a current event packet associated with a content carried by said transport stream, said event packet carrying a synchronization header comprising:

- determining an offset between an actual position of said current event packet in said transport stream, and a desired position of said current event packet in said transport stream, determined from said reference time information and from said desired delay, called processing lag.

18. Device for inserting an event into a transport stream intended to be broadcast in a broadcast network, characterized in that it comprises a reprogrammable calculation machine or a dedicated calculation machine, configured for:

- obtain said transport stream,

- inserting, in said transport stream, at least one current event packet associated with a content carried by said transport stream, said current event packet carrying a synchronization header comprising:

19. Platform for managing a transport stream broadcast in a broadcasting network, characterized in that it comprises a reprogrammable calculation machine or a dedicated calculation machine, configured for: - obtain at least one shift among:

• at least one offset between a real position of a current event packet in said transport stream, at the output of equipment of the broadcast network, and a desired position of said current event packet in said transport stream, said processing lag,

• an offset determined according to a type of receiver intended to receive said transport stream, called reception offset, said current event packet being associated with a content carried by said transport stream, and carrying a synchronization header comprising :

- Transmitting, to at least one other equipment of said broadcast network, said at least one shift obtained, or a global shift determined from said at least one shift obtained.

20. Device for receiving a transport stream broadcast in a broadcasting network, characterized in that it comprises a reprogrammable computing machine or a dedicated computing machine, configured for:

- receiving a transport stream carrying at least one current event packet associated with content carried by said transport stream, said current event packet carrying a synchronization header comprising:

- synchronizing an event carried by payload data of said current event packet with a reference point associated with said reference time information, taking into account a waiting time determined from said synchronization header of said event packet running.

21. Computer program comprising program code instructions for implementing a method according to any one of claims 1 to 16, when said program is executed on a computer.