FR3109489A1 - Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau - Google Patents

Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau Download PDF

Info

Publication number
FR3109489A1
FR3109489A1 FR2003825A FR2003825A FR3109489A1 FR 3109489 A1 FR3109489 A1 FR 3109489A1 FR 2003825 A FR2003825 A FR 2003825A FR 2003825 A FR2003825 A FR 2003825A FR 3109489 A1 FR3109489 A1 FR 3109489A1
Authority
FR
France
Prior art keywords
content
bit rate
digital content
network
encoding
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
FR2003825A
Other languages
English (en)
Other versions
FR3109489B1 (fr
Inventor
Olivier Gaste
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 FR2003825A priority Critical patent/FR3109489B1/fr
Priority to PCT/FR2021/050638 priority patent/WO2021209706A1/fr
Publication of FR3109489A1 publication Critical patent/FR3109489A1/fr
Application granted granted Critical
Publication of FR3109489B1 publication Critical patent/FR3109489B1/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/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/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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • 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)
  • Library & Information Science (AREA)
  • Databases & Information Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau L'invention concerne un procédé de préparation d’un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau de distribution dudit contenu ; le contenu numérique (C1) est associé à un fichier de description du contenu numérique, comprenant une liste de segments temporels du contenu associés chacun à plusieurs débits d’encodage apparents du contenu ; les segments temporels du contenu numérique sont encodés (20) selon une méthode d’encodage à débit variable (VBR) associé à un débit d’encodage moyen (ABR) et à un débit d’encodage maximum (MBR).Selon l’invention, un tel procédé comprend une détermination (21) des débits d’encodage apparents (Nj) exposés dans le fichier de description en association avec les segments temporels du contenu, en fonction d’au moins un critère de charge (ChNet) du réseau de distribution, un débit d’encodage apparent (Nj) pouvant prendre une valeur comprise entre le débit d’encodage moyen (ABRj) et le débit d’encodage maximum (MBRj). Figure pour l’abrégé : Fig 2

