FR3096210A1 - Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution. - Google Patents

Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution. Download PDF

Info

Publication number
FR3096210A1
FR3096210A1 FR1906670A FR1906670A FR3096210A1 FR 3096210 A1 FR3096210 A1 FR 3096210A1 FR 1906670 A FR1906670 A FR 1906670A FR 1906670 A FR1906670 A FR 1906670A FR 3096210 A1 FR3096210 A1 FR 3096210A1
Authority
FR
France
Prior art keywords
content
version
segments
segment
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1906670A
Other languages
English (en)
Other versions
FR3096210B1 (fr
Inventor
Mathieu Rivoalen
Hervé MARCHAND
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1906670A priority Critical patent/FR3096210B1/fr
Publication of FR3096210A1 publication Critical patent/FR3096210A1/fr
Application granted granted Critical
Publication of FR3096210B1 publication Critical patent/FR3096210B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L’invention se rapporte à un Procédé de transmission d’un contenu à destination d’un terminal de restitution (8) via un réseau de communication, le contenu (C1) étant accessible depuis un serveur de contenus sous plusieurs versions associées à des qualités de restitution respectives, une version donnée comprenant respectivement plusieurs segments du contenu, caractérisé en ce qu’il comprend les étapes suivantes dans un dispositif (DI) s’intercalant entre le serveur de contenus et le terminal de restitution une première étape de réception au cours de laquelle le dispositif intermédiaire reçoit du serveur de contenus plusieurs versions d’un même contenu ; une deuxième étape de réception d’une requête d’accès à une version donnée du contenu ; et une étape de transmission, à destination du terminal de restitution, de segments associés à la version du contenu demandée lors de la deuxième étape de réception. FIGURE 1

Description

Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
Le domaine de l'invention est celui des contenus multimédia numériques, à savoir les contenus audio et/ou vidéo numériques.
Plus précisément, plusieurs versions du contenu sont disponibles ; l'invention concerne un procédé de transmission du contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
Les versions du contenu, aussi appelées représentations du contenu, sont associées à des qualités de restitution respectives.
Etat de la technique
Avec la généralisation de la communication sans fil à haut débit et la multiplication des équipements personnels de type téléphone intelligent (en anglais « Smartphone ») ou tablette, la consommation de contenus multimédia numériques, notamment vidéo et/ou audio, a fortement augmenté. En effet, l’accès à un contenu numérique depuis un réseau de type Internet est possible aujourd’hui, pour la plupart de ces équipements personnels, notamment lorsqu’ils appartiennent à un réseau de communication local, tel qu’un réseau domestique.
La diffusion de contenus numériques sur Internet est souvent basée sur des protocoles client-serveur de la famille HTTP (de l’anglais « Hyper Text Transfer Protocol »). En particulier, le téléchargement en mode progressif, dit téléchargement adaptatif progressif (en anglais « http Adaptive Streaming » ou HAS), des contenus numériques, aussi appelé streaming, permet de transporter et consommer les données en temps réel, c'est-à-dire que les données numériques sont transmises sur le réseau et restituées par le terminal au fur et à mesure de leur arrivée. Le terminal client, i.e l’équipement personnel, reçoit et stocke une partie des données numériques dans une mémoire tampon avant de les restituer. Ce mode de distribution est particulièrement utile quand le débit dont dispose l’utilisateur n’est pas garanti pour le transfert en temps réel de la vidéo.
Le téléchargement progressif adaptatif (HAS) permet de surcroît de diffuser et recevoir des données suivant différentes qualités, aussi appelées représentations ou versions, correspondant par exemple à différents débits. Ces différentes qualités sont décrites dans un fichier de paramètres disponible en téléchargement sur un serveur de données, par exemple un serveur de contenus. Quand le terminal client souhaite accéder à un contenu, ce fichier de description permet de sélectionner le bon format pour le contenu à consommer notamment en fonction de la bande passante disponible ou des capacités de stockage et de décodage du terminal client. Ce type de technique permet notamment de tenir compte des variations de bande passante sur la liaison entre le terminal client et le serveur de contenus.
Il existe plusieurs solutions techniques pour faciliter la distribution d’un tel contenu en streaming, comme par exemple les solutions propriétaires Microsoft® Smooth Streaming, Apple® HLS, Adobe® HTTP Dynamic Streaming ou encore la norme MPEG-DASH de l’organisme ISO/IEC qui sera décrite ci-après. Ces méthodes proposent d’adresser au client un ou plusieurs fichiers de description intermédiaires, appelés aussi documents ou manifest, contenant les adresses de différents segments à différentes qualités d’encodage du contenu multimédia.
Ainsi, la norme MPEG-DASH (pour l’anglais “Dynamic Adaptive Streaming over HTTP”, en français « diffusion en flux adaptatif dynamique sur HTTP ») est un standard de format de diffusion audiovisuelle sur Internet. Il se base sur la préparation du contenu en différentes présentations de qualité et débit variables, découpées en segments temporels de courte durée (de l’ordre de quelques secondes), également appelés « chunks », ou segments. Chacun de ces segments est rendu disponible individuellement au moyen d'un protocole d'échange. Le protocole principalement ciblé est le protocole HTTP, mais d'autres protocoles (par exemple FTP) peuvent également être utilisés. L'organisation des segments et les paramètres associés sont publiés dans un manifest au format XML.
Le principe sous-jacent à cette norme est que le client MPEG-DASH effectue une estimation de la bande passante disponible pour la réception des segments, et, en fonction du remplissage de sa mémoire tampon de réception, choisit, pour le prochain segment à charger, une qualité/version dont le débit :
- assure la meilleure qualité possible, et,
- permet un délai de réception compatible avec le rendu ininterrompu du contenu sur le terminal client.
Ainsi, pour s’adapter à la variation des conditions réseau, notamment en termes de bande passante, les solutions existantes de téléchargement adaptatif permettent au terminal client de passer d’une version du contenu encodée à un certain débit, à une autre encodée à un autre débit, au cours du téléchargement. En effet, chaque version du contenu est divisée en segments de même durée ; Pour permettre une restitution en continu du contenu sur le terminal client, chaque segment doit atteindre le terminal avant son instant programmé de restitution. La qualité perçue associée à un segment augmente avec la taille du segment, exprimée en bits, mais dans le même temps, des segments plus gros requièrent un temps de transmission plus important, et donc présentent un risque accru de ne pas être reçus à temps pour une restitution en continu du contenu.
Le terminal de restitution doit donc trouver un compromis entre la qualité globale du contenu, et sa restitution ininterrompue, en sélectionnant avec soin le prochain segment à télécharger, parmi les différents débits d’encodage proposés. Il existe pour ce faire différents algorithmes de sélection de la qualité du contenu en fonction de la bande passante disponible, qui peuvent présenter des stratégies plus ou moins agressives, ou plus ou moins sécuritaires.
De nombreux services de visualisation de ces contenus numériques existent tels que des services de streaming (en français, diffusion en mode continu, ou lecture en continu), la vidéo à la demande (VOD), la diffusion en différé de programmes télévisuels (Replay), ou encore les offres de type Network PVR (pour « Network Personal Video Recorder », i.e. un service d’enregistrement des contenus numériques, effectué par le fournisseur de contenus lui-même plutôt qu’au domicile de l’utilisateur final).
Un gros problème lié à l’utilisation du téléchargement progressif adaptatif HAS est qu’il est basé sur une transmission de contenus en mode point à point, ce qui entraine inévitablement une charge importante au niveau des plateformes de distribution des contenus et une charge importante sur le réseau de l’opérateur impactant la bande passante offerte par l’opérateur sur son réseau. Plus précisément, les contenus «LIVE» diffusés selon la technique HAS nécessitent une session unique pour chaque utilisateur entre le serveur et le terminal multimédia. Cela nécessite de dimensionner des serveurs de distribution de contenus en conséquence et entraine parfois des interruptions de service quand un contenu «LIVE» est très demandé (évènement sportif comme un match de Football par exemple). La diffusion de contenu en HAS est bien adaptée pour des contenus à la demande (VOD, Replay, …) mais est très consommatrice de ressource réseau (serveur et bande passante) pour des contenus en direct («LIVE»).
Il existe donc un besoin d’une technique permettant de diminuer la consommation de ressources réseaux lors de la diffusion de contenu selon la technologie HAS, tout en conservant une qualité d’images au moins aussi bonne que celles que fournissent les techniques actuelles.
L’invention
L’invention répond à ce besoin en proposant un procédé de transmission d’un contenu à destination d’un terminal de restitution via un réseau de communication, le contenu étant accessible depuis un serveur de contenus sous plusieurs versions associées à des qualités de restitution respectives, une version donnée comprenant respectivement plusieurs segments du contenu, caractérisé en ce qu’il comprend les étapes suivantes dans un dispositif s’intercalant entre le serveur de contenus et le terminal de restitution
- une première étape de réception au cours de laquelle le dispositif intermédiaire reçoit du serveur de contenus plusieurs versions d’un même contenu ;
- une deuxième étape de réception d’une requête d’accès à une version donnée du contenu ;
- et une étape de transmission, à destination du terminal de restitution, de segments associés à la version du contenu demandée lors de la deuxième étape de réception.
La transmission des requêtes d’accès à un contenu provenant des terminaux de restitution ne s’effectue plus vers le serveur de contenus mais vers un dispositif intermédiaire situé entre le serveur de contenus et le terminal de restitution. On verra dans la suite que la localisation du dispositif intermédiaire sera choisie au plus près du terminal de restitution ; de cette façon, les différentes versions du contenu numérique sont localisés au plus proche de l’utilisateur, sous-entendu du terminal de restitution. La délocalisation de différentes versions d’un contenu dans le dispositif intermédiaire permet de diminuer considérablement la charge du serveur de contenus car la communication n’est plus en mode point à point entre le serveur de contenus et le terminal de restitution comme dans l’état de la technique.
Avec l’invention, le serveur de contenus se limite à la transmission de versions d’un même contenu à destination des dispositifs intermédiaires. Le dispositif intermédiaire a en charge quant à lui la transmission d’une version des segments choisie judicieusement pour chaque terminal de restitution. On décrira dans la suite deux modes de réalisation pour la détermination des versions (ou qualités) des segments à transmettre ; un premier mode basé sur la technologie HAS introduite précédemment et dont l’utilisation nécessite un fichier manifest qui sera décrit plus tard ; et un deuxième mode basé sur une autre technologie dans laquelle le terminal de réception comprend un module de réception capable de requérir, sans utilisation d’un fichier manifest, une augmentation, ou une diminution, ou un maintien de la version des segments à transmettre depuis le dispositif intermédiaire.
La localisation choisie pour le dispositif intermédiaire est idéalement un dispositif ayant une fonction de routage de flux de données vers les terminaux de restitution et qui est idéalement capable de créer des groupes d’abonnements permettant de rassembler des utilisateurs souhaitant accéder à un même contenu numérique en même temps, en particulier un contenu «live» tel qu’une chaîne de télévision.
Selon un premier mode de réalisation, la version choisie pour au moins le premier segment temporel transmis est une version choisie par défaut. Ce premier mode vise à transmettre des premiers segments de préférence d’une version ayant un faible nombre d’octets et donc associée à une faible qualité de restitution. Ce premier mode permet de transmettre les premiers segments assez rapidement, du fait de la petite taille, vers le terminal de restitution concerné, de manière à ce que le ou les premiers segments soient reçus avant leur(s) instant (s) programmé(s) de restitution, respectivement ; la restitution s’effectue dans ce cas sans problème. On verra par la suite que la version des segments transmis varie dans le temps par la suite.
Selon un deuxième mode de réalisation, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, le choix de la version d’un segment ultérieur évolue en fonction d’une donnée issue du terminal de restitution, ladite donnée étant issue d’une comparaison entre la durée de transmission d’un segment précédemment transmis et la durée du segment temporel. Ce deuxième mode évite l’utilisation d’un fichier manifest définissant plusieurs versions possibles des segments. Dans ce deuxième mode, le terminal de restitution ne spécifie par une valeur précise d’une version mais une tendance à savoir une augmentation, ou une diminution, ou un maintien de la version pour les segments futurs à transmettre depuis le dispositif intermédiaire.
Selon un troisième mode de réalisation, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, le contenu reçu lors de la première étape de réception est un contenu transmis en mode multicast. Ce troisième mode de réalisation tire profit des avantages de la diffusion de contenu en multicast tout en permettant grâce à la présence du dispositif intermédiaire de sélectionner la meilleure version du segment temporel à transmettre à destination d’un terminal de restitution.
Selon un quatrième mode de réalisation, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, l’étape de réception est suivie d’une étape de stockage en mémoire des segments reçus du serveur de contenus ; dans ce quatrième mode de réalisation, l’étape de transmission d’un segment temporel d’une version donnée entraîne la suppression dans la mémoire du dispositif intermédiaire des autres versions du segment transmis. Ce deuxième mode permet de supprimer des segments qui ont déjà été restitués et d’augmenter de ce fait l’espace mémoire disponible pour le stockage d’autres segments dans le dispositif intermédiaire.
Selon un premier aspect matériel, l’invention se rapporte à un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de transmission d’un contenu numérique selon le procédé de transmission décrit ci-dessus, lorsqu’il est exécuté par un processeur.
Selon un deuxième aspect matériel, l’invention se rapporte à un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur tel que décrit ci-dessus.
Selon un troisième aspect matériel l’invention se rapporte à un dispositif, dit dispositif intermédiaire, apte à communiquer avec un serveur de contenus et avec des terminaux de restitution via un réseau de communication, un contenu étant accessible depuis le serveur de contenus sous plusieurs versions, une version donnée comprenant respectivement plusieurs segments du contenu,
comprenant :
a. un premier module de réception apte à recevoir du serveur de contenus plusieurs versions d’un même contenu ;
b. un deuxième module de réception apte à recevoir une requête d’accès à une version donnée d’un contenu ;
c. un module de transmission apte à transmettre, à destination du terminal de restitution, des segments associés à la version du contenu demandée lors de la de deuxième étape de réception.
Selon un deuxième aspect fonctionnel, l’invention se rapporte à un procédé d’accès par un terminal de restitution à un contenu numérique accessible depuis un dispositif, dit dispositif intermédiaire, plusieurs versions différentes du contenu étant accessibles, une version donnée comprenant respectivement plusieurs segments du contenu ayant des durées respectives, caractérisé en ce qu’il comprend les étapes suivantes
- une étape de réception au cours de laquelle le dispositif de restitution reçoit un segment d’une version donnée du contenu depuis le dispositif intermédiaire (DI);
- une deuxième étape de mesure de la durée de transmission du segment reçu et de comparaison avec la durée du segment temporel,
- en fonction du résultat de l’étape de mesure, une étape de transmission ou pas, à destination du dispositif intermédiaire, d’une demande d’accès à une autre version.
Selon un quatrième aspect matériel, l’invention se rapporte à un terminal de restitution comprenant de restitution à un contenu numérique accessible depuis un dispositif, dit dispositif intermédiaire, plusieurs versions différentes du contenu étant accessibles, une version donnée comprenant respectivement plusieurs segments du contenu, caractérisé en ce qu’il comprend
- un module de réception apte à recevoir un segment d’une version donnée du contenu depuis le dispositif intermédiaire ;
- un module de mesure apte à mesurer la durée de transmission du segment reçu et de comparer la durée mesurée avec la durée du segment temporel,
- un module de transmission apte à transmettre ou pas, à destination du dispositif intermédiaire, une demande d’accès à une autre version en fonction du résultat de l’étape de mesure.
Selon un cinquième aspect matériel, l’invention se rapporte à un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé d’accès défini ci-dessus, lorsqu’il est exécuté par un processeur.
Selon un quatrième aspect matériel, l’invention se rapporte à un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur défini ci-dessus.
Le dispositif intermédiaire, le dispositif de restitution, et les programme d’ordinateur /supports d’enregistrement correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de transmission selon les différents modes de réalisation de la présente invention.
Brève description 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 :
représente une architecture de téléchargement progressif sur Internet basée sur l’utilisation du téléchargement progressif adaptatif selon l’invention;
illustre de façon schématique la structure matérielle d’un dispositif de restitution selon un mode de réalisation de l’invention;
illustre de façon schématique plusieurs versions d’un même contenu selon un mode de réalisation.
illustre de façon schématique la structure matérielle d’un dispositif de restitution selon un mode de réalisation de l’invention;
illustre un mode de réalisation dans lequel des segments correspondants à un segment transmit sont supprimés du dispositif intermédiaire pour augmenter l’espace mémoire disponible dans le dispositif intermédiaire.
illustre de façon schématique un autre mode de réalisation dans un système informatique comprenant plusieurs dispositifs intermédiaires.
Description détaillée de l'invention
On présente désormais, en relation avec la figure 1, un exemple de système informatique dans lequel l’invention peut être mise en œuvre.
Ce système comprend plusieurs terminaux de restitution : Un terminal 3, par exemple un téléphone intelligent de type « Smartphone », un terminal 4, par exemple un ordinateur portable, et un terminal 8, par exemple une clef HDMI connectée à un téléviseur 5. Ces terminaux de restitution, appelés aussi terminaux clients, se trouvent dans cet exemple situé dans un réseau local (LAN, 10) piloté par une passerelle domestique 6. Le contexte du réseau local est donné à titre d’exemple et pourrait être transposé aisément à un réseau Internet de type « best effort », un réseau d’entreprise, etc.
Un serveur de contenus numériques 2 se trouve selon cet exemple dans le réseau étendu (WAN, 1). Le serveur de contenus 2 reçoit par exemple des chaînes de contenus de télévision numérique en provenance d’un réseau de télévision diffusée, non représenté, et/ou des vidéos à la demande, et les met à disposition des terminaux clients.
Dans l’art antérieur, les terminaux 3, 4 et 8 peuvent entrer en communication avec le serveur de contenus 2 pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.). En général, un terminal émet une requête à destination d’un serveur de contenus 2, en indiquant le contenu choisi et il reçoit en retour un flux de données numériques relatives à ce contenu. Dans le cadre d’un réseau de communication local, une telle requête transite par la passerelle d’accès au réseau, par exemple la passerelle résidentielle.
Le terminal de restitution est adapté pour recevoir ces contenus numériques sous forme de données multimédia et pour en faire une restitution. Cette restitution consiste à fournir au niveau du terminal le contenu numérique sous une forme accessible à l’utilisateur. Par exemple, des données reçues correspondant à une vidéo sont généralement décodées, puis restituées au niveau du terminal sous la forme d’un affichage de la vidéo correspondante avec sa bande-son associée.
Il est fréquent, dans ce contexte client-serveur, de recourir, pour transmettre les données aux terminaux client 3, 4 et 8, à une technique de téléchargement progressif adaptatif, en anglais « adaptive streaming », abrégé en HAS basée sur le protocole HTTP. Ce type de technique permet notamment d'offrir une bonne qualité de contenus à l’utilisateur en tenant compte des variations de bande passante qui peuvent se produire sur la liaison entre le terminal client 3, 4 et 8 et la passerelle de services 6, ou entre cette dernière et le serveur de contenus 2.
Classiquement, différentes qualités peuvent être encodées pour le même contenu d’une chaîne, correspondant par exemple à différents débits. Plus généralement, on parlera de qualité pour se référer à une certaine résolution du contenu numérique (résolution spatiale, temporelle, niveau de qualité associée à la compression vidéo et/ou audio) avec un certain débit, parfois aussi de version ou de représentation. Chaque niveau de qualité est lui-même découpé sur le serveur de contenus en segments temporels (en anglais « chunks »), ces deux mots étant utilisés indifféremment dans l’ensemble de ce document).
La description de ces différentes qualités et de la segmentation temporelle associée, ainsi que les segments de contenu, sont décrits pour le terminal client et mis à sa disposition via leurs adresses Internet (URI : Universal Ressource Identifier). L’ensemble de ces paramètres (qualités, adresses des segments, etc.) est en général regroupé dans un fichier de paramètres, dit fichier de description ou manifest. On notera que ce fichier de paramètres peut être un fichier informatique ou un ensemble d’informations descriptives du contenu, accessible à une certaine adresse.
Ces segments ou « chunks » comprennent un ensemble de données représentatives du contenu. Dans l’exemple d’une vidéo, chaque « chunk » de la vidéo comprend notamment une première image dite image « I », ou intra, et une ou plusieurs images qui peuvent être prédites à partir de cette image I par estimation/compensation de mouvement.
Les terminaux 3, 4 et 8 possèdent leurs propres caractéristiques en termes de capacité de décodage, d’affichage, etc. Dans un contexte de téléchargement adaptatif progressif, ils peuvent adapter leurs requêtes pour recevoir et décoder le contenu demandé par l’utilisateur à la qualité qui leur correspond au mieux. Dans notre exemple, si les contenus sont disponibles aux débits 512 kb/s (kilobits par seconde) (Résolution 1, ou niveau 1, noté D1), 1024 kb/s (D2), 2048 kb/s (D3) et que le terminal client dispose d’une bande passante de 3000 kb/s, il peut demander le contenu à n’importe quel débit inférieur à cette limite, par exemple 2048 kb/s. De manière générale, on note « Ci@Dj » le contenu numéro i avec la qualité j (par exemple le j-ième niveau Dj de qualité décrit dans le fichier de description).
La passerelle de service 6 est dans cet exemple une passerelle domestique qui assure le routage des données entre le réseau étendu 1 et le réseau local 10, gère les contenus numériques en assurant notamment leur réception en provenance du réseau et leur décodage grâce à un lecteur de flux multimédia (non représenté), aussi appelé décodeur que l’on suppose ici intégré aux terminaux clients 3, 4 et 8.
Dans cet exemple, pour visualiser un contenu avec la technique HAS, le terminal 3, 4 ou 8 interroge tout d’abord la passerelle de service 6 pour obtenir une adresse du document de description 7 du contenu (par exemple, C1) souhaité. La passerelle de service 6 répond en fournissant au terminal l’adresse du fichier de description 7. Dans la suite, on supposera que ce fichier est un fichier de type manifest selon la norme MPEG-DASH (noté « C.mpd ») et on se réfèrera indifféremment, selon le contexte, à l’expression « fichier de description » ou « manifest».
Alternativement, ce fichier peut être récupéré directement auprès d’un serveur Internet local ou externe au réseau local, ou se trouver déjà sur la passerelle de service ou sur le terminal au moment de la requête.
Un exemple de fichier manifest (MPD) conforme à la norme MPEG-DASH et comportant la description de contenus disponibles dans trois qualités différentes (D1 = 512 kb/s, D2 = 1024 kb/s, D3 = 2048 kb/s) des contenus segmentés est présenté en annexe 1. Ce fichier manifest simplifié décrit des contenus numériques dans une syntaxe XML (de l'Anglais « eXtended Markup Language»), comprenant une liste de contenus sous forme de segments classiquement décrits entre une balise ouvrante (<SegmentList>) et une balise fermante (</SegmentList>). La découpe en segments permet notamment de s’adapter finement aux fluctuations de la bande passante. Chaque segment correspond à une certaine durée (champ « duration ») avec plusieurs niveaux de qualité et permet de générer leurs adresses (URL – Uniform Resource Locator). Cette génération est faite dans cet exemple à l’aide des éléments « BaseURL » (« HTTP://server.com») qui indique l’adresse du serveur de contenus et « SegmentURL » qui liste les parties complémentaires des adresses des différents segments :
- « C1_512kb_1.mp4 » pour le premier segment du contenu « C1 » à 512 kilobits par seconde (« kb ») au format MPEG-4 (« mp4 »),
- « C1_512kb_2.mp4 » pour le second segment,
- etc.
Une fois qu’elle dispose des adresses de segments correspondant au contenu souhaité, la passerelle de service 6 procède à l’obtention des segments via un téléchargement à ces adresses. On notera que ce téléchargement s’opère ici, traditionnellement, au travers d’une URL HTTP, mais pourrait également s’opérer au travers d’une adresse universelle (URI) décrivant un autre protocole (dvb://monsegmentdecontenu par exemple).
Les terminaux 3, 4 ou le téléviseur 5, par exemple via sa connexion à une clef HDMI 8 par branchement sur son port HDMI, sont utilisés pour restituer un contenu numérique tel qu’un programme télévisuel diffusé en direct («live») ou en différé, une vidéo à la demande, etc. Par la suite, on désigne ce programme télévisuel sous le nom de contenu C1. Un tel contenu C1 est décrit dans un fichier manifest 7.
Dans un exemple, un utilisateur souhaite visualiser un contenu multimédia, tel qu’une émission de télévision, sur son téléviseur 5 connecté à une clé HDMI 8. La clef HDMI 8 est connectée en WiFi® directement à la passerelle résidentielle 6. En variante, la clef HDMI 8 pourrait également être connectée en WiFi® à un autre périphérique nomade du réseau domestique, par exemple à l’ordinateur portable 4 ou au téléphone intelligent 3, par l’intermédiaire duquel elle pourrait accéder au réseau de communication étendu 1.
La clef HDMI 8 peut également être pilotée par l’utilisateur au moyen du téléphone intelligent 3, sur lequel est installée une application logicielle de commande de la clef HDMI 8.
Les segments de contenu obtenus par la passerelle résidentielle 6 sont par exemple transmis en WiFi® à la clef HDMI 8, qui pilote leur affichage sur l’écran du téléviseur 5, pour restitution à l’utilisateur après décodage par un lecteur de flux multimédia 9.
La figure 2 représente une architecture d’un dispositif de restitution selon un mode de réalisation de l’invention. Ce dispositif comprend, classiquement, des mémoires M associées à un processeur CPU. Les mémoires peuvent être de type ROM (de l’anglais« Read Only Memory ») ou RAM (de l’anglais« Random Access Memory ») ou encore Flash. Dans le mode de réalisation, le dispositif de restitution comprend un module de téléchargement progressif adaptatif HAS, apte à demander un téléchargement progressif de l’un des contenus à l’une des qualités proposées dans un fichier de description 7. Dans un second mode de réalisation, on verra que ce module HAS peut être remplacé par un module de réception.
Le fichier de description 7 peut être enregistré par exemple dans les mémoires M du lecteur de flux multimédia 9 ou se trouver à l’extérieur.
Le dispositif de restitution peut aussi contenir d’autres modules (non représentés) comme un disque dur pour le stockage des segments vidéo, un module de contrôle d’accès aux contenus, un module de traitement des commandes reçues d’une tablette, d’un Smartphone, ou d’une télécommande, grâce à laquelle l’utilisateur peut en contrôler le fonctionnement, etc.
On notera que le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
Comme indiqué précédemment, dans l’art antérieur, les terminaux clients 3, 4 et 8 peuvent entrer en communication avec le serveur de contenus 2 pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.). En général, un terminal émet une requête à destination d’un serveur de contenus, en indiquant le contenu choisi et il reçoit en retour un flux de données numériques relatives à ce contenu. Un gros problème lié à l’utilisation de la technologie HAS est qu’elle est basée sur des connections point à point qui entrainent inévitablement une charge importante sur le serveur de contenus et sur le réseau de l’opérateur comme expliqué ci-dessus. A la différence des contenus «LIVE» diffusé en multicast dont les flux de données associés sont répliqués au plus proche du consommateur, les contenus diffusés en HAS nécessitent une session unique pour chaque utilisateur. Cela nécessite de dimensionner des serveurs de distribution de contenus en conséquence.
Pour résoudre ce problème, le système de l’invention comprend un dispositif DI, appelé dans la suite dispositif intermédiaire, qui s’intercale sur le réseau entre le serveur de contenu 2 et le ou les terminaux de restitution 3, 4 et 8. On verra dans la suite dans plusieurs modes de réalisation que le système peut comprendre un ou plusieurs dispositifs intermédiaires.
Selon l’invention, la transmission d’un contenu numérique selon l’invention s’effectue en deux phases.
Le dispositif intermédiaire DI reçoit depuis le serveur de contenus 2, lors d’une première phase, plusieurs versions d’un même contenu, les versions étant associées respectivement à des qualités de restitution respectives.
Lors d’une deuxième phase, le dispositif intermédiaire DI fournit la version du contenu au terminal de restitution la plus adapté à l’environnement du terminal de restitution.
Deux modes de réalisations vont être décrits ci-dessous. Un premier mode sera décrit dans lequel le module de réception installé dans le terminal de restitution est un module de téléchargement progressif adaptatif HAS comme décrit ci-dessus, et dans lequel un fichier manifest est utilisé. Un deuxième mode sera décrit dans lequel le module est un mode de réception qui n’utilise pas de fichier manifest comme cela sera expliqué ci-dessous. Dans ce deuxième mode, pour déterminer la version des segments ultérieurs, le module de réception mesure le temps de transmission d’un segment depuis le serveur de contenus 2 jusqu’au terminal de restitution concerné et compare ensuite ce temps de réception à la durée du segment. En fonction du résultat, le terminal requiert, auprès du dispositif intermédiaire auquel il est relié, une autre version pour les segments suivants ou un maintien de la version.
Selon le premier mode de réalisation, le module de téléchargement progressif adaptatif HAS présent dans le terminal de restitution requiert au dispositif intermédiaire DI le téléchargement progressif de l’un des contenus à l’une des qualités proposées dans un fichier de description 7.
Dans la suite, afin de simplifier l’exposé, un seul contenu numérique C1 sera considéré pour illustrer un accès. L’invention ne se limite pas à ce cet exemple mais s’étend au contraire à un nombre indéterminé de contenus.
D’une manière générale, à un contenu correspond un ensemble de segments C1i@Dj encodés à différents débits d’encodage Dj, où l’indice i désigne un identifiant temporel, ou position, du « chunk » C1i@Dj dans le contenu numérique.
Lors de la première phase, le serveur de contenus numériques 2 transmet différentes versions d’un même contenu numérique, les versions étant associées à des versions différentes du contenu numérique considéré. Plus précisément, dans notre exemple, en référence à la figure 1, le serveur de contenus 2 transmet une première version C1/500 du contenu numérique ; cette première version avec D1 égal à 500kb/s du contenu numérique inclus un ensemble de segments C1i@D1 encodés à un premier débit d’encodage D1, où l’indice i désigne un identifiant temporel, ou position, du « chunk » C1i@D1.
En référence à la figure 1, le serveur de contenus 2 transmet aussi de la même manière une deuxième version C1/1000, une troisième version C1/2000, une quatrième version C1/3000 et une cinquième version C1/5000 de ce même contenu C1.
L’ensemble des segments transmis est illustré sur la figure 3. Cet ensemble est représenté sous forme de matrice C1i@Dj, Dj correspondant au débit d’encodage et l’indice i désigne un identifiant temporel, ou position, du segment C1i@Dj dans le contenu C1.
Plus précisément, le dispositif intermédiaire DI reçoit et stocke une voire plusieurs matrices en fonction du nombre de contenu Ck à stocker. Dans cette configuration les différentes matrices seront Cki@Dj, l’indice k désignant un contenu particulier.
Dans un exemple illustré par la suite en relation avec la figure 3, le contenu C1 est par exemple proposé sous forme de segments de durée 2s, avec un premier débit d’encodage D1 = 500 kb/s, un deuxième débit d’encodage D2 = 1000 kb/s, un troisième débit d’encodage D3 = 2000 kb/s, etc.
Le dispositif intermédiaire DI reçoit l’ensemble des segments décrits ci-dessus. En outre, dans notre exemple, le dispositif intermédiaire DI stocke le fichier manifest décrit ci-dessus et le transmet à un terminal de resttution lors de la réception d’une demande d’accès au contenu associé au manifest.
Dans cet exemple, un utilisateur souhaite visualiser un contenu numérique C1, comme une vidéo, sur son téléviseur 5 connecté à une clé HDMI 8.
Afin de visualiser une vidéo, lors d’une première étape ET1, une requête d’accès REQ(C1) au contenu C1 est transmise par le terminal 8 à destination du dispositif intermédiaire DI. Dans notre exemple, cette requête transite par la passerelle 6.
Lors d’une deuxième étape, une requête d’accès REQ’(C1), identique ou pas à la requête transmise à la première étape, est transmise au serveur de contenus 2 qui télécharge en retour différentes versions du contenu dans le dispositif intermédiaire DI. Cette étape peut aussi être précédée d’une étape de vérification au cours de laquelle le terminal de restitution vérifie si le contenu demandé est déjà en cours de transmission vers un autre terminal de restitution auquel cas le dispositif intermédiaire DI ne réalise pas la deuxième étape mais requiert à la place au dispositif intermédiaire DI une transmission du contenu vers le terminal 8.
A noter que la requête transmise à la première étape aurait pu être transmise directement au serveur de contenus 2. Cette requête pourrait transiter ou pas par le dispositif intermédiaire DI.
A noter aussi que l’ordre d’exécution des deux premières étapes est indifférent. En d’autres mots, le téléchargement du contenu dans le dispositif intermédiaire DI peut aussi se faire avant réception d’une requête d’accès ou après réception de la requête d’accès.
Lors d’une troisième étape, le dispositif intermédiaire DI transmet en réponse à cette requête un flux de données représentatif du contenu choisi.
Comme indiqué précédemment, le dispositif intermédiaire DI expose le contenu C1 sous forme de segments, ou « chunks » C1i@Dj encodés à différents débits d’encodage Dj, où l’indice i désigne un identifiant temporel, ou position, du « chunk » C1i@Dj.
Le dispositif intermédiaire DI transmet ensuite des segments à choisissant un débit Dj. On verra dans la suite que les premiers segments sont transmis avec un débit faible, 500kb/s dans notre exemple.
Ce flux de données est récupéré par le module HAS du terminal de restitution, par exemple la clé HDMI 8 qui en pilote la restitution sur le téléviseur 5 pour une visualisation par l’utilisateur.
En général, un module HAS est chargé de venir récupérer les segments temporels auprès du dispositif intermédiaire DI en choisissant la qualité vidéo Dj en fonction de la ressource réseau disponible comme expliqué précédemment. On ne décrit pas ici plus en détail la façon dont le module client HAS choisit le débit d’encodage du prochain segment vidéo à télécharger : il existe en effet de nombreux algorithmes permettant d’opérer ce choix, dont les stratégies sont plus ou moins sécuritaires ou agressives. On rappelle cependant que, le plus souvent, le principe général de tels algorithmes repose sur le téléchargement d’un premier segment au débit d’encodage le plus faible proposé dans le manifest, et sur l’évaluation du temps de récupération de ce premier segment. Sur cette base, le module client HAS évalue si, en fonction de la taille du segment et du temps mis pour le récupérer, les conditions réseau permettent de télécharger le segment suivant à un débit d’encodage plus élevé. Certains algorithmes reposent sur une augmentation progressive du niveau de qualité des segments de contenu téléchargés ; d’autres proposent des approches plus risquées, avec des sauts dans les niveaux des débits d’encodage des segments successifs.
Dans un cas classique, si un segment temporel vidéo dure 2 secondes, la récupération du segment par le module HAS ne doit pas excéder 2 secondes afin de permettre une restitution sans interruption du contenu. Il convient donc pour le module HAS d’opérer le meilleur compromis entre une qualité de restitution, et donc un débit d’encodage, aussi élevés que possible, et le temps de téléchargement du segment, qui doit être suffisamment faible pour permettre une restitution en continu sur le téléviseur 5 par exemple.
Au cours d’une cinquième étape ET5, le module HAS du terminal de restitution 8 récupère le fichier manifest 7 afin de découvrir les segments disponibles du contenu vidéo C1, et les différentes qualités vidéo Dj associées.
Dans un exemple, non illustré, le module HAS opère lors d’une sixième étape ET6 le téléchargement par exemple, des segments successifs C11@D1 (soit le premier segment temporel à un débit d’encodage de 500 kb/s), puis C12@D3 (soit le deuxième segment temporel à un débit d’encodage de 2000 kb/s), puis C13@D3 (soit le troisième segment temporel à un débit d’encodage de 2000 kb/s), etc.
Les différents segments téléchargés par le module client HAS sont transmis au téléviseur 5 via la clé HDMI 8 par exemple pour leur restitution à l’utilisateur.
L’algorithme mis en œuvre par le module client HAS pour déterminer quel segment à quel débit d’encodage doit être téléchargé peut être l’un des algorithmes déjà existants de l’art antérieur. Cet algorithme ne sera donc pas décrit ici plus en détail.
Selon une variante possible le serveur de contenus transmet les segments en mode multicast. Ce mode tire profit des avantages de la diffusion de contenus en multicast tout en permettant grâce au dispositif intermédiaire DI d’adapter le contenu à chaque client. Cette variante consiste donc à répliquer les segments vidéo, de préférence au plus proche des terminaux de restitution, afin de diminuer la charge au niveau du serveur de contenus et sur e réseau de communication ; et conserver l’adaptation du contenu aux contraintes du réseau d’accès au niveau des terminaux de restitution.
Selon un deuxième mode de réalisation pouvant être utilisé seul ou en combinaison avec le premier mode de réalisation, un module de réception peut être utilisé en lieu et place du module de téléchargement progressif adaptatif HAS. Dans notre exemple, contrairement au module HAS, le module de réception ne dispose pas de fichier manifest. De manière à déterminer la version des segments à télécharger, le module de réception mesure le temps de récupération d’un segment depuis le serveur de contenus et compare ce temps de récupération à la durée du segment temporel ; et en fonction du résultat de la comparaison, le module de réception décide de requérir une modification (diminution ou augmentation) de la qualité de restitution des segments, sous-entendu de la version des segments ultérieurs.
A noter que dans notre exemple, un maintien d’une version ne nécessite pas de transmission d’une requête à destination du dispositif intermédiaire, seules l’augmentation et la diminution de la version nécessite une requête à destination du dispositif intermédiaire DI.
Le dispositif intermédiaire DI est idéalement un routeur apte à router des flux de données vers le terminaux de restitution et apte à former des groupes d’utilisateurs (sous-entendu des terminaux de restitution ou réseaux locaux) vers qui un même contenu numérique peut être transmis ; Dans cette configuration, de manière à recevoir un contenu numérique tel qu’un contenu en direct ou «live», un ou plusieurs utilisateurs s’abonnent à un groupe sur le dispositif intermédiaire DI. Les terminaux de restitution d’un même groupe vont alors télécharger, depuis le dispositif intermédiaire DI, les segments du contenu de différentes qualités.
Le dispositif intermédiaire DI se charge de répliquer les segments vers les différents utilisateurs d’un même groupe ayant demandé un accès au même contenu et transmet les segments avec une version demandée par le ou les modules de réception concernés comme indiqué ci-dessus.
Aussi, lorsque le contenu est un contenu « Live », le dispositif intermédiaire DI stocke dans une mémoire tampon quelques secondes du contenu de façon à pouvoir répliquer les segments temporels vers les différents terminaux de restitution et distribuer les qualités optimales en fonction des besoins des terminaux de restitution. Ce stockage de segments dans une mémoire tampon est nécessaire pour fournir les segments au terminal de restitution, ce dernier stockant aussi quelques secondes dans une mémoire tampon les segments qu’il va restituer. Par exemple, sur un décodeur du type « Clé TV », la consultation d’un contenu «live» nécessite le stockage de segments vidéos sur une quinzaine de secondes. Ce stockage en mémoire tampon dans le terminal de restitution permet de gérer les perturbations possibles de débit sur le réseau.
Selon une variante, la mise en œuvre du procédé de l’invention est conditionnée à la réception d’un nombre minimum de requêtes d’accès au même contenu.
En référence à la figure 5, la réception d’une requête d’accès à un segment temporel d’une version donnée, par exemple C1N@D1000, entraîne la suppression des autres versions du même segment de la mémoire du dispositif intermédiaire, à savoir C1N@D500, C1N@D2000, C1N@D3000, et C1N@D5000. Cette caractéristique permet de gagner de l’espace mémoire dans le dispositif intermédiaire DI dès réception d’une requête d’accès à un segment.
La figure 6 illustre un autre mode de réalisation incluant deux dispositifs intermédiaires DI1 et DI2. Cet autre mode peut être utilisé seul ou en combinaison avec l’un des modes de réalisation décrits ci-dessus. On choisit ici d’illustrer ce troisième mode en utilisant le deuxième mode décrit ci-dessus c’est-à-dire celui utilisant un module de réception n’ayant pas à dispositif un fichier manifest. Dans ce troisième mode, les dispositifs intermédiaires DI1 et DI2 sont reliés à des réseaux locaux 10-1 et 10-2, respectivement. Le réseau local 10-1 comprend un seul terminal de restitution TRM, le réseau local 10-2 comprend plusieurs terminaux de restitution TRM1-TRM5.
Plusieurs versions d’un même contenu C1 est transmis en mode multicast depuis le serveur de contenus 2 à destination des dispositifs intermédiaires DI1 et DI2.
Si le contenu est un contenu en temps réel ou «live», les dispositifs intermédiaires DI1 et DI2 stockent les segments reçus en mode multicast dans une mémoire tampon de façon à stocker quelques secondes de vidéos «LIVE» et à répliquer les segments temporels vers les différents terminaux.
On suppose ci que le terminal TRM du réseau local 10-1 et les terminaux TRM1-TRM5 du réseau local 10-2 requiert un accès au contenu C1.
Dans notre exemple, après réception de la demande d’accès, n’ayant pas connaissance des besoins en termes de qualité de restitution des terminaux de restitution, le dispositif intermédiaire DI transmet au terminal TRM par défaut un segment vidéo d’une version associée à un faible débit. Suite à la réception, le terminal TRM mesure le temps de récupération de ce segment et vérifie que le temps de récupération du segment n’excède pas la durée du segment. En fonction du résultat, le module de réception du terminal de restitution transmet ou pas un message au dispositif intermédiaire requérant une plus grande qualité, une diminution de qualité voire un maintien de la qualité reçue.
A noter que les terminaux de restitutions requièrent les versions de segments auprès du dispositif intermédiaire auquel il est relié.
Dans l’exemple utilisant un module de réception, les protocoles RTP/RTCP sur UDP peuvent être utilisés. Dans ce cas, les segments peuvent être transmis au moyen de message UDP ; les demandes de modifications de versions sont transmises par les terminaux de restitution au moyen de RTSP respectifs.
ANNEXE 1 : exemple de fichier manifest

Claims (12)

  1. Procédé de transmission d’un contenu à destination d’un terminal de restitution (8) via un réseau de communication, le contenu (C1) étant accessible depuis un serveur de contenus sous plusieurs versions associées à des qualités de restitution respectives, une version donnée comprenant respectivement plusieurs segments du contenu, caractérisé en ce qu’il comprend les étapes suivantes dans un dispositif (DI) s’intercalant entre le serveur de contenus et le terminal de restitution
    • une première étape de réception au cours de laquelle le dispositif intermédiaire reçoit du serveur de contenus plusieurs versions d’un même contenu ;
    • une deuxième étape de réception d’une requête d’accès à une version donnée du contenu ;
    • et une étape de transmission, à destination du terminal de restitution, de segments associés à la version du contenu demandée lors de la deuxième étape de réception.
  2. Procédé de transmission selon la revendication 1, caractérisé en ce que la version choisie pour au moins le premier segment temporel transmis est une version choisie par défaut.
  3. Procédé de transmission selon la revendication 2, caractérisé en ce que le choix de la version d’un segment ultérieur évolue en fonction d’une donnée issue du terminal de restitution, ladite donnée étant issue d’une comparaison entre la durée de transmission d’un segment précédemment transmis et la durée du segment temporel.
  4. Procédé de transmission selon la revendication 1, caractérisé en ce que le contenu reçu lors de la première étape de réception est un contenu transmis en mode multicast.
  5. Procédé de transmission selon la revendication 1, caractérisé en ce que l’étape de réception est suivie d’une étape de stockage en mémoire des segments reçus du serveur de contenus, et en ce que l’étape de transmission d’un segment temporel d’une version donnée, entraîne la suppression des autres versions du segment transmis.
  6. Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de transmission d’un contenu numérique selon l'une quelconque des revendications 1 à 5, lorsqu’il est exécuté par un processeur.
  7. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 6.
  8. Dispositif (DI), dit dispositif intermédiaire, apte à communiquer avec un serveur de contenus (2) et avec des terminaux de restitution (3,4,8) via un réseau de communication, un contenu (C1) étant accessible depuis le serveur de contenus sous plusieurs versions, une version donnée comprenant respectivement plusieurs segments du contenu,
    comprenant :
    1. un premier module de de réception au cours de laquelle le dispositif intermédiaire reçoit du serveur de contenus plusieurs versions d’un même contenu ;
    2. un deuxième module de réception apte à recevoir une requête d’accès à une version donnée d’un contenu ;
    3. un module de transmission apte à transmettre, à destination du terminal de restitution, des segments associés à la version du contenu demandée lors de la de deuxième étape de réception.
  9. Procédé d’accès par un terminal de restitution à un contenu numérique accessible depuis un dispositif (DI), dit dispositif intermédiaire, plusieurs versions différentes du contenu étant accessibles, une version donnée comprenant respectivement plusieurs segments du contenu ayant des durées respectives, caractérisé en ce qu’il comprend les étapes suivantes
    • une étape de réception au cours de laquelle le dispositif de restitution (8) reçoit un segment d’une version donnée du contenu depuis le dispositif intermédiaire (DI);
    • une deuxième étape de mesure de la durée de transmission du segment reçu et de comparaison avec la durée du segment temporel,
    • en fonction du résultat de l’étape de mesure, une étape de transmission ou pas, à destination du dispositif intermédiaire (DI), d’une demande d’accès à une autre version.
  10. Terminal de restitution comprenant de restitution à un contenu numérique accessible depuis un dispositif (DI), dit dispositif intermédiaire, plusieurs versions différentes du contenu étant accessibles, une version donnée comprenant respectivement plusieurs segments du contenu ayant des durées respectives, caractérisé en ce qu’il comprend
    • un module de réception apte à recevoir un segment d’une version donnée du contenu depuis le dispositif intermédiaire (DI);
    • un module de mesure apte à mesurer la durée de transmission du segment reçu et de comparer la durée mesurée avec la durée du segment temporel,
    • un module de transmission apte à transmettre ou pas, à destination du dispositif intermédiaire, une demande d’accès à une autre version en fonction du résultat de l’étape de mesure.
  11. Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de transmission d’un contenu numérique selon la revendication 9, lorsqu’il est exécuté par un processeur.
  12. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 11.
FR1906670A 2019-06-20 2019-06-20 Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution. Active FR3096210B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1906670A FR3096210B1 (fr) 2019-06-20 2019-06-20 Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1906670A FR3096210B1 (fr) 2019-06-20 2019-06-20 Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
FR1906670 2019-06-20

Publications (2)

Publication Number Publication Date
FR3096210A1 true FR3096210A1 (fr) 2020-11-20
FR3096210B1 FR3096210B1 (fr) 2023-10-06

Family

ID=68072746

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1906670A Active FR3096210B1 (fr) 2019-06-20 2019-06-20 Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.

Country Status (1)

Country Link
FR (1) FR3096210B1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130262693A1 (en) * 2012-04-02 2013-10-03 Chris Phillips Methods and apparatus for segmenting, distributing, and resegmenting adaptive rate content streams
US20150256583A1 (en) * 2015-05-01 2015-09-10 Elemental Technologies, Inc. Content delivery network video content invalidation through adaptive bitrate manifest manipulation
US20160337426A1 (en) * 2015-05-14 2016-11-17 Hola Networks Ltd. System and Method for Streaming Content from Multiple Servers
US20170188065A1 (en) * 2015-12-29 2017-06-29 Echostar Technologies L.L.C. Methods and systems for assisted content delivery
WO2018049321A1 (fr) * 2016-09-12 2018-03-15 Vid Scale, Inc. Procédé et systèmes d'affichage d'une partie d'un flux vidéo avec des rapports de grossissement partiel

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130262693A1 (en) * 2012-04-02 2013-10-03 Chris Phillips Methods and apparatus for segmenting, distributing, and resegmenting adaptive rate content streams
US20150256583A1 (en) * 2015-05-01 2015-09-10 Elemental Technologies, Inc. Content delivery network video content invalidation through adaptive bitrate manifest manipulation
US20160337426A1 (en) * 2015-05-14 2016-11-17 Hola Networks Ltd. System and Method for Streaming Content from Multiple Servers
US20170188065A1 (en) * 2015-12-29 2017-06-29 Echostar Technologies L.L.C. Methods and systems for assisted content delivery
WO2018049321A1 (fr) * 2016-09-12 2018-03-15 Vid Scale, Inc. Procédé et systèmes d'affichage d'une partie d'un flux vidéo avec des rapports de grossissement partiel

Also Published As

Publication number Publication date
FR3096210B1 (fr) 2023-10-06

Similar Documents

Publication Publication Date Title
EP2947888A1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
FR3081274A1 (fr) Gestion du telechargement progressif adaptatif d&#39;un contenu numerique au sein d&#39;un terminal de restitution d&#39;un reseau de communication local.
WO2021058910A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique sur réseau mobile avec sélection d&#39;un débit d&#39;encodage maximum autorisé en fonction d&#39;un godet de données
WO2021089942A1 (fr) Procédé de gestion de zapping de contenus multimédias numériques obtenu par téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d&#39;ordinateur correspondants
FR3068852A1 (fr) Procede de gestion du droit d&#39;acces a un contenu numerique
WO2020259911A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d&#39;un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d&#39;ordinateur correspondants
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
EP3926929B1 (fr) Procédé de gestion de la lecture d&#39;un contenu numérique au sein d&#39;un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
FR3081647A1 (fr) Gestion du telechargement progressif adaptatif (has) d&#39;un contenu numerique au sein d&#39;un terminal lecteur de flux multimedia en temps reel.
WO2023208688A1 (fr) Gestion de la restitution d&#39;un contenu multimédia
EP3840391A1 (fr) Gestion de la restitution d&#39;un contenu multimédia et d&#39;une interface de navigation sur un écran
FR3114719A1 (fr) Procédé de gestion de la lecture d’un contenu numérique au sein d’un terminal lecteur de contenus multimédias connecté à un dispositif de restitution
WO2021105585A1 (fr) Procédé de gestion d&#39;une liste de contenus accessibles au zapping, les contenus numériques étant téléchargeables en mode de téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d&#39;ordinateur correspondants
EP3846489A1 (fr) Procédé de gestion d&#39;un téléchargement progressif et adaptatif d&#39;un contenu numérique par un terminal lecteur de flux multimédia connecté à un réseau de communication, dispositif de gestion, terminal lecteur de flux multimédia et programme d&#39;ordinateur correspondants
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique en mode économiseur d&#39;écran
WO2021209706A1 (fr) Gestion de l&#39;accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d&#39;encodage à débit variable, en fonction d&#39;une charge réseau
FR3093605A1 (fr) Procédé de navigation accélérée dans un contenu numérique obtenu par téléchargement progressif adaptatif (HAS), gestionnaire, lecteur de flux multimédia et programme d’ordinateur correspondants.
FR3093603A1 (fr) Procédé de navigation accélérée dans un contenu numérique obtenu par téléchargement progressif adaptatif (HAS), gestionnaire, lecteur de flux multimédia et programme d’ordinateur correspondants.
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
WO2020234030A1 (fr) Restitution d&#39;un contenu en arrière-plan ou sous forme d&#39;incrustation dans le cadre d&#39;un téléchargement progressif adaptatif de type has
FR3103668A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu numérique sur réseau mobile avec détermination d’un débit d’encodage maximum autorisé sur une session en fonction d’un godet de données
FR3124344A1 (fr) Procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif.
EP4297409A1 (fr) Procédé de gestion de la lecture d&#39;un contenu multimédia.
FR3138020A1 (fr) Streaming vidéo adaptatif hybride amélioré
FR3114720A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu tenant compte de la qualité du signal échangé entre le terminal client et le point d’accès au réseau

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20201120

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6