FR3121809A1 - Procédés et dispositifs d’insertion d’un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d’ordinateur correspondants. - Google Patents

Procédés et dispositifs d’insertion d’un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d’ordinateur correspondants. Download PDF

Info

Publication number
FR3121809A1
FR3121809A1 FR2103688A FR2103688A FR3121809A1 FR 3121809 A1 FR3121809 A1 FR 3121809A1 FR 2103688 A FR2103688 A FR 2103688A FR 2103688 A FR2103688 A FR 2103688A FR 3121809 A1 FR3121809 A1 FR 3121809A1
Authority
FR
France
Prior art keywords
transport stream
packet
event packet
current event
offset
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR2103688A
Other languages
English (en)
Other versions
FR3121809B1 (fr
Inventor
David Vincent
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telediffusion de France ets Public de Diffusion
Enensys Technologies SA
Original Assignee
Telediffusion de France ets Public de Diffusion
Enensys Technologies SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telediffusion de France ets Public de Diffusion, Enensys Technologies SA filed Critical Telediffusion de France ets Public de Diffusion
Priority to FR2103688A priority Critical patent/FR3121809B1/fr
Priority to PCT/EP2022/059243 priority patent/WO2022214586A1/fr
Priority to US18/554,478 priority patent/US20240205472A1/en
Priority to EP22721337.8A priority patent/EP4320871A1/fr
Publication of FR3121809A1 publication Critical patent/FR3121809A1/fr
Application granted granted Critical
Publication of FR3121809B1 publication Critical patent/FR3121809B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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

Landscapes

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

Abstract

Procédés et dispositifs d’insertion d’un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d’ordinateur correspondants. L’invention concerne un procédé de surveillance d’un flux de transport en sortie d’un équipement d’un réseau de diffusion, mettant en œuvre au moins une itération des étapes suivantes : obtention (61) du flux de transport délivré par ledit équipement, détection (62) d’un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement portant un entête de synchronisation comprenant : une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence, détermination (63) d’un décalage entre une position réelle dudit paquet d’événement courant dans ledit flux de transport, et une position souhaitée dudit paquet d’événement courant dans ledit flux de transport, déterminée à partir de ladite information temporelle de référence et dudit délai souhaité, dit décalage de traitement. FIGURE D’ABREGE : Fig. 6

Description

Procédés et dispositifs d’insertion d’un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d’ordinateur correspondants.
1. Domaine de l’invention
Le domaine de l’invention est celui de la diffusion d’informations, notamment de services de télévision, dans un réseau de diffusion.
Plus précisément, l’invention concerne la diffusion d’événements, permettant de déclencher des actions liées à des contenus diffusés dans le réseau de diffusion, par exemple des contenus vidéo.
En particulier, l’invention propose une solution permettant d’améliorer la synchronisation d’un événement avec le contenu auquel il se rapporte, notamment au niveau d’un récepteur.
L’invention s’applique notamment, mais non exclusivement, à la diffusion d’un flux de transport selon les normes DVB-T ou DVB-T2 (en anglais « Digital Video Broadcasting – Terrestrial »), DVB-S ou DVB-S2 (en anglais « Digital Video Broadcasting – Satellite »), ou encore DVB-C (en anglais « Digital Video Broadcasting – Cable »).
2. Art antérieur
Il existe aujourd’hui des solutions permettant de bénéficier de services interactifs avec les programmes des chaînes de télévision.
En particulier, il est possible de transmettre, dans un flux de transport portant un ou plusieurs contenus, des informations liées à une ou plusieurs application(s) destinée(s) à être exécutée(s) par un récepteur, permettant notamment au récepteur de bénéficier de contenus additionnels.
2.1 Événements
De telles informations comprennent notamment des événements, permettant de déclencher des actions liées à ces applications.
Ces événements peuvent être utilisés pour permettre une synchronisation entre des données interactives et les composantes vidéo et/ou audio d’un contenu du flux de transport, par exemple pour synchroniser l’affichage d’éléments graphiques en complément d’une vidéo (par exemple une « pop-up »), substituer une publicité par une publicité ciblée, insérer un sous-titre ou le substituer par un autre, etc.
Ces événements sont par exemple de type « Stream Event », ou SE, au format DSM-CC (pour « Digital Storage Media Command and Control » en anglais), tels que définis dans la norme ISO/IEC 13818-6: « Information technology - Generic coding of moving pictures and associated audio information - Part 6: Extensions for DSM-CC ».)
Ces évènements peuvent être reçus par les récepteurs compatibles avec les normes HbbTV (en anglais « Hybrid Broadcast Broadband TV »), également appelés récepteurs hybrides ou connectés, qui représentent la grande majorité des téléviseurs connectables du marché aujourd’hui.
Ainsi, la norme HbbTV, telle que définie dans la spécification technique ETSI TS 102 796 V1.4.1, décrit la signalisation, le transport et la signalisation de telles applications interactives destinées à être exécutées par un récepteur hybride, et notamment d’événements associés à de telles applications. Des exemples d’applications sont notamment présentés dans la spécification technique ETSI TS 102 809 (V1.3.1):« Digital Video Broadcasting (DVB); Signalling and carriage of interactive applications and services in Hybrid Broadcast/Broadband environments ».
2.2 Insertion d’événement dans un flux de transport
On décrit ci-après l’insertion d’un événement dans un flux de transport, par exemple un flux MPEG-TS (pour « Moving Picture Experts Group - Transport Stream » en anglais).
Classiquement, un premier codeur d’une tête de réseau reçoit en entrée des données source et délivre en sortie un premier flux MPEG-TS. Un deuxième codeur reçoit en entrée d’autres données source et délivre en sortie un deuxième flux MPEG-TS. De tels codeurs peuvent également recevoir des commandes au format SCTE 104 et les convertir au format SCTE 35.
Chaque flux MPEG-TS « élémentaire » (i.e. issu d’un codeur) est composé d’un ensemble de paquets de transport (TS), comprenant des paquets audio, vidéo et/ou de sous-titre, etc. Ces différents paquets portent des informations temporelles définies par rapport à une horloge de référence associée au flux MPEG-TS « élémentaire », par exemple un signal d’horloge PCR (en anglais « programme clock reference ») ou TEMI (en anglais « Timed External Media Information »). Par exemple, un paquet vidéo porte une valeur PTS (« Presentation Time Stamp » en anglais) et/ou DTS (« Decoding Time Stamp » en anglais) correspondant à une heure de présentation et/ou décodage d’une image codée dans ce paquet vidéo, par rapport à l’horloge de référence associée au flux MPEG-TS « élémentaire ».
Les flux MPEG-TS « élémentaires » obtenus en sortie des différents codeurs peuvent être multiplexés par un multiplexeur de la tête de réseau. En sortie du multiplexeur, on obtient donc un flux MPEG-TS « global » encapsulant plusieurs flux MPEG-TS « élémentaire », dans lequel tous les paquets TS sont mélangés.
En particulier, au moins un événement peut être défini par rapport à un flux MPEG-TS « élémentaire » (par exemple un ordre de décrochage, un élément graphique à ajouter à une image du contenu porté par le flux MPEG-TS « élémentaire », etc). Un tel événement, par exemple un événement au format SCTE 35 obtenu en sortie du codeur, peut notamment être converti en « Stream Event », comme décrit dans la demande de brevet WO2019/011655. En particulier, cette demande de brevet propose d’utiliser les informations temporelles obtenues à partir d’une commande de type SCTE 35 par exemple, pour positionner un événement dans un flux de transport et établir une synchronisation fine entre l’événement et un point de référence du flux MPEG-TS « élémentaire ».
Un tel événement peut être inséré sous la forme d’un paquet d’événement dans le flux MPEG-TS, de façon relative par rapport à un paquet de référence du flux MPEG-TS « élémentaire ». Un tel paquet d’événement est donc un paquet TS.
La illustre un exemple de flux MPEG-TS 11 reçu par un récepteur. Les paquets TS 111, 112, et 113 sont par exemple des paquets utiles d’un flux MPEG-TS « élémentaire ». Le paquet d’événement 110 peut porter un événement se rapportant au flux MPEG-TS « élémentaire ». Par exemple, le paquet d’événement est un paquet TS portant un Stream Event au format DSM-CC définissant une ou plusieurs actions liées au contenu porté par le flux MPEG-TS « élémentaire ».
Classiquement, un « pré-roll d’insertion » est défini pour un événement, correspondant à un délai souhaité entre l’insertion de la commande et un point du flux MPEG-TS élémentaire signalé par l’événement. Ce positionnement en avance permet aux récepteurs de préparer les actions à réaliser lors de la réception de l’événement. Une réception en avance implique que la valeur de pré-roll d’insertion soit connue par le récepteur.
Selon l’exemple illustré en , un tel pré-roll d’insertion 12 correspond à un délai souhaité, classiquement exprimé en millisecondes, entre la position du paquet d’événement 110 dans le flux MPEG-TS et la position d’un paquet de référence 111 du flux MPEG-TS « élémentaire » dans le flux MPEG-TS. Par exemple, la position souhaitée d’insertion du paquet d’événement 110 dans le flux MPEG-TS peut être de l’ordre de 100ms avant le paquet de référence 100 correspondant au premier paquet d’une image cible repérée par sa valeur de PTS, en se basant sur l’horloge de référence servant de référence au PTS utilisé.
On constate toutefois sur la qu’il existe un décalage 13 entre la position réelle du paquet d’événement 110 dans le flux MPEG-TS (qui correspond par exemple à l’heure de réception, par le récepteur du flux MPEG-TS 11, du premier octet du paquet d’événement 110) et la position souhaitée du paquet d’événement 110 par rapport au paquet de référence 111 (référencée 114).
Un tel décalage d’insertion correspond donc à un décalage, non souhaité, entre les positions d’insertion cible et réelle du paquet d’événement dans le flux MPEG-TS.
Ce décalage peut être provoqué par des opérations réalisées sur le flux MPEG-TS :
  • insertion du « stream event »,
  • multiplexage, transcodage, remultiplexage (qui peuvent modifier l’ordonnancement des paquets TS),
  • utilisation d’un code correcteur d’erreur (FEC ou « Forward Error Correction » en anglais) dans un équipement,
  • etc.
Notamment, la structure du réseau de diffusion et/ou la nature des équipements traversés par le flux MPEG-TS peuvent introduire un décalage entre les composantes HbbTV (par exemple de type Stream Event) et vidéo (ou audio, de sous-titre, etc) d’un flux MPEG-TS. Par exemple, un transcodeur peut introduire un retard de plusieurs secondes. De même, l’utilisation d’un code correcteur d’erreur peut ajouter une latence de plusieurs centaines de millisecondes.
En particulier, un tel décalage peut évoluer si le réseau de diffusion est modifié au fil du temps.
De plus, un tel décalage peut être diffèrent d’un sous réseau à l’autre. Par exemple, pour un même contenu diffusé en TNT et en satellite, le décalage peut être diffèrent pour les deux modes de diffusion, puisqu’ils n’utilisent pas la même structure de réseau et pas les mêmes équipements.
Par ailleurs, un décalage supplémentaire peut également être introduit par le récepteur entre l’affichage d’une image de référence et la réception de l’événement défini à partir de cette image de référence au niveau de l’application HbbTV. Ce décalage peut être variable d’un modèle de récepteur à l’autre.
Un inconvénient lié à ce ou ces décalages est la désynchronisation entre l’événement et le flux MPEG-TS « élémentaire » auquel il se rapporte, au niveau d’un récepteur.
En effet, les PTS/DTS et commandes SCTE ne sont pas accessibles par une application HbbTV. Les événements selon la norme HbbTV ne portent donc pas de référence temporelle, comme un instant de présentation (PTS) ou un instant de décodage (DTS), qui permettrait une synchronisation fine, au niveau des récepteurs, de l’événement (ou plus généralement de la composante HbbTV) avec une composante vidéo (ou audio, de sous-titre, etc) du flux MPEG-TS « élémentaire » à laquelle il se rapporte. En d’autres termes, un récepteur ne dispose d’aucune information entre l’événement et la composante du flux MPEG-TS « élémentaire » à laquelle il est associé.
Quand bien même un événement a été inséré dans le flux MPEG-TS pour assurer une synchronisation entre l’événement et la composante à laquelle il se rapporte, tel que décrit dans la demande de brevet WO2019/011655 par exemple, la synchronisation peut être altérée par le ou les décalages introduits par le réseau de diffusion ou le récepteur.
Il existe donc un besoin pour une nouvelle technique permettant d’améliorer la synchronisation entre un événement et la composante du flux de transport à laquelle il se rapporte, au niveau d’un récepteur.
3. Exposé de l’invention
L’invention propose, dans au moins un mode de réalisation, une solution ne présentant pas l’ensemble des inconvénients de l’art antérieur, sous la forme d’un procédé de surveillance d’un flux de transport en sortie d’un équipement d’un réseau de diffusion. Par exemple, un tel équipement, dit équipement à surveiller, peut être un multiplexeur, une passerelle, un transcodeur, etc.
Selon l’invention, un tel procédé met en œuvre au moins une itération des étapes suivantes :
  • obtention du flux de transport délivré par ledit équipement,
  • détection d’un paquet d’événement courant associé à un contenu porté par le flux de transport, le paquet d’événement portant un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
  • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
  • détermination d’un décalage entre une position réelle dudit paquet d’événement courant dans ledit flux de transport, et une position souhaitée dudit paquet d’événement courant dans ledit flux de transport, déterminée à partir de ladite information temporelle de référence et dudit délai souhaité, dit décalage de traitement.
