TITRE : Procédé de transmission d'un contenu audio dans un récepteur hybride en recevant des manifestes émis par un serveur manageur, récepteur et serveur manageur associé

DOMAINE TECHNIQUE

Le domaine de l'invention est celui de la réception d'un contenu audio ou audiovisuel dans un récepteur hybride capable de recevoir à la fois des contenus d'un réseau de diffusion et d'un réseau bidirectionnel. L'invention concerne plus particulièrement le fait de recevoir en différé des parties d'une émission audio qui a préalablement été diffusée sur un canal radio en se connectant à un serveur dédié.

ART ANTERIEUR

Il est connu des stations radio émettant des contenus audio dans un canal fréquentiel donné. Cette source radio dispose généralement d'un site permettant de recevoir en streaming des contenus audio sous la forme de fichier de paquet de données. Il est également connu que la diffusion des documents numériques peut s'effectuer par des réseaux de diffusion de télévision numérique, comme les réseaux TNT, mettant en oeuvre la norme DVB-T2 ("Digital Video Broadcasting - Terrestrial" pour "diffusion vidéo numérique terrestre"). La diffusion de paquets de données est spécifiée par des standards de façon à pouvoir être reçu par un grand nombre de récepteurs de tout type. Dans le domaine de la diffusion de contenus audio, il est également connu des récepteurs dits « hybrides » capables de recevoir des contenus et de reproduire à la fois des émissions en provenance d'un réseau de diffusion, des contenus transmis à partir d'un site, et des contenus transmis en baladodiffusion ou « podcast » selon la terminologie anglo-saxonne. Ces récepteurs sont dotés d'une interface utilisateur comportant un écran et un clavier, des moyens de réception radio et des moyens d'émission de signaux sonores vers des haut-parleurs. L'utilisateur règle son appareil pour recevoir un contenu diffusé à la radio, ou en provenance d'un site Internet.

Certains appareils hybrides peuvent enrichir la réception de contenus audio diffusés par une connexion de type Internet ou « IP », par exemple en améliorant la zone de couverture des contenus diffusés en combinant leurs réceptions traditionnelles par réseau de diffusion selon les normes de diffusion suivantes (liste non limitatives) :

