FR3135857A1 - Gestion de la restitution d’un contenu multimédia sur plusieurs écrans. - Google Patents

Gestion de la restitution d’un contenu multimédia sur plusieurs écrans. Download PDF

Info

Publication number
FR3135857A1
FR3135857A1 FR2204658A FR2204658A FR3135857A1 FR 3135857 A1 FR3135857 A1 FR 3135857A1 FR 2204658 A FR2204658 A FR 2204658A FR 2204658 A FR2204658 A FR 2204658A FR 3135857 A1 FR3135857 A1 FR 3135857A1
Authority
FR
France
Prior art keywords
terminal
content
latency
restitution
slave
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR2204658A
Other languages
English (en)
Inventor
Hervé MARCHAND
Mathieu Rivoalen
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
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 FR2204658A priority Critical patent/FR3135857A1/fr
Publication of FR3135857A1 publication Critical patent/FR3135857A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4307—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen
    • H04N21/43076—Synchronising the rendering of multiple content streams or additional data on devices, e.g. synchronisation of audio on a mobile phone with the video output on the TV screen of the same content streams on multiple devices, e.g. when family members are watching the same movie on different devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

L’invention se rapporte à un procédé de gestion dans un terminal (STBsi) , dit terminal esclave, de la lecture d’un contenu (C1) en vue d’une restitution sur un écran, le contenu comprenant des segments temporels reçus depuis un premier réseau de communication (RES), caractérisé en ce que le terminal esclave (STBsi) réalise les étapes suivantes : a. Réception de segments d’un même contenu (C1) par un terminal maître et un terminal et restitution des segments sur un écran maître (TVm) et un écran esclave (TVsi) , respectivement, b. Obtention, en liaison avec un autre terminal, dit terminal maître, d’une première durée de latence précédant la restitution du segment sur l’écran maître (TVm), c. Détermination d’un deuxième délai de latence précédant la restitution sur l’écran esclave (TVsi), d. Comparaison des durées de latence, et si les durées de latence diffèrent, sélection d’un mode lecture des segments en fonction du résultat de l’étape de comparaison.. Figure pour l'abrégé : Figure 1

Description

Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.
Le domaine de l'invention est celui de la gestion de la restitution de contenus multimédia numériques, à savoir les contenus audio et/ou vidéo numériques. Plus précisément, l'invention concerne la gestion de la restitution d’un contenu multimédia sur plusieurs écrans de télévision.
L’invention vise tout particulièrement les contenus accessibles selon plusieurs formats associés à des tailles respectives en octets ayant plus ou moins d’impact sur la bande passante du réseau sur lequel le contenu est téléchargé. L’invention vise tout particulièrement les contenus téléchargés selon une technique dite de téléchargement progressif adaptatif, ou HAS, ou toutes autres techniques de téléchargement utilisant le même principe.
L’invention s’applique tout particulièrement à un système dans lequel un même contenu est restitué sur plusieurs écrans appartenant à des utilisateurs qui intéragissent entre eux en temps réel lors de la restitution. L’intéraction peut être réalisée au moyen d’une caméra et d’une restitution des participants sur les différents écrans. L’intéraction peut aussi être faite avec des téléphones fixes ou mobile.
 Etat de la technique