La solution proposée permet ainsi de mesurer, au cours de la diffusion du flux de transport dans le réseau de diffusion, un décalage introduit par au moins un équipement du réseau de diffusion, par exemple un multiplexeur, une passerelle de diffusion, un transcodeur, etc. Il est ainsi possible de compenser ce décalage avant de poursuivre la diffusion du flux de transport dans le réseau ou d’en informer les autres équipements du réseau de diffusion. Il est également possible de tenir compte de ce décalage lors de l’insertion de paquets d’événement suivants dans le flux de transport.
En particulier, l’équipement à surveiller peut être un équipement placé à l’extrémité du réseau de diffusion (par exemple une passerelle de diffusion), de façon à déterminer le décalage introduit par l’ensemble du réseau de diffusion.
Pour ce faire, on détecte, dans le flux de transport en sortie de l’équipement à surveiller, au moins un paquet d’événement courant portant des informations spécifiques. Grâce à ces informations spécifiques, il est possible de déterminer une position souhaitée, ou théorique, du paquet d’événement courant dans le flux de transport par rapport à un point de référence du contenu. Il est également possible de mesurer la position réelle du paquet d’événement courant dans le flux de transport en sortie de l’équipement à surveiller par rapport à ce point de référence, et de déterminer un décalage entre la position réelle du paquet courant et sa position souhaitée dans le flux de transport. Ce décalage, introduit notamment par le traitement du flux de transport jusqu’à l’équipement à surveiller, est par la suite appelé « décalage de traitement ».
Connaissant ce décalage de traitement, différentes actions peuvent être exécutées.
Par exemple, ce décalage de traitement peut être :
  • stocké dans une mémoire du dispositif de surveillance,
  • transmis à au moins un autre équipement du réseau de diffusion (dispositif d’insertion d’événement, plateforme de services stockant les différentes valeurs de décalages, etc), directement ou en modifiant un champ de l’entête de synchronisation du paquet d’événement courant,
  • utilisé pour corriger la position du paquet d’événement courant dans le flux de transport, de façon que la position souhaitée du paquet d’événement courant et sa position réelle coïncide ;
  • utilisé pour insérer au moins un paquet d’événement suivant dans le flux de transport, à une position telle que la position souhaitée du paquet d’événement suivant et sa position réelle coïncide,
  • etc.
De cette façon, il est possible d’améliorer la synchronisation entre un paquet d’événement et le point de référence du contenu auquel il se rapporte, notamment au niveau d’un récepteur recevant le flux de données.
De telles étapes peuvent notamment être mises en œuvre dans un dispositif de surveillance d’un flux de transport. L’invention concerne donc également un dispositif de surveillance correspondant.
Un tel dispositif de surveillance, également appelé SE monitoring, est notamment adapté à mettre en œuvre le procédé de surveillance décrit ci-dessus. Il pourra bien sûr comporter les différentes caractéristiques relatives au procédé de surveillance selon au mode de réalisation de l’invention, qui peuvent être combinées ou prises isolément. Par exemple, un tel dispositif peut être intégré à un dispositif d’insertion d’événement, à une passerelle ou à tout autre équipement du réseau de diffusion.
L’invention concerne par ailleurs un procédé d’insertion d’un événement dans un flux de transport destiné à être diffusé dans un réseau de diffusion.
Selon l’invention, un tel procédé met en œuvre les étapes suivantes :
  • obtention dudit flux de transport,
  • insertion, dans ledit flux de transport, d’au moins un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement courant portant un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
  • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
ledit paquet d’événement courant étant inséré dans ledit flux de transport à une position définie à partir de la position dudit paquet de référence et dudit délai souhaité.
La solution proposée permet ainsi d’insérer, dans le flux de transport, des paquets d’événement particuliers, qui peuvent être utilisés pour mesurer un décalage introduit par le réseau de diffusion.
En particulier, un paquet d’événement selon l’invention porte une information temporelle de référence définie par rapport à une horloge de référence du contenu, par exemple une valeur de PTS associée à une image de référence du contenu définie par rapport à un signal d’horloge embarqué dans le contenu (une PCR, un TEMI, etc). Un tel paquet d’événement porte également un délai souhaité entre le paquet d’événement courant et un paquet de référence du contenu identifié à partir de l’information temporelle de référence, par exemple le paquet portant l’image de référence. Un tel délai souhaité correspond par exemple à un pré-roll d’insertion.
Grâce à ces informations spécifiques, il est possible de déterminer une position souhaitée, ou théorique, du paquet courant dans le flux de transport par rapport à un point de référence du contenu. Il est également possible de mesurer la position réelle du paquet courant dans le flux de transport par rapport à ce point de référence, en sortie d’un équipement du réseau de diffusion, et de déterminer le décalage de traitement entre la position réelle du paquet courant et sa position souhaitée dans le flux de transport.
De telles étapes peuvent notamment être mises en œuvre dans un dispositif d’insertion d’un événement dans un flux de transport. L’invention concerne donc également un dispositif d’insertion d’un événement correspondant.
Un tel dispositif d’insertion d’un événement dans un flux de transport, également appelé SE inserteur, est notamment adapté à mettre en œuvre le procédé d’insertion d’un événement décrit ci-dessus. Il pourra bien sûr comporter les différentes caractéristiques relatives au procédé d’insertion d’un événement selon un mode de réalisation de l’invention, qui peuvent être combinées ou prises isolément.
Par exemple, un tel dispositif peut être intégré à un multiplexeur ou à tout autre équipement du réseau de diffusion.
L’invention concerne encore un procédé de gestion d’un flux de transport diffusé dans un réseau de diffusion.
Selon l’invention, un tel procédé met en œuvre les étapes suivantes :
  • obtention d’au moins un décalage parmi :
    • au moins un décalage entre une position réelle d’un paquet d’événement courant dans ledit flux de transport, en sortie d’un équipement du réseau de diffusion, et une position souhaitée dudit paquet d’événement courant dans ledit flux de transport, dit décalage de traitement,
    • un décalage déterminé en fonction d’un type de récepteur destiné à recevoir ledit flux de transport, dit décalage de réception,
ledit paquet d’événement courant étant associé à un contenu porté par ledit flux de transport, et portant un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
  • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
ladite position souhaitée étant déterminée à partir de ladite information temporelle de référence et dudit délai souhaité,
  • transmission, à au moins un autre équipement dudit réseau de diffusion, dudit au moins un décalage obtenu, ou d’un décalage global déterminé à partir dudit au moins un décalage obtenu.
La solution proposée permet ainsi de collecter dans un même équipement, par exemple une plateforme de services, au moins une valeur de décalage liée à l’utilisation d’au moins un équipement du réseau de diffusion ou du récepteur.
De cette façon, il est possible de centraliser la ou les valeurs de décalages obtenues, éventuellement de moyenner la ou les valeurs de décalages obtenues, éventuellement de déterminer une valeur de décalage global à partir de la ou des valeurs de décalage (moyennées) obtenues, et d’en informer au moins un équipement du réseau de diffusion, par exemple le SE inserteur.
On peut ainsi améliorer la précision d’insertion des événements dans le flux de transport, et donc la synchronisation des événements avec les contenus/composantes auxquel(le)s ils se rapportent, notamment au niveau du récepteur.
L’invention concerne également une plateforme de services correspondante.
Une telle plateforme de services, par exemple de type AdsReach® telle que développée par la société ENENSYS TECHNOLOGIES®, est notamment adaptée à mettre en œuvre le procédé de gestion décrit ci-dessus. Elle pourra bien sûr comporter les différentes caractéristiques relatives au procédé de gestion selon un mode de réalisation de l’invention, qui peuvent être combinées ou prises isolément.
L’invention concerne encore un procédé de réception d’un flux de transport diffusé dans un réseau de diffusion.
Selon l’invention, un tel procédé met en œuvre les étapes suivantes :
  • réception d’un flux de transport portant au moins un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement courant portant un entête de synchronisation comprenant :
    • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu,
    • un délai souhaité ou réel entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
  • synchronisation d’un événement porté par des données utiles dudit paquet d’événement courant avec un point de référence (par exemple une image de référence) associé à ladite information temporelle de référence, en tenant compte d’un délai d’attente déterminé à partir dudit entête de synchronisation dudit paquet d’événement courant.
La solution proposée permet ainsi, au niveau d’un récepteur, de synchroniser un événement avec le contenu auquel il se rapporte.
L’invention concerne également un récepteur correspondant.
Un tel récepteur est notamment adapté à mettre en œuvre le procédé de réception décrit ci-dessus. Il pourra bien sûr comporter les différentes caractéristiques relatives au procédé de réception selon un mode de réalisation de l’invention, qui peuvent être combinées ou prises isolément. En particulier, un tel récepteur est un récepteur hybride, compatible avec la norme HbbTV.
L’invention concerne par ailleurs un système correspondant, comprenant au moins un SE inserteur et un SE monitoring (éventuellement combiné au SE inserter). De préférence, un tel système comprend également une plateforme de services permettant de stocker les différents décalages et un récepteur selon l’invention.
Les différents procédés selon au moins un mode de réalisation de l’invention peuvent être mis en œuvre de diverses manières, notamment sous forme matérielle et/ou sous forme logicielle.
Par exemple, au moins une étape des procédés décrits ci-dessus peut être mise en œuvre :
  • sur une machine de calcul reprogrammable (un ordinateur, un processeur par exemple DSP (en anglais « Digital Signal Processor »), un microcontrôleur, etc) exécutant un programme comprenant une séquence d’instructions,
  • sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA (en anglais « Field Programmable Gate Array ») ou un ASIC (en anglais « Application-Specific Integrated Circuit »), ou tout autre module matériel).
En conséquence, un mode de réalisation de l’invention vise aussi à protéger un ou plusieurs programmes d’ordinateur comportant des instructions adaptées à la mise en œuvre des procédés décrits ci-dessus lorsque ce ou ces programmes sont exécutés par un processeur, ainsi qu’au moins un support d’informations lisible par un ordinateur comportant des instructions d’au moins un programme d’ordinateur tel que mentionné ci-dessus.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels :
la illustre un exemple de flux MPEG-TS reçu par un récepteur ;
la illustre un exemple de réseau de diffusion dans lequel peut être mise en œuvre l’invention ;
la présente les principales étapes mises en œuvre par un dispositif d’insertion d’un événement selon un mode de réalisation de l’invention ;
la illustre la structure d’un paquet d’événement de mesure selon un mode de réalisation de l’invention ;
la illustre la structure d’un paquet d’événement utile selon un mode de réalisation de l’invention ;
la présente les principales étapes mises en œuvre par un dispositif de surveillance d’un flux de transport en sortie d’un équipement du réseau de diffusion selon un mode de réalisation de l’invention ;
la présente les principales étapes mises en œuvre par une plateforme de services selon un mode de réalisation de l’invention ;
la présente les principales étapes mises en œuvre par un récepteur selon un mode de réalisation de l’invention ;
la illustre un exemple de réseau de diffusion mettant en œuvre un transcodeur ;
la illustre un exemple de mise en œuvre de la synchronisation en tête de réseau selon un mode de réalisation particulier ;
la illustre la structure simplifiée d’un SE inserteur, d’un SE monitoring, d’une plateforme de services, ou d’un récepteur selon un mode de réalisation de l’invention.
5. Description de modes de réalisation de l’invention
5.1 Principe général
Comme déjà indiqué en relation avec l’art antérieur, il existe classiquement, en fin de chaine de diffusion (au niveau du dernier équipement du réseau de diffusion ou d’un récepteur), un décalage entre la position réelle d’un événement et sa position souhaitée, définies par rapport à un point de référence du contenu auquel se rapporte l’événement.
Un tel décalage peut être composé de plusieurs décalages provenant :
  • de l’ensemble des variations introduites par le réseau de diffusion (transport, (re)multiplexage, transcodage…)
  • du délai de traitement de l’évènement et de décodage du flux de transport par le récepteur.
