FR3080247A1 - Lecture d'un flux multimedia - Google Patents

Lecture d'un flux multimedia Download PDF

Info

Publication number
FR3080247A1
FR3080247A1 FR1853365A FR1853365A FR3080247A1 FR 3080247 A1 FR3080247 A1 FR 3080247A1 FR 1853365 A FR1853365 A FR 1853365A FR 1853365 A FR1853365 A FR 1853365A FR 3080247 A1 FR3080247 A1 FR 3080247A1
Authority
FR
France
Prior art keywords
multimedia stream
multimedia
configuration data
stream
reading device
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
FR1853365A
Other languages
English (en)
Other versions
FR3080247B1 (fr
Inventor
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
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 FR1853365A priority Critical patent/FR3080247B1/fr
Publication of FR3080247A1 publication Critical patent/FR3080247A1/fr
Application granted granted Critical
Publication of FR3080247B1 publication Critical patent/FR3080247B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/435Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing 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/23439Processing 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383Accessing a communication channel
    • H04N21/4384Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637Control signals issued by the client directed to the server or network components
    • H04N21/6373Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84Generation or processing of descriptive data, e.g. content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/433Content storage operation, e.g. storage operation in response to a pause request, caching operations
    • H04N21/4331Caching operations, e.g. of an advertisement for later insertion during playback

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Television Signal Processing For Recording (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)

Abstract

L'invention un procédé de traitement comprenant : réception de métadonnées (DT1) caractérisant des flux multimédias (FL) accessibles par un dispositif de lecture (2) ; extraction, à partir des métadonnées, de données de configuration (DT2) associées aux flux multimédia (FL), ces données de configuration comprenant des données de manifeste (DM) caractérisant des paquets de données associés aux flux multimédias ; enregistrement des données de configuration (DT2) ; dans lequel, après l'étape d'enregistrement, le procédé comprend : détection d'un flux multimédia (FL), dit premier flux multimédia, que le dispositif de lecture doit lire ; récupération des données de configuration (DT22) enregistrées pour ce premier flux multimédia ; et configuration du dispositif de lecture selon les données de configuration (DT22) du premier flux multimédia de sorte à permettre la lecture dudit premier flux multimédia.

Description

Arrière-plan de l'invention
L’invention se rapporte au domaine du traitement de données multimédias et concerne plus particulièrement le traitement de flux multimédias par un dispositif de lecture.
Il existe aujourd'hui diverses manières d'accéder à des contenus multimédias sur un dispositif de lecture tel qu'une télévision ou un smartphone par exemple. Une technique courante, dite de « streaming », consiste à transmettre des contenus multimédias en continu vers un dispositif de lecture, de sorte que la lecture du contenu puisse être réalisée parallèlement à la réception progressive des différentes parties du contenu en question. La technique de streaming, ou téléchargement adaptatif, s'oppose ainsi au téléchargement classique de fichiers multimédias qui nécessite de récupérer l'ensemble des données du fichier avant de pouvoir lire le contenu multimédia.
Plus particulièrement, la technique de téléchargement en flux adaptatif dynamique sur HTTP, appelée aussi téléchargement (streaming) HTTP adaptatif ou HAS (pour « http adaptative streaming »), est un format d'échange de contenus multimédias bien connu, utilisé notamment sur Internet. Cette technique repose sur la préparation de plusieurs représentations (ou versions) d'un contenu multimédia, ces représentations ayant des niveaux de qualité (résolution, débit...) différents et étant chacune décomposée en une succession de segments ou paquets de données (typiquement de quelques secondes). Chacun des segments est rendu disponible individuellement au moyen d'un protocole d'échange, tel que le protocole HTTP par exemple. L'organisation des segments et les paramètres associés sont publiés dans un manifeste se présentant généralement sous la forme d'un document XML.
Diverses implémentations de cette technique de téléchargement dynamique adaptatif (HAS) sont possibles, parmi lesquelles les protocoles DASH, SmoothStreaming ou HLS, par exemple. De façon générale, un protocole de téléchargement dynamique adaptatif (ou protocole HAS) repose sur le principe que le client HAS effectue une estimation de la bande passante (ou du débit) disponible pour la réception des segments d'un contenu multimédia, et en fonction de cette estimation, il choisit pour le prochain segment à charger la représentation la plus adaptée, c'est-à-dire celle dont la qualité (résolution...) permet un délai de réception compatible avec la lecture en continue (sans interruption du contenu) tout en assurant la meilleure qualité possible de ce contenu.
La norme ISO/IEC 23009-1 (Dash), par exemple, définit le format du manifeste ainsi que celui des segments basés sur des formats de conteneur MPEG : ISO Base Media File Format (ISO/IEC 14496-12) et MPEG-2 Transport Stream (ISO/IEC 13818-1), et donne des indications pour la définition d'autres formats de segment.
De façon connue, des lecteurs HAS sont aujourd'hui largement utilisés dans les décodeurs TV, ordinateurs et téléphones intelligents (smartphones), par exemple, pour lire des contenus multimédias, tels que des flux de chaînes TV par exemple.
Ces lecteurs HAS sont généralement équipés d'une interface utilisateur permettant à un utilisateur de sélectionner le flux multimédia auquel il désire accéder. Le passage d'un flux multimédia à un autre lorsque l'utilisateur change de chaîne ou de contenu présente cependant un inconvénient en ce qu'un temps (ou délai) de latence plus ou moins important est requis pour permettre au lecteur HAS de récupérer le nouveau flux sélectionné, cette latence pouvant causer une discontinuité dans la lecture ou la reproduction des flux, se traduisant par exemple par un écran noir ou figé lorsqu'il s'agit d'afficher un contenu multimédia sur un écran.
Un tel temps de latence peut également survenir lors du démarrage d'un décodeur TV par exemple, lorsque celui-ci tente de lire la dernière chaîne sélectionnée avant la mise en veille du décodeur TV.
Ces délais dans la lecture d'un flux peuvent se traduire par des ralentissements perceptibles pour l'utilisateur, engendrant ainsi une dégradation de l'expérience de l'utilisateur. Ces temps de latence peuvent en particulier être perceptibles par les utilisateurs, et donc dégrader sensiblement la qualité de lecture, dans le cas où les terminaux de lecture sont de type liaison point à point (« unicast »).
Un besoin existe aujourd'hui pour améliorer la gestion par un dispositif de lecture, de type HAS par exemple, du téléchargement de flux multimédias, notamment lorsqu'un changement de flux survient ou lors du démarrage du lecteur.
Objet et résumé de l'invention
A cet effet, la présente invention concerne un procédé de traitement mis en œuvre par un dispositif de lecture de flux multimédias, comprenant les étapes suivantes :
- réception de métadonnées caractérisant une pluralité de flux multimédias accessibles par le dispositif de lecture, lesdites métadonnées comprenant une adresse associée à chaque flux multimédia ;
- extraction, à partir desdites adresses, de données de configuration associées à au moins un flux multimédia sélectionné parmi ladite pluralité de flux multimédias, lesdites données de configuration comprenant des données de manifeste caractérisant des paquets de données associés audit au moins un flux multimédia sélectionné ;
- enregistrement des données de configuration dudit au moins un flux multimédia sélectionné ;
dans lequel, après l'étape d'enregistrement, le procédé comprend les étapes suivantes :
- détection d'un flux multimédia, dit premier flux multimédia, que le dispositif de lecture doit lire ;
- récupération des données de configuration enregistrées en association avec le premier flux multimédia ; et
- configuration du dispositif de lecture selon les données de configuration du premier flux multimédia de sorte à permettre la lecture dudit premier flux multimédia.
L'invention permet avantageusement de réduire significativement le temps de latence nécessaire au dispositif de lecture pour lire un flux multimédia donné, en particulier lors d'un changement de flux (zapping) ou lors de la lecture d'un flux initial au démarrage du dispositif de lecture. Ceci est possible car le dispositif de lecture acquiert et enregistre à l'avance les données de configuration (notamment le manifeste) associées aux différents flux multimédias dont la lecture est susceptible d'être requise ultérieurement. Ainsi, lorsqu'il détecte par la suite qu'un premier flux multimédia doit être lu (sur détection par exemple d'une commande d'un utilisateur), le dispositif de lecture peut avantageusement chercher et récupérer dans sa mémoire les données de configuration correspondantes et ainsi se configurer pour lire le premier flux multimédia.
Dans un mode de réalisation particulier, le dispositif de lecture comprend une mémoire et, lors de l'étape d'enregistrement, les données de configuration sont enregistrées dans cette mémoire.
Selon un mode de réalisation particulier, le procédé comprend une étape de téléchargement du premier flux multimédia conformément aux données de configuration dudit premier flux multimédia.
Grâce à l'invention, lorsqu'un nouveau flux doit être lu, le dispositif de lecture peut rapidement se configurer à partir des données de configuration correspondantes, stockées par exemple dans sa mémoire, et ainsi, accéder au nouveau flux en question avec un minimum de délai de traitement.
Selon un mode de réalisation particulier, lesdites données de manifeste caractérisent, selon un protocole de téléchargement HTTP adaptatif (HAS), des paquets de données contenus dans ledit (ou associés audit) au moins un flux multimédia sélectionné.
Le dispositif de lecture peut ainsi sélectionner, selon le protocole HAS appliqué, la représentation du flux qu'il souhaite acquérir, en fonction de la bande passante (ou débit) disponible pour l'acquisition des paquets de données.
Selon un mode de réalisation particulier, les données de configuration comprennent en outre une clé de sécurité respective allouée au dispositif de lecture pour chaque flux multimédia sélectionné.
L'utilisation d'une clé de sécurité, ou licence, permet de sécuriser l'accès à des contenus multimédias depuis un serveur distant d'un fournisseur de contenu.
Selon un mode de réalisation particulier, lors de l'étape d'extraction, le dispositif de lecture requière, auprès d'un premier serveur, les données de manifeste associées audit au moins un flux multimédia sélectionné et requière, auprès d'un deuxième serveur, la ou les clés de sécurité associées audit au moins un flux multimédia.
Le dispositif de lecture peut ainsi spécifier les paquets de données qu'il souhaite acquérir et obtenir l'accès à ce contenu à l'aide de la clé de sécurité qui lui a été allouée à cette fin. Les premier et deuxième serveurs peuvent être différents ou constituer un seul et même serveur.
Selon un mode de réalisation particulier, le procédé comprend, avant l'étape d'extraction, une étape de détermination dudit au moins un flux multimédia sélectionné, en fonction d'un flux multimédia (flux initial) en cours de lecture par le dispositif de lecture ou selon une sélection de flux multimédias prédéterminée.
De cette manière, le dispositif de lecture peut sélectionner la ou les flux auxquels un utilisateur est le plus susceptible de vouloir accéder. Cette sélection est déterminée à partir d'un flux en cours de lecture par le dispositif de lecture. Le dispositif de lecture peut, par exemple, déterminer que doivent être extraites les données de configuration du flux qui précède immédiatement et/ou du flux qui succède immédiatement le flux en cours de lecture, selon un ordre ordonné de flux accessibles par le dispositif de lecture.
Selon un mode de réalisation particulier, lors de l'étape de détection, le dispositif de lecture détecte une commutation depuis un flux multimédia initial vers ledit premier flux multimédia, la détection du premier flux multimédia à lire résultant de ladite commutation.
Lorsqu'un changement de flux (de chaîne par exemple) est opéré par un utilisateur, le dispositif de lecture peut ainsi détecter que les données de configuration du nouveau flux demandé doivent être chargées pour configurer le dispositif de lecture et ainsi permettre la lecture dudit flux demandé.
Selon un mode de réalisation particulier, lors de l'étape de détection, le premier flux multimédia à lire est détecté en réponse à une commande d'un utilisateur pour lire le premier flux multimédia.
Dans un mode particulier de réalisation, les différentes étapes du procédé de traitement sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations (ou support d'enregistrement), ce programme étant susceptible d'être mis en œuvre dans un dispositif de lecture ou plus généralement dans un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de traitement tel que défini ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations (ou support d'enregistrement) lisible par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations 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 disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations 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. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations 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é en question.
L'invention vise également un dispositif de lecture correspondant, à savoir, un dispositif de lecture de flux multimédias, comprenant :
- un module de réception configuré pour obtenir des métadonnées caractérisant une pluralité de flux multimédias accessibles par le dispositif de lecture, lesdites métadonnées comprenant une adresse associée à chaque flux multimédia ;
- un module d'extraction configuré pour extraire, à partir desdites adresses, de données de configuration associées à au moins un flux multimédia sélectionné parmi ladite liste de flux multimédias, lesdites données de configuration comprenant des données de manifeste caractérisant des paquets de données associés audit moins un flux multimédia sélectionné ;
- un module d'enregistrement configuré pour enregistrer les données de configuration dudit au moins un flux multimédia sélectionné ;
- un module de détection configuré, après enregistrement des données de configuration par le module d'enregistrement, pour détecter un flux multimédia, dit premier flux multimédia, que le dispositif de lecture doit lire ;
- un module de configuration configuré pour récupérer des données de configuration enregistrées en association avec le premier flux multimédia, et pour configurer le dispositif de lecture selon les données de configuration du premier flux multimédia de sorte à permettre la lecture dudit premier flux multimédia.
On notera que les différents modes de réalisation mentionnés ci-avant en relation avec le procédé de traitement de l'invention ainsi que les avantages associés s'appliquent de façon analogue au dispositif de lecture de l'invention.
Ainsi, selon un mode de réalisation particulier, le dispositif de lecture comprend un module de lecture configuré pour télécharger le premier flux multimédia conformément aux données de configuration dudit premier flux multimédia.
Selon un mode de réalisation particulier, lesdites données de manifeste caractérisent, selon un protocole de téléchargement HTTP adaptatif, des paquets contenus dans ledit au moins un flux multimédia sélectionné.
Selon un mode de réalisation particulier, les données de configuration comprennent en outre une clé de sécurité respective allouée au dispositif de lecture pour chaque flux multimédia sélectionné.
Selon un mode de réalisation, l'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu’à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. 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, selon ce qui est décrit ci-dessous pour le module concerné..
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures:
- la figure 1 représente schématiquement un environnement comportant un dispositif de lecture conforme à un mode de réalisation particulier de l'invention ;
- la figure 2 représente schématiquement différentes représentations d'un flux multimédia conformément à un protocole de lecture HAS ;
- la figure 3 représente schématiquement des modules mis en œuvre dans le dispositif de lecture de la figure 1, selon un mode de réalisation particulier de l'invention ;
- la figure 4 représente schématiquement, sous forme d'un diagramme, les étapes d'un procédé de traitement selon un mode de réalisation particulier de l'invention ;
- la figure 5 représente un plan de service représentatif de flux multimédias, selon un mode de réalisation particulier de l'invention ;
- la figure 6 représente des données de configuration de flux multimédias, selon un mode de réalisation particulier de l'invention ; et
- la figure 7 représente schématiquement, sous forme d'un diagramme, les étapes d'un procédé de traitement selon un mode de réalisation particulier de l'invention.
Description détaillée de plusieurs modes de réalisation
Comme indiqué précédemment, l'invention porte sur le traitement de flux multimédias par un dispositif de lecture, et porte notamment sur le téléchargement en continu (streaming) d'un flux multimédia par un dispositif de lecture, de type HAS (pour « http adaptative streaming ») par exemple.
L'invention, selon différents modes de réalisation, met ainsi en œuvre un dispositif de lecture, de type HAS par exemple, capable de recevoir des métadonnées caractérisant des flux multimédias, d'extraire des données de configuration (manifeste, clé...) associées à ces flux et d'enregistrer ces données de configuration, par exemple dans une mémoire locale. Ainsi, lorsqu'un nouveau flux multimédia doit être lu par le dispositif de lecture, en cas de changement de flux (zapping) par exemple, le dispositif de lecture peut récupérer facilement les données de configuration enregistrées en association avec le flux concerné, et ainsi se configurer rapidement avec ces données de configuration pour pouvoir lire le flux en question.
D'autres aspects et avantages de la présente invention ressortiront des exemples de réalisation décrits ci-dessous en référence aux dessins mentionnés ci-avant.
Dans ce document, des exemples de mise en œuvre de l'invention sont décrits dans le cadre d'un décodeur TV. On comprend cependant que l'invention ne s'applique pas exclusivement à ce cas particulier mais peut être mise en œuvre plus généralement dans le cadre d'un quelconque dispositif de lecture, de type HAS par exemple.
Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
La figure 1 représente schématiquement un environnement comprenant un dispositif de lecture 2, un téléviseur (ou écran) 20 et un serveur 30.
Dans cet exemple, le dispositif de lecture 2 de type HAS est configuré pour réceptionner, selon un protocole HAS, un flux multimédia FL sélectionné parmi des flux accessibles depuis le serveur 30, et pour lire ce flux FL. Ce flux peut ainsi être reproduit sur le téléviseur 20 sous contrôle du dispositif de lecture 2.
Le dispositif de lecture 2 est dans cet exemple un décodeur TV. Il peut s'agir, par exemple, d'un décodeur TV distribué par le fournisseur d'accès à Internet ORANGE™. Selon d'autres exemples de réalisation, le dispositif de lecture 2 prend la forme d'une clé (dongle), telle que la clé TV distribuée par ORANGE, permettant la transmission et la reproduction de flux multimédias sur un téléviseur.
Selon des exemples particuliers, le dispositif de lecture 2 peut être un ordinateur, un téléphone intelligent (smartphone), une tablette etc. Dans ces variantes, un téléviseur 20 externe n'est pas nécessaire pour reproduire les contenus multimédias. Selon un exemple particulier, les moyens de reproduction (audio et/ou vidéo) 20 du flux multimédia FL sont intégrés dans le dispositif de lecture 2.
Le dispositif 2 est configuré pour coopérer avec le serveur distant 30 pour recevoir et lire un flux multimédia FL parmi ceux disponibles auprès du serveur distant 30. La lecture cause ainsi la reproduction du flux multimédia FL par le téléviseur 20.
Dans cet exemple, le serveur 30 transmet vers le dispositif de lecture 2 des flux multimédias FL via une connexion point à point (client-serveur). Autrement dit, il s'agit ici d'un téléchargement de type « unicast », bien que d'autres exemples soient possibles.
Comme représenté en figure 1, le dispositif de lecture (ou dispositif de réception) 2 comprend dans cet exemple un contrôleur (ou processeur) 4, une mémoire volatile (RAM) 6, une mémoire non volatile réinscriptible 8 (de type Flash par exemple), un module de lecture HAS 10, une interface de communication 12 et une interface utilisateur 14.
Dans cet exemple, la mémoire 8 constitue un support d'enregistrement (ou support d'informations) conforme à un mode de réalisation particulier, lisible par le dispositif de lecture 2, et sur lequel est enregistré un programme d'ordinateur PG1 conforme à un mode de réalisation particulier. Ce programme d'ordinateur PG1 comporte des instructions pour l'exécution des étapes d'un procédé de traitement selon un mode de réalisation particulier. Les étapes de ce procédé sont décrites ultérieurement.
La mémoire 8 est également configurée pour stocker des données DTI et DT2 associés aux flux multimédias FL transmis par le serveur 30. Comme expliqué plus en détail par la suite, les données DTI sont dans cet exemple des métadonnées caractérisant les flux multimédias FL accessibles par le dispositif de lecture 2 depuis le serveur 30. Ces métadonnées identifient les différents flux FL et comprennent en particulier, pour chaque flux multimédia FL fourni par le serveur 30, une adresse URL notée AD (ou « url.json »). Cette adresse AD permet en particulier au dispositif de lecture 2 de récupérer si besoin des données de configuration DT2 associées au flux multimédia FL en question.
Les données de configuration DT2 sont destinées à configurer le dispositif de lecture 2, et plus particulièrement le module de lecture 10, pour permettre la lecture du flux multimédia FL associé. Dans un exemple particulier, les données de configuration DT2 caractérisent selon un protocole de téléchargement HTTP adaptatif (protocole HAS, par exemple DASH, SmoothStreaming ou HLS) des paquets de données ou segments associés à (ou contenus dans) un flux multimédia FL correspondant.
Les données de configuration DT2 comprennent en particulier des données de manifeste DM caractérisant des paquets de données (ou segments) associés au (ou contenus dans le) flux multimédia FL associé. Autrement dit, ces données de manifeste DM définissent un manifeste représentatif de la structure du flux multimédia FL associé. Comme décrit par la suite, les données de configuration DT2 peuvent également comprendre une licence, prenant la forme d'une clé de sécurité K associée au flux multimédia FL correspondant. Une telle clé K permet de protéger la lecture d'un flux multimédia FL donné.
Les données DTI et DT2 peuvent être récupérées par le dispositif de lecture 2 auprès du serveur distant 30, comme expliqué ultérieurement.
Comme déjà indiqué, le dispositif de lecture 2 comprend également un module de lecture HAS 10 configuré pour recevoir et lire un flux multimédia FL transmis par le serveur 30. Ce module de lecture 10 est configuré pour lire les données d'un flux FL sélectionné, selon un protocole HAS. Le protocole HAS en question peut être quelconque, par exemple de type DASH, SmoothStreaming ou HLS. Dans un exemple particulier, ce module de lecture 30 est mis en œuvre par le processeur 4 iui-même.
Le serveur 30 est configuré pour transmettre les flux multimédias FL selon un protocole HAS. Le server 30 est par exemple un serveur CDN (pour « Content de/ivery network»). La communication entre le serveur 30 et le dispositif de lecture 2 peut se faire via un réseau de télécommunication, tel qu'internet par exemple.
La figure 2 représente schématiquement un flux multimédia FL accessible par le dispositif de lecture 2 auprès du serveur 30. Ce flux FL est disponible dans cet exemple selon 3 représentations (ou versions) différentes, notées ici Fia, FLb et FLc, ces représentations ayant chacune un degré de résolution (ou qualité) différent. Chaque représentation Fia, FLb et FLc comporte des paquets de données (ou segments) notés respectivement CKa, CKb et CKc.
Conformément au protocole HAS mis en œuvre, le module de lecture 2 sélectionne et reçoit la représentation FLa-FLc la plus appropriée du flux FL en fonction de la bande passante (ou débit) disponible, de sorte à acquérir le ou les paquets de données souhaités et permettre une lecture continue du flux FL choisi sur le téléviseur 20.
Par ailleurs, l'interface de communication 12 permet au dispositif de lecture 2 de communiquer avec le serveur 30 afin de recevoir les données DTI et DT2, ainsi que les flux multimédias FL transmis par le serveur 30.
L'interface utilisateur 14 permet à un utilisateur d'interagir avec le dispositif de lecture 2 afin, notamment, de commander la lecture d'un flux multimédia FL souhaité. On suppose par la suite que chaque flux FL correspond à une chaîne TV que l'utilisateur peut visualiser en temps réel sur son écran 20 à l'aide de son décodeur TV 2. En variante, les flux FL peuvent être, par exemple, des flux de contenus multimédias téléchargés à la demande (VOD) ou tous autres de types de flux multimédias.
Le processeur 2 piloté par le programme d'ordinateur PG1, met ici en œuvre un certain nombre de modules représentés en figure 3, à savoir : un module de réception MD2, un module d'extraction MD4, un module d'enregistrement MD6, un module de détection MD8, un module de configuration MD10 et un module de téléchargement MD12.
Le module de réception MD2 est configuré pour obtenir des métadonnées DTI caractérisant les flux multimédias FL accessibles par le dispositif de lecture 2, ces métadonnées comprenant, pour chaque flux multimédia FL, une adresse URL (url.json) associée, notée AD.
Selon un exemple particulier, le module de réception MD2 est configuré pour recevoir, en provenance du serveur 30, une liste (list.json) des flux FL accessibles auprès du serveur 30 ainsi que les métadonnées DTI associées à chacun de ces flux FL.
Le module d'extraction MD4 est configuré pour extraire (ou récupérer), à partir des adresses AD, des données de configuration DT2 associées à un ou des flux multimédias sélectionnés parmi cette pluralité de flux multimédias. Pour ce faire, le module d'extraction MD4 lit (charge) le contenu de l'adresse AD spécifiée dans les métadonnées DTI du ou des flux FL désirés. Le ou les flux multimédias sélectionnés peuvent correspondre à tous les flux FL accessibles auprès du serveur 20 ou à une sélection d'un ou de plusieurs flux parmi ceux-ci.
Comme déjà indiqué, les données de configuration DT2 peuvent comprendre, pour chaque flux multimédia FL sélectionné, un manifeste, autrement dit des données de manifeste caractérisant des paquets de données associés audit (ou contenus dans ledit) flux multimédia sélectionné. Les données de configuration DT2 peuvent en outre comprendre une clé de sécurité respective allouée au dispositif de lecture 2 pour chaque flux multimédia FL sélectionné.
Le module d'enregistrement MD6 est configuré pour enregistrer les données de configuration DT2 extraites par le module d'extraction M4, c'est-à-dire les données de configuration DT2 du ou des flux multimédia FL sélectionné. Dans cet exemple de réalisation, les données de configuration sont enregistrées dans la mémoire locale 8 du dispositif de lecture 2 (figure 1).
Le module de détection MD8 est configuré, après enregistrement des données de configuration DT2 par le module d'enregistrement MD6, pour détecter un flux multimédia FL, dit premier flux multimédia (ou flux multimédia cible), que le dispositif de lecture doit lire. Comme indiqué par la suite, une telle détection peut survenir par exemple lorsqu'un utilisateur change de flux FL, c'est-à-dire lorsque le module de détection MD7 détecte une commande de changement de chaîne (zapping). Une telle détection peut également survenir lors du démarrage du dispositif de lecture 2, causant la détection par le module de détection MD8 qu'une chaîne FL précédemment sélectionnée doit être lue (la dernière chaîne lue avant la désactivation ou mise en veille du dispositif de lecture 2).
Le module de configuration MD10 est configuré pour récupérer des données de configuration DT2 enregistrées par le module d'enregistrement MD6 en association avec le premier flux multimédia FL, et pour configurer le dispositif de lecture 2 (et plus particulièrement le module de lecture 10) selon les données de configuration DT2 du premier flux multimédia FL de sorte à permettre la lecture dudit premier flux multimédia FL.
Le module de téléchargement MD12 est configuré pour télécharger (récupérer) le premier flux multimédia FL depuis le serveur 30, conformément aux données de configuration DT2 dudit premier flux multimédia.
La configuration et le fonctionnement des modules MD2-MD12 du dispositif de lecture 2 apparaîtront plus précisément dans les exemples de réalisation décrits ci-après. On comprend que les modules MD2-MD12 tels que représentés en figure 3 ne représentent qu'un exemple de mise en œuvre non limitatif de l'invention.
A noter que certains éléments généralement présents dans un dispositif de lecture HAS, et plus généralement dans un environnement dient/serveur HAS, ont été volontairement omis car ils ne sont pas nécessaires à la compréhension de la présente invention.
Un mode de réalisation particulier est à présent décrit en référence à la figure 4. Plus précisément, le dispositif de lecture 2 décrit précédemment (figures 1-3) met en oeuvre un procédé de traitement en exécutant le programme d'ordinateur PG1.
On suppose ici que le dispositif de lecture 2 a été préalablement démarré et que le serveur 30 transmet au choix 4 flux multimédias FL, notés respectivement FL1, FL2, FL3 et FL4. Chacun de ces flux FL correspond dans cet exemple à une chaîne TV que l'utilisateur peut sélectionnée à l'aide de l'interface utilisateur 14, de façon à visualiser le contenu correspondant sur l'écran 20. Ces flux peuvent comprendre de quelconques contenus multimédias, tels que des programmes TV, films, des images ou contenus audio par exemple.
Au cours d'une étape de réception S2, le dispositif de lecture 2 reçoit, depuis le serveur 30, des métadonnées DTI caractérisant les flux multimédias FL1-FL4 accessibles par le dispositif de lecture 2 (comme déjà décrit précédemment). Ces métadonnées DTI, représentées en figure 5, identifient les flux FL1, FL2, FL3 et FL4 et comprennent des métadonnées DT11, DT12, DT13 et DT14 caractérisant respectivement les flux FL1, FL2, FL3 et FL4.
Selon un exemple particulier, le dispositif de lecture 2 reçoit, au cours de l'étape S2, une liste (list.json) des flux FL1-FL4 disponibles ainsi que les métadonnées DT11-D14 associées.
Dans cet exemple, les métadonnées DT11, DT12, DT13 et DT14 comportent chacune une adresse URL AD (url.json), notée respectivement ADI, AD2, AD3 et AD4. Comme indiqué ci-après, ces adresses AD permettent au dispositif de lecture 2 de récupérer des données de configuration DT2 propres à chaque flux FL1-FL2. Les métadonnées DTI peuvent également comprendre divers informations ou spécifications caractérisant les flux FL1-FL4 associés, tels que par exemple au moins l'un parmi :
- un identifiant du flux (nom de chaîne, etc.) ;
- une adresse URL d'une jaquette ou autre correspondant au contenu multimédia ; et
- informations sur un contenu en cours de transmission dans le flux (artiste, programme, durée etc.).
Au cours d'une étape d'extraction S4, le dispositif de lecture 2 extrait (récupère) à partir des adresses AD, des données de configuration DT2 associées à au moins un flux multimédia FL sélectionné parmi les flux FL1-FL4 disponibles. Pour ce faire, le dispositif de lecture lit (charge) le contenu de l'adresse URL AD de chaque flux FL sélectionné.
Autrement dit, le dispositif de lecture envoie au serveur 30 une requête pour lire le contenu de l'adresse AD de chaque flux FL sélectionné.
On suppose ici que le dispositif de lecture 2 récupère en S4 les données de configuration DT2, notées respectivement DT21-DT24, des flux multimédias FL1-FL4. Comme décrit ultérieurement, d'autres exemples sont possibles dans lesquels un sousgroupe parmi les flux FL1-FL4 est sélectionné en S4. Le dispositif de lecture 2 sélectionne par exemple en S2 une sélection prédéterminée parmi les flux FL1-FL4 accessibles.
Comme représenté en figure 6, les données de configuration DT21-DT24 obtenues en S4 comprennent respectivement des données de manifeste DM1-DM4 caractérisant des paquets de données (ou segments) associés à (ou contenus dans) chaque flux multimédia FL1-FL4. Comme déjà décrit, ces données de manifeste DM1-DM4 comportent des adresses URL (ou identifiants) identifiant les différentes représentations FLa, FLb et FLc de chaque flux FL1-FL4, et plus particulièrement, pour identifier les paquets CKa, CKb et CKc de chacune de ces représentations (figure 2). Ces données de manifeste comportent par exemple une adresse URL principale correspondant à chaque représentation FLa-FLc d'un flux, ainsi que des adresses URL secondaires correspondant aux différents paquets constituant ces représentations.
Dans l'exemple considéré ici, les données de configuration DT21-DT24 caractérisent selon un protocole de téléchargement HTTP adaptatif (protocole HAS, par exemple DASH, SmoothStreaming ou HLS) des paquets de données ou segments contenus dans les flux multimédias respectifs FL1-FL4.
Selon un exemple particulier, les données de configuration DT21-DT24 comprennent en outre chacune une clé de sécurité (ou licence) associée qui est allouée au dispositif de lecture 2 afin de pouvoir accéder au contenu multimédia en question. Le dispositif de lecture 2 peut utiliser cette clé auprès du serveur 30 afin d'obtenir l'accès au flux multimédias FL correspondant. L'usage d'une telle clé permet de protéger l'accès aux contenus multimédias.
Au cours d'une étape d'enregistrement S6, le dispositif de lecture 2 enregistre dans sa mémoire locale 8 les données de configuration DT2 associées aux flux multimédias FL1-FL4 sélectionnés en S2.
Dans cet exemple, on suppose à ce stade que le dispositif de lecture 2 est en cours de lecture du flux multimédia FL2 et que, à cet effet, le dispositif de lecture 2 est configuré selon les données de configuration DT2 associées au flux FL2. Cette configuration permet au module de lecture 10 HAS de télécharger le flux FL2 en provenance du serveur 30, de décoder (et éventuellement déchiffrer) ce flux selon les données de manifeste DM2 (et éventuellement à partir de la clé K2) et enfin de causer l'affichage d'un contenu multimédia correspondant à l'écran 20.
Par la suite, le dispositif de lecture 2 détecte (S8) un flux multimédia, dit flux multimédia cible (ou premier flux multimédia), que le dispositif de lecture 2 doit lire. On suppose ici que le dispositif de lecture 2 détecte en S8 que le flux cible FL3 doit être lu en réponse à une commande de l'utilisateur. Plus précisément, le dispositif de lecture 2 détecte en S8 un changement (ou commutation) de chaîne depuis le flux initial FL2 vers le flux cible FL3. Cette commutation (ou zapping) survient par exemple sur détection d'une commande de changement de chaîne entrée par l'utilisateur à l'aide de l'interface utilisateur 14. Comme indiqué par la suite, des exemples autres qu'une commutation de flux sont toutefois possibles en S8.
Selon un exemple particulier, le dispositif de lecture 2 présente à l'utilisateur la liste « list.json » des différentes chaînes disponibles auprès du serveur 30, de sorte que l'utilisateur puisse sélectionner la chaîne cible FL3.
Au cours d'une étape de récupération S10, le dispositif de lecture 2 effectue une recherche dans sa mémoire locale 8 et récupère les données de configuration DT23 enregistrées en association avec le flux cible FL3 identifié en S8.
Le dispositif de lecture 2 configure alors son module de lecture 10 selon les données de configuration DT23 de sorte à permettre la lecture du flux cible FL3.
Au cours d'une étape de lecture S16, le module de lecture 10 télécharge ainsi le flux cible FL3 transmis par le serveur 30, selon les données de configuration DT23, et en particulier selon les données de manifeste DM3 spécifiant les paquets de données constituant la ou les représentations disponibles du flux cible FL3. Selon un exemple particulier, le module de lecture 10 transmet à cette fin au serveur 30 une requête de lecture du flux cible FL3 comportant la ou les adresses des paquets souhaités, conformément aux données de manifeste DM3. Cette requête comprend éventuellement la clé de sécurité K3 associée. En réponse à cette requête, le module de lecture 10 reçoit le ou les paquets demandés du flux cible FL3. Le module de lecture 10 décode (et éventuellement déchiffre) ensuite ces paquets de données et cause l'affichage de ceux-ci à l'écran 20. Ce décodage peut comprendre un quelconque traitement approprié, tel qu'une décompression, démultiplexage, etc. par exemple. L'utilisateur peut ainsi visualiser la chaîne FL3 sélectionnée.
Le dispositif de lecture 2 sélectionne le ou les paquets de données du flux cible FL3 qu'il souhaite acquérir en fonction de la bande passante (ou débit) disponible pour recevoir ces données depuis le serveur 30, conformément à un protocole HAS (tel qu'un protocole DASH, SmoothStreaming ou HLS, par exemple).
Selon l'exemple décrit ci-dessus, l'identification en S8 du flux FL2 à lire survient dans le cadre d'un changement de flux (zapping). Selon une variante, les étapes S2 à S6 sont réalisées pendant que le dispositif de lecture 2 est en phase de veille (veille dite « semiprofonde ») et, une fois le dispositif de lecture 2 mis en marche, celui-ci détecte au démarrage en S8 qu'un flux FL particulier doit être lu et affiché à l'écran 20. Ce flux (LF2 par exemple) correspond par exemple au dernier flux sélectionné ou lu par le dispositif de lecture 2, avant d'initier la phase de veille. Lorsqu'un utilisateur démarre le décodeur TV 2, c'est ainsi la dernière chaîne visualisée avant d'éteindre le décodeur TV qui est affichée à l'écran. Le dispositif de lecture 2 peut ainsi acquérir et stocker dans sa mémoire les données de configuration DT2 appropriées avant même le démarrage dudit dispositif de lecture 2.
L'invention permet avantageusement de réduire significativement le temps de latence nécessaire au dispositif de lecture pour lire un flux multimédia donné, en particulier lors d'un changement de flux (zapping) ou lors de la lecture d'un flux initial au démarrage du dispositif de lecture. Ceci est possible car le dispositif de lecture acquiert et enregistre au préalable les données de configuration (notamment le manifeste) associées aux flux multimédias dont la lecture est susceptible d'être requise ultérieurement. Ainsi, lorsqu'un nouveau flux doit être lu, le dispositif de lecture peut rapidement se configurer à partir des données de configuration correspondantes stockées dans sa mémoire et ainsi, accéder au nouveau flux en question avec un minimum de délai de traitement.
L'invention permet ainsi d'éviter que des temps de latence importants surviennent lors de l'affichage d'un nouveau flux multimédia, ce qui améliore par conséquent l'expérience de l'utilisateur. En particulier, l'invention permet d'éviter que des interruptions (écrans noirs ou figés) viennent dégrader l'affichage en temps réel lorsqu'un changement de chaîne est réalisé par l'utilisateur.
Dans l'exemple décrit ci-dessus, les données de configuration DT2 de tous les flux FL1-FL4 accessibles depuis le serveur 30 sont extraites (chargées) par le dispositif de lecture 2 en S4, puis enregistrées en S6 (figure 4). Selon une variante, seules les données de configuration DT2 d'une sous-sélection parmi les flux FL1-LF4 disponibles sont prises en compte en S4 et S6. Selon un exemple particulier, le dispositif de lecture 2 extrait (S4) et enregistre (S6) les données de configuration DT2 d'un ensemble prédéterminé d'au moins un flux parmi les flux FL1-LF4 disponibles (correspondant aux flux favoris de l'utilisateur, par exemple).
Selon une variante, le dispositif de lecture 2 détermine, avant l'étape d'extraction S4, au moins un flux sélectionné, en fonction d'un flux multimédia FL en cours de lecture par le dispositif de lecture. Dans un exemple particulier, le flux FL2 est en cours de lecture et le dispositif de lecture 2 détermine que les données de configuration DT2 du flux immédiatement précédent et/ou du flux immédiatement suivant - à savoir les flux FL1 et/ou FL3 - dans la liste ordonnée de flux FL1-FL4, doivent être extraites en S4 et enregistrées en S6.
Il est ainsi possible de configurer le dispositif de lecture 2 de sorte à ce qu'il enregistre les données de configuration DT2 des flux ou chaînes qui sont les plus susceptibles d'être demandés ultérieurement par l'utilisateur. Dans le cas où un grand nombre de flux FL sont accessibles depuis le serveur 30, cela permet de faciliter la configuration du dispositif de lecture 2 sans pour autant enregistrer les données de configuration DT2 de tous les flux FL disponibles. Un compromis efficace peut ainsi être atteint entre vitesse d'exécution du procédé et ressources requises.
Dans l'exemple représenté en figure 4, c'est le même serveur distant 30 qui est en charge de fournir au dispositif de lecture 2 les données DTI, les données DT2 et les flux multimédias FL, bien que d'autres implémentations soient possibles. Selon une variante, un premier serveur SV1 est configuré pour transmettre les données DTI, un deuxième serveur SV2 est configuré pour transmettre les données DT2 et un troisième serveur SV3 est configuré pour transmettre le ou les flux FL au dispositif de lecture 2. Ces 3 serveurs peuvent être distincts. Alternativement, au moins deux parmi ces 3 serveurs SV1-SV3 peuvent constituer un seul et même serveur.
Selon un exemple particulier, à l'étape S4 (figure 4), le dispositif de lecture 2 récupère tour à tour l'ensemble des données de configuration, à savoir les données de manifeste DM et clés de sécurité K, pour chaque flux multimédia FL sélectionné. Selon une variante, le dispositif de lecture 2 récupère, à l'étape S4, les données de manifeste DM de tous les flux multimédia FL sélectionnés auprès du premier serveur SV1 puis, une fois ces données DM obtenus, récupère les clés de sécurité K de tous les flux sélectionnés auprès du deuxième serveur SV2 (ou dans l'ordre inverse). Cette dernière variante permet de réduire le temps de chargement des données de manifeste DM et des clés K dans la mesure où l'on utilise la connexion TCP établie entre le dispositif de lecture 2 et le premier serveur SV1 avant de procéder à la collecte des clé K auprès du deuxième serveur SV2 (ou inversement), limitant ainsi les temps nécessaire à l'établissement des connexion TCP requises.
Un mode de réalisation particulier est à présent décrit en référence à la figure 7. Plus précisément, le dispositif de lecture 2 décrit précédemment (figures 1-3) met en œuvre un procédé de traitement en exécutant le programme d'ordinateur PG1.
Le dispositif de lecture 2 détecte (S30) une commutation depuis le flux multimédia FL2 vers le flux multimédia FL3, par exemple sur commande d'un utilisateur (zapping).
Le dispositif de lecture 2 détermine en S32 (étape de recherche) si des données de configuration DT23 associées au flux cible FL3 sont enregistrées dans la mémoire locale 8, et plus précisément dans une base de données configurée pour comprendre les données de configuration DT2 (figure 1).
Si les données de configuration DT23 sont déjà stockées dans la mémoire 8, le dispositif de lecture 2 récupère ou charge (S34) ces données de configuration DT23 et configure (S36) son module de lecture 10 à partir de ces données de configuration DT23 (de façon analogue aux étapes S10 et S12 de la figure 4). Comme déjà indiqué précédemment, les données de configuration DT23 peuvent comprendre des données de manifeste DM3 caractérisant des paquets associés au (ou contenus dans le) flux cible FL3 et, éventuellement, une clé de sécurité K3 allouée au dispositif de lecture 2 pour accéder à ce flux cible FL3 (figure 6).
Le dispositif de lecture 2 télécharge (S38) ensuite le flux cible FL3 conformément aux données de configuration DT23, et en particulier à partir des données de manifeste DM3 (de façon analogue à l'étape S14 de la figure 4).
Au cours d'une étape de lecture S40, le dispositif de lecture 2 lit ainsi les données multimédia du flux cible FL3 et cause l'affichage de celles-ci à l'écran 20 (de façon analogue à l'étape S16 de la figure 4).
En revanche, s'il est détecté en S32 que les données de configuration DT23 ne sont pas stockées dans la mémoire 8, le dispositif de lecture 2 procède à l'extraction (S42) des données de configuration DT23 du flux cible FL3 à partir de l'adresse AD3 spécifiées dans les métadonnées DTI en association avec le flux cible FL3 (figure 5), de façon analogue à l'étape S4 précédemment décrite (figure 4). Le dispositif de lecture 2 enregistre ensuite en S44 les données de configuration DT23 dans sa mémoire locale 8 en association avec le flux FL3, puis procède aux étapes S36, S38 et S40 comme déjà décrit ci-avant.
Un homme du métier comprendra que les modes de réalisation et variantes décrits ciavant ne constituent que des exemples non limitatifs de mise en œuvre de l'invention. En particulier, l'homme du métier pourra envisager une quelconque adaptation ou combinaison des modes de réalisation et variantes décrits ci-avant afin de répondre à un 5 besoin bien particulier.

Claims (15)

1. Procédé de traitement mis en œuvre par un dispositif de lecture (2) de flux multimédias, comprenant les étapes suivantes :
- réception (52) de métadonnées (DTI) caractérisant une pluralité de flux multimédias (FL) accessibles par le dispositif de lecture, lesdites métadonnées comprenant une adresse (AD) associée à chaque flux multimédia ;
- extraction (S4), à partir desdites adresses, de données de configuration (DT2) associées à au moins un flux multimédia (FL) sélectionné parmi ladite pluralité de flux multimédias, lesdites données de configuration comprenant des données de manifeste (DM) caractérisant des paquets de données associés au moins un flux multimédia sélectionné ;
- enregistrement (S6) des données de configuration (DT2) dudit au moins un flux multimédia sélectionné ;
dans lequel, après l'étape d'enregistrement (S6), le procédé comprend les étapes suivantes :
- détection (S8) d'un flux multimédia (FL2), dit premier flux multimédia, que le dispositif de lecture doit lire ;
- récupération (S10) des données de configuration (DT22) enregistrées en association avec le premier flux multimédia ; et
- configuration (S12) du dispositif de lecture selon les données de configuration (DT22) du premier flux multimédia de sorte à permettre la lecture dudit premier flux multimédia.
2. Procédé selon la revendication 1, comprenant une étape de téléchargement (S14) du premier flux multimédia conformément aux données de configuration (DT22) dudit premier flux multimédia.
3. Procédé selon la revendication 1 ou 2, dans lequel lesdites données de manifeste (DM) caractérisent, selon un protocole de téléchargement HTTP adaptatif, des paquets de données (CKa, CKb, CKc) contenus dans ledit au moins un flux multimédia (FL) sélectionné.
4. Procédé selon l'une quelconque des revendications 1 à 3, dans lequel les données de configuration comprennent en outre une clé de sécurité (K) respective allouée au dispositif de lecture pour chaque flux multimédia sélectionné.
5. Procédé selon la revendication 4 dans lequel, lors de l'étape (S4) d'extraction, le dispositif de lecture requière, auprès d'un premier serveur (30), les données de manifeste (DM) associées audit au moins un flux multimédia sélectionné et requière, auprès d'un deuxième serveur (30), la ou les clés de sécurité (K) associées audit au moins un flux multimédia.
6. Procédé selon l'une quelconque des revendications 1 à 5, dans lequel le procédé comprend, avant l'étape (S4) d'extraction, une étape de détermination dudit au moins un flux multimédia sélectionné, en fonction d'un flux multimédia en cours de lecture par le dispositif de lecture ou selon une sélection de flux multimédias prédéterminée.
7. Procédé selon l'une quelconque des revendications 1 à 6, dans lequel, lors de l'étape (S8) de détection, le dispositif de lecture détecte une commutation depuis un flux multimédia initial vers ledit premier flux multimédia, la détection du premier flux multimédia à lire résultant de ladite commutation.
8. Procédé selon l'une quelconque des revendications 1 à 7, dans lequel, lors de l'étape (S8) de détection, le premier flux multimédia à lire est détecté en réponse à une commande d'un utilisateur pour lire le premier flux multimédia.
9. Procédé selon l'une quelconque des revendications 1 à 8, dans lequel le dispositif de lecture comprend une mémoire et, lors de l'étape d'enregistrement, les données de configuration sont enregistrées dans ladite mémoire.
10. Programme d'ordinateur (PG1) comportant des instructions pour l'exécution des étapes d'un procédé de traitement selon l'une quelconque des revendications 1 à 9 lorsque ledit programme est exécuté par un ordinateur.
11. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG1) comprenant des instructions pour l'exécution des étapes d'un procédé de traitement selon l'une quelconque des revendications 1 à 9.
12. Dispositif de lecture de flux multimédias, comprenant :
- un module de réception (MD2) configuré pour obtenir des métadonnées caractérisant une pluralité de flux multimédias accessibles par le dispositif de lecture, lesdites métadonnées comprenant une adresse associée à chaque flux multimédia ;
- un module d'extraction (MD4) configuré pour extraire, à partir desdites adresses, de données de configuration associées à au moins un flux multimédia sélectionné parmi ladite liste de flux multimédias, lesdites données de configuration comprenant des données de manifeste caractérisant des paquets de données associés audit au moins un flux multimédia sélectionné ;
- un module d'enregistrement (MD6) configuré pour enregistrer les données de configuration dudit au moins un flux multimédia sélectionné ;
- un module de détection (MD8) configuré, après enregistrement des données de configuration par le module d'enregistrement, pour détecter un flux multimédia (FL2), dit premier flux multimédia, que le dispositif de lecture doit lire ;
un module de configuration (MD10) configuré pour récupérer des données de configuration enregistrées en association avec le premier flux multimédia, et pour configurer le dispositif de lecture selon les données de configuration du premier flux multimédia de sorte à permettre la lecture dudit premier flux multimédia.
13. Dispositif selon la revendication 12, comprenant un module de lecture configuré pour télécharger le premier flux multimédia conformément aux données de configuration dudit premier flux multimédia.
14. Dispositif selon la revendication 12 ou 13, dans lequel lesdites données de manifeste caractérisent, selon un protocole de téléchargement HTTP adaptatif, des paquets de données contenus dans ledit au moins un flux multimédia sélectionné.
15. Dispositif selon l'une quelconque des revendications 12 à 14, dans lequel les données de configuration comprennent en outre une clé de sécurité respective allouée au dispositif de lecture pour chaque flux multimédia sélectionné.
FR1853365A 2018-04-17 2018-04-17 Lecture d'un flux multimedia Active FR3080247B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1853365A FR3080247B1 (fr) 2018-04-17 2018-04-17 Lecture d'un flux multimedia

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1853365 2018-04-17
FR1853365A FR3080247B1 (fr) 2018-04-17 2018-04-17 Lecture d'un flux multimedia