L’accès à un contenu multimédia, tel que la télévision ou la vidéo à la demande, depuis un réseau de type Internet, est possible aujourd’hui pour la plupart des terminaux de restitution, notamment lorsqu’ils appartiennent à un réseau de communication local, tel qu’un réseau domestique.
Le terminal émet généralement une requête à destination d’un serveur, en indiquant le contenu choisi ; le terminal reçoit en retour un flux de données numériques relatives à ce contenu. Dans le cadre d’un réseau de communication local, une telle requête transite par la passerelle d’accès au réseau, par exemple la passerelle résidentielle.
Le terminal est adapté pour recevoir un contenu numérique sous forme de données multimédia et pour requérir une restitution de ce contenu sur un dispositif de restitution. Les données reçues correspondant à une vidéo sont généralement décodées, puis restituées 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 sur Internet 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 (buffer en anglais) avant de les restituer. Ce mode de distribution est particulièrement utile quand le débit dont dispose l’utilisateur n’est pas garanti pour le transfert en temps réel de la vidéo.
Le téléchargement progressif adaptatif, 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 description, appelé « manifest » par l’homme du métier, 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 « manifests », 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 segments. Chacun de ces segments est rendu disponible individuellement au moyen d'un protocole d'échange. Le protocole principalement ciblé est le protocole HTTP, mais d'autres protocoles (par exemple FTP) peuvent également être utilisés. L'organisation des segments et les paramètres associés sont publiés dans un manifest au format XML.
Le principe sous-jacent à cette norme est que le terminal client 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 d’encodage, à 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.
D’autre part, 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.
En effet, une telle fluctuation peut induire une variation de la latence au fil du temps, appelée gigue, ou en anglais « jitter ». On rappelle que la latence est définie, dans un réseau de transmission de données, comme le temps nécessaire à un paquet de données pour être restitué. On calcul en général ce temps de latence en prenant comme instant initial l’instant de diffusion d’un paquet par un serveur de diffusion et comme instant final l’instant de restitution. Pendant ce temps de latence, le paquet passe de la source à la destination au travers du réseau, jusqu’à la restitution des données du paquet. Afin de compenser les effets néfastes de la gigue pour l’utilisateur, il est connu de placer une mémoire tampon (ou en anglais « buffer ») dans le terminal de restitution des flux de données reçus, dans laquelle sont stockées un certain nombre de paquets de données, avant le début de leur restitution à l’utilisateur. Ce tampon de gigue induit donc un délai détectable au début de la restitution du flux.
Ce fonctionnement, qui est le même dans chaque terminal de restitution, pose problème dans un contexte dans lequel plusieurs personnes interagissent en temps réel à propos du contenu restitué. En effet, les réseaux auxquels sont connectés les terminaux de restitution, respectivement, ont des caractéristiques qui peuvent différés ; en particulier, la bande passante diffère d’un réseau à un autre ; les tailles (aussi appelées profondeurs) de buffers diffèrent aussi. Il résulte de ces différences, pour un même contenu live, un décalage temporel entre instants de restitution de segments sur les différents téléviseurs qui peut être de l’ordre de 10 à 15 secondes parfois. Ce décalage est très pénalisant lorsque plusieurs utilisateurs visualisent et commentent ce même contenu live ; par exemple dans le cas d’un match de foot, une action peut se dérouler avec dix secondes d’écart temporel entre deux restitutions ; l’intéraction en temps réel devient alors impossible du fait du décalage temporel.
L'invention vient améliorer la situation.
L’invention
L’invention se rapporte à un procédé de gestion dans un terminal, dit terminal esclave, de la lecture d’un contenu en vue d’une restitution sur un écran, le contenu comprenant des segments temporels reçus depuis un premier réseau de communication, caractérisé en ce que le terminal esclave réalise les étapes suivantes:
a. Réception de segments d’un même contenu par un terminal maître et un terminal et restitution des segments sur un écran maître et un écran esclave, respectivement,
b. Obtention, en liaison avec un autre terminal, dit terminal maître, d’une première durée de latence précédant la restitution du segment sur l’écran maître (TVm),
c. Détermination d’un deuxième délai de latence précédant la restitution sur l’écran esclave,
d. Comparaison des durées de latence, et si les durées de latence diffèrent, sélection d’un mode lecture des segments en fonction du résultat de l’étape de comparaison.
Grâce à l’invention, les téléchargements des segments sur les différents décodeurs ne sont plus gérés indépendamment les uns des autres. Les terminaux vont interagir de manière à synchroniser la restitution des segments en réduisant considérablement l’écart temporel de restitution de chaque segments vidéo entre différents dispositifs de restitution. Le décalage temporel entre les différentes restitutions étant réduit à une valeur raisonnable, voir un décalage temporel nul, des commentaires réalisés en temps réels par des participants visualisant les dispositifs de restitution respectivement. Il résulte de cette optimisation, de cette synchronisation, une expérience utilisateur largement améliorée.
Selon l’invention, le mode de lecture utilisé par défaut initialement va être interrompu puis remplacé par un autre mode de lecture capable de rattraper le décalage temporel. Une fois le décalage réduit voire supprimé, le mode de lecture par défaut est de nouveau utilisé.
Précisons ici qu’une durée de latence précédant une restitution est une durée qui sépare un instant initial et un instant de restitution. L’instant initial est choisi au cas par cas. Par exemple, comme indiqué ci-dessus, l’instant initial peut être un instant de diffusion de données depuis un serveur de diffusion de données ; dans cette configuration, le délai de latence sera la différence entre l’instant de restitution et l’instant de diffusion du paquet.
On pourra choisir un autre instant initial, ce dernier peut aussi être un instant d’émission de données par le terminal ; dans ce cas, le délai de latence sera la différence entre ’'instant d’émission des données et l’instant de restitution.
Ici, les différents terminaux, maître ou exclaves, utilisent le même délai de latence. On verra dans la suite que l’instant initial utilisé pour illustrer l’invention est un instant de diffusion des données, en l’occurrence des segments de données, depuis un serveur de diffusion.
Selon un premier mode de réalisation du procédé, si la deuxième durée de latence est inférieure à la première durée de latence, la lecture par le terminal esclave est suspendue et reprise après un délai de reprise donné. Ce premier mode vise le cas où le terminal esclave restitue le contenu avant le terminal maître. Ce premier mode est avantageux car une suspension de la lecture consomme très peu de ressources physiques et/ou logicielles du terminal esclave.
Selon une variante de ce premier mode, le délai de reprise est déterminé en fonction d’une durée de décalage obtenue lors de l’étape de comparaison. Dans cette variante, le délai de reprise prend en compte le décalage temporel entre les restitutions obtenu lors de l’étape de comparaison. Une fois l’écart temporel obtenu, la lecture est repise en déduisant cette durée de décalage.
Selon une sous-variante, le délai de repise comprend en outre une marge temporelle supplémentaire. Cette marge temporelle permet de placer l’instant de lecture à un en prenant en compte non seulement la durée de décalage visée ci-dessus mais aussi des délais tels qu’un délai de récupération d’un segment, un délai d’initialisation du décodeur présent dans le terminal, etc.
Selon encore un deuxième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, si la deuxième durée de latence est inférieure à la première durée de latence, la vitesse de lecture par le terminal esclave est modifiée. Dans cette variante, un décalage de restitution est corrigé en modifiant la vitesse de lecture d’un des deux terminaux ou des deux terminaux jusqu’à ce que les instants de lecture coïncident et qu’une synchronisation entre les différentes restitutions soient rétablis.
Le contenu comprend des segments temporels associés à des instants de diffusion. Selon encore un troisième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, si la deuxième durée de latence est supérieure à la première durée de latence, la lecture est réinitialisée et reprise en téléchargeant le contenu à partir d’un segment dont l’instant de diffusion est fonction de la durée de décalage obtenue lors de l’étape de comparaison.
Selon une variante du troisième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, les étapes visées ci-dessus sont mises en œuvre dès que la première durée de latence est modifiée.
Selon un aspect matériel, l’invention se rapporte à une entité de gestion de la lecture par un terminal, dit terminal esclave, de la lecture d’un contenu en vue d’une restitution sur un écran, , le contenu comprenant des segments temporels reçus depuis un premier réseau de communication, caractérisé en ce que le terminal esclave comprend un processeur configuré pour réaliser les étapes suivantes :
a. Réception de segments d’un même contenu par un terminal maître et un terminal et restitution des segments sur un écran maître et un écran esclave , respectivement,
b. Obtention, en liaison avec un autre terminal, dit terminal maître, d’une première durée de latence précédant la restitution du segment sur l’écran maître,
c. Détermination d’un deuxième délai de latence précédant la restitution sur l’écran esclave,
d. Comparaison des durées de latence, et si les durées de latence diffèrent, sélection d’un mode lecture des segments en fonction du résultat de l’étape de comparaison.
Selon un autre aspect matériel, l’invention se rapporte à un terminal lecteur comprenant une entité de gestion telle que définie ci-dessus.
Selon un autre aspect matériel, l’invention a pour objet un programme d'ordinateur apte à être mis en œuvre sur une entité de gestion telle que définie ci-dessus, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé de gestion définies ci-dessus.
Selon un autre aspect matériel, l’invention a pour objet un support de données sur lequel a été mémorisée au moins une série d’instructions de code de programme pour l’exécution d’un procédé de gestion tel que défini ci-dessus.
Le support en question 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 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 sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés sur lesquels :
La représente une architecture de téléchargement progressif sur Internet basée sur l’utilisation du streaming adaptatif selon un mode de réalisation du procédé de l’invention ;
La illustre de façon schématique la structure matérielle d’un terminal maître lecteur de flux multimédia en temps réel;
La illustre de façon schématique la structure matérielle d’un terminal esclave lecteur de flux multimédia en temps réel;
La illustre un contenu et ses segments disponibles.
La illustre un mode de réalisation possible du procédé de l’invention.
Description détaillée de modes de réalisation de l'invention
On présente désormais, en relation avec la , une architecture de téléchargement d’un contenu multimédia.
Dans notre exemple, le téléchargement est de type progressif basé sur l’utilisation du streaming adaptatif HAS. Précisons à nouveau ici que l’invention ne se limite pas à la technologie HAS mais s’étend à toutes autres technologies de téléchargement de données.
Un serveur de contenus numériques SRV se trouve selon cet exemple dans le réseau étendu WAN référencé RES mais il pourrait indifféremment être situé une passerelle domestique ou tout autre équipement capable d’héberger un tel serveur de contenus.
Le serveur de contenus SRV 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 de terminaux clients.
Des terminaux de lecture clients, par exemple des décodeurs, peuvent entrer en communication avec le serveur de contenus SRV pour recevoir un ou plusieurs contenus (films, documentaires, séquences publicitaires, etc.).
Les terminaux clients peuvent être de toute sorte, par exemple un décodeur STB, un ordinateur PC, un téléphone mobile MOB, etc.
Les modes de réalisation se baseront sur des décodeurs équipés d’un dispositif de restitution tel qu’un téléviseur.
Comme on le verra plus tard, on distinguera un terminal client maître STBm (l’indice « m » désigne ce terminal client maître) de terminaux clients esclaves STBsi (« s » désigne un terminal client esclave et « i » le n-ième terminal ; l’indice « i » est un entier et désigne un terminal « i » en particulier).
Il est fréquent, dans ce contexte client-serveur, de recourir, pour échanger les données entre un terminal client STBm/STBsi et le serveur SRV, à 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, et une passerelle de services , et/ou entre cette dernière et le serveur de contenus SRV.
Classiquement, comme on le verra en référence à la , différentes qualités peuvent être encodées pour le même contenu d’une chaîne, correspondant par exemple à différents débits d’encodage. 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 d’encodage. Chaque niveau de qualité est lui-même découpé sur le serveur de contenus en segments temporels (aussi appelés « segments » de contenu par l’homme du métier, en anglais segments).
La description de ces différentes qualités et de la segmentation temporelle associée, ainsi que les segments de contenu, sont décrits pour le terminal client et mis à sa disposition via leurs adresses Internet (URI : Universal Ressource Identifier). L’ensemble de ces paramètres (qualités, adresses des segments, etc.) est en général regroupé dans un fichier de paramètres, dit fichier de description ou « manifest ». On notera que ce fichier de paramètres peut être un fichier informatique ou un ensemble d’informations descriptives du contenu, accessible à une certaine adresse.
Le terminal de lecture STBm/STBsi, dans un contexte de téléchargement adaptatif progressif, peut adapter les requêtes d’accès qu’il transmet au serveur pour recevoir et décoder le contenu demandé par l’utilisateur à la qualité qui lui correspond au mieux. Dans notre exemple, si les contenus sont disponibles aux débits 400 kb/s (kilobits par seconde) (Résolution 1, ou niveau 1, noté N1), 800 kb/s (N2), 1200 kb/s (N3) 2100 kb/s (N4) 3000 kb/s (N4) 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 2100 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).
Une passerelle de service GTWm/GTWsi, par exemple une passerelle domestique peut s’intercaler entre le réseau WAN et un terminal client. Cette passerelle assure le routage des données entre un réseau étendu WAN et le décodeur STB, gère les contenus numériques en assurant notamment leur réception en provenance du réseau et leur décodage grâce au décodeur STB.
Dans cet exemple, pour visualiser un contenu, un terminal client interroge tout d’abord la passerelle de service à laquelle il est relié pour obtenir une adresse du fichier de description du contenu (par exemple, C1) souhaité. La passerelle de service répond en fournissant au terminal l’adresse du fichier de description. Dans la suite, on supposera que ce fichier est un fichier de type manifest selon la norme MPEG-DASH et on se réfèrera indifféremment, selon le contexte, à l’expression « fichier de description » ou « manifest».
Alternativement, ce fichier peut être récupéré directement auprès d’un serveur Internet local ou externe au réseau local, ou se trouver déjà sur la passerelle de service ou sur le terminal au moment de la requête.
Un exemple de fichier manifest, qui sera décrit ci-dessous en référence à la , comporte la description de contenus disponibles dans plusieurs qualités différentes (N1 = 400 kb/s, N2 = 800 kb/s, N3 = 1200 kb/s, …).
Une fois qu’elle dispose des adresses de segments correspondant au contenu souhaité, la passerelle de service concernée procède à l’obtention des segments via un téléchargement à ces adresses. On notera que ce téléchargement s’opère ici, traditionnellement, au travers d’une URL HTTP, mais pourrait également s’opérer au travers d’une adresse universelle (URI) décrivant un autre protocole (dvb://monsegmentdecontenu par exemple).
Le décodeur STBm/STBsi est utilisé pour restituer, sur l’écran du téléviseur TVm/TVsi respectivement, un programme télévisuel. Par la suite, on désigne ce programme télévisuel sous le nom de contenu C1. Un tel contenu C1 est décrit dans un fichier manifest (cf. ).
En variante, on notera que le contenu C1 peut être un programme télévisuel diffusé en différé, ou une vidéo à la demande, ou une vidéo personnelle de l’utilisateur, ou tout autre contenu multimédia de durée déterminée, pour laquelle l’invention s’applique également.
Dans notre exemple, une communication en temps réel a lieu en parallèle des différentes restitutions sur les téléviseurs TVm/TVsi. La façon de communiquer en temps réel entre utilisateurs est quelconque. Dans notre exemple, la communication s’effectuera via des caméras et par incrustation de capture d’utilisateurs sur les différents écrans des téléviseurs. Dans notre exemple, sur le téléviseur maître TVm, apparaît en incrustation les utilisateur UTs1 et UTs2. sur le téléviseur esclave TVs1, apparaît en incrustation les utilisateur UTm et UTs2 ; et sur le téléviseur maître TVs2 apparaît en incrustation les utilisateur UTm et UTs1.
Un décodeur STBm/STBsi peut être piloté par l’utilisateur au moyen d’une télécommande (non représentée). Cette télécommande permettra de sélectionner des onglets sur une interface de sélection. La télécommande peut être physique ou logicielle.
La représente une architecture d’un terminal client maître STBm, illustré au moyen d’un décodeur selon un mode de réalisation de l’invention.
Le décodeur STBm comprend, classiquement, des mémoires MEMm associées à un processeur CPUm. 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.
Le décodeur STBm communique avec la passerelle GTWm via un premier module de communication COMm et avec le téléviseur TVm via un deuxième module de communication COMm2.
Le premier module de communication COMm1 est par exemple un lien Wi-Fi. Le deuxième module de communication COMm2 est par exemple un lien HDMI.
Le décodeur STBm comprend en outre un module de téléchargement progressif adaptatif HASm apte à demander un téléchargement progressif de l’un des contenus à l’une des qualités proposées dans un fichier de description MNF.
Le décodeur STB comprend en outre une entité de gestion ENTm, objet de l’invention, dont le fonctionnement sera détaillé ci-après.
Le décodeur STBm peut aussi contenir d’autres modules comme un disque dur non représenté pour le stockage des segments vidéo, un module de contrôle d’accès aux contenus, un module de traitement des commandes reçues du smartphone.
La représente une architecture d’un terminal client esclave STBsi, également illustré au moyen d’un décodeur selon un mode de réalisation de l’invention. L’architecte d’un tel décodeur esclave est la même que celle décrite en référence à la .
En particulier, le décodeur STBsi comprend, classiquement, des mémoires MEMsi associées à un processeur CPUsi. 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.
Le décodeur STBsi communique avec la passerelle GTWsi via un premier module de communication COMsi1 et avec le téléviseur TVsi via un deuxième module de communication COMsi2.
Le premier module de communication COMsi1 est par exemple un lien Wi-Fi. Le deuxième module de communication COMsi2 est par exemple un lien HDMI.
Le décodeur STBsi comprend en outre un module de téléchargement progressif adaptatif HASsi apte à demander un téléchargement progressif de l’un des contenus à l’une des qualités proposées dans un fichier de description MNF.
Le décodeur STBsi comprend en outre une entité de gestion ENTsi, objet de l’invention, dont le fonctionnement sera détaillé ci-après.
Le décodeur STB peut aussi contenir d’autres modules comme un disque dur non représenté pour le stockage des segments vidéo, un module de contrôle d’accès aux contenus, un module de traitement des commandes reçues du smartphone.
On présente désormais, en relation avec la , une vue schématique d’un contenu principal C1 découpé en segments et stocké dans le serveur de contenus SRV. Plus précisément, le serveur de contenu HAS expose une vidéo C1 sous forme de segments C1i@Nj encodés à différents débits d’encodage Nj, où l’indice i désigne un identifiant temporel du segment C1i@Nj.
Selon l’art antérieur, le module de téléchargement HAS, appelé mode de téléchargement classique ci-dessous, du décodeur STB est chargé de venir récupérer les segments auprès du serveur de contenu HAS 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 de téléchargement HAS choisit le débit d’encodage du prochain segment vidéo à télécharger : il existe en effet de nombreux algorithmes permettant d’opérer ce choix, dont les stratégies sont plus ou moins sécuritaires ou agressives. On rappelle cependant que, le plus souvent, le principe général de tels algorithmes repose sur le téléchargement d’un premier segment au débit d’encodage le plus faible proposé dans le fichier manifest, et sur l’évaluation du temps de récupération de ce premier segment. Sur cette base, le module de téléchargement HAS évalue si, en fonction de la taille du segment et du temps mis pour le récupérer, les conditions réseau permettent de télécharger le segment suivant à un débit d’encodage plus élevé. Certains algorithmes reposent sur une augmentation progressive du niveau de qualité des segments de contenu téléchargés ; d’autres proposent des approches plus risquées, avec des sauts dans les niveaux des débits d’encodage des segments successifs.
Dans le cas classique, si un segment vidéo dure 3 secondes, la récupération du segment par le module de téléchargement HAS ne doit pas excéder 3 secondes, afin de permettre une restitution sans interruption du contenu par le décodeur STB. Il convient donc pour le module de téléchargement HAS d’opérer le meilleur compromis entre une qualité de restitution, et donc un débit d’encodage, aussi élevés que possible, et le temps de téléchargement du segment, qui doit être suffisamment faible pour permettre une restitution en continu sur le téléviseur TV.
Dans un premier temps, le module HAS récupère le fichier manifest MNF qui correspond au contenu vidéo C1 afin de découvrir les segments disponibles du contenu vidéo C1, et les différentes qualités vidéo Nj associées. Dans l’exemple de la , le contenu C1 est par exemple proposé sous forme de segments de durée 3s, avec un premier débit d’encodage N1 = 400 kb/s, un deuxième débit d’encodage N2 = 800 kb/s, un troisième débit d’encodage N3 = 1200 kb/s, etc.
Dans un mode de fonctionnement normal, non illustré sur la , le module HAS opère le téléchargement par exemple, des segments successifs C11@N1 (soit le premier segment temporel à un débit d’encodage de 400 kb/s), puis C12@N3 (soit le deuxième segment temporel à un débit d’encodage de 1200 kb/s), puis C13@N3 (soit le troisième segment temporel à un débit d’encodage de 1200 kb/s), etc.
Les différents segments téléchargés par le module de téléchargement HAS sont transmis à un module d’affichage AFF apte à requérir un affichage sur l’écran du téléviseur TV.
L’algorithme mis en œuvre par le module de téléchargement HAS pour déterminer quel segment à quel débit d’encodage doit être téléchargé en mode de fonctionnement normal peut être l’un des algorithmes déjà existants de l’art antérieur. Cet algorithme ne sera donc pas décrit ici plus en détail.
La illustre un mode de réalisation du procédé de l’invention.
Dans ce mode, deux décodeurs vont accéder au même contenu C1 et vont utiliser un module de communication pour partager des commentaires sur le contenu C1.
Le module de communication est indifférent. Ce dernier est par exemple une webcam associée à une application de réseau social permettant de communiquer en temps réel avec d’autres utilisateurs. Dans notre exemple un serveur VS gère la communication en temps réel par caméra. Via ce serveur VS, des participant à une visioconférence peuvent communiquer et commenter la restitution du contenu.
Au lieu d’une visioconférence, la communication entre participants peut aussi être tout simplement une communication audio par téléphone fixe ou mobile ; les participants communiquent dans ce cas en temps réel entre eux au moyen de téléphones pour commenter le contenu C1.
Sur la on a choisi d’illustrer l’invention au moyen d’une visioconférence. En référence aux figures 2 et 3, les décodeurs STBm/STBsi sont équippés de caméra CAMm/CAMsi respectivement (i=1,2).
Chaque décodeur STBm/STBsi transmet un flux vidéo capté par sa caméra et reçoit l’ensemble des flux vidéos captés par les autres caméras associées aux autres décodeurs.
La représente par exemple un écran de télévision TVs1 associée à un décodeur STBs1.
Sur cet écran, sont représentés le contenu C1 et les flux Fm et Fs2 reçus depuis les décodeurs STBm et STBs2, respectivement.
La figure 6 illustre la gestion du téléchargement des segments par les entités ENTm et ETMsi, le but étant que synchroniser la restitution du contenu C1 sur les écrans. En effet, l’état du réseau associé aux différents décodeurs peut différer. Un décodeur peut être relié à un réseau de télécommunication associé à une excellente bande passante alors qu’un autre décodeur dispose d’une bande passante moins bonne. Tous ces paramètres font que la restitution du contenu peut ne pas avoir lieu au même moment.
Si on prend comme exemple un match de football, les décalages temporels entre les différentes restitutions font que les utilisateurs visualisant le match ne voient pas la même scène au même moment. S’il y a un décalage de quelques secondes entre deux restitutions, deux réactions à propos d’une même scène (un but par exemple) seront décalées dans le temps. L’intéraction via la visioconférence devient alors chaotique, ce d’autant plus que le nombre de décodeurs est important.
Deux phases sont décrites en référence à la figure.
Lors d‘une première phase, les décodeurs accèdent au contenu C1 avec un mode de lecture par défaut de la façon indiquée ci-dessus conformément au mode de téléchargement HAS ; chaque module téléchargement HASm/HASsi gère le téléchargement des segments séparément.
Dans l’exemple qui suit, seul un décodeur esclave STBs1 sera utilisé pour simplifier l’exposé.
Lors de cette première phase, le décodeur maître STBm initie une session de visioconférence et invite le terminal esclave à y participer.
Dans notre exemple, le décodeur esclave STBs1 accepte et une session de visioconférence est activée.
A ce stade, chaque écran affiche une image équivalente à celle représentée sur la .
Les écrans TVm et TVs1 comporte alors un flux Fm ou Fs1 selon le terminal concerné. L’écran maître TVm fait apparaître le contenu et C1 et le flux lié à la visioconférence issue du décodeur exclave STBs1. A l’inverse, L’écran esclave TVs1 fait apparaître le contenu et C1 et le flux lié à la visioconférence issue du décodeur maître STBm.
Lors d’une deuxième phase, illustrée sur la figure 6, les entités ENTm et ENTs1 interviennent dans le procédé. Cette deuxième phase comprend plusieurs étapes.
Lors d’une première étape ET1, le décodeurs STBm/STBs1 déterminent un délai de latence T1 et T2, respectivement.
Dans notre exemple, le décodeur maître STBm calcule le délai de latence T1 grâce au fichier de description obtenu lors de la première phase.
Dans notre exemple, le calcul du premier délai de latence T1 est réalisé aussi souvent que possible de manière à exécuter de nouveau les étapes qui suivent.
Aussi, dans notre exemple, dès que cette première durée de latence T1 subit une modification, le procédé est de nouveau exécuté. En effet, des perturbations peuvent apparaitre au fil du temps imposant le terminal maître à modifier par exemple la taille de la mémoire tampon et donc à modifier la première durée de latence T1
Dans notre exemple, rappelons que le délai de latence avant restitution correspond au délai entre un instant donnée, par exemple l’instant l’émission d’un segment depuis le serveur, et la restitution du segment sur l’écran. On comprend donc que la taille de la mémoire tampon qui évolue dans le temps joue un rôle primordial sur la durée de latence.
Le délai de latence avant restitution peut être obtenu différemment. Par exemple, le délai de latence peut concerner le délai entre, non pas un instant de diffusion, mais un instant d’émission d’un segment depuis un terminal, qu’il soit maître ou exclave, et la restitution du segment. Ce mode est intéressant lorsque la bande passante sur la réseau est telle qu’elle n’engendre pas ou peu de décalage temporel entre des transmissions de données réalisées à destination de différents terminaux.
Dans notre exemple, pour obtenir ce délai de latence, l’entité maître ENT1 consulte le fichier de description HAS qui indique l’heure exacte de production et de diffusion des segments HAS du contenu Live.
Le décodeur maître détermine, pour un segment donné qu’il a reçu, l’heure à laquelle ce segment a été restitué sur l’écran maître TVm. Ayant l’heure de diffusion et l’heure de restitution sur le terminal maître, le décodeur maître STBm soustrait ces deux valeurs et obtient un premier délai de latence avant restitution T1. Ce délai de latence permet d’obtenir le décalage temporel réel entre ce qui est affiché à l’écran et le « vrai » live (heure de production du segment).
Ayant obtenu le premier délai de latence T1, lors d’une deuxième étape ET2, le décodeur maître STBm transmet ce délai de latence T1 au décodeur esclave. La transmission est faite par exemple via le serveur VS.
L’entité esclave ENTs1 réalise le même calcul et obtient un deuxième délai de latence avant restitution T2. Le calcul du deuxième délai de latence sur la même base que le terminal maître à savoir un délai de latence entre un instant de diffusion et un instant de restitution d’un segment.
Ayant à dispositif les délais de latence T1 et T2, lors d’une troisième étape ET3, l’entité esclave ENTs compare les deux délais de latence T1 et T2. La suite du procédé dépend du résultat de cette comparaison.
Si les délais de latence sont les mêmes ou quasi les mêmes, dans ce cas, les segments sont téléchargés sans modification du mode de téléchargement (OK).
On définira des valeurs pour lesquels on estimera que la différence entre les délais de latence T1 et T2 est telle que le décalage ne gêne pas ou est peu visible des participants à la visioconférence. par exemple une différence de quelques dixièmes de seconde (par exemple 0,1 seconde) sera toléré ; au-delà un traitement est exécuté.
Si les délais de latence diffèrent, les entités sont aptes à modifier le mode de lecture par défaut. Deux cas se présentent selon que la première durée de latence est supérieure ou inférieure à la deuxième durée de latence (ET4).
Si le délai T2 est inférieur au délai T1 (T2<T1), dans ce premier cas, la restitution du contenu C1 sur l’écran esclave TVs1 s’effectue avant la restitution sur l’écran maître TVm. Dans notre exemple, l’entité esclave ENTs1 va alors appliquer un traitement lors d’une étape ET5a, consistant à réaliser une pause tout en poursuivant la réception des segments C1i@Nj. Le décodeur esclave ajuste la profondeur de sa mémoire tampon en fonction de la durée du décalage temporel entre les deux restitutions. Cette pause d’une durée donnée est suivie lors d’une étape ET6b d’une reprise de la lecture. Lors de la reprise, du fait de l’adaptation de la profondeur de la mémoire, le terminal esclave restitue les segments de manière synchrone avec le terminal maître.
Si le délai T2 est supérieur au délai T1 (T2>T1), dans ce deuxième cas, la restitution du contenu C1 sur l’écran esclave TVs1 s’effectue après la restitution sur l’écran maître TVm. L’entité esclave va modifier le mode de lecture par défaut ; l’entité esclave STBs1 va alors appliquer, lors d’une étape ET5c, un traitement consistant à rattraper le retard dans la restitution. Ce rattrapage peut être réalisé de plusieurs manières. Dans notre exemple, le décodeur esclave STBs1 va réinitialialiser INIT la lecture du flux Live. Cette réinitialisation est équivalente à zapper c’est-à-dire à sélectionner de nouveau le contenu par exemple avec une télécommande. L’entité esclave STBS1 détermine le segment qu’il doit télécharger pour rattraper la lecture sur le décodeur maître. Pour cela, l’entité esclave ENTs1 vide sa mémoire tampon, définie une nouvelle profondeur de mémoire tampon adaptée pour assurer une synchronisation de restitution du contenu avec le terminal maître ; le terminal esclave remplit ensuite sa mémoire tampon de nouveau en sélectionnant judicieusement le premier segment à télécharger pour la reprise ainsi que les segments suivants. La lecture peut alors reprendre lors d’une étape ET6d.
Pour déterminer le segment à télécharger pour la reprise, l’entité esclave ENTs1 prend en compte la durée du décalage de restitution avec le décodeur maître et requiert un téléchargement d’un segment qui est a une durée de vie supérieure à cette durée de décalage.
En variante, l’entité esclave ENTs1 peut également prendre en compte une marge temporelle supplémentaire de manière à se trouver dans le premier cas visé ci-dessus plus simple à traiter. Il suffira alors à l’entité esclave d’appliquer une pause avant la lecture pour synchroniser les flux sur le décodeur maître et le décodeur esclave.
Par exemple, si la durée de décalage par rapport au Live qui est déterminée par le Master est de 17 secondes, dans ce cas, le décodeur esclave STBs1, après avoir vidé son buffer de lecture va commencer à récupérer un segment produit il y a 17 secondes + 5 secondes (marge) = 23 secondes.
Cette marge permet de prendre en compte les temps de récupération du premier segment, d’initialisation du décodeur, etc., voire plus. Le décodeur esclave STBs va donc très probablement se retrouver dans le premier cas 1 visé ci-dessus et se synchroniser précisément en faisant une pause suivie d’une reprise.
Selon une deuxième variante des modes de réalisation décrits ci-dessus, en particulier lorsque l’écart temporel entre restitution est relativement faible, de l’ordre de quelques secondes (deux secondes par exemple), au lieu des traitements prévus ci-dessus pour faire coïncider les deux restitutions, l’entité esclave STBs1 applique un coefficient multiplicateur à la vitesse de lecture du terminal maître et/ou au terminal esclave pour diminuer et/ou augmenter les vitesses de lecture jusqu’à ce que les restitutions coïncident. Cette deuxième variante offre un ajustement des restitution moins agressif qu’une pause, l’expérience est plus fluide .
Le coefficient multiplicateur est de préférence choisi de telle manière que la modification de la vitesse de lecture reste peu ou pas perceptible pour un utilisateur qui visualise l’écran concerné.
Concrètement, si le terminal esclave Ts est en retard de 2 secondes par rapport au terminal maître, en appliquant un coefficient multiplicateur de 0,75 à la vitesse de lecture Vm sur le terminal maître Tm et un coefficient multiplicateur de 1,25 à la vitesse de lecture Vs sur le terminal esclave Ts, dans ce cas d’espèce, l’écart temporel de 2 secondes entre les deux restitutions se rattrape en 4 secondes
Vm x 0.75 pendant 4 secondes
Vs x 1.25 pendant 4 secondes
En effet, accélérer d’un coefficient x1,25 entraîne une lecture de 1,25s du contenu en 1s, donc on avance de 5s en 4s ; et décélérer d’un coefficient x0,75 entraîne une lecture de 0,75s du contenu en 1s, donc on avance de 3s dans le contenu en en 4s.
Le symbole « x » étant le signe mathématiques de multiplication
En résumé, lors d’une session de partage en visioconférence d’un contenu Live, le décodeur maître obtient une latence de lecture (temps séparant la génération effective d’un segment vidéo HAS produit par le serveur Live HAS et la consommation de ce segment dans le player Live du master). Cette latence est diffusée à travers un canal de communication aux différents décodeurs esclaves participants de la session. Ensuite, chacun de participants récupère la latence fournie par le décodeur maître et compare cette valeur à la latence qu’ils ont eux-mêmes sur le flux Live. Si la valeur n’est pas identique, le décodeur maître déclenche une procédure de synchronisation consistant soit en une mise en pause suivie d’une reprise soit en une réinitialisation, le tout en gérant et ajustant la profondeur de la mémoire tampon. Il résulte de cet ajustement une restitution du contenu de manière synchronisée.
Précisons enfin ici aussi ici que le terme « entité » 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.)