Le principe général de l’invention repose sur la détermination d’au moins un de ces décalages, et la compensation de ce ou ces décalages.
La solution proposée permet ainsi de synchroniser, ou de maintenir la synchronisation, d’un événement avec un point de référence d’un contenu, porté par un flux de transport, signalé par cet événement. Elle peut notamment être utilisée pour assurer la synchronisation d’événements de type substitution de contenu (par exemple en HbbTV), affichage de bandeaux, notamment en forme de L (en anglais « L-Banner »), etc.
Selon au moins un mode de réalisation, la solution proposée permet de :
  • déterminer un décalage (éventuellement un décalage moyen) entre une date/position souhaitée de l’événement, et une date/position réelle d’insertion de l’événement, par exemple en fin de chaine de diffusion (au niveau du dernier équipement du réseau de diffusion – également appelé équipement d’extrémité – ou d’un récepteur), et/ou
  • mesurer en continu cette valeur de décalage et adapter automatiquement la correction d’insertion de l’événement dans le flux de transport en fonction de l’évolution du réseau, et/ou
  • adresser plusieurs sous réseaux comportant des décalages différents (puisqu’ils n’utilisent pas la même structure de réseau et pas les mêmes équipements) et/ou des récepteurs comportant des caractéristiques différentes, et donc adapter la synchronisation en compensant les décalages introduits par le réseau et/ou le récepteur, et cela même si les délais varient d’une partie du réseau à l’autre ou d’un récepteur à l’autre, et/ou
  • prendre en compte les écarts de synchronisation jusque dans le récepteur.
5.2 Description des équipements principaux
A. Architecture générale
On présente ci-après le fonctionnement des différents modules mis en œuvre par l’invention, pour la transmission de paquets d’événement de type « Stream Event » au format DSM-CC dans un flux de transport au format MPEG-TS. Bien entendu, l’invention ne se limite pas à ce type de formats d’événement ou de flux de transport.
Afin d’illustrer l’invention, on se place dans le contexte du réseau de diffusion de la , mettant en œuvre :
  • une tête de réseau 21, comprenant au moins un codeur 211 et un multiplexeur 212, prenant en entrée au moins un contenu à diffuser (par exemple un service A) et délivrant en sortie un flux de transport TS, et
  • deux sous-réseaux de diffusion, diffusant le flux de transport TS vers des récepteurs 24, 25, comprenant :
    • un premier sous-réseau de diffusion par satellite 22 mettant en œuvre un satellite 221, un multiplexeur 222 et une passerelle 223,
    • un deuxième sous-réseau de diffusion terrestre 23 mettant en œuvre une passerelle 231.
Le récepteur 24 reçoit par exemple le flux de transport diffusé par le premier sous-réseau de diffusion par satellite 22, et le récepteur 25 reçoit le flux de transport diffusé par le deuxième sous-réseau de diffusion terrestre 23.
Le flux de transport peut être composé de plusieurs contenus, chaque contenu embarquant sa propre horloge de référence.
Bien entendu, une telle structure de réseau est purement illustrative.
Selon un mode de réalisation avantageux, afin de maintenir une synchronisation optimale de l’insertion de l’évènement jusqu’à son utilisation, la solution proposée peut utiliser plusieurs modules permettant d’estimer les variations introduites et de les corriger :
- un dispositif d’insertion d’événement 213, également appelé SE inserteur, insérant des paquets d’événement SE dans le flux de transport TS issu du multiplexeur 222, et
- au moins un dispositif de surveillance d’un flux de transport en sortie d’un équipement du réseau de diffusion, également appelé SE monitoring (par exemple intégré dans le dispositif d’insertion d’événement 213 et configuré pour surveiller le flux de transport en sortie du multiplexeur 222, ou situé à un autre endroit du réseau et configuré pour surveiller le flux de transport en sortie d’une passerelle, d’un transcodeur, …, du réseau) ; dans l’exemple illustré en , les passerelles 223 et 231 sont chacune équipées d’un dispositif de surveillance 2231 et 2311.
De manière optionnelle, une plateforme de services 26 peut également être prévue pour collecter ou fournir des informations sur les différents équipements du réseau et sur les récepteurs.
Enfin, une application spécifique peut être exécutée par les récepteurs 24 et 25.
L’utilisation de certains de ces modules (notamment l’utilisation de plusieurs dispositifs de surveillance, d’une plateforme de service, ou d’applications spécifiques au niveau des récepteurs) est facultative, notamment si la précision de la synchronisation recherchée est faible.
B. Dispositif d’insertion d’un événement dans un flux de transport (SE Inserteur)
On présente, en relation avec la , les principales étapes mises en œuvre par le dispositif d’insertion d’un événement 213, également appelé SE inserteur. Le SE inserteur peut être un équipement dédié ou un module logiciel embarqué dans un autre équipement, par exemple dans le codeur 211 ou le multiplexeur 212 de la tête de réseau.
Un tel dispositif permet d’insérer des paquets d’événement dans le flux de transport
Ainsi, au cours d’une première étape 31, le SE inserteur obtient un flux de transport. A la première itération, le flux de transport ne porte pas de paquets d’événement. Lors des itérations suivantes, le flux de transport peut éventuellement porter un ou plusieurs paquets d’événement insérés au cours d’une itération précédente.
Par exemple, le SE inserteur prend en entrée le flux de transport issu du multiplexeur 212, portant un ou plusieurs contenus, ou directement un flux de transport issu du codeur 211, portant généralement un seul contenu, et délivre en sortie le flux de transport portant au moins un paquet d’événement courant associé à des contenus. Éventuellement, il prend en entrée une information permettant d’identifier un point de référence dans le contenu (message de type SCTE 35, tatouage, etc).
Par la suite, par souci de simplification, on considère que le flux de transport porte un seul contenu (par exemple le service A). Des étapes similaires peuvent être mises en œuvre pour chaque contenu porté par le flux de transport.
Le SE inserteur génère au moins un paquet d’événement à partir d’un point de référence du contenu (par exemple, le service A) porté par le flux de transport.
Plus précisément, un tel paquet d’événement courant porte un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence du contenu ;
  • un délai souhaité entre le paquet d’événement courant et un paquet de référence du contenu identifié à partir de l’information temporelle de référence.