Publications (2)

Publication Number Publication Date
FR3080247A1 true FR3080247A1 (fr) 2019-10-18
FR3080247B1 FR3080247B1 (fr) 2021-08-06

Family

ID=63143233

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1853365A Active FR3080247B1 (fr) 2018-04-17 2018-04-17 Lecture d'un flux multimedia

Country Status (1)

Country Link
FR (1) FR3080247B1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140280781A1 (en) * 2013-03-15 2014-09-18 General Instrument Corporation Enhanced playlist definition and delivery for fast channel change with http adaptive streaming
WO2014167168A1 (fr) * 2013-04-10 2014-10-16 Teleste Oyj Diffusion en continu adaptative de contenu multimédia
US20170230708A1 (en) * 2013-09-25 2017-08-10 Ericsson Television Inc System and Method for Effectuating Fast Channel Change in an Adaptive Streaming Environment

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140280781A1 (en) * 2013-03-15 2014-09-18 General Instrument Corporation Enhanced playlist definition and delivery for fast channel change with http adaptive streaming
WO2014167168A1 (fr) * 2013-04-10 2014-10-16 Teleste Oyj Diffusion en continu adaptative de contenu multimédia
US20170230708A1 (en) * 2013-09-25 2017-08-10 Ericsson Television Inc System and Method for Effectuating Fast Channel Change in an Adaptive Streaming Environment

