BE1024519B1 - Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué - Google Patents
Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué Download PDFInfo
- Publication number
- BE1024519B1 BE1024519B1 BE2016/5252A BE201605252A BE1024519B1 BE 1024519 B1 BE1024519 B1 BE 1024519B1 BE 2016/5252 A BE2016/5252 A BE 2016/5252A BE 201605252 A BE201605252 A BE 201605252A BE 1024519 B1 BE1024519 B1 BE 1024519B1
- Authority
- BE
- Belgium
- Prior art keywords
- video production
- video
- production server
- server
- elementary
- Prior art date
Links
- 238000004519 manufacturing process Methods 0.000 title claims abstract description 193
- 238000000034 method Methods 0.000 title claims abstract description 18
- 238000012545 processing Methods 0.000 claims abstract description 46
- 238000003860 storage Methods 0.000 claims abstract description 20
- 230000005236 sound signal Effects 0.000 claims abstract description 17
- 230000003936 working memory Effects 0.000 claims abstract description 5
- 230000037406 food intake Effects 0.000 claims description 25
- 238000013507 mapping Methods 0.000 claims description 13
- 238000004891 communication Methods 0.000 claims description 11
- 230000001360 synchronised effect Effects 0.000 claims description 8
- 238000011017 operating method Methods 0.000 claims description 6
- 238000004422 calculation algorithm Methods 0.000 claims description 4
- 230000008569 process Effects 0.000 claims description 4
- 230000006870 function Effects 0.000 description 10
- 230000007246 mechanism Effects 0.000 description 9
- 238000013459 approach Methods 0.000 description 6
- 238000011161 development Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 239000000463 material Substances 0.000 description 4
- 230000015654 memory Effects 0.000 description 4
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 241000238876 Acari Species 0.000 description 3
- 108700009949 PTP protocol Proteins 0.000 description 3
- 238000004364 calculation method Methods 0.000 description 3
- 238000011084 recovery Methods 0.000 description 3
- 230000002123 temporal effect Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 238000004513 sizing Methods 0.000 description 2
- 244000025254 Cannabis sativa Species 0.000 description 1
- 240000007313 Tilia cordata Species 0.000 description 1
- 230000001133 acceleration Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000003139 buffering effect Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 238000005520 cutting process Methods 0.000 description 1
- 238000009795 derivation Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011143 downstream manufacturing Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 239000011159 matrix material Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 230000000630 rising effect Effects 0.000 description 1
- 230000009897 systematic effect Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
-
- 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/226—Characteristics of the server or Internal components of the server
-
- 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/241—Operating system [OS] processes, e.g. server setup
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
Un serveur de production vidéo comprenant au moins un processeur et un magasin de stockage est suggéré. Des modules logiciels composés d’un code de programme exécutable sont chargés dans une mémoire de travail dudit au moins un processeur. Chaque module logiciel, lorsqu’il est exécuté par ledit au moins un processeur, fournit un service élémentaire. Une concaténation de services élémentaires fournit une fonctionnalité impliquant le traitement de signaux vidéo et/ou audio requis en vue de produire un programme de diffusion. Le serveur de production vidéo inclut un ensemble de composants logiciels qui s’exécute sur du matériel conventionnel. Chaque fonctionnalité du serveur de production vidéo est réalisée en utilisant un logiciel unitaire spécifique qui est assemblé à partir de blocs logiciels fonctionnels réutilisables et qui peut s’exécuter sur toute plateforme matérielle compatible. Par ailleurs, un procédé d’exploitation du serveur de production vidéo et d’un système de production vidéo distribué incluant le serveur de production vidéo est suggéré.
Description
(73) Titulaire(s) :
EVS BROADCAST EQUIPMENT SA
4102, SERAING
Belgique (72) Inventeur(s) :
BARN ICH Olivier 4000 LIEGE Belgique
BASTINGS Michael 4420 SAINT NICOLAS Belgique
VOUNCKX Johan 3210 LINDEN Belgique (54) Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué
208 (57) Un serveur de production vidéo comprenant au moins un processeur et un magasin de stockage est suggéré. Des modules logiciels composés d’un code de programme exécutable sont chargés dans une mémoire de travail dudit au moins un processeur. Chaque module logiciel, lorsqu’il est exécuté par ledit au moins un processeur, fournit un service élémentaire. Une concaténation de services élémentaires fournit une fonctionnalité impliquant le traitement de signaux vidéo et/ou audio requis en vue de produire un programme de diffusion. Le serveur de production vidéo inclut un ensemble de composants logiciels qui s’exécute sur du matériel conventionnel. Chaque fonctionnalité du serveur de production vidéo est réalisée en utilisant un logiciel unitaire spécifique qui est assemblé à partir de blocs logiciels fonctionnels réutilisables et qui peut s’exécuter sur toute plateforme matérielle compatible. Par ailleurs, un procédé d’exploitation du serveur de production vidéo et d’un système de production vidéo distribué incluant le serveur de production vidéo est suggéré.
206205—
204— 203—L
Applications d'utilisateur
Applications d'utilisateur
| Service | Servicerte | service | | Service de | Service n | ||
| d ingestion | stccksge | de codeur j | décodeur | XX |
Fig.2
201 □□□□ ni
207
BREVET D'INVENTION BELGE
SPF Economie, PME, Classes Moyennes & Energie
Numéro de publication : 1024519 Numéro de dépôt : BE2016/5252
Office de la Propriété intellectuelle Classification Internationale : H04N 21/854 H04N 5/265 H04N 21/226 H04N 21/2343 H04N 21/241 Date de délivrance : 28/03/2018
Le Ministre de l'Economie,
Vu la Convention de Paris du 20 mars 1883 pour la Protection de la propriété industrielle ;
Vu la loi du 28 mars 1984 sur les brevets d'invention, l'article 22, pour les demandes de brevet introduites avant le 22 septembre 2014 ;
Vu le Titre 1er “Brevets d’invention” du Livre XI du Code de droit économique, l'article XI.24, pour les demandes de brevet introduites à partir du 22 septembre 2014 ;
Vu l'arrêté royal du 2 décembre 1986 relatif à la demande, à la délivrance et au maintien en vigueur des brevets d'invention, l'article 28 ;
Vu la demande de brevet d'invention reçue par l'Office de la Propriété intellectuelle en date du 12/04/2016.
Considérant que pour les demandes de brevet tombant dans le champ d'application du Titre 1er, du Livre XI du Code de Droit économique (ci-après CDE), conformément à l'article XI. 19, §4, alinéa 2, du CDE, si la demande de brevet a fait l'objet d'un rapport de recherche mentionnant un défaut d'unité d'invention au sens du §ler de l'article XI.19 précité et dans le cas où le demandeur n'effectue ni une limitation de sa demande ni un dépôt d'une demande divisionnaire conformément aux résultats du rapport de recherche, le brevet délivré sera limité aux revendications pour lesquelles le rapport de recherche a été établi.
Arrête :
Article premier. - Il est délivré à
EVS BROADCAST EQUIPMENT SA, Rue Bois Saint-Jean 13, 4102 SERAING Belgique;
représenté par
SPEICH Stéphane, Rue des Bruyères 55, 1274, HOWALD;
un brevet d'invention belge d'une durée de 20 ans, sous réserve du paiement des taxes annuelles visées à l’article XI.48, §1 du Code de droit économique, pour : Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué.
INVENTEUR(S) :
BARNICH Olivier, Boulevard d'Avroy 200, 4000, LIEGE;
BASTINGS Michael, Rue de Tilleur 275, 4420, SAINT NICOLAS;
VOUNCKX Johan, Tempelstraat 30, 3210, LINDEN;
PRIORITE(S) :
DIVISION :
divisé de la demande de base : date de dépôt de la demande de base :
Article 2. - Ce brevet est délivré sans examen préalable de la brevetabilité de l'invention, sans garantie du mérite de l'invention ou de l'exactitude de la description de celle-ci et aux risques et périls du (des) demandeur(s).
Bruxelles, le 28/03/2018, Par délégation spéciale :
DESCRIPTION D
Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué
Domaine technique
La présente divulgation concerne un serveur de production vidéo à base de logiciel, un procédé de fonctionnement du serveur de production vidéo et un système de production vidéo distribué. Le serveur de production vidéo prend en charge différents types de fonctionnalités qui sont nécessaires dans le cadre d’une production de diffusion.
Contexte
Pour une production TV en direct dans un environnement de production vidéo d’aujourd'hui, un équipement spécialisé très coûteux est utilisé dans le cadre de l’acquisition, du traitement et de la lecture de sources ou flux vidéo et/ou audio provenant de dispositifs d’acquisition, par exemple de caméras et de microphones. Parfois, les sources vidéo et/ou audio sont combinées avec des métadonnées associées, par exemple des métadonnées audio/vidéo ou des métadonnées associées à l’événement capturé, par exemple la vitesse d’athlètes, ou des données situationnelles fournies par des experts, par exemple des commentaires sur des faits de jeux tels que des buts, des fautes, etc. Tous les signaux entrants ou les données entrantes doivent être traité(e)s en vue de produire un ou plusieurs signaux de sortie de programme final. Une unité de traitement qui fait partie de l’équipement de production met en œuvre le traitement des signaux. Le traitement incluant :
l’ingestion de signaux provenant de dispositifs d’acquisition dans le matériel de traitement ;
le codage de signaux bruts provenant des dispositifs d’acquisition en des signaux à débit binaire faible ;
la dérivation de copies de résolution inférieure du signal d’origine, par exemple à des fins de surveillance ou autres ;
le décodage des signaux à débit binaire faible en le signal brut d’origine ; le transcodage de signaux ;
l’enregistrement, d’un signal en vue d’une utilisation ultérieure ; l’application d’effets vidéo aux signaux ;
le mélange de différents signaux en un seul signal ; la lecture de signaux ;
BE2016/5252 l’affichage des signaux.
Une grande partie du traitement nécessaire est mise en œuvre par des mélangeurs vidéo 5 et des serveurs de production. Des mélangeurs vidéo sont disponibles, par exemple, auprès de sociétés comme EVS, Grass Valley, Sony, SAM et Ross. Dans une production de diffusion typique, les mélangeurs vidéo et les serveurs de production sont connectés à d'autres dispositifs tels que des caméras, des magasins de stockage vidéo, des générateurs d'effets vidéo et d’autres dispositifs. Tous ces dispositifs sont disponibles dans le commerce. Aujourd'hui, tous ces dispositifs sont fabriqués à partir de composants matériels spécialisés. De toute évidence, les signaux audio qui accompagnent les signaux vidéo doivent également être traités au cours d’une production de diffusion.
Des appareils dédiés fonctionnent sur ces dispositifs matériels spécialisés en vue de mettre en œuvre les fonctions spécifiques mentionnées ci-dessus. La probabilité d’utiliser tous les dispositifs dédiés et leur puissance maximale en même temps est très faible. Cela se traduit par un provisïonnement excessif de la puissance de traitement. Parallèlement, cela occasionne également un grand manque de flexibilité de l'infrastructure de traitement dans un studio de diffusion classique, étant donné que différents types de productions, par exemple les sports en direct versus les actualités en direct, ne peuvent être réalisés sur la même infrastructure à moins que tous les dispositifs nécessaires aux deux types de productions ne soient disponibles.
Une autre raison contribue également à l’inefficacité des studios de diffusion conventionnels. Dans un environnement de diffusion conventionnel, la majeure partie de la communication entre les dispositifs d'équipements de diffusion est réalisée grâce à une transmission en bande de base de signaux vidéo/audio utilisant le format SDI propriétaire. Les dispositifs fonctionnent de manière synchrone, selon un signal de temporisation partagé (appelé « Genlock » ou « salve de noir », ou encore « signal de référence ») lequel est acheminé conjointement avec les signaux SDI. Ce signal de temporisation est typiquement un signal quadratique dont les fronts montants correspondent à l’arrivée de nouvelles trames vidéo dans le système. En conséquence, des trames vidéo / audio doivent être traitées en interne au cours d’un intervalle de temps fixe, ce qui entraîne un dimensionnement « basé sur le cas le plus défavorable » de l’infrastructure, étant donné que toutes les étapes de traitement doivent être finalisées avant l’arrivée de la trame successive. Les systèmes matériels typiques nécessitent un niveau de synchronisation encore plus fin, jusqu'à un niveau de ligne, voire un niveau de sous-ligne.
Le brevet US 2009/0187826 Al décrit un système d’affichage et de commande de données qui commande tous les dispositifs de production dans un système de production vidéo. Les dispositifs de production sont conventionnels, mais le système de commande consolide les fonctionnalités des dispositifs de production connectés. Le système de commande simplifie le fonctionnement du système de production vidéo.
Un concept plus récent pour les productions de diffusion est la production vidéo distribuée. Ce concept tente de surmonter au moins certaines des limitations imposées par les équipements de diffusion conventionnels. Le concept de production vidéo distribuée est décrit, par exemple, dans l’article de Boutaba et ass. : « Distributed Video Production: Tasks, Architecture and QoS Provisioning » (production vidéo distribuée : tâches, architecture et provisionnement de qualité QoS), publié dans l’ouvrage « Multimedia Tools et Applications » (outils et applications multimédias), Kluwer Academie Publishers, Boston, États-Unis, Volume 16, numéro 1-2,1er janvier 2002, pages 99 à 136. Boutaba et ass. abordent le problème du retard, ou délai, des fluctuations de retard et des exigences en termes de dissymétrie, ou obliquité, entre supports. Boutaba et al. déclarent explicitement que les performances de retard sont mesurées sur la base de la fluctuation de retard ou « gigue ». La gigue correspond à une mesure de la différence en termes de retard rencontrée par différents paquets dans un réseau, sous l’effet d’une variation en termes d'occupation de mémoire tampon dans les nœuds de commutation intermédiaires. Une autre forme de gigue concerne la gigue inter-flux ou « dissymétrie », également appelée « obliquité », qui mesure la différence en termes de retard telle que perçue par des flux distincts appartenant à la même application (par exemple audio et vidéo). Afin de garantir une synchronisation intra-flux appropriée, une faible fluctuation de retard est souvent requise. Boutaba et ass. suggèrent de compenser la gigue en mettant en mémoire tampon les flux de données. Cela nécessite la fourniture d’une quantité de mémoire suffisante, en mesure de stocker des intervalles suffisamment longs de données vidéo et audio, afin de compenser la gigue. Dans le cas de données vidéo haute définition, cela nécessite une grande capacité de stockage.
Boutaba et ass. s’appuient sur différents types de serveurs pour réaliser différentes fonctionnalités nécessaires à une production de diffusion. Pour chaque fonctionnalité, un type de serveur spécifique est utilisé. Chaque serveur spécifique est soit construit exclusivement avec du matériel propriétaire, soit avec du matériel standard et des cartes d'accélération
BE2016/5252 in prenant cela comme vidéo à base de loei de départ, la présente divulgation suggère un serveur de offrant une flexibilité accrue dans le cadre de productions
Résumé
Selon un premier aspect, la présente divulgation suggère un serveur de production vidéo comportant au moins un processeur et un magasin de stockage. Des modules logiciels composés d’un code de programme exécutable sont chargés dans une mémoire de travail dudit au moins un processeur. Chaque module logiciel, lorsqu’il est exécuté par ledit au moins un processeur, fournit un service élémentaire. Une concaténation de services élémentaires fournit une fonctionnalité impliquant un traitement de signaux vidéo et/ou audio requis en vue de produire un programme de diffusion.
Selon un mode de réalisation du serveur de production vidéo, les modules logiciels sont mis en correspondance sur le matériel du serveur de production vidéo.
Dans un mode de réalisation avantageux, le serveur de production vidéo est configuré en qualité d’un serveur d’ingestion ingérant des signaux, notamment des signaux vidéo et/ou audio, sous la forme de flux de trames de données en provenance de dispositifs d’acquisition en synchronicité avec la sortie de dispositifs d’acquisition.
Selon un mode de réalisation, le serveur d’ingestion est apte à ingérer simultanément de multiples flux de signaux de différents formats.
Si le serveur de production vidéo est configure en qualité de serveur d’ingestion, il est données entrante.
Dans un autre mode de réalisation, le serveur de production vidéo est configuré en qualité de serveur de lecture délivrant en sortie des signaux vidéo et/ou audio sous la forme de trames de données en synchronicité avec des dispositifs en aval recevant les signaux de sortie du serveur de production vidéo. Les dispositifs d’acquisition et les dispositifs en aval n’ont pas besoin de présenter la même synchronicité.
Avantageusement, ledit au moins un processeur du serveur de production vidéo met en œuvre un traitement interne asynchrone des signaux vidéo et/ou audio.
Dans un mode de réalisation avantageux, ledit au moins un processeur est configuré de manière à traiter les trames de données selon la séquence de leurs estampilles temporelles affectées par les modules d’ingestion.
Avantageusement, chaque module logiciel du serveur de production vidéo présente des interfaces de données définies (API) décrivant un format de données unitaire pour les données vidéo, les données audio, les métadonnées et/ou les données de commande, au niveau de l’entrée et de la sortie des modules logiciels, permettant une séquence « définie par l’utilisateur » de sendees élémentaires. Dans ce cas, la séquence « définie par l’utilisateur » de services élémentaires forme au moins un pipeline de traitement pour les signaux vidéo et/ou audio et/ou les métadonnées.
Dans un mode de réalisation avantageux, un sendee élémentaire peut être supprimé dudit au moins un pipeline de traitement, ou remplacé on inséré dans ledit au moins un pipeline de traitement, sans affecter le fonctionnement du reste du pipeline de traitement.
Dans un mode de réalisation, le serveur de production vidéo exécute un algorithme qui détecte des défaillances matérielles et remet automatiquement en correspondance les modules logiciels de sorte que les modules logiciels ne sont plus mis en correspondance sur le matériel défaillant.
Dans un mode de réalisation supplémentaire, le serveur de production vidéo inclut un magasin de stockage permettant un accès direct à tout grain, après que le grain a été stocké, dans lequel le terme « grain » est un terme général désignant le plus petit élément traité dans le serveur de production vidéo. Par exemple, un grain est une trame vidéo ou une trame audio.
Dans encore un autre mode de réalisation, le serveur de production vidéo comporte de multiples nœuds de serveurs connectés en communication par un réseau. Selon un développement de ce mode de réalisation, les modules logiciels sont dynamiquement mis en correspondance sur ies multiples nœuds de serveurs en vue d’une amélioration des performances dudit au moins un pipeline de traitement composé de services élémentaires fournis par les modules logiciels.
Selon un deuxième aspect, la présente divulgation suggère un système de production vidéo distribué comportant au moins deux dispositifs de production de diffusion, lesquels sont interconnectés par un réseau et sont mutuellement synchronisés. Au moins l’un des dispositifs de production de diffusion est un serveur de production vidéo selon la présente divulgation.
Selon un troisième aspect, la présente divulgation suggère un procédé d’exploitation de ce serveur de production vidéo, dans lequel le procédé comporte les étapes ci-dessous
BE2016/5252 consistant a :
définir une séquence de services élémentaires appliquée à des trames de données de flux de signaux reçus tels que des flux vidéo et audio ;
traiter des trames de données selon la séquence de services élémentaires définie d’une manière asynchrone, et simultanément maintenir la relation temporelle de trames de données horodatées de flux audio et/ou vidéo associés.
Dans un mode de réalisation supplémentaire, le procédé comporte en outre l’étape ci-dessous consistant à :
modifier dynamiquement la séquence de services élémentaires, d’une trame de données à la trame de données successive, d’un flux de signaux reçu, en supprimant un service élémentaire de la séquence de services élémentaires, ou en remplaçant un service élémentaire dans la séquence de services élémentaires, ou en insérant un service élémentaire dans la séquence de services élémentaires.
Dans un autre mode de réalisation, le procédé comporte en outre l’étape ci-dessous consistant à :
mettre en correspondance dynamiquement les modules logiciels sur la plateforme matérielle composée de multiples nœuds de serveurs en vue d’une amélioration des performances de la séquence de services élémentaires.
Selon un développement de ce mode de réalisation, la mise en correspondance dynamique varie d’une trame de données à la trame de données successive d’un flux de signaux reçu.
Selon un dernier aspect, la présente divulgation suggère un logiciel contenant un code de programme, qui, lorsqu’il est exécuté par un processeur, met en œuvre un procédé selon le troisième aspect de la présente divulgation.
Brève description des dessins
Dans les dessins, des modes de réalisation exemplaires de la présente divulgation sont illustrés. Les éléments identiques ou similaires dans les figures sont indiqués par des numéros de référence identiques ou similaires. Dans lesquelles figures :
La figure 1 illustre une structure schématique d’un système de
Ί
BE2016/5252 production de diffusion distribué ;
La figure 2 illustre l’architecture d’un serveur de production vidéo selon
La figure 3 illustre une visualisation de la relation conceptuelle entre des sources, des services élémentaires et des fonctionnalités ;
La figure 4 illustre la mise en correspondance de services élémentaires sur une plateforme matérielle ;
La figure 5A illustre un. premier pipeline de services élémentaires pour une production en direct ;
Les figures 5B et 5C représentent une illustration schématique de services élémentaires et d’interfaces API correspondantes ;
La figure 5D illustre un second pipeline de sendees élémentaires pour une production en direct ;
La figure 6 illustre un mécanisme de reconfiguration de pipeline ;
La figure 7 représente une illustration des principes de synchronisation du serveur de production vidéo ;
Les figures 8A et 8C représentent des illustrations d’une application à sécurité intégrée, autrement dit à tolérance de pannes, sur le serveur· de production vidéo ;
Les figures 9A et 9B illustrent des pipelines de services élémentaires qui sont tolérants aux pannes ;
La figure 10 illustre un organigramme du procédé de fonctionnement du serveur de production vidéo ;
La figure 11 illustre un serveur de production vidéo composé de nœuds de serveurs interconnectés : et
Les figures 12A et 12B illustrent une mise en correspondance de pipelines sur le serveur de production vidéo de la figure 11.
; modes de réalisation
Tonte référence, dans les présentes, à « un unique mode de réalisation » ou à « un mode de réalisation » signifie qu’une fonction, une structure ou une caractéristique spécifique décrite dans le cadre du mode de réalisation peut être incluse dans au moins une mise eu œuvre de la présente solution. Les occurrences de l’expression « dans un mode de réalisation » dans différents passages de la présente spécification ne font pas nécessairement toutes référence au même mode de réalisation, et ne constituent pas nécessairement des modes de réalisation distincts ou alternatifs, mutuellement exclusifs d’autres modes de réalisation.
Tandis que la présente solution peut-être être sujette à diverses modifications et prendre des formes alternatives, des modes de réalisation spécifiques ont été illustrés à titre d’exemple dans les dessins d’accompagnent et seront décrits en détail ci-après. Cependant, il doit être entendu que la présente solution n’est pas destinée à être limitée aux formes spécifiques divulguées.
Un ou plusieurs modes de réalisation spécifiques de la présente solution seront décrits ci-dessous. Dans le but de fournir une description concise de ces modes de réalisation, toutes les fonctions d’une mise en œuvre en cours ne seront pas nécessairement décrites dans la spécification. 11 doit être apprécié que, dans le développement d’une telle mise en œuvre en cours quelconque, par exemple dans un quelconque projet de conception ou d’ingénierie, de nombreuses décisions spécifiques à ia mise en œuvre doivent être prises pour atteindre les objectifs précis des développeurs, par exemple la conformité avec les contraintes liées au système et à l’activité commerciale, qui peuvent varier d’une mise en œuvre à l’autre. Par ailleurs, il doit être apprécié qu’un tel effort de développement, bien que potentiellement complexe et chronophage, représenterait néanmoins une activité systématique de conception et de fabrication pour l’homme du métier bénéficiant de cette divulgation.
Certains aspects comparables, en termes de champ d’application, aux modes de réalisation divulgués, sont décrits ci-dessous. Il convient de comprendre que ces aspects sont présentés simplement en vue de fournir au lecteur un bref résumé de certaines formes que pourrait prendre la solution et que ces aspects ne sont pas destinés à limiter son champ d’application. En effet, la présente solution peut englober une variété d’aspects qui peuvent ne pas être définis ci-dessous.
La figure 1 représente une illustration schématique de l’architecture d’un système de production vidéo distribué (DVP). Les réalisateurs et les monteurs travaillent dans un studio local 101, où Ils créent un modèle provisoire d’un programme de diffusion. Certains studios sont équipés de tous les dispositifs de diffusion de haute qualité requis qui sont nécessaires en vue de produire des programmes de diffusion, y compris des programmes complexes. E§E2°16/5252 revanche, le studio local 101 dans la figure 1 est connecté, par le biais d’un réseau de diffusion haut débit 102, à deux serveurs de production vidéo uniquement, à savoir un serveur vidéo 103 et un serveur de production 104. Les étiquettes « serveur vidéo » et « serveur de production » renvoient aux tâches dans l’agencement illustré dans la figure L Dans ce qui suit, le terme « serveur de production vidéo » est utilisé en tant que terme générique pour des serveurs exécutant différentes tâches dans un système de production vidéo. Le serveur vidéo 103 stocke une base de données de séquences vidéo, sous la forme de flux vidéo qui sont à disposition du réalisateur. Le serveur de production 104 active différentes fonctionnalités, telles que le découpage, l’effacement, l’atténuation, l’incrustation, etc., permettant de composer le flux de sortie de programme selon le concept créatif du réalisateur. Le studio local 101 est également équipé de caméras et de microphones (non illustrés dans la figure 1) qui produisent des données vidéo et audio, par exemple en provenance d’un modérateur effectuant une interview avec un invité du studio. Dans le cas d’un programme préalablement produit, ces flux sont envoyés du studio local 101 au serveur vidéo 103, Cela est symbolisé, dans la figure 1, par les flèches 105 et 106. Dans le cas d’un programme en direct, le flux vidéo produit dans 1e studio local 1 ö 1 est envoyé directement au serveur de production 104 (flèches 105, 107), en vue de l’inclure dans un flux de programme édité 108 délivré en sortie par le serveur de production 104. Le flux de programme 108 est transféré par Γintermédiaire du réseau 102 vers le studio local 101 afin d’être surveillé par le réalisateur et d’être diffusé. Le flux de programme édité 108 inclut généralement également des flux vidéo stockés sur le serveur vidéo 103, lequel envoie ces flux (flèche 109) par l’intermédiaire du réseau 102 au serveur de production 104. Le réalisateur régule le fonctionnement du serveur vidéo 103 et du serveur de production 104 en envoyant des signaux d’instruction 110 à partir du studio local 101.
Dans le système exemplaire illustré dans la figure 1, seuls deux serveurs 103, 104 sont présents. Mais d’autres systèmes peuvent comporter un seul ou plus de deux serveurs, selon le type de fonctionnalités requises par le réalisateur en vue de réaliser le programme. Dans le système de production DVP selon la présente divulgation, des serveurs de production vidéo peuvent être intégrés selon les besoins. Cela confère au système de production DVP davantage de flexibilité relativement à celle des studios de diffusion classiques qui doivent être dimensionnés pour une production plus étendue et plus compliquée. Certes, de nombreux d’équipements dans un tel studio de diffusion classique sont en veille lorsque seuls des programmes simples sont prodiuts.
La présente divulgation fait principalement référence à un studio de diffusion? Toutefois, la présente divulgation est également applicable à des studios TV, des véhicules de production TV ou à tout autre environnement de production TV en direct.
La figure 2 illustre l’architecture du serveur de production vidéo selon la présente divulgation. Le serveur dans son ensemble est référencé par le numéro de référence 201. Tel qu’illustré dans la figure 2,l’architecture est organisée en couches. La couche la plus basse, dans la figure 2, est une couche matérielle 202. Par souci d’illustration, quelques composants matériels sont illustrés, par exemple une unité centrale de traitement (CPU), un enregistreur de disque numérique (DDR), une carte d’interface réseau (NIC), une unité de traitement graphique (GPU) et des cartes d’entrée/soriie (I/O), Tel qu’indiqué par les suites de points sur la couche matérielle 202, il peut y avoir d’autres composants matériels, en plus ou moins grande quantité, dans les autres modes de réalisation. Tous les composants matériels partagent la même horloge.
Un bus 203, par exemple un bus d’interface PCI ou QPÏ, connecte les composants matériels entre eux. Un système d’exploitation 204 commande le fonctionnement du matériel. Le système d’exploitation peut être un système basé sur Linux. Le serveur de production vidéo 201 décrit jusqu’ici héberge, sur une couche de service 205, des modules logiciels comprenant un code de programme qui est exécutable par Γ unité CPU du serveur 201. Chaque module logiciel est conçu de manière à fournir un dit service élémentaire particulier. Les services élémentaires sont construits à partir de fils d’exécution. Les fils d’exécution correspondent aux plus petites unités qui sont admissibles à une mise en correspondance sur le matériel. Par exemple, le service élémentaire dans le cadre de l’ingestion d’un flux de format « ST2022-5/6/7 » inclut trois fils d’exécution, à savoir : i) un fil pour recevoir les paquets de protocole UDP « ST2022-5/6/7 », ii) un fil pour décoder le flux de paquets « ST2022-5/6/7 » en des images, et iii) un fil pour copier les images dans une mémoire de travail. Le flux de données codé selon le format « ST2022-5/6/7 » ne constitue qu’un exemple. Le concept décrit s’applique également à d’autres normes, par exemple aux nonnes « AES67 » et « RFC41.75 ».
Une image unique est également appelée « grain », où « grain » est un terme général désignant le plus petit élément traité dans le serveur de production vidéo 201. Un grain peut également représenter une trame vidéo ou une trame audio.
Dans la description des modes de réalisation, il est la plupart du temps fait référence au traitement signaux vidéo. Toutefois, il doit être entendu que, dans le cadre de la présente demande de brevet, le traitement du signal vidéo implique également un traitement2016/5252 correspondant d’un signal audio d’accompagnement et de métadonnées associées, le cas échéant. Afin de rendre plus intelligible la description de la présente solution, les signaux audio et les métadonnées ne sont pas toujours mentionnés conjointement avec les signaux vidéo.
La figure 2 illustre quatre types distincts de sendees élémentaires sur la couche de service 205, à savoir un service d’ingestion, un service de stockage, un sendee de codeur' et un service de décodeur. Par ailleurs, la figure 2 indique graphiquement que le serveur de production vidéo 201 peut également héberger des services supplémentaires. Sur une couche d’application 206, plusieurs services élémentaires sont combinés en vue d’obtenir une fonctionnalité nécessaire en vue d’une production de diffusion.
Une application exemplaire du serveur de production vidéo 201 doit être illustrée en référence à nouveau à la figure 1. Dans le studio local 101, une interview, autrement dit un entretien, est enregistrée. Un serveur de production vidéo (non illustré dans la figure 1) ingère les flux audio et vidéo non compressés en provenance des caméras et des microphones dans le studio, il les code, et il lit les données par l’intermédiaire du réseau 102 sur le serveur vidéo 103, où les données d’interview peuvent être rappelées en vue d’une diffusion d’actualités plus tard dans la journée. Par conséquent, le serveur de production vidéo dans le studio local utilise l’ingestion, le codage et la lecture de services élémentaires.
L’architecture du serveur de production vidéo 201 fait une abstraction complète du matériel sous-jacent. Dans différents modes de réalisation du serveur de production vidéo, le matériel peut correspondre à une machine unique ou à plusieurs machines, ainsi qu’à un environnement distribué et en réseau. De même, Γ architecture logicielle du serveur de production vidéo 201 présente une composition modulaire. Les services élémentaires du serveur de production vidéo 201 peuvent être recombinés en vue de créer de nouvelles instances et de nouvelles entités fonctionnelles. Par exemple, les instances peuvent être des résultats intermédiaires dans le cadre d’une production complexe, par exemple un flux édité qui doit être inséré dans un autre flux pour le programme de diffusion final. Dans un autre mode de réalisation, un premier service élémentaire ingère des signaux bruts non compressés en provenance de dispositifs d’acquisition, par exemple des caméras et des microphones, lesquels sont destinés à être codés en un signal à débit binaire faible par le sendee élémentaire successif.
Ce signal est stocké dans un magasin de stockage de données par le sendee élémentaire successif à des fins d’utilisation ultérieure. Les sendees élémentaires suivants lisent les données et décodent le signal en le signal brut d’origine avant qu’il ne soit finalement transcodé par le dernier service élémentaire.
Bien que l’architecture du serveur de production vidéo 201 ne soit pas limitée à un type spécifique de matériel, il va sans dire que, quel que soit le type de matériel choisi, celui-ci doit disposer de performances suffisantes pour exécuter le traitement nécessaire à la réalisation des services élémentaires et fonctionnalités.
D’après la description de la figure 2, il devient évident que le serveur de production vidéo permet de distinguer cinq fonctions de base dans la production de diffusion, à savoir, les fonctions d’acquisition, de stockage, de calcul, de lecture et de commande. L’acquisition de signaux vidéo et/ou audio est mise en œuvre par des dispositifs d’acquisition en dehors et séparément du serveur de production vidéo. La fonction de base, à savoir la fonction de « commande », fait référence à l’opération du serveur de production vidéo au moyen du panneau de commande ou de l’application de commande. Seul le calcul est exécuté à l’intérieur du serveur de production vidéo, ou à l’intérieur d’une grappe de plusieurs serveurs de production vidéo partageant les tâches de calcul. Au niveau matériel, ces fonctions de base sont séparées, tandis que les composants matériels communiquent par le biais de connexions de réseau, par exemple d’un réseau IP.
Un second serveur 207 est indiqué dans la figure 2. La communication entre le serveur 201 et le serveur 207 est établie au niveau des couches de services 205 correspondantes des serveurs 201 et 207, respectivement, par une connexion de réseau 208. La connexion de réseau 208 peut être une connexion de réseau local ainsi qu’une connexion de réseau étendu, eu fonction de l’architecture du système de production DVP dans son ensemble.
Il convient de remarquer que l’entrée et la sortie du serveur de production vidéo 201 sont synchronisées avec les autres composants matériels au sein d’un système de production DVP spécifique. Les modules matériels du serveur de production vidéo sont synchronisés avec d’autres dispositifs dans le système de production vidéo numérique, par exemple, au moyen du protocole PTP, en vue de garantir la synchronisation des modules matériels sur le réseau IP. Toutefois, l’exécution des services élémentaires au sein du serveur de production vidéo 201 est mise en œuvre de manière asynchrone.
Le serveur de production vidéo correspond à un ensemble de composants logiciels s’exécutant sur du matériel de produits commerciaux (COTS). Chacune de ses fonctionnalités est réalisée en utilisant un logiciel unitaire spécifique qui est assemblé à partir de blocs logiciels fonctionnels réutilisables et qui peut fonctionner sur une quelconque plateforme matérielle compatible. De nouvelles fonctionnalités peuvent être fournies rapidement en composant delE2°16/5252 blocs logiciels fonctionnels existants.
Le fait de s’appuyer exclusivement sur un ou des logiciels apporte une flexibilité sans précédent :
Les composants matériels font l’objet d’une abstractioit totale et deviennent un produit de base pouvant être réutilisé et reconfiguré selon les besoins fonctionnels ponctuels.
La plateforme matérielle devient dynamiquement évolutive étant donné que le ou les logiciels peuvent être déployés sur une quelconque machine spécifique, ce qui permet d’éviter tout provisionnement excessif en matériel.
Le dimensionnement peut être serré, étant donné que toute la puissance de traitement disponible peut être utilisée à tout moment.
La plateforme matérielle peut être virtualisée et être mise en œuvre dans un nuage.
La totalité de la communication inter-équipements des commandes et signaux est réalisée à travers des liaisons IP, ce qui offre, d’une part, de la flexibilité et de l’évolutivité à l’acheminement de tout type de signaux, y compris les signaux de bande de base et les signaux compressés. D’autre part, la communication inter-équipements devient asynchrone. Une communication synchrone est maintenue uniquement au niveau des frontières du système, en vue de garantir l’interopérabilité avec les équipements conventionnels. La communication asynchrone conduit à un dimensionnement plus souple, étant donné qu’elle permet un dimensionnement statistique des interfaces d’entrée/sortie et de la puissance de calcul, au lieu d’un dimensionnement reposant sur un scénario du cas le plus défavorable.
La figure 3 illustre visuellement, dans un graphique simple, l’architecture du logiciel hiérarchique. Les petits cercles 301 représentent des sources ou des flux d’entrée, par exemple des signaux bruts provenant de dispositifs d’acquisition nécessitant des ressources pour l’ingestion, la compression, etc., sous la forme des services élémentaires susmentionnés, lesquels sont illustrés dans la figure 3 par des ellipses 302a et 302b. Ce concept peut être cascadé de sorte que la sortie du sendee élémentaire 302a devient l’entrée du sendee élémentaire 302b. La séquence de services élémentaires se traduit par une fonctionnalité ou un service fonctionnel 303. Le service fonctionnel 303 peut être conçu de manière souple en modifiant le type et/ou le nombre des services élémentaires sous-jacents afin qu’ils s’adaptent aux besoins du réalisateur.
BE2016/5252
La figure 4 symbolise, par différents éléments graphiques, l’abstraction de l’architecture logicielle du matériel sous-jacent. Tel que mentionné précédemment, les modules logiciels mettant en œuvre des sendees élémentaires peuvent fonctionner sur un matériel quelconque pourvu que ses performances soient suffisantes pour exécuter les modules logiciels avec la qualité de service requise, à savoir fournir suffisamment de puissance de traitement, de stockage et de connectivité. Les services élémentaires 302 sont constitués de fils
401 présentant un motif, dans la figure 4, qui correspond au motif des services élémentaires associés 302 et des nœuds matériels associés 402. Les parties vierges des symboles de nœuds matériels indiquent que la capacité du nœud matériel correspondant n’est pas entièrement utilisée. La partie inférieure de la figure 4 illustre comment des nœuds matériels spécifiques
402 représentant des processeurs, des mémoires et des interfaces d’entrée/sortie forment une plateforme matérielle. Les services élémentaires 302 sont mis en correspondance sur les nœuds matériels 402. La même instance logicielle peut être mise en correspondance sur plusieurs topologies matérielles. Cette mise en correspondance est mise en œuvre, par exemple, par un algorithme affectant les ressources de calcul informatique, de stockage et de connectivité nécessaires aux ressources matérielles, lesquelles sont disponibles sur une plateforme matérielle spécifique. L’algorithme de mise en correspondance permet la mise en correspondance de services élémentaires sur différentes topologies matérielles. Par conséquent, l’architecture logicielle est totalement détachée de la topologie matérielle. En conséquence, la plateforme matérielle peut être un unique serveur de production vidéo ou une grappe de multiples serveurs de production vidéo.
En termes généraux, une fonctionnalité spécifique ou un sendee fonctionnel offert(e) par le serveur de production vidéo suggéré est conçu(e) comme un pipeline. À l’entrée du pipeline, le serveur de production vidéo ingère un flux généré par un dispositif d’acquisition. À la fin du pipeline, un flux est lu. Entre les deux, des services élémentaires sont appliqués au flux en vue de fournir la fonctionnalité souhaitée.
La figure 5A illustre un exemple d’un tel pipeline qui inclut les services élémentaires « ingestion » 501, « stockage » 502 et « lecture » 503. Entre les différents sendees élémentaires, des interfaces de programmation d’application (API) sont définies (figure 5B). Les interfaces API prescrivent un format de données unitaire pour la vidéo, l’audio et/ou les métadonnées à l’entrée et à la sortie des modules logiciels, ce qui permet une séquence de services élémentaires « définie par l’utilisateur ». Les interfaces API incluent en outre un format unitaire pour des données de commande, permettant de commander les services élémentaires et
BE2016/5252 le serveur de production vidéo dans leur ensemble. Ces interfaces API sont fondamentales étant donné qu’elles permettent, conjointement avec le mécanisme de pipeline, la flexibilité du serveur de production vidéo selon la présente divulgation.
Dans un mode de réalisation du serveur de production vidéo suggéré, lequel est adapté pour des productions de diffusion en direct, le mécanisme de pipeline nécessite une certaine optimisation. Dans le cadre de productions de diffusion en direct, de très grandes quantités de données doivent être transférées et traitées. Un flux vidéo HD est constitué de 24 à 60 images par seconde, et chaque image HD comporte jusqu'à 1 920 x 1 080 pixels. Cela conduit à un débit de données de 50 à 440 Mbit/s pour un flux vidéo compressé, en production, et de jusqu'à 3 Gbit/s si le flux vidéo est non compressé. Les signaux vidéo de type « ultra haute définition » (UHD), « plage dynamique élevée » (HDR) et « fréquence de trames élevée » (HFR) conduisent à des débits de données encore plus élevés. Par conséquent, il est nécessaire de gérer correctement la charge sur la plateforme matérielle et de ne pas introduire de surcharge dans le pipeline sous l’effet de copies inutiles d’images vidéo. Ceci est réalisé en mettant en œuvre un mécanisme de source/collecteur entre chaque sendee élémentaire. Le mécanisme de source/collecteur est instancié dans le cadre de la mise en correspondance de chaque service élémentaire sur une plateforme matérielle donnée. Dans le cas où la mise en correspondance est effectuée sur une machine unique, un mécanisme de mémoire partagée protégé est utilisé. Dans le cas où la mise en correspondance est effectuée sur une grappe de multiples serveurs de production vidéo, une communication à base de protocole Internet (IP) est utilisée. Pour une communication de confiance et à courte distance, le protocole TCP peut être utilisé, tandis que pour une communication à plus longue distance, un protocole UDP amélioré est préféré.
La figure 5B illustre la relation et l’interaction entre les interfaces API et les services élémentaires. Chaque service élémentaire 504 présente, au niveau de son entrée, une interface API source 506, et au niveau de sa sortie, une interface API collectrice 507. Les interfaces API source et collectrice 506, 507 soustraient le sendee élémentaire 504 permettant une concaténation de sendees élémentaires 504 tel que cela est illustré dans la figure 5C. Dans la figure 5C, la flèche 508 symbolise le flux de données du sendee élémentaire 504 au service élémentaire 504’, par l’intermédiaire de l’interface API collectrice 507 et de l’interface API source 506'.
Les interfaces API permettent une intercession, à savoir, des sendees élémentaires supplémentaires sont exécutables entre les services élémentaires d’un pipeline existant. Cela est illustré dans la figure 5D. La figure 5D contient toujours le pipeline du premier exemple illustré dans la figure 5A. Cependant, il existe d’autres sendees élémentaires, comme le service de « codage » 509 et le service de « décodage » 510, placés entre les sendees élémentaires 501 à 503 existant à l’origine. Les sendees élémentaires supplémentaires 509 et 510 ne sont qu’exemplaires. Tout autre sendee élémentaire pourrait également être inséré, étant donné que les interfaces API permettent une quelconque combinaison de sendees élémentaires produisant la fonctionnalité spécifique requise par le réalisateur.
La figure 6 présente un schéma visant à illustrer le mécanisme de reconfiguration de pipeline. Sur le côté gauche de la figure 6, la ligne chronologique 601 est illustrée sur laquelle le temps augmente de haut en bas dans la figure 6. À l’instant Tl, le pipeline d’origine existe dans lequel des signaux transitent du service élémentaire A au sendee élémentaire B. À l’instant Tl+delta, un nouveau service élémentaire C est annoncé, puis active à l’instant T2, tandis que, simultanément, le service élémentaire B est désactivé. Ä l’instant T2+delta, le nouveau pipeline avec un flux de signaux allant du sendee élémentaire A au service élémentaire C est établi. Le flux de signaux actif, de gauche à droite dans la figure 6, est illustré par des flèches en trait continu 602, tandis qu’un flux de signaux potentiel pour un service élémentaire annoncé, ou encore annoncé, est illustré par des flèches en pointillés 603. Sur le côté droit, la figure 6 illustre également un organigramme présentant les étapes qui vont de l’établissement du pipeline d’origine à l’établissement du nouveau pipeline.
En outre, les interfaces API permettent que le pipeline soit modifié grain par grain. Cette flexibilité conduit à des applications intéressantes, étant donné qu’il est possible de gérer des besoins très différents en tenues de production, avec un unique système, sans nécessiter une quelconque surcharge de reconfiguration. Un exemple typique est la lecture consécutive dans des applications d’actualités.
Les applications d’actualités doivent combiner plusieurs sources vidéo différentes. Ces différentes sources vidéo présentent différentes propriétés, par exemple des flux de différentes sources présentent différents codages, et, par conséquent, exigent des décodeurs différents. Cela signifie que le pipeline contient différents décodeurs pour les différentes sources vidéo.
Le serveur de production vidéo suggéré, fort de son approche « par pipeline » de services élémentaires séquencés, avec des interfaces API définies entre eux, permet Γutilisation d’un décodeur différent pour chaque grain. Les interfaces API et le pipeline restent inchangés, tandis que seul le traitement interne des services élémentaires est modifié.
Le pipeline et les interfaces API permettent la modification du traitement interne d’un
E2016/5252 service élémentaire sans aucun impact sur le pipeline. Cela offre la possibilité, par exemple, de modifier le format de la vidéo (résolution, matrice de couleur,ou le protocole de la vidéo (ST2022-5/6/7, RFC4175, .,.) sans modifier le reste du pipeline. Cela permet des évolutions rapides de composants du serveur de production vidéo, ainsi qu’une polyvalence extrême et une reconfiguration « à l’échelle du grain » du pipeline.
Techniquement, cela revient au remplacement ou à la modification de fils qui composent le sendee élémentaire. Mais, indépendamment de ces modifications, les relations entre les services élémentaires restent inchangées, de sorte que le pipeline lui-même n’est pas altéré.
À titre illustratif est envisagée une simple instance de serveur de production vidéo qui stocke des flux vidéo et/ou audio dans un magasin de stockage. Un premier service d’ingestion ingère des flux de type « 10801 » selon le protocole ST2022-5/6/7. Cela nécessite une configuration simple avec un service élémentaire d’ingestion et un service de stockage. Si, au lieu de cela, un flux audio doit être stocké, alors seul le traitement interne du service élémentaire d’ingestion doit être modifié pour ingérer, par exemple, un flux audio « AES67 ». De même, le sendee d’ingestion est adaptable à d’autres formats vidéo et audio. Enfin, il doit être remarqué que le module d’ingestion est en mesure d’ingérer simultanément plusieurs sources de contenus distincts, par exemple du contenu audio, du contenu vidéo et des métadonnées, et différents formats, notamment différents codages. Les sources peuvent être reçues à partir de différentes interfaces techniques, par exemple : multidiffusion IP, SDI, ASI, monodiffusion TCP IP, etc. Les dispositifs d’acquisition à partir desquels les sources sont reçues n’ont pas besoin d’être dans le même domaine temporel.
Le serveur de production vidéo est basé sur un mécanisme de synchronisation unique. Plutôt que de s’appuyer sur une synchronisation par le pipeline d’exécution lui-même, tel que c’est le cas dans les mises en œuvre orientées matériel, le présent serveur de production vidéo est intrinsèquement asynchrone en interne. La synchronicité entre différents dispositifs dans un studio de diffusion, laquelle est essentielle dans les applications de diffusion, est obtenue en affectant des estampilles temporelles aux grains. Le module d’ingestion du serveur de production vidéo affecte une estampille temporelle à chaque paquet ou « grain ». Les estampilles temporelles sont basées sur des informations au sein du flux de données. Par ailleurs, les estampilles temporelles sont basées sur une horloge unique qui est rendue unique à travers plusieurs serveurs de production vidéo au moyen du protocole de temporisation PTP. Les paquets ou grains individuels sont identifiés par la durée temporelle et l’estampille
Π Λ, ... ΒΕ2016/5252 d acquisition.
temporelle. Le module d’ingestion lui-même est synchronisé avec les di De cette manière, le serveur de production vidéo permet un traitement en temps réel cadre d’une production en direct.
Chaque « grain » est traité, par exemple par un codage, un stockage, etc., au sein du serveur de production vidéo, de façon indépendante, tout en conservant l’ordre de traitement. Cela implique que la relation temporelle entre différents grains n’est pas garantie au sein du serveur de production vidéo.
Lorsque le serveur de production vidéo délivre en sortie les grains à nouveau, la séquence correcte des grains doit être rétablie. Il convient de remarquer que la fréquence d’horloge du système de sortie peut être différente de la fréquence d’horloge du module d’ingestion, par exemple, des trames d’image d’entrée sont reçues en provenance d’une caméra à une fréquence de 240 trames par seconde, tandis que les trames d’image de sortie sont délivrées en sortie à une fréquence de 50 Hz ou 60 Hz.
La figure 7 illustre le principe de fonctionnement du serveur de production vidéo. Dans la figure 7, deux flux sériels entrants 701, 702 sont ingérés par un serveur de production vidéo 703. Le module d’ingestion du serveur de production vidéo est synchronisé avec les dispositifs d’acquisition. Le traitement des trames de données au sein du serveur de production vidéo 703 est mis en œuvre d’une manière asynchrone. Le module de sortie du serveur de production vidéo est synchronisé à nouveau avec des dispositifs de traitement en aval et délivre en sortie deux flux 704, 705. La synchronicité des trames de sortie des flux 704, 705 est garantie par l’horloge d’un module de sortie demandant les grains correspondants : pour chaque tic d’horloge du module de sortie, le système recherche le grain qui correspond à ce tic, c'est-à-dire le grain dont le tic se situe dans la période [estampille temporelle, estampille temporelle plus durée]. Les tics d’horloge du module de sortie sont affichés sous la forme de cercles 706. Les tics d’horloge 706 se produisent simultanément pour les deux flux de sortie 704 et 705.
Pour cette raison, il est important que les différents modules matériels partagent la même horloge, tandis que les couches logicielles de l’architecture de serveur de production vidéo sont extraites du matériel sous-jacent. Le protocole PTP est utilisé en vue de garantir la synchronisation des modules matériels sur des réseaux IP. Compte tenu des taux ou fréquences de trames actuellement utilisés (une trame toutes les 8 à 50 ms), le protocole PTP est le
La combinaison de la synchronisation des flux « à base d’estampilles temporelles » et les capacités d’intercession du pipeline de serveur de production vidéo au moyen d’interfaces API unitaires permettent une approche innovante de résistance aux pannes au niveau du système.
Une application dite « d’arbitre » constitue une application du serveur de production vidéo présenté. L’application d’arbitre pennet l’affichage de trames d’images capturées par différentes caméras sous des angles différents. Les trames affichées sont prises au même instant par les différentes caméras, et un arbitre est placé dans une position en vue d’évaluer correctement une situation complexe dans un jeu de balle comme le basketball. Il peut également y avoir d’autres applications où la navigation dans plusieurs flux vidéo stockés est souhaitable.
La figure 8A illustre le fonctionnement normal du serveur de production vidéo. Les services élémentaires 801-803 et les fils 805 sont mis en correspondance sur une plateforme matérielle 806 donnée. La figure 8B illustre une situation différente dans laquelle un service élémentaire de codage 804 supplémentaire est introduit dans le pipeline s’exécutant simultanément pour fournir une fonction de reprise à chaud en cas de défaillance d’un matériel quelconque prenant en charge l’un des deux services élémentaires de codage 802, 804. Cette situation est illustrée dans la figure 8C, où ie service élémentaire de codage 802 est tombé en panne sans affecter le flux de traitement ni le pipeline dans son ensemble, étant donné que, dans cette situation, tous les paquets sont acheminés par le biais du sendee élémentaire de codage
La nature « horodatée » des grains pennet au service élémentaire successif, à savoir le service de stockage 803, de faire facilement face à d’éventuelles différences de temps de latence entre les deux modules de codage 802, 804, et de ne stocker qu’une seule instance d’une trame traitée. En cas de défaillance d’un module matériel, le système continue d’être opérationnel. De toute évidence, grâce à la possibilité de reconfiguration « à l’échelle du grain » du pipeline, cette approche peut également être utilisée dans une configuration de reprise intermédiaire.
Cette approche de reprise, ou continuité de services, nécessite nettement moins de ressources redondantes, étant donné qu’elle repose sur une connaissance du système et sur l’exploitation des propriétés du pipeline de serveur de production vidéo, plutôt que sur la duplication de l’installation complète en reproduisant la totalité du matériel sous-jacent,
La capacité de modification dynamique du pipeline ne permet pas seulement un fonctionnement à sécurité intégrée, autrement dit à tolérance de pannes, mais permet également2016/5252 de reconfigurer dynamiquement le même matériel de serveur de production vidéo, en vue de passer d’un serveur d’ingestion à un serveur de lecture ou de stockage. Ces modifications peuvent être mises en œuvre d’un grain, ou limite de trame de données, au grain successif d’un flux de données reçu.
La figure 9A illustre la tolérance aux pannes plus en détail. Le service élémentaire A 901 envoie un grain identique « Ti » 902 au sendee élémentaire Bl 903 et au service élémentaire B2 904 en même temps. Le grain Ti est traité à la fois par les services élémentaires Bl et B2, 903, 904, lesquels envoient leur sortie à l’interface API source 506 du sendee élémentaire C 906. L’interface API source 506 du service élémentaire C 906 supprime le second grain Ti si le grain identique TI a déjà été reçu. Autrement dif, si le grain Ti traité par le service élémentaire B2 904 parvient en qualité de second grain Ti à l’interface API source 506, il est abandonné. Cette configuration garantit un traitement sans interruption y compris en cas de défaillance de l’un des sendees élémentaires Bl, B2, 903, 904.
La figure 9B illustre une section d’un mode de réalisation supplémentaire d’un pipeline à tolérance de pannes. Dans ce mode de réalisation, le service élémentaire A 901 envoie le même grain Ti 902 à trois services élémentaires Bl, B2 et B3 903,904 et 905 mettant en œuvre le même type de traitement sur le grain Ti. La sortie de chaque service élémentaire Bl, B2 et B3 903, 904 et 905 est transmise à l’interface API source 506 du service élémentaire C 906. Si l’ensemble du matériel fonctionne correctement, alors le grain Ti est reçu trois fois à niveau de l’interface API source 506 du service élémentaire C 906. Dès lors que deux grains Ti identiques sont reçus au niveau de l’interface API source 506, l’un des grains identiques Ti est acheminé vers le sendee élémentaire C 906 en vue d’être traité. Si l’interface API source 506 ne détecte pas au moins deux grains Ti identiques, un message d’erreur est généré. Ce mécanisme pennet la détection des défaillances au niveau du matériel.
Enfin, il doit être remarqué que le serveur de production vidéo suggéré fournit un composant de stockage logiciel évolutif qui offre un accès basé sur IP à granularité fine instantané aux grains, dès qu’ils sont enregistrés.
La figure 10 illustre visuellement le concept du procédé de fonctionnement du serveur de production vidéo. Une séquence de services élémentaires est définie initialement, 1001, laquelle doit être appliquée à des trames de signaux vidéo et/ou audio. Ensuite, le traitement de signaux vidéo et/ou audio selon la séquence de services élémentaires définie est mis en œuvre d’une manière asynchrone 1002. Enfin, il est important de maintenir 1003 la relatioîPE2°16/5252 temporelle de trames horodatées des flux vidéo et/ou audio associés. Les flux vidéo et audio associés se rapportent à la même application.
La figure 11 représente une vue d’ensemble d’une installation de production impliquant une pluralité de serveurs 1101A à 1101F. Dans la figure 11, les serveurs individuels sont étiquetés comme des nœuds de serveurs afin de souligner que les nœuds de serveurs 1101A à 1101F sont des machines autonomes individuelles. Les nœuds de serveurs 1101A à 1101F sont reliés entre eux par l’intermédiaire d’un réseau interne 1102 en vue de former une grappe de serveurs mettant en œuvre des tâches de traitement dans le cadre d’une production de diffusion.
Etant donné que les services élémentaires sont extraits du matériel sous-jacent, en ce qui concerne l’utilisateur, peu importe si le traitement pour la production de diffusion est mis en œuvre par un nœud de serveur individuel ou une grappe de serveurs comprenant une pluralité de nœuds de serveurs. La seule différence, pour l’utilisateur, réside dans le fait qu’une grappe de nœuds de serveurs fournit une puissance de traitement supérieure, laquelle est évolutive en ce que des nœuds de serveurs supplémentaires peuvent être ajoutés ou retirés de la grappe.
Les nœuds de serveurs reçoivent des données vidéo en entrée 1103, et fournissent des données vidéo traitées en sortie 1104. Les données vidéo sont communiquées par le biais du réseau 1102. Les nœuds de serveurs 1101D et 1101E sont connectés à des stockages de disque local 1105 et 1106, Les nœuds de serveurs 1101A à 1101C sont connectés à un réseau de zone de système (SAN) î 107 connectant la grappe de serveurs illustrée dans la figure 11 à d’autres grappes de serveurs, afin d’échanger des données vidéo, par exemple, au cours d’une production de diffusion. Les nœuds de serveurs 1101C et 1101D sont connectés à des dispositifs clients 1108 en vue de recevoir une entrée et/ou de fournir une sortie. L’un des dispositifs clients 1108 peut exécuter une application commandant la grappe de serveurs.
La figure 12A représente une illustration schématique d’un exemple indiquant comment le pipeline déjà illustré dans la figure 5 est mis en œuvre sur une grappe de serveurs.
Le pipeline comprend des services élémentaires, 501, 502, 503, 509 et 510. Les flèches dans la figure 12A indiquent sur quel nœud de serveur chacun des services élémentaires est mis en correspondance. Dans d’autres modes de réalisation, la. mise en correspondance pourrait être differente. En outre, dans certains modes de réalisation, la mise en correspondance est adaptée dynamiquement en vue d’améliorer les performances de la grappe de serveurs. Le cas échéant, les modifications de la mise en correspondance se produisent d’une trame de données, ou grain, d’un flux de signaux, à la trame de données successive. Ces modifications rapides sont également pertinentes pour la tolérance aux pannes du serveur de production vidéo.
BE2016/5252
La figure 12B représente une illustration de la mise en correspondance des deux pipelines. Le premier pipeline comprend les services élémentaires 501, 502, 503, 509 et 510. Le second pipeline comprend les services élémentaires 50Γ, 502’, 503’, 509’ et 510’.
Dans les exemples illustrés dans les figures 12A et 12B, les pipelines de services élémentaires sont mis en correspondance sur une pluralité de nœuds de serveurs. Toutefois, il convient de remarquer que, dans une approche alternative, chaque nœud de serveur de la grappe exécute tous les services élémentaires d’un pipeline complet, mais uniquement une fraction de la totalité des signaux vidéo. Les deux approches ont en commun que le traitement requis pour une production de diffusion spécifique est partagé parmi les nœuds de serveurs dans la grappe.
Liste des numéros de référence
101 Studio local
BE2016/5252
509,510 services
| 102 | réseau | 601 | ligne chronologique |
| 103 | serveur vidéo | 602 | flux de signaux effectif |
| 104 | serveur de production | 603 | flux de signaux potentiel |
| 201 | serveur de production vidéo | 701,702 flux d’entrée | |
| 202 | couche matérielle | 703 | serveur de production vidéo |
| 203 | couche de bus | 704, 705 flux de sortie | |
| 204 | couche de système d’exploitation | 706 | tics d’horloge |
| 205 | couche de service | 801 - | 804 services élémentaires |
| 206 | couche d’application | 805 | fils |
| 207 | second serveur de production vidéo | 806 | plateforme matérielle |
| 208 | connexion de réseau | 901 | sendee élémentaire |
| 301 | source | 902 | grain |
| 302 | service élémentaire | 903 - | 906 services élémentaires |
| 303 | fonctionnalité | 1001 | - 1003 étapes de procédé |
| 401 | source, flux d’entrée | 1101A-1101F nœuds de serveurs | |
| 402 | nœuds matériels | 1102 | réseau de serveur interne |
| 501 - | 504 services élémentaires | 1103 | entrée vidéo |
| 506 | interface API source | 1104 | sortie vidéo |
| 507 | interface API collectrice | 1105, | 1106 stockage de disque |
| 508 | flux de données | 1107 | réseau de zone de système |
| 1108 | dispositif client |
Claims (15)
- RevendicationsBE2016/52521. Serveur de production vidéo comprenant au moins un processeur et un magasin de stockage, dans lequel des modules logiciels composés d’un code de programme exécutable sont chargés dans une mémoire de travail dudit au moins un processeur, dans lequel chaque module logiciel, lorsqu’il est exécuté par ledit au moins un processeur, fournit un. service élémentaire (501-504); dans lequel une concaténation de services élémentaires fournit une fonctionnalité impliquant le traitement de signaux vidéo et/ou audio requis en vue de produire un programme de diffusion, dans lequel le serveur de production vidéo est configuré en qualité de serveur d’ingestion ingérant des signaux, notamment des signaux vidéo et/ou audio, reçus sous la forme de flux de trames de données en provenance de dispositifs d’acquisition en synchronicité avec la sortie de dispositifs d’acquisition ;dans lequel le serveur de production vidéo est équipé d’un module d’ingestion affectant des estampilles temporelles à chaque trame de données entrante, et dans lequel le serveur de production vidéo inclut un magasin de stockage permettant un accès direct à toute trame de données après que le grain a été stocké
- 2. Serveur de production vidéo selon la revendication 1, dans lequel les modules logiciels sont mis en correspondance sur le matériel (401) du serveur de production vidéo.
- 3. Serveur de production vidéo selon la revendication 1, dans lequel le serveur d’ingestion est apte à ingérer simultanément de multiples flux de signaux de différents tonnais.
- 4. Serveur de production vidéo selon la revendication 1, dans lequel le serveur de production vidéo est aussi configuré en qualité de serveur de lecture délivrant en sortie des signaux vidéo et/ou audio sous la forme de trames de données en synchronicité avec des dispositifs en aval recevant les signaux de sortie du serveur de production vidéo.BE2016/5252
- 5. Serveur de production vidéo selon la revendication 1, dans lequel ledit au moins un processeur du serveur de production vidéo met en œuvre un traitement interne asynchrone des signaux vidéo et/ou audio et/ou de métadounées.
- 6, Serveur de production vidéo selon la revendication 1, dans lequel ledit au moins un processeur est configuré de manière à traiter les trames de données selon 1a séquence de leurs estampilles temporelles affectées par le module d’ingestion.10
- 7. Serveur de production vidéo selon la revendication 1, dans lequel chaque module logiciel du serveur de production vidéo présente des interfaces de données définies API (506, 507) prescrivant un format de données unitaire pour des données vidéo, des données audio, des métadonnées et/ou des données de commande, au niveau de l’entrée et de la sortie des modules logiciels, permettant une séquence15 « définie par l’utilisateur » de services élémentaires.
- 8. Serveur de production vidéo selon la revendication 7, dans lequel la séquence « définie par l’utilisateur » de services élémentaires forme au moins un pipeline de traitement pour des signaux vidéo et/ou audio et/ou des métadonnées.
- 9. Serveur de production, vidéo selon la revendication 8, dans lequel un service élémentaire peut être supprimé dudit au moins un pipeline de traitement, ou remplacé ou inséré dans ledit au moins un pipeline de traitement sans affecter le fonctionnement du reste du pipeline de traitement.
- 10. Serveur de production vidéo selon la revendication 2, dans lequel le serveur de production vidéo exécute un algorithme qui détecte les défaillances matérielles et remet automatiquement en correspondance les modules logiciels, de sorte que les modules logiciels ne sont plus mis en correspondance sur 3e matériel défaillant.BE2016/5252
- 11. Serveur de production vidéo selon une ou plusieurs des revendications précédentes, comprenant de multiples nœuds de serveurs (1101 A-l 101F) connectés en communication par un réseau (1102).
- 12. Serveur de production vidéo selon la revendication 11, dans lequel les modules logiciels sont mis en correspondance dynamiquement sur les multiples nœuds de serveurs (1101A-1101F) en vue d’une amélioration des performances dudit au moins un pipeline de traitement composé de services élémentaires fournis par les modules logiciels.
- 13. Système de production vidéo distribué comprenant au moins deux dispositifs de production de diffusion (103, 104), lesquels sont interconnectés par un réseau (102) et sont mutuellement synchronisés, dans lequel au moins un dispositif de l’un des dispositifs de production de diffusion est un serveur de production vidéo selon une ou plusieurs des revendications précédentes.
- 14. Procédé de fonctionnement d’un serveur de production vidéo, dans lequel le procédé comporte les étapes ci-dessous consistant à :définir une séquence de services élémentaires appliquée à des trames de données de flux de signaux reçus tels que des flux vidéo et audio ;traiter des trames de données selon la séquence de services élémentaires définie d’une manière asynchrone, et simultanément maintenir l’ordre temporel de trames de données horodatées et la synchronicité entre des flux associés, par exemple un flux vidéo, et un flux audio associé, mettre eu correspondance dynamiquement les modules logiciels sur une plateforme matérielle composée de multiples nœuds de serveurs (1101 A-l 101F) en vue d’une amélioration des performances de la séquence de services élémentaires, et- dans lequel la mise en correspondance dynamique varie d’une trame de données à la trame de données successive d’un flux de signaux reçu.BE2016/52525 15. Procédé selon la revendication 14, dans lequel le procédé comporte en outre l’étape ci-dessous consistant à :modifier dynamiquement la séquence de services élémentaires, d’une trame de données à la trame de données successive, d’un flux de signaux reçu, en supprimant un service élémentaire de la séquence de services10 élémentaires, ou en remplaçant un service élémentaire dans la séquence de services élémentaires, ou en insérant un service élémentaire dans la séquence de services élémentaires.16. Logiciel contenant un code de programme, qui, lorsqu’il est exécuté par
- 15 un processeur, met en œuvre un procédé selon les revendications 14 à 15.BE2016/5252CTtServeur ® C o3 ü Φ 3 > X?Φ S co ex.BE2016/5252BE2016/5252BE2016/5252503
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| BE2016/5252A BE1024519B1 (fr) | 2016-04-12 | 2016-04-12 | Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| BE2016/5252A BE1024519B1 (fr) | 2016-04-12 | 2016-04-12 | Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| BE1024519A1 BE1024519A1 (fr) | 2018-03-21 |
| BE1024519B1 true BE1024519B1 (fr) | 2018-03-28 |
Family
ID=59294868
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BE2016/5252A BE1024519B1 (fr) | 2016-04-12 | 2016-04-12 | Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué |
Country Status (1)
| Country | Link |
|---|---|
| BE (1) | BE1024519B1 (fr) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030208638A1 (en) * | 2002-04-02 | 2003-11-06 | Abrams Thomas Algie | Digital production services architecture |
| US20040151242A1 (en) * | 2003-01-30 | 2004-08-05 | Chienchung Chang | Modular architecture having reusable front end for processing digital video data |
-
2016
- 2016-04-12 BE BE2016/5252A patent/BE1024519B1/fr not_active IP Right Cessation
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20030208638A1 (en) * | 2002-04-02 | 2003-11-06 | Abrams Thomas Algie | Digital production services architecture |
| US20040151242A1 (en) * | 2003-01-30 | 2004-08-05 | Chienchung Chang | Modular architecture having reusable front end for processing digital video data |
Also Published As
| Publication number | Publication date |
|---|---|
| BE1024519A1 (fr) | 2018-03-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10218826B2 (en) | Scalable, live transcoding with support for adaptive streaming and failover | |
| JP6928038B2 (ja) | ライブビデオエンコーディングおよびストリーミングにおけるフレーム複写およびフレーム拡張のためのシステムおよび方法 | |
| EP3443691B1 (fr) | Serveur de production vidéo à base de logiciel modulaire, procédé pour faire fonctionner le serveur de production vidéo et système de production vidéo distribué | |
| EP3058486B1 (fr) | Plate-forme de média définie par logiciel | |
| KR102051012B1 (ko) | 스케일러블하고 강인한 라이브 스트리밍 시스템 | |
| EP2658271A1 (fr) | Distribution vidéo pair-à-pair | |
| EP3225027B1 (fr) | Procédé de composition d'une représentation vidéo intermédiaire | |
| EP1432246B1 (fr) | Procede et dispositif de decodage et d'affichage en marche arriere d'images mpeg, circuit pilote video et boitier decodeur incorporant un tel dispositif | |
| EP1483915B1 (fr) | Procede de transmission de flux de donnees dependants | |
| BE1024519B1 (fr) | Serveur de production vidéo à base de logiciel modulaire, procédé de fonctionnement du serveur de production vidéo et système de production vidéo distribué | |
| EP3891999B1 (fr) | Diffusion juste après de contenu multimédia | |
| US20240064293A1 (en) | Hybrid media recording | |
| EP3780632B1 (fr) | Systeme de distribution d'un contenu audiovisuel | |
| WO2017055771A1 (fr) | Procédé d'encodage de flux de données vidéo basées sur des groupements d'images (gop) | |
| EP2614655B1 (fr) | Diffusion synchronisee de flux | |
| EP3973714A1 (fr) | Restitution d'un contenu en arrière-plan ou sous forme d'incrustation dans le cadre d'un téléchargement progressif adaptatif de type has | |
| Pohl | Media Facility Infrastructure of the Future | |
| FR2906954A1 (fr) | Procede de retardement temporel de flux de contenus numeriques,dispositif,et produit programme d'ordinateur correspondants. |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FG | Patent granted |
Effective date: 20180328 |
|
| MM | Lapsed because of non-payment of the annual fee |
Effective date: 20220430 |