Par exemple, si le point de référence est une image de référence, l’information temporelle de référence correspond à une date de restitution (par exemple une valeur de PTS) de l’image de référence du contenu porté par le flux de transport, en référence à une horloge de référence (par exemple une horloge PCR ou TEMI) embarquée dans le contenu, et le paquet de référence est par exemple le premier paquet codant l’image de référence. En particulier, l’image de référence est une image IDR (en anglais « Instantaneous Decoder Refresh »).
Au cours d’une deuxième étape 32, le SE inserteur insère le paquet d’événement courant dans le flux de transport, à une position définie à partir de la position du paquet de référence et du délai souhaité. Le SE inserteur cherche donc à assurer, lors de l’insertion, la synchronisation du paquet d’événement avec le contenu auquel il se rapporte.
Selon un premier mode de réalisation, un paquet d’événement courant peut être un paquet d’événement de mesure inséré par le SE inserteur pour mesurer le ou les décalage introduit(s) par les différents équipements du réseau.
Selon un deuxième mode de réalisation, un paquet d’événement courant peut être un paquet d’événement utile portant des données utiles associées à l’événement.
Ces deux modes de réalisation, décrits plus en détail par la suite, peuvent être combinés. Par exemple, des paquets d’événement de mesure peuvent être insérés au début de la diffusion du flux de transport pour déterminer les décalages à corriger, puis des paquets d’événement utiles peuvent être insérés au cours de la diffusion du flux de transport pour maintenir la synchronisation.
Le flux de transport dans lequel a été inséré au moins un paquet d’événement courant peut alors être diffusé dans le réseau de diffusion, ou renvoyé en entrée du multiplexeur 212.
Comme décrit par la suite, le paquet d’événement courant inséré dans le flux de transport peut être utilisé par un ou plusieurs dispositifs de surveillance répartis dans le réseau de diffusion pour mesurer le ou les décalages introduits par le réseau, dits décalages de traitement.
Le ou les décalages de traitement obtenus peuvent éventuellement être transmis au SE inserteur 213, directement ou par l’intermédiaire d’un autre équipement, par exemple la passerelle de services 26, pour qu’il modifie la position du paquet d’événement courant dans le flux de transport pour compenser le ou les décalages de traitement, ou qu’il puisse insérer un paquet d’événement suivant dans le flux de transport en anticipant ce décalage de traitement.
Ainsi, selon un mode de réalisation particulier, le SE inserteur 213 obtient au cours d’une étape 33 un décalage de traitement entre une position réelle du paquet d’événement courant dans le flux de transport, en sortie d’un équipement à surveiller du réseau de diffusion (par exemple le multiplexeur 212, la passerelle 231, la passerelle, 223, etc), et une position souhaitée du paquet d’événement courant dans le flux de transport, déterminée à partir de l’information temporelle de référence et du délai souhaité.
Le SE inserteur peut notamment déterminer lui-même cette valeur de décalage (par exemple s’il dispose d’un dispositif de surveillance), ou recevoir cette valeur de décalage en provenance d’un dispositif de surveillance du réseau (par exemple les SE monitoring 2231 ou 2311), directement ou par l’intermédiaire de la plateforme de services 26, par exemple sous la forme de notifications.
L’obtention de ce décalage de traitement par le SE inserteur 213 permet notamment de corriger la position du paquet d’événement courant dans le flux de transport, ou d’insérer un paquet d’événement suivant dans le flux de transport à une position souhaitée, de façon à compenser un décalage de traitement introduit par au moins un équipement du réseau (multiplexeur 212, passerelle 223, passerelle 231, etc).
Ce décalage peut notamment être transmis à un autre équipement du réseau de diffusion, par exemple à la plateforme de services 26.
En particulier, le SE inserteur 213 peut déterminer un décalage de traitement « moyen » à réception de plusieurs valeurs de décalage de traitement en provenance d’un même dispositif de surveillance, ou directement recevoir un décalage de traitement « moyen ».
Selon un mode de réalisation particulier, le SE inserteur 213 peut également mettre en œuvre la réception 34 d’un décalage de réception déterminé en fonction d’un type de récepteur destiné à recevoir le flux de transport.
Par exemple, les caractéristiques de différents récepteurs selon leur type (par exemple selon leur marque, leur modèle) peuvent être déterminées lors de tests en laboratoire et stockées dans une base de données. Une telle base de données peut être accessible au SE inserteur 213, directement ou par l’intermédiaire de la plateforme de services 26. De cette façon, il est également possible d’estimer le décalage introduit par le récepteur entre l’affichage de l’image de référence et la réception du paquet d’événement, au niveau de l’application HbbTV par exemple, et de compenser ce décalage.
On note que ces étapes d’obtention d’un décalage de traitement 33 ou d’un décalage de réception 34 sont facultatives, et peuvent être mises en œuvre indépendamment l’une de l’autre.
Le SE inserteur a ainsi la possibilité de recevoir des notifications de la plateforme de services ou d’un dispositif de surveillance du réseau, portant au moins une valeur de décalage de traitement ou décalage de réception.
Le ou les décalages obtenus, éventuellement moyennés, peuvent être utilisés par le SE inserteur pour modifier la position du paquet d’événement courant dans le flux de transport et/ou pour insérer un paquet d’événement suivant dans le flux de transport à une position permettant d’assurer une synchronisation entre l’événement et le point de référence auquel il se réfère, en compensant le ou les décalages obtenus. En particulier, un paquet d’événement suivant peut être un paquet d’événement « classique », au format DSM-CC par exemple, ne portant pas d’entête de synchronisation. Il peut notamment être associé à un contenu distinct du paquet d’événement courant.
Par exemple, le SE inserteur intègre une valeur de décalage de traitement ou décalage de réception lors de l’insertion d’un paquet d’événement en additionnant la valeur reçue au décalage initialement prévu lors de l’insertion. Cela a pour but d’obtenir une synchronisation correcte du paquet d’événement au moment de la diffusion en compensant les actions du réseau sur la position du paquet d’événement par rapport au point de référence avec lequel il est synchronisé.
Cette boucle de rétroaction peut être permanente, ce qui permet de maintenir la synchronisation même si certains paramètres du réseau de diffusion sont modifiés, ou mise en œuvre ponctuellement (par exemple lors de l’installation du réseau, lors de l’ajout d’un nouvel équipement dans le réseau, à intervalles de temps régulier (une fois par semaine, une fois par mois, etc), lorsqu’une perte de synchronisation est détectée, etc.
En résumé, le SE inserteur peut exécuter au moins une action parmi :
  • insérer au moins un paquet d’événement (paquet d’événement de mesure, paquet d’événement utile synchronisé avec le contenu auquel il se rapporte) ;
  • corriger la synchronisation lors de l’insertion d’un paquet d’événement, en compensant les décalages de traitement et/ou de réception ;
  • etc.
C. Paquets d’événement
Comme indiqué ci-dessus, différents paquets d’événement peuvent être utilisés pour mesurer le ou les décalages et améliorer la synchronisation.
Ainsi, selon un premier mode de réalisation, un paquet d’événement courant peut être un paquet d’événement de mesure inséré par le SE inserteur pour mesurer le ou les décalage introduit(s) par au moins un équipement du réseau. Dans ce cas, le SE inserteur prend en entrée le flux de transport issu du multiplexeur 212, ou du codeur 211, et délivre en sortie un flux de transport portant au moins un paquet d’événement de mesure.
Par exemple, le SE inserteur sélectionne une image dans le contenu, dite image de référence. Cette image peut être sélectionnée de façon aléatoire. Le SE inserteur lit la valeur de PTS associée à cette image de référence, et la stocke dans le champ « information temporelle de référence » de l’entête de synchronisation du paquet d’événement de mesure. Le SE inserteur insère le paquet d’événement de mesure juste avant le premier paquet portant l’image de référence, dit paquet de référence, et stocke une valeur nulle dans le champ « délai souhaité ». En variante, le SE inserteur remplace un paquet de bourrage dans le flux de transport par le paquet d’événement de mesure, et stocke dans le champ « délai souhaité » une valeur correspondant au nombre de paquets TS utilisant la même horloge de référence (i.e. associés au même contenu) entre le paquet de bourrage remplacé par le paquet d’événement de mesure et le premier paquet portant l’image de référence.
On note à cet effet que ce décalage ou délai peut être calculé en nombre de paquets TS se basant sur l’horloge utilisée pour l’information temporelle de référence. Par exemple, le décalage est calculé en nombre de paquets TS appartenant au même contenu. En variante, le décalage peut être calculé en nombre de paquets TS appartenant au flux de transport. Dans ce cas, si l’incrément de la valeur d’horloge entre deux paquets TS appartenant à un même contenu est de X ms, on peut diviser cette valeur par le nombre de paquets TS du flux de transport entre deux paquets TS appartenant à un même contenu. L’utilisation de tous les paquets du flux de transport est donc plus précise, car chaque paquet correspond à une durée plus courte.
La conversion en temps peut être réalisée en multipliant le nombre de paquets d’écart par la durée d’émission d’un paquet TS.
La durée d’émission d’un paquet peut être calculée en comptant le nombre de paquets dans le flux de transport entre deux paquets portant une valeur de la même horloge de référence (PCR ou TEMI par exemple).
En particulier, un paquet d’événement de mesure porte un identifiant de synchronisation, permettant aux autres équipements du réseau ou aux récepteurs de détecter qu’il s’agit d’un paquet utilisé pour la synchronisation.
La illustre un exemple de structure d’un tel paquet d’événement de mesure, comprenant un entête SE_H 41 (« SE header »), et une partie utile SE_P 42 (« SE payload »). La partie utile 42 comprend uniquement un entête de synchronisation, portant par exemple trois champs :
  • un champ SYNC 421, par exemple sur 4 octets, portant un identifiant de synchronisation permettant d’identifier que le paquet d’événement est utilisé pour la synchronisation. Il peut contenir par exemple la valeur « ARSC » codée en ascii ;
  • un champ D 422 (« Delai », ou « Delay ms »), par exemple sur 2 octets, portant un délai souhaité entre le paquet d’événement de mesure et un paquet de référence du contenu, identifié à partir de l’information temporelle de référence (le paquet de référence étant par exemple le premier paquet portant l’image de référence dont la valeur de PTS est présente dans le champ PTS 423) ; un tel délai ou décalage s’exprime notamment en temps (par exemple en millisecondes ou en nanosecondes) pour pouvoir être utilisé par les récepteurs,
  • un champ PTS 423, par exemple sur 5 octets, portant une information temporelle de référence définie par rapport à une horloge de référence embarquée dans le contenu (par exemple la valeur de PTS de l’image de référence).
Un tel paquet d’événement utile peut être utilisé par les équipements successifs du réseau pour mesurer le ou les décalages, introduits par les différents équipements du réseau, entre la position réelle du paquet d’événement utile (Stream Event) et sa position souhaitée.
En particulier, un tel paquet d’événement de mesure porte un identifiant de paquet (PID, en anglais « Packet Identifier ») signalant qu’il est de type paquet d’événement, ou un PID fantôme. Classiquement, un PID fantôme n’est référencé dans aucune table de description du flux (PAT, PMT). Il est donc uniquement interprétable par des équipements ayant été spécifiquement configurés pour l’utiliser, et ignoré par les autres équipements.
Notamment, le SE inserteur utilise le même PID pour le paquet d’événement et les paquets utiles d’un contenu. De cette façon, on s’affranchit de problèmes potentiels d’implémentation de certains équipements. Par exemple, si un équipement utilise en entrée une file par PID, le traitement des files peut être différent. Si le paquet d’événement et les paquets utiles d’un même contenu portent le même PID, ils sont traités de la même façon par l’équipement, ce qui permet d’assurer une mesure précise du délai.
Selon un deuxième mode de réalisation, un paquet d’événement courant peut être un paquet d’événement utile portant des données utiles associées à un événement. Dans ce cas, le SE inserteur prend en entrée le flux de transport issu du multiplexeur 212, ou le contenu issu du codeur 211, et une information permettant de sélectionner une image de référence dans le contenu (message de type SCTE 35, tatouage, etc), et délivre en sortie un flux de transport portant au moins un paquet d’événement utile. Par exemple, le SE inserteur sélectionne une image de référence du contenu.
Selon ce deuxième mode de réalisation, le SE inserteur insert, dans le flux de transport, au moins un paquet d’événement utile synchronisé avec le contenu auquel il se rapporte.
Selon une première variante, l’image de référence peut être identifiée à partir d’un message de type SCTE 35. En effet, le SE inserteur peut recevoir sur son entrée le flux de transport issu du multiplexeur 212 et des messages SCTE 35 (par exemple de type « time-signal » ou « splice insert ») contenant des PTS qui référencent des images. De tels messages SCTE 35 peuvent être envoyés en pré-roll, par exemple quelques secondes avant l’image qu’ils référencent. La synchronisation peut être effectuée lors de la conversion des messages SCTE 35 en paquets d’événement, en utilisant la valeur de la PTS de l’image de référence et la PCR du contenu.
Selon une deuxième variante, l’image de référence peut être identifiée à partir d’un tatouage porté par l’image de référence. Dans ce cas, le SE inserteur cherche à détecter, dans le contenu, une image portant un tatouage connu du SE inserteur (« fingerprint video »). Cette variante permet de s’affranchir des messages SCTE 35, mais nécessite la connaissance des tatouages associés aux images à détecter. Il peut également être nécessaire d’ajouter un stockage en mémoire tampon (également appelé « bufferisation ») du flux de transport, afin de permettre une insertion d’un paquet d’événement utile en amont d’une image de référence.
Le SE inserteur lit la valeur de PTS associée à cette image de référence, et la stocke dans le champ « information temporelle de référence » de l’entête de synchronisation du paquet d’événement utile.
Le SE inserteur insère le paquet d’événement utile en tenant compte du délai souhaité entre le paquet d’événement utile et le paquet de référence (valeur choisie par le SE inserteur, valeur de pré-roll d’insertion, ou valeur mesurée à une itération précédente par exemple).
En particulier, un tel paquet d’événement utile porte un identifiant de synchronisation, permettant aux autres équipements du réseau ou aux récepteurs de détecter qu’il s’agit d’un paquet utilisé pour la synchronisation.
La illustre un exemple de structure d’un tel paquet d’événement utile, comprenant un entête SE_H 51 (« SE header »), et une partie utile SE_P 52 (« SE payload »). La partie utile 52 comprend un entête de synchronisation et des données utiles 525, par exemple des données privées décrivant l’événement.
L’entête de synchronisation comprend par exemple quatre champs :
  • un champ SYNC 521, par exemple sur 4 octets, portant un identifiant de synchronisation permettant d’identifier que le paquet d’événement est utilisé pour la synchronisation. Il peut contenir par exemple la valeur « ARSU » codée en ascii ;
  • un champ Ins. Pos. 522, par exemple sur 2 octets, portant un délai souhaité entre le paquet d’événement utile et un paquet de référence du contenu identifié à partir de l’information temporelle de référence (le paquet de référence étant par exemple le premier paquet portant l’image de référence dont la valeur de PTS est présente dans le champ PTS 524). Un tel délai ou décalage s’exprime notamment en temps (par exemple en millisecondes ou en nanosecondes) pour pouvoir être utilisé par les récepteurs,
  • un champ PTS 524, par exemple sur 5 octets, portant une information temporelle de référence définie par rapport à une horloge de référence embarquée dans le contenu (par exemple la valeur de PTS de l’image de référence),
  • éventuellement un champ G 523 (« gap »), par exemple sur 2 octets, portant une valeur de décalage mesurée entre la position souhaitée du paquet d’événement utile (déterminée à partir du champ Ins. Pos.) et sa position réelle dans le flux de transport. Un tel délai ou décalage s’exprime notamment en temps (par exemple en millisecondes ou en nanosecondes) pour pouvoir être utilisé par les récepteurs. En particulier, si le paquet d’événement est inséré au bon endroit dans le flux de transport (i.e. sa position réelle coïncide avec sa position souhaitée), la valeur de ce champ est égale à 0.
En particulier, les valeurs des champs Ins. Pos. 522 et G 523 peuvent être mises à jour tout au long de la chaine de diffusion, par exemple par les dispositifs de surveillance, et utilisées par le récepteur pour corriger la synchronisation.
Un paquet d’événement utile peut être utilisé par les équipements successifs du réseau pour mesurer le ou les décalages, introduits par les différents équipements du réseau, entre la position réelle du paquet d’événement utile (Stream Event) et sa position souhaitée.
En particulier, au niveau d’un récepteur, un paquet d’événement utile peut comporter, dans le champ Ins. Pos., une valeur de décalage en millisecondes entre la réception du paquet d’événement utile (position réelle du paquet d’événement) et la position réelle de l’affichage de l’image de référence signalée par le paquet d’événement (position du paquet de référence). La connaissance de cette valeur permet notamment aux récepteurs de temporiser le lancement d’une action lors de la réception du paquet d’événement utile.
Comme déjà indiqué, pour la mesure du décalage, cette valeur peut être exprimée en paquet TS. En revanche, elle peut être convertie en temps (par exemple milliseconde ou nanoseconde) pour être utilisée par un récepteur.
D. Dispositif de surveillance (SE monitoring)
Comme indiqué ci-dessus, certains équipements du réseau de diffusion, par exemple le SE inserteur 213 et/ou la passerelle 223 du premier sous -réseau de diffusion, et/ou la passerelle 231 du deuxième sous-réseau de diffusion, etc), peuvent coopérer avec un dispositif de surveillance, permettant de déterminer le délai de traitement introduit par cet équipement ou par le réseau jusqu’à cet équipement. Par exemple, comme illustré en relation avec la , la passerelle 223 est surveillée par le dispositif de surveillance 2231, et la passerelle 231 est surveillée par le dispositif de surveillance 2311. D’autres équipements du réseau pourraient également être surveillés par un dispositif de surveillance, notamment les équipements qui modifient le flux de transport en modifiant l’ordonnancement des paquets (multiplexeur, transcodeur par exemple).
On présente, en relation avec la , les principales étapes mises en œuvre par un dispositif de surveillance, également appelé SE monitoring. Le SE monitoring peut être un équipement dédié ou un module logiciel embarqué par un autre équipement (par exemple le SE inserteur 213 et/ou la passerelle 223 et/ou la passerelle 231).
Au cours d’une première étape 61, le SE monitoring obtient un flux de transport délivré par l’équipement à surveiller (i.e. le flux de transport en sortie de l’équipement à surveiller, noté TS + SE), portant au moins un paquet d’événement courant.
Au cours d’une étape suivante 62, le SE monitoring cherche, dans le flux de transport, des paquets d’événement portant un entête de synchronisation (paquet(s) d’événement de mesure et/ou paquet(s) d’événement utile(s)). Par exemple, le SE monitoring lit le champ SYNC 421, 521 d’un paquet d’événement et détecte qu’il s’agit d’un paquet d’événement utilisé pour la synchronisation.
Comme déjà décrit, un tel paquet d’événement courant, préalablement inséré par le SE inserteur 213, est associé à un contenu porté par le flux de transport (par exemple, le service A) et porte un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence du contenu ;
  • un délai souhaité entre le paquet d’événement courant et un paquet de référence du contenu identifié à partir de l’information temporelle de référence,
