Brevet FR3034278A1 — publié le 20160930

Procédé et dispositif de fourniture d'un flux de données, procédé et dispositif de traitement d'un flux de données, programmes d'ordinateur et media de stockage correspondants. 1. Domaine de l'invention Le domaine de l'invention est celui de la transmission et de la diffusion numérique de contenus multimédia, notamment de contenus télévisuels, ainsi que la réception de contenus linéaires en mobilité. L'invention s'applique notamment, mais non exclusivement, à des flux multimédia conformes aux normes de diffusion DVB-T ou DVB-T2 (« Digital Video Broadcasting - Terrestrial » en anglais, pour «diffusion vidéo numérique terrestre»), ainsi qu'à la transmission de contenus au sein d'un réseau local sans fil, par exemple conformément aux normes WIFI en vigueur et à venir. 2. Art antérieur Une des problématiques de la réception de contenus linéaires en mobilité réside dans la mise en oeuvre de fonctionnalités de navigation telles que le « retour arrière » ou dans la continuité de service entre plusieurs points d'accès. En effet, un contenu linéaire, par opposition à un contenu non linéaire pour lequel l'utilisateur décide quand il souhaite le consommer (par exemple de la vidéo à la demande, ou du téléchargement), est diffusé au moment choisi et programmé par l'opérateur de diffusion, et n'offre donc aucune « souplesse » en réception, qui s'effectue en temps réel, au fur et à mesure de la diffusion. Par exemple, si l'on considère un système de réception de contenus linéaires en mobilité dans lequel des équipements récepteurs (par exemple installés dans des transports en commun) reçoivent des contenus multimédia en temps réel (par exemple diffusés en Broadcast via la Télévision Numérique Terrestre, ou via un réseau Telecom de type 3G ou 4G), puis les mettent à disposition de terminaux de restitution d'utilisateurs, via un réseau sans fil (par exemple un réseau WIFI), on observe que certaines situations de mobilité peuvent engendrer des dégradations de service pour les utilisateurs, comme par exemple lorsqu'un utilisateur change de point d'accès (par exemple lorsqu'il change de bus). De même, la question se pose des moyens à mettre en oeuvre pour offrir des fonctionnalités de navigation optimales (le retour arrière par exemple) pour l'utilisateur, alors que la consommation du contenu est mise en oeuvre au fur et à mesure de sa diffusion, en temps réel. Pour améliorer la qualité de service à l'utilisateur, il existe aujourd'hui plusieurs solutions permettant de visualiser des contenus linéaires en mobilité, basées par exemple sur des mécanismes propriétaires d'enregistrement de contenus et de navigation dans ces contenus enregistrés. Ces techniques propriétaires permettent par exemple d'offrir aux utilisateurs la fonctionnalité de « retour arrière », ainsi qu'une continuité de services, mais présentent les inconvénients de nécessiter des équipements assurant l'enregistrement des contenus reçus en 3034278 2 vue de la mise à disposition de ces contenus, via des applications de navigation, également propriétaires. Il existe donc un besoin pour une nouvelle technique de fourniture de contenus linéaires en mobilité, qui soit simple à mettre en oeuvre et peu coûteuse, et ne nécessite pas de 5 mécanismes d'enregistrement et de navigation propriétaires. 3. Exposé de l'invention L'invention propose une solution nouvelle qui ne présente pas l'ensemble de ces inconvénients de l'art antérieur, sous la forme d'un procédé de fourniture d'un flux de données destiné à être diffusé dans un réseau de diffusion numérique, le procédé étant mis en oeuvre au 10 sein d'une tête de réseau dudit réseau de diffusion et comprenant les étapes suivantes : - obtention d'au moins un flux multimédia source comprenant au moins un service à diffuser ; - segmentation dudit au moins un flux multimédia source en une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière 15 unique, dits chunks ; - traitement desdits chunks de ladite pluralité, délivrant ledit flux de données apte à être diffusé dans ledit réseau de diffusion. Ainsi, selon ses différents modes de réalisation, l'invention repose sur une approche nouvelle et inventive de la fourniture d'un flux de données pour sa diffusion, en broadcast, dans 20 un réseau de diffusion donné, permettant, en réception (par exemple au sein d'un réseau WIFI local), une restitution optimisée des données du flux diffusé, correspondant à des contenus linéaires. Côté diffusion, l'invention est basée, selon ses différents modes de réalisation, sur : - une segmentation d'un flux multimédia source (par exemple de type MPEG-2 TS), 25 en fichiers multimédia indépendants, de petite taille, appelés chunks, puis - un traitement de « mise en forme » de ces chunks de façon à les diffuser sous forme de données dans un multiplex conforme aux normes du réseau de diffusion. Ainsi, le fait que les données contenues dans le flux diffusé correspondent à une pluralité 30 de fichiers indépendants, contenant chacun un « morceau » de flux source, permet, en réception, une adaptabilité de lecture et de restitution performante pour les contenus linéaires correspondants. En effet, ces fichiers indépendants, ou chunks, peuvent être lus de manière autonome, indépendamment les uns des autres. 3034278 3 En d'autres termes, une restitution, sur un terminal d'un utilisateur, d'un contenu multimédia linéaire, peut commencer à partir de n'importe lequel de ces chunks (qui commence par une image codée en mode dit « intra », ne nécessitant pas la connaissance d'une image préalablement codée) offrant ainsi des fonctionnalités en mobilité telles que la continuité de 5 service, ou le « retour arrière ». La segmentation d'un contenu en une pluralité de chunks est connue plus particulièrement sous le nom « Adaptative Bitrate Streaming », dans le domaine « broadband », c'est-à-dire pour la transmission de données de type client-serveur, afin de fournir (par exemple pour du téléchargement de type HTTP ou FTP), en réponse à une requête d'un utilisateur, un 10 contenu adapté en fonction des capacités du terminal de restitution. Les technologies HLS, DASH et Smooth Streaming sont par exemple basées sur cette technique dite « Adaptative Bitrate Streaming ». En revanche, cette technique de segmentation n'est à ce jour pas utilisée dans le domaine du « broadcast », c'est-à-dire de la diffusion numérique de contenus dans lequel un même flux 15 source est destiné à une pluralité d'utilisateurs, via un site d'émission pouvant être capté par les récepteurs de sa zone de couverture. Dans le cadre de la présente invention, selon les différents modes de réalisation décrits ci- après, cette technique de segmentation s'inscrit dans un système mettant en oeuvre à la fois de la diffusion en Broadcast de flux segmentés et du Wifi local pour l'accès, par les utilisateurs, au 20 contenu multimédia linéaire correspondant à une partie du flux segmenté. Ainsi, l'invention, selon ses différents modes de réalisation, tire partie des avantages des différentes techniques de diffusion broadcast et d'accès à des contenus multimédia, pour optimiser la restitution d'un contenu linéaire sur un terminal utilisateur, en mobilité. Selon un aspect particulier de l'invention, l'étape de traitement comprend les sous-étapes 25 suivantes, pour un nombre n de chunks disponibles à un instant t : - concaténation desdits n chunks disponibles, délivrant un conteneur de chunks ; - ajout d'un entête audit conteneur de chunks, ledit entête comprenant une information représentative de chaque chunk dudit conteneur. Ainsi, selon ce mode de réalisation de l'invention, les chunks obtenus après segmentation 30 du ou des flux source sont mis en forme de manière à pouvoir être diffusés sous la forme de données dans un multiplex conforme aux normes de diffusion du réseau donné. Ce traitement de mise en forme consiste d'abord à concaténer, à un instant t, les n chunks disponibles, pour obtenir un conteneur de chunks, appelé archive, laquelle est ensuite encapsulée 3034278 4 dans un protocole (ajout notamment d'un entête portant, pour chaque chunk, sa taille et l'identifiant de son service). Par exemple, ce traitement consiste à concaténer, toutes les vingt secondes, dix fichiers/chunks par service, de façon à obtenir une archive qui est ensuite encapsulée dans un 5 protocole avant d'être diffusée, sous forme de données, dans le réseau de diffusion. Cette encapsulation permet notamment, en réception, de pouvoir à nouveau obtenir les chunks, ainsi que les services auxquels ils appartiennent, pour pouvoir fournir les contenus multimédia correspondants, grâce notamment aux informations portées par l'entête. Par exemple, l'information représentative comprend la taille dudit chunck et le service 10 auquel il appartient. Selon une caractéristique particulière de l'invention, l'étape d'obtention obtient au moins deux flux multimédia source correspondant à deux services distincts et la sous-étape de concaténation concatène des chunks appartenant auxdits deux services distincts, ledit flux de données délivré correspondant auxdits au moins deux flux multimédia sources multiplexés. 15 Ainsi, selon ce mode de réalisation de l'invention, lorsque plusieurs services sont à diffuser dans le réseau de diffusion, chaque flux multimédia correspondant à chaque service est segmenté en une pluralité de chunks, lesquels sont ensuite concaténés, quelque soit le service auquel ils appartiennent, dans un conteneur qui regroupe donc des chunks appartenant à différents services. Le flux de données diffusé, comportant une pluralité de conteneurs, eux- 20 mêmes portant des chunks appartenant à différents services, correspond donc à un multiplex de services. L'invention concerne également un procédé de traitement d'un flux de données diffusé dans un réseau de diffusion numérique et fourni selon le procédé décrit ci-dessus, le procédé de traitement étant mis en oeuvre dans un équipement de communication connecté audit réseau de 25 diffusion, dit serveur de contenus. Selon les différents modes de réalisation de l'invention, le procédé de traitement délivre un contenu multimédia linéaire accessible via un réseau de communication sans fil auquel est connecté ledit serveur de contenus, et comprend les étapes suivantes, mises en oeuvre en temps réel au fur et à mesure de la réception dudit flux de données : 30 - traitement dudit flux reçu délivrant une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks ; - mémorisation circulaire desdits chunks de ladite pluralité, en fonction d'un critère prédéterminé de mémorisation ; 3034278 5 - mise à jour d'une liste représentative desdits chunks mémorisés à un instant donné. Ainsi, selon ses différents modes de réalisation, l'invention repose sur une approche nouvelle et inventive permettant de bénéficier des fonctionnalités liées à la fourniture, au sein 5 d'un réseau sans fil local, d'un contenu multimédia linéaire sous forme de fichiers indépendants, ce contenu linéaire étant auparavant reçu via un réseau de diffusion en « Broadcast ». Par exemple, le fait que le contenu linéaire soit rendu disponible, au sein d'un réseau local sans fil, sous la forme de fichiers indépendants de petite taille, dits chunks, permet d'offrir à l'utilisateur, en mobilité, les fonctionnalités de continuité de service ou de « retour arrière ». 10 Pour ce faire, l'invention, selon ses différents modes de réalisation, met en oeuvre un traitement particulier d'un flux de données reçu via un réseau de diffusion, ce flux étant construit à partir d'une pluralité de chunks issus de la segmentation d'au moins un flux multimédia source. Ce traitement particulier consiste à obtenir à nouveau cette pluralité de chunks, au fur et à mesure de la réception du flux de données, à mémoriser ces chunks, de manière circulaire, en 15 fonction par exemple d'une profondeur temporelle de mémorisation souhaitée, afin de les rendre accessibles, au sein d'un réseau WIFI local, pour leur restitution par un terminal de communication connecté à ce réseau WIFI. Cette restitution est facilitée notamment par la gestion d'une liste représentative de tous les chunks mémorisés à un instant t, liste mise à jour au fur et à mesure de la réception du flux de 20 données et de la mémorisation des chunks obtenus. Selon un aspect particulier de l'invention, le traitement obtient, pour chaque chunk délivré, au moins une information représentative du service auquel il appartient, et l'étape de mémorisation comprend une sous-étape de répartition de chaque chunk, dans une zone mémoire dédiée, en fonction de ladite information représentative dudit service. 25 Ainsi, selon ce mode de réalisation, les chunks, une fois obtenus, sont répartis en mémoire en fonction du service auquel ils appartiennent, de façon à pouvoir fournir, à un utilisateur, un contenu multimédia linéaire correspondant à ce service, à partir d'un chunk mémorisé. Cette répartition peut être mise en oeuvre grâce à une information présente dans l'entête 30 de l'archive contenant le chunk en question. En effet, cet entête (ajouté, côté diffusion broadcast, au moment de l'encapsulation de l'archive obtenue par concaténation d'une pluralité de chunks pouvant appartenir à différents services source) porte notamment une information représentative de la taille du chunk et une information représentative du service auquel il appartient. 35 Selon une caractéristique particulière de l'invention, le critère prédéterminé de 3034278 6 mémorisation correspond à une profondeur temporelle de mémorisation souhaitée et l'étape de mémorisation met en oeuvre, avant de mémoriser un chunk, une sous-étape d'effacement d'une partie de la mémoire lorsque ladite profondeur temporelle de mémorisation souhaitée est atteinte. 5 Ainsi, selon ce mode de réalisation, le ou les buffers circulaires utilisé(s) pour mémoriser les chunks désencapsulés présente(nt) une profondeur temporelle prédéterminée, de façon à optimiser les performances du serveur de contenus, tout en offrant des fonctionnalités optimales à l'utilisateur lors de la restitution du contenu. Ainsi, par exemple, les performances de la fonctionnalité de « retour arrière » offerte à un 10 utilisateur dépendent de cette profondeur temporelle de mémorisation. L'invention concerne également, côté diffusion, un dispositif de fourniture d'un flux de données destiné à être diffusé dans un réseau de diffusion numérique, ledit dispositif étant mis en oeuvre au sein d'une tête de réseau dudit réseau de diffusion et comprenant : - un module d'obtention d'au moins un flux multimédia source comprenant au moins un 15 service à diffuser ; - un module de segmentation dudit au moins un flux multimédia source en une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks ; - un module de traitement desdits chunks de ladite pluralité, délivrant ledit flux de 20 données apte à être diffusé dans ledit réseau de diffusion. Un tel dispositif de fourniture, situé au niveau d'une tête de réseau, comprend par exemple un module de segmentation (par exemple un codeur de type HLS) et un serveur Push. L'invention concerne également, côté réception, un serveur de contenus apte à mettre en oeuvre un traitement d'un flux de données diffusé dans un réseau de diffusion numérique et 25 fourni par un dispositif tel que décrit ci-dessus. Selon les différents modes de réalisation de l'invention, le serveur de contenus est connecté audit réseau de diffusion et délivre un contenu multimédia linéaire accessible via un réseau de communication sans fil auquel est connecté ledit serveur de contenus. Le serveur de contenus comprend : - un module de traitement dudit flux reçu délivrant une pluralité de fichiers 30 indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks ; - un module de mémorisation circulaire desdits chunks de ladite pluralité, en fonction d'un critère prédéterminé de mémorisation ; - un module de mise à jour d'une liste représentative desdits chunks mémorisés à un instant donné. 35 Par exemple, un tel serveur de contenus est appelé « WIFI media serveur » et permet à 3034278 7 des terminaux, vis des applications préalablement installées, d'accéder à des contenus linéaires via un réseau WIFI. L'invention concerne aussi un programme d'ordinateur pour la mise en oeuvre d'un procédé de fourniture ou d'un procédé de traitement tels que décrits précédemment, selon les 5 différents modes de réalisation de l'invention, lorsque ce programme est exécuté par un processeur. Enfin, l'invention concerne un médium de stockage lisible par ordinateur et non transitoire, stockant un programme d'ordinateur comprenant des instructions exécutables par un processeur pour mettre en oeuvre un procédé de fourniture ou un procédé de traitement tels que 10 décrits précédemment, selon les différents modes de réalisation de l'invention. 4. Liste des figures D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : 15 la figure 1 illustre un exemple de système dans lequel l'invention peut être mise en oeuvre, selon un mode de réalisation particulier ; la figure 2 présente les principales étapes d'un procédé de fourniture d'un flux de données, selon un mode de réalisation particulier de l'invention ; la figure 3 présente les principales étapes d'un procédé de traitement d'un flux de 20 données, selon un mode de réalisation particulier de l'invention ; les figures 4 et 5 illustrent un exemple d'architecture simplifiée respectivement pour un dispositif de fourniture d'un flux de données et pour un serveur de contenus, selon un mode de réalisation de l'invention ; 5. Description d'un mode de réalisation de l'invention 25 5.1 Principe général Le principe général de l'invention repose sur la diffusion, en mode Broadcast, de contenus sous la forme de flux multimédia source segmentés en chunks encapsulés dans un protocole, de façon à optimiser les performances de la navigation dans ces contenus linéaires en mobilité. L'invention, selon ses différents modes de réalisation, est donc basée sur une architecture 30 particulière alliant la diffusion en Broadcast et l'accès à des contenus linéaires au sein d'un réseau sans fil, permettant à la fois de s'affranchir, en réception, de mécanismes d'enregistrement et de navigation propriétaires et de s'affranchir, en transmission, des contraintes liées à l'utilisation d'un réseau Telecom, de façon à faciliter le déploiement de nouveaux services de réception de 3034278 8 contenus linéaires en mobilité. Un exemple d'une telle architecture est illustré en figure 1, comprenant d'une part une structure de diffusion d'un flux de données (composée par exemple d'un module de segmentation, d'un serveur Push et d'un réseau de diffusion) et d'autre part au moins un 5 équipement de réception/rediffusion (noté serveur de contenus) recevant ce flux de données, l'enregistrant et rediffusant les contenus linéaires correspondants via un réseau WIFI. Enfin, des équipements de restitution (des terminaux d'utilisateurs) permettent la restitution de ces contenus linéaires, via des applications installées sur ces terminaux, en se connectant au serveur de contenus via le réseau WIFI local. 10 En particulier, le module de segmentation (par exemple un codeur HLS (pour « HTTP Live Streaming » en anglais)) et le serveur Push se situent au niveau de la tête de réseau du réseau de diffusion Broadcast. Comme décrit plus en détails ci-après, le module de segmentation reçoit en entrée au moins un flux multimédia source comprenant au moins un service (audio-vidéo par exemple), segmente ce flux en une pluralité de petits fichiers indépendants, appelés chunks, et 15 délivre au serveur Push cette pluralité de chunks pour le service donné. Le serveur de Push reçoit donc une pluralité de chunks par service et les encapsule, selon des critères prédéterminés décrits ci-après, pour délivrer un flux de données à diffuser dans le réseau de diffusion. Par exemple, ce réseau de diffusion correspond à un réseau DVB Terrestre. Le flux source reçu par le module de segmentation peut être un flux non encodé et non 20 compressé, comme par exemple un flux de type SDI (en anglais « Serial Digital Interface »), pour une qualité optimale de l'image, ou un flux déjà encodé et compressé, par exemple de type MPEG2-TS (en anglais « Motion Picture Expert Group 2 - Transport Stream »). En réception, le serveur de contenus, à la fois récepteur du flux diffusé dans le réseau de diffusion, et « rediffuseur » au sein d'un réseau WIFI, désencapsule les chunks reçus, les répartit 25 par services le cas échéant (lorsque le flux de données correspond à plusieurs services multiplexés) pour les mémoriser par exemple dans des buffers circulaires de profondeur(s) temporelle(s) prédéterminée(s). Enfin, lorsqu'un utilisateur souhaite accéder à un contenu linéaire à l'aide de son terminal de restitution, ce dernier se connecte au serveur de contenus via le réseau WIFI et permet à 30 l'utilisateur de naviguer dans le contenu, via une application installée sur le terminal. L'invention, selon ses différents modes de réalisation, est donc mise en oeuvre dans différents équipements, côté diffusion et côté réception, comme décrit plus en détails ci-dessous. 5.2 Description d'un mode de réalisation 3034278 9 5.2.1 Diffusion On décrit maintenant, en relation avec la figure 2, les principales étapes du procédé de fourniture d'un flux de données, mises en oeuvre au niveau de la tête de réseau, selon un mode de réalisation particulier. 5 Comme indiqué ci-dessus, plusieurs équipements sont impliqués, au niveau de la tête de réseau du réseau de diffusion, dans la fourniture d'un flux de données. Ces équipements peuvent être considérés par exemple comme des modules d'un dispositif de fourniture d'un flux de données, ou comme des équipements distincts au sein de la tête de réseau. Ainsi, dans un premier temps, un module de segmentation, par exemple un codeur de 10 type HLS, reçoit, lors d'une étape 20 d'obtention, au moins un flux multimédia source pour les N services à diffuser (Service 1 ... Service N). Par exemple, un flux multimédia source est de type MPEG2-TS et correspond à un contenu audio-vidéo, encodé pour la vidéo en H.264 (ou MPEG-4 AVC pour « Advanced Video Coding » en anglais) et pour l'audio en AAC (« Advanced Audio Coding » en anglais), encapsulé 15 dans un flux de transport MPEG2. Selon un autre exemple, un flux multimédia source correspond à un flux de type SDI, correspondant à des images non compressées, de la plus haute qualité du capteur d'acquisition, pouvant ensuite être compressé le cas échéant. Le module de segmentation effectue ensuite, lors d'une étape 21 de segmentation, un 20 découpage de ces flux source reçus en une pluralité de chunks, c'est-à-dire une pluralité de petits fichiers indépendants, de taille (ou durée) fixe et prédéterminée, identifiés chacun de manière unique. Cette segmentation en chunks présente les avantages suivants : - chaque chunk peut être lu de façon autonome, car il commence par une image codée en mode dit « intra », 25 - tous les chunks ont une durée fixe D, paramétrable, - chaque chunk est identifié de façon unique, - à partir d'un même flux source, il est possible de produire en temps réel des chunks correspondant à des débits de lecture différents (i.e. plus ou moins élevés), ce qui permet d'adapter dynamiquement la lecture des contenus aux 30 caractéristiques instantanées du réseau avec lequel on y accède (ici le réseau WIFI) ainsi qu'aux caractéristiques du terminal de restitution utilisé. Selon les technologies connues de segmentation (par exemple HLS, DASH (pour« Dynamic Adoptive Streaming over HTTP » en anglais ou « Smooth Streaming ») basées sur ces principes, ces 3034278 10 chunks peuvent être manipulés comme des fichiers, par exemple pour du téléchargement http ou ftp. En pratique, dans le contexte de la présente invention, un chunk contient par exemple un « morceau » d'un flux MPEG2-TS, pouvant être lu de manière autonome. 5 Une fois les chunks générés, pour chaque service, le module de segmentation les transmet par exemple à un serveur, noté serveur Push, en charge de l'émission du flux de données. Ce serveur Push met alors en oeuvre, lors d'une étape 22 de traitement, un traitement de ces chunks, de manière à délivrer un flux de données F apte à être diffusé via le réseau de 10 diffusion (ce flux de données F correspondant donc à un multiplex des différents services source). Cette étape 22 de traitement consiste à encapsuler un certain nombre de chunks dans des conteneurs, afin d'optimiser la diffusion. Ces conteneurs, encore appelés « archives », sont traités, en réception, comme étant d'un type « data » et non pas identifiés comme un flux vidéo. L'encapsulation est par exemple mise en oeuvre selon le processus suivant : 15 - tous les chunks disponibles à un instant t pour N services sont regroupés dans un conteneur (ou archive), - l'entête de ce conteneur porte notamment un fichier d'index, qui permet de connaître, en réception, pour chaque chunk, sa taille ainsi que l'identifiant du service auquel il appartient. 20 Le flux de données F est donc ensuite diffusé, lors d'une étape non illustrée sur la figure 2, dans le réseau de diffusion (par exemple un réseau DVB-T). Il est à noter que toutes ces étapes sont mises en oeuvre, au niveau de la tête de réseau, de manière à diffuser un flux de données correspondant à des contenus linéaires destinés à être « consommés » en temps réel, dans un réseau sans fil de type WIFI par exemple. 25 5.2.2 Réception On décrit donc ci-après les étapes du procédé de traitement d'un flux de données, mises en oeuvre au niveau d'un équipement récepteur du réseau de diffusion, lequel équipement étant également émetteur (ou ré-émetteur, ou rediffuseur) au sein d'un réseau WIFI. Par exemple, un tel équipement correspond à un serveur de contenus auquel peuvent 30 accéder des terminaux utilisateurs connectés au réseau WIFI. Ce serveur de contenus est donc apte à recevoir le flux de données F diffusé dans le réseau de diffusion, et fourni par le procédé de fourniture de l'invention, selon ses différents modes de réalisation, et met en oeuvre, au fur et à mesure de la réception en temps réel du flux F, 3034278 11 les étapes décrites ci-après. A réception de chaque conteneur (archive) du flux de données F, le serveur de contenus désencapsule le conteneur, lors d'une étape 30 de traitement, afin d'en obtenir les différents chunks le composant. Pour ce faire, le serveur de contenus utilise notamment les informations 5 présentes dans l'entête de chaque conteneur, afin de connaître par exemple la taille de chaque chunk. Ensuite, une étape 31 de mémorisation de chaque chunk reçu est mise en oeuvre par le serveur de contenus, en tenant compte également de l'information portée dans l'entête du conteneur indiquant à quel service chaque chunk appartient. 10 Ainsi, par exemple, une zone de mémorisation dédiée est prévue par service, et le serveur de contenus répartit les chunks d'un conteneur dans les différentes zones de mémorisation correspondantes. Ceci permet ensuite de pouvoir accéder à un contenu multimédia correspondant à un service. Le serveur de contenus met également à jour une liste des chunks mémorisés, lors d'une 15 étape 32, de façon à toujours recenser, à un instant t, les chunks à lire, au fur et à mesure de leur mémorisation. Cette liste est également appelée « manifest ». Selon ce mode de réalisation de l'invention, l'étape 31 de mémorisation consiste à sauvegarder, dans une zone mémoire de type buffer circulaire, chaque chunk reçu, en temps réel, et tient compte d'au moins un paramètre prédéterminé correspondant à une profondeur 20 temporelle de mémorisation souhaitée. Ainsi, un nombre prédéterminé de chunks est disponible à un instant t, et les chunks les plus anciens sont supprimés, au fur et à mesure, pour pouvoir mémoriser les nouveaux chunks reçus. C'est justement cette mémorisation « circulaire » qui permet l'optimisation de la navigation dans les contenus rendus ainsi disponibles, via le serveur de contenus, dans le réseau 25 WIFI, comme décrit ci-après, et la profondeur temporelle est paramétrée par exemple en fonction des fonctionnalités de navigation souhaitées. 5.2.3 Restitution Le serveur de contenus permet donc à des terminaux de restitution (par exemple des smartphones ou des tablettes), via des applications installées sur ces terminaux, d'accéder aux 30 contenus linéaires rendus disponibles, en se connectant au réseau WIFI. Ces applications peuvent ainsi facilement naviguer dans ces contenus grâce à la liste des chunks disponibles à un instant t (le « manifest ») et proposer leur lecture aux utilisateurs. Des fonctionnalités de « retour arrière » et de continuité de service peuvent également être 3034278 12 proposées via ces applications, grâce à l'invention, selon ses différents modes de réalisation. 5.3 Description d'un premier exemple d'application : le « retour arrière » Nous décrivons ci-après un premier exemple d'application de l'invention, dans un contexte de diffusion de contenus linéaires en DVB Terrestre pour leur réception dans des 5 transports en commun. On considère un utilisateur ayant connecté son smartphone sur le réseau Wifi présent dans un transport en commun. Après avoir démarré l'application correspondante, il commence à regarder un contenu linéaire et s'aperçoit qu'il a raté le début du programme en cours. Grâce à l'invention, il peut revenir en arrière jusqu'à trouver le début de l'émission (si la 10 profondeur temporelle paramétrée le permet) et peut redémarrer la lecture du programme à partir de son début (ou du chunk le plus ancien, si la profondeur temporelle paramétrée ne permet pas de revenir au début du programme). Pour ce faire, l'application de lecture installée sur le smartphone de l'utilisateur présente à l'usager une « time-line » qui permet à celui-ci de naviguer temporellement dans un contenu. 15 Lorsque l'usager demande une navigation temporelle de x minutes (un retour en arrière par exemple), l'application, connaissant la durée D d'un chunk, via le fichier « manifest » disponible sur le serveur de contenus, calcule à combien de chunks cela correspond, soit i = x/D. Chaque chunk étant identifié suivant un formalisme connu, l'application est donc capable de calculer l'identifiant « ID » du chunk correspondant à une navigation de i chunks. 20 Elle demande alors le chunk « ID » au serveur de contenus et redémarre la lecture à partir de cet instant-là. Ainsi, l'invention, selon ses différents modes de réalisation, permet une navigation optimale dans des contenus linéaires, en mobilité, sans nécessiter de mécanismes propriétaires d'enregistrement, à partir de flux de données diffusé sous forme de conteneurs de chunks. 25 5.4 Description d'un deuxième exemple d'application : la continuité de service Nous décrivons ci-après un deuxième exemple d'application de l'invention, dans le même contexte de diffusion de contenus linéaires en DVB Terrestre pour leur réception dans des transports en commun, avec un premier serveur de contenus au niveau d'un arrêt de bus, et un deuxième serveur de contenus dans un bus. 30 Un utilisateur attend son bus à un arrêt de bus qui offre la rediffusion de contenus en WIFI, via un premier serveur de contenus connecté à un premier réseau WIFI. Après avoir connecté son smartphone à ce premier réseau WIFI, et démarré l'application correspondante, l'utilisateur commence à regarder un programme. Lorsque son bus arrive, l'utilisateur appuie par 3034278 13 exemple sur le bouton « Pause » de l'application, de façon à monter dans le bus, s'installer à sa place et redémarrer la lecture de son programme en appuyant sur le bouton « Lecture », sans avoir « raté » une partie du programme. L'invention permet, selon ses différents modes de réalisation, d'offrir une continuité de 5 service à l'utilisateur, en n'interrompant pas la lecture du programme alors que son smartphone change de point d'accès WIFI (et donc de serveur de contenus) lorsque l'utilisateur monte dans le bus, ou lorsque le bus s'éloigne de l'arrêt. Pour ce faire, le processus suivant est mis en oeuvre : - un retard T par rapport au temps réel, est introduit volontairement par tous les 10 serveurs de contenus (par exemple, pour un retard souhaité de durée T secondes, on calcule le nombre N de chunks auquel cela correspond avec la formule : N=7-1« durée d'un chunk ». Il suffit alors d'envoyer comme premier chunk à l'application de lecture, le chunk n° (x-N). Tous les chunks entre (x-N) et x servent alors de buffer tampon, 15 - avant de commencer la lecture, l'application installée sur le smartphone de l'utilisateur télécharge, à partir du premier serveur de contenus (au niveau de l'arrêt de bus), un certain nombre de chunks afin de se constituer un buffer propre (sur le terminal de restitution donc), puis elle commence la lecture de ce buffer. A tout moment l'application connait l'identifiant « ID » du chunk qu'elle 20 est en train de lire, grâce notamment au fichier « manifest » disponible sur le premier serveur de contenus. Cette identification des chunks ayant été mise en oeuvre au niveau de la tête de réseau, elle est identique pour tous les serveurs de contenus, - lorsque l'utilisateur se déplace d'un point d'accès Wifi à un autre, il suffit à 25 l'application de demander au nouveau point d'accès (c'est-à-dire dans cet exemple au deuxième serveur de contenus) l'identifiant « 0+1 » du chunk suivant celui qu'elle est en train de lire, - cependant, lorsque le smartphone de l'utilisateur change de réseau Wifi, il y a un laps de temps pendant lequel il n'est plus connecté au premier réseau Wifi et 30 n'est pas encore connecté au second réseau WIFI. Pour pouvoir offrir la continuité de service, l'application consomme alors les chunks contenu dans son propre buffer en attendant d'être connecté au second réseau WIFI et de demander la suite des chunks au deuxième serveur de contenus. 3034278 14 Ce service peut également être offert même si l'utilisateur n'appuie pas sur le bouton « Pause » de son application, et dans ce cas, la lecture continue (pendant qu'il monte dans le bus et s'installe à sa place) et n'est pas interrompue pendant la montée de l'usager dans le bus. 5.5 Architecture simplifiée d'un dispositif de fourniture et d'un serveur de contenus 5 On présente finalement, en relation avec les figures 4 et 5, des exemples de la structure simplifiée d'un dispositif de fourniture au sein d'une tête de réseau et d'un serveur de contenus, mettant en oeuvre respectivement une technique de fourniture d'un flux de données et une technique de traitement de ce flux de donnée, selon un mode de réalisation décrit ci-dessus. Ces figures 4 et 5 illustrent seulement une manière particulière, parmi plusieurs possibles, de réaliser 10 les différents modes de réalisation détaillés ci-dessus. Le dispositif de fourniture 400, illustré en figure 4, comprend une mémoire RAM 40, une unité de traitement 41, équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire ROM 42, mettant en oeuvre le procédé de fourniture d'un flux de données selon un mode de réalisation de l'invention. 15 A l'initialisation, les instructions de code du programme d'ordinateur 42 sont par exemple chargées dans la mémoire RAM 40 avant d'être exécutées par le processeur de l'unité de traitement 41. L'unité de traitement 41 reçoit en entrée au moins un flux multimédia source (par exemple de type MPEG2-TS ou SDI) comprenant au moins un service à diffuser Service 1 ... Service N. Le processeur de l'unité de traitement 41 met en oeuvre les étapes du procédé de fourniture 20 d'un flux de données décrit précédemment, selon les instructions du programme d'ordinateur 42, pour délivrer ledit flux de données apte à être diffusé dans ledit réseau de diffusion. Pour cela, le dispositif de fourniture 400 comprend, outre la mémoire 40, un module d'obtention d'au moins un flux multimédia source (par exemple de type MPEG2-TS ou SDI) comprenant au moins un service à diffuser, un module de segmentation (par exemple un codeur de type HLS) dudit au 25 moins un flux multimédia source en une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks, un module de traitement (par exemple un serveur Push) desdits chunks de ladite pluralité, délivrant ledit flux de données apte à être diffusé dans ledit réseau de diffusion. Ces modules sont pilotés par le processeur de l'unité de traitement 41. Ce dispositif de fourniture 400 est mis en oeuvre au niveau d'une tête de réseau 30 d'un réseau de diffusion numérique. Le serveur de contenus 500, illustré en figure 5, comprend une mémoire RAM 50, une unité de traitement 51, équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire ROM 52, mettant en oeuvre le procédé de traitement 3034278 15 selon un mode de réalisation de l'invention. A l'initialisation, les instructions de code du programme d'ordinateur 52 sont par exemple chargées dans la mémoire RAM 50 avant d'être exécutées par le processeur de l'unité de traitement 51. L'unité de traitement 51 reçoit en entrée un flux de données diffusé dans un 5 réseau de diffusion numérique et fourni par un dispositif de fourniture tel que décrit précédemment en relation avec la figure 4. Le processeur de l'unité de traitement 51 met en oeuvre les étapes du procédé de traitement décrit précédemment, selon les instructions du programme d'ordinateur 52, pour délivrer un contenu multimédia linéaire accessible via un réseau de communication sans fil auquel est connecté ledit serveur de contenus. Pour cela, le 10 serveur de contenus comprend, outre la mémoire 50, un module de traitement dudit flux reçu délivrant une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks, un module de mémorisation circulaire desdits chunks de ladite pluralité, en fonction d'un critère prédéterminé de mémorisation, un module de mise à jour d'une liste représentative desdits chunks mémorisés à un instant donné. Ces modules sont pilotés par le 15 processeur de l'unité de traitement 51. REVENDICATIONS1. Procédé de fourniture d'un flux de données destiné à être diffusé dans un réseau de diffusion numérique, ledit procédé étant mis en oeuvre au sein d'une tête de réseau dudit réseau de diffusion et comprenant les étapes suivantes : - obtention (20) d'au moins un flux multimédia source comprenant au moins un service à diffuser ; - segmentation (21) dudit au moins un flux multimédia source en une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks ; - traitement (22) desdits chunks de ladite pluralité, délivrant ledit flux de données apte à être diffusé dans ledit réseau de diffusion. 2. Procédé de fourniture d'un flux de données selon la revendication 1, caractérisé en ce que ladite étape de traitement comprend les sous-étapes suivantes, pour un nombre n de chunks disponibles à un instant t : - concaténation desdits n chunks disponibles, délivrant un conteneur de chunks ; - ajout d'un entête audit conteneur de chunks, ledit entête comprenant une information représentative de chaque chunk dudit conteneur. 3. Procédé de fourniture d'un flux de données selon la revendication 2, caractérisé en ce que ladite information représentative comprend la taille dudit chunck et le service auquel il appartient. 4. Procédé de fourniture d'un flux multimédia selon la revendication 2, caractérisé en ce que ladite étape d'obtention obtient au moins deux flux multimédia source correspondant à deux services distincts et ladite sous-étape de concaténation concatène des chunks appartenant auxdits deux services distincts, ledit flux de données délivré correspondant auxdits au moins deux flux multimédia sources multiplexés. 5. Procédé de traitement d'un flux de données diffusé dans un réseau de diffusion numérique et fourni selon le procédé des revendications 1 à 4, ledit procédé de traitement étant mis en oeuvre dans un équipement de communication connecté audit réseau de diffusion, dit serveur de contenus, ledit procédé de traitement délivrant un contenu multimédia linéaire accessible via un réseau de communication sans fil auquel est connecté ledit serveur de contenus, ledit procédé de traitement comprenant les étapes suivantes, mises en oeuvre en 3034278 17 temps réel au fur et à mesure de la réception dudit flux de données : - traitement (30) dudit flux reçu délivrant une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks ; - mémorisation circulaire (31) desdits chunks de ladite pluralité, en fonction d'un critère 5 prédéterminé de mémorisation ; - mise à jour (32) d'une liste représentative desdits chunks mémorisés à un instant donné. 6. Procédé de traitement selon la revendication 5, caractérisé en ce que ledit traitement 10 obtient, pour chaque chunk délivré, au moins une information représentative du service auquel il appartient, et en ce que ladite étape de mémorisation comprend une sous-étape de répartition de chaque chunk, dans une zone mémoire dédiée, en fonction de ladite information représentative dudit service. 15 7. Procédé de traitement selon les revendications 5 et 6, caractérisé en ce que ledit critère prédéterminé de mémorisation correspond à une profondeur temporelle de mémorisation souhaitée et en ce que ladite étape de mémorisation met en oeuvre, avant de mémoriser un chunk, une sous-étape d'effacement d'une partie de la mémoire lorsque ladite profondeur temporelle de mémorisation souhaitée est atteinte. 20 8. Dispositif de fourniture d'un flux de données destiné à être diffusé dans un réseau de diffusion numérique, ledit dispositif étant mis en oeuvre au sein d'une tête de réseau dudit réseau de diffusion et comprenant : - un module d'obtention d'au moins un flux multimédia source comprenant au moins un 25 service à diffuser ; - un module de segmentation dudit au moins un flux multimédia source en une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks ; - un module de traitement desdits chunks de ladite pluralité, délivrant ledit flux de 30 données apte à être diffusé dans ledit réseau de diffusion. 9. Serveur de contenus apte à mettre en oeuvre un traitement d'un flux de données diffusé dans un réseau de diffusion numérique et fourni par un dispositif selon la revendication 8, ledit serveur de contenus étant connecté audit réseau de diffusion et délivrant un contenu multimédia linéaire accessible via un réseau de communication sans fil auquel est connecté 3034278 18 ledit serveur de contenus, ledit serveur de contenus comprenant : - un module de traitement dudit flux reçu délivrant une pluralité de fichiers indépendants de durée fixe paramétrable et identifiés de manière unique, dits chunks ; - un module de mémorisation circulaire desdits chunks de ladite pluralité, en fonction 5 d'un critère prédéterminé de mémorisation ; - un module de mise à jour d'une liste représentative desdits chunks mémorisés à un instant donné. 10. Programme d'ordinateur pour la mise en oeuvre d'un procédé de fourniture selon l'une 10 quelconque des revendications 1 à 4 ou d'un procédé de traitement selon l'une quelconque des revendications 5 à 7 lorsque ce programme est exécuté par un processeur. 11. Médium de stockage lisible par ordinateur et non transitoire, stockant un programme d'ordinateur comprenant des instructions exécutables par un processeur pour mettre en 15 oeuvre un procédé de fourniture selon l'une quelconque des revendications 1 à 4 ou un procédé de traitement selon l'une quelconque des revendications 5 à 7.