Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
  • H04N21/23614—Multiplexing of additional data and video streams
  • H04N21/23617—Multiplexing of additional data and video streams by inserting additional data into a data carousel, e.g. inserting software modules into a DVB carousel
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04H—BROADCAST COMMUNICATION
  • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
  • H04H20/18—Arrangements for synchronising broadcast or distribution via plural systems
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04H—BROADCAST COMMUNICATION
  • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
  • H04H60/02—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information
  • H04H60/07—Arrangements for generating broadcast information; Arrangements for generating broadcast-related information with a direct linking to broadcast information or to broadcast space-time; Arrangements for simultaneous generation of broadcast information and broadcast-related information characterised by processes or methods for the generation
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/21—Server components or server architectures
  • H04N21/222—Secondary servers, e.g. proxy server, cable television Head-end
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
  • H04N21/23608—Remultiplexing multiplex streams, e.g. involving modifying time stamps or remapping the packet identifiers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
  • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
  • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
  • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
  • H04N21/2625—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for delaying content or additional data distribution, e.g. because of an extended sport event
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
  • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
  • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
  • H04N21/43074—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of additional data with content streams on the same device, e.g. of EPG data or interactive icon with a TV program
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
  • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
  • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
  • H04N21/4348—Demultiplexing of additional data and video streams
  • H04N21/4349—Demultiplexing of additional data and video streams by extracting from data carousels, e.g. extraction of software modules from a DVB carousel

Definitions