A partir des informations présentes dans l’entête de synchronisation, le SE monitoring peut déterminer 63 un décalage entre une position réelle du paquet d’événement courant dans le flux de transport, et une position souhaitée du paquet d’événement courant dans le flux de transport, dit décalage de traitement.
Si l’on reprend l’exemple illustré en figure 1, l’information temporelle de référence permet d’identifier le paquet de référence 111. Le délai souhaité entre le paquet d’événement courant 110 et le paquet de référence est défini par le pré-roll 12, et permet de définir la position souhaitée 114 du paquet d’événement courant dans le flux de transport. Le décalage entre la position réelle du paquet d’événement courant 110 et sa position souhaitée 114 correspond au décalage de traitement 13 ( ).
Par exemple, si le paquet d’événement courant détecté est un paquet d’événement utile, le SE monitoring extrait la valeur du champ PTS 524, portant l’information temporelle de référence, et la valeur du champ Ins. Pos. 522, portant le délai souhaité entre le paquet d’événement utile et un paquet de référence du contenu identifié à partir de l’information temporelle de référence.
Le SE monitoring cherche ensuite la position du paquet de référence dans le flux de transport, i.e. la position du paquet (par exemple un paquet vidéo) contenant la valeur de PTS du champ PTS 524.
A partir de la position du paquet de référence et de la valeur du champ Ins. Pos. 522, le SE monitoring détermine la position souhaitée (i.e. théorique) du paquet d’événement, et l’écart en nombre de paquets TS entre la position réelle du paquet d’événement et sa position souhaitée.
Cet écart, correspondant au décalage de traitement, peut éventuellement être stocké dans le champ G 523 de l’entête de synchronisation du paquet d’événement, comme décrit ci-après.
Le SE monitoring peut transmettre le décalage de traitement ainsi déterminé à au moins un autre équipement du réseau de diffusion, par exemple sous la forme d’une notification : au SE inserter 213, à la plateforme de services 26, à un équipement en aval du réseau de diffusion, etc.
De cette façon, il est possible d’informer les autres équipements du réseau du décalage introduit par l’équipement à surveiller pour compenser cette valeur de décalage. Une telle compensation du décalage de traitement peut être mise en œuvre :
  • en amont de l’équipement à surveiller, ou dans l’équipement à surveiller, de sorte que l’événement soit synchronisé avec le contenu auquel il se rapporte dans le flux de transport en sortie de l’équipement à surveiller, ou
  • en aval de l’équipement à surveiller, de façon à corriger la synchronisation de l’événement dans un équipement en aval du réseau de diffusion.
Selon un mode de réalisation particulier, le SE monitoring met à jour l’entête de synchronisation avec le décalage de traitement ainsi déterminé. Par exemple, la valeur du champ G 523 est mise à jour en la remplaçant par le décalage de traitement . De cette façon, il est possible d’informer les autres équipements du réseau du décalage de traitement introduit par l’équipement à surveiller. En particulier, un CRC (pour « Cyclic Redundancy Check » en anglais) peut être recalculé pour le paquet d’événement ainsi mis à jour. On note que cette mise à jour ne modifie pas la position des paquets dans le flux de transport et n’impacte donc pas les valeurs de l’horloge de référence.
Selon un autre mode de réalisation, le SE monitoring met en œuvre une étape de modification de la position du paquet d’événement courant dans le flux de transport tenant compte du décalage de traitement, et une étape de transmission du flux de transport modifié. De cette façon, il est possible de compenser le décalage de traitement avant de poursuivre la diffusion du flux de transport.
Par exemple, si le paquet d’événement courant est un paquet d’événement utile, le SE monitoring lit la valeur du champ Ins. Pos. 522, portant le délai souhaité entre le paquet d’événement utile et un paquet de référence du contenu identifié à partir de l’information temporelle de référence, et la valeur de PCR du paquet d’événement.
Le SE monitoring cherche ensuite le paquet de référence servant de référence pour trouver le point d’insertion (par exemple le premier paquet portant l’image de référence dont la valeur de PTS est présente dans le champ PTS 524).
Le SE monitoring peut alors déplacer le paquet d’événement pour l’insérer à la position souhaitée par rapport à la valeur de PCR. Pour réaliser ce déplacement, le SE monitoring dispose d’une mémoire tampon, ou buffer. Par exemple, un buffer de 1 seconde permet de rattraper des retards de 1 seconde au plus. Cette modification demande un ajustement des PCR du flux de transport. En particulier, le SE monitoring ne peut déplacer le paquet d’événement que d’un nombre entier de paquets TS. Si la valeur de décalage qu’il reçoit est en ms, il convertit cette valeur en nombre de paquets TS.
En particulier, le SE monitoring peut mettre en œuvre une étape de suppression de l’entête de synchronisation du paquet d’événement courant avant la transmission du flux de transport modifié, notamment si le paquet d’événement courant est de type paquet d’événement utile. En effet, une fois le paquet d’événement courant correctement positionné dans le flux de transport pour compenser le décalage de traitement, il n’est plus nécessaire de conserver l’entête de synchronisation du paquet d’événement courant. De cette façon, la compensation des décalages pour améliorer la synchronisation d’un événement avec le contenu auquel il se rapporte est transparente pour les récepteurs recevant le flux de transport, et compatible avec les récepteurs hybrides actuels.
Selon un mode de réalisation particulier, le décalage de traitement est un décalage moyen obtenu à l’issue d’au moins deux itérations des étapes de détection d’un paquet d’événement courant et de détermination d’un décalage entre une position réelle du paquet d’événement courant dans le flux de transport, et une position souhaitée.
Comme déjà indiqué, un ou plusieurs SE monitoring peuvent être prévus dans le réseau de diffusion (un SE monitoring intégré dans le SE inserteur, ou bien un SE monitoring au niveau d’une seule passerelle, ou bien un SE monitoring au niveau de chaque passerelle de diffusion, ou bien un SE monitoring intégré dans le SE inserteur et un SE monitoring au niveau de chaque passerelle de diffusion, etc).
Dans ce cas, chaque SE monitoring peut utiliser les informations spécifiques portées par un paquet d’événement pour exécuter au moins une action parmi :
  • déterminer la position souhaitée d’un paquet d’événement par rapport à un point de référence du contenu auquel l’événement se rapporte ;
  • déterminer la position réelle du paquet d’événement par rapport au point de référence du contenu auquel l’événement se rapporte ;
  • déterminer le décalage entre les positions réelle et souhaitée ;
  • stocker le décalage ou la/les position(s) déterminé(e)(s) ;
  • envoyer le décalage ou la/les position(s) déterminé(e)(s) à un autre équipement du réseau de diffusion, par exemple à la plateforme de services 26 (par exemple via une connexion IP) et/ou au SE inserteur 213 ;
  • mettre à jour l’entête de synchronisation du paquet d’événement (par exemple le champ G 523 d’un paquet d’événement utile), qui pourra être transmis aux équipements suivants de la chaine de diffusion et cela jusqu’aux récepteurs (et donc utilisé par le récepteur pour la synchronisation) ;
  • modifier la position du paquet d’événement courant dans le flux de transport pour compenser le décalage, en replaçant le paquet d’événement le plus près possible de sa position d’insertion souhaitée ;
  • etc.
On note par ailleurs qu’en cas de retard important des paquets d’événement, un paquet de référence (i.e. contenant par exemple une valeur de PTS recherchée dans le contenu) peut être reçu avant le paquet d’événement qui le référence. Il est donc souhaitable de conserver également en mémoire les dernières valeurs de PTS reçues et leur position dans le flux de transport (i.e. position des paquets de référence et PTS contenues dans ces paquets de référence). De même, il peut être souhaitable de mettre en place une bufferisation du flux de transport afin de pouvoir modifier la position du paquet d’événement dans le flux de transport, même si la position d’insertion est passée par rapport à la réception du paquet d’événement.
E. Plateforme de services
Selon un mode de réalisation particulier, la solution proposée met en œuvre une plateforme de services, par exemple la plateforme de services internet 26 illustrée en , permettant notamment de recevoir et stocker les différentes valeurs de décalage de traitement et/ou de réception, et de les transmettre aux équipements intéressés.
Une telle plateforme de services peut notamment être configurée pour communiquer avec le SE inserteur 213, avec un ou plusieurs SE monitoring 223, 231, avec un ou plusieurs récepteurs 24, 25, etc.
On présente, en relation avec la , les principales étapes mises en œuvre par la plateforme de services 26.
Au cours d’une première étape 71, la plateforme de services 26 obtient au moins un décalage parmi :
  • au moins un décalage entre une position réelle d’un paquet d’événement courant dans le flux de transport, en sortie d’un équipement du réseau de diffusion, et une position souhaitée du paquet d’événement courant dans le flux de transport (décalage de traitement),
  • un décalage déterminé en fonction d’un type de récepteur destiné à recevoir ledit flux de transport (décalage de réception).
Par exemple, l’obtention d’au moins un décalage de traitement ( ) met en œuvre la réception d’au moins un décalage déterminé par un SE monitoring.
En d’autres termes, au moins un SE monitoring présent dans le réseau de diffusion détermine un décalage de traitement en sortie d’un équipement du réseau, et transmet ce décalage de traitement à la plateforme de services 26. Si plusieurs valeurs de décalage de traitement sont reçues pour un même équipement à surveiller, la plateforme de services peut déterminer un décalage moyen associé à cet équipement.
L’obtention d’un décalage de réception ( ) met par exemple en œuvre la lecture d’une base de données stockant les caractéristiques des différents récepteurs selon leur type. Par exemple, la plateforme de services peut identifier le type de récepteur à partir d’une requête émise par le récepteur et reçue par la plateforme de services. Notamment, la plateforme peut utiliser l’agent utilisateur (en anglais « user agent » ou UA) d’une requête http émise par le récepteur pour reconnaître le récepteur. Par exemple, un filtrage est appliqué aux UA pour déterminer le type de récepteur.
Au cours d’une étape suivante 72, la plateforme de services transmet le ou les décalages de traitement et/ou de réception obtenus, éventuellement moyennés, à au moins un autre équipement du réseau de diffusion. En variante, la plateforme de services peut transmettre un décalage global déterminé à partir du ou des décalages de traitement et/ou de réception obtenus, éventuellement moyennés. En particulier, si des valeurs de décalage de traitement sont reçues pour des équipements appartenant à des sous-réseaux différents (par exemple une première valeur de décalage de traitement liée à la passerelle 223 du premier sous-réseau 22, et une deuxième valeur de décalage de traitement liée à la passerelle 231 du deuxième sous-réseau 23), la passerelle transmet au SE inserteur 213 la valeur de décalage de traitement la plus grande, permettant de compenser tous les retards induits par les différents sous réseaux. Un exemple est présenté par la suite.
La plateforme de services peut donc exécuter au moins une action en lien avec les récepteurs, parmi :
  • stocker des décalages de réception (i.e. délais liés aux récepteurs ou informations de synchronisation) par type de récepteur ;
  • identifier un type de récepteur, par exemple en utilisant l’UA dans la requête http ;
  • transmettre au récepteur le décalage de réception déterminé en fonction du type de récepteur (i.e. délai à utiliser pour maintenir la synchronisation ou informations de synchronisation), par exemple via une application HbbTV ;
  • recevoir des informations de délai du réseau envoyées par les récepteurs ;
  • etc.
La plateforme de services peut également exécuter au moins une action en lien avec les autres équipements du réseau de diffusion, parmi :
  • stocker des décalages de traitement (i.e. délais mesurés dans le réseau, déterminés par le(s) SE monitoring et le SE inserteur) ;
  • déterminer des retards / décalages de traitement moyens ;
  • calculer le délai d’anticipation minimum pour l’insertion du paquet d’événement pour compenser tous les retards induits par les différents sous réseaux, dans le cas d’un réseau comportant plusieurs sous réseaux, pour que le paquet d’événement puisse être utilisé dans tous les sous-réseaux ;
  • notifier les différents équipements du réseau (notamment le SE Inserteur) du ou des décalages de traitement et/ou de réception à appliquer pour optimiser la synchronisation ;
  • etc.
