FR3054765B1 - Procede pour la lecture sur un equipement d'un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne - Google Patents

Abstract

La présente invention concerne un procédé pour la lecture sur un équipement (1) connecté à un réseau étendu (10) d'un contenu multimédia avec un retard cible par rapport au direct inférieur à un retard maximal donné, le procédé étant caractérisé en ce qu'il comprend la mise en œuvre d'étapes de : (a) Emission, depuis un réseau de diffusion de contenus (20) disposé au sein du réseau étendu (10), dudit contenu sous la forme d'une pluralité de flux multicast chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal ; (b) Réception par l'équipement (1) du flux de ladite pluralité présentant le retard prédéterminé le plus proche par valeur supérieure dudit retard cible ; (c) Lecture en continu dudit flux reçu.

Description

PROCEDE POUR LA LECTURE SUR UN EQUIPEMENT D’UN CONTENU MULTIMEDIA AVEC UN RETARD CIBLE PAR RAPPORT AU DIRECT INFERIEUR A UN RETARD MAXIMAL DONNE

DOMAINE TECHNIQUE GENERAL

La présente invention concerne le streaming de contenus multimédia, et en particulier un procédé pour la lecture sur un équipement d’un contenu multimédia avec un retard par rapport au direct.

ETAT DE L’ART L’IPTV, ou télévision sur IP, est une forme de télévision diffusée sur le réseau internet. Elle est souvent fournie soit avec l'offre d'abonnement Internet haut débit (dans ce cas-là elle utilise la même infrastructure que l'accès Internet, mais avec une bande passante réservée, dans la mesure où le flux TV est reçu depuis des serveurs de l’opérateur disposés dans leur propre réseau), soit dans un contexte OTT (par contournement en français), c’est-à-dire sans la participation d'un opérateur de réseau traditionnel (dans ce cas-là elle consomme la bande-passante internet au même titre que n’importe quel autre service, dans la mesure où le flux TV est reçu depuis des serveurs internet du fournisseur de services).

La télévision peut ainsi être regardée soit sur un écran classique le plus souvent grâce à un boitier dédié appelé Set-Top Box, soit directement sur un équipement connecté (ordinateur personnel, smartphone, etc.).

Le terme IPTV regroupe la télévision classique en direct (avec un grand nombre de chaînes, en particulier des chaînes privées pour ΓΟΤΤ), mais également la VoD (en français vidéo à la demande) et le replay (en français télévision de rattrapage), qui permet de regarder avec du retard un contenu préalablement diffusé en direct.

Diffuser la télévision en direct s’avère facile, car il est possible d’utiliser une solution IP multicast (un flux est adressé depuis un serveur à plusieurs clients), ce qui permet d'envoyer les données une seule fois pour plusieurs personnes. Plus précisément, lorsqu’un téléspectateur regarde un flux TV en multicast, il consomme une ressource partagée avec d’autres, et la bande passante consommée par le réseau est quasiment identique quel que soit le nombre de téléspectateurs.

En revanche, la VoD et le replay doivent utiliser une solution IP unicast (un flux est adressé depuis un serveur à un seul client, via une liaison point à point), ce qui signifie que les serveurs de mise à disposition génèrent autant de flux qu’il y a des demandes, chaque téléspectateur recevant « son » flux.

Dans le cas de l’OTT, cela s’avère problématique car la bande passante consommée est proportionnelle au nombre de spectateurs utilisant ces services de VoD ou replay, et leur nombre est en augmentation. Si beaucoup de personnes tentent d’accéder au service simultanément (par exemple pour regarder un match de football de façon décalée), il risque d’y avoir des ralentissements et des baisses de qualité très gênantes.

Des solutions ont été proposées pour réduire la bande-passante consommée, ces solutions consistant à tenter de détecter les téléspectateurs voulant regarder le même contenu au même moment, et leur envoyer un flux en multicast.

Outre le fait que faire une telle détection est complexe et coûteux en ressources, on constate que cela permettrait d’économiser au mieux une poignée seulement de flux unicast, et ne diminuerait que marginalement la bande-passante consommée. II serait ainsi souhaitable de disposer d’une nouvelle méthode de diffusion de contenus vidéo sur internet qui soit bien plus économe en termes de bande-passante tout en maximisant l’expérience utilisateur.

PRESENTATION DE L’INVENTION

Selon un premier aspect, la présente invention se rapporte donc à un procédé pour la lecture sur un équipement connecté à un réseau étendu d’un contenu multimédia avec un retard cible par rapport au direct inférieur à un retard maximal donné, le procédé étant caractérisé en ce qu’il comprend la mise en oeuvre d’étapes de : (a) Emission, depuis un réseau de diffusion de contenus disposé au sein du réseau étendu, dudit contenu sous la forme d’une pluralité de flux multicast chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal ; (b) Réception par l’équipement du flux de ladite pluralité présentant le retard prédéterminé le plus proche par valeur supérieure dudit retard cible ; (c) Lecture en continu dudit flux reçu.

Selon d’autres caractéristiques avantageuses et non limitatives : • sont émis à l’étape (a) des flux multicast tels que le k-ième flux multicast est associé à un retard de k*At, où Δί est un pas de temps prédéterminé ; • Δί est compris entre trente secondes et dix minutes, préférentiellement entre une minute et cinq minutes ; • ledit réseau de diffusion de contenus comprend au moins un premier serveur et un deuxième serveur, le procédé comprenant une étape préalable (aO) d’émission par le premier serveur d’une pluralité de flux unicast du contenu multimédia chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal, le deuxième serveur recevant chaque flux unicast et générant à partir de chaque flux unicast un flux multicast de sorte à générer ladite pluralité de flux multicast ; • l’étape (aO) comprend la conversion préalable par un serveur fournisseur connecté au réseau de diffusion de contenu dudit contenu multimédia en séquence de segments formant flux ; • l’étape (aO) comprend la requête par le deuxième serveur auprès du serveur fournisseur de ladite pluralité de flux unicast du contenu multimédia chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal ; • une pluralité de profils est disponible pour chaque flux multicast, chaque profil étant associé à un port sur une adresse du flux multicast.

Selon un deuxième aspect, l’invention concerne un ensemble comprenant :

Un réseau de diffusion de contenus disposé au sein d’un réseau étendu, comprenant au moins un deuxième serveur configuré pour émettre un contenu multimédia sous la forme d’une pluralité de flux multicast chacun associé avec un retard prédéterminé par rapport au direct inférieur à un retard maximal donné ;

Un équipement connecté au réseau étendu et configuré pour recevoir le flux de ladite pluralité présentant le retard prédéterminé le plus proche par valeur supérieure d’un retard cible, et lire en continu ledit flux reçu.

Selon d’autres caractéristiques avantageuses et non limitatives : • le réseau de diffusion de contenus comprend un premier serveur configuré pour émettre une pluralité de flux unicast du contenu multimédia chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal, le deuxième serveur étant en outre configuré pour recevoir chaque flux unicast et généré à partir de chaque flux unicast un flux multicast de sorte à générer ladite pluralité de flux multicast ; • l’ensemble comprend en outre un serveur fournisseur connecté au réseau de diffusion de contenu et configuré pour convertir ledit contenu multimédia en séquence de segments formant flux.

Selon un troisième et un quatrième aspect, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de l’invention pour la lecture sur un équipement connecté à un réseau étendu d’un contenu multimédia avec un retard cible par rapport au direct inférieur à un retard maximal donné ; et des moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon le premier aspect de l’invention pour la lecture sur un équipement connecté à un réseau étendu d’un contenu multimédia avec un retard cible par rapport au direct inférieur à un retard maximal donné.

PRESENTATION DES FIGURES D’autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description qui va suivre d’un mode de réalisation préférentiel. Cette description sera donnée en référence aux dessins annexés dans lesquels : la figure 1 représente une architecture dans laquelle est mis en oeuvre le procédé selon l’invention ; la figure 2a représente schématiquement le principe de diffusion en différé conforme à l’art antérieur; la figure 2b représente schématiquement le principe de diffusion en différé conforme au procédé selon l’invention; la figure 3 illustre un exemple de mise en oeuvre d’un mode de réalisation préférée du procédé selon l’invention.

DESCRIPTION DETAILLEE

Lecture différée

La présente invention vise à traiter un cas particulier de replay couramment proposé aux téléspectateurs, celui de la lecture en différé. II s’agit regarder un contenu « presque » en direct, en d’autres termes avec un faible retard (dit retard cible dans la suite de la présente description, même comme l’on verra plus loin il peut y avoir une légère différence entre le retard cible et le retard réel de l’utilisateur, selon les préférences de ce dernier) de l’ordre de l’heure (typiquement de quelques minutes à quelques heures) par rapport au « live », c’est-à-dire l’instant du direct. Cela est également appelé le « start over » car cela permet de redémarrer la lecture du contenu.

On constate en effet que ce type de replay, qui voit aujourd’hui comme expliqué la nécessité d’émettre une pluralité de flux unicast, est de plus en plus sollicité par les téléspectateurs, et ce a fortiori en cas de forte audience (par exemple lors d’un match de football ou d’un concert très attendu), d’où les problèmes de bande-passante.

La présente invention concerne ainsi un procédé de lecture sur un équipement 1 d’un contenu multimédia « en différé », c’est à dire avec un retard par rapport au direct inférieur à un retard maximal donné (comme expliqué quelques heures, avantageusement trois heures), appelé « profondeur ».

Pour des retards supérieurs, on utilisera le replay classique, i.e. l’émission de flux unicast à la demande.

Architecture

En référence à la figure 1, le présent procédé est mis en oeuvre entre un « réseau de diffusion de contenu » 20, appelé CDN (Content Distribution Network), et un « client » 1. Ce dernier est un équipement multimédia grand public tel qu’un smartphone, une tablette tactile, un ordinateur personnel, une télévision connectée, une console de jeux, un boîtier multimédia secondaire (set top box), etc., adapté pour la lecture de contenus multimédia (typiquement des contenus audio ou vidéo).

De façon préférée, le contenu multimédia est un contenu vidéo correspondant à une chaîne de télévision (le contenu est émis en continu sur toute la journée).

De façon générale, l’équipement 1 comprend des moyens de traitement de données 11 tel qu’un processeur, éventuellement des moyen de stockage de données 12 tel qu’une mémoire, par exemple un disque dur, et des moyens de restitution 10 qui consistent généralement en un moyen d’affichage vidéo (un écran ou une sortie vidéo sécurisée) et/ou des moyens de restitution sonore (un ou plusieurs haut-parleurs). Les moyens de restitution 10 peuvent constituer un ou plusieurs élément physiquement indépendant d’un élément abritant les moyens de traitement de données 11 (par exemple un moniteur d’un côté et une unité centrale de l’autre).

Avantageusement, les moyens de traitement 11 (et le cas échant les moyens de stockage 12) sont ceux d’un composant électronique dédié au présent procédé et intégré dans l’équipement 1 (par exemple une puce d’une carte fournie par un fournisseur des contenus ou un opérateur, par exemple une carte SIM) qui peut comprendre notamment un autre processeur pour le reste des traitements usuels. Un tel mode de réalisation garantit une sécurité optimale, en particulier dans un environnement DRM (Digital Right

Management, i.e. gestion des droits numériques), c’est-à-dire dans lequel les contenus multimédia à restituer sont transmis chiffrés.

Alternativement, les moyens de traitement 11 sont le processeur classiquement utilisé par l’équipement 1 et le présent procédé est avantageusement mis en œuvre via un module logiciel exécuté par ce processeur, ledit module étant préférentiellement fourni et installé par ledit fournisseur des contenus ou opérateur pour en garantir l’intégrité. En particulier, ce module peut être intégré à une application de lecture de contenus, par exemple un player vidéo. Ainsi, l’utilisateur n’a qu’à ouvrir cette application s’il veut lire un contenu, l’application gérant à la fois la requête du contenu multimédia, le cas échéant son déchiffrement (s’il est protégé par DRM), et sa lecture à la volée, et ce de façon complètement transparente pour l’utilisateur. L’équipement client 1 est connecté à un réseau étendu 10, typiquement le réseau internet.

Le CDN 20 est constitué de serveurs (en particulier les serveurs 2, 3 et 5 dont on verra en détail plus loin le fonctionnement) reliés en réseau à travers le réseau étendu 10 et qui coopèrent afin de mettre des contenus multimédia à disposition des utilisateurs.

Carrousel multicast

Le présent procédé résout les problèmes précités en mettant en œuvre une étape (a) d’émission, depuis le CDN 20, du contenu multimédia sous la forme d’une pluralité de flux multicast chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal.

En d’autres termes, au lieu d’émettre un flux unicast pour chaque demande de lecture du contenu en différé, sont émis une pluralité de flux multicast entre lesquels l’utilisateur va choisir. On comprendra que tous les flux multicast sont tous identiques et seulement décalés dans le temps.

Avantageusement, un flux est initié toutes les X minutes après le direct. Cela signifie que les flux multicast émis sont tels que le k-ième flux multicast est associé à un retard de k*At, où Δί est un pas de temps prédéterminé. Ce pas de temps Δί est avantageusement compris entre trente secondes et dix minutes, préférentiellement entre une minute et cinq minutes, encore plus préférentiellement environ deux minutes. L’équipement 1 n’a plus qu’à se caler sur le prochain flux multicast lorsqu’il veut lire le contenu en différé. Ainsi dans une étape (b), l’équipement 1 (ou plutôt ses moyens de traitement 11) reçoit le flux de ladite pluralité présentant le retard prédéterminé le plus proche par valeur supérieure dudit retard cible. Une adresse du flux peut être requise auprès du CDN manager 5, et l’équipement 1 s’y connecte.

Ledit flux reçu est alors lu en continu (comme si le contenu était en direct) au niveau de l’équipement 1 dans une étape (c), pour restitution sur les moyens de restitution 10 de l’équipement 1 et/ou stockage sur la mémoire 12. II est à noter que la restitution peut être mise en oeuvre soit par les moyens de traitement 11, soit d’autres composants dédiés tels qu’une carte graphique. Cette étape (c) peut comprendre le déchiffrement du flux s’il est chiffré par DRM. II est d’ailleurs possible de déchiffrer et rendre le flux « à la volée », c’est-à-dire à la chaîne, suivant la séquence de segments qui le constitue.

La présente solution peut être vue comme un « carrousel » dans la mesure où il suffit d’attendre le prochain flux pour lire le contenu en différé (ainsi dans un premier mode de réalisation le retard cible correspond exactement au retard de l’utilisateur, i.e. le retard cible est calculé comme la différence entre l’heure du début du direct et l’heure de requête de lecture du contenu en différé par l’utilisateur), ou même de prendre en route un flux dont l’émission a commencé il y a peu de temps pour n’avoir aucune attente et n’avoir presque rien manqué du contenu (dans un second mode de réalisation il peut être par exemple défini que le retard cible est le retard de l’utilisateur moins une durée prédéterminé, par exemple une minute, voire un pas de temps complet ; ou tout simplement que le retard cible est configurable). A titre d’exemple, si le pas entre deux flux est de deux minutes, et si l’utilisateur requiert sur son équipement la lecture du contenu 34min30s après le début du direct, alors l’émission du 17e flux différé aura été démarrée 34 minutes après le début du direct, et le 18e démarrera 36 minutes après le début du direct. II sera alors proposé à l’utilisateur d’attendre 1min30s (par exemple en diffusant des publicités) de sorte à recevoir et lire « en direct » le 18e flux. Si l’on avait défini que le retard cible était le retard de l’utilisateur moins une minute (celui-ci passe donc à +33min30s), alors l’algorithme définit que le 17e flux démarré à +34min est le plus proche par valeur supérieur. II est alors proposé à l’utilisateur de recevoir et lire « en direct» le 17e flux, il manque donc les premières 30 secondes du contenu mais n’a aucune attente, ce qui est plus confortable.

On notera par ailleurs que le retard cible reste une valeur qui peut être manuellement définie par l’utilisateur, et peut être complément décorrélée du retard réel par rapport au direct.

Par exemple, on peut envisager un scénario dans lequel l’utilisateur regarderait en direct pendant un quart d’heure, puis serait interrompu une vingtaine de minutes (par exemple par un appel téléphonique). A ce moment (à +35min par rapport au direct), s’il souhaite continuer sa lecture, il peut sauter les quinze premières minutes qu’il a déjà vues en indiquant directement au niveau de l’équipement qu’il requiert un retard cible de seulement vingt minutes (la durée de l’interruption). L’émission du flux à +15min a en effet commencé vingt minutes auparavant et lui permet donc de reprendre instantanément la lecture où il l’avait laissée. Aucune attente n’est nécessaire puisque la diffusion de ce flux est déjà en cours, au pire l’utilisateur reverra une poignée de secondes du contenu (ou en manquera une poignée de secondes) sans incidence sur son expérience.

On pourrait même envisager que l’utilisateur sache qu’il va avoir un certain retard, et donc qu’il indique ce retard comme retard cible alors même qu’il pourrait regarder le contenu en direct. Le système va alors simplement se mettre en attente jusqu’à ce que le flux correspondant commence à être diffusé.

Dans tous les cas, les valeurs de pas de temps proposées précédemment sont un bon équilibre entre temps moyens d’attente avant le début de la lecture ou durée sautée (en moyenne une minute), et nombre de flux multicast à prévoir (si le retard maximal est 3h, 90 flux multicast suffisent, à comparer avec les centaines de milliers nécessaires en utilisant des flux unicast).

Cela réduit donc très fortement la bande-passante nécessaire.

CDN

Va à présent être décrite une structure particulière de CDN particulièrement adaptée pour la mise en oeuvre du présent procédé et ne nécessitant que très peu de modifications par rapport à une structure existante. La figure 2a représente à ce titre le principe conforme à l’art antérieur de diffusion de contenus multimédia dans un service de lecture en différé.

Comme l’on voit, le contenu multimédia est diffusé sous la forme d’un flux unicast (par exemple en http en utilisant le protocole de transport TCP) depuis un premier serveur 2 du CDN 20, le « streamer», c’est-à-dire un serveur configuré pour servir le contenu à un ou plusieurs équipements 1 sous la forme d’une pluralité de segments envoyés à tour de rôle (constituant le flux continu). Le CDN 20 présente généralement un grand nombre de streamers 2 pour gérer un grand nombre de demandes d’utilisateurs

Plus précisément, les streamers 2 sont des serveurs dédiés à l’émission en mettant à disposition les segments de divers contenus conformément à un protocole de streaming donné. On citera par exemple l’exemple de HLS (« HTTP Live Streaming »), dans lequel les segments sont des fichiers « ts », listés dans un fichier playlist « m3u8 ». HLS implique le format MPEG2 pour le contenu. On citera également les protocoles de streaming DASH, Smooth streaming, ou HDS.

En amont du CDN 20, on trouve un serveur fournisseur 4 (appelé « packager ») dédié à la génération à la volée et au chiffrement (en cas de DRM) des flux à partir des contenus « bruts » (fournis par exemple par les opérateurs de télévision dans le cas de chaînes) dans le format de streaming souhaité. Dans le cas de flux vidéos, ces derniers sont avantageusement enregistrés en permanence dans un format pivot (tel que fragmented TS) sur des moyens de stockage du packager 4, typiquement pour une durée de quelques jours. Les streamers peuvent eux-mêmes comporter une mémoire cache pour stocker temporairement les flux, avantageusement sur une durée du même ordre de grandeur que la profondeur maximale.

On comprendra que le packager 4 est destiné à la génération des flux, et le CDN 20 à leur transmission vers les équipements 1.

Le CDN 20 comprend généralement en outre un serveur de gestion 5 (appelé « CDN manager ») pour le contrôle des streamers 2.

Ainsi le principe de fonctionnement classique est le suivant : l’utilisateur requiert la lecture en différé d’un contenu depuis son équipement 1 auprès du CDN manager 5, qui transmet la demande au packager 4 qui fournit en réponse un manifeste construit pour le retard de lecture souhaité. Ce fichier est un descriptif du flux (au format XML pour la plupart des protocoles de streaming sauf HLS), qui contient notamment la liste des segments.

Sur la base du manifeste, l’équipement 1 sait à quel streamer 2 s’adresser et quelles est la série de segments qu’il doit récupérer.

La figure 2b représente le principe selon l’invention de diffusion de contenus multimédia dans un service de lecture en différé.

Par rapport à l’architecture existante, on voit qu’il suffit d’ajouter un deuxième serveur 3 dans le CDN, appelé le « transcaster » qui va être l’équipement générant ladite pluralité de flux multicast.

En effet, le transcaster 3 permet de recevoir des flux unicast et générer des flux multicast correspondant pour rediffusion dans le CDN 20, par exemple en encapsulant chaque flux unicast dans un flux multicast. A noter que TCP supporte seulement un mode unicast, c’est pourquoi on utilisera par exemple le protocole de transport UDP au niveau du transcaster 3.

On pourra par exemple utiliser le système de transcaster nanoCDN™ de Broadpeak.

Le présent procédé comprend ainsi avantageusement une étape préalable (aO) de génération par le premier serveur 2 (le streamer) d’une pluralité de flux unicast du contenu multimédia chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal, le deuxième serveur 3 (le transcaster) recevant chaque flux unicast et générant à partir de chaque flux unicast reçu un flux multicast (en particulier en l’encapsulant dans un flux multicast) de sorte à générer ladite pluralité de flux multicast.

Lorsque le transcaster 3 démarre, il fait les demandes de manifeste vidéo au CDN Manager 5, avec tous les incréments de décalage souhaités (c’est-à-dire l’ensemble des retards prévus).

Le CDN Manager 5 transfert ces demandes au packager 4, qui les reçoit comme s’il s’agissait de demandes provenant d’équipements 1 Le packager 4 fournit un manifeste construit sur la période de temps souhaitée par le transcaster 3.

Sur la base des manifestes, le transcaster 4 sait à quel(s) streamer(s) 2 il doit s’adresser et quelles sont les séquences de segments qu’il doit récupérer.

Le transcaster 4 encapsule ensuite dans un flux Multicast chaque flux unicast reçu du streamer 2 pour le diffuser vers le ou les équipements 1. Dans le cas d’une encapsulation du flux unicast dans un flux multicast, ce dernier est ouvert à réception dans le réseau local de l’équipement pour récupération du flux unicast contenu et lecture par l’équipement 1. On comprendra ainsi que les versions unicast des flux n’existent qu’au sein du CDN 20 ou des réseaux locaux des équipements 1.

Le présent mode de réalisation s’avère très avantageux car il réutilise l’architecture existante en rajoutant seulement le transcaster 4 qui a pour rôle de « commander » les flux unicast avec retard (comme le ferait un équipement 1) et les convertir en multicast pour diffusion.

Autres modes de réalisation

En référence à la figure 3, qui représente de façon récapitulative le procédé (exemple de cinq décalages temporels avec un pas de deux minutes pour une profondeur de dix minutes), plusieurs « profils » différents sont avantageusement diffusés pour chaque flux multicast, sur la même adresse mais sur des ports différents de cette adresse.

Par « profil », on entend différentes versions du contenu véhiculé par le flux, en particulier en termes de qualité (bitrate, i.e. le taux d’échantillonnage), mais également de format, de DRM, etc. Le bitrate va typiquement de quelques centaines de kbit/s à quelques Mbit/s dans le cas de contenus vidéo.

Dans l’exemple représenté sur la figure 3, chaque flux multicast présente une adresse du type @239.0.0.k, pour le k-ième flux, et est disponibles en trois bitrates (et un seul format), correspondant respectivement aux ports 5000, 5001 et 5002.

Cela permet de garder un seul flux par contenu et par incrément de temps de retard.

Si les contenus sont des chaînes de télévision (une quarantaine bénéficie d’un service de start over), en prenant comme expliqué un pas de temps de deux minutes et un retard maximal de trois heures, on obtient que 3600 adresses multicast suffisent pour la totalité du traffic, quel que soit le nombre d’équipements 1 connectés. Cela est extrêmement réduit par rapport à l’art antérieur, sans diminution de l’expérience pour les utilisateurs (au pire quelques dizaines de secondes d’attente) et même plutôt une augmentation de la qualité car il y aura moins de risque de latence.

Equipement

Selon un deuxième aspect, l’invention concerne un ensemble pour la mise en oeuvre du procédé selon le premier aspect.

Cet ensemble comprend comme expliqué un réseau de diffusion de contenus (CDN) 20 émetteur de flux, et au moins un équipement receveur de flux.

Le CDN 20, disposé au sein d’un réseau étendu 10, comprend au moins un deuxième serveur 3 configuré pour émettre un contenu multimédia sous la forme d’une pluralité de flux multicast chacun associé avec un retard prédéterminé par rapport au direct inférieur à un retard maximal donné, et avantageusement un premier serveur 2 configuré pour émettre une pluralité de flux unicast du contenu multimédia chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal, le deuxième serveur 3 étant en outre configuré pour recevoir chaque flux unicast et générer à partir de chaque flux unicast (en particulier par encapsulation) un flux multicast de sorte à générer ladite pluralité de flux multicast. L’équipement 1 est connecté au réseau étendu 10 et est configuré pour recevoir (et plus précisément configuré pour identifier son adresse) le flux de ladite pluralité présentant le retard prédéterminé le plus proche par valeur supérieure d’un retard cible, et lire en continu ledit flux reçu.

Comme expliqué l’ensemble peut comprendre en outre un serveur fournisseur 4 connecté au réseau de diffusion de contenu 20 et configuré pour convertir ledit contenu multimédia en séquence de segments formant flux.

Produit programme d’ordinateur

Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (en particulier via les moyens de traitement des serveurs 2, 3, 4, 5 et de l’équipement 1) du procédé pour la lecture sur un équipement 1 connecté à un réseau étendu 10 d’un contenu multimédia avec un retard cible par rapport au direct inférieur à un retard maximal donné, ainsi que des moyens de stockage lisibles par un équipement informatique (notamment des moyens de stockage de données des serveurs 2, 3, 4, 5 et de l’équipement 1) sur lequel on trouve ce produit programme d’ordinateur.

Claims (10)

1. REVENDICATIONS

   1. Procédé pour la lecture sur un équipement (1) connecté à un réseau étendu (10) d’un contenu multimédia avec un retard cible par rapport au direct inférieur à un retard maximal donné, le procédé étant caractérisé en ce qu’il comprend la mise en œuvre d’étapes de : (a) Emission, depuis un réseau de diffusion de contenus (20) disposé au sein du réseau étendu (10) et comprenant au moins un premier serveur (2) et un deuxième serveur (3), dudit contenu sous la forme d’une pluralité de flux multicast chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal ; (b) Réception par l’équipement (1) du flux de ladite pluralité présentant le retard prédéterminé le plus proche par valeur supérieure dudit retard cible ; (c) Lecture en continu dudit flux reçu ; le procédé comprenant une étape préalable (aO) d’émission par le premier serveur (2) d’une pluralité de flux unicast du contenu multimédia chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal, le deuxième serveur (3) recevant chaque flux unicast et générant à partir de chaque flux unicast un flux multicast de sorte à générer ladite pluralité de flux multicast
2. 2. Procédé selon la revendication 1, dans lequel sont émis à l’étape (a) des flux multicast tels que le fc-ième flux multicast est associé à un retard de k*At, où Δί est un pas de temps prédéterminé.
3. 3. Procédé selon la revendication 2, dans lequel Δί est compris entre trente secondes et dix minutes, préférentiellement entre une minute et cinq minutes.
4. 4. Procédé selon l’une des revendications 1 à 3, dans lequel l’étape (aO) comprend la conversion préalable par un serveur fournisseur (4) connecté au réseau de diffusion de contenu (20) dudit contenu multimédia en séquence de segments formant flux.
5. 5. Procédé selon la revendication 4, dans lequel l’étape (aO) comprend la requête par le deuxième serveur (3) auprès du serveur fournisseur (4) de ladite pluralité de flux unicast du contenu multimédia chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal.
6. 6. Procédé selon l’une des revendications précédentes, dans lequel une pluralité de profils est disponible pour chaque flux multicast, chaque profil étant associé à un port sur une adresse du flux multicast.
7. 7. Ensemble comprenant : - Un réseau de diffusion de contenus (20) disposé au sein d’un réseau étendu (10), comprenant au moins un deuxième serveur (3) configuré pour émettre un contenu multimédia sous la forme d’une pluralité de flux multicast chacun associé avec un retard prédéterminé par rapport au direct inférieur à un retard maximal donné, et un premier serveur (2) configuré pour émettre une pluralité de flux unicast du contenu multimédia chacun associé avec un retard prédéterminé par rapport au direct inférieur au retard maximal, le deuxième serveur (3) étant en outre configuré pour recevoir chaque flux unicast et générer à partir de chaque flux unicast un flux multicast de sorte à générer ladite pluralité de flux multicast ; Un équipement (1) connecté au réseau étendu (10) et configuré pour recevoir le flux de ladite pluralité présentant le retard prédéterminé le plus proche par valeur supérieure d’un retard cible, et lire en continu ledit flux reçu.
8. 8. Ensemble selon la revendications 7, comprenant en outre un serveur fournisseur (4) connecté au réseau de diffusion de contenu (20) configuré pour convertir ledit contenu multimédia en séquence de segments formant flux.
9. 9. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 6 pour la lecture sur un équipement (1) connecté à un réseau étendu (10) d’un contenu multimédia avec un retard cible par rapport au direct inférieur à un retard maximal donné, lorsque ledit programme est exécuté par un ordinateur.
10. 10. Moyens de stockage lisibles par un équipement informatique sur lesquels un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 6 pour la lecture sur un équipement (1) connecté à un réseau étendu (10) d’un contenu multimédia avec un retard cible par rapport au direct inférieur à un retard maximal donné.