Claims (11)

  1. Procédé de gestion dans un terminal (STBsi) , dit terminal esclave, de la lecture d’un contenu (C1) en vue d’une restitution sur un écran, le contenu comprenant des segments temporels reçus depuis un premier réseau de communication (RES), caractérisé en ce que le terminal esclave (STBsi) réalise les étapes suivantes :
    1. Réception de segments d’un même contenu (C1) par un terminal maître et un terminal et restitution des segments sur un écran maître (TVm) et un écran esclave (TVsi) , respectivement,
    2. Obtention, en liaison avec un autre terminal, dit terminal maître, d’une première durée de latence précédant la restitution du segment sur l’écran maître (TVm),
    3. Détermination d’un deuxième délai de latence précédant la restitution sur l’écran esclave (TVsi),
    4. Comparaison des durées de latence, et si les durées de latence diffèrent, sélection d’un mode lecture des segments en fonction du résultat de l’étape de comparaison.
  2. Procédé de gestion selon la revendication 1, caractérisé en ce que si la deuxième durée de latence (Ts) est inférieure à la première durée de latence (TM), la lecture par le terminal esclave est suspendue et reprise après un délai de reprise donné.
  3. Procédé de gestion selon la revendication 2, en ce que le délai de reprise est déterminé en fonction d’une durée de décalage obtenue lors de l’étape de comparaison.
  4. Procédé selon la revendication 2 ou 3, caractérisé en ce que le délai de repise comprend en outre une marge temporelle supplémentaire.
  5. Procédé selon la revendication 1, caractérisé en ce que si la deuxième durée de latence (Ts) est inférieure à la première durée de latence (TM), la vitesse de lecture par le terminal esclave est modifiée.
  6. Procédé selon la revendication 1, caractérisé en ce que le contenu comprend des segments temporels associés à des instants de diffusion et en ce que, si la deuxième durée de latence (Ts) est supérieure à la première durée de latence (TM), la lecture est réinitialisée et reprise en téléchargeant le contenu à partir d’un segment dont l’instant de diffusion est fonction de la durée de décalage obtenue lors de l’étape de comparaison..
  7. Procédé selon la revendication 4, caractérisé en ce que les étapes b) à c) sont mise en œuvre dès que la première durée de latence est modifiée.
  8. Entité de gestion (ENTsi) de la lecture par un terminal (STBsi) , dit terminal esclave, d’un contenu (C1) en vue d’une restitution sur un écran, , le contenu comprenant des segments temporels reçus depuis un premier réseau de communication (RES), caractérisé en ce que le terminal esclave (STBsi) comprend un processeur configuré pour réaliser les étapes suivantes :
    1. Réception de segments d’un même contenu (C1) par un terminal maître et un terminal et restitution des segments sur un écran maître (TVm) et un écran esclave (TVsi) , respectivement,
    2. Obtention, en liaison avec un autre terminal, dit terminal maître, d’une première durée de latence précédant la restitution du segment sur l’écran maître (TVm),
    3. Détermination d’un deuxième délai de latence précédant la restitution sur l’écran esclave (TVsi),
    4. Comparaison des durées de latence, et si les durées de latence diffèrent, sélection d’un mode lecture des segments en fonction du résultat de l’étape de comparaison.
  9. Terminal lecteur (STBsi) comprenant une entité de gestion (ENTsi) telle que définie dans la revendication 8.
  10. Programme d'ordinateur apte à être mis en œuvre sur une entité de gestion (ENTsi) telle que définie dans la revendication 8, le programme comprenant des instructions de code qui, lorsqu’il est exécuté par un processeur, réalise les étapes du procédé définies dans la revendication 1.
  11. Support de données sur lequel a été mémorisée au moins une série d’instructions de code de programme pour l’exécution d’un procédé selon la revendication 1.