F. Récepteur
La solution proposée peut être mise en œuvre dans des récepteurs hybrides, supportant notamment le standard HbbTV. De tels récepteurs sont notamment adaptés à recevoir des paquets d’événement classiques, notamment des paquets SE au format DSM-CC tels que définis dans la norme ISO/IEC 13818-6 précitée.
Selon un mode de réalisation particulier, de tels récepteurs peuvent mettre en œuvre un module logiciel, noté SDK, qui peut être intégré à une application HbbTV destinée à être exécutée sur les récepteurs. Dans ce cas, les récepteurs sont adaptés à recevoir des paquets d’événement selon l’invention, portant un entête de synchronisation tel que décrit précédemment. Un tel module logiciel peut notamment être utilisé pour améliorer la synchronisation sur le récepteur.
En particulier, pour que l’application HbbTV puisse synchroniser un évènement avec le contenu auquel il se rapporte, elle peut soit recevoir un évènement synchronisé avec le contenu, soit recevoir un évènement en avance ainsi que le délai entre cet évènement et le point de synchronisation.
Dans le premier cas, la mise en œuvre du module logiciel n’est pas nécessaire puisque la synchronisation est effectuée en amont. Dans le deuxième cas, la mise en œuvre du module logiciel permet d’utiliser les informations portées par un paquet d’événement pour synchroniser l’événement avec le contenu au niveau du récepteur. Dans ce deuxième cas, pour réaliser la synchronisation, le module logiciel utilise la date de réception du paquet d’événement, les informations portées par l’entête de synchronisation du paquet d’événement, et, si elles sont disponibles, les informations liées au récepteur (permettant de compenser le décalage de réception).
Ainsi, la illustre les principales étapes mises en œuvre par un récepteur selon l’invention.
Un tel récepteur met en œuvre la réception 81 d’un flux de transport portant au moins un paquet d’événement courant associé à un contenu porté par le flux de transport, le paquet d’événement courant portant un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu,
  • un délai souhaité ou réel entre le paquet d’événement courant et un paquet de référence du contenu identifié à partir de l’information temporelle de référence.
En particulier, si le paquet d’événement est un paquet utile dans lequel l’entête de synchronisation a été mis à jour, le délai stocké dans le champ Ins. Pos. peut être le délai réel entre le paquet d’événement courant et le paquet de référence.
Au cours d’une étape suivante, le récepteur synchronise 82 l’événement porté par des données utiles du paquet d’événement courant avec un point de référence associé à l’information temporelle de référence, en tenant compte d’un délai d’attente déterminé à partir de l’entête de synchronisation du paquet d’événement courant.
Les étapes précédentes permettent de compenser le ou les décalages de traitement liés aux équipements du réseau de diffusion.
Éventuellement, pour compenser le décalage de réception lié au type de récepteur, le récepteur met en œuvre une étape d’obtention d’un décalage de réception, reçu par exemple de la plateforme de services. Le récepteur, ou le module logiciel, peut ainsi communiquer avec la plateforme pour obtenir le délai de réception lié au type de récepteur.
Dans ce cas, le délai d’attente tient également compte de ce décalage de réception.
En d’autres termes, le récepteur peut effectuer une resynchronisation d’un événement avec le contenu auquel il se rapporte, par exemple l’affichage d’une vidéo, en utilisant les valeurs de décalages de traitement et/ou de réception obtenues dans les paquets d’événement et/ou via la plateforme de services.
En particulier, il est possible de filtrer, au niveau d’un récepteur, les entêtes de synchronisation. Dans ce cas, seule la partie utile est remontée à l’application HbbTV, et cela au bon moment. De cette façon, l’opération de synchronisation peut être transparente pour l’application HbbTV.
Le module logiciel, exécuté sur le récepteur, peut ainsi mettre en œuvre au moins une action parmi :
  • s’abonner, auprès du récepteur, à la réception de paquets d’événement présents dans le flux de transport ;
  • obtenir des informations sur le type du récepteur via une requête http à la plateforme de services, notamment un décalage de réception. Cette valeur est notamment liée au délai de décodage du contenu (par exemple une vidéo) dans le récepteur et au délai de remontée des événements vers le middleware HbbTV ;
  • extraire des informations de l’entête de synchronisation lors de la réception d’un paquet d’événement, permettant de synchroniser l’événement avec le contenu auquel il se rapporte ;
  • déterminer un délai d’attente entre la réception d’un paquet d’événement et la notification de l’application HbbTV. Cette valeur correspond à la resynchronisation dans le récepteur. Le délai d’attente est par exemple égal à la somme de la valeur de pré-roll, du retard/délai ajouté par le réseau (décalage de traitement), du retard/délai ajouté dans le récepteur (décalage de réception). Pour cela, le module logiciel peut utiliser la valeur du champ G 523 de l’entête de synchronisation, qui porte une valeur de décalage de traitement lié au réseau de diffusion (retard ou avance du paquet d’événement) et éventuellement la valeur de décalage de réception liée au récepteur ;
  • à l’issue du délai d’attente, notifier l’application HbbTV avec les données utiles du paquet d’événement ;
  • envoyer à la plateforme de services les informations de décalage portées par les paquets d’événement pour permettre la surveillance / monitoring du réseau de diffusion ;
  • etc.
G. Transcodeur
Dans le cas où le flux de transport passe par un équipement de type transcodeur, on note que la structure du flux de transport peut être modifiée : le transcodeur peut changer les valeurs de l’horloge de référence embarquée dans le contenu (et donc l’information temporelle de référence, par exemple les PTS) et/ou modifier la position des images de référence dans le flux de transport.
La illustre un exemple d’un réseau de diffusion mettant en œuvre un transcodeur, comprenant :
  • une tête de réseau 91, comprenant au moins un codeur 911 et un multiplexeur 912, prenant en entrée au moins un contenu à diffuser (par exemple un service A) et délivrant en sortie un flux de transport TS, et
  • un sous-réseau de diffusion terrestre 92, diffusant le flux de transport TS vers un récepteur 93, mettant en œuvre un transcodeur 921.
La tête de réseau met également en œuvre un premier SE inserteur 913 tel que décrit précédemment.
En cas de modification de l’horloge de référence d’un contenu, si le transcodeur 921 est en capacité de conserver les paquets SCTE 35 et de corriger les valeurs de PTS pour les mettre en conformité avec la nouvelle horloge de référence, alors un équipement en amont du transcodeur pourra supprimer le ou les paquets d’événement précédemment insérés et effectuer une nouvelle insertion en utilisant les commandes SCTE 35 modifiées.
Si le délai de passage dans le transcodeur est fixe et connu, il est possible de faire appliquer un décalage de traitement à tous les paquets d’événement du flux de transport, par un équipement en aval du transcodeur. Les paquets d’événement peuvent soit être déplacés dans le flux de transport pour anticiper ce décalage de traitement, soit leur entête de synchronisation peut être mis à jour avec cette nouvelle valeur de décalage de traitement. Les valeurs de PTS de l’entête de synchronisation doivent également être mises à jour.
Si le transcodeur ne change ni les horloges ni la structure du flux de transport (l’image de référence est conservée) alors les paquets d’événement précédemment insérés restent valides.
Si le transcodeur change toute la structure du flux de transport, la synchronisation entre un paquet d’événement et le contenu auquel il se rapporte est généralement perdue. Dans ce cas, un deuxième SE inserteur 922 peut être prévu en aval du transcodeur 921. Le maintien de la synchronisation peut alors être effectué en déterminant un tatouage d’au moins une image de référence au niveau de la tête de réseau par le premier SE inserteur 913. Le deuxième SE inserteur 922 peut recevoir le ou les tatouages en provenance du premier SE inserteur 913 et chercher les images correspondantes dans le flux de transport. Quand les images sont trouvées, le deuxième SE inserteur 922 peut reconstruire les paquets d’événement comme décrit précédemment en relation avec le SE inserteur 213 et les insérer dans le flux de transport.
On note que ce mode de réalisation demande à bufferiser le flux de transport pour permettre l’insertion des paquets d’événement à la position demandée.
5.3 Exemples de réalisation
On présente ci-après quelques exemples de mise en œuvre de l’invention.
A. Synchronisation en tête de réseau
Selon un premier exemple, illustré en , on cherche uniquement à mesurer le décalage introduit entre un paquet d’événement et le contenu auquel il se rapporte en tête de réseau.
Pour ce faire, on considère que la tête de réseau comprend, de manière classique, un codeur 100 et un multiplexeur 101. La tête de réseau comprend également un SE monitoring 102 et un SE inserteur 103 selon un mode de réalisation de l’invention.
Le SE monitoring 102 et le SE inserteur 103 peuvent être hébergés sur le même équipement ou sur des équipements distincts.
Comme illustré en , le multiplexeur 101 reçoit des contenus, par exemple des flux vidéo, en provenance de différents codeurs, notamment du codeur 100. De tels contenus peuvent contenir des commandes SCTE 35. Il multiplexe les flux vidéo, et le multiplexe ainsi construit est envoyé sous la forme d’un flux de transport en entrée du SE monitoring 102 et aux équipements de diffusion.
S’il ne détecte aucun paquet d’événement dans le flux de transport (par exemple il ne détecte pas d’entête de synchronisation ou d’identifiant de synchronisation dans le champ SYNC), le SE monitoring 102 n’effectue aucun traitement sur le flux de transport et le fait suivre au SE inserteur 103.
Si une commande SCTE est détectée, elle peut être transformée en paquet d’événement utile par le SE inserteur. Le SE inserteur 103 peut ainsi construire un paquet d’événement utile à partir de la commande SCTE et du flux vidéo auquel elle se rapporte, et renvoyer le flux de transport et le paquet d’événement en entrée du multiplexeur 101. Le multiplexeur 101 prend le paquet d’événement ainsi construit et l’ajoute à son multiplexe de sortie. Pour rappel, une commande SCTE 35 est classiquement envoyée N secondes en avance par rapport à l’image de référence. Le SCTE est donc passé depuis N secondes quand l’image de référence passe à son tour dans le multiplexeur.
S’il détecte un paquet d’événement dans le flux de transport (par exemple il détecte un entête de synchronisation ou un identifiant de synchronisation dans le champ SYNC), le SE monitoring 102 estime le décalage induit par la boucle d’insertion et le multiplexeur 101. Il notifie alors le SE inserteur 103 avec la valeur calculée (directement ou via une plateforme de services).
Le SE inserteur 103 peut ainsi corriger ce décalage en anticipant ou retardant l’insertion des paquets d’événement suivants.
Pour plus de robustesse, la valeur utilisée pour compenser le décalage peut être moyennée dans le temps.
En variante ou en complément, le SE inserteur 103 peut construire un paquet d’événement de mesure à partir d’un flux vidéo porté par le flux de transport, et renvoyer le flux de transport et le paquet d’événement en entrée du multiplexeur 101. Le multiplexeur 101 prend le paquet d’événement ainsi construit et l’ajoute à son multiplexe de sortie.
Par exemple, le SE inserteur 103 remplace, dans le flux de transport, des paquets de bourrage par des paquets d’événement de mesure et met à jour le champ « délai souhaité » (D 422 par exemple) avec le décalage entre un paquet de référence (contenant l’information temporelle de référence, de type PTS par exemple) et le paquet de bourrage remplacé par le paquet d’événement de mesure.
Une telle mesure peut être réalisée périodiquement afin que la tête de réseau puisse s’auto-adapter aux variations potentielles de délai lors de l’insertion des paquets d’événement.
Selon ce premier exemple, la synchronisation est donc uniquement mise en œuvre en tête de réseau.
B. Délai identique sur tout le réseau
Selon un deuxième exemple, on considère que le flux de transport qui arrive à tous les émetteurs du réseau contient le même décalage entre la position souhaitée et la position réelle du paquet d’événement, par rapport au contenu auquel il se rapporte.
Par exemple, un SE monitoring mesure cette valeur de décalage au niveau de l’équipement d’extrémité du réseau (par exemple une passerelle de diffusion) et notifie cette valeur de décalage au SE inserteur, directement ou via une plateforme de services.
La valeur obtenue par le SE inserteur est utilisée pour anticiper l’insertion des paquets d’événement suivants. Cette anticipation de l’insertion permet de compenser le retard induit par le réseau. Éventuellement, l’entête de synchronisation des paquets d’événement peut être supprimée une fois que le retard induit par le réseau a été compensé.
Si la mesure du décalage est continue, alors le SE inserteur peut adapter l’anticipation d’insertion automatiquement pour que la synchronisation soit optimale.
C. Délais différents sur les sous-réseaux
Selon un troisième exemple, on considère un réseau de diffusion comprenant une tête de réseau alimentant au moins deux sous-réseaux avec des traitements et/ou des équipements différents.
La solution proposée permet d’éviter qu’un paquet d’événement soit retardé sur un sous-réseau, et arrive trop tard au niveau de certains récepteurs pour réaliser la synchronisation.
On considère selon cet exemple que chaque sous-réseau est équipé d’un SE monitoring, surveillant par exemple l’équipement d’extrémité du sous-réseau. Les SE monitoring de chaque sous-réseau peuvent envoyer leur valeur de décalage de traitement mesurée au SE inserteur de la tête de réseau, ou à une plateforme de services. Le SE inserteur ou la plateforme de services détermine la valeur de décalage de traitement la plus longue. Cette valeur est utilisée par le SE inserteur pour insérer les paquets d’événement suivant, de façon à anticiper ce décalage.
Le SE monitoring d’un sous-réseau peut modifier les entêtes des paquets d’événement qu’il reçoit pour y inscrire l’avance d’insertion du paquet d’événement pour le sous-réseau qu’il suit. Le module logiciel du récepteur peut notamment utiliser ces valeurs pour améliorer la synchronisation.
A titre d’exemple, si trois sous-réseaux sont utilisés et induisent les retards suivants entre la position souhaitée et la position réelle d’un paquet d’événement :
  • sous-réseau 1 : 150 ms,
  • sous-réseau 2 : 50 ms,
  • sous-réseau 3 : 700 ms,
