FR3004055A1 - Transcodage et diffusion adaptative de contenus multimedia - Google Patents

Transcodage et diffusion adaptative de contenus multimedia Download PDF

Info

Publication number
FR3004055A1
FR3004055A1 FR1352878A FR1352878A FR3004055A1 FR 3004055 A1 FR3004055 A1 FR 3004055A1 FR 1352878 A FR1352878 A FR 1352878A FR 1352878 A FR1352878 A FR 1352878A FR 3004055 A1 FR3004055 A1 FR 3004055A1
Authority
FR
France
Prior art keywords
content
level
terminal
fragment
network
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.)
Pending
Application number
FR1352878A
Other languages
English (en)
Inventor
Herve Marchand
Mathieu Rivoalen
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
France Telecom 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 France Telecom SA filed Critical France Telecom SA
Priority to FR1352878A priority Critical patent/FR3004055A1/fr
Priority to PCT/FR2014/050740 priority patent/WO2014155017A1/fr
Publication of FR3004055A1 publication Critical patent/FR3004055A1/fr
Pending legal-status Critical Current

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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615—Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440227—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/44029—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/4508—Management of client data or end-user data
    • H04N21/4516—Management of client data or end-user data involving client characteristics, e.g. Set-Top-Box type, software version or amount of memory available

Abstract

L'invention concerne un procédé de gestion d'un contenu multimédia apte à être restitué par un terminal (2-4) d'un réseau (1,12) connecté à une passerelle de service (6). Le contenu est apte à être transcodé en fragments (Frags) de données selon plusieurs résolutions (N1-N3) par la passerelle de service. Le procédé comprend : - Une étape de réception d'une requête (E10) pour la restitution d'un contenu (C) selon un second niveau (N1-N2); - Une étape de mise à disposition du terminal d'au moins un premier fragment (f1.N3) du contenu (C) selon un premier niveau (N3) ; - Une étape de commande de transcodage d'au moins un fragment (f1.N2, f2.N2) selon le second niveau (N2) ; - Et une étape de mise à disposition du terminal (2-4) d'au moins un fragment (f1.N2, f2.N2) selon le second niveau (N2).

Description