Description

Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau
Le domaine de l'invention est celui des contenus multimédias numériques, à savoir les contenus audio et/ou vidéo numériques. Plus précisément, l'invention concerne la préparation de contenus numériques accessibles selon une technique dite de téléchargement progressif adaptatif, et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau.
Art antérieur
L’accès à un contenu multimédia, tel que la télévision ou la vidéo à la demande, est possible aujourd’hui, pour la plupart des terminaux de restitution.
Le terminal émet généralement une requête à destination d’un serveur, en indiquant le contenu choisi et il reçoit en retour un flux de données numériques relatives à ce contenu.
Le terminal 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. Dans la suite, par souci de simplification, on assimilera le contenu numérique à une vidéo et la restitution par le terminal, ou consommation par l’utilisateur du terminal, à une visualisation sur l’écran du terminal.
La diffusion de contenus numériques est souvent basée sur des protocoles client-serveur de la famille HTTP (de l’anglais « Hyper Text Transport Protocol »). En particulier, le téléchargement en mode progressif 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 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, en fonction par exemple de la fluctuation de la bande passante disponible.
Le téléchargement progressif adaptatif, en anglais HTTP Adaptative Streaming, d’abréviation HAS, permet de surcroît de diffuser et recevoir des données suivant différentes qualités 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 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 manifestes, contenant les adresses des différents segments aux différentes qualités 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 de courte durée (de l’ordre de quelques secondes), également appelés « chunks ». 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 manifeste 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 son tampon de réception, choisit, pour le prochain segment à charger, une représentation dont le débit :
  • assure la meilleure qualité possible,
  • et permet un délai de réception compatible avec le rendu ininterrompu du contenu.
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, 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.
La consommation de contenus numériques en téléchargement progressif adaptatif (HAS) tend à se démocratiser. Elle est notamment utilisée par de nombreux services de streaming (en français, diffusion en mode continu, ou lecture en continu), mais également par certains décodeurs TV, ou set-top-box, qui l’utilisent pour accéder à des contenus délinéarisés, tels que 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).
En outre, d’autres dispositifs tels que des appareils lecteurs de flux multimédia en temps réel accèdent également aux contenus numériques en mode de téléchargement adaptatif progressif pour des contenus télévisuels en temps réel (ou Live). C’est le cas par exemple de l’appareil Chromecast® développé par Google®, ou de la CléTV® d’Orange®. De tels appareils, plus génériquement désignés sous le nom de Clef HDMI, peuvent également être utilisés pour accéder à des contenus de type vidéo à la demande.
De tels appareils se branchent classiquement sur le port HDMI d’un téléviseur et communiquent, par exemple par connexion Wi-Fi®, avec un autre appareil du réseau de communication domestique connecté à un réseau de communication étendu (par exemple un téléphone intelligent de type smartphone, connecté à un réseau mobile 4G), afin de restituer, sur le téléviseur, le contenu multimédia reçu par une application logicielle compatible. On désignera par la suite ces appareils sous la désignation générique de Clef HDMI.
Il existe par ailleurs plusieurs techniques d’encodage des contenus numériques qui sont ainsi accessibles en téléchargement progressif adaptatif HAS.
Une première technique connue, appelée CBR (pour l’anglais « Constant Bit Rate », que l’on peut traduire par « taux d’échantillonnage fixe »), consiste à encoder le contenu à un débit constant : ainsi, tous les segments vidéo, ou « chunks », d’un même niveau de qualité, présentent une taille identique, exprimée en kilo octets. Ainsi, quelle que soit la nature des images encodées, la taille des segments est toujours la même, ce qui permet de prévoir la consommation de données dans le réseau de distribution des contenus numériques.
Une autre technique d’encodage connue, appelée VBR (pour l’anglais « Variable Bit Rate », que l’on peut traduire par « taux d’échantillonnage variable »), permet d’encoder le contenu à un débit variable, borné par un débit maximum appelé MBR (pour « Max Bit Rate »). Le débit moyen d’encodage obtenu pour le contenu est appelé ABR (pour « Average Bit Rate »). Selon cette technique, la taille des segments vidéo d’un même niveau de qualité évolue en fonction du contenu numérique encodé et de la nature des images : ainsi, les segments vidéo correspondant à une scène très animée seront encodés à un débit proche du débit maximum MBR, contrairement aux « chunks » de scènes très peu animées (par exemple des images noires avec très peu de mouvement), qui seront encodés selon un débit d’encodage plus faible, par exemple inférieur au débit moyen ABR.
En considérant des segments vidéo de même durée (par exemple 2s) et de même niveau de qualité, on observera donc une très forte disparité de leur taille (en kilo octets), en fonction de la portion de contenu à laquelle ils correspondent (scène calme ou scène animée).
Cette technique d’encodage à débit variable VBR est avantageuse en ce qu’elle permet de diminuer la taille moyenne en kilo octets des segments vidéo, tout en conservant un même niveau de qualité perçue par l’utilisateur : on observe ainsi en moyenne une diminution de 50% de l’utilisation de la bande passante sur le réseau, par rapport à un encodage en CBR, pour une même qualité vidéo.
On comprend aisément que, pour un contenu encodé selon une technique CBR, le débit d’encodage apparent exposé dans le fichier de description du contenu, ou manifeste, est le débit d’encodage constant qui s’applique pour l’ensemble du contenu, en fonction du niveau de qualité proposé. Ainsi, un fichier manifest (MPD) conforme à la norme MPEG-DASH peut comporter la description d’un contenu disponible dans trois qualités différentes (N1 = 512 kb/s, N2 = 1024 kb/s, N3 = 2048 kb/s), où N1, N2 et N3 désignent les débits d’encodage constants utilisés pour l’encodage de l’ensemble des segments vidéo du contenu. Le terminal de restitution multimédia choisit alors de télécharger les segments à l’un de ces trois niveaux de qualité : pour un même niveau de qualité, tous les segments téléchargés sont de même taille en kilo octets.
En revanche, pour un contenu encodé selon une technique VBR, se pose la question de savoir quel est le débit d’encodage apparent qu’il convient d’exposer dans le fichier manifest.
Une première option consiste à exposer dans le fichier manifest, pour chaque niveau de qualité du contenu, le débit d’encodage maximum MBR des segments vidéo : cette première option est avantageuse en termes de diminution de la consommation de la bande passante dans le réseau de diffusion des contenus HAS. En effet, l’affichage du débit maximum MBR dans le fichier manifest conduit le terminal lecteur de flux multimédia à surestimer la taille des segments à télécharger, par rapport à leur taille effective. C’est cette valeur de MBR qui est utilisée par le terminal lecteur de flux multimédia pour calculer le temps de récupération des chunks, et ainsi déterminer le niveau de qualité proposé dans le fichier manifest auquel il peut prétendre. Ceci conduit donc le terminal lecteur de flux multimédia à sélectionner un niveau de qualité probablement inférieur à celui auquel il pourrait effectivement prétendre en pratique, et donc, in fine, pour l’opérateur, à une diminution de la consommation de la bande passante et à une réduction de la charge du réseau de distribution.
Une deuxième option consiste à exposer dans le fichier manifest, non pas le débit maximum MBR, mais, pour chaque niveau de qualité du contenu, le débit d’encodage moyen ABR associé. Cette deuxième option permet avantageusement d’améliorer la qualité perçue par l’utilisateur.
Ces deux options présentent donc chacune leurs intérêts, selon les attentes respectives de l’opérateur d’une part, et du client d’autre part. Elles présentent cependant l’inconvénient d’être figées : le choix, une fois pour toutes, d’exposer dans le fichier manifest, soit le débit maximum MBR, soit le débit moyen ABR, ne permet en effet pas de s’adapter au contexte.
Il existe donc un besoin d’une technique de préparation de contenus numériques accessibles en téléchargement HAS et encodés selon une technique d’encodage VBR à débit variable qui ne présente pas ces différents inconvénients de l’art antérieur. Notamment, il existe un besoin d’une telle technique qui permette de s’adapter finement au contexte, tout particulièrement, mais non exclusivement, au contexte particulier de charge du réseau de diffusion de contenus et des serveurs associés.
Il existe également un besoin d’une telle technique qui permette de profiter de façon combinée des avantages des techniques connues d’affichage du MBR et d’affichage de l’ABR dans le fichier manifest.
Il existe encore un besoin d’une telle technique qui soit simple à mettre en œuvre et puisse répondre conjointement aux attentes de l’opérateur du réseau d’une part, et des clients utilisateurs d’autre part.
L'invention répond à ce besoin en proposant un procédé de préparation d’un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau de distribution dudit contenu. Le contenu numérique est associé à un fichier de description du contenu numérique, comprenant une liste de segments temporels (C1i@Nj) du contenu associés chacun à plusieurs débits d’encodage apparents du contenu.
Les segments temporels du contenu numérique sont encodés selon une méthode d’encodage à débit variable (VBR) associé à un débit d’encodage moyen (ABR) et à un débit d’encodage maximum (MBR).
Selon l’invention, un tel procédé comprend une détermination des débits d’encodage apparents exposés dans le fichier de description en association avec les segments temporels du contenu, en fonction d’au moins un critère de charge (ChNet) du réseau de distribution, un débit d’encodage apparent pouvant prendre une valeur comprise entre le débit d’encodage moyen et le débit d’encodage maximum.
Ainsi, l’invention repose sur une approche tout à fait nouvelle et inventive de la préparation des contenus numériques mis à disposition des terminaux clients utilisateurs pour un téléchargement progressif adaptatif de type HAS, lorsque ces contenus sont encodés selon une technique d’encodage à débit variable VBR.
En effet, contrairement aux techniques de l’art antérieur, selon lesquelles on décide une fois pour toutes d’exposer dans le fichier manifest, soit le débit maximum MBR, soit le débit moyen ABR, la technique de l’invention propose au contraire de faire évoluer dans le temps le débit apparent exposé dans ce fichier de description, en fonction d’un ou plusieurs critères de charge du réseau de distribution de contenus. Ce débit apparent peut avantageusement prendre une valeur comprise entre le débit moyen ABR, pour améliorer la qualité perçue par l’utilisateur, et le débit maximum MBR, pour diminuer la consommation de ressources dans le réseau.
En d’autres termes, la solution proposée vise à adapter le contenu du manifest en fonction de l’utilisation en temps réel de la charge réseau de l’opérateur. On entend ici, par charge réseau, l’ensemble de la charge générée sur les serveurs de contenus et également sur la consommation de bande passante dans le réseau de l’opérateur.
Selon un premier mode de réalisation, le débit d’encodage apparent prend une valeur égale à (MBR-ABR)/100*ChNet+ABR, où MBR désigne le débit d’encodage maximum, ABR désigne le débit d’encodage moyen et ChNet désigne une valeur, comprise entre 0 et 100, affectée audit au moins un critère de charge. Lorsque le critère de charge ChNet prend la valeur 0, la charge est nulle ; lorsqu’il prend la valeur 100, la charge est maximale.
Ainsi, si la charge est faible, la technique selon l’invention permet de privilégier l’amélioration de la qualité vidéo restituée au client, sans pour autant optimiser la diminution de la charge du réseau. En revanche, lorsque la charge augmente, la technique selon l’invention permet d’optimiser progressivement la diminution de la charge réseau au détriment de l’amélioration de la qualité de l’image.
En effet, si le critère de charge ChNetprend la valeur 0, l’opérateur construit les fichiers manifest en indiquant comme débit de chaque niveau de qualité la valeur du débit moyen ABR. Dans ce cas, on favorise au maximum l’amélioration de qualité vidéo fournie au client, sans limiter l’utilisation de bande passante. En effet, dans ce cas, le réseau de l’opérateur étant peu utilisé, il n’est pas nécessaire d’optimiser les flux.
Si la charge réseau augmente, l’opérateur expose dans les fichiers manifest une valeur de débit apparent qui augmente pour se rapprocher du débit maximum MBR lorsque la valeur du critère de charge ChNet se rapproche de 100.
Une telle approche de détermination du débit apparent à exposer dans le fichier manifest assure une boucle retour d’asservissement avantageuse.
Selon un aspect, un tel procédé de préparation de contenu comprend une mesure d’une charge du réseau de distribution et la valeur affectée audit au moins un critère de charge du réseau est fonction de la mesure.
Ainsi, l’opérateur surveille et monitore en permanence la charge réseau liée à la diffusion de contenus en HAS, et adapte sa stratégie de construction des fichiers manifest, en fonction de la charge mesurée. On assure ainsi une adaptabilité optimale de la proposition de contenu faite aux clients en fonction de la charge réelle du réseau, et le meilleur compromis possible entre la qualité vidéo perçue par l’utilisateur et la consommation de ressources pour l’opérateur.
Ceci est tout particulièrement avantageux lorsque le contenu numérique est diffusé sur le réseau en temps réel. En effet, les contenus dits LIVE sont des contenus ouverts pour lequel le terminal client doit télécharger très régulièrement le fichier de description, en général toutes les minutes. L’adaptation en temps réel des débits apparents exposés dans le fichier manifest a donc un impact direct sur le choix, par le terminal lecteur de flux multimédia, de la qualité à laquelle il peut prétendre pour le téléchargement des segments vidéo de contenu.
Selon un autre aspect, ledit au moins un critère de charge du réseau tient également compte d’au moins un paramètre appartenant au groupe comprenant :
  • une prédiction de charge du réseau ;
  • une consommation électrique du réseau ;
  • une période de l’année ;
  • une programmation de mise à jour d’équipements du réseau.