alors le SE inserteur peut insérer les paquets d’événement 700 ms avant leur position d’insertion souhaitée.
Les SE monitoring présents dans chaque sous-réseau peuvent insérer les valeurs suivantes dans le champ « délai souhaité » (D 422 ou Ins. Pos. 522 par exemple) des paquets d’événement :
  • sous-réseau 1 : 550 ms (i.e. 700 ms – 150 ms),
  • sous-réseau 2 : 650 ms (i.e 700 ms – 50 ms),
  • sous-réseau 3 : 0 ms.
Le module logiciel du récepteur attend pendant les délais d’attente définis ci-dessus avant de déclencher une action (affichage d’une pop-up par exemple) synchronisée avec le contenu auquel elle se rapporte. On note que cette partie de la synchronisation ne nécessite pas que le récepteur soit connecté.
Si le récepteur est connecté, le module logiciel peut encore améliorer la synchronisation en tenant compte du décalage de réception lié au type de récepteur. Par exemple, le module logiciel peut demander à une plateforme de services si le récepteur sur lequel il s’exécute induit un décalage supplémentaire (avance ou retard). La valeur de ce décalage de réception est alors utilisée par le module logiciel pour resynchroniser les actions.
5.4 Dispositifs correspondants
On présente finalement, en relation avec la , la structure simplifiée d’un SE inserteur, d’un SE monitoring, d’une plateforme de services ou d’un récepteur selon un mode de réalisation de l’invention.
Un SE inserteur selon un mode de réalisation de l’invention comprend une mémoire 1111I(comprenant par exemple une mémoire tampon) et une unité de traitement 1112I(équipée par exemple d’au moins un processeur, FPGA, ou DSP), pilotée ou pré-programmée par une application ou un programme d’ordinateur 1113Imettant en œuvre le procédé d’insertion d’un événement selon un mode de réalisation de l’invention.
A l’initialisation, les instructions de code du programme d’ordinateur 1113Isont par exemple chargées dans une mémoire RAM avant d’être exécutées par l’unité de traitement 1112I .L’unité de traitement 1112Imet en œuvre les étapes du procédé d’insertion d’un événement dans un flux de transport décrit précédemment, selon les instructions du programme d’ordinateur 1113I. Pour ce faire, selon un mode de réalisation, l’unité de traitement 1112Iest configurée pour :
  • obtenir le flux de transport,
  • insérer, dans le flux de transport, au moins un paquet d’événement courant associé à un contenu porté par le flux de transport, le paquet d’événement courant portant un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
  • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
le paquet d’événement courant étant inséré dans le flux de transport à une position définie à partir de la position du paquet de référence et du délai souhaité.
Un SE monitoring selon un mode de réalisation de l’invention comprend une mémoire 1111M(comprenant par exemple une mémoire tampon) et une unité de traitement 1112M(équipée par exemple d’au moins un processeur, FPGA, ou DSP), pilotée ou pré-programmée par une application ou un programme d’ordinateur 1113Mmettant en œuvre le procédé de surveillance d’un flux de transport en sortie d’un équipement d’un réseau de diffusion selon un mode de réalisation de l’invention.
A l’initialisation, les instructions de code du programme d’ordinateur 1113Msont par exemple chargées dans une mémoire RAM avant d’être exécutées par l’unité de traitement 1112M .L’unité de traitement 1112Mmet en œuvre les étapes du procédé de surveillance décrit précédemment, selon les instructions du programme d’ordinateur 1113M. Pour ce faire, selon un mode de réalisation, l’unité de traitement 1112Mest configurée pour :
  • obtenir un flux de transport délivré par l’équipement à surveiller,
  • détecter un paquet d’événement courant associé à un contenu porté par le flux de transport, le paquet d’événement portant un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
  • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
  • déterminer un décalage entre une position réelle du paquet d’événement courant dans le flux de transport, et une position souhaitée dudit paquet d’événement courant dans le flux de transport, déterminée à partir de l’information temporelle de référence et du délai souhaité (décalage de traitement).
Une plateforme de services selon un mode de réalisation de l’invention comprend une mémoire 1111P(comprenant par exemple une mémoire tampon) et une unité de traitement 1112P(équipée par exemple d’au moins un processeur, FPGA, ou DSP), pilotée ou pré-programmée par une application ou un programme d’ordinateur 1113Pmettant en œuvre le procédé de gestion d’un flux de transport selon un mode de réalisation de l’invention.
A l’initialisation, les instructions de code du programme d’ordinateur 1113Psont par exemple chargées dans une mémoire RAM avant d’être exécutées par l’unité de traitement 1112P .L’unité de traitement 1112Pmet en œuvre les étapes du procédé de gestion d’un flux de transport décrit précédemment, selon les instructions du programme d’ordinateur 1113P. Pour ce faire, selon un mode de réalisation, l’unité de traitement 1112Pest configurée pour :
  • obtenir au moins un décalage parmi :
    • au moins un décalage entre une position réelle d’un paquet d’événement courant dans le flux de transport, en sortie d’un équipement du réseau de diffusion, et une position souhaitée du paquet d’événement courant dans le flux de transport (décalage de traitement),
    • un décalage déterminé en fonction d’un type de récepteur destiné à recevoir le flux de transport (décalage de réception),
le paquet d’événement courant étant associé à un contenu porté par le flux de transport, et portant un entête de synchronisation comprenant :
  • une information temporelle de référence définie par rapport à une horloge de référence du contenu ;
  • un délai souhaité entre le paquet d’événement courant et un paquet de référence du contenu identifié à partir de l’information temporelle de référence,
la position souhaitée étant déterminée à partir de ladite information temporelle de référence et dudit délai souhaité,
  • transmettre, à au moins un autre équipement du réseau de diffusion, ledit au moins un décalage obtenu, ou un décalage global déterminé à partir dudit au moins un décalage obtenu.
Un récepteur selon un mode de réalisation de l’invention comprend une mémoire 1111R(comprenant par exemple une mémoire tampon) et une unité de traitement 1112R(équipée par exemple d’au moins un processeur, FPGA, ou DSP), pilotée ou pré-programmée par une application ou un programme d’ordinateur 1113Rmettant en œuvre le procédé de réception d’un flux de transport selon un mode de réalisation de l’invention.
A l’initialisation, les instructions de code du programme d’ordinateur 1113Rsont par exemple chargées dans une mémoire RAM avant d’être exécutées par l’unité de traitement 1112R.L’unité de traitement 1112Rmet en œuvre les étapes du procédé de réception d’un flux de transport décrit précédemment, selon les instructions du programme d’ordinateur 1113R. Pour ce faire, selon un mode de réalisation, l’unité de traitement 1112Rest configurée pour :
  • recevoir un flux de transport portant au moins un paquet d’événement courant associé à un contenu porté par le flux de transport, le paquet d’événement courant portant un entête de synchronisation comprenant :
    • une information temporelle de référence définie par rapport à une horloge de référence du contenu,
    • un délai souhaité ou réel entre le paquet d’événement courant et un paquet de référence du contenu identifié à partir de l’information temporelle de référence,
  • synchroniser un événement porté par des données utiles du paquet d’événement courant avec un point de référence associé à l’information temporelle de référence, en tenant compte d’un délai d’attente déterminé à partir de l’entête de synchronisation du paquet d’événement courant.