FR2204658A 2022-05-17 2022-05-17 Gestion de la restitution d’un contenu multimédia sur plusieurs écrans. Pending FR3135857A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR2204658A FR3135857A1 (fr) 2022-05-17 2022-05-17 Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2204658 2022-05-17
FR2204658A FR3135857A1 (fr) 2022-05-17 2022-05-17 Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.

Publications (1)

Publication Number Publication Date
FR3135857A1 true FR3135857A1 (fr) 2023-11-24

Family

ID=82100235

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2204658A Pending FR3135857A1 (fr) 2022-05-17 2022-05-17 Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.

Country Status (1)

Country Link
FR (1) FR3135857A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150120953A1 (en) * 2013-10-31 2015-04-30 At&T Intellectual Property I, Lp Synchronizing media presentation at multiple devices
US20210321159A1 (en) * 2020-04-09 2021-10-14 Caavo Inc System and method for social multi-platform media playback synchronization

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150120953A1 (en) * 2013-10-31 2015-04-30 At&T Intellectual Property I, Lp Synchronizing media presentation at multiple devices
US20210321159A1 (en) * 2020-04-09 2021-10-14 Caavo Inc System and method for social multi-platform media playback synchronization

Similar Documents

Publication Publication Date Title
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
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.
FR3135857A1 (fr) Gestion de la restitution d’un contenu multimédia sur plusieurs écrans.
EP4346216A1 (fr) Gestion de la lecture d&#39;un contenu multimédia
EP4035408A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique sur réseau mobile avec sélection d&#39;un débit d&#39;encodage maximum autorisé en fonction d&#39;un godet de données
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
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
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
WO2023208688A1 (fr) Gestion de la restitution d&#39;un contenu multimédia
FR3054765B1 (fr) Procede pour la lecture sur un equipement d&#39;un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
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
FR3128084A1 (fr) procédé de gestion de la lecture d’un contenu multimédia.
EP3840391A1 (fr) Gestion de la restitution d&#39;un contenu multimédia et d&#39;une interface de navigation sur un écran
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.
EP4297409A1 (fr) Procédé de gestion de la lecture d&#39;un contenu multimédia.
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
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
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.
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.
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d&#39;un contenu numérique en mode économiseur d&#39;é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
EP4184922A1 (fr) Procédé de gestion de l&#39; accès à un contenu multimédia
WO2021209706A1 (fr) Gestion de l&#39;accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d&#39;encodage à débit variable, en fonction d&#39;une charge réseau
WO2024126138A1 (fr) Gestion de gestion de la fourniture d&#39;adresses de segments d&#39;un contenu multimédia
EP4373099A1 (fr) Procédé de gestion de l&#39;accès à une contenu a lecture d&#39;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: 20231124