En effet, ce principe d’adaptation du débit apparent exposé dans le fichier manifest peut être étendu à la prise en compte d’autres critères de charge que la simple charge effective mesurée du réseau, et notamment prendre une dimension prédictive.
Ainsi, il est possible de tenir compte d’une période de l’année, par exemple la période hivernale au cours de laquelle la consommation électrique globale est plus élevée : dans ce cas, on tend à faire évoluer le débit apparent vers le MBR, pour réduire la consommation de ressources, et donc réduire également la consommation électrique au cours des pics enregistrés de consommation, par exemple en période d’alerte grand froid.
Il est également possible de tenir compte de prédictions de charge du réseau, obtenues par observation des charges au cours de périodes passées écoulées. Ainsi, si l’on constate une augmentation de la charge du réseau en début de mois, par rapport à la fin de mois, on peut en tenir compte pour pondérer la valeur du débit apparent exposé dans le fichier manifest.
Il est encore possible de tenir compte de périodes de congés, ou des conditions météorologiques pour prédire la charge du réseau : en effet, lorsque la météo est mauvaise, on constate que la consommation vidéo est plus importante.
On peut encore modifier volontairement le débit apparent exposé dans le fichier manifest, par exemple en cas d’opérations de maintenance ou de mise à jour de certains équipements ou de certaines plateformes du réseau de diffusion des contenus, pour alléger la charge sur les autres équipements.
On peut encore agir sur ce débit apparent pour tenir compte de situations inédites et imprévues, par exemple afin de réduire la consommation en ressources du réseau lors d’une période de confinement de la population, pour privilégier l’accès aux ressources pour des besoins plus prioritaires, tels que le télétravail.
L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé tel que décrit précédemment, lorsqu’il est exécuté par un processeur.
L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé de préparation d’un contenu numérique selon l’invention, tel que décrit ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.
D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de contrôle d’affichage précité.
L’invention concerne également une plate-forme de préparation d’un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau de distribution du contenu. Le contenu numérique est associé à un fichier de description du contenu numérique, comprenant une liste de segments temporels (C1i@Nj) du contenu associés chacun à plusieurs débits d’encodage apparents du contenu. Les segments temporels du contenu numérique sont encodés selon une méthode d’encodage à débit variable (VBR) associé à un débit d’encodage moyen (ABR) et à un débit d’encodage maximum (MBR).
Selon l’invention, une telle plate-forme comprend un calculateur apte à déterminer les débits d’encodage apparents exposés dans le fichier de description en association avec les segments temporels du contenu, en fonction d’au moins un critère de charge (ChNet) du réseau de distribution, un débit d’encodage apparent pouvant prendre une valeur comprise entre le débit d’encodage moyen et le débit d’encodage maximum.
On notera que cette plate-forme peut être dissociée de la plate-forme de mise à disposition du contenu, dont la structure et le fonctionnement ne sont pas impactés par la technique de l’invention.
Avantageusement, le débit d’encodage apparent déterminé par le calculateur prend une valeur égale à (MBR-ABR)/100*ChNet+ABR, où MBR désigne le débit d’encodage maximum, ABR désigne le débit d’encodage moyen et ChNet désigne une valeur, comprise entre 0 et 100, affectée audit au moins un critère de charge.
Selon un autre aspect, une telle plate-forme de préparation d’un contenu numérique comprend un module de mesure d’une charge du réseau de distribution et le calculateur affecte audit au moins un critère de charge du réseau une valeur qui est fonction de la charge mesurée.
Selon un autre aspect, un tel critère de charge du réseau tient également compte d’au moins un paramètre appartenant au groupe comprenant :
  • une prédiction de charge du réseau ;
  • une consommation électrique du réseau ;
  • une période de l’année ;
  • une programmation de mise à jour d’équipements du réseau.
