Brevet FR3073112A1 — publié le 20190503

Procédé et système de traitement d'un contenu multimédia dans un réseau de zone métropolitaine Le domaine de l'invention se rapporte aux procédés et systèmes de traitement d'un contenu multimédia au sein d'un réseau de type MAN (Metropolitan Area Network). Au cours des dernières années, la distribution de la télévision numérique a connu plusieurs évolutions. De nouveaux services audiovisuels tels que la vidéo à la demande (VOD) ou la télévision de rattrapage (Catch-Up TV) se sont développés et ont conduit au développement d'infrastructures réseaux offrant une bande passante plus large afin de faciliter la fourniture de tels services en plus de la distribution télévisuelle traditionnelle (Broadcast). Ces évolutions ont entrainé la création d'un nouveau type de services, appelé services OTT (OverThe-Top) ou services par contournement, assurant la livraison multi-écrans de contenus multimédias (vidéo et audio notamment) sur Internet. La participation d'un opérateur de réseau traditionnel dans le contrôle de la distribution du contenu est superflue pour que les services OTT fonctionnent. Ainsi, les services OTT sont fournis par l'intermédiaire de réseaux dits non managés, c'est-à-dire des réseaux dont la qualité de service (QoS) ou la bande passante varie pour chaque client et varie dans le temps. Néanmoins, les infrastructures réseaux supportant ces services OTT atteignent leurs limites lorsque le nombre de clients est trop important. Les fournisseurs de services OTT sont donc dans l'incapacité de maîtriser la qualité de service ressentie par l'utilisateur final. La fourniture de services OTT fonctionne en point à point, chaque client disposant de sa propre connexion pour télécharger les contenus multimédias. Aussi, lorsque le nombre de clients augmente, la bande passante consommée augmente également ce qui entraine une surcharge des équipements amonts des fournisseurs de services OTT et aussi une surcharge des réseaux avals de distribution jusqu'à l'utilisateur final. Cette surcharge est accentuée par la multiplicité des formats de distribution des contenus multimédias qui obligent les fournisseurs de services OTT à conserver et gérer plusieurs versions d'un même contenu sous différents formats. De plus, les fournisseurs de contenus ont un contrôle limité de la charge des plateformes de distribution. En effet, les protocoles OTT sont centrés sur le logiciel client. Celui-ci peut ainsi décider du débit qu'il va demander à la plateforme de distribution sans tenir compte des capacités et limites de celle-ci, ce qui peut conduire à une saturation de la plateforme de distribution. La présente invention vient améliorer la situation. Il est proposé un procédé de traitement mis en oeuvre par des moyens informatiques, dans un réseau de zone métropolitaine (MAN), d'un contenu multimédia préalablement encodé numériquement en un 2 flux audio-vidéo et transmis depuis une plateforme de distribution en vue d'une transmission à la demande à une pluralité de terminaux de réception, le procédé comprenant les étapes suivantes : - appliquer une fonction de démultiplexage au flux audio-vidéo, ladite fonction étant agencée pour générer au moins un groupe de flux de données, 5 - appliquer une transformation sur chaque flux de données de l'au moins un groupe de flux de données - segmenter chaque flux de données de l'au moins un groupe de flux de données transformés, - stocker l'au moins un groupe de flux de données segmentés dans une mémoire, le procédé comprenant en outre, seulement en réponse à une requête émise par un terminal de 10 réception parmi la pluralité de terminaux de réception, les étapes suivantes : - sélectionner en fonction de la requête au moins un flux de données d'au moins un groupe de flux de données stockés, - transmettre l'au moins un flux de données sélectionné à destination du terminal de réception émetteur de la requête. 15 Le procédé proposé permet la distribution de contenus multimédias aux terminaux de réception et notamment une distribution OTT (Over-The-Top). Cette distribution est mise en oeuvre notamment par la transformation et la segmentation de flux de données, appelés alors profils. Les profils sont sélectionnés en fonction des requêtes reçues puis transmis aux terminaux de réception. La réalisation du procédé au sein d'un réseau de zone métropolitaine (MAN) permet de réduire la charge sur le 20 réseau en amont, c'est-à-dire le réseau transportant les flux audio-vidéo à la plateforme de distribution, puisque ce dernier transporte un unique flux audio-vidéo pour un contenu multimédia donné. Selon un aspect, la fonction de démultiplexage est adaptée pour générer un premier groupe de flux de données vidéo, un deuxième groupe de flux de données audio et un troisième groupe de flux de données de texte et/ou sous-titrage. 25 La fonction de démultiplexage permet de décomposer le flux audio-vidéo en flux de données vidéo, en flux de données audio et en flux de données de texte et/ou sous-titrage puisque ces flux nécessitent respectivement un traitement et des transformations différentes. Selon un aspect, le procédé comprend en outre les étapes suivantes : - décoder les flux de données de l'au moins un groupe de flux de données, préalablement à 30 l'étape d'application de la transformation, - encoder chaque flux de données de l'au moins un groupe de flux de données, consécutivement à l'étape d'application de la transformation. 3 Lorsque les conditions du réseau de zone métropolitaine le permettent, un transcodage permet une plus grande latitude concernant la transformation appliquée sur les différents flux de données. Par transcodage, on entend la combinaison de processus consistant à décoder puis à encoder ultérieurement un flux de données. En effet, la transformation appliquée sur des flux de données 5 décodés et donc décompressés est moins restrictive que la transformation appliquée sur des flux de données déjà encodés et donc compressés. Selon un aspect, un manifeste comportant des données représentatives des flux de données segmentés est produit parallèlement ou consécutivement à l'étape de segmentation des flux de données. Selon un aspect, une partie au moins du manifeste produit est transmis à une partie au moins de la 10 pluralité de terminaux de réception. Le manifeste est un document de faible taille par comparaison aux données de contenu multimédia qu'il qualifie. La production du manifeste et sa mise à disposition aux terminaux de réception permet aux terminaux de réception de connaitre les profils disponibles. Selon un aspect, le procédé comprend en outre l'application d'une transformation supplémentaire sur 15 au moins un flux de données segmenté. Selon un aspect, la transformation supplémentaire inclut un filtrage et/ou une compression de l'au moins un flux de données segmenté. L'application d'une transformation supplémentaire sur les flux segmentés, c'est-à-dire les profils, permet d'adapter les profils et donc le manifeste aux conditions du réseau de zone métropolitaine. Par 20 exemple, si les conditions du réseau ne permettent pas la distribution d'un profil produit, la transformation supplémentaire permet de filtrer ce profil et donc de ne pas distribuer ce profil aux terminaux de réception. En conséquence, ce profil est supprimé du manifeste, alors mis à jour, pour éviter toute demande, via une requête, de distribution du profil en question. Selon un aspect, l'étape de segmentation des flux de données est mise en oeuvre selon un protocole de 25 type HTTP Adaptative Streaming. La segmentation des flux de données selon un protocole de type HTTP Adaptative Streaming (HAS) permet une distribution OTT selon les standards HAS et permet également une de produire plusieurs versions d'un même profil selon les protocoles de segmentation utilisés. Cette diversité des protocoles HAS permet de s'adapter aux différents terminaux de réception et d'ainsi assurer une diffusion multi- 30 écrans. Selon un aspect, l'au moins un flux de données sélectionné est transmis à destination du terminal de réception via un serveur du réseau de zone métropolitaine (MAN), le serveur étant distant de la 4 plateforme de distribution et de la pluralité de terminaux de réception, et couplé à une mémoire, la mémoire étant adaptée pour stocker temporairement l'au moins un flux de données transmis. Selon un aspect, l'au moins un flux de données sélectionné est transmis à destination du terminal de réception via un serveur du réseau de zone métropolitaine (MAN), le serveur étant distant de la 5 plateforme de distribution et de la pluralité de terminaux de réception, et couplé à une mémoire, la mémoire étant adaptée pour stocker temporairement l'au moins un flux de données transmis, la durée de conservation de l'au moins un flux de données stocké dans la mémoire étant fonction du protocole. Selon un aspect, en réponse à une requête ultérieure à la première et émise par un deuxième terminal de réception parmi la pluralité de terminaux de réception, au moins un flux de données stocké dans la 10 mémoire est transmis audit deuxième terminal de réception. Le serveur du réseau de zone métropolitaine permet de stocker les différents profils demandés par les terminaux de réception. Ainsi, si un terminal de réception transmet une requête pour la diffusion d'un profil déjà stocké dans la mémoire du serveur, celui-ci peut transmettre le profil demandé au terminal de réception. En particulier, la durée de stockage d'un profil est d'autant plus longue que sa probabilité 15 d'être à nouveau demandé est élevée. L'invention vise en outre un programme informatique comprenant des instructions pour la mise en oeuvre du procédé, lorsque les instructions sont exécutées par au moins un processeur. L'invention vise enfin un système de traitement, dans un réseau de zone métropolitaine (MAN), d'un contenu multimédia, préalablement encodé numériquement en un flux audio-vidéo et transmis au 20 système depuis une plateforme de distribution, en vue d'une transmission à la demande à une pluralité de terminaux de réception, le système comprenant - - un module de démultiplexage agencé pour appliquer une fonction de démultiplexage au flux audio-vidéo reçu et générer au moins un groupe de flux de données, - une unité de traitement agencée pour appliquer une transformation sur chaque flux de données 25 de l'au moins un groupe de flux de données, - un intégrateur agencé pour segmenter chaque flux de données de l'au moins un groupe de flux de données transformés, - une mémoire, couplée à l'intégrateur, adaptée pour stocker l'au moins un groupe de flux de données segmentés, 30 - un module de communication agencé pour réceptionner des requêtes émises par des terminaux de réception, l'intégrateur étant agencé en outre pour sélectionner, uniquement à la réception par le module de communication d'une requête émise par un terminal de réception de la pluralité de terminaux de 5 réception, en fonction de la requête au moins un flux de données d'au moins un groupe de flux de données stockés. Comme expliqué précédemment en référence au procédé, le système proposé est localisé au sein du réseau de zone métropolitaine (MAN), donc au plus près des terminaux de réception. La localisation 5 du système proposé permet de réduire la charge sur le réseau en amont transportant les flux audio- vidéo à la plateforme de distribution. Selon un aspect, la plateforme de distribution forme une passerelle entre un réseau étendu (WAN) et le réseau de zone métropolitaine (MAN). Selon un aspect, le système comprend en outre : 10 - un module de décodage agencé pour décoder les flux de données de l'au moins un groupe de flux de données en sortie du module de démultiplexage, - un module d'encodage adapté pour encoder chaque flux de données de l'au moins un groupe de flux de données en sortie de l'unité de traitement. Selon un aspect, l'unité de traitement ou une unité de traitement supplémentaire du système est 15 agencée pour appliquer une transformation supplémentaire sur au moins un flux de données segmenté. Selon un aspect, l'unité de traitement ou l'unité de traitement supplémentaire est adaptée pour filtrer et/ou compresser l'au moins un flux de données segmenté. L'unité de traitement ou l'unité de traitement supplémentaire localisée dans le système permet aux fournisseurs de contenu d'avoir davantage de maîtrise dans la distribution des contenus multimédias et 20 de modifier ou de supprimer des profils ne respectant pas les conditions du réseau de zone métropolitaine. D'autres caractéristiques, détails et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-après, et à l'analyse des dessins annexés, sur lesquels : - La Figure 1 illustre un ensemble, comprenant une plateforme de distribution, un système 25 selon un premier mode de réalisation de l'invention, un serveur distant et une pluralité de terminaux de réception ; - La Figure 2 illustre l'ensemble de la Figure 1, comprenant un système selon un deuxième mode de réalisation de l'invention ; - La Figure 3 illustre un procédé de traitement d'un contenu multimédia selon l'invention ; 30 - La Figure 4 illustre une étape du procédé de la Figure 3 selon un premier mode de réalisation de l'invention ; et 6 - La Figure 5 illustre l'étape de la Figure 4 selon un deuxième mode de réalisation de l'invention. Dans la suite, du contenu multimédia est encodé en un flux audio-vidéo pour permettre le transport du contenu, par exemple de manière connue en soit. Il est fait mention de « stockage de flux ». Le lecteur 5 comprendra qu'il s'agit de stocker des données tirées d'un flux. Sauf mention contraire, les données tirées d'un flux sont stockées sans décodage préalable, notamment dans le but d'être à nouveau transportées. Les Figures 1 et 2 illustrent un ensemble 1. L'ensemble 1 comprend une plateforme de distribution 3, un système 5, un serveur distant 7 et une pluralité de terminaux 41, 43 de réception. L'ensemble 1 est 10 localisé dans un réseau 9 de zone métropolitaine, connu sous l'acronyme anglophone MAN (Metropolitan Area Network). Le réseau 9 est, ici, défini par la norme IEEE 802.2001 : «IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture, 8 Manch 2002 ». La plateforme de distribution 3 est agencée pour transmettre un flux audio-vidéo F correspondant à un contenu multimédia au système 5. La plateforme de distribution 3 est par exemple connue sous 15 l'acronyme anglophone CDN (Content Delivery Network). Dans le contexte de l'invention, la plateforme de distribution 3 est agencée pour réaliser une distribution dite OTT (Over-The-Top). On comprend donc que le réseau 9 de zone métropolitaine est typiquement un réseau dit non managé, c'est-à-dire un réseau dont la qualité de service (QoS) ou la bande passante varie pour chaque client et varie dans le temps. Typiquement, le flux audio-vidéo F provient d'une tête de réseau d'un réseau 20 étendu, connu sous l'acronyme anglophone WAN (Wide Area Network), par exemple le réseau Internet. Avantageusement, la plateforme de distribution 3 forme une passerelle entre le réseau étendu et le réseau 9 de zone métropolitaine. Le contexte de l'invention concerne donc la distribution OTT. Néanmoins, la plateforme de distribution 3 et le système 5 sont agencés en outre pour mettre en oeuvre au moins en partie la 25 diffusion large ou diffusion télévisuelle traditionnelle ou broadcast. Le contenu multimédia désigne ici un contenu vidéo et/ou audio. Dans l'exemple décrit ici, le contenu multimédia comprend en outre du contenu texte tel que des sous-titres. Un tel contenu est destiné à être livré à au moins un terminal de réception parmi la pluralité de terminaux de réception pour rendre le contenu multimédia accessible à un utilisateur du terminal de réception. La livraison du contenu 30 multimédia au terminal de réception nécessite un traitement numérique du contenu. Ici, le contenu multimédia est préalablement encodé numériquement sous la forme du flux audio-vidéo F apte à subir le traitement décrit ci-après. On comprend que le contenu multimédia est encodé numériquement en amont de la plateforme de distribution 3, au niveau du réseau étendu avant d'être transmis à la plateforme de distribution 3. Par exemple, le flux audio-vidéo F est encodé numériquement au niveau 7 de la tête de réseau. Ensuite, un traitement numérique est appliqué au flux audio-vidéo F encodé. Le traitement numérique est exécuté par un équipement dans le réseau 9 de zone métropolitaine, par exemple la plateforme de distribution 3 elle-même ou un autre équipement. La plateforme de distribution 3 comprend un module de communication 11, une mémoire 13 et un 5 processeur 15. Le module de communication 11 est configuré recevoir le flux audio-vidéo F, par exemple via le réseau étendu en amont. Le module de communication 11 est en outre agencé pour transmettre le flux audio-vidéo F à destination de l'ensemble 5 en aval. Une plateforme de distribution 3 peut être reliée à une pluralité de réseaux tels que le réseau 9 de zone métropolitaine. 10 La mémoire 13 est adaptée pour stocker temporairement le flux audio-vidéo F reçu. Dans l'exemple décrit ici, un seul flux audio-vidéo F correspondant à un contenu multimédia est stocké. Néanmoins, la mémoire 13 est adaptée pour stocker temporairement plusieurs flux audio-vidéo. La mémoire 13 est par exemple une mémoire cache. En outre, la mémoire 13 stocke un programme informatique dont l'exécution par le processeur 15 se traduit par le fonctionnement de la plateforme de distribution 3. 15 Avantageusement, la mémoire 13 comprend une adresse de l'ensemble 5 et/ou les adresses respectives des terminaux de réception de la pluralité de terminaux de réception pour l'acheminement du flux audio-vidéo F à destination de l'ensemble 5 correspondant. On comprendra ici que les capacités de stockage de la plateforme de distribution 3 sont peu sollicitées par comparaison à des têtes de réseaux stockant tous les flux reçus. En effet, pour un contenu 20 multimédia donné, un unique flux audio-vidéo F est conservé, et ce de manière temporaire. Dans un premier mode de réalisation, illustré en Figure 1, le système 5 comprend un module de démultiplexage 17, au moins un module de décodage 19, ici trois modules de décodage 19, au moins une première unité de traitement 21, ici cinq premières unités de traitement 21, au moins un module d'encodage 23, ici cinq modules d'encodage 23, et un intégrateur 25. Avantageusement, le système 5 25 et ses composants sont physiquement regroupés et de préférence à proximité ou dans de la zone géographique correspondant au réseau 9 de zone métropolitaine. Le système 5 est, par exemple, localisé dans un point de présence, connu sous l'acronyme anglophone PoP (Point-of-Presence). Le module de démultiplexage 17 est agencé pour appliquer une fonction de démultiplexage au flux audio-vidéo F reçu de la plateforme de distribution 3 via son module de communication 11. La 30 fonction de démultiplexage permet de générer une pluralité de groupes de flux de données, tirés du flux audio-vidéo F. Par exemple, la pluralité de groupes de flux de données comprend au moins un premier groupe GR1 de flux de données vidéo, un deuxième groupe GR2 de flux de données audio et un troisième groupe GR3 de flux de données texte et/ou de sous-titrage. 8 Chaque groupe de flux de données comprend au moins un flux de données. Dans l'exemple illustré en Figure 1, le premier groupe GR1 de flux de données vidéo comprend un premier F11 et un deuxième F12 flux de données vidéo. Le deuxième groupe GR2 de flux de données audio comprend un premier F21 et un deuxième F22 flux de données audio. Le troisième groupe GR3 de flux de données de sous- 5 titrage comprend, ici, un unique flux F31 de données de sous-titrage. En sortie du module de démultiplexage 17, tous les flux de données d'un groupe de flux de données sont identiques. Dans l'exemple décrit ici, on a donc en sortie du module de démultiplexage 17 : F11 = F12 F21 = F22 10 Comme expliqué précédemment, le flux audio vidéo F est un flux encodé numériquement. Par « encodé numériquement », on entend ici que le flux audio-vidéo F est un flux compressé selon un standard donné de compression. Par conséquent, les flux de données de chaque groupe de flux de données sont également des flux compressés selon ce même standard de compression. Chaque module de décodage 19 est agencé pour décoder numériquement les flux de données d'un 15 groupe de flux de données en sortie du module de démultiplexage 17. Un module de décodage 19 est associé respectivement à chacun des groupes de flux de données. Dans l'exemple décrit ici, un module de décodage 19; est adapté pour décoder les flux de données vidéo du premier groupe GR1, un module de décodage 19j est adapté pour décoder les flux de données audio du deuxième groupe GR2 et un module de décodage 19k est adapté pour décoder le flux de données de sous-titrage du troisième 20 groupe GR3. Le même décodage numérique est appliqué à chaque flux de données d'un même groupe de flux de données. Par « décodage numérique », on entend ici que chaque flux de données d'un groupe de flux de données est, en sortie du module de décodage 19 associé, un flux non compressé en bande de base. 25 La première unité de traitement 21, ci-après l'unité de traitement 21, est adaptée pour appliquer une première transformation TR1 sur chaque flux de données en sortie du module de décodage 19. Plus précisément, une unité de traitement 21 est associée respectivement à chaque flux de données en sortie du module de décodage 19 associé. Dans l'exemple décrit ici, une unité de traitement 21i1 est adaptée pour appliquer une première transformation TR1 sur le premier flux de données vidéo F11 et une unité 30 de traitement 21j2 est adaptée pour appliquer une première transformation TR1 sur le deuxième flux de données vidéo F12. De même, une unité de traitement 21,1 est adaptée pour appliquer une première transformation TR1 sur le premier flux de données audio F21 et une unité de traitement 212 est adaptée pour appliquer une première transformation TR1 sur le deuxième flux de données audio F22. Enfin, 9 une unité de traitement 21k1 est adaptée pour appliquer une première transformation TR1 sur le flux de données de sous-titrage F31. Dans l'exemple décrit ici, un traitement numérique différent est appliqué à chaque flux de données. Les flux de données d'un même groupe de flux de données peuvent donc être différents les uns des 5 autres en sortie de l'unité de traitement 21. Par exemple, pour un même groupe, des flux de données de différentes tailles peuvent être obtenus en jouant sur la qualité du contenu multimédia au cours du traitement. Par « traitement numérique », on entend ici que la première transformation TR1 appliquée à un flux de données en sortie du module de décodage 19 est une opération ou un ensemble d'opérations parmi au 10 moins les opérations suivantes : modification du nombre de trames par secondes, redimensionnement, réduction du bruit, lissage ou correction d'erreurs présentes dans le flux. La première transformation TR1 peut évidemment désigner d'autres types d'opérations connues applicables à un flux de données dans le domaine du traitement numérique. Le module d'encodage 23 est agencé pour encoder numériquement chaque flux de données en sortie 15 de l'unité de traitement 21. Plus précisément, un module d'encodage 23 respectif est associé respectivement à chaque flux de données en sortie de l'unité de traitement 21 associée. Dans l'exemple décrit ici, un module d'encodage 23,1 est adapté pour encoder le premier flux de données vidéo F11 et un module d'encodage 23,2 est adapté pour encoder le deuxième flux de données vidéo F12. De même, un module d'encodage 23,1 est adapté pour encoder le premier flux de données audio 20 F21 et un module d'encodage 23,2 est adapté pour encoder le deuxième flux de données audio F22. Enfin, un module d'encodage 23k1 est adapté pour encoder le flux de données de sous-titrage F31. Avantageusement, un procédé d'encodage numérique différent est appliqué sur chaque flux de données. Comme expliqué précédemment, chaque flux de données d'un groupe de flux de données en sortie du 25 module de décodage 19 associé est un flux non compressé en bande de base. Par « encodage numérique », on entend ici que chaque flux de données décodé et transformé est compressé selon un standard de compression donné. En sortie du module d'encodage 23, les flux de données d'un même groupe de flux de données ont été successivement décodés selon un même processus de décodage, puis se sont vus appliqués chacun une 30 première transformation TR1 spécifique, et enfin un processus d'encodage spécifique. Par la suite, on appellera transcodage la combinaison de processus consistant à décoder puis à encoder ultérieurement un flux de données. Le mode de réalisation illustré en Figure 1 est donc un mode de réalisation permettant la mise en oeuvre d'un processus de transcodage. 10 Les différents flux de données, encodés et transformés, d'un même groupe de flux de données sont appelés profils dans la suite de la description. Dans l'exemple décrit ici, le premier groupe GR1 de flux de données vidéo comprend un premier profil vidéo F11 et un deuxième profil vidéo F12. Le deuxième groupe GR2 de flux de données audio 5 comprend un premier profil audio F21 et un deuxième profil audio F22. Enfin, le troisième groupe GR3 de flux de données de sous-titrage comprend un profil de sous-titrage F31. Les profils d'un groupe de flux de données correspondent à diverses versions d'un même contenu multimédia initial. Ainsi, le premier groupe GR1 comprend une ou plusieurs versions, ici deux profils donc deux versions, d'un même contenu vidéo, le deuxième groupe GR2 comprend une ou plusieurs 10 versions, ici deux profils donc deux versions, d'un même contenu audio et le troisième groupe GR3 comprend une ou plusieurs versions, ici un profil donc une version, d'un contenu de sous-titrage. L'existence de différents profils permet de s'adapter aux caractéristiques et capacités propres de chaque terminal de réception parmi la pluralité de terminaux de réception. Par exemple et de manière non limitative, les différents profils vidéo se distinguent par le nombre d'images par seconde, par la 15 résolution, par le standard de compression et/ou par la définition. Par exemple et de manière non limitative, les différents profils audio se distinguent par exemple par le nombre de pistes, par le standard de compression et/ou le nombre de trames par seconde. Par exemple et de manière non limitative, les différents profils de sous-titrage se distinguent par la langue et/ou le type de sous-titrage (sous-titrage des voix uniquement ou complet à destination de personnes malentendantes). 20 L'intégrateur 25 (ou « packager » en anglais) est agencé pour segmenter en une pluralité de segments chaque flux de données, donc chaque profil, d'au moins un groupe de flux de données. La segmentation des profils est mise en oeuvre selon un protocole de type HTTP Adaptative Streaming (connu sous l'acronyme anglophone « HAS »). La segmentation des profils est donc réalisée dans des formats permettant une distribution OTT selon les standards FIAS. Par exemple, le protocole de 25 segmentation de la pluralité de segments est un protocole de type MP4, MPEG2-TS ou tout autre protocole connu. Avantageusement, un même profil est segmenté selon plusieurs protocoles. On comprend ici que plusieurs versions d'un même profil sont produites, chaque version étant caractérisée au moins par le protocole de segmentation appliqué au profil. On comprend donc ici que l'intégrateur 25 est agencé pour mettre en oeuvre au moins en partie une distribution OTT. Néanmoins, comme 30 expliqué précédemment, l'intégrateur 25 est agencé en outre pour permettre, au moins en partie, la diffusion en broadcast. Parallèlement ou consécutivement à la segmentation des flux de données, donc des profils, l'intégrateur 25 est agencé pour produire un manifeste. Le manifeste est un document contenant des informations relatives aux caractéristiques de chaque profil et des segments associés. Le manifeste est ici défini par la norme ISO/IEC 23009. Plus spécifiquement, le manifeste comporte des données 11 représentatives des flux de données segmentés, donc des profils obtenus. Plus spécifiquement, on comprend ici que, pour un profil obtenu et renseigné dans le manifeste, des données représentatives du profil en question sont comprises dans le manifeste produit. Par exemple, pour un profil donné et renseigné dans le manifeste produit, les données représentatives du profil en question comprennent des 5 données représentatives du protocole de segmentation du profil. Les données représentatives du profil en question peuvent comprendre des données représentatives de la taille des segments obtenus. . Typiquement, le manifeste est produit dans un format XML. Le manifeste est un document de faible taille par comparaison aux données de contenu multimédia qu'il qualifie. Il peut donc être largement diffusé sans que cela ait une influence négative importante sur la charge des réseaux. Le manifeste est 10 mis à disposition, rendu accessible, aux terminaux de réception. On comprend donc qu'une partie au moins du manifeste est transmis à une partie au moins des terminaux de réception. En outre, le manifeste peut être mis à jour au sein de l'intégrateur. La mise à jour du manifeste est par exemple fonction des conditions du réseau 9 de zone métropolitaine. On comprend ici qu'il est possible que les conditions du réseau 9 de zone métropolitaine ne permettent pas, temporairement, la distribution d'un 15 profil même si ce profil a pu être généré et segmenter. Dans un tel cas, ce profil peut par exemple être filtré du manifeste. En d'autres termes, les données représentatives du profil en question sont supprimées du manifeste. Ainsi, le profil filtré ne peut plus être demandé par un terminal de réception. Le manifeste mis à jour est ensuite rendu accessible aux terminaux de réception à la place du manifeste précédent. Ainsi, tant que les conditions du réseau 9 de zone métropolitaine ne permettent 20 pas la distribution d'un profil, un utilisateur ne peut demander la distribution du profil en question, ce dernier n'étant pas renseigné dans le manifeste. L'intégrateur 25 est agencé en outre pour sélectionner, à la réception d'une requête émise par un terminal de réception parmi la pluralité de terminaux de réception, au moins un flux de données d'au moins un groupe de flux de données segmentés en fonction de la requête reçue. L'intégrateur 25 est en 25 outre agencé pour transmettre l'au moins un flux de données sélectionné au terminal de réception à l'origine de la requête via le serveur distant 7. Dans le contexte de l'invention, un terminal de réception émet une requête à destination de l'intégrateur 25 pour accéder d'un contenu multimédia via la diffusion d'un ou plusieurs profils correspondant à ce contenu multimédia. Comme expliqué précédemment, les profils accessibles à un terminal de réception sont renseignés dans le manifeste 30 rendu accessible au terminal de réception. Typiquement, pour accéder à un contenu multimédia donné, un terminal de réception envoie une requête pour la diffusion d'un profil vidéo, d'un profil audio et d'un profil de texte et/ou sous-titrage. Les profils disponibles sont les profils renseignés dans le manifeste. La distribution des profils demandés dans la requête constitue une distribution dite à la demande. 35 L'intégrateur 25 comprend un module de communication 27, une mémoire 29 et un processeur 31. 12 Le module de communication 27 est agencé pour recevoir la requête émise par un terminal de réception de la pluralité de terminaux de réception via le serveur distant 7. Le module de communication 27 est agencé pour recevoir les différents profils de chaque groupe de flux de données en sortie du module d'encodage 23. Le module de communication 27 est en outre agencé pour émettre 5 les profils segmentés à destination du terminal de réception via le serveur distant 7. La mémoire 29 est adaptée pour stocker temporairement les différents profils de chaque groupe en sortie du module d'encodage 23. La mémoire 29 inclut par exemple une mémoire cache. En outre, la mémoire 29 stocke un programme informatique dont l'exécution par le processeur 31 se traduit par le fonctionnement de l'intégrateur 25. Avantageusement, la mémoire 29 comprend les adresses 10 respectives des terminaux de réception de la pluralité de terminaux de réception pour l'acheminement des profils segmentés à destination des terminaux de réception. Dans un mode de réalisation, l'intégrateur 25 est agencé pour chiffrer les segments et/ou le manifeste transmis au serveur distant. Le serveur distant 7 est adapté pour transmettre des segments ou des profils segmentés reçus en 15 provenance de l'intégrateur 25 à destination d'un terminal de réception parmi la pluralité de terminaux de réception. On comprend ici que le serveur distant 7 est adapté pour permettre à la pluralité de terminaux de réception d'accéder aux profils segmentés transmis. Le serveur distant 7 comprend un module de communication 33, une mémoire 35 et un processeur 37. Le module de communication 33 est configuré recevoir les segments ou profils segmentés émis par 20 l'intégrateur 25. Le module de communication 33 est configuré pour transmettre une requête reçue en provenance d'un terminal de réception à l'intégrateur 25. La mémoire 35 est agencée pour stocker temporairement les segments ou profils segmentés reçus. La mémoire 35 inclut, par exemple, une mémoire cache. Avantageusement, la durée de conservation d'un profil ou d'un segment dans la mémoire 35 est déterminée en fonction du protocole de segmentation. 25 Un profil ou un segment est conservé dans la mémoire 35 d'autant plus longtemps que le protocole de segmentation dont il résulte est susceptible d'être demandé par les utilisateurs par l'intermédiaire des requêtes. On comprend ici qu'une probabilité est associée, au sein du serveur distant 7, à un profil segmenté stocké dans la mémoire 35. Cette probabilité correspond à la probabilité que ce profil soit à nouveau demandé par un autre terminal de réception. Cette probabilité est par exemple déterminée en 30 fonction du protocole de segmentation du profil segmenté en question. Ainsi, en réponse à une requête ultérieure émise par un deuxième terminal de réception de la pluralité de terminaux de réception, le serveur distant 7 est agencé pour transmettre un segment ou un profil segmenté stocké dans la mémoire 35 au deuxième terminal de réception. Les segments ou profils segmentés fréquemment 13 utilisés restent disponibles dans la mémoire 35 tandis que les segments ou profils segmentés rarement demandés sont, à terme, supprimés de la mémoire 35. En outre, la mémoire 35 stocke un programme informatique dont l'exécution par le processeur 37 se traduit par le fonctionnement du serveur distant 7. 5 Comme expliqué précédemment, la distribution des profils segmentés est mise en oeuvre selon les standards HAS dans le contexte d'une distribution OTT. Néanmoins, et comme précisé précédemment, le système 5 est agencé en outre pour mettre en oeuvre au moins en partie la diffusion large ou diffusion télévisuelle traditionnelle ou broadcast dans un ou plusieurs modes de réalisation. Pour permettre la diffusion de contenu multimédia en broadcast, le serveur distant 7 comprend, dans 10 un ou plusieurs modes de réalisation, un module de multiplexage 39. Le module de multiplexage 39 est agencé pour générer un contenu multimédia incluant de la vidéo, de l'audio et du texte et/ou sous-titrage. De même que pour la distribution OTT, le contenu généré par le module de multiplexage 39 est transmis à un terminal de réception de la pluralité de terminaux de réception via le module de communication 33. 15 Dans le cadre du broadcast, les flux sont diffusés, c'est-à-dire envoyés sur le réseau sans requête. A l'inverse, dans la distribution OTT, les flux sont mis à disposition des terminaux de réception et ne sont distribués que sur réception des requêtes reçues en provenance des terminaux de réception. Comme expliqué précédemment, le système 5 et le serveur 7 sont agencés pour permettre à la fois une distribution OTT et une diffusion en broadcast. 20 Dans l'exemple illustré en Figure 1, la pluralité de terminaux de réception comprend un premier terminal de réception 41 et un deuxième terminal de réception 43. Les terminaux de réception 41, 43 sont aptes à recevoir des segments ou des profils segmentés en provenance de l'intégrateur 25 via le serveur distant 7. Les terminaux de réception 41, 43 sont agencés en outre pour générer, à partir des segments ou des profils segmentés reçus, le contenu multimédia auquel l'utilisateur souhaite accéder. 25 Alternativement, le contenu multimédia demandé est généré au niveau du serveur distant 7 puis est transmis aux terminaux de réception. Les premier et deuxième terminaux de réception 41, 43 comprennent chacun un module de communication 45 et un écran 47. Par exemple, le premier terminal de réception 41 est un ordinateur et le deuxième terminal de réception 43 est une télévision. 30 Le module de communication 45 est configuré pour recevoir le contenu multimédia transmis par le serveur distant 7. Le module de communication 45 est en outre adapté pour émettre une requête à destination du serveur distant 7. 14 L'écran 47 est adapté pour diffuser une partie au moins du contenu multimédia reçu par le module de communication 45. Les premier 41 et deuxième 43 terminaux de réception sont agencés pour générer des requêtes à destination du serveur distant 7. Les requêtes peuvent contenir une combinaison de paramètres 5 déterminés automatiquement, par exemple un niveau de qualité du contenu multimédia en fonction de la qualité de la connexion, et des paramètres sélectionnés par l'utilisateur, par exemple par l'intermédiaire d'une interface homme-machine. Ces paramètres sont par exemple, et de manière non limitative, le débit, la résolution, la définition de l'image ou la présence ou non de sous-titres. La Figure 2 illustre le système 5 selon un deuxième mode de réalisation. Ce deuxième mode de 10 réalisation se distingue du premier mode de réalisation décrit précédemment en ce qu'il est dépourvu de module destiné au transcodage. En d'autres termes, le système 5 de ce deuxième mode de réalisation ne comprend pas de module de décodage 19 ni de module d'encodage 23. Ainsi, l'unité de traitement 21 est agencée pour appliquer une première transformation TR1 sur chaque flux de données déjà encodé 19. Dans le contexte de ce deuxième mode de réalisation, les différents 15 profils de chaque groupe de flux de données correspondent aux différents flux de données préalablement encodés puis transformés de chaque groupe de flux de données. Comme expliqué précédemment, ce deuxième mode de réalisation est mis en oeuvre sans transcodage. La première transformation TR1 de ce deuxième mode de réalisation est donc appliquée sur des flux de données déjà compressés. A l'inverse, la première transformation TR1 du premier mode de 20 réalisation décrit précédemment en référence à la Figure 1 est appliquée à des flux de données décodés et donc décompressés. La première transformation TR1 appliquée sur des flux de données déjà compressés est plus restrictive que la première transformation TR1 appliquée sur des flux de données décompressés. On comprend donc que seule une partie des opérations applicables aux flux de données décompressés est applicable aux flux de données compressés. 25 Le deuxième mode de réalisation se distingue du premier mode de réalisation en outre par la présence d'une deuxième unité de traitement 49, ci-après l'unité de traitement 49. L'unité de traitement 49 est incluse dans l'intégrateur 25. Alternativement, la deuxième unité de traitement 49 intervient en sortie de l'unité de traitement 21. L'unité de traitement 49 est agencée pour appliquer une transformation supplémentaire TR2, ci-après 30 deuxième transformation TR2, sur au moins un profil segmenté. La deuxième transformation TR2 inclut par exemple un filtrage et/ou une compression d'au moins un flux de données. En variante, la distinction entre l'unité de traitement 21 et l'unité de traitement 49 est seulement fonctionnelle : les deux traitements peuvent être mis en oeuvre au moins en partie par un même équipement informatique. 15 Dans l'exemple décrit, l'unité de traitement 19 et l'unité de traitement 49 sont deux unités de traitement réalisant respectivement la première transformation TR1 et la deuxième transformation TR2. Alternativement, l'unité de traitement 19 et l'unité de traitement 49 sont une même unité de traitement agencée pour appliquer la première transformation TR1 et la deuxième transformation TR2. 5 Un procédé de traitement du contenu multimédia dans le réseau 9 de zone métropolitaine est décrit-ci- après en référence à la Figure 3. Le contenu multimédia est distribué dans le cadre d'une distribution OTT. Typiquement, le réseau 9 de zone métropolitaine est un réseau dit non managé, c'est-à-dire des réseaux dont la qualité de service (QoS) ou la bande passante varie pour chaque client et varie dans le temps 10 Dans une première étape S 1, la plateforme de distribution 3 reçoit un contenu multimédia, préalablement encodé numériquement en un flux audio-vidéo F. Par exemple, le contenu multimédia a été encodé numériquement par la tête de réseau dans un réseau étendu et le flux audio-vidéo F résultant a été transmis à la plateforme de distribution 3. Dans un mode de réalisation, la plateforme de distribution 3 joue le rôle de passerelle entre le réseau étendu et le réseau 9 de zone métropolitaine 15 (MAN). À l'issue de cette première étape S1, le flux audio-vidéo F est transmis par le module de communication 11 de la plateforme de distribution 3 au système 5. Comme expliqué précédemment, le système 5 est typiquement localisé dans un point de présence, ou PoP. En particulier dans l'exemple décrit ici, le flux audio-vidéo F est transmis par le module de communication 11 au module de démultiplexage 17. 20 Dans une deuxième étape S2, le module de démultiplexage 17 applique une fonction de démultiplexage au flux audio-vidéo F. Cette fonction de démultiplexage génère au moins un groupe de flux de données. Dans l'exemple décrit en Figure 1, la fonction de démultiplexage génère un premier groupe GR1 de flux de données vidéo, un deuxième groupe GR2 de flux de données audio et un troisième groupe GR3 de flux de données de texte et/ou sous-titrage. Le premier groupe GR1 de flux 25 de données vidéo comprend un premier F11 et un deuxième F12 flux de données vidéo. Le deuxième groupe GR2 de flux de données audio comprend un premier F21 et un deuxième F22 flux de données audio. Enfin, le troisième groupe GR3 de flux de données de sous-titrage comprend un flux F31 de données de sous-titrage. Une troisième étape S3 comprend le traitement numérique des flux de données des groupes de flux de 30 données. La troisième étape S3 inclut la génération et le traitement des différents profils pour chaque groupe de flux de données. Les profils obtenus sont ensuite segmentés au sein de l'intégrateur 25, puis stockés dans la mémoire 29 de l'intégrateur 25. La troisième étape S3 inclut en outre la génération d'un manifeste. Comme expliqué précédemment, le manifeste est un document rendu accessible aux terminaux de réception et contenant des informations relatives aux caractéristiques de chaque profil et 35 des segments associés. Le manifeste comporte plus particulièrement des données représentatives des 16 flux de données segmentés, donc des profils obtenus. Par exemple, pour un profil donné et renseigné dans le manifeste produit, les données représentatives du profil en question comprennent des données représentatives du protocole de segmentation du profil. Les données représentatives du profil en question peuvent comprendre des données représentatives de la taille des segments obtenus. Le 5 manifeste permet aux terminaux de réception de déterminer quels sont les profils disponibles. Un premier et un deuxième mode de réalisation de cette troisième étape S3 seront décrits en détails ci-après. Comme expliqué par la suite, cette étape S3 correspond en fait à une suite d'étapes qui diffèrent selon le mode de réalisation. A l'issue de cette troisième étape S3, des profils sont sélectionnés par l'intégrateur 25 en vue d'une distribution à au moins un terminal de réception. 10 Dans une quatrième étape S4, l'intégrateur 25 reçoit une requête en provenance d'un terminal de réception parmi la pluralité de terminaux de réception. Par exemple, la requête est émise par le premier terminal de réception 41. La requête comprend des données représentatives du choix de profils que l'utilisateur du terminal de réception souhaite recevoir. Comme expliqué précédemment, les profils disponibles sont renseignés dans le manifeste rendu accessible au terminal de réception. Ainsi 15 l'utilisateur peut effectuer un choix parmi les profils disponibles par l'intermédiaire d'une interface du terminal de réception. Les profils demandés via la requête sont donc nécessairement des profils renseignés dans le manifeste. Dans l'exemple décrit ici, plusieurs profils vidéo correspondant à un même contenu multimédia sont disponibles. De même, plusieurs profils audio correspondant à un même contenu multimédia sont disponibles. Enfin, plusieurs profils de texte et/ou sous-titrage 20 correspondant à un même contenu multimédia. En outre, et comme expliqué ci-dessus chaque profil peut être segmenté dans la mémoire 29 de l'intégrateur 25 selon différents protocoles de type HTTP Adaptative Streaming. Ainsi, plusieurs versions d'un même profil sont donc stockées dans la mémoire 29, chaque version correspondant à un protocole de segmentation. La requête peut comprendre en outre des informations d'adressage telles que l'adresse du terminal de réception et optionnellement 25 toute autre information utile à l'acheminement du ou des profils segmentés demandés à destination du terminal par l'intermédiaire du serveur distant 7. Dans une cinquième étape S5, l'intégrateur 25 sélectionne en fonction de la requête reçue au moins un profil segmenté. Avantageusement, l'intégrateur 25 sélectionne au moins un profil par groupe de flux de données, c'est-à-dire par groupe de profils. À titre d'exemple, l'intégrateur peut sélectionner le 30 premier profil vidéo F11, le deuxième profil audio F22 et le profil de texte et/ou sous-titrage F31. La sélection d'au moins un profil par groupe de profils permet la génération d'un contenu multimédia comprenant un contenu vidéo, un contenu audio et un contenu de texte et/ou sous-titrage. Dans une sixième étape S6, le module de communication 27 de l'intégrateur 25 transmet les profils sélectionnés au serveur distant 7 en vue d'une distribution en OTT au terminal de réception à l'origine 35 de la requête traitée. L'intégrateur peut transmettre en outre un manifeste produit ou un manifeste mis 17 à jour par l'intégrateur au serveur distant 7 en vue de rendre accessible aux terminaux de réception le manifeste, et donc d'informer les utilisateurs respectifs des terminaux de réception des profils et protocoles disponibles. Dans une septième étape S7, le module de communication 33 du serveur distant 7 reçoit les profils 5 segmentés transmis par l'intégrateur 25. Le ou les profils segmentés sont stockés temporairement dans la mémoire 35. Comme expliqué précédemment, la durée de conservation d'un profil segmenté ou d'un segment dépend de la probabilité que le profil segmenté ou segment en question soit à nouveau demandé par un autre terminal de réception. Autrement dit, plus un profil segmenté ou un segment est susceptible de faire l'objet d'une requête émise par un terminal de réception, plus la durée de 10 conservation de ce profil segmenté ou segment sera élevée. Typiquement, cette durée de conservation est fonction du protocole de segmentation du profil considéré. On comprend ici que certains protocoles de segmentation peuvent être plus demandés que d'autres. Dans un mode de réalisation, le contenu multimédia demandé est généré au niveau du serveur distant, par exemple par le processeur 31, à partir des profils segmentés reçus, conformément à la requête. Mais comme expliqué 15 précédemment, le contenu multimédia peut, dans un autre mode de réalisation, être généré au niveau des terminaux de réception, le serveur distant 7 relayant simplement les profils segmentés ou des segments. Par exemple, dans une huitième étape S8, une nouvelle requête est émise par un terminal de réception parmi la pluralité de terminaux de réception. Par exemple, le deuxième terminal de réception 43 émet 20 une requête, via le module de communication 45, au serveur distant 7 pour accéder à un contenu multimédia identifié. Si cette nouvelle requête est similaire à la requête précédemment traitée et que les profils segmentés ou segments demandés sont toujours stockés dans la mémoire 35, le serveur 7 transmet le contenu multimédia demandé sans qu'il soit nécessaire d'adresser la requête à l'intégrateur 25. 25 En référence à la Figure 4, la troisième étape S3 va être décrite selon un premier mode de réalisation du procédé. Ce mode de réalisation est mis en oeuvre par l'ensemble 1 illustré en Figure 1. Un tel mode de réalisation est, par exemple, mis en oeuvre lorsque le transcodage est possible au niveau du réseau 9 de zone métropolitaine. Dans une première étape Ti, les flux de données de chaque groupe de flux de données sont décodés 30 numériquement par le module de décodage 19 en sortie du module de démultiplexage 17. Comme expliqué précédemment, un module de décodage 19 est associé respectivement à chaque groupe de flux de données. Dans l'exemple décrit ici, un module de décodage est adapté pour décoder les flux de données vidéo du premier groupe GR1, un module de décodage est adapté pour décoder les flux de données audio du deuxième groupe GR2 et un module de décodage est adapté pour décoder les flux de 35 données de sous-titrage du troisième groupe GR3. 18 Comme expliqué précédemment, on entend par « décodage numérique », que chaque flux de données d'un groupe de flux de données est, en sortie du module de décodage 19 associé, un flux non compressé en bande de base. Dans une deuxième étape T2, une première transformation TR1 est appliquée par la première unité de 5 traitement 21, ci-après l'unité de traitement 21, sur chaque flux de données en sortie du module de décodage 19. Comme expliqué précédemment, une unité de traitement 21 est attribuée à chacun des flux de données. Comme expliqué précédemment, on entend par « traitement numérique » que la première transformation TR1 appliquée à un flux de données en sortie du module de décodage 19 est une 10 opération ou un ensemble d'opérations parmi les opérations suivantes : modification du nombre de trames par secondes, redimensionnement, réduction du bruit, lissage ou correction d'erreurs présentes dans le flux. La première transformation TR1 peut désigner d'autres types d'opérations connues applicables à un flux de données. Dans une troisième étape T3, chaque flux de données est encodé numériquement en sortie de l'unité 15 de traitement 21 par un module d'encodage 23. Comme expliqué précédemment, un module d'encodage 23 respectif est associé à chacun des flux de données. Les différents flux de données en sortie des modules d'encodage 23 constituent différents profils. Comme expliqué précédemment, on entend par « encodage numérique » que chaque flux de données décodé et transformé est compressé selon un standard donné. 20 Les différents profils d'un même groupe de flux de données correspondent à différentes versions d'un même contenu multimédia. Dans l'exemple décrit ici, le premier groupe GR1 comprend deux profils, donc deux versions, d'un même contenu vidéo. Le deuxième groupe GR2 comprend deux profils d'un même contenu audio. Le troisième groupe GR3 contient un seul profil d'un contenu de sous-titrage. Dans une quatrième étape T4, les profils obtenus sont respectivement segmentés en une pluralité de 25 segments. Chaque segment correspond à un fragment temporel du contenu multimédia. Typiquement, un segment correspond à quelques secondes du contenu multimédia. Comme expliqué précédemment, la segmentation des profils est mise en oeuvre selon un protocole de type HTTP Adaptative Streaming. Par exemple, le protocole de segmentation de la pluralité de segments est un protocole de type MP4 ou MPEG2-TS. Un même profil est segmenté selon plusieurs protocoles. Ainsi plusieurs versions d'un 30 même profil sont produites, chaque version étant caractérisée au moins par le protocole de segmentation appliqué au profil. Dans une cinquième étape T5, parallèlement ou consécutivement à l'étape T4, l'intégrateur 25 génère un manifeste. Comme expliqué précédemment, le manifeste est un document contenant des 19 informations relatives aux caractéristiques de chaque profil et des segments associés. Le manifeste comporte des données représentatives des flux de données segmentés, c'est à dire des profils obtenus. On comprend ici que, pour un profil obtenu et renseigné dans le manifeste, des données représentatives du profil en question sont comprises dans le manifeste produit. Par exemple, pour un 5 profil donné et renseigné dans le manifeste, les données représentatives du profil en question comprennent des données représentatives du protocole de segmentation du profil. Les données représentatives du profil en question peuvent comprendre des données représentatives de la taille des segments obtenus. Typiquement, le manifeste est produit dans un format XML. Le manifeste est destiné à être mis à disposition, rendu accessible, aux terminaux de réception. En outre, le manifeste 10 peut être mis à jour au sein de l'intégrateur, indépendamment des profils. La mise à jour du manifeste est par exemple fonction de paramètres du réseau 9 de zone métropolitaine. Par exemple, les paramètres d'un réseau 9 de zone métropolitaine peuvent ne pas permettre, temporairement ou non, la distribution d'un profil même si ce profil a pu être préalablement généré et segmenté. Dans un tel cas, les données relatives ce profil peuvent, par exemple, être supprimées du manifeste. Le manifeste mis à 15 jour est ensuite rendu accessible aux terminaux de réception en remplacement du manifeste précédent. Ainsi, tant que les conditions du réseau 9 de zone métropolitaine ne permettent pas la distribution d'un profil, un utilisateur ne peut demander la distribution du profil en question, ce dernier n'étant pas renseigné dans le manifeste, et ce indépendamment de la disponibilité effective du profil en amont du réseau 9 de zone métropolitaine. 20 Dans une sixième étape T6, les profils segmentés obtenus sont stockés dans la mémoire 29 de l'intégrateur 25. Les étapes Ti, T2, T3, T4, T5 et T6 de ce premier mode de réalisation sont ici appelées « étapes » mais peuvent être également considérées comme des sous-étapes de l'étape S3. Comme expliqué précédemment, l'exécution des étapes Ti, T2, T3, T4, T5 et T6 est un mode de réalisation de 25 l'exécution de l'étape S3. Dans le mode de réalisation du procédé décrit en référence à la Figure 4, la segmentation des profils selon différents protocoles précède la réception d'une requête. Néanmoins, les technologies de fourniture en temps réel, dites de Just in Time (JIT), permettent de procéder à la segmentation des profils reçus par l'intégrateur 25 à réception de la requête et en fonction de la requête. En variante, un profil est segmenté, à l'avance ou à réception d'une première requête, selon 30 un seul protocole, avantageusement le protocole le plus susceptible d'être demandé, de manière à optimiser les capacités de stockage de la mémoire 29 de l'intégrateur 25. En référence à présent à la Figure 5, la troisième étape S3 va être décrite selon un deuxième mode de réalisation. Ce mode de réalisation est mis en oeuvre par l'ensemble 1 illustré en Figure 2. Dans ce deuxième mode de réalisation, il n'y a pas de transcodage. Autrement dit, le traitement numérique est 35 appliqué à des flux préalablement encodés et non encore décodés. 20 Dans une première étape Ul, une première transformation TR1 est appliquée par l'unité de traitement 21 sur chaque flux de données encodé. Comme expliqué précédemment, une unité de traitement 21 respective est associée à chacun des flux de données. Les différents flux de données en sortie de l'unité de traitement 21 constituent les différents profils de chaque groupe de flux de données. Comme 5 expliqué précédemment, la première transformation TR1 de ce deuxième mode de réalisation est donc appliquée sur des flux de données encodés, donc déjà compressés. La première transformation TR1 appliquée sur des flux de données déjà compressés est plus restrictive que la première transformation TR1 appliquée sur des flux de données décompressés : seule une partie des opérations applicables aux flux de données décompressés est applicable aux flux de données compressés. 10 Dans une deuxième étape U2, similaire à l'étape T4 du premier mode de réalisation, les profils obtenus sont respectivement segmentés en une pluralité de segments. Chaque segment correspond à un fragment temporel du contenu multimédia. Typiquement, un segment correspond à quelques secondes du contenu multimédia. Comme expliqué précédemment, la segmentation des profils est mise en oeuvre selon un protocole de type HTTP Adaptative Streaming. Par exemple, le protocole de 15 segmentation de la pluralité de segments est un protocole de type MP4 ou MPEG2-TS. Un même profil est segmenté selon plusieurs protocoles. On comprend ici que plusieurs versions d'un même profil sont produites, chaque version étant caractérisée au moins par le protocole de segmentation appliqué au profil. Dans une troisième étape U3, similaire à l'étape T5 du premier mode de réalisation, parallèlement ou 20 consécutivement à l'étape U2, l'intégrateur 25 génère un manifeste, comportant des données représentatives des flux de données segmentés, c'est à dire des profils obtenus. Le manifeste est destiné à être mis à disposition, rendu accessible, aux terminaux de réception. Dans une quatrième étape U4, similaire à l'étape T6 du premier mode de réalisation, les profils segmentés obtenus sont stockés dans la mémoire 29 de l'intégrateur 25. 25 Dans une sixième étape U6, une deuxième transformation TR2 est appliquée sur au moins un profil stocké par la deuxième unité de traitement 49, ci-après l'unité de traitement 49. Dans une réalisation, la deuxième transformation TR2 inclut un filtrage et/ou une compression. Cette deuxième transformation TR2 peut s'avérer avantageuse ou nécessaire lorsque, par exemple, les conditions de fonctionnement du réseau 9 de zone métropolitaine ne permettent pas, temporairement ou non, la 30 distribution d'un profil même si ce profil a pu être préalablement généré et segmenté. Dans un tel cas, la deuxième transformation TR2 permet de transformer un profil en une version dont les conditions du réseau 9 de zone métropolitaine permettent une distribution. Dans ce cas, le manifeste est mis à jour en conséquence. 21 Dans les cas où les conditions du réseau 9 de zone métropolitaine sont altérées, un profil du manifeste peut être filtré. En d'autres termes, le profil segmenté en question n'est pas transformé mais n'est plus renseigné dans le manifeste de sorte qu'il ne peut plus faire l'objet d'une requête. Le manifeste mis à jour est ensuite rendu accessible aux terminaux de réception à la place du manifeste précédent. Ainsi, 5 tant que les conditions de fonctionnement du réseau 9 de zone métropolitaine ne permettent pas la distribution d'un profil, un utilisateur ne peut demander la distribution du profil en question, ce dernier n'étant pas renseigné dans le manifeste. Les étapes Ul, U2, U3, U4 et U5 de ce deuxième mode de réalisation sont ici appelées « étapes » mais peuvent être également considérées comme des sous-étapes de l'étape S3. Comme expliqué 10 précédemment, l'exécution des étapes Ul, U2, U3, U4 et U5 est un mode de réalisation de l'étape S3. Dans le mode de réalisation du procédé décrit en référence à la Figure 5, la segmentation des profils selon différents protocoles précède la réception d'une requête. Néanmoins, les technologies dites de Just in Time (JIT) permettent de procéder à la segmentation des profils reçus par l'intégrateur 25 après réception de la requête et en fonction de la requête. En variante, un profil est segmenté selon un seul 15 protocole, à l'avance ou à réception d'une première requête, avantageusement le protocole le plus susceptible d'être demandé, de manière à optimiser les capacités de stockage de la mémoire 29 de l'intégrateur 25. L'exemple décrit ci-après illustre ce deuxième mode de réalisation, notamment l'étape U6 d'application de la deuxième transformation TR2 et/ou la mise à jour du manifeste : 20 On suppose que le premier groupe GR1 de flux de données vidéo comprend un premier F11, un deuxième F12 et un troisième F13 flux de données vidéo, définis ainsi après application de la première transformation TR1 respectivement sur chaque flux de données déjà encodé du premier groupe GR1 de flux de données vidéo (le troisième flux n'est pas représenté sur les figures) : - F11 : Ultra-haute définition (connue sous l'acronyme UHD) à 50 images par seconde 25 - F12 : Haute-définition (connue sous l'acronyme HD) à 50 images par seconde - F13 : Quad Haute-définition (connue sous l'acronyme QHD) à 25 images par seconde Les trois flux de données déjà encodés puis transformés sont donc trois profils différents. Ces profils sont ensuite segmentés selon différents protocoles de segmentation. Si l'accessibilité, les conditions ou l'état du réseau 9 de zone métropolitaine ne permettent pas une 30 distribution à la pluralité de terminaux de réception de profils avec une définition supérieure à la haute-définition et à plus de 25 images par seconde, l'unité de traitement 49 applique une deuxième transformation au premier F11 et au deuxième F12 profils vidéo. Le troisième profil vidéo F13 présente 22 des propriétés compatibles avec les limites du réseau 9 de zone métropolitaine et ne nécessite donc pas l'application de la deuxième transformation TR2. Par exemple, le premier profil vidéo F11 est filtré. Ce premier profil vidéo F11 ne sera donc plus accessible à la pluralité de terminaux de réception. En conséquence et comme expliqué précédemment, 5 ce profil sera donc également filtré du manifeste. En d'autres termes, les données représentatives de ce premier profil vidéo F11 seront supprimées du manifeste. Le manifeste, ainsi mis à jour, est ensuite rendu accessible aux terminaux de réception à la place du manifeste précédent. Ainsi, le premier profil vidéo F11 ne peut plus faire l'objet d'une requête en provenance de l'un de la pluralité de terminaux de réception. Néanmoins, dans un mode de réalisation, il est également possible de filtrer le premier 10 profil vidéo F11 du manifeste sans supprimer le premier profil de la mémoire 29. Le deuxième profil vidéo F12 peut également être filtré. Néanmoins, afin de préserver une variété dans les versions disponibles du contenu multimédia et de ne pas modifier trop significativement le manifeste, ce deuxième profil vidéo F22 peut en variante être compressé pour réduire le débit à 25 images par seconde. En conséquence, les données représentatives du deuxième profil vidéo F12 dans le manifeste 15 sont modifiées. Un premier et un deuxième modes de réalisation de l'invention ont été présentés dans la description. Ces deux modes de réalisation sont compatibles et peuvent être implémentés conjointement. Autrement dit, une architecture mixte réunissant des unités fonctionnelles et équipements présentés dans le premier mode de réalisation illustré en Figure 1, et des unités fonctionnelles et équipements 20 présentés dans le deuxième mode de réalisation illustré en Figure 2 peut être prévue. Une telle architecture mixte permet la mise en oeuvre du procédé décrit en référence à la Figure 3, et notamment la mise en oeuvre de l'étape S3 selon le premier mode de réalisation illustré en Figure 4 lorsque le transcodage est possible, ou selon le deuxième mode de réalisation illustré en Figure 5 lorsque le transcodage n'est pas possible. 25 L'invention présente plusieurs avantages. Tout d'abord, la localisation physique du système 5 au sein du réseau 9 de zone métropolitaine, au plus près de l'utilisateur final, permet de réduire la charge sur le réseau étendu (en amont) puisque ce dernier transporte un unique flux audio-vidéo F d'un contenu multimédia. Cet unique flux audio-vidéo fait office de référence, pour le système 5, pour en tirer diverses versions du même contenu 30 multimédia. En d'autres termes, une partie du traitement des fichiers multimédia est délocalisé en aval de la plateforme de distribution de sorte que les quantités de données transmises depuis la plateforme de distribution vers les utilisateurs finaux sont réduites. 23 En outre, les capacités de stockage des plateformes de distribution, telles que la plateforme de distribution 3, sont moins sollicitées. Toutes choses égales par ailleurs, le système proposé permet donc de supporter une augmentation du nombre de requêtes clients par rapport aux systèmes existants. Enfin, REVENDICATIONS: 1. Procédé de traitement mis en oeuvre par des moyens informatiques, dans un réseau (9) de zone métropolitaine (MAN), d'un contenu multimédia préalablement encodé numériquement en un flux audio-vidéo (F) et transmis depuis une plateforme de distribution (3) en vue d'une transmission à la demande à une pluralité de terminaux de réception (41, 43), le procédé comprenant les étapes suivantes : - appliquer (S2) une fonction de démultiplexage au flux audio-vidéo, ladite fonction étant agencée pour générer au moins un groupe de flux de données (GR1, GR2, GR3), - appliquer (T2, U1) une transformation (TR1) sur chaque flux de données (F11, F12, F21, F22, F31) de l'au moins un groupe de flux de données, - segmenter (T4, U2) chaque flux de données de l'au moins un groupe de flux de données transformés, - stocker (T6, U4) l'au moins un groupe de flux de données segmentés dans une mémoire (29), le procédé comprenant en outre, seulement en réponse à une requête émise par un terminal de réception (41) parmi la pluralité de terminaux de réception, les étapes suivantes : - sélectionner (S5) en fonction de la requête au moins un flux de données d'au moins un groupe de flux de données stockés, - transmettre (S6) l'au moins un flux de données sélectionné à destination du terminal de réception émetteur de la requête. 2. Procédé selon la revendication 1, dans lequel la fonction de démultiplexage est adaptée pour générer un premier groupe (GR1) de flux de données vidéo, un deuxième groupe (GR2) de flux de données audio et un troisième groupe (GR3) de flux de données de texte et/ou sous-titrage. 3. Procédé selon la revendication 1 ou 2, comprenant en outre les étapes suivantes : - décoder (Ti) les flux de données de l'au moins un groupe de flux de données, préalablement à l'étape d'application de la transformation, - encoder (T3) chaque flux de données de l'au moins un groupe de flux de données, consécutivement à l'étape d'application de la transformation. 4. Procédé selon l'une des revendications précédentes, dans lequel un manifeste comportant des données représentatives des flux de données segmentés est produit (T5, U3) parallèlement ou consécutivement à l'étape de segmentation des flux de données. 5. Procédé selon la revendication 4, dans lequel une partie au moins du manifeste produit est transmis à une partie au moins de la pluralité de terminaux de réception. 25 6. Procédé selon l'une des revendications précédentes, comprenant en outre l'application (U5) d'une transformation supplémentaire (TR2) sur au moins un flux de données segmenté. 7. Procédé selon la revendication 6, dans lequel la transformation supplémentaire inclut un filtrage et/ou une compression de l'au moins un flux de données segmenté. 5 8. Procédé selon la revendication 6 ou 7, dans lequel l'étape de segmentation des flux de données est mise en oeuvre selon un protocole de type HTTP Adaptative Streaming. 9. Procédé selon l'une des revendications précédentes, dans lequel l'au moins un flux de données sélectionné est transmis à destination du terminal de réception via un serveur (7) du réseau de zone métropolitaine (MAN), le serveur étant distant de la plateforme de distribution et de la pluralité de 10 terminaux de réception, et couplé à une mémoire (35), ladite mémoire étant adaptée pour stocker temporairement l'au moins un flux de données transmis. 10. Procédé selon la revendication 8, dans lequel l'au moins un flux de données sélectionné est transmis à destination du terminal de réception via un serveur (7) du réseau de zone métropolitaine (MAN), le serveur étant distant de la plateforme de distribution et de la pluralité de terminaux de 15 réception, et couplé à une mémoire (35), ladite mémoire étant adaptée pour stocker temporairement l'au moins un flux de données transmis, la durée de conservation de l'au moins un flux de données stocké dans la mémoire étant fonction dudit protocole. 11. Procédé selon la revendication 9 ou 10, dans lequel, en réponse à une requête ultérieure à la première et émise par un deuxième terminal de réception (43) parmi la pluralité de terminaux de 20 réception, au moins un flux de données stocké dans la mémoire est transmis audit deuxième terminal de réception. 12. Programme informatique comprenant des instructions pour la mise en oeuvre du procédé selon l'une des revendications précédentes, lorsque lesdites instructions sont exécutées par au moins un processeur (15, 31, 37). 25 13. Système (5) de traitement, dans un réseau (9) de zone métropolitaine (MAN), d'un contenu multimédia, préalablement encodé numériquement en un flux audio-vidéo (F) et transmis au système depuis une plateforme de distribution (3), en vue d'une transmission à la demande à une pluralité de terminaux de réception (41, 43), le système comprenant - - un module de démultiplexage (17) agencé pour appliquer une fonction de démultiplexage au 30 flux audio-vidéo reçu et générer au moins un groupe de flux de données (GR1, GR2, GR3), - une unité de traitement (21) agencée pour appliquer une transformation (TR1) sur chaque flux de données (F11, F12, F21, F22, F31) de l'au moins un groupe de flux de données, 26 - un intégrateur (25) agencé pour segmenter chaque flux de données de l'au moins un groupe de flux de données transformés, - une mémoire (31), couplée à l'intégrateur, adaptée pour stocker l'au moins un groupe de flux de données segmentés, 5 - un module de communication (27) agencé pour réceptionner des requêtes émises par des terminaux de réception, l'intégrateur étant agencé en outre pour sélectionner, uniquement à la réception par le module de communication d'une requête émise par un terminal de réception (41) de la pluralité de terminaux de réception, en fonction de la requête au moins un flux de données d'au moins un groupe de flux de 10 données stockés. 14. Système selon la revendication 13, dans lequel la plateforme de distribution forme une passerelle entre un réseau étendu (\VAN) et le réseau de zone métropolitaine (MAN). 15. Système selon la revendication 13 ou 14, comprenant en outre : - un module de décodage (19) agencé pour décoder les flux de données de l'au moins un groupe 15 de flux de données en sortie du module de démultiplexage, - un module d'encodage (23) adapté pour encoder chaque flux de données de l'au moins un groupe de flux de données en sortie de l'unité de traitement. 16. Système selon l'une des revendications 13 à 15, dans lequel l'unité de traitement ou une unité de traitement supplémentaire (49) du système est agencée pour appliquer une transformation 20 supplémentaire (TR2) sur au moins un flux de données segmenté. 17. Système selon la revendication 16, dans lequel l'unité de traitement ou l'unité de traitement supplémentaire est adaptée pour filtrer et/ou compresser l'au moins un flux de données segmenté.