• TITLE Methods and devices for inserting an event into a transport stream, monitoring, managing and receiving the transport stream, and corresponding computer program.
• the field of the invention is that of broadcasting information, in particular television services, in a broadcasting network.
• 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.
• 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”).
• 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.
• 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”.
• 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.
• TS transport packets
• 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”),
• 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.
• PTS Presentation Time Stamp
• DTS Decoding Time Stamp
• the "elementary" MPEG-TS streams obtained at the output of the various coders can be multiplexed by a multiplexer of the network head.
• a “global” MPEG-TS stream is therefore obtained encapsulating several “elementary” MPEG-TS streams, in which all the TS packets are mixed.
• 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).
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• FEC Forward Error Correction
• 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.
• a transcoder may introduce a delay of several seconds.
• using error-correcting code can add hundreds of milliseconds of latency.
• such a shift can change if the broadcast network is changed over time.
• such a shift may be different from one subnet to another.
• 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.
• 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.
• 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.
• PTS presentation instant
• DTS decoding instant
• a receiver has no information between the event and the component of the “elementary” MPEG-TS stream with which it is associated.
• 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.
• equipment called equipment to be monitored
• 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.
• 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.
• 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”.
• 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.
• 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.
• 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.
• 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.
• an event packet 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a reference point for example a reference image
• 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.
• 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).
• a system also comprises a service platform making it possible to store the various offsets and a receiver according to the invention.
• 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).
• 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
• 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.
• 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.
• Figure 1 illustrates an example of an MPEG-TS stream received by a receiver
• FIG 2 illustrates an example of a broadcast network in which the invention can be implemented
• FIG. 3 presents the main steps implemented by a device for inserting an event according to one embodiment of the invention
• FIG 4 illustrates the structure of a measurement event packet according to one embodiment of the invention
• FIG 5 illustrates the structure of a payload event packet according to one embodiment of the invention
• 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 presents the main steps implemented by a service platform according to one embodiment of the invention
• FIG. 8 shows the main steps implemented by a receiver according to one embodiment of the invention
• FIG. 9 illustrates an example of a broadcast network implementing a transcoder
• FIG. 10 illustrates an example of implementation of synchronization at the head end of the network according to a particular embodiment
• 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.
• 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.
• 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
• end equipment - also called end equipment - or a receiver
• end equipment - also called end equipment - or a receiver
• 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.
• 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.
• 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
• the gateways 223 and 231 are each equipped with a monitoring device 2231 and 2311.
• 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.
• receivers 24 and 25 can be executed by receivers 24 and 25.
• inserter SE the main steps implemented by the device for inserting an event 213, also called inserter SE.
• 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
• the inserter SE obtains a transport stream.
• the transport stream carries no event packets.
• the transport stream may optionally carry one or more event packets inserted during a previous iteration.
• 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.
• it takes as input information making it possible to identify a reference point in the content (message of SCTE 35 type, watermark, etc.).
• 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.
• 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.
• 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
• the reference packet is for example the first packet encoding the reference image.
• the reference image is an IDR (Instantaneous Decoder Refresh) image.
• 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.
• 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.
• a current event packet can be a payload event packet carrying payload data associated with the event.
• 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.
• 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.
• 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.
• 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.
• a network monitoring device for example the monitoring SEs 2231 or 2311
• This shift can in particular be transmitted to another piece of equipment in the broadcast network, for example to the service platform 26.
• 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.
• 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.
• the characteristics of different receivers according to their type can be determined during laboratory tests and stored in a database.
• 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.
• 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.
• 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.
• 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.
• 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
• Event Packages As noted above, different event packets can be used to measure the offset(s) and improve synchronization.
• 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.
• 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.
• 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.
• 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.
• this shift or delay can be calculated in number of packets TS based on the clock used for the reference time information.
• the offset is calculated in number of TS packets belonging to the same content.
• 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).
• 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”).
• SE header an SE_H header 41
• SE payload a useful part SE_P 42
• 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.
• 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).
• 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 (
• 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.
• 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.
• PID packet identifier
• 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.
• the inserter SE uses the same PID for the event packet and the payload packets of a content.
• 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.
• a current event packet can be a payload event packet carrying payload data associated with an event.
• 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.
• the inserter OS selects a content reference image.
• the inserter SE inserts, into the transport stream, at least one useful event packet synchronized with the content to which it relates.
• the reference image can be identified from an SCTE 35 type message.
• 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.
• 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.
• the reference image can be identified from a watermark carried by the reference image.
• the inserter SE seeks to detect, in the content, an image bearing a watermark known to the inserter SE (“video fingerprint”).
• video fingerprint an image bearing a watermark known to the inserter SE
• 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).
• 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”).
• SE header an SE_H header 51
• SE payload a useful part SE_P 52
• SE payload a useful part SE_P 52
• 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).
• 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
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a monitoring device making it possible to determine the processing delay introduced by this equipment or by the network up to this equipment.
• the gateway 223 is monitored by the monitoring device 2231
• 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).
• 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).
• 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.
• 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
• 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.
• such a current event packet 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,
• 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.
• 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).
• 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.
• 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.
• 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.
• the monitoring SE updates the synchronization header with the processing offset thus determined.
• the value of the G field 523 is updated by replacing it with the processing offset D1.
• a CRC for “Cyclic Redundancy Check”
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.).
• 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
• a reference packet i.e. containing for example a PTS value sought in the content
• a reference packet 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).
• 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.
• 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.
• 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) .
• obtaining at least one processing offset (D1) implements the reception of at least one offset determined by an SE monitoring.
• 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 implements for example the reading of a database storing the characteristics of the various receivers according to their type.
• the service platform can identify the type of receiver from a request sent by the receiver and received by the service platform.
• 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.
• 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.
• the service platform can transmit an overall offset determined from the processing and/or reception offset(s) obtained, possibly averaged.
• 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
• 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.
• such receivers can implement a software module, denoted SDK, which can be integrated into an HbbTV application intended to be executed on the receivers.
• the receivers are suitable for receiving event packets according to the invention, carrying a synchronization header as described above.
• a software module can in particular be used to improve the synchronization on the receiver.
• the HbbTV application 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 .
• the implementation of the software module is not necessary since the synchronization is carried out upstream.
• 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.
• 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).
• 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.
• the delay stored in the Ins. pos. may be the actual delay between the current event packet and the reference packet.
• 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 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.
• the timeout also takes this reception delay into account.
• 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.
• the synchronization headers 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).
• 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
• 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.
• 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.
• the transcoder 921 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.
• 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.
• 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.
• this embodiment requires buffering the transport stream to allow the insertion of event packets at the requested position.
• the only aim is to measure the shift introduced between an event packet and the content to which it relates at the head end.
• 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.
• the multiplexer 101 receives content, for example video streams, coming from different coders, in particular from the coder 100.
• 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.
• the monitoring SE 102 does not perform any processing on the transport stream and forwards it to inserter SE 103.
• 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 .
• 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.
• 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.
• the value used to compensate for the offset can be averaged over time.
• 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.
• 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.
• D 422 the "desired delay" field
• Such a measurement can be performed periodically so that the headend can self-adapt to potential variations in delay when inserting event packets.
• the synchronization is therefore only implemented at the head end.
• 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.
• 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.
• the synchronization header of event packets can be removed once the network-induced delay has been compensated.
• the inserter SE can adapt the insertion anticipation automatically so that the synchronization is optimal.
• 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.
• 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.
• subnet 1 150 ms
• subnet 2 50 ms
• subnet 3 700 ms
• 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.
• 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.
• An SE inserter comprises a memory lllli (comprising for example a buffer memory) and a processing unit 1112
• a memory lllli comprising for example a buffer memory
• equipped for example with at least one processor, FPGA, or DSP
• are for example loaded into a RAM memory before being executed by 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
• 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 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.
• a memory 1111M comprising for example a buffer memory
• a processing unit 1112M equipped for example with at least one processor, FPGA, or DSP
• 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.
• 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 ⁇
• 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 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.
• a memory 1112p comprising for example a buffer memory
• a processing unit 1112p equipped for example with at least one processor, FPGA, or DSP
• 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.
• 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 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.
• IIIIR memory comprising for example a buffer memory
• 1112R processing unit equipped for example with at least one processor, FPGA, or DSP
• 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Signal Processing (AREA)
• Multimedia (AREA)
• Databases & Information Systems (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=76523070

Family Applications (1)

Country Status (3)

Families Citing this family (1)

Family Cites Families (3)

• 2021
  • 2021-04-09 FR FR2103688A patent/FR3121809B1/fr active Active
• 2022
  • 2022-04-07 EP EP22721337.8A patent/EP4320871A1/de active Pending
  • 2022-04-07 WO PCT/EP2022/059243 patent/WO2022214586A1/fr active Application Filing

Also Published As

Similar Documents

Legal Events