Présentation 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 :
présente une architecture de téléchargement progressif sur réseau mobile basée sur l’utilisation du streaming adaptatif selon l’invention ;
illustre sous forme d’organigramme schématique les différentes étapes du procédé de préparation d’un contenu selon un mode de réalisation de l’invention ;
illustre le principe d’évolution du débit d’encodage d’un contenu encodé selon une technique à débit variable de type VBR ;
présente la structure matérielle d’une plateforme de préparation d’un contenu numérique mettant en œuvre le procédé de Fig 2.
Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention repose sur l’adaptation des fichiers de description des contenus numériques accessibles en téléchargement progressif HAS et encodés selon une technique d’encodage à débit variable VBR, afin de faire évoluer le débit apparent exposé dans ces fichiers de description, en fonction d’un ou plusieurs critères de charge du réseau de distribution.
On présente désormais, en relation avecFig 1, une architecture de téléchargement progressif basée sur l’utilisation du streaming adaptatif selon l’invention.
Le terminal 3, par exemple un téléphone intelligent de type « smartphone » et le terminal 4, par exemple une tablette, sont, dans cet exemple, connectés à un réseau de communication étendu 1, formant réseau de distribution de contenus numériques. Ils communiquent avec un terminal 8, par exemple une clef HDMI connectée à un téléviseur 5.
Un serveur de contenus numériques 2 se trouve selon cet exemple dans le réseau étendu (WAN, 1) et 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.
Les terminaux client 3 et 4 peuvent entrer en communication avec le serveur de contenus 2 pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.).
Il est fréquent, dans ce contexte client-serveur, de recourir, pour échanger les données entre les terminaux client 3, 4 et le serveur 2, à 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 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 apparent. Chaque niveau de qualité est lui-même découpé sur le serveur de contenus en segments temporels (ou « fragments » de contenu, en anglais « chunks », ces trois 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 fragments 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 fragments, etc.) est en général regroupé dans un fichier de paramètres, dit fichier de description. 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.
Les terminaux 3, 4 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 apparents 512 kb/s (kilobits par seconde) (Résolution 1, ou niveau 1, noté N1), 1024 kb/s (N2), 2048 kb/s (N3) 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@Nj » le contenu numéro i avec la qualité j (par exemple le j-ième niveau Nj de qualité décrit dans le fichier de description).
Les terminaux clients 3, 4 reçoivent les données en provenance du réseau étendu 1 et assurent leur décodage, et éventuellement leur restitution sur leur écran, ou leur transmission à la clef HDMI 8 pour restitution sur l’écran du téléviseur 5. En variante, les décodeurs peuvent se trouver ailleurs dans le réseau, notamment au niveau d’un élément de type STB (de l’anglais Set-Top-Box) (non représenté) associé à un téléviseur.
Dans cet exemple, pour visualiser un contenu, le terminal 3, 4 ou 8 récupère tout d’abord une adresse du document de description 7 du contenu (par exemple, C1) souhaité. 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 ». Ce fichier peut être récupéré directement auprès d’un serveur Internet du réseau étendu 1, ou se trouver déjà 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 (N1 = 512 kb/s, N2 = 1024 kb/s, N3 = 2048 kb/s) des contenus fragmentés est présenté enannexe 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 fragments classiquement décrits entre une balise ouvrante (<SegmentList>) et une balise fermante (</SegmentList>). La découpe en fragments permet notamment de s’adapter finement aux fluctuations de la bande passante. Chaque fragment 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 fragments :
- « C1_512kb_1.mp4 » pour le premier fragment du contenu « C1 » à un débit apparent de 512 kilobits par seconde (« kb ») au format MPEG-4 (« mp4 »),
- « C1_512kb_2.mp4 » pour le second fragment,
- etc.
Une fois qu’il dispose des adresses de fragments correspondant au contenu souhaité, le terminal procède à l’obtention des fragments 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).
On suppose ici que la clef HDMI 8 est connectée au téléviseur 5 par branchement sur le port HDMI de ce dernier, et est utilisée pour restituer, sur l’écran du téléviseur 5, un contenu C1, décrit dans un fichier manifeste 7. On notera que le contenu C1 peut être un programme télévisuel diffusé en direct ou en différé, ou une vidéo à la demande, ou tout autre contenu multimédia.
La clef HDMI 8 peut être connectée en WiFi® directement à la tablette 4 ou au téléphone intelligent 3, par l’intermédiaire duquel elle peut accéder au réseau de communication étendu 1, par exemple via une connexion 4G.
La clef HDMI 8 peut également être pilotée par l’utilisateur au moyen du téléphone intelligent 3, sur lequel est installé une application logicielle de commande de la clef HDMI 8.
Les fragments de contenu obtenus par le smartphone 3 ou la tablette 4 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.
Fig 2illustre sous forme d’organigramme simplifié les différentes étapes mises en œuvre selon un mode de réalisation de l’invention pour préparer le fichier manifeste 7, lorsqu’un contenu C1 est destiné à être encodé selon une technique d’encodage à débit variable, VBR. On considère dans cet exemple un contenu C1 diffusé en temps réel, également appelé LIVE. En effet, pour de tels contenus LIVE, le terminal lecteur de flux multimédia récupère à intervalles de temps très réguliers le fichier manifest 7, par exemple toutes les minutes environ, selon une technique connue. L’adaptation du débit apparent du contenu exposé dans ce fichier manifest 7, en fonction d’un critère de charge, est donc particulièrement efficace et directement suivie d’effet, pour le choix de débit et de niveau de qualité effectué par le terminal lecteur de flux multimédia, par exemple la clef HDMI 8.
Au cours d’une première étape référencée 20, le contenu C1 est encodé selon une technique d’encodage à débit variable VBR. En d’autres termes, le contenu C1 est fractionné en segments, ou chunks, de durée constante, par exemple de 2s. Chaque segment du contenu C1 est alors encodé selon un débit d’encodage qui peut fluctuer, en fonction de la nature du contenu sur la durée du segment. Ce débit d’encodage est cependant borné par le débit d’encodage maximum MBR (pour un niveau de qualité ou une résolution donnés). Le débit d’encodage moyen du contenu C1 est appelé ABR (pour un niveau de qualité ou une résolution donnés). Ceci est illustré parFig 3, qui représente sous forme simplifiée une fluctuation possible du débit d’encodage du contenu C1 en fonction du temps, selon la technique d’encodage VBR. Les deux droites horizontales en traits pointillés représentent respectivement (pour un niveau de qualité ou une résolution donnés) le débit d’encodage maximum MBR qui est atteint pour ce contenu C1, et le débit d’encodage moyen ABR, correspondant à la moyenne des débits d’encodage de chacun des segments.
Au cours d’une étape référencée 21, l’opérateur du réseau détermine un ou plusieurs critères de charge ChNet. Ces critères de charge comprennent notamment une estimation de la charge du réseau de distribution du contenu, telle qu’elle peut être mesurée par l’opérateur, selon des techniques connues qui ne font pas l’objet de la présente invention. Par charge réseau, on entend ici l’ensemble de la charge générée sur les serveurs de contenus, et notamment sur les plateformes de diffusion des contenus, et également la consommation de bande passante dans le réseau de l’opérateur.
Ces critères de charge peuvent également tenir compte d’autres paramètres de charge, tels que :
  • une période de l’année : ainsi, en période hivernale, en cas d’alerte grand froid, il peut être utile d’envisager une réduction de la consommation par le réseau de l’opérateur ;
  • une décision politique de l’opérateur, qui peut souhaiter privilégier la qualité perçue par ses clients ou, à l’inverse, réduire la charge sur son réseau ;
  • une situation particulière de mise à jour par l’opérateur de certains équipements ou de certaines plateformes du réseau ;
  • une politique de RSE (Responsabilité Sociétale des Entreprises) de l’opérateur, qui peut, dans une démarche de développement durable, choisir de réduire la consommation électrique de son réseau ;
  • une prédiction de charge, en fonction de l’observation passée des pics de consommation dans le réseau, en fonction de l’heure du jour, du jour de la semaine, ou de la période de l’année.