Claims (21)

  1. Procédé de surveillance d’un flux de transport en sortie d’un équipement d’un réseau de diffusion, caractérisé en ce que ledit procédé met en œuvre au moins une itération des étapes suivantes :
    • obtention (61) du flux de transport délivré par ledit équipement,
    • détection (62) d’un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement portant un entête de synchronisation comprenant :
      • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu,
      • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
    • détermination (63) d’un décalage entre une position réelle dudit paquet d’événement courant dans ledit flux de transport, et une position souhaitée dudit paquet d’événement courant dans ledit flux de transport, déterminée à partir de ladite information temporelle de référence et dudit délai souhaité, dit décalage de traitement.
  2. Procédé selon la revendication 1, caractérisé en ce qu’il comprend une étape de transmission dudit décalage de traitement à au moins un autre équipement dudit réseau de diffusion.
  3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu’il comprend une étape de mise à jour dudit entête de synchronisation avec ledit décalage de traitement.
  4. Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce qu’il comprend une étape de modification de la position dudit paquet d’événement courant dans ledit flux de transport tenant compte dudit décalage de traitement et une étape de transmission dudit flux de transport modifié.
  5. Procédé selon la revendication 4, caractérisé en ce qu’il comprend une étape de suppression dudit entête de synchronisation dudit paquet d’événement courant, préalable à ladite transmission du flux de transport modifié.
  6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ledit décalage de traitement est un décalage moyen obtenu à l’issue d’au moins deux itérations.
  7. Procédé d’insertion d’un événement dans un flux de transport destiné à être diffusé dans un réseau de diffusion, caractérisé en ce qu’il met en œuvre les étapes suivantes :
    • obtention (31) dudit flux de transport,
    • insertion (32) , dans ledit flux de transport, d’au moins un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement courant portant un entête de synchronisation comprenant :
      • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
      • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
    ledit paquet d’événement courant étant inséré dans ledit flux de transport à une position définie à partir de la position dudit paquet de référence et dudit délai souhaité.
  8. Procédé selon la revendication 7, caractérisé en ce qu’il met en œuvre au moins une étape d’obtention (33) d’un décalage entre une position réelle dudit paquet d’événement courant dans ledit flux de transport, en sortie d’un équipement du réseau de diffusion, et une position souhaitée dudit paquet d’événement courant dans ledit flux de transport, déterminée à partir de ladite information temporelle de référence et dudit délai souhaité, dit décalage de traitement.
  9. Procédé selon l'une quelconque des revendications 7 et 8, caractérisé en ce qu’il met en œuvre la réception (34) d’un décalage déterminé en fonction d’un type de récepteur destiné à recevoir ledit flux de transport, dit décalage de réception.
  10. Procédé selon l'une quelconque des revendications 8 et 9, caractérisé en ce qu’il met en œuvre une étape de modification de la position dudit paquet d’événement courant dans ledit flux de transport tenant compte dudit décalage de traitement selon la revendication 8 et/ou dudit décalage de réception selon la revendication 9.
  11. Procédé selon l'une quelconque des revendications 8 à 10, caractérisé en ce qu’il met en œuvre une étape d’insertion d’un paquet d’événement suivant dans ledit flux de transport tenant compte dudit décalage de traitement selon la revendication 8 et/ou dudit décalage de réception selon la revendication 9.
  12. Procédé de gestion d’un flux de transport diffusé dans un réseau de diffusion, caractérisé en ce qu’il met en œuvre les étapes suivantes :
    • obtention (71) d’au moins un décalage parmi :
      • au moins un décalage entre une position réelle d’un paquet d’événement courant dans ledit flux de transport, en sortie d’un équipement du réseau de diffusion, et une position souhaitée dudit paquet d’événement courant dans ledit flux de transport, dit décalage de traitement,
      • un décalage déterminé en fonction d’un type de récepteur destiné à recevoir ledit flux de transport, dit décalage de réception,
    ledit paquet d’événement courant étant associé à un contenu porté par ledit flux de transport, et portant un entête de synchronisation comprenant :
    • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
    • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
    ladite position souhaitée étant déterminée à partir de ladite information temporelle de référence et dudit délai souhaité,
    • transmission (72), à au moins un autre équipement dudit réseau de diffusion, dudit au moins un décalage obtenu, ou d’un décalage global déterminé à partir dudit au moins un décalage obtenu.
  13. Procédé de réception d’un flux de transport diffusé dans un réseau de diffusion, caractérisé en ce qu’il met en œuvre les étapes suivantes :
    • réception (81) d’un flux de transport portant au moins un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement courant portant un entête de synchronisation comprenant :
      • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu,
      • un délai souhaité ou réel entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
    • synchronisation (82) d’un événement porté par des données utiles dudit paquet d’événement courant avec un point de référence associé à ladite information temporelle de référence, en tenant compte d’un délai d’attente déterminé à partir dudit entête de synchronisation dudit paquet d’événement courant.
  14. Procédé selon la revendication 13, caractérisé en ce qu’il comprend une étape d’obtention d’un décalage déterminé en fonction d’un type de récepteur recevant ledit flux de transport, dit décalage de réception, et en ce que ledit délai d’attente tient également compte dudit décalage de réception.
  15. Procédé selon l'une quelconque des revendications 1 à 14, caractérisé en ce que ladite information temporelle de référence correspond à une date de restitution d’une image de référence dudit contenu et en ce que ledit paquet de référence porte ladite image de référence.
  16. Procédé selon l’une quelconque des revendications 1 à 15, caractérisé en ce que ledit flux de transport est au format MPEG-TS, et en ce que ledit paquet d’événement courant est un « Stream Event » au format DSM-CC.
  17. Dispositif de surveillance d’un flux de transport en sortie d’un équipement d’un réseau de diffusion, caractérisé en ce qu’il comprend une machine de calcul reprogrammable ou une machine de calcul dédiée, configurée pour :
    • obtenir le flux de transport délivré par ledit équipement,
    • détecter un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement portant un entête de synchronisation comprenant :
      • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
      • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
    • déterminer un décalage entre une position réelle dudit paquet d’événement courant dans ledit flux de transport, et une position souhaitée dudit paquet d’événement courant dans ledit flux de transport, déterminée à partir de ladite information temporelle de référence et dudit délai souhaité, dit décalage de traitement.
  18. Dispositif d’insertion d’un événement dans un flux de transport destiné à être diffusé dans un réseau de diffusion, caractérisé en ce qu’il comprend une machine de calcul reprogrammable ou une machine de calcul dédiée, configurée pour :
    • obtenir ledit flux de transport,
    • insérer, dans ledit flux de transport, au moins un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement courant portant un entête de synchronisation comprenant :
      • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
      • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
    ledit paquet d’événement courant étant inséré dans ledit flux de transport à une position définie à partir de la position dudit paquet de référence et dudit délai souhaité.
  19. Plateforme de gestion d’un flux de transport diffusé dans un réseau de diffusion, caractérisé en ce qu’elle comprend une machine de calcul reprogrammable ou une machine de calcul dédiée, configurée pour :
    • obtenir au moins un décalage parmi :
      • au moins un décalage entre une position réelle d’un paquet d’événement courant dans ledit flux de transport, en sortie d’un équipement du réseau de diffusion, et une position souhaitée dudit paquet d’événement courant dans ledit flux de transport, dit décalage de traitement,
      • un décalage déterminé en fonction d’un type de récepteur destiné à recevoir ledit flux de transport, dit décalage de réception,
    ledit paquet d’événement courant étant associé à un contenu porté par ledit flux de transport, et portant un entête de synchronisation comprenant :
    • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu ;
    • un délai souhaité entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
    ladite position souhaitée étant déterminée à partir de ladite information temporelle de référence et dudit délai souhaité,
    • transmettre, à au moins un autre équipement dudit réseau de diffusion, ledit au moins un décalage obtenu, ou un décalage global déterminé à partir dudit au moins un décalage obtenu.
  20. Dispositif de réception d’un flux de transport diffusé dans un réseau de diffusion, caractérisé en ce qu’il comprend une machine de calcul reprogrammable ou une machine de calcul dédiée, configurée pour :
    • recevoir un flux de transport portant au moins un paquet d’événement courant associé à un contenu porté par ledit flux de transport, ledit paquet d’événement courant portant un entête de synchronisation comprenant :
      • une information temporelle de référence définie par rapport à une horloge de référence dudit contenu,
      • un délai souhaité ou réel entre ledit paquet d’événement courant et un paquet de référence dudit contenu identifié à partir de ladite information temporelle de référence,
    • synchroniser un événement porté par des données utiles dudit paquet d’événement courant avec un point de référence associé à ladite information temporelle de référence, en tenant compte d’un délai d’attente déterminé à partir dudit entête de synchronisation dudit paquet d’événement courant.
  21. Programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l’une quelconque des revendications 1 à 16, lorsque ledit programme est exécuté sur un ordinateur.
FR2103688A 2021-04-09 2021-04-09 Procédés et dispositifs d’insertion d’un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d’ordinateur correspondants. Active FR3121809B1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR2103688A FR3121809B1 (fr) 2021-04-09 2021-04-09 Procédés et dispositifs d’insertion d’un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d’ordinateur correspondants.
PCT/EP2022/059243 WO2022214586A1 (fr) 2021-04-09 2022-04-07 Procédés et dispositifs d'insertion d'un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d'ordinateur correspondants
US18/554,478 US20240205472A1 (en) 2021-04-09 2022-04-07 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
EP22721337.8A EP4320871A1 (fr) 2021-04-09 2022-04-07 Procédés et dispositifs d'insertion d'un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d'ordinateur correspondants

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2103688A FR3121809B1 (fr) 2021-04-09 2021-04-09 Procédés et dispositifs d’insertion d’un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d’ordinateur correspondants.
FR2103688 2021-04-09

Publications (2)

Publication Number Publication Date
FR3121809A1 true FR3121809A1 (fr) 2022-10-14
FR3121809B1 FR3121809B1 (fr) 2024-01-12

Family

ID=76523070

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2103688A Active FR3121809B1 (fr) 2021-04-09 2021-04-09 Procédés et dispositifs d’insertion d’un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d’ordinateur correspondants.

Country Status (4)

Country Link
US (1) US20240205472A1 (fr)
EP (1) EP4320871A1 (fr)
FR (1) FR3121809B1 (fr)
WO (1) WO2022214586A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230025628A1 (en) * 2019-10-04 2023-01-26 Enensys Technologies Method for signalling a substitution to a terminal, method for substitution by a terminal, and corresponding computer program products, system and terminal

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2533547A1 (fr) * 2011-06-10 2012-12-12 Koninklijke KPN N.V. Procédé et système pour fournir une expérience d'utilisateur synchronisée à partir de plusieurs modules
WO2019011655A1 (fr) 2017-07-12 2019-01-17 Tdf Procédé de signalisation d'une substitution à un terminal, procédé de substitution par un terminal, produits programme d'ordinateur, système et terminal correspondants
US20190141406A1 (en) * 2017-11-03 2019-05-09 Dish Network L.L.C. Message tunneling over closed captioning

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2533547A1 (fr) * 2011-06-10 2012-12-12 Koninklijke KPN N.V. Procédé et système pour fournir une expérience d'utilisateur synchronisée à partir de plusieurs modules
WO2019011655A1 (fr) 2017-07-12 2019-01-17 Tdf Procédé de signalisation d'une substitution à un terminal, procédé de substitution par un terminal, produits programme d'ordinateur, système et terminal correspondants
US20190141406A1 (en) * 2017-11-03 2019-05-09 Dish Network L.L.C. Message tunneling over closed captioning

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"A Guide to MPEG Fundamentals and Protocol Analysis", 1 March 2007 (2007-03-01), pages 1 - 101, XP002505551, Retrieved from the Internet <URL:http://www.tek.com/products/video_test/mpeg_monitors.html> [retrieved on 20081125] *
ATSC ORGANIZATION: "A/93 - Synchronized/Asynchronous Trigger", 1 April 2002 (2002-04-01), XP017861351, Retrieved from the Internet <URL:https://www.atsc.org/wp-content/uploads/2021/04/A93-2002.pdf> [retrieved on 20210408] *
JON PIESING (TP VISION): "Interactive app signalling and carriage", no. r1, 13 January 2017 (2017-01-13), XP017852645, Retrieved from the Internet <URL:(Old): https://www.dvb.org/resources/restricted/members/documents/CM/CM1037r1_Interactive-app-signalling-and-carriage.docx> [retrieved on 20170113] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230025628A1 (en) * 2019-10-04 2023-01-26 Enensys Technologies Method for signalling a substitution to a terminal, method for substitution by a terminal, and corresponding computer program products, system and terminal
US11889129B2 (en) * 2019-10-04 2024-01-30 Enensys Technologies Method for signaling a substitution to a terminal, method for substitution by a terminal, and corresponding computer program products, system and terminal

Also Published As

Publication number Publication date
EP4320871A1 (fr) 2024-02-14
FR3121809B1 (fr) 2024-01-12
WO2022214586A1 (fr) 2022-10-13
US20240205472A1 (en) 2024-06-20

Similar Documents

Publication Publication Date Title
EP1432250B1 (fr) Procédé et dispositif de synchronisation de la présentation de Trames audio et/ou de Trames video
EP2347588B1 (fr) Horodatage d&#39; un flux de donnees dans un reseau a frequence unique
EP2520085A1 (fr) Procede de signalisation de contenus videos diffuses, procede et dispositif d&#39;enregistrement utilisant la signalisation
FR2919775A1 (fr) Procede et dispositif pour la synchronisation d&#39;un flux de donnees dans un reseau a frequence unique
WO2022214586A1 (fr) Procédés et dispositifs d&#39;insertion d&#39;un événement dans un flux de transport, de surveillance, de gestion et de réception du flux de transport, et programme d&#39;ordinateur correspondants
EP2030449B1 (fr) Procede d&#39;insertion d&#39;au moins une composante dans un flux numerique, dispositif d&#39;insertion et produit programme d&#39;ordinateur correspondants
EP3284260B1 (fr) Procédé de remplacement d&#39;un contenu principal par au moins un contenu secondaire, équipement de remplacement de contenus et programme d&#39;ordinateur correspondants
EP3652953B1 (fr) Procédé de signalisation d&#39;une substitution à un terminal, procédé de substitution par un terminal, produits programme d&#39;ordinateur, système et terminal correspondants
EP2243232A1 (fr) Procede de diffusion d &#39; un flux de donnees dans un reseau comprenant une pluralite d &#39; emetteurs ainsi que produit programme d &#39; ordinateur, tete de reseau et systeme pour la mise en oeuvre de ce procede
EP3085098A1 (fr) Procédé de génération d&#39;un marquage temporel pour une diffusion terrestre synchrone
EP2345185A1 (fr) Dispositif et procédé de synchronisation fine de différentes versions d&#39;un flux de données reçues
EP2865189B1 (fr) Procédé et dispositif d&#39;horodatage d&#39;un flux de données, procédé et dispositif d&#39;insertion, produits programme d&#39;ordinateur et médium de stockage correspondants
EP3643072A1 (fr) Procédé et équipement de génération d&#39;un flux de transport, procédé et site de diffusion, et programme d&#39;ordinateur correspondants.
KR101233329B1 (ko) 디지털 방송 서비스를 위한 다중화기의 레이트 적응 장치
EP2345250B1 (fr) Modification du debit d&#39;un flux de donnees diffuse dans un reseau monofrequence
FR2930098A1 (fr) Procede de transmission simplifie d&#39;un flux de signaux entre un emetteur et un appareil electronique
EP3673662A1 (fr) Procédé de téléchargement de chaîne pour le zapping d&#39;une chaîne numérique en fonction du comportement utilisateur
WO2016016403A1 (fr) Procédé de diffusion d&#39;un service d&#39;alerte
OA17812A (fr) Procédé de génération d&#39;un marquage temporel pour une diffusion terrestre synchrone.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20221014

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4