- FM (Fréquence Modulée) ou AM (modulation d'amplitude),

- DAB (acronyme de « Digital Audio Broadcasting »), DAB+, - DMB,

- DRM, DRM+,

- DVB (acronyme de « Digital Audio Broadcasting »), DVB-T, DVB-S, avec des téléchargements ou « streaming » selon la terminologie anglo-saxonne par réseau IP (Wifi, 3G, 4G).

Si les documents numériques sont de type audio et/ou vidéo, alors ils sont

généralement encodés selon le standard MPEG, puis un serveur les reçoit en provenance d'une ou plusieurs sources et planifie la diffusion en temps réel des contenus sous forme numérique. Dans le même temps, un serveur crée une succession de paquets de données numériques (ou « chunk » - cette appellation sera ensuite utilisée dans le reste du document) permettant à des récepteurs numériques de les télécharger (en « streaming » par exemple) et de pouvoir accéder en différé à ces contenus. La durée d'un chunk varie typiquement de 2 à 10 secondes. Les techniques de segmentation sont connues en soi, on peut citer par exemple les technologies HLS,

DASH ou encore, Smooth Streaming. Chaque chunk dispose d'une structure de données de fichier contenant au moins une charge utile (par exemple, les données audio et /ou vidéo, avec les données synchronisant leur reproduction, par exemple des marqueurs temporels ou « timestamps » en langue anglo-saxonne), une référence permettant de les identifier, et éventuellement, un identifiant de la source (typiquement l'identifiant d'une chaîne de diffusion).

La reproduction sur un récepteur d'un contenu peut intervenir soit à cause d'une action de l'utilisateur, soit par un événement affectant les bonnes conditions de la réception. Cet événement peut par exemple être le fait que le récepteur est un ordiphone (ou « smartphone » selon la terminologie anglo-saxonne) et qu'à un certain moment, un appel est passé interrompant la reproduction du document audio. Dans un autre contexte, le récepteur peut être déplacé dans une zone sans porteuse radio et ne peut donc plus recevoir l'émission radio sélectionnée par l'utilisateur (c'est le cas par exemple d'un autoradio lorsque le véhicule passe dans un tunnel). Dans de tel cas, l'utilisateur peut avoir envie de reprendre la reproduction au moment où celle-ci s'est arrêtée et donc écouter en différé l'émission choisie.

Une première solution consiste en ce que le récepteur continue à recevoir le contenu pendant l'interruption et l'enregistre dans une mémoire gérée circulairement. Lors de la reprise, l'appareil lit sa mémoire au moment de l'interruption et reproduit le contenu en différé. Ce système nécessite une mémoire locale de taille suffisante et, de toute façon, ne convient pas pour des événements qui ont empêché de recevoir correctement le contenu. Une autre façon de poursuivre la reproduction d'un contenu à un moment où il a été interrompu, consiste à se connecter à un site permettant de télécharger la partie restante. L'appareil télécharge et enregistre une partie au moins du contenu et, en utilisant une interface utilisateur, l'utilisateur peut avancer rapidement et ainsi passer par dessus des moments qui ont déjà être reproduits.

Les sources de contenus, comme par exemple les stations radios, disposent de serveurs dit CDN (acronyme de « Content Delivery Network », selon la terminologie anglo- saxonne) permettant de transmettre des parties de contenus audio. Ces paquets de contenus audio sont référencés dans une structure de données appelées « manifeste », un manifeste référence plusieurs paquets de données correspondant à des chunks dont les contenus audio se suivent. La création d'un nouveau chunk déclenche la mise à jour du manifeste courant (ou « Live » selon la terminologie anglo-saxonne) par le CDN, qui produit ainsi une succession de manifestes concomitamment à la diffusion du contenu. Lorsqu'un récepteur hybride veut recevoir un contenu qui a été diffusé à un certain moment du passé, il demande au serveur dédié à la source radio de lui transmettre le manifeste dont le premier chunk référencé est celui créé à ce moment déterminé. Suite à la réception du manifeste, le récepteur en extrait la référence des chunks,

typiquement une adresse URL, et peut alors télécharger la partie audio correspondante et la reproduire.

Mais, le serveur dédié ne sauvegarde pas tous les manifestes qu'il crée au fur et à mesure de la diffusion du contenu, mais seulement le dernier : le manifeste Live. De ce fait, en s'adressant à ce serveur dédié, un récepteur hybride ne peut récupérer qu'un nombre restreint de manifestes et ne peut donc avoir accès qu'aux derniers paquets de données diffusés. Si le récepteur souhaite revenir sur un contenu diffusé il y a peu de temps, le serveur dédié a déjà effacé les manifestes qui référencent les chunks correspondants et ne pourra donc pas le transmettre au récepteur. C'est d'autant plus dommage que le serveur dédié garde en mémoire les différents chunks pendant un certain temps, même si le manifeste les référençant a été effacé. De cette manière, il serait encore possible de récupérer des paquets de données d'un contenu audio diffusé il y a un certain temps. Un des buts de la présente invention est la possibilité de récupérer une partie au moins d'un contenu audio préalablement diffusé, bien que le manifeste permettant de référencer cette partie audio ne soit plus disponible au niveau du serveur dédié à cette source de contenus.

Un autre but de la présente invention est de pouvoir facilement informer un récepteur hybride de la disponibilité ou non d'une partie d'un contenu audio en fonction de sa source et de son moment de sa diffusion.

Il existe un besoin d'une telle technique, qui permette de palier à la disparition prématurée des manifestes au niveau des serveurs dédié à des sources radio.

Il existe également un besoin de mettre à la disposition des utilisateurs des moyens permettant de recréer des manifestes qui ont été supprimés et qui référencent des contenus audio qui sont toujours disponibles sur le serveur de la source radio.

EXPOSE DE L'INVENTION

L'invention répond à ce besoin en proposant un procédé de transmission d'un contenu audio dans un récepteur hybride en vue d'une reproduction en différé, ledit contenu étant diffusé en temps réel sur un canal radio déterminé, les paquets de données dudit contenu étant disponibles en différé en se connectant à un serveur dédié (CDN), le procédé comprenant au moins les étapes suivantes :

- émission par un serveur dit « Manager » à ce serveur dédié (CDN) d'une pluralité de requêtes pour recevoir un manifeste identifiant une succession d'un nombre déterminé de paquets de données dont celui contenant l'audio diffusé en temps réel sur le canal radio déterminé,

- mémorisation dans le serveur Manager de la pluralité de manifestes émis par le serveur dédié, les manifestes mémorisés étant datés par le moment d'émission du plus récent paquet de données diffusées sur le canal radio déterminé,

- transmission par le récepteur hybride au serveur Manager d'une requête pour recevoir la partie au moins du contenu diffusée à partir d'un moment déterminé,

- recherche par le serveur Manager dans les manifestes mémorisés des références des paquets de données correspondant à la partie de contenu diffusé à partir du moment déterminé et émission vers le récepteur hybride d'un manifeste référençant l'ensemble de ces paquets de données,

- émission par le récepteur hybride au serveur dédié (CDN) d'une requête pour recevoir les paquets de données référencées dans le manifeste transmis par le serveur Manager. Selon un premier mode de réalisation les requêtes émises par le serveur Manager au serveur dédié (CDN) pour recevoir un nouveau manifeste sont émises à des intervalles de temps régulier, dont la durée est inférieure à la durée de reproduction du contenu audio d'un paquet de données.

Selon un autre mode de réalisation, le procédé de transmission comporte une étape d'émission vers le serveur dédié d'une requête pour recevoir un paquet de données diffusé à un moment déterminé, une réponse émise par le serveur dédié indiquant une absence de disponibilité de ce paquet déclenchant l'effacement au sein du serveur Manager des manifestes ayant les références de ce paquet de données, ainsi que les références des paquets de données dont le contenu audio a été diffusé avant celui du paquet référencé dans la requête.

Selon un autre mode de réalisation, les manifestes mémorisés dans le serveur Manager sont gérés circulairement, les plus anciens étant effacés par les plus récents.

Selon un autre mode de réalisation, l'étape de recherche dans la mémoire circulaire s'arrête jusqu'à un nombre déterminé de manifestes les plus anciens qui sont considérés inaccessibles.

Selon un autre mode de réalisation, le procédé de transmission comporte une étape d'association au sein du serveur Manager de chaque paquet de donnée référencé par un manifeste et du moment de la diffusion de ce paquet de donnée sur le canal radio déterminé, le serveur Manager émettant les références d'un paquet de données à la suite de la réception d'une requête mentionnant ce canal radio déterminé et du moment de sa diffusion.

Selon un autre mode de réalisation, le procédé de transmission comporte une étape de renumérotation des manifestes reçus du serveur dédié, pour toujours attribuer la valeur « 1 » au dernier manifeste et en numérotant successivement les autres jusqu'au plus ancien manifeste reçu et présent en mémoire.

Selon un autre mode de réalisation, lorsque la recherche n'a pas permis de trouver un manifeste référençant des paquets de données correspondant à la partie de contenu diffusé à partir du moment déterminé, alors la recherche continue en recherchant un manifeste référençant des paquets de données dont le contenu a été diffusé avant le moment déterminé.

Selon un autre aspect, l'invention concerne un serveur de données comportant des moyens de communication avec au moins un serveur (CDN) dédié à la diffusion d'un canal radio déterminé et au moins un récepteur hybride, et des moyens de

mémorisation capable d'enregistrer au moins un manifeste identifiant une succession d'un nombre déterminé de paquets de données dont celui contenant l'audio diffusé en temps réel sur le canal radio déterminé. Le moyen de communication transmet vers ce serveur dédié (CDN) une pluralité de requêtes pour recevoir un manifeste identifiant les paquets de données contenant l'audio diffusé en temps réel sur le canal radio déterminé, le moyen de mémorisation enregistrant la pluralité de manifestes émis par le serveur dédié en les datant par le moment d'émission du plus récent paquet de données diffusées sur le canal radio déterminé, le moyen de communication recevant du récepteur hybride au moins une requête pour recevoir la partie au moins du contenu diffusée à partir d'un moment déterminé, le serveur manager disposant d'un moyen de recherche dans les manifestes mémorisés des références des paquets de données correspondant à la partie de contenu diffusé à partir du moment déterminé et le moyen de communication transmettant vers le récepteur hybride d'un manifeste référençant l'ensemble de ces paquets de données.

Selon un autre aspect, l'invention concerne un système de transmission comprenant un récepteur hybride et un serveur Manager, le récepteur hybride comportant des moyens de réception d'un contenu diffusé en temps réel sur un canal radio déterminé, des moyens de communication avec au moins un serveur (CDN) dédié à la diffusion de ce canal radio déterminé et au moins le serveur Manager, un moyen de reproduction du contenu audio reproduisant en temps réel le contenu audio reçu du canal radio déterminé, et un moyen de mémorisation du moment de l'interruption de la reproduction du contenu, tel qu'au moment de la reprise de la reproduction du contenu interrompu, le moyen de communication émet vers le serveur Manager une requête pour recevoir la partie au moins du contenu diffusée à partir d'un moment mémorisé, le moyen de communication recevant du serveur Manager un manifeste identifiant une succession d'un nombre déterminé de paquets de données dont celui contenant l'audio diffusé au moment déterminé, le moyen de communication émettant vers le serveur dédié (CDN) une requête pour recevoir les paquets de données référencées dans le manifeste transmis par le serveur Manager, les paquets de données reçus étant reproduit à la réception ; le serveur Manager comportant des moyens de communication avec au moins un serveur (CDN) dédié à la diffusion d'un canal radio déterminé et au moins un récepteur hybride, et des moyens de mémorisation capable d'enregistrer au moins un manifeste identifiant une succession d'un nombre déterminé de paquets de données dont celui contenant l'audio diffusé en temps réel sur le canal radio déterminé, tel que le moyen de communication 24 transmet à ce serveur dédié (CDN) une pluralité de requêtes pour recevoir un manifeste identifiant les paquets de données contenant l'audio diffusé en temps réel sur le canal radio déterminé, le moyen de mémorisation enregistrant la pluralité de manifestes émis par le serveur dédié en les datant par le moment d'émission du plus récent paquet de données diffusées sur le canal radio déterminé, le moyen de communication 24 recevant du récepteur hybride au moins une requête pour recevoir la partie au moins du contenu diffusée à partir d'un moment déterminé, le serveur manager disposant d'un moyen de recherche dans les manifestes mémorisés des références des paquets de données correspondant à la partie de contenu diffusé à partir du moment déterminé et le moyen de communication 24 transmettant vers le récepteur hybride d'un manifeste référençant l'ensemble de ces paquets de données.

Selon un autre aspect, l'invention concerne un produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé tel que décrit dans les paragraphes ci-dessus, lorsque ledit programme est exécuté sur un ordinateur.

PRESENTATION DES FIGURES

D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :

[Fig 1] : présente une architecture générale d'un système de diffusion de contenus permettant à des récepteurs hybrides de recevoir et de reproduire en différé des contenus, selon un mode particulier de réalisation de l'invention;

[Fig 2] : présente un exemple d'ordinogramme des principales étapes du procédé de transmission en différé d'une partie au moins d'un contenu audio, qui a été préalablement diffusé ;

[Fig 3] : présente un schéma montrant la présence des manifestes et des chunks au sein des différents serveurs ;

[Fig 4] : représente un schéma d'un appareil récepteur hybride, selon un mode de réalisation particulier de l'invention ;

[Fig 5] : illustre les principaux composants d'un serveur distant selon un exemple de réalisation.

DESCRIPTION DETAILLEE DE L'INVENTION

Sur toutes les figures du présent document, les éléments identiques sont désignés par une même référence.

Principe général.

L'invention concerne un procédé de transmission d'un contenu audio dans un récepteur hybride en vue d'une reproduction en différé, ce contenu étant diffusé en temps réel sur un canal radio déterminé, et les paquets de données étant disponibles en différé en se connectant à un serveur dédié (CDN). Dans un premier temps, un serveur dit

« Manager » émet à ce serveur dédié des requêtes pour recevoir un manifeste identifiant une succession d'un nombre déterminé de paquets de données dont celui contenant l'audio diffusé en temps réel sur le canal radio déterminé. Le serveur Manager enregistre les manifestes émis par le serveur dédié en les datant par le moment d'émission du plus récent paquet de données diffusées sur le canal radio déterminé. Un récepteur hybride demande au serveur Manager de recevoir une partie d'un contenu diffusé à partir d'un moment déterminé. Le serveur Manager recherche alors dans les manifestes mémorisés des références des paquets de données correspondant à la partie de contenu diffusé à partir du moment déterminé et émet vers le récepteur hybride un manifeste référençant l'ensemble de ces paquets de données. Le récepteur hybride envoie alors au serveur dédié (CDN) une requête pour recevoir les paquets de données référencées dans ce manifeste.

Description d'un mode particulier de réalisation

Sur toutes les figures du présent document, les éléments (ou les étapes) identiques sont désignées par une même référence numérique.

On présente maintenant, en relation avec la Fig. 1, une architecture générale d'un système de diffusion de contenus audio permettant à des récepteurs hybrides de recevoir et de reproduire en différé des contenus, selon un mode particulier de réalisation de l'invention.

Une source radio 1, appelée « studio radio » produit un flux audio correspondant à un contenu tel que : musique, journal, émission culturelle, feuilleton, ... Cette source radio émet sur des ondes radio le contenu à diffuser de façon que des récepteurs puissent les capter et les reproduire en temps réel. Ces récepteurs 2 sont dit « hybrides » par le fait qu'ils peuvent recevoir des émissions radio sur un canal de diffusion et reproduire le contenu, et qu'ils ont également les moyens de se connecter par une liaison bidirectionnelle avec un serveur pour lui demander de transmettre des paquets de données représentant un contenu audio. Au sein de la source radio 1, ses signaux audio sont codés par un codeur 3 et mis dans des paquets de données appelés « chunk ». Une fois produit, chaque chunk est envoyé à un serveur 4 dit « CDN », qui est un serveur dédié à une source de contenus particulière. Ce serveur CDN gère la transmission des chunks aux récepteurs hybrides 2 dans le contexte du streaming ou du podcast. La gestion des chunks s'effectue à l'aide d'un manifeste qui est une structure de données identifiant plusieurs chunks, ces derniers correspondent à des contenus audio qui se suivent. Dès qu'un nouveau chunk est créé à un instant T0, un nouveau manifeste est créé qui contient les références des trois chunk suivants :

- le chunk émis par la source à T0,

- le chunk émis par la source à T0-At ,

- le chunk émis par la source à T0 - (2xAt),

où At est la durée de reproduction du contenu audio d'un chunk, par exemple 6 secondes, ou 10 secondes. Il est bien évident que le chiffre « trois » n'est donné qu'à titre d'exemple et que le nombre de chunks référencés dans un manifeste peut varier dans le cadre de l'invention. Le manifeste référence également un numéro de session qui identifie la source radio, et qui spécifie un format (HLS ou DASH, par exemple). Lorsqu'un récepteur hybride veut recevoir un contenu qui a été diffusé précédemment, il demande au serveur CDN 4 de cette source radio 1 de lui transmettre le manifeste dont le premier chunk référencé est celui créé à ce moment déterminé, la charge utile de ce chunk étant le contenu audio qui a été diffusé à ce moment. Suite à la réception du manifeste, le récepteur en extrait les références des trois chunks, typiquement des adresses URL. Le récepteur peut alors les télécharger du serveur CDN 4, et les reproduire.

Mais les serveurs CDN 4 ne gardent en mémoire qu'un nombre restreint de manifestes, l'apparition d'un nouveau manifeste déclenchant l'effacement du plus ancien dans la mémoire du serveur CDN. Les serveurs CDN sauvegardent les chunks plus longtemps que les manifestes. Pour palier à la disparition prématurée des manifestes, la présente invention prévoit la configuration d'un serveur 5 dit « Manager » qui reçoit au fil du temps des manifestes en provenance des serveur CDN et les enregistre dans une mémoire 6, typiquement un disque dur. La capacité de stockage étant plus grande, le serveur Manager maintient dans sa mémoire 6 plus de manifestes qu'un serveur CDN.

La Fig. 2 présente un ordinogramme des principales étapes du procédé de transmission en différé d'une partie au moins d'un contenu audio, quia été préalablement diffusé. A l'étape 2.1, le serveur Manager 5 émet vers le serveur CDN 4 une pluralité de requêtes pour recevoir un manifeste. Avantageusement, les requêtes sont émises

périodiquement vers le serveur dédié CDN pour guetter la présence d'un nouveau manifeste, ces requêtes étant émises à des intervalles de temps réguliers, dont la durée est inférieure à la durée de reproduction d'un chunk. De cette façon, le serveur Manager ne peut manquer l'apparition d'un nouveau manifeste référençant un nouveau chunk. Typiquement, le serveur Manager interroge le serveur CDN toutes les 50 millisecondes et guette ainsi l'apparition d'un nouveau manifeste. La précision de la datation d'un manifeste (et donc de chaque nouveau chunk) correspond à la période d'interrogation du serveur CDN dédié à une source radio.

Suite à la découverte d'un nouveau manifeste, le serveur Manager l'analyse et en extrait les identifiants des chunks. Le serveur Manager met ensuite à jour dans une mémoire 7 un tableau associant chaque chunk émis par une même source radio, les références du manifeste dont ce chunk est le premier élément et le moment de la diffusion de ce chunk, c'est à dire le moment où le contenu audio de ce chunk est diffusé par radio (étape 2.2). Le serveur Manager liste ainsi un historique de l'ensemble des manifestes émis par un serveur CDN 4 donné. De cette manière, le serveur Manager peut retransmettre à un récepteur qui en fait la demande, un manifeste qui a été auparavant émis par un serveur CDN et qui a été ensuite effacé. En utilisant son historique, le serveur Manager est capable d'associer chaque chunk avec le moment où son contenu audio a été diffusé par la source radio.

Lors de l'étape 2.3, un récepteur hybride 2 souhaite reprendre la reproduction d'un contenu audio interrompu. Il émet pour cela au serveur Manager une requête pour recevoir la partie au moins du contenu diffusée à partir d'un moment déterminé. Le serveur Manager 5 recherche alors dans les manifestes mémorisés des références des paquets de données correspondant à la partie de contenu diffusé à partir du moment déterminé et émet vers le récepteur hybride un manifeste référençant les paquets de données (étape 2.4). Suite à la réception du manifeste et au cours d'une étape 2.5, le récepteur hybride 4 émet vers le serveur dédié (CDN) une requête pour recevoir les paquets de données référencées dans le manifeste reçus. Dès que les paquets de données sont reçus, ils sont décodés et le contenu audio est reproduit.

Détermination de la datation d'un chunk

On constate généralement un décalage entre le moment où le contenu audio est diffusé par radio et le moment où le chunk contenant les données de ce contenu apparaissent dans un manifeste en sortie du serveur CDN 4. Lorsque le récepteur hybride 2 veut reprendre la reproduction, il doit indiquer le moment où la reproduction du contenu audio diffusé par radio a été interrompu, ce qui n'est pas nécessairement le moment d'apparition du manifeste référençant le chunk correspondant à ce contenu audio. La façon de calculer la date associée à l'apparition du chunk (ou du manifeste qui le référence) en fonction de la date de diffusion de son contenu audio, va maintenant être décrite.

La source de contenu 1 dispose d'un module logiciel que l'on peut appeler « Délai compute », ce module permet de calculer, pour une même radio, le délai entre deux sources audio. Pour une radio, la source qui est diffusée en premier, souvent l'onde radio en Modulation de Fréquence (FM), est considérée comme la référence. On appelle « R », la valeur du retard entre le flux en streaming et le flux audio diffusé en temps réel vers tous les récepteurs. La valeur « R » est avantageusement calculée dynamiquement en réceptionnant d'un côté le flux IP diffusé et de l'autre le contenu diffusé, et en comparant les contenus pour évaluer le décalage.

En interrogeant périodiquement le serveur CDN, on obtient la date d'apparition d'un nouveau manifeste signalant l'ajout d'un nouveau chunk, cette date est notée Dp. Le lien entre le contenu audio diffusé et celui transmis dans un chunk est réalisé à l'aide d'une base de données qui liste, pour chaque station de radio, les flux IP associés. De plus, des algorithmes évaluent les deux contenus et élaborent un indice de confiance sur leur ressemblance. Si cet indice est faible, alors les contenus sont différents.

Soit « Dur » la durée d'un chunk, l'estimation de la date « Dck » de la partie de l'audio la plus ancienne dans le chunk peut alors être calculée par l'équation suivante :

Dck = Dp - Dur - R,

En d'autres termes, un nouveau chunk apparaît sur le serveur CDN 4 à une date et heure Dp qui est déterminé par la date et heure de diffusion Dck du contenu audio en temps réel, à laquelle on rajoute la durée du chunk Dur et une valeur de retard R qui est calculé pour un certain temps au moins. Une fois les valeurs Dp, Dur et R, calculées pour un chunk n, les dates des chunks suivants sont calculées en utilisant la relation : Dckn+1 = Dckn + durée du chunk n.

Le serveur Manager 5 qui scrute périodiquement l'apparition de nouveau manifeste vérifie que la date de mise à disposition réelle d'un chunk ne diverge pas. Si l'écart est supérieur à un seuil préconfiguré, alors la scrutation rapide toutes les 50 millisecondes effectuée précédemment, doit être répétée pour se resynchroniser. Cette dérive est normale car elle est liée aux différences d'horloge entre le codeur du flux et la plateforme RB (acronyme de « RadioBridge »). Un arrêt du flux en entrée du codeur peut avoir le même effet.

Détermination du nombre de chunks disponibles sur un serveur CDN

Les manifestes qui décrivent un flux diffusé en temps réel en streaming adaptatif ne comportent les références que d'un petit nombre de chunks. En effet, ces manifestes ne concernent finalement que les chunks des derniers morceaux d'audio diffusés par la station. Ceci évite que le fichier ne soit trop volumineux car il est chargé très fréquemment par les récepteurs hybrides 2. Par exemple, le manifeste peut ne contenir que les références vers les trois chunks les plus récents, alors que plusieurs centaines de chunks peuvent encore être disponibles sur le serveur CDN.

La disponibilité de chaque chunk au niveau du serveur CDN est déterminée par une durée appelée « Durée de Vie » ou TTL (de l'anglo-saxon : « Time To Live »). Si le temps entre l'apparition du chunk et le temps courant atteint cette valeur, alors le chunk est effacé de la mémoire du serveur CDN. Pendant toute la durée TTL, le chunk reste disponible même s'il n'est plus référencé par les manifestes apparaissant au fil du temps sur le serveur CDN.

Si à un instant donné, le serveur Manager se connecte à un serveur CDN, il reçoit un manifeste ne référençant qu'un petit nombre de chunks, or le serveur CDN peut encore fournir bien d'autres chunks. Pour améliorer la quantité de chunks qui sont réellement disponibles au sein du serveur CDN, le serveur Manager met en place un mécanisme de recherche qui est notamment lancé lors de la réinitialisation du serveur Manager.

Ce mécanisme consiste dans un premier temps, à charger le manifeste puis à rechercher le nom du chunk le plus ancien référencé dans ce manifeste. Ce nom est terminé par un numéro de chunk. Le mécanisme se poursuit en diminuant de le numéro pour obtenir la référence du chunk précédent puis, le mécanisme tente de le télécharger à partir du serveur CDN. Si le chunk peut être téléchargé, il est ajouté à la liste des chunks disponibles.

L'opération est ensuite répétée de façon itérative jusqu'à ce que le serveur Manager n'arrive plus à télécharger le chunk dont il vient de construire le nom. Pour limiter le volume téléchargé par ce mécanisme, la méthode HTTP HEAD sera privilégiée pour vérifier la disponibilité d'un chunk.

Afin de limiter l'impact de coupures courtes et selon un perfectionnement, en cas d'échec d'un téléchargement de chunks, le serveur Manager cherche à télécharger un certain nombre de chunks ayant un numéro inférieur à celui non disponible. Si toutes les tentatives échouent, alors on ne peut plus remonter plus en avant dans le temps et le nombre de manifestes permettant de retrouver des chunks sur le serveur CDN est alors figé en utilisant le dernier chunk disponible trouvé. Ces manifestes sont enregistrés dans une mémoire circulaire gérée par deux pointeurs, la taille de cette mémoire étant directement proportionnelle au nombre de chunks disponibles.

Afin de limiter la taille de cette mémoire circulaire, le serveur Manager ne recherche itérativement qu'un nombre limité de chunks, par exemple 300. Si le nombre de chunks référencés atteint cette valeur, alors le processus de recherche s'interrompt.

Si pendant la recherche de chunk, le compteur utilisé pour construire leurs identifiants atteint la valeur 0, alors la recherche est arrêtée. Il n'existe pas en effet de numéro de chunk ayant une valeur négative.

Pour chaque chunk découvert sur le serveur CDN, une entrée est ajoutée dans la base de données du gestionnaire. Cette entrée contient :

- la référence du chunk (typiquement son adresse URL),

- la date de production de son contenu audio,

- un numéro de session correspondant au manifeste pointant le chunk comme le premier à lire. Le manifeste associé est construit en utilisant les N chunks découverts qui précèdent celui émis en temps réel. Selon le standard HLS, ce manifeste a pour référence « numero_de_session.m3u8 ». Cette méthode a pour avantage de rendre le système auto adaptatif au nombre de chunks disponibles sur le serveur CDN.

Selon un perfectionnement et afin d'éviter de fournir des manifestes qui référenceraient des chunks récemment supprimés du serveur CDN, les N derniers chunks du buffer ne doivent pas être adressables pour une reprise de la lecture. Pour un buffer contenant M chunks, seuls (M-N) chunks seront adressables via les manifestes produits par la plateforme.

Le serveur Manager gère dans une mémoire circulaire la disponibilité des chunks, en demandant au serveur CDN le téléchargement des manifestes en temps réel, en inscrivant les références des nouveaux chunk, et en mettant à jour les références en fonction de la disponibilités des chunks.

Ces trois étapes sont répétées cycliquement avec une période qui peut varier, puisqu'elle doit être légèrement inférieure à la durée du dernier chunk chargé (une seconde en moins par exemple).

Le fait de vérifier la disponibilité d'un chunk au sein du serveur CDN entraîne la remise à zéro de son compteur de durée de vie, et une augmentation de sa disponibilité. Une vérification systématique de tous les chunks a donc pour effet de faire artificiellement croître le nombre de chunks disponible sur le serveur CDN et d'augmenter les coûts de fonctionnement. Afin de limiter le coût d'implémentation, la vérification de la présence d'un chunk doit être réalisée en utilisant la méthode « http HEAD » plutôt que la méthode GET.

Afin d'éviter les effets décrit ci-dessus, le plus ancien chunk N est automatiquement retiré de la liste des chunks disponible quand un nouveau chunk sera ajouté et le chunk N-l (qui devient le dernier chunk) est testé. Si le serveur Manager constate que le chunk N-l n'est plus disponible au sein du serveur CDN, alors il est supprimé de la mémoire circulaire et le chunk N-2 est testé. Ces étapes sont répétées jusqu'à ce qu'un chunk disponible soit découvert.

Le serveur Manager gère autant de mémoires circulaires que de sources radio 1.

Lors de chaque émission d'un nouveau chunk, la source radio 1 crée un nouveau manifeste en le référençant par un numéro chronologique et un suffixe, par exemple « m3u8 », par exemple le 125° manifeste porte la référence « 125.m3u8 ». Le serveur Manager gère la mémoire de façon circulaire, le plus récent manifeste référencé « 1 » écrase le plus ancien qui est référencé « N ». Lors de chaque rajout dans la mémoire, l'ensemble des manifestes, sauf celui qui vient d'être ajouté, est alors renommé en augmentant son indice de 1. Le manifeste « 125.m3u8 » devient « 126.m3u8 », etc... La renumérotation doit commencer par le manifeste N-l qui est renommé en N. Lors de cette renumérotation, la session N-i n'a plus de manifeste le temps que le manifeste N- i+1 soit renommé en N-i. Les requêtes d'accès aux manifestes qui peuvent arriver sur la plate-forme pendant cette phase de renumérotation doivent donc être temporisées. Pour des raisons de performance, la renumérotation doit être effectuée de façon atomique localement en utilisant une méthode atomique du système d'exploitation, ce qui signifie que cette action est effectuée en une seule opération d'un point de vue système d'exploitation. Ceci ne peut être fait à distance en FTP.

Une fois que la renumérotation des anciens manifestes est terminée, le dernier émis qui comporte le chunk correspondant au contenu diffusé en temps réel porte la référence « I.m3u8 ». Prenons un exemple en considérant que la profondeur de la mémoire circulaire est de 2 heures et que les chunks ont une durée de 10 secondes. Les 7200 secondes de contenus adressables par cette mémoire sont accessibles par 720 manifestes qui adressent chacun des chunk de 10 secondes. Selon cet exemple et en considérant qu'un manifeste référence trois chunks, les 720 manifestes occupent une mémoire n'excédant pas 2 Mo sur le serveur Manager, ce qui est tout à fait raisonnable. La Fig. 3 présente un schéma montrant la présence des manifestes et des chunks au sein des différents serveurs utilisant la présente invention. Plus précisément, le schéma décrit la relation entre les données existantes sur le serveur CDN de la source radio, les manifestes créés par la plateforme, les identifiants de session et les heures de reprise qui leur sont associées.

La partie gauche du schéma présente le contenu de la mémoire du serveur CDN, le chunk référencé « 1 » est le dernier créé, le manifeste intitulé « M3u live » est le dernier créé, il référence les chunks 1, 2 et 3.

La partie centrale décrit les manifestes créés par le serveur Manager, ils sont accessibles par un serveur dit « cache » portant la référence 7 sur la Fig. 1. Le serveur Manager maintient en mémoire les manifestes référencés M3ul, M3u2, M3u3, ... M3uN-2, qui sont numérotés de 1 à 300. Le premier manifeste (c'est à dire le plus récent) M3ul, numéroté 1, référence les chunk 1, 2 et 3. Le second manifeste M3u2, M3u3, numéroté 2, référence les chunk 2, 3 et 4. Le troisième manifeste M3u3, numéroté 3, référence les chunk 3, 4 et 5, et ainsi de suite. Le dernier manifeste présent en mémoire du serveur Manager est le 300 ième, il permet de rechercher dans la mémoire du serveur CDN, les derniers chunks encore disponibles et respectivement référencés N-2, N-l, N.

La partie droite du schéma présente le contenu de la mémoire d'une partie du serveur Manager appelé « Time Shift manager » portant la référence 8 sur la Fig. 1. En utilisant la formule pour le calcul de la date « Dck » de la partie de l'audio la plus ancienne dans le chunk, en fonction de la durée d'un chunk, l'heure courante et le retard, le sous- serveur Time Shift manager 8 met à jour un tableau associant des numéros de session avec des dates et heure de reprise de contenus audio. De cette manière, un récepteur hybride adresse une requête au sous-serveur 8 en présentant la date et l'heure de l'interruption et l'identification de la radio source, le sous-serveur 8 recherche dans son tableau d'association et en extrait aussitôt un numéro de session qui est utilisé ensuite pour récupérer le manifeste référençant le premier chunk à reproduire.

Présentation d'un appareil récepteur hybride

La Fig. 4 représente un schéma d'un appareil récepteur hybride 2, selon un mode de réalisation particulier de l'invention. Le récepteur hybride 2 comporte typiquement une unité centrale 10 associée à une mémoire de programme 11, un module de réception d'un flux radio 12 recevant des émissions d'un réseau monodirectionnel, un réseau FM par exemple, et un module de communication 13 autorisant des communications bidirectionnelles à courte ou à longue portée par un câble ou par la radio, en utilisant par exemple le réseau Bluetooth, Wifi et/ou GSM. Le récepteur dispose également de moyens d'introduction de commande 14 (clavier, boutons, écran tactile, ...), et de moyens d'affichage (écran, voyants lumineux, synthèse vocale, ...). Ces moyens peuvent être intégrés à l'appareil ou déportés. L'appareil dispose également d'un moyen de reproduction d'un contenu audio et/ou audiovisuel, composé par exemple d'un écran déporté 15, et/ou d'un amplificateur 16 intégré à l'appareil émettant des signaux acoustiques vers des haut-parleurs déportés 17. L'appareil dispose d'un mémoire de stockage de données, typiquement des chunks 18 permettant d'enregistrer des contenus audio.

Un récepteur en cours de reproduction d'un contenu diffusé à partir d'une source radio peut être interrompu pour quelques raisons que ce soit : action de l'utilisateur, manque de réception, coupure de l'alimentation, mobilisation des moyens de reproduction du son pour un autre usage, etc. Au moment de l'interruption, le récepteur mémorise la date et l'heure courante et l'identification de la radio source diffusant le contenu audio. Un peu plus tard, l'utilisateur peut demander de reprendre la reproduction de ce contenu audio interrompu. Le récepteur hybride 2 émet alors une requête vers le sous- serveur 8 Time-Shift manager pour le calcul du décalage temporel, la requête comporte au moins les informations suivantes : l'heure courante, la date et l'heure de

l'interruption et l'identification de la radio source dont la diffusion a été interrompue (ces deux dernières informations ayant été mémorisées). Ce sous-serveur 8 calcule alors l'heure de reprise du côté serveur, ce qui permet de connaître l'identifiant de la session correspondant à l'heure de reprise souhaitée pour la radio demandée. Le serveur 7 retourne alors au récepteur 2 l'URL du manifeste à utiliser pour reprendre la lecture.

A travers le serveur de cache 7, le récepteur hybride 2 transmet l'identifiant du manifeste au serveur Manager 5 qui lui renvoie le contenu du manifeste identifié. Le récepteur hybride 2 extrait dans le manifeste reçu les identifiants des chunks et émet des requêtes vers le serveur CDN afin de les télécharger et les reproduire.

Présentation d'un serveur Manager ou CDN

La Fig. 5 illustre les principaux composants d'un serveur distant 20 tel qu'un serveur CDN et un serveur Manager, selon un exemple de réalisation. Un tel serveur 20 comporte une unité centrale ALU 21 reliée à une mémoire de programme exécutable PM 22, un disque dur HD 23 contenant une base de données pour le stockage de données de façon non-volatile. Le serveur 20 contient également une interface I/O 24 pour la

communication avec un récepteur hybride 2 via un réseau informatique. Un tel serveur 20 permet de fournir des manifestes référençant des chunk dont les contenus sont diffusés en temps réel, et de gérer la reprise de contenu en différé. Ce serveur peut transmettre à la demande d'un récepteur 1 les chunks d'un contenu transmis en streaming adaptatif ou des blocs de données au format MP3 d'un contenu à télécharger. Il n'est pas exclu que les moyens de liaison diffèrent selon le type d'appareil en communication, ainsi le serveur 20 peut communiquer avec les récepteurs 2 à travers un réseau sans fil (téléphonie mobile 3G/4G/5G) et/ou par un câble via un réseau numérique quelconque.

Il doit être évident pour les personnes versées dans l'art que la présente invention permet des modes de réalisation sous de nombreuses autres formes spécifiques sans l'éloigner du domaine d'application de l'invention comme revendiqué. Par conséquent, les présents modes de réalisation doivent être considérés à titre d'illustration mais peuvent être modifiés dans le domaine défini par la portée des revendications jointes.