Transcodage et diffusion adaptative de contenus multimédia Domaine technique L'invention se rapporte aux communications de contenus multimédia. On entend par contenu multimédia tout contenu audio ou vidéo, ou plus généralement tout autre contenu numérique. L'invention concerne plus spécifiquement la préparation, la transmission et la réception de contenus vidéo sur un réseau, en particulier le téléchargement continu, aussi appelé streaming, de contenus multimédia sur un réseau domestique à partir d'un terminal client (dans la suite appelé simplement terminal) capable d'accéder à un tel contenu. Etat de la technique Pour accéder à un contenu multimédia sur un réseau de type Internet, ou de manière similaire sur un réseau local, c'est-à-dire un réseau qui relie ensemble, avec ou sans fils, les équipements terminaux d'une maison (ordinateurs, périphériques d'impression, de stockage, etc.), un terminal client effectue généralement une requête de la manière suivante : une première étape consiste à télécharger sur un premier serveur un document décrivant les paramètres d'accès au service via le protocole HTTP (de l'anglais Hyper Text Transport Protocol), un protocole de communication client-serveur développé pour les réseaux Internet et en particulier le Web. Ce document peut être un fichier informatique ou un ensemble d'informations descriptives du contenu accessible à une certaine adresse sur un second serveur, dit serveur de contenus. Dans la suite, on y réfèrera sous l'expression « fichier de description ». Lors d'une seconde étape, le terminal client accède au contenu sur le second serveur et le service démarre effectivement, c'est-à-dire que le terminal client peut recevoir et afficher le contenu. Il est fréquent, dans ce contexte du protocole HTTP, de recourir, pour échanger les données entre le terminal client et le serveur, à une technique de type dit « streaming adaptatif » (HAS pour « HTTP Adaptive Streaming »). Ce type de technique permet notamment d'offrir une bonne expérience à l'utilisateur tout en tenant compte, par exemple, des variations de bande passante sur la liaison entre le terminal client et le serveur de contenus. Classiquement, différents flux sont encodés, ou transcodés, pour la même vidéo, correspondant par exemple à différents débits, différentes résolutions, différentes qualités. Dans la suite, on appellera « niveau » un flux vidéo correspondant à une certaine qualité et/ou débit et/ou résolution spatiale ou temporelle. Le codage d'une vidéo a pour but de fournir une représentation du contenu initial de la vidéo conforme à certains paramètres (débit moyen, débit instantané, norme de codage-décodage utilisée, résolution spatiale, fréquentielle, etc.) sous une forme généralement plus compacte. Le transcodage consiste à ré-encoder une vidéo déjà encodée avec de nouveaux paramètres. Chaque niveau est lui-même découpé en segments temporels, aussi appelés « fragments » (ou « chunks » en anglais) correspondant généralement à quelques secondes de contenu. La description de ces différents niveaux et de la segmentation associée est généralement décrite dans le fichier de description. Il existe plusieurs solutions pour faciliter la mise à disposition et distribution d'un tel contenu en streaming, comme par exemple les solutions propriétaires Microsoft Smooth Streaming et Apple HTTP Live Streaming (HLS), ou encore la norme MPEG DASH (pour Dynamic Adaptive Streaming over HTTP - norme ISO/IEC 23009-1:2012(E)), une norme de l'organisme ISO/IEC dédiée au streaming de contenus multimédia sur Internet. Cette dernière norme permet notamment à des périphériques connectés au réseau (TV, tablettes, etc.) de consommer des contenus multimédia via le protocole HTTP. Dans le cas de MPEG DASH, l'accès au contenu se fait traditionnellement selon deux étapes : 1) Obtention d'un document de description, typiquement via le téléchargement, au travers d'une adresse HTTP, d'un fichier contenant notamment les adresses des fragments de média du contenu multimédia (fichier d'extension « .mpd » (pour Media Presentation Description). 2) Obtention des fragments de média, typiquement via un téléchargement, à l'aide des adresses contenues dans le document de description.
Ainsi, le terminal client choisit les différents fragments qui lui sont proposés dans le fichier de description en fonction de certains critères, comme ses capacités de décodage, la taille de son écran, la bande passante disponible, le format de codage vidéo le plus adapté, etc. Pour adapter ce choix au cours du temps, selon la variation de tels critères (par exemple l'évolution de la bande passante), le format des fragments peut évoluer dynamiquement tout au long de la lecture de la vidéo. Il n'y a cependant pas, aujourd'hui, de corrélation entre le format du contenu vidéo réellement consommé (par exemple visualisé) par le terminal client et la génération des différents formats disponibles. Ceci est particulièrement gênant dans le contexte d'un réseau qui ne garantit pas la qualité de service, comme par exemple un réseau local ou le réseau Internet. Dans la suite, on considère que le terminal client est connecté à une passerelle de service, c'est à dire un équipement du réseau capable de lui fournir, directement ou indirectement, l'accès aux contenus. Ce type d'équipement peut aussi s'appeler serveur de contenus multimédia, ou plateforme de services, passerelle domestique, etc. Si l'on considère qu'un contenu vidéo, dit contenu initial, arrive à la passerelle de service, il doit être transcodé en autant de niveaux qu'il y a de différents débits/qualités/résolutions proposés dans le fichier de description, ce qui introduit une grande complexité sur le module de transcodage, nécessitant des capacités d'encodage très importantes. De plus la passerelle de service doit stocker ou faire stocker tous les niveaux transcodés, ce qui nécessite des capacités de stockage importantes. Ainsi, il n'est généralement pas possible de stocker plus de quatre ou cinq niveaux différents pour un même contenu vidéo initial. Pour s'accommoder de cette limitation, le nombre de « niveaux » disponible dans le fichier de description est volontairement limité et donc le niveau choisi par le terminal client peut être éloigné du niveau optimum : par exemple, si l'on a reçu le contenu initial à 2048 kilobits par seconde (kbps) et transcodé à 256, 512, 1024 kbps, une requête pour obtenir un débit de 700 kbps entraînera la fourniture du niveau inférieur le plus proche, c'est à dire 512 kbps, qui est assez éloignée de 700 kbps. L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique. L'invention A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de gestion d'un contenu multimédia apte à être restitué par un terminal d'un réseau connecté à une passerelle de service, ledit contenu étant apte à être transcodé en fragments de données selon plusieurs résolutions, ledit procédé comprenant les étapes de : Réception d'une requête en provenance d'un terminal pour la restitution d'un contenu selon un second niveau ; Mise à disposition du terminal d'au moins un premier fragment du contenu selon un premier niveau ; Commande de transcodage d'au moins un fragment selon le second niveau ; Mise à disposition du terminal d'au moins un fragment selon le second niveau.
Il est ainsi possible, selon l'invention, de recevoir un contenu vidéo de manière adaptative sans créer de surcharge au niveau de la passerelle de service : il suffit à la passerelle de transcoder un premier fragment (quelques secondes de la vidéo) dans au moins un premier niveau de débit/qualité/résolution. Puis, dès réception d'une requête en provenance d'un terminal client, la passerelle lui fournit ce premier fragment et dans le même temps commande le transcodage dans le débit/qualité/résolution (second niveau) requis par le terminal client, du second fragment. De cette manière, il n'est plus nécessaire de transcoder à l'avance tous les fragments correspondant à tous les niveaux à prévoir pour le réseau local, ce qui est extrêmement coûteux pour la passerelle. De plus ce procédé selon l'invention garantit que le terminal client est servi au plus près de sa requête : comme il n'est plus nécessaire d'effectuer à l'avance un nombre de transcodages, forcément limité (par les caractéristiques de la passerelle) à un petit nombre de niveaux qui peuvent être éloignés de la requête du terminal client, celui-ci peut recevoir exactement le niveau qu'il a demandé et non pas l'un des niveaux préalablement transcodés qui ne lui correspond pas forcément.
Selon un mode de mise en oeuvre particulier de l'invention, un procédé tel que décrit ci-dessus est en outre caractérisé en ce que le premier et le second niveau sont décrits dans un fichier de description du contenu numérique. Il est ainsi possible, selon ce mode de mise en oeuvre, de lister dans un fichier de description, normalisé ou non, par exemple selon le format MPEG- DASH de l'organisme international précité, les formats qui peuvent être délivrés aux terminaux clients du réseau, par exemple un réseau local. Contrairement à l'état de l'art, qui limite le nombre de niveaux décrits dans ce fichier au nombre de niveaux pouvant être raisonnablement transcodés par la passerelle (généralement moins de cinq niveaux), le fichier de description selon l'invention n'est pas limité, puisque le transcodage est effectué ultérieurement à la requête du terminal client dans le second niveau requis. L'invention permet ainsi de disposer de fichiers de description plus riches pour les terminaux clients du réseau.
Selon une première variante de ce mode de mise en oeuvre de l'invention, un tel procédé est en outre caractérisé en ce que le fichier de description du contenu numérique est adapté en fonction du terminal. Cette variante permet à la passerelle d'utiliser les caractéristiques du terminal qui a émis la requête pour lui fournir un fichier de description adapté.
En effet, il n'est pas judicieux de décrire pour un terminal un niveau qui ne lui est pas accessible (par exemple, il est inutile d'offrir des résolutions très élevées à un terminal de petit écran tel une tablette numérique). En particulier, si le nombre de niveaux décrits est limité dans le fichier de description (par exemple à cinq), il est judicieux d'utiliser ce nombre restreint de niveaux pour décrire des contenus au plus proche des capacités du terminal client.
Selon une seconde variante de ce mode de mise en oeuvre de l'invention, qui pourra être mise en oeuvre alternativement ou cumulativement avec la précédente, un tel procédé est en outre caractérisé en ce que le fichier de description du contenu numérique est adapté en fonction du débit disponible sur le réseau. Cette variante permet à la passerelle d'utiliser les caractéristiques du réseau pour fournir au terminal client un fichier de description adapté. En effet, il n'est pas judicieux de décrire pour un terminal un niveau qui ne lui est pas accessible parce que le réseau n'est pas capable de le lui délivrer (par exemple, parce qu'il est encombré). En particulier, il est judicieux d'utiliser une information relative au débit disponible pour restreindre ou augmenter la taille des fragments : par exemple, si la bande passante diminue pour le réseau, ou pour un terminal donné, un fragment peut correspondre à une seconde de vidéo au lieu des trois initialement prévues. Selon une troisième variante de ce mode de mise en oeuvre de l'invention, qui pourra être mise en oeuvre alternativement ou cumulativement avec les précédentes, un tel procédé est en outre caractérisé en ce que le format de codage du contenu numérique est adapté en fonction du terminal. Ainsi il est possible, selon la nature du terminal qui a émis la requête, de choisir un certain type de codeur vidéo. En effet, il n'est pas judicieux de fournir au terminal un flux vidéo qu'il n'est pas en mesure de décoder parce qu'il n'a pas, par exemple, installé le décodeur prévu à l'origine dans le fichier de description, ou parce que ses capacités ne lui permettent pas de se conformer à un certain profil de codage vidéo, etc. Selon une quatrième variante de ce mode de mise en oeuvre de l'invention, qui pourra être mise en oeuvre alternativement ou cumulativement avec les précédentes, un tel procédé est en outre caractérisé en ce que le premier niveau est le niveau le plus faible du fichier de description du contenu numérique. L'invention permet ainsi de s'assurer que le premier niveau fourni au terminal client est un niveau qui peut être réellement consommé par le terminal client : s'il s'agit du plus petit niveau en termes de résolution/débit/qualité, il est très vraisemblable que le terminal client pourra le décoder et l'afficher en attendant de recevoir le niveau supérieur qu'il a requis, lui évitant ainsi une attente longue et pénible.
Selon un aspect matériel, l'invention concerne également un dispositif de gestion d'un contenu multimédia apte à être restitué par un terminal d'un réseau, ledit contenu étant apte à être transcodé en fragments de données selon plusieurs résolutions, ledit dispositif comprenant : Un module de réception d'une requête en provenance d'un terminal pour la restitution d'un contenu selon un second niveau ; Un module pour la mise à disposition du terminal d'au moins un premier fragment du contenu selon un premier niveau ; Un module de pilotage du transcodage d'au moins un fragment selon le second niveau ; Un module de mise à disposition du terminal d'au moins un fragment selon le second niveau. Selon un autre aspect matériel, l'invention concerne également une passerelle de service comportant un dispositif de gestion d'un contenu multimédia tel que revendiqué ci-dessus. Selon un autre aspect matériel, l'invention concerne également un programme d'ordinateur comportant des instructions de code pour la mise en oeuvre d'un procédé de gestion d'un contenu multimédia tel que décrit ci-dessus, lorsque celles-ci est exécutée par un processeur.
Selon encore un autre aspect matériel, l'invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes du procédé défini ci-dessus.
Les objets selon les aspects matériels de l'invention procurent au moins les mêmes avantages que ceux procurés par les procédés selon l'aspect fonctionnel.
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.
Les figures: La figure 1 représente une architecture de streaming basée sur l'utilisation du protocole HTTP dans un réseau local selon l'état de l'art. La figure 2 représente une architecture de streaming basée sur l'utilisation du protocole HTTP dans un réseau local selon un mode de réalisation de l'invention. La figure 3 représente une architecture d'une passerelle de service implémentant un mode de réalisation de l'invention. La figure 4 représente un chronogramme selon un mode de réalisation de l'invention.
Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente une architecture de streaming adaptatif basée sur l'utilisation du protocole HTTP dans un réseau local selon l'état de la technique. Le contexte du réseau local est donné à titre d'exemple et pourrait être transposé aisément à celui d'un réseau Internet quelconque. Classiquement, un terminal client (2-4) souhaite entrer en communication avec un serveur de contenus (5) pour télécharger un contenu multimédia composé d'un ou plusieurs médias (audio, vidéo, etc.) Le serveur de contenus se trouve selon cet exemple dans le réseau large bande (12) mais il pourrait indifféremment être situé dans le réseau local (1), par exemple dans la passerelle de service (6) ou tout autre équipement capable d'héberger un tel serveur de contenus. Chacun des terminaux (2-4) possède ses propres caractéristiques en termes de capacité de décodage, d'affichage, etc. Par exemple sur la figure sont schématisés trois niveaux différents correspondant à des débits et résolution différents (N1-N3) pour la séquence vidéo (C) destinée aux trois terminaux représentés : résolution la plus faible (N3) pour la tablette (4), intermédiaire (N2) pour le PC (3) et élevée (Ni) pour le TV (2). Chaque niveau est découpé en fragments (frags) de contenu dont les limites sont schématisées par des bordures verticales noires. Dans cet exemple, on a représenté des fragments de durée identique quelque soit la résolution spatiale de la vidéo mais naturellement tout autre arrangement à la portée de l'homme du métier est concevable. Un terminal donné doit récupérer les fragments correspondant à la résolution qui lui correspond au mieux.
Le terminal peut être un terminal du réseau local (1) ou se trouver plus généralement sur un réseau de données, connecté à une passerelle de services (6), par exemple un terminal en mobilité sur un réseau mobile (3G, 4G, etc.) La passerelle de service (6) est dans cet exemple une passerelle domestique qui assure le routage des données entre le réseau large-bande (12) et le réseau local (1), gère les contenus multimédia en assurant notamment leur réception en provenance du réseau large-bande (12) ou du réseau local (1) et leur transcodage grâce aux transcodeurs (8-10). En variante, les transcodeurs (8-10) peuvent se trouver ailleurs dans le réseau large-bande (12) ou local (1), notamment au niveau de l'élément STB (de l'anglais Set-Top-Box) si celui-ci est indépendant de la passerelle. Chaque niveau transcodé par l'un des transcodeurs (8-10) est stocké sur la passerelle de service (6) ou alternativement sur un autre espace de stockage accessible par la passerelle de service (6), situé dans le réseau local ou à l'extérieur.
Dans la suite de l'exemple, comme exposé ci-dessus, on se positionne dans un contexte de streaming adaptatif selon la norme MPEG-DASH. Le terminal (2-4) interroge tout d'abord la passerelle de service (6) pour obtenir une adresse du document de description (7) du contenu multimédia (C) souhaité. La passerelle de service (6) répond en fournissant au terminal l'adresse du fichier de description. Dans la suite, ce document est un fichier de type manifest selon la norme MPEG-DASH (C.mpd). 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 au moment de la requête.
Un exemple de fichier manifest (MPD) conforme à la norme MPEG/DASH et comportant la description de trois résolutions (Ni, N2, N3) du contenu C fragmenté est présenté en annexe 1. Le fichier MPD décrit les fragments et permet de générer leurs adresses (URL). Dans cet exemple simplifié, cette génération est faite à l'aide des éléments « BaseURL » (« http://x.com/Bunny ») et « SegmentList » qui liste les parties complémentaires des adresses des différents fragments : « bunny_1s_500kb/bunny_1s1.m4s » pour le premier fragment d'une seconde de la séquence Bunny à 500kbps au format MPEG-4 (m4s), « bunny_1s_500kb/bunny_1s2.m4s » pour le second fragment, etc.
Le champ duration spécifié comme attribut de la balise « Segment List » indique la durée d'un segment en secondes. Le champ « codecs » de la représentation indique que l'on utilise un encodeur de type AVC, etc.
Ainsi, les URL d'accès aux deux premiers fragments vidéo pour le niveau N3 le plus faible, correspondant au débit le plus faible de 500 kbps sont ici : http://x.com/Bunny/ bunny_1s_500kb/bunny_1s1.m4s http://x.com/Bunny/ bunny_1s_500kb/bunny_1s2.m4s Une fois qu'il dispose de ces adresses de fragments, le terminal client (la tablette 4 dans notre exemple) procède à l'obtention des fragments de média via un téléchargement à ces adresses. On notera que ce téléchargement s'opère 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). Actuellement, un transcodage multiple accompagné d'une description adéquate permet donc d'accéder à un nombre restreint de niveaux (résolutions/débits/qualités) vidéo. Comme il a été dit précédemment, ce mécanisme suppose cependant l'existence d'autant de transcodeurs que l'on souhaite générer de niveaux (trois dans notre exemple). De surcroît, il est impossible d'accéder à des fragments correspondant à un niveau qui n'a pas été prévu dans le fichier manifest. C'est donc une méthode coûteuse et peu flexible.
C'est pourquoi l'invention propose, comme illustré en figure 2, de piloter en temps réel un transcodeur unique (11), en se basant sur un fichier de description (manifest) plus riche et éventuellement adapté aux caractéristiques du terminal client ou à la bande passante du réseau.
En fonctionnement nominal, le terminal client (par exemple le PC3) demande toujours le même format (N2 dans notre exemple). Le transcodeur transcode donc toujours dans ce format (N2). Lors d'une demande de changement de format par le terminal client (3), une requête est envoyée par le terminal client à un serveur web situé par exemple sur la passerelle domestique (6), qui propose le manifest (7) associé à la vidéo. Le serveur interprète cette requête de nouveau format et pilote le transcodeur de manière adéquate pour changer le format du prochain fragment : comme illustré sur la figure 2, le transcodeur génère des fragments (Frags) de débits différents au cours du temps.
Sur requête de l'un des terminaux, le serveur lui transmet le fragment généré précédemment (qui peut-être sous-optimal car ne correspondant pas à la résolution requise immédiatement). La chaîne de transcodage de l'invention permet ainsi de s'adapter dynamiquement au contenu demandé par le terminal client avec seulement un fragment de décalage (le premier fragment pouvant être sous-optimal) à l'aide d'un transcodeur unique. Il devient intéressant, dans ce contexte, de proposer un nombre important de niveaux dans le fichier de description manifest et de transcoder en temps réel la vidéo uniquement dans le format demandé par le terminal client. Notamment, le fichier manifest de l'annexe 1 peut être modifié pour proposer, non plus seulement trois résolutions, mais autant qu'on le souhaite, offrant ainsi un choix illimité au terminal client. Selon une variante, la requête est accompagnée d'un paramètre qui permet d'identifier les capacités du terminal client, par exemple en termes de résolution d'affichage. Le fichier manifest peut alors être adapté à la volée au terminal client : rien ne sert de lui proposer des niveaux qu'il ne sera pas capable de décoder. Selon une autre variante, la passerelle analyse l'état de la bande passante du réseau et adapte le manifest en conséquence.
De façon à ne pas trop pénaliser le terminal client du fait du temps nécessaire à la récupération des fragments, on doit pré-transcoder lors de l'initialisation au moins un fragment vidéo en avance sur celui qui va être téléchargé par le terminal client. Il est judicieux de transcoder ce fragment au niveau le plus faible possible en termes de résolution/débit/qualité, dans l'exemple 500kbps, afin que tous les terminaux puissent en bénéficier. La figure 3 représente l'architecture d'un équipement qui implémente un mode de réalisation de l'invention, comme par exemple la passerelle de service (6) de la figure 2. Elle 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. La passerelle (6) communique avec le réseau local et le réseau large bande (12) via le module Ethernet (ETH) d'une part et éventuellement le module WIFI pour une communication locale sans fils. La passerelle de service (6) comprend en outre, conformément à l'invention, un module de gestion du transcodage TRANSC et un transcodeur (11). Le module TRANSC, qui peut être logiciel et/ou matériel, est notamment capable de fournir et adapter les fichiers de description (DESC) de manière dynamique, de piloter (PIL) le (ou les) transcodeur(s) (11) et de mettre à disposition un site Web sur lequel les terminaux clients viennent se connecter et chercher les fichiers Manifest. La passerelle de service selon l'invention peut aussi contenir un disque dur (15) pour le stockage des fragments vidéo, et éventuellement d'autres modules, comme par exemple un module de contrôle d'accès (CAS), un module d'interface vidéo, etc. La figure 4 décrit les différentes étapes de streaming selon l'invention sous forme de chronogramme. Comme expliqué plus haut, avant d'avoir accès au premier segment de la vidéo (C) qu'il souhaite visualiser, le terminal client doit commencer par récupérer le fichier de description manifest (7). Ainsi lors d'une étape El, le terminal (3) demande le fichier de description « C.mpd » (7) qui lui est transmis par la plate-forme (6) au cours d'une étape E10. La passerelle de service (6) répond en fournissant au terminal l'adresse du fichier manifest, ou le fichier manif est lui-même. Dans cet exemple, l'adresse URL « http://x.com/C.mpd » représente l'adresse d'un fichier C de description de type manifest (.mpd) qui peut être téléchargé sur le site « x.com » de la passerelle, mais il pourrait aussi s'agir d'une adresse universelle (URI) décrivant un autre protocole (« ftp://monfichierdedescription » par exemple) et/ou d'un accès sur un autre réseau, ou serveur. A partir de cette URL (ou URI), le document de description (7) peut être téléchargé sur la passerelle (6). Selon une variante, une identification <ID> du terminal client est effectuée en paramètre de la requête HTTP : par exemple, le champ « USER- AGENT » de la requête HTTP peut être utilisé. On peut en déduire pour chaque terminal client la taille de l'écran qu'il supporte. Selon le paramètre de cette requête, un fichier manifest adapté peut être transmis au terminal : par exemple, si le terminal qui émet la requête est une tablette, il est inutile de lui fournir des résolutions très élevées. Au contraire il peut être intéressant de lui proposer davantage de points de débit à une même résolution, ou des résolutions plus faibles que celles initialement contenues dans le fichier manifest.
Selon une autre variante, on peut déduire pour chaque terminal client les capacités de décodage supportées et adapter en conséquence le choix du codeur/décodeur à utiliser (attributs « codec » et « mimeType » du fichier manifest).
Lors d'une étape d'initialisation El 1 Le serveur Web de la passerelle (6) intime au module de pilotage du transcodeur de générer immédiatement le premier fragment vidéo (f1) au plus petit niveau décrit dans le fichier manifest requis (N3), puis le module de pilotage stocke éventuellement le fichier sur le disque et met le module transcodeur vidéo en pause (E12). Ainsi, quel que soit le format choisi ultérieurement par le terminal client, celui-ci pourra recevoir et consommer le fragment précédemment généré, puisque le niveau utilisé lors de sa génération est forcément inférieur ou égal à celui qui sera réellement requis par le terminal client. Notamment, s'il s'agit de la première requête, le terminal client récupère le premier fragment de la vidéo (f1) au niveau le plus faible (N3).
Comme décrit à l'appui de la figure 1, une URL d'accès à ce premier fragment vidéo pour une qualité de 500 kbps (N3) est http://x.com/bunny/bunny_1s_500kbit/bunny_1s1. m4s, schématisé sur la figure par "fi .N3" Le premier fragment peut être immédiatement transmis au terminal client (3) à la suite de cette étape. Le terminal le reçoit lors d'une étape E2. Puis le terminal client analyse le fichier de description (7) qui lui a été fourni lors d'une étape E3 et génère une adresse d'un second fragment de contenu (http://x.com/bunny/bunny_1s_1Mb/bunny_1s2.m4s résumée sur la figure en en http://x.com/N2/f2) correspondant aux caractéristiques souhaitées (débit/résolution/qualité) du niveau N2. Lors d'une étape E14, Le serveur Web reçoit cette requête et transmet au module de pilotage du transcodeur le format choisi par le terminal client (N2).
Le module de pilotage du transcodeur demande au transcodeur (11) de générer les fragments suivants (f2, f3, etc.) selon le format choisi par le terminal client (N2, 1000kbps) au cours d'une étape E22. Les fragments correspondant sont éventuellement stockés sur le disque puis transmis au terminal client lors d'une étape E16. On va ainsi pouvoir se rapprocher rapidement (en fonction de la durée des fragments générés) du format optimal requis. Puis le module de pilotage va remettre le module transcodeur vidéo en pause dans l'attente d'une nouvelle requête. En effet, en général, l'encodage matériel est plus rapide que la vitesse de consommation de contenu par le terminal client (qui peut, de plus, mettre la lecture du flux en attente ou en arrêt sans que la passerelle en soit avertie). Il est donc préférable de ne pas générer trop de fragments en avance car on ne pourrait plus s'adapter aux changements demandés par le terminal client.
Le transcodeur contrôlé par le module pilote continue ainsi à générer les fragments de manière dynamique en respectant les phases de pause et d'asservissement jusqu'à la fin de la lecture du contenu vidéo qui peut être visualisé par le terminal client au cours d'une étape E5 facultative. Lors d'une nouvelle requête pour un nouveau fichier manifeste, les étapes El 0 à E16 sont effectuées de nouveau sur la passerelle de service. En variante, la passerelle de service peut surveiller les évolutions de la bande passante dans le réseau et adapter en conséquence la taille des fragments : par exemple si la bande passante diminue, il peut être préférable de générer des fragments plus petits, et donc par exemple de modifier leur valeur dans le manifest (attribut « duration ») fourni au terminal client. Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent y être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention.30 Annexe 1 : exemple de fichier manifest MPEG-DASH <?xml version="1.0"?> <MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:DASH:schema:MPD:2011" xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd" type="dynamic" minimumUpdatePeriod=" PT1.0S " profiles="urn:mpeg:dash:profile:isoff-live:2011"> <Representation id="0" codecs="avc1" mimeType="video/mp4" width="320" height="240" startWithSAP="1" bandwidth="46986"> <BaseURL>http://x.com/ Bunny</BaseURL> <SegmentBase> <Initialization sourceURL="bunny_1s_500kbit/bunny_500kbit_dash.mp4"/> </SegmentBase> <SegmentList duration="1"> <SegmentURL media="bunny_1s_500kb/bunny_1s1.m4s"/> <SegmentURL media="bunny_1s_500kb/bunny_1s2.m4s"/> <SegmentURL media="bunny_1s_500kb/bunny_1s3.m4s"/> </SegmentList> <SegmentList duration="1"> <SegmentURL media="bunny_1s_1000kb/bunny_1s1.m4s"/> <SegmentURL media="bunny_1s_1000kb/bunny_1s2.m4s"/> <SegmentURL media="bunny_1s_1000kb/bunny_1s3.m4s"/> </SegmentList> <SegmentList duration="1"> <SegmentURL media="bunny_1s_2000kb/bunny_1s1.m4s"/> <SegmentURL media="bunny_1s_2000kb/bunny_1s2.m4s"/> <SegmentURL media="bunny_1s_2000kb/bunny_1s3.m4s"/> </SegmentList> </MPD>

Claims (9)

  1. REVENDICATIONS1. Procédé de gestion d'un contenu multimédia apte à être restitué par un terminal (2-4) d'un réseau (1,12) connecté à une passerelle de service (6), ledit contenu étant apte à être transcodé en fragments (Frags) de données selon plusieurs résolutions (N1-N3), ledit procédé comprenant les étapes de : Réception d'une requête (E10) pour la restitution d'un contenu (C) selon un second niveau (N1-N2); Mise à disposition du terminal d'au moins un premier fragment (fi .N3) du contenu (C) selon un premier niveau (N3) ; Commande de transcodage d'au moins un fragment (fi .N2, f2.N2) selon le second niveau (N2) ; Mise à disposition du terminal (2-4) d'au moins un fragment (fi .N2, f2.N2) selon le second niveau (N2).
  2. 2. Procédé selon la revendication 1, caractérisé en ce que le premier et le second niveau (Ni, N2, N3) sont décrits dans un fichier de description (C.mpd, manifest) du contenu numérique (C).
  3. 3. Procédé selon la revendication 2, caractérisé en ce que le fichier de description (C.mpd, manifest) du contenu numérique (C) est adapté en fonction du terminal.
  4. 4. Procédé selon la revendication 2, caractérisé en ce que le fichier de description (C.mpd, manifest) du contenu numérique (C) est adapté (chunks, duration, 1s) en fonction du débit disponible sur le réseau.
  5. 5. Procédé selon la revendication 2, caractérisé en ce que le format de codage (mimeType, codec, avc1) du contenu numérique (C) est adapté en fonction du terminal.
  6. 6. Procédé selon la revendication 2, caractérisé en ce que le premier niveau est le niveau le plus faible du fichier de description (C.mpd) du contenu numérique (C).
  7. 7. Dispositif (TRANSC) de gestion d'un contenu multimédia apte à être restitué par un terminal (2-4) d'un réseau (1,12), ledit contenu étant apte à êtretranscodé en fragments (Frags) de données selon plusieurs résolutions (Ni-N3), ledit dispositif comprenant : Un module de réception d'une requête (E10) pour la restitution d'un contenu (C) selon un second niveau (N1-N2); Un module (WIFI, ETH) pour la mise à disposition du terminal d'au moins un premier fragment (fi .N3) du contenu (C) selon un premier niveau (N3) ; Un module de pilotage (PIL) du transcodage d'au moins un fragment (fi .N2, f2.N2) selon le second niveau (N2) ; Un module (WIFI, ETH) de mise à disposition du terminal (2-4) d'au moins un fragment (fi .N2, f2.N2) selon le second niveau (N2).
  8. 8. Passerelle de service (6) comportant un dispositif de gestion d'un contenu multimédia (TRANSC) selon la revendication 7.
  9. 9. Programme d'ordinateur comportant des instructions de code pour la mise en oeuvre de la gestion d'un contenu multimédia conforme à la revendication 1, lorsque celle-ci est exécutée par un processeur.
FR1352878A 2013-03-29 2013-03-29 Transcodage et diffusion adaptative de contenus multimedia Pending FR3004055A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1352878A FR3004055A1 (fr) 2013-03-29 2013-03-29 Transcodage et diffusion adaptative de contenus multimedia
PCT/FR2014/050740 WO2014155017A1 (fr) 2013-03-29 2014-03-28 Transcodage et diffusion adaptative de contenus multimédia

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1352878A FR3004055A1 (fr) 2013-03-29 2013-03-29 Transcodage et diffusion adaptative de contenus multimedia

Publications (1)

Publication Number Publication Date
FR3004055A1 true FR3004055A1 (fr) 2014-10-03

Family

ID=48656115

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1352878A Pending FR3004055A1 (fr) 2013-03-29 2013-03-29 Transcodage et diffusion adaptative de contenus multimedia

Country Status (2)

Country Link
FR (1) FR3004055A1 (fr)
WO (1) WO2014155017A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20170114360A (ko) * 2016-04-04 2017-10-16 엘에스산전 주식회사 Ｎ－스크린 기능을 지원하는 원격 관리 시스템
FR3071374A1 (fr) * 2017-09-15 2019-03-22 Neotion Procede et systeme pour distribuer un contenu multimedia a des terminaux informatiques

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005029224A2 (fr) * 2003-09-12 2005-03-31 Arkados, Inc. Procede et systeme de gestion et de distribution de contenu reparti
US20080141303A1 (en) * 2005-12-29 2008-06-12 United Video Properties, Inc. Interactive media guidance system having multiple devices
US20080181578A1 (en) * 2007-01-31 2008-07-31 Hanes David H Transcoding of media content
US20080195744A1 (en) * 2007-02-14 2008-08-14 Microsoft Corporation Adaptive media playback
US20090103607A1 (en) * 2004-06-07 2009-04-23 Sling Media Pvt. Ltd. Systems and methods for controlling the encoding of a media stream
WO2010014123A1 (fr) * 2008-07-26 2010-02-04 Thomson Licensing Procédé de mise en paquets avec un protocole de transport en temps réel (rtp) pour des applications de changement de canal rapide utilisant un codage vidéo évolutif (svc)

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005029224A2 (fr) * 2003-09-12 2005-03-31 Arkados, Inc. Procede et systeme de gestion et de distribution de contenu reparti
US20090103607A1 (en) * 2004-06-07 2009-04-23 Sling Media Pvt. Ltd. Systems and methods for controlling the encoding of a media stream
US20080141303A1 (en) * 2005-12-29 2008-06-12 United Video Properties, Inc. Interactive media guidance system having multiple devices
US20080181578A1 (en) * 2007-01-31 2008-07-31 Hanes David H Transcoding of media content
US20080195744A1 (en) * 2007-02-14 2008-08-14 Microsoft Corporation Adaptive media playback
WO2010014123A1 (fr) * 2008-07-26 2010-02-04 Thomson Licensing Procédé de mise en paquets avec un protocole de transport en temps réel (rtp) pour des applications de changement de canal rapide utilisant un codage vidéo évolutif (svc)

Also Published As

Publication number Publication date
WO2014155017A1 (fr) 2014-10-02

Similar Documents

Publication Publication Date Title
US9351020B2 (en) On the fly transcoding of video on demand content for adaptive streaming
EP3127336B1 (fr) Dispositif et procédé de commande a distance de la restitution de contenus multimedia
EP3072303B1 (fr) Diffusion adaptative de contenus multimedia
Chakraborty et al. Dynamic http live streaming method for live feeds
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
EP3496407A1 (fr) Procédé de gestion de la consommation électrique d&#39;un dispositif électronique
WO2014155017A1 (fr) Transcodage et diffusion adaptative de contenus multimédia
WO2019220034A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique au sein d&#39;un terminal de restitution d&#39;un réseau de communication local
EP3245794A1 (fr) Procédé de transmission d&#39;un flux de données utilisant un protocole de diffusion en direct
EP3461135A1 (fr) Procédé de gestion du droit d&#39;accès à un contenu numérique
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.
EP3987820A1 (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
EP4035408A1 (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
EP2819424A1 (fr) Procédé d&#39;amelioration du temps de changement entre programmes audiovisuels
US20220030298A1 (en) Adaptive bitrate video management platform
EP3675505B1 (fr) Procede et systeme de distribution d&#39;un contenu audiovisuel
EP2879352A1 (fr) Contrôle de la diffusion de contenus multimedia
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
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
FR3111502A1 (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
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
EP3721637A1 (fr) Procédé de gestion des connexions d&#39;un dispositif électronique
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.
FR2931328A1 (fr) Procede pour donner acces a un service sur un terminal par l&#39;intermediaire d&#39;une passerelle domestique