Also Published As

Publication number Publication date
FR3080247B1 (fr) 2021-08-06

Similar Documents

Publication Publication Date Title
WO2011073586A1 (fr) Pre-chargement de contenu entre un serveur de contenu et au moins un terminal
FR3080247A1 (fr) Lecture d'un flux multimedia
EP4035408A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données
FR3081647A1 (fr) Gestion du telechargement progressif adaptatif (has) d'un contenu numerique au sein d'un terminal lecteur de flux multimedia en temps reel.
WO2023208688A1 (fr) Gestion de la restitution d'un contenu multimédia
WO2020259911A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d'un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d'ordinateur correspondants
WO2021089942A1 (fr) Procédé de gestion de zapping de contenus multimédias numériques obtenu par téléchargement progressif adaptatif (has), dispositif de gestion, lecteur de flux multimédia et programme d'ordinateur correspondants
EP3926929B1 (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
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
EP4297409A1 (fr) Procédé de gestion de la lecture d'un contenu multimédia.
EP3840391A1 (fr) Gestion de la restitution d'un contenu multimédia et d'une interface de navigation sur un écran
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique en mode économiseur d'écran
FR3059187A1 (fr) Procede de reglage des parametres lies a la restitution d'un contenu, programme d'ordinateur et dispositif correspondants
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
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.
EP4346216A1 (fr) Gestion de la lecture d'un contenu 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.
EP4373099A1 (fr) Procédé de gestion de l'accès à une contenu a lecture d'un contenu multimédia
WO2015104490A1 (fr) Procede de traitement d'erreur de restitution d'un contenu numerique
FR3143930A1 (fr) Gestion de gestion de la fourniture d’adresses de segments d’un contenu multimédia
FR3124344A1 (fr) Procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif.
EP4184922A1 (fr) Procédé de gestion de l' accès à un contenu multimédia
FR3138020A1 (fr) Streaming vidéo adaptatif hybride amélioré
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.
FR3135857A1 (fr) Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20191018

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7