Cette liste n’est bien sûr pas exhaustive, et tout autre paramètre influant directement ou indirectement sur l’évaluation d’une charge du réseau peut être pris en compte pour la détermination, au cours de l’étape 21, de la métrique de charge ChNet.
Dans la suite, par souci de simplification, on considère que cette métrique de charge ChNet prend, à l’étape 21, une valeur comprise entre 0 et 100, où la valeur 0 correspond à une charge réseau nulle, et où la valeur 100 correspond à la charge maximale du réseau. Toute autre échelle de valeur ou pondération du critère ChNet peut bien sûr être envisagée dans le cadre de la présente invention, moyennant adaptation correspondante de la formule de calcul qui sera décrite ci-après en relation avec l’étape référencée 22.
Au cours de cette étape 22, on calcule donc le débit apparent d’encodage qui va être exposé en association avec chaque niveau de qualité du contenu, dans le fichier manifest 7. En référence à l’exemple de l’annexe 1, cette étape 22 permet donc de calculer la valeur des niveaux de qualité N1, N2, N3, etc. qui vont être affichés dans le fichier manifest 7 pour le contenu C1.
Ainsi, pour une résolution j donnée, le calculateur de la plateforme de préparation de contenu calcule le débit apparent Nj selon la formule :
Nj=(MBRj-ABRj)/100*ChNet+ABRj
Ainsi, si la charge réseau est nulle, et que le critère de charge ChNet prend la valeur 0, le débit d’encodage apparent Nj qui sera exposé dans le fichier manifest 7 pour le niveau de résolution j sera Nj=ABRj, soit le débit d’encodage moyen au niveau de qualité j pour les segments vidéo du contenu C1. Ainsi, on favorise l’amélioration de la qualité vidéo fournie au client, sans limiter l’utilisation de la bande passante. En effet, ce cas correspond à celui où le réseau de l’opérateur est peu utilisé (heures creuses par exemple), et il n’est donc pas nécessaire d’optimiser les flux.
Lorsque la charge réseau augmente, la valeur du critère de charge ChNet augmente progressivement entre 0 et 100 ; la valeur du débit d’encodage apparent Nj augmente donc également pour se rapprocher de la valeur maximale MBRj du débit d’encodage pour ce niveau de résolution. Ainsi, on favorise l’optimisation de la consommation de ressource réseau, au détriment de la qualité vidéo perçue par le client.
Le tableau ci-dessous illustre un exemple de valeurs de débits apparents exposés dans le fichier manifest 7 pour différents niveaux de résolution d’une portion du contenu C1. On suppose dans cet exemple que, pour cette portion du contenu C1, le critère de charge ChNet prend une valeur ChNet=80.
Niveau j Résolution Débit maximum (MBRj) Débit moyen (ABRj) Débit apparent (Nj)
1 320x180 pixels 600kb/s 300kb/s 540kb/s
2 569x320 pixels 1,2Mb/s 600kb/s 1080kb/s
3 1024x576 pixels 2,1Mb/s 1,05Mb/s 1,89Mb/s
4 1280x720 pixels 3Mb/s 1,5Mb/s 2,7Mb/s
5 1920x1080 pixels 5Mb/s 2,5Mb/s 4,5Mb/s
Lors du téléchargement du fichier manifest 7, le terminal lecteur de flux multimédia pourra donc choisir de demander à la plateforme de distribution de contenu un téléchargement des prochains segments vidéo à un débit d’encodage N1=540kb/s, N2=1080kb/s, N3=1,89Mb/s, N4=2,7MB/s ou N5=4,5MB/s.
Ainsi, un serveur de contenu HAS 2 expose une vidéo C1 sous forme de « chunks » C1i@Nj encodés à différents débits d’encodage Nj, où l’indice i désigne un identifiant temporel du « chunk » C1i@Nj.
Selon l’art antérieur, un module client HAS est chargé de venir récupérer ses « chunks » auprès du serveur de contenu HAS 2 en choisissant la qualité vidéo Nj en fonction de la ressource réseau disponible. 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 fragment 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 fragment au débit d’encodage le plus faible proposé dans le manifeste, et sur l’évaluation du temps de récupération de ce premier fragment. Sur cette base, le module client HAS évalue si, en fonction de la taille du fragment et du temps mis pour le récupérer, les conditions réseau permettent de télécharger le fragment suivant à un débit d’encodage plus élevé. Certains algorithmes reposent sur une augmentation progressive du niveau de qualité des fragments 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 fragments successifs.
Dans le cas classique, si un « chunk » vidéo dure 3 secondes, la récupération du « chunk » par le module client HAS ne doit pas excéder 3 secondes, afin de permettre une restitution sans interruption du contenu par le terminal. Il convient donc pour le module client 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 fragment, qui doit être suffisamment faible pour permettre une restitution en continu sur le terminal de restitution.
Pour un contenu C1 de type LIVE (i.e. diffusé en temps réel), le module de téléchargement HAS du terminal lecteur de flux multimédia récupère le fichier manifest 7 à intervalles de temps réguliers, par exemple toutes les minutes, afin de découvrir les fragments disponibles du contenu vidéo C1, et les différentes qualités vidéo apparentes Nj associées.
Ainsi, dans l’exemple deTable 1, le contenu C1 est par exemple proposé sous forme de fragments de durée 3s, avec un premier débit d’encodage apparent N1=540kb/s, un deuxième débit d’encodage apparent N2=1080kb/s, un troisième débit d’encodage apparent N3=1,89Mb/s, etc.
Sur la base des débits d’encodage Nj exposés dans le fichier manifeste 7, le module de téléchargement HAS du terminal opère le téléchargement par exemple, des fragments successifs C11@N1 (soit le premier fragment temporel à un débit d’encodage de 540kb/s), puis C12@N3 (soit le deuxième fragment temporel à un débit d’encodage de 1,89Mb /s), puis C13@N3 (soit le troisième fragment temporel à un débit d’encodage de 1,89Mb /s), ...
Ce choix opéré par le module de téléchargement HAS se fonde donc sur la valeur de débit apparent d’encodage Nj exposé dans le fichier manifest 7, et non sur la taille effective en kilo-octets des segments vidéo qu’il reçoit. Cette taille n’est en effet utilisée que pour calculer le temps de récupération des chunks, et déterminer ainsi à quel niveau de qualité j il peut prétendre.
Ainsi, s’il choisit pour le deuxième fragment temporel un téléchargement à un débit d’encodage de 1,89Mb /s (soit C12@N3), il est possible, comme illustré par Fig 3, que le débit d’encodage réel de ce fragment soit bien inférieur, par exemple de 800kb/s seulement. Le gain résultant de cette différence entre débits d’encodage apparent et effectif permet d’optimiser la consommation des ressources réseau de l’opérateur.
Les différents fragments téléchargés par le module de téléchargement HAS sont ensuite restitués à l’utilisateur sur l’écran du terminal de restitution.
Si la charge du réseau fluctue, et que la valeur du critère de charge ChNet évolue, les débits d’encodage apparents exposés dans le fichier manifest 7 vont également être modifiés, dans la version suivante du manifest 7, téléchargée par le terminal lecteur de flux multimédia, par exemple 60 s plus tard. Ainsi, si le critère de charge ChNet passe d’une valeur 80 à une valeur 40, les débits d’encodage apparent exposés dans la version suivante du fichier manifest 7 deviennent :
Niveau j Résolution Débit maximum (MBRj) Débit moyen (ABRj) Débit apparent (Nj)
1 320x180 pixels 600kb/s 300kb/s 420kb/s
2 569x320 pixels 1,2Mb/s 600kb/s 840kb/s
3 1024x576 pixels 2,1Mb/s 1,05Mb/s 1,47Mb/s
4 1280x720 pixels 3Mb/s 1,5Mb/s 2,1Mb/s
5 1920x1080 pixels 5Mb/s 2,5Mb/s 3,5Mb/s
La charge ayant diminué, on peut exposer des débits d’encodage apparents plus faibles dans le fichier manifest 7, et ainsi favoriser l’amélioration de la qualité vidéo fournie à l’utilisateur.
On assure ainsi une boucle retour d’asservissement, selon laquelle, plus la charge réseau est faible, et plus on autorise à consommer une part importante des ressources du réseau de l’opérateur, et ainsi à faire en sorte que l’encodage en VBR (en comparaison avec l’encodage CBR) participe à l’amélioration de la qualité vidéo rendue au client final.
Le mode de réalisation ci-dessus a été décrit dans le contexte d’un contenu vidéo C1 diffusé en temps réel, ou LIVE, pour lequel le fichier manifest est téléchargé à intervalles de temps réguliers par le terminal lecteur de flux multimédia, ce qui permet d’assurer un asservissement.
On notera que la technique de l’invention peut également trouver application pour des contenus de type VOD (pour « Video On Demand », ou vidéo à la demande), ou des contenus en « replay » (en français, télévision de rattrapage), en se fondant sur le caractère prédictif de l’évolution de la charge réseau. En effet, pour de tels contenus, le fichier manifest 7 est téléchargé une fois pour toutes, lorsque le client commence à visionner le contenu. Cependant, en fonction de l’heure de téléchargement de ce fichier manifest 7, de la durée du contenu, et d’une prédiction de l’évolution de la charge du réseau sur cette durée, il est possible d’affecter une valeur au critère de charge ChNet, et ainsi de déterminer les débits apparents d’encodage optimums à exposer dans le manifest, selon le principe deFig 2. Dans ce cas, la valeur de ChNet ne résulte pas uniquement d’une mesure de la charge du réseau, mais d’une connaissance fine des pics de charge récurrents quotidiens, hebdomadaires ou saisonniers. En effet, les volumes de téléchargement HAS fluctuent fortement au cours d’une journée, avec de forts pics de consommation en soirée. Ainsi, pour un même contenu, et une même charge de réseau mesurée au début de son téléchargement, des débits d’encodage apparents différents vont pouvoir être exposés dans le fichier manifest, selon l’heure à laquelle ce contenu est demandé par l’utilisateur.
On présente désormais, en relation avecFig 4, la structure matérielle d’une plateforme 40 de préparation d’un contenu numérique accessible en téléchargement progressif adaptatif (HAS), connectée au réseau de distribution 1 d’un opérateur.
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 plateforme 40 communique avec le réseau Internet étendu 1 via un module E/S pour une communication avec d’autres serveurs et équipements du réseau, par exemple le serveur de contenus 2, auquel elle fournit le fichier manifest 7. La plateforme 40 comprend en outre un module MONIT_ChNet de mesure de la charge du réseau 1, apte à affecter une valeur au critère de charge ChNet. Cette valeur peut être enregistrée par exemple dans les mémoires M de la plateforme 40.
La plateforme 40 comprend également un module ENCOD(Ci) d’encodage des segments vidéo d’un contenu Ci, selon une technique d’encodage à débit variable VBR.
Elle comprend également un module PREP_MANIFEST de préparation du fichier manifest 7, pour le contenu Ci, qui expose dans ce fichier les débits d’encodage apparents calculés par le calculateur CPU, en fonction du critère de charge ChNet délivré par le module MONIT_ChNet et des valeurs de débit maximum d’encodage MBR et de débit moyen d’encodage ABR fournis par le module d’encodage ENCOD(Ci).
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.).
Plus généralement, une telle plateforme 40 comprend une mémoire vive (par exemple une mémoire RAM), une unité de traitement équipée par exemple d'un processeur CPU, et pilotée par un programme d'ordinateur, stocké dans une mémoire morte (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive avant d'être exécutées par le processeur CPU de l'unité de traitement. La mémoire vive contient notamment la valeur du critère de charge ChNet. Le processeur de l’unité de traitement pilote la détermination des débits d’encodage apparent à exposer dans le fichier manifest 7, selon l’algorithme deFig 2.
Fig 4illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser une plateforme de préparation de contenu afin qu’elle effectue les étapes du procédé détaillé ci-avant, en relation avecFig 2(dans l’un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
ANNEXE 1 : exemple de fichier manifest

Claims (10)

  1. Procédé de préparation d’un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau (1) de distribution dudit contenu,
    ledit contenu numérique étant associé à un fichier (7) de description dudit contenu numérique, comprenant une liste de segments temporels (C1i@Nj) dudit contenu associés chacun à plusieurs débits d’encodage apparents dudit contenu,
    lesdits segments temporels dudit contenu numérique étant encodés (20) selon une méthode d’encodage à débit variable (VBR) associé à un débit d’encodage moyen (ABR) et à un débit d’encodage maximum (MBR),
    caractérisé en ce qu’il comprend une détermination (21) desdits débits d’encodage apparents (Nj) exposés dans ledit fichier (7) de description en association avec lesdits segments temporels dudit contenu, en fonction d’au moins un critère de charge (ChNet) dudit réseau de distribution,
    un débit d’encodage apparent (Nj) pouvant prendre une valeur comprise entre ledit débit d’encodage moyen (ABRj) et ledit débit d’encodage maximum (MBRj).
  2. Procédé de préparation d’un contenu numérique selon la revendication 1,caractérisé en ce queledit débit d’encodage apparent (Nj) prend une valeur égale à (MBR-ABR)/100*ChNet+ABR,
    où MBR désigne ledit débit d’encodage maximum, ABR désigne ledit débit d’encodage moyen et ChNet désigne une valeur, comprise entre 0 et 100, affectée audit au moins un critère de charge.
  3. Procédé de préparation d’un contenu numérique selon la revendication 2,caractérisé en ce qu’il comprend une mesure d’une charge dudit réseau (1) de distributionet en ce queladite valeur affectée audit au moins un critère de charge (ChNet) dudit réseau (1) est fonction de ladite mesure.
  4. Procédé de préparation d’un contenu numérique selon l'une quelconque des revendications 1 à 3,caractérisé en ce queledit au moins un critère de charge (ChNet) dudit réseau (1) tient également compte d’au moins un paramètre appartenant au groupe comprenant :
    une prédiction de charge dudit réseau ;
    une consommation électrique dudit réseau ;
    une période de l’année ;
    une programmation de mise à jour d’équipements dudit réseau.
  5. Procédé de préparation d’un contenu numérique selon l'une quelconque des revendications 1 à 4,caractérisé en ce queledit contenu numérique (Ci) est diffusé sur ledit réseau (1) en temps réel.
  6. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé 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 comprenant des instructions de code de programme pour l’exécution des étapes du procédé selon l'une quelconque des revendications 1 à 5.
  8. Plate-forme (40) de préparation d’un contenu numérique accessible en téléchargement progressif adaptatif (HAS) par un terminal lecteur de flux multimédia connecté à un réseau (1) de distribution dudit contenu,
    ledit contenu numérique étant associé à un fichier (7) de description dudit contenu numérique, comprenant une liste de segments temporels (C1i@Nj) dudit contenu associés chacun à plusieurs débits d’encodage apparents dudit contenu,
    lesdits segments temporels dudit contenu numérique étant encodés selon une méthode d’encodage à débit variable (VBR) associé à un débit d’encodage moyen (ABR) et à un débit d’encodage maximum (MBR),
    caractérisée en ce qu’elle comprend un calculateur (CPU) apte à déterminer lesdits débits d’encodage apparents (Nj) exposés dans ledit fichier (7) de description en association avec lesdits segments temporels dudit contenu, en fonction d’au moins un critère de charge (ChNet) dudit réseau (1) de distribution,
    un débit d’encodage apparent (Nj) pouvant prendre une valeur comprise entre ledit débit d’encodage moyen (ABRj) et ledit débit d’encodage maximum (MBRj).
  9. Plate-forme (40) de préparation d’un contenu numérique selon la revendication 8,caractérisée en ce queledit débit d’encodage apparent (Nj) déterminé par ledit calculateur (CPU) prend une valeur égale à (MBR-ABR)/100*ChNet+ABR,
    où MBR désigne ledit débit d’encodage maximum, ABR désigne ledit débit d’encodage moyen et ChNet désigne une valeur, comprise entre 0 et 100, affectée audit au moins un critère de charge.
  10. Plate-forme (40) de préparation d’un contenu numérique selon la revendication 8,caractérisée en ce qu’elle comprend un module (MONIT_ChNet) de mesure d’une charge dudit réseau (1) de distributionet en ce queledit calculateur (CPU) affecte audit au moins un critère de charge (ChNet) dudit réseau une valeur qui est fonction de ladite charge mesurée.
FR2003825A 2020-04-16 2020-04-16 Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau Active FR3109489B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2003825A FR3109489B1 (fr) 2020-04-16 2020-04-16 Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau
PCT/FR2021/050638 WO2021209706A1 (fr) 2020-04-16 2021-04-12 Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2003825 2020-04-16
FR2003825A FR3109489B1 (fr) 2020-04-16 2020-04-16 Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau

Publications (2)

Publication Number Publication Date
FR3109489A1 true FR3109489A1 (fr) 2021-10-22
FR3109489B1 FR3109489B1 (fr) 2022-08-05

Family

ID=72356059

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2003825A Active FR3109489B1 (fr) 2020-04-16 2020-04-16 Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau

Country Status (2)

Country Link
FR (1) FR3109489B1 (fr)
WO (1) WO2021209706A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160182594A1 (en) * 2014-12-19 2016-06-23 Cable Television Laboratories, Inc. Adaptive streaming
US20160205162A1 (en) * 2012-07-12 2016-07-14 Futurewei Technologies, Inc. Signaling and Processing Content with Variable Bitrates for Adaptive Streaming
WO2017167958A1 (fr) * 2016-04-01 2017-10-05 Orange Procede d'optimisation du debit de contenus multimedia accessibles par au moins un terminal utilisateur, produit programme d'ordinateur et dispositif de gestion correspondants
FR3055762A1 (fr) * 2016-09-07 2018-03-09 Ericsson It Solutions & Services Sas Procede et dispositif d'encodage d'un contenu audiovisuel destine a etre diffuse par telechargements successifs de morceaux de donnees

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160205162A1 (en) * 2012-07-12 2016-07-14 Futurewei Technologies, Inc. Signaling and Processing Content with Variable Bitrates for Adaptive Streaming
US20160182594A1 (en) * 2014-12-19 2016-06-23 Cable Television Laboratories, Inc. Adaptive streaming
WO2017167958A1 (fr) * 2016-04-01 2017-10-05 Orange Procede d'optimisation du debit de contenus multimedia accessibles par au moins un terminal utilisateur, produit programme d'ordinateur et dispositif de gestion correspondants
FR3055762A1 (fr) * 2016-09-07 2018-03-09 Ericsson It Solutions & Services Sas Procede et dispositif d'encodage d'un contenu audiovisuel destine a etre diffuse par telechargements successifs de morceaux de donnees

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Technologies under Consideration for DASH", no. n18815, 3 February 2020 (2020-02-03), XP030225532, Retrieved from the Internet <URL:http://phenix.int-evry.fr/mpeg/doc_end_user/documents/128_Geneva/wg11/w18815-v2-w18815.zip SC29WG11_N18815_DASH_TuC.docx> [retrieved on 20200203] *

Also Published As

Publication number Publication date
WO2021209706A1 (fr) 2021-10-21
FR3109489B1 (fr) 2022-08-05

Similar Documents

Publication Publication Date Title
FR2902266A1 (fr) Procede et dispositif de repartition de la bande passante de communication
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
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
EP4055831A1 (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
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
FR3109489A1 (fr) Préparation de contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d’encodage à débit variable, en fonction d’une charge réseau
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
EP2819424A1 (fr) Procédé d&#39;amelioration du temps de changement entre programmes audiovisuels
WO2023208688A1 (fr) Gestion de la restitution d&#39;un contenu multimédia
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.
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
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
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
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
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
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.
EP3840391A1 (fr) Gestion de la restitution d&#39;un contenu multimédia et d&#39;une interface de navigation sur un écran
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
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.
FR3116684A1 (fr) Gestion du téléchargement progressif adaptatif d’un contenu acheté, tenant compte d’un historique de niveaux de qualité de lecture de contenu par un terminal lecteur de flux multimédia
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.
EP3973714A1 (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
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique en mode économiseur d&#39;écran
EP4184922A1 (fr) Procédé de gestion de l&#39; accès à un contenu multimédia

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20211022

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5