Brevet FR3068554A1 — publié le 20190104

Procédé de transmission d'un contenu audio interrompu dans un récepteur hybride, système, récepteur et programme associé au procédé 1. DOMAINE DE L'INVENTION 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 que la reproduction des contenus peut être interrompue et que la partie restante à reproduire est ensuite téléchargée d'un réseau. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Dans le domaine de la diffusion de contenus audio ou audiovisuels, il est connu des récepteurs dits « hybrides » capables de recevoir 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). 2 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 des documents sous la forme d'une succession de paquets de données numériques (ou « chunk » - cette appellation sera 5 ensuite utilisée dans le reste du document). Les techniques de segmentation sont connues en soi, on peut citer par exemple les algorithmes HLS, DASH ou encore, Smooth Streaming. Chaque chunk dispose d'une structure de données de fichier contenant une charge utile (par exemple, les données audio et /ou vidéo, avec les données synchronisant leur reproduction, par exemple des parqueurs temporels ou 10 « timestamps » en langue anglo-saxonne), une référence, et un identifiant de source (typiquement l'identifiant d'une chaîne de diffusion). 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 15 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. A tout moment, un événement peut intervenir forçant l'utilisateur à interrompre la reproduction sur son récepteur. Cet événement peut par exemple être le fait que le récepteur est un autoradio embarqué dans un véhicule et qu'à certains endroits, 20 l'appareil quitte une zone de couverture et se retrouve sans pouvoir recevoir le contenu en cours de reproduction. L'événement peut aussi être le fait que l'utilisateur reçoit une communication téléphonique qui va utiliser le même système audio que celui qui reproduit actuellement le contenu audio. Dans un autre contexte, l'utilisateur quitte son domicile, et demande à son système d'interrompre la reproduction jusqu'à ce qu'il 25 revienne. Un des buts de la présente invention est la possibilité de reprendre la reproduction du contenu au moment où il a été interrompu. Pour cela, un moyen simple de poursuivre la reproduction d'un contenu interrompu est de continuer à le recevoir et à l'enregistrer dans une mémoire du l'appareil de reproduction. Lors de la reprise, l'appareil lit sa mémoire organisée 30 circulairement 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 3 ont empêché de recevoir correctement le contenu. Une autre façon de poursuivre la reproduction d'un contenu consiste à se connecter à un site permettant de télécharger la partie restante. L'appareil télécharge et enregistre le contenu complet et, en utilisant une interface utilisateur, l'utilisateur peut avancer rapidement et ainsi passer par dessus des 5 moments qui ont déjà être reproduits. Cette opération qui permet de retrouver des parties non reproduites de contenus diffusés, est assez lourde car l'utilisateur doit identifier lui-même le contenu qu'il veut télécharger. Il existe donc un réel besoin d'un procédé permettant de récupérer facilement au moins des parties du contenu diffusé sur un flux radio et qui n'ont pas été reproduites au 10 niveau d'un récepteur. L'invention propose également un procédé technique et une architecture applicable à la mise en oeuvre de l'ensemble des cas d'usage de services « Arrêt et Redépart », et utilisable par les constructeurs de récepteurs de contenus et par les éditeurs de contenus diffusés sur un flux radio sous la forme d'un accès à une 15 plateforme de service dédiée et opérée dans le réseau informatique mondial. 3. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé 20 de transmission d'un contenu audio et/ou audiovisuel au niveau d'un appareil récepteur. Le procédé comprend au moins les étapes suivantes : - une étape de réception d'un flux déterminé diffusé sur un réseau et reproduction des contenus transmis par ledit flux au niveau de l'appareil récepteur, - une étape de détection d'un premier événement extérieur à l'appareil récepteur 25 déclenchant l'interruption de la reproduction du contenu en cours et l'enregistrement du moment de l'interruption, - une étape ultérieure de détection d'un second événement extérieur déclenchant une étape de transmission de l'appareil récepteur vers un serveur distant du moment datant le premier événement et d'une requête de reprise de reproduction du contenu 30 interrompu, 4 - une étape de transmission du serveur distant vers l'appareil récepteur d'une information spécifiant les identifiants des paquets de données du contenu au moment de l'interruption, - une étape de transmission des paquets de données du contenu ainsi identifiés, 5 de réception par le récepteur desdits paquets de données en vue de leur reproduction en différé. Ainsi, la solution proposée repose sur une approche tout à fait nouvelle et inventive, permettant de déterminer précisément la partie manquante d'un contenu dont la reproduction a commencé et qui a été interrompu, et de demander à un site distant de 10 transmettre cette partie manquante afin de continuer la reproduction en différé. Selon un mode préféré de réalisation, l'information transmise par le serveur distant vers le récepteur comporte un manifeste identifiant une succession de chunks dont le premier contient les paquets de données du contenu au moment de l'interruption. De cette manière les données d'audio à transmettre du serveur au récepteur son 15 parfaitement mises à jour et identifiées. Selon un autre mode de réalisation, le manifeste transmis identifie tous les chunks disponibles sur le serveur contenant le contenu audio diffusé entre le moment de l'interruption et le moment présent. Selon un autre mode de réalisation, le manifeste transmis identifie tous les 20 chunks mémorisés dans le serveur à partir du moment où l'intervalle de temps entre le moment de l'interruption et le moment présent dépasse la durée de tous les chunks mémorisés dans le serveur. Selon un autre mode de réalisation, l'information transmise par le serveur distant vers le récepteur comporte une adresse de lecture dans un buffer circulaire d'un autre 25 serveur distant, cette adresse correspondant à la première trame audio de la partie restante du contenu non lu, le serveur transmettant par la suite les trames audio de la partie restante du contenu non lue. De cette manière, les données audio de la partie du contenu restant à reproduire sont parfaitement identifiables et peuvent plus facilement être transmises. 30 Selon un autre mode de réalisation, le procédé comporte une étape de détermination de l'heure courante au moment de la transmission du récepteur vers le 5 serveur distant du moment datant le premier événement et d'une étape de calcul de l'écart temporel entre la dite heure courante reçue et l'heure courante du serveur, les paquets de données du contenu au moment de l'interruption étant datés par l'heure transmise à laquelle est retranchée l'écart calculé. De cette manière, le moment de la 5 reprise est parfaitement synchronisé avec celui de l'interruption, l'utilisateur étant assuré de ne rien manquer et de ne rien entendre deux fois. Selon un autre mode de réalisation, le procédé comporte une étape de modification de l'interface utilisateur pendant une durée limitée spécifiant que le service d'interruption de la reproduction du contenu et de reprise pour une transmission en 10 différé, n'est pas disponible pendant cette durée limitée. De cette manière, l'utilisateur peut immédiatement voir si le service de reprise est disponible ou non. Selon un autre aspect de l'invention, il est proposé un récepteur hybride pour la reproduction d'un contenu audio en provenance d'un flux déterminé diffusé sur un premier réseau, ledit récepteur comportant un moyen de réception du flux déterminé 15 diffusé sur ledit premier réseau, un moyen de communication avec un serveur distant et un moyen de reproduction de ce contenu audio en vue d'une reproduction en différé. Le récepteur comporte en outre : - un premier moyen de détection d'un premier événement extérieur au récepteur déclenchant l'interruption de la reproduction du contenu en cours et l'enregistrement 20 d'au moins le moment de l'interruption fourni par une horloge interne, - un second moyen de détection d'un second événement extérieur pour la reprise de la réception dudit contenu déclenchant la transmission vers un serveur distant du moment datant le premier événement et d'une requête pour recevoir les paquets de données de contenu diffusé à partir dudit moment, le moyen de communication recevant 25 les paquets de données ainsi identifiés et destinés à être reproduits avec un différé. Selon un autre aspect de l'invention, il est proposé un système de reproduction d'un contenu audio comportant un récepteur hybride doté d'un moyen de réception dudit contenu audio en provenance d'un flux déterminé diffusé sur un réseau et d'un moyen de reproduction de ce contenu audio en vue d'une reproduction en différé. Le système 30 comporte en outre un premier moyen de détection d'un premier événement extérieur au récepteur déclenchant l'interruption de la reproduction du contenu en cours et 6 l'enregistrement du moment de l'interruption, et un second moyen de détection d'un second événement extérieur déclenchant la transmission du récepteur vers un serveur distant du moment datant le premier événement et d'une requête de reprise de reproduction du contenu interrompu, le système comportant un serveur recevant du 5 récepteur une information spécifiant les identifiants des paquets de données du contenu au moment de l'interruption et émettant vers le récepteur des paquets de données ainsi identifiés destinés à être reproduits avec un différé. Dans un autre mode de réalisation de l'invention, il est proposé un produit programme d'ordinateur, comprenant des instructions de code de programme pour la 10 mise en oeuvre du procédé décrit dans les paragraphes précédents, par l'appareil récepteur, lorsque ledit programme est exécuté sur un ordinateur. 4. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de 15 la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure 1 présente la structure d'un récepteur, selon un mode de réalisation particulier de l'invention ; - la figure 2 illustre les principaux composants d'un serveur distant, selon un 20 exemple de réalisation ; - la figure 3 présente une architecture générale des éléments mis en communication pour fournir un service de reprise en différé de contenus selon un mode préféré de réalisation de l'invention ; - la figure 4 présente un chronogramme des différentes communications 25 intervenant entre les éléments du système, selon un exemple de réalisation ; - la figure 5 présente un ordinogramme des étapes permettant de convertir l'heure du récepteur en heure de reprise serveur selon un exemple de réalisation ; - la figure 6 présente un chronogramme des communications intervenant entre les éléments du système, dans le cas de téléchargements de fichiers de contenu ; 7 - la figure 7 présente un ordinogramme des étapes permettant de convertir l'heure du récepteur en heure de reprise serveur dans le cas de téléchargements de fichiers de contenus. 5 5. DESCRIPTION DÉTAILLÉE 5.1 Principe _g_énéral L'invention concerne un procédé de reprise de la reproduction d'un contenu audio et/ou audiovisuel au niveau d'un appareil récepteur. Le procédé commence par une étape de réception du flux déterminé diffusé sur un réseau et reproduction des 10 contenus transmis par ledit flux au niveau de l'appareil récepteur, puis un premier événement extérieur à l'appareil récepteur est détecté qui déclenche l'interruption de la reproduction du contenu en cours et l'enregistrement du moment de l'interruption. Quelques temps après, un second événement extérieur déclenche la transmission de l'appareil récepteur vers un serveur distant du moment datant le premier événement et 15 d'une requête de reprise de reproduction du contenu interrompu. Une information spécifiant les identifiants des paquets de données du contenu au moment de l'interruption est alors transmise du serveur distant vers l'appareil récepteur. Enfin, l'appareil reçoit des paquets de données ainsi identifiés et reproduit le contenu desdits paquets. 20 Ainsi, la solution proposée repose sur une approche tout à fait nouvelle et inventive, permettant de récupérer facilement d'un serveur distant des parties d'un contenu diffusé qui n'ont pas été reproduites au niveau d'un récepteur. 5.2 Description d'un mode_particulier de réalisation 25 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 structure d'un appareil récepteur hybride 1, selon un mode de réalisation particulier de l'invention. Le récepteur hybride 1 comporte typiquement une unité centrale 2 associée à une mémoire de 30 programme 3, un module de réception d'un flux radio 4 recevant des émissions d'un 8 réseau monodirectionnel, un réseau FM par exemple, et un module de communication 5 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 6 (clavier, 5 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é 7, et/ou d'un amplificateur 8 intégré à l'appareil émettant des signaux acoustiques vers des haut-parleurs déportés 9. 10 L'appareil dispose de moyens d'entrée/sortie 10 permettant d'émettre et de recevoir des signaux avec tout appareil avec lequel il est connecté. Il peut ainsi recevoir des signaux provenant de capteurs, un microphone par exemple. Selon un perfectionnement non obligatoire, le récepteur hybride dispose également d'une mémoire 11 capable de stocker un contenu audio et/ou visuel diffusé 15 par un réseau unidirectionnel ou bidirectionnel. Le récepteur hybride reçoit une alimentation électrique ou dispose de sa propre batterie. Il peut être mobile et prendre l'aspect d'un téléphone portable intelligent (ou « smartphone » selon la terminologie anglo-saxonne. Il peut par exemple être embarqué dans un véhicule itinérant. 20 La Fig. 2 illustre les principaux composants d'un serveur distant 20. Selon cet exemple de réalisation, le 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 6 contient également une interface I/O 24 pour la communication avec le récepteur 1 via un réseau 25 informatique. Le serveur 6 permet la gestion du service de reprise de contenu, le même serveur ou un autre 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 9 1 à travers un réseau sans fil (téléphonie mobile 3G/4G) et/ou par un câble via un réseau numérique quelconque. La fig. 3 présente une architecture générale des éléments mis en communication 5 pour fournir un service dit « Stop and Resume » ou S&R en abrégé, qui permet de reprendre en différé un contenu. Comme le montre les deux parties séparées par un trait vertical apparaissant sur la figure, ces éléments se trouvent soit dans le récepteur, soit dans les différents serveurs accessibles par le réseau. Le système S&R permettant la gestion de l'arrêt de la reproduction d'un contenu 10 et de sa reprise en différé s'appuie sur différents appareils et différents modules logiciels. Le système S&R assure les fonctions suivantes : - Il s'assure de la disponibilité du service S&R pour le contenu interrompu auprès d'un serveur dédié au management de service. - Il analyse si le service est toujours disponible pour le programme qui était joué 15 lors de la dernière interruption. - Il informe l'IHM du récepteur de cette disponibilité pour adapter l'affichage afin d'informer l'utilisateur et lui permettre de reprendre le contenu interrompu. - Sur demande de l'utilisateur, de relancer la reproduction d'un contenu toujours disponible. Pour cela, il demande au module d'adaptation d'accès au service 20 audio l'URL à utiliser pour reprendre la lecture du contenu. - Il fournit cette URL au décodeur de streaming pour que le récepteur puisse reprendre la lecture du contenu là où il a été interrompu. Rappelons qu'une « URL » est un acronyme tiré de l'anglais Uniform Resource Locator, littéralement « localisateur uniforme de ressource ». 25 Le récepteur 1 possède une IHM 6 permettant à son utilisateur de choisir un contenu, de le stopper à tout moment et de demander sa reprise sur sa demande ou automatiquement, dans le cas où la cause de l'interruption est extérieure à l'utilisateur (appel téléphonique, arrêt du récepteur...). L'IHM 6 affiche la disponibilité ou non du service S&R sous la forme d'une 30 icône présente à l'écran. Cette icône est par exemple représentée par un dessin 10 « STOP » indiquant en cela que le contenu peut être interrompu à tout moment. L'absence de cette icône indique que cette fonction n'est pas disponible, cela peut être dû par exemple à une coupure de communication avec le serveur gérant le service S&R, ou à une mémoire de données saturée ne permettant aucun enregistrement. Lorsque le 5 contenu a été interrompu, le service S&R est alors accessible par une icône qui illustre la « REPRISE », l'absence d'une telle icône signifie aussi que le service n'est plus disponible. Dans le cas où l'accès au service s'effectue par une touche mécanique, l'indicateur d'accessibilité du service peut être représenté par un voyant à coté de cette touche. 10 Le récepteur possède également les modules logiciels suivants : - Module de sélection de source audio 30: il reçoit les sources audio disponible sur le récepteur et sélectionne le contenu audio à reproduire. Ce module est piloté par l'utilisateur via l'IHM. - Module de décodage FM, DAB 31: il décode le service sélectionné en 15 réception FM et/ou DAB et fournit en sortie les échantillons audio décodé au Module de sélection de la source audio. - Décodeur de streaming 32: il se connecte au serveur de streaming via une adresse URL fournie par le serveur du service S&R, décode les données audio et/ou vidéo et les fournit au module de sélection de source audio. Ce module 20 peut être compatible avec un ou plusieurs protocoles de streaming comme DASH, HLS ou streaming mp3. - Module de gestion S&R 33 : il reçoit les ordres de l'utilisateur introduites dans l'IHM et commande le décodeur de streaming. Coté réseau, le services S&R s'appuie sur les différents serveurs suivants, qui 25 peuvent être hébergés sur la même matériel informatique : - Serveur de management du service 34: il informe les terminaux de la disponibilité du service S&R. Le récepteur 1 émet une requête en fournissant l'ID du programme en cours d'écoute. Le Serveur lui retourne les données suivantes : 11 o la profondeur, en secondes, du buffer circulaire disponible du coté serveur pour le service considéré, o la liste des protocoles de streaming disponibles pour reprendre la lecture du contenu, 5 o l'adresse URL du module d'adaptation de l'accès au contenu. - Module d'adaptation de l'accès au contenu 35: il construit l'adresse de l'URL qui est transmise au récepteur 1 pour reprendre la lecture du contenu. Pour cela, il attend les éléments suivants dans la requête du récepteur : o le protocole de streaming demandé par le récepteur : streaming 10 mp3, HLS, DASH... o l'heure courante du récepteur lors de l'envoi de la requête : cette heure est utilisée pour calculer le décalage d'heure entre le serveur et le récepteur, o l'heure à laquelle la lecture doit être reprise. 15 o l'identification de la source transmettant le contenu pour laquelle la lecture doit être reprise. Si par exemple, le récepteur demande une URL de streaming MP3 : le serveur retourne une URL contenant un identifiant de la position où doit être démarrer le streaming. Cet identifiant peut être l'heure serveur à laquelle reprendre la lecture. 20 Si par exemple, le récepteur demande une URL de streaming adaptatif (HLS, DASH...) : Le serveur calcule dynamiquement et retourne alors au lecteur, par exemple, un MPD (pour DASH) ou d'un m3u (pour HLS) qui est propre au récepteur qui a fait la requête. Ce fichier contient, comme première référence, la référence de la première trame à jouer pour reprendre le contenu audio à la position demandée. Le 25 récepteur vient cycliquement lire le fichier, le serveur le met alors dynamiquement à jour afin assurer le téléchargement des chuncks suivants par le récepteur. - Buffer audio circulaire mp3 dans le cloud 36 : l'URL utilisée par le lecteur, coté récepteur, contient un identifiant de la position où doit être démarrer le streaming. Cet identifiant peut être l'heure serveur à laquelle 30 reprendre la lecture. Cet identifiant est interprété par le serveur qui se 12 positionne dans la liste des trames qu'il contient dans son buffer circulaire. Si l'identifiant est l'heure serveur le serveur utilise l'heure de la dernière trame ajouter au buffer pour calculer le décalage à effectuer pour se positionnée sur la bonne trame pour démarrer le streaming. Le 5 streaming et ensuite vue par le récepteur comme un streaming live et se poursuis jusqu'à ce que l'utilisateur choisis de sortir du mode résume. - Buffer audio circulaire de chunks 37 (DASH, HLS...) : les chuncks sont mis à disposition des récepteurs sur un serveur http sous la forme de fichiers. Chaque chunck n'est présent qu'une fois sur le serveur et est 10 partagé par tous les récepteurs. Le serveur efface progressivement les chuncks qui sortent de la plage horaire couverte par la fonction résume afin de ne pas saturer l'espace de stockage. - Codeur audio 38: il crée les trames audio mp3 ou AAC en utilisant la même source audio que celle diffusée en DAB et FM, si le contenu est de 15 type audio. - Encapsuleur 39 : Dans le cas du streaming adaptatif pour un contenu audio, les trames sont ensuite encapsulées sous forme de chuncks et déposées sur un serveur. L'invention peut s'utiliser dans au moins deux systèmes de transmission de 20 contenus, le premier concerne des documents transmis en streaming adaptatif selon des standards comme DASH (acronyme de l'Anglo-saxon Dynamic Adaptive Streaming over http), ou HLS (acronyme de l'Anglo-saxon HTTP Live Streaming), le second concerne des documents téléchargés selon un standard MP3 par exemple. Ces standards ont été développés par de grandes sociétés américaines d'informatique. 25 De façon générale, les protocoles de streaming adaptatif cités ci-dessus sont massivement utilisés de nos jours, et il n'y a pas lieu de les expliciter davantage dans ce document. Le streaming adaptatif permet de transmettre un ou plusieurs fichiers de descriptions (appelés « manifeste » dans certain standard) et un ensemble de fichiers contenant le contenu à diffuser (ou un fichier dans le cas du MP3). 13 L'invention va maintenant être expliquée dans ces échanges de communications, pour l'un et l'autre des systèmes. 5.3 Mode particulier de réalisation dans le cadre du streaminadaptatif 5 La Fig. 4 illustre sous la forme d'un chronogramme ou le temps évolue de haut en bas, des différentes communications intervenant entre : - l'utilisateur et son récepteur, - le serveur de gestion du service S&R, - le serveur d'adaptation de l'accès au contenu audio, 10 - le serveur fournissant le contenu (c'est à dire fournissant des chunks). Cette figure est illustrative d'une reprise de la reproduction d'un contenu audio, mais l'invention concerne aussi des contenus ayant une composante vidéo. Dans un premier temps, l'utilisateur lance la reproduction d'un contenu transmis par un flux radio à partir de son récepteur 1. Un événement intervient qui interrompt la 15 reproduction. Cet événement est par exemple, une intervention de l'utilisateur pour stopper la reproduction, la prise d'un appel téléphonique qui va utiliser le système audio 8, 9 du récepteur, la détection d'un défaut d'alimentation entraînant l'arrêt immédiat du récepteur, ... Au moment de l'interruption, le récepteur 1 mémorise dans une mémoire non volatile le moment précis de l'interruption. Un peu plus tard, l'utilisateur introduit 20 une nouvelle commande « Resume » pour reprendre la reproduction, le récepteur transmet alors une requête contenant le moment précis de l'interruption de ce contenu au serveur d'adaptation de l'accès au contenu audio. Le serveur renvoie alors une URL permettant au récepteur de recevoir un manifeste. Un manifeste est un fichier décrivant l'ensemble des contenus disponibles selon un certain standard, DASH par exemple, et 25 notamment la façon de trouver les flux qui fournissent ces contenus. Le récepteur transmet alors une requête pour recevoir ce manifeste, et le serveur d'adaptation de l'accès au contenu audio lui transmet. Ce manifeste contient les références des chunks de la partie restant à reproduire du contenu. Le récepteur transmet alors ces références au serveur fournissant le contenu, qui renvoie les chunks contenant les données à 30 reproduire. Le récepteur peut alors commencer la reprise de la reproduction du contenu 14 interrompu. L'implémentation dans le cas d'un streaming adaptatif prend en compte le fait que les chunks sont des entités indépendantes et qu'il suffit de les demander pour les recevoir. Le récepteur effectue régulièrement des mises à jour du manifeste auprès du 5 serveur d'adaptation de l'accès au contenu audio, de façon à recevoir les chunks qui suivent la partie du contenu actuellement en cours de reproduction. Selon un mode particulier de réalisation, le récepteur demande une nouvelle version du manifeste lorsque la durée de reproduction dont il dispose est en dessous d'un seuil, une minute par exemple. 10 Selon un autre aspect de l'invention, chaque récepteur dispose de son propre moyen pour horodater l'heure de l'interruption, et de ce fait cette heure peut changer d'un récepteur à l'autre. Il importe donc pour le serveur de déterminer avec précision le moment où l'interruption est réellement intervenue sur chaque récepteur, pour que la lecture démarre au bon endroit. La Fig. 5 présente un ordinogramme des étapes 15 permettant de convertir l'heure du récepteur en heure de reprise serveur selon un exemple de réalisation. A l'étape 5.1, le récepteur reçoit de l'utilisateur une demande de reprise, et transmet au serveur d'adaptation de l'accès au contenu audio l'heure de l'interruption prise par le récepteur. Le serveur calcule alors l'écart entre l'heure courante du récepteur et l'heure courante du serveur, et en appliquant cet écart, il 20 convertit l'heure du récepteur en une heure de reprise serveur (étape 5.2). Supposons par exemple que l'heure du récepteur est 2h02 alors qu'au même moment, l'heure du serveur est 2h00. Au moment où le récepteur envoie sa requête, il transmet son heure courante : 2h02 au serveur. Le serveur prend son heure courante et calcule l'écart : + 2 mn, l'horloge du récepteur avance donc de 2 minutes. Supposons par la suite que le 25 récepteur veut reprendre la reproduction d'un contenu qu'il a interrompu à 11h00 (pour lui). Alors le serveur retranche 2 mn et à l'étape 5.3, identifie le chunk qui correspond à l'heure de reprise du serveur. Le serveur d'adaptation de l'accès au contenu crée ensuite un manifeste dont le premier chunk correspond à l'heure de reprise du serveur (étape 5.4). A l'étape 5.5, ce manifeste est transmis au récepteur. Ainsi, le serveur d'adaptation 30 fournit la première URL de MPD/playlist au récepteur afin qu'il puisse démarrer la 15 lecture. Cette URL possède une structure particulière. La première partie comporte le chemin pour que les requêtes de mise à jour du manifeste arrivent au module d'adaptation. La seconde contient l'identifiant de la radio à rejouer et l'heure serveur de début de lecture dans le buffer. Cette heure peut être mise dans le nom du manifeste ou 5 dans le chemin permettant d'y accéder. Cette structure permet de traiter les demandes de mise à jour du manifeste sans à avoir à maintenir une session entre le récepteur et un module de d'adaptation en particulier. Cela facilite la scalabilté de la plateforme et la gestion du load balancing. La seconde partie correspond à la lecture du flux, elle peut se résumer en une 10 boucle consistant en ce que le récepteur demande un nouveau manifeste et en ce que serveur d'adaptation de l'accès au contenu audio crée ces nouveaux manifestes en ajoutant les nouveaux chunks disponibles et en supprimant ceux effacés dans la mémoire. De cette façon, le serveur met à jour le contenu de chaque manifeste en fonction des chuncks disponible. Par exemple si le récepteur demande à reprendre 10 15 minutes après l'interruption de la reproduction, le prochain manifeste contiendra la liste des chuncks correspondants à ces 10 minutes. Supposons que le récepteur demande un manifeste toutes les 20 secondes par exemple, lors de la seconde demande le manifeste transmis par le serveur contient les références pour lire 10 minutes 20 secondes. Puis à la troisième demande il contient les références pour 10 minutes et 40 secondes, etc... 20 Il est à noter que le serveur d'adaptation possède une implémentation différente pour chaque type de streaming adaptatif : DASH, HLS, HSS... Le serveur génère dynamiquement les manifestes afin de rester compatible avec les spécifications du chaque protocole. 25 5.4 Mode particulier de réalisation dans le cadre de téléchar_g_ement La Fig. 4 illustre sous la forme d'un chronogramme ou le temps évolue de haut en bas, des différentes communications intervenant entre : - l'utilisateur et son récepteur, - le serveur de gestion du service S&R, 30 - le serveur fournissant le contenu sous la forme de fichiers MP3 par exemple. 16 A la différence du système fournissant des chunks, ce qui nécessite la création de manifestes, les fichiers sont directement identifiables sans passer par un manifeste. Le ou les fichiers composant le contenu sont alors gérés circulairement par un pointeur de lecture et un pointeur d'écriture. A noter qu'un contenu MP3 est géré sous forme 5 d'un buffer en mémoire qui est vu comme un seul fichier/flux par le récepteur. Dans ce cas, le serveur peut associer chaque trame transmise à une heure d'émission et, lorsqu'on lui demande de transmettre des trames à partir d'une certaine heure, il peut déterminer de quelles trames il s'agit. Le récepteur 1 reçoit un ensemble de trames et se synchronise sur la trame dont la reproduction a été interrompue, ou sur la trame entière 10 qui suit le moment de l'interruption. Dans un premier temps, l'utilisateur lance la reproduction d'un contenu transmis par un flux radio à partir de son récepteur 1. Un événement intervient qui interrompt la reproduction et qui déclenche dans le récepteur, la mémorisation du moment précis de l'interruption. Un peu plus tard, l'utilisateur introduit une nouvelle commande « Play » 15 pour reprendre la reproduction, le récepteur transmet alors une requête contenant le moment précis de l'interruption de ce contenu au serveur d'adaptation de l'accès au contenu audio. Le serveur calcule alors l'URL permettant de pointer dans le buffer circulaire la trame de données du contenu qui suit le moment de l'interruption, et émet cette URL vers le récepteur. Ce dernier demande alors au serveur fournissant le contenu 20 de lui renvoyer la trame identifiée par l'URL transmise (par exemple MP3). Le serveur transmet la trame au récepteur et décale le pointeur de lecture. Après avoir reçu les premiers fichiers, ceux-ci sont décodés et leurs contenus audio et/ou visuels sont reproduits au niveau du récepteur. Le récepteur effectue régulièrement des requêtes pour télécharger les fichiers suivants, de façon à poursuivre 25 continuellement la reproduction. Une nouvelle requête est transmise au serveur fournissant le contenu lorsque la durée des fichiers reçus mais non encore reproduits est en dessous d'un seuil, une minute par exemple. Selon une variante de réalisation, les manifestes transmis décrivent les fichiers du contenu diffusé entre le moment de la reprise jusqu'au moment présent, dans la 30 limite des fichiers disponibles dans la mémoire circulaire coté serveur. Cette variante 17 permet à l'utilisateur du récepteur d'avancer et de reculer rapidement dans la reproduction du contenu audio et notamment de revenir à la reproduction du contenu actuellement diffusé. Selon cette variante, au moment de la reprise de la reproduction, le premier 5 manifeste décrit la liste de tous les fichiers disponibles à partir du moment de l'interruption et jusqu'au moment présent. Dans un second temps, les autres manifestes décrivent les fichiers dont le contenu audio a été diffusé au moment de la reprise jusqu'au moment présent, jusqu'à atteindre la taille maximale de la mémoire circulaire du serveur. De cette manière, l'utilisateur peut naviguer dans le contenu audio qui a été 10 diffusé lors de la reprise de la reproduction et jusqu'au moment présent. Dans un troisième temps, lorsque le manifeste décrit l'ensemble des fichiers disponibles au niveau du serveur, il est nécessaire d'avancer dans le temps le premier fichier décrit par le manifeste. Il n'est alors plus possible de revenir au moment de la reprise car les fichiers associés ne sont plus disponibles dans la mémoire du serveur. Les 15 manifestes décrivent alors une fenêtre temporelle qui correspond à la taille du buffer circulaire. Cela implique que l'heure la plus ancienne pour la reproduction indiquée dans la demande de manifeste devienne l'heure la plus ancienne dans le buffer circulaire, et plus celle de la reproduction en différé coté récepteur. Ceci explique pourquoi le récepteur doit connaître la durée de mémorisation du serveur. 20 Prenons un exemple, la mémoire circulaire possède une capacité de stockage correspondant à 2 heures de reproduction de contenus, et l'utilisateur demande une reprise 1h30 heures après l'interruption. Pendant les premières 30 minutes qui suivent la reprise, l'utilisateur peut naviguer dans la reproduction du contenu et peut la reprendre jusqu'au moment de la reprise. Ensuite, l'utilisateur navigue dans le contenu diffusé au 25 cours des deux heures précédant le moment présent. La Fig. 7 présente un ordinogramme des étapes permettant de convertir l'heure du récepteur en heure de reprise serveur selon un exemple de réalisation. A l'étape 7.1, le récepteur reçoit de l'utilisateur une demande de reprise, et transmet au serveur d'adaptation de l'accès au contenu audio l'heure de l'interruption prise au niveau du 30 récepteur (avec son horloge par exemple). Le serveur calcule alors l'écart entre l'heure 18 courante du récepteur et l'heure courante du serveur, et en appliquant cet écart, il convertit l'heure du récepteur en une heure de reprise serveur (étape 7.2). De même que précédemment, le serveur retranche l'écart mesuré à l'heure transmise par le récepteur. Le serveur d'adaptation de l'accès au contenu crée ensuite une URL qui pointe sur un 5 premier fichier contenant les données audio et/ou vidéo correspond à l'heure de reprise du serveur (étape 7.3), et transmet cette URL au récepteur. A l'étape 7.4, le récepteur émet l'URL vers le serveur de contenu afin de télécharger les fichiers dont les données sont à reproduire. De cette manière, les premières trames du contenu qui sont transmises sont bien 10 celles qui correspondent à la partie restante à reproduire. Les contenus transmis par un canal FM ne comporte pas d'indications temporelles. Certains flux transmettent ce type de données. Selon un perfectionnement et dans ce cas, par exemple selon le standard MPEG TS on utilise une horloge interne. Le module S&R enregistré dans récepteur prend alors en compte les valeurs d'horloge 15 transmise et détermine les valeurs et le serveur web a accès aux valeurs de l'horloge utilisée lors de la diffusion. De cette façon, le récepteur peut calculer son propre décalage temporel par rapport à l'horloge du réseau de diffusion. Ce décalage est constant dans le temps, de sorte que le récepteur peut, lors d'une interruption suivi d'une reprise, le transmettre 20 pour recevoir les bons fichiers. Selon un perfectionnement, le récepteur reçoit une indication sur la durée de reproduction du contenu enregistré dans la mémoire gérée circulairement. Dans ce cas, le récepteur peut soustraire la taille de la mémoire à son heure courante pour déterminer la position du pointeur. Si l'heure résultat est antérieure à l'heure de l'arrêt de l'écoute 25 alors il est possible de proposer la fonction S&R à l'utilisateur, sinon ce n'est pas possible. Cette analyse doit être réalisée cycliquement toutes les 1 secondes par exemple, afin d'arrêter de proposer cette fonction à l'utilisateur dès que l'heure de reprise sort de la plage de temps couverte par la mémoire circulaire. La reprise de la lecture à partir de la mémoire circulaire peut prendre un peu de 30 temps. Ce délai est variable est fortement dépendant du débit réseau disponible pour le 19 récepteur. Il y a donc un risque, pour l'utilisateur, de demander la reprise de lecture et que le contenu ne soit plus disponible au moment où le serveur de streaming reçoit la requête. Afin d'éviter ce disfonctionnement et selon un autre perfectionnement, le récepteur peut supprimer l'accès à la fonction S&R, une minute par exemple, avant la 5 fin réelle de disponibilité du service. 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, 10 les présents modes de réalisation doivent être considérés à titre d'illustration REVENDICATIONS1. Procédé de transmission d'un contenu audio interrompu dans un récepteur hybride en vue d'une reproduction en différé, le procédé comprenant au moins les étapes suivantes : - une étape de réception d'un flux déterminé diffusé sur un réseau et reproduction des contenus transmis par ledit flux au niveau du récepteur, - une étape de détection d'un premier événement extérieur au récepteur déclenchant l'interruption de la reproduction du contenu en cours et l'enregistrement du moment de l'interruption, - une étape ultérieure de détection d'un second événement extérieur déclenchant une étape de transmission du récepteur vers un serveur distant du moment datant le premier événement et d'une requête de reprise de reproduction du contenu interrompu, - une étape de transmission du serveur distant vers le récepteur d'une information spécifiant les identifiants des paquets de données du contenu au moment de l'interruption, - une étape de transmission des paquets de données du contenu ainsi identifiés, et réception par le récepteur desdits paquets de données en vue de leur reproduction en différé. 2. Procédé de transmission d'un contenu audio selon la revendication 1, caractérisé en ce que l'information transmise par le serveur distant vers le récepteur comporte un manifeste identifiant une succession de chunks dont le premier contient les paquets de données du contenu au moment de l'interruption. 3. Procédé de transmission d'un contenu audio selon la revendication 2, caractérisé en ce que le manifeste transmis identifie tous les chunks disponibles sur le serveur contenant le contenu audio diffusé entre le moment de l'interruption et le moment présent. 4. Procédé de transmission d'un contenu audio selon la revendication 3, caractérisé en ce que le manifeste transmis identifie tous les chunks mémorisés dans le serveur à partir du 21 moment où l'intervalle de temps entre le moment de l'interruption et le moment présent dépasse la durée de tous les chunks mémorisés dans le serveur. 5. Procédé de transmission d'un contenu audio selon la revendication 1, caractérisé en ce que l'information transmise par le serveur distant vers le récepteur comporte une adresse de lecture dans un buffer circulaire d'un autre serveur distant, cette adresse correspondant à la première trame audio de la partie restante du contenu non lu, le serveur transmettant par la suite les trames audio de la partie restante du contenu non lue. 10 6. Procédé de transmission d'un contenu audio selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte une étape de détermination de l'heure courante au moment de la transmission du récepteur vers le serveur distant du moment datant le premier événement et d'une étape de calcul de l'écart temporel entre 15 la dite heure courante reçue et l'heure courante du serveur, les paquets de données du contenu au moment de l'interruption étant datés par l'heure transmise à laquelle est retranchée l'écart calculé. 7. Procédé de transmission d'un contenu audio selon l'une quelconque des 20 revendications précédentes, caractérisé en ce qu'il comporte une étape de modification de l'interface utilisateur pendant une durée limitée spécifiant que le service d'interruption de la reproduction du contenu et de reprise pour une transmission en différé, n'est pas disponible pendant cette durée limitée. 25 8. Procédé de transmission d'un contenu audio selon l'une quelconque des revendications précédentes, caractérisé en ce que le contenu audio interrompu puis repris en différé est reçu au niveau du récepteur hybride dans un format selon l'un des standards de la liste suivante : MPEG, HLS, ou DASH. 22 9. Procédé de transmission d'un contenu audio selon l'une quelconque des revendications précédentes, caractérisé en ce que le contenu audio est lu au niveau du serveur à partir d'une mémoire gérée circulairement. 5 10. Récepteur hybride pour la reproduction d'un contenu audio en provenance d'un flux déterminé diffusé sur un premier réseau, ledit récepteur comportant un moyen de réception (4) du flux déterminé diffusé sur ledit premier réseau, un moyen de communication (5) avec un serveur distant et un moyen de reproduction (8, 9) de ce contenu audio en vue d'une reproduction en différé, ledit récepteur étant caractérisé en 10 ce qu'il comporte en outre : - un premier moyen de détection d'un premier événement extérieur au récepteur déclenchant l'interruption de la reproduction du contenu en cours et l'enregistrement d'au moins le moment de l'interruption fourni par une horloge interne, - un second moyen de détection d'un second événement extérieur pour la reprise 15 de la réception dudit contenu déclenchant la transmission vers un serveur distant du moment datant le premier événement et d'une requête pour recevoir les paquets de données de contenu diffusé à partir dudit moment, le moyen de communication (5) recevant les paquets de données ainsi identifiés et destinés à être reproduits avec un différé. 20 11. Système de reproduction d'un contenu audio comportant un récepteur hybride doté d'un moyen de réception dudit contenu audio en provenance d'un flux déterminé diffusé sur un réseau et d'un moyen de reproduction de ce contenu audio en vue d'une reproduction en différé, 25 caractérisé en ce qu'il comporte un premier moyen de détection d'un premier événement extérieur au récepteur déclenchant l'interruption de la reproduction du contenu en cours et l'enregistrement du moment de l'interruption, et un second moyen de détection d'un second événement extérieur déclenchant la transmission du récepteur vers un serveur distant du moment datant le premier événement et d'une requête de reprise de 30 reproduction du contenu interrompu, le système comportant un serveur recevant du récepteur une information spécifiant les identifiants des paquets de données du contenu 23 au moment de l'interruption et émettant vers le récepteur des paquets de données ainsi identifiés destinés à être reproduits avec un différé. 12. Produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 9, lorsque ledit programme est exécuté sur un ordinateur.