FR3005820A1 - Procede de gestion de listes de lecture personnalisees du type comprenant un gabarit d'uri et une liste d'identifiants de segments. - Google Patents

Procede de gestion de listes de lecture personnalisees du type comprenant un gabarit d'uri et une liste d'identifiants de segments. Download PDF

Info

Publication number
FR3005820A1
FR3005820A1 FR1354503A FR1354503A FR3005820A1 FR 3005820 A1 FR3005820 A1 FR 3005820A1 FR 1354503 A FR1354503 A FR 1354503A FR 1354503 A FR1354503 A FR 1354503A FR 3005820 A1 FR3005820 A1 FR 3005820A1
Authority
FR
France
Prior art keywords
segment
identifier
content
list
request
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
FR1354503A
Other languages
English (en)
Other versions
FR3005820B1 (fr
Inventor
Alexander Macaulay
Alain Leal
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.)
MK Systems USA Inc
Original Assignee
Envivio France SARL
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 Envivio France SARL filed Critical Envivio France SARL
Priority to FR1354503A priority Critical patent/FR3005820B1/fr
Priority to US14/281,560 priority patent/US9710473B2/en
Publication of FR3005820A1 publication Critical patent/FR3005820A1/fr
Application granted granted Critical
Publication of FR3005820B1 publication Critical patent/FR3005820B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40—Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/43—Querying
    • G06F16/438—Presentation of query results
    • G06F16/4387—Presentation of query results by the use of playlists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2812—Exchanging configuration information on appliance services in a home automation network describing content present in a home automation network, e.g. audio video content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2834—Switching of information between an external network and a home network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L2012/2847—Home automation networks characterised by the type of home appliance used
    • H04L2012/2849—Audio/video appliances

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Un premier dispositif intermédiaire gère une requête de demande de liste venant (1-1) d'un dispositif de lecture et paramétrée avec un identifiant d'un 1er contenu et un identifiant de groupe. Il obtient (1-2, 1-3) une liste de lecture initiale comprenant un 1er gabarit d'URI (pointant vers un 1er serveur et pré-paramétré avec l'identifiant du 1er contenu) et une 1ère liste d'identifiants de segments (chacun permettant, utilisé comme paramètre du 1er gabarit, de générer un URI pointant vers un segment du 1er contenu). Il construit et transmet (1-4 à 1-9) au dispositif de lecture une liste de lecture finale comprenant un 2ème gabarit d'URI (pointant vers un 2nd dispositif intermédiaire - éventuellement confondu avec le 1er - et pré-paramétré avec l'identifiant du 1er contenu et l'identifiant de groupe) et une 2ème liste d'identifiants de segments virtuels (chacun permettant, utilisé comme paramètre du 2ème gabarit, de générer un URI pointant vers un des segments virtuels). Chaque segment virtuel est associé à un segment du 1er contenu ou un segment alternatif.

Description

Procédé de gestion de listes de lecture personnalisées du type comprenant un gabarit d'URI et une liste d'identifiants de segments. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui de la diffusion par streaming (aussi appelée « diffusion directe », « diffusion en flux » ou « lecture en transit ») permettant à un dispositif de lecture (aussi appelé « lecteur multimédia » ; « player device » ou « media player » en anglais) de lire un flux (audio ou vidéo) à mesure qu'il est diffusé. Plus précisément, l'invention concerne une technique de gestion de listes de lecture personnalisées.
L'invention a de nombreuses applications, telles que notamment, mais non exclusivement, l'insertion de publicités et la substitution de programmes. 2. ARRIÈRE-PLAN TECHNOLOGIQUE On oppose généralement la diffusion par streaming à la diffusion par téléchargement de fichiers, qui nécessite de récupérer l'ensemble des données d'un contenu avant de pouvoir l'écouter ou le regarder. Cependant, du point de vue théorique, le streaming est un téléchargement car il y a un échange de données brutes entre un client et un serveur, mais le stockage est provisoire et n'apparaît pas directement sous forme de fichier sur le disque dur du destinataire. La diffusion par streaming est notamment utilisée pour les services de vidéo à la demande (VOD, pour « Video On Demand » en anglais) et la transmission de programmes en direct (« Live streaming » en anglais). On distingue généralement trois types de streaming : - le streaming traditionnel, qui permet une « lecture en continu ». Il n'y a qu'un seul fichier diffusé, contenant plusieurs fois les mêmes informations avec différents niveaux de qualité, et c'est un serveur spécialisé qui se charge de diffuser l'information adaptée (en fonction du débit de la connexion du client et de la bande passante). Les échanges entre serveur et client peuvent utiliser un protocole standard normalisé (par exemple RTP (« Real-Time Transport Protocol ») ou RTSP (« Real Time Streaming Protocol ») ou un protocole propriétaire (par exemple MMS (« Microsoft Media Services », propriétaire Microsoft) ou RTMP (« Real Time Messaging Protocol », propriétaire Adobe Systems)); - le pseudo-streaming (aussi appelé « téléchargement progressif »), qui permet une « lecture en progressif ». Il s'appuie sur le protocole HTTP (« HyperText Transfer Protocol ») et ne nécessite pas de serveur spécialisé (un serveur HTTP standard étant suffisant). Le fichier audio ou vidéo est simplement proposé au téléchargement, et c'est le client qui se charge d'effectuer la lecture du fichier, en commençant avant que le fichier soit complètement téléchargé ; - le streaming adaptatif, qui s'appuie en général sur le protocole HTTP (bien qu'utilisable avec d'autres protocoles de communication client-serveur). Il est basé sur le téléchargement progressif, par le client, de petits segments du contenu (flux multimédia). Ces segments, aussi appelés fragments (ou « chunk » en anglais), ont par exemple une durée comprise entre 2 et 4 secondes. Le streaming adaptatif est donc une adaptation de la deuxième technique de streaming présentée ci-dessus (« téléchargement progressif »). Il est adaptatif en ce sens que chaque segment est choisi, par le client, parmi plusieurs segments ayant le même contenu mais encodés avec des débits différents. Les principaux formats actuellement disponibles pour le streaming adaptatif sont : « HTTP Live Streaming » (HLS), proposé par Apple, « Smooth Streaming » (SS), proposé par Microsoft, « HTTP Dynamic Streaming » (HDS), proposé par Adobe et « Dynamic Adaptative Streaming over HTTP » (DASH, ou MPEG-DASH), proposé par MPEG. Dans la présente description, on considère que par streaming adaptatif, on entend également le cas particulier (bien qu'il ne soit pas « adaptatif » au sens précité) dans lequel il n'existe qu'un seul débit disponible pour chaque segment. On s'intéresse dans la suite de la description (et dans le cadre de la présente invention) aux techniques de diffusion par streaming adaptatif qui s'appuient sur l'utilisation d'une liste de lecture (aussi appelée « playlist », « manifeste », « index » ou « MPD », pour « Media Presentation Description » en anglais).
Une liste de lecture est un fichier qui contient une séquence ordonnée de références à des fichiers média. Typiquement, la référence d'un fichier média est un identifiant uniforme de ressource (URI, pour « Uniform Resource Identifier » en anglais), comme par exemple un localisateur uniforme de ressource (URL, pour « Uniform Resource Locator » en anglais). Les fichiers média ont une durée courte (par exemple entre 1 et 10 secondes) et peuvent être lus en séquence pour construire une présentation média continue, partielle ou complète. Dans le cas du streaming adaptatif, ces fichiers média de courte durée correspondent aux segments ou fragments (« chunk » en anglais) mentionnés plus haut. La liste de lecture et les segments ne sont pas localisés localement sur le dispositif de lecture (player device) mais sur un serveur distant auquel le dispositif de lecture doit envoyer une requête afin d'obtenir la liste de lecture et les segments. Le dispositif de lecture télécharge et analyse la liste de lecture. Ensuite, il télécharge, analyse, décode et restitue les segments référencés dans la liste de lecture, afin de restituer la présentation média (vidéo par exemple). Par exemple, dans la solution proposée par Apple et décrite notamment dans le document intitulé « HTTP Live Streaming Overview », l'architecture du système de diffusion par streaming adaptatif comprend : - une composante de préparation, comprenant un encodeur média, qui délivre un contenu média encodé (par exemple au format MPEG-2 TS), et un segmenteur de flux, qui divise le contenu média encodé en segments (petits fichiers médias de courte durée) et crée également une liste de lecture (« playlist », « index file ») contenant les références des segments (et plus précisément les adresses URL des segments). Le segmenteur peut créer plusieurs listes de lecture pour un même contenu, chaque liste référençant des segments encodés avec un débit différent. Dans une alternative de réalisation, le segmenteur peut créer une unique liste de lecture pour un contenu donné, cette unique liste référençant des segments encodés avec des débits différents. Par exemple, dans le cas décrit plus bas d'une liste de lecture comprenant un gabarit d'URI, ce dernier comprend un identifiant de débit (exemple : http://server/cnn/{bitrate}/{timestamp}). Les segments et les listes de lecture sont sauvegardés au format « .ts » et « .M3U8 » respectivement ; - une composante de distribution, comprenant un serveur qui délivre la ou les listes de lecture, et les segments de chaque liste de lecture, au client (dispositif de lecture), via le protocole HTTP ; - une composante client, comprenant le dispositif de lecture, qui récupère la ou les listes de lecture auprès du serveur. Grâce au contenu de la ou les listes de lecture récupérées, le dispositif de lecture télécharge en séquence les segments (avec le débit souhaité pour chaque segment) et les restitue à l'utilisateur sous la forme d'un flux continu. Ainsi, dans le cas multi-débit, tous les segments de la séquence téléchargée par le dispositif de lecture ne sont pas au même débit. En pratique, un réseau de fourniture de contenus (CDN, pour « Content Delivery Network » en anglais) est mis en oeuvre entre les serveurs et les dispositifs de lecture. Ce réseau CDN étant transparent vis-à-vis des mécanismes décrits ci-dessus et dans la suite de la présente description, il ne sera pas décrit. Dans un seul souci de simplification de la description, on considère ci-après que le dispositif de lecture transmet directement ses requêtes au serveur. On distingue deux types de listes de lecture : - celles qui contiennent directement les références des segments. En recevant la liste de lecture, le dispositif client reçoit l'URI (par exemple sous forme d'URL) de chaque segment. C'est par exemple le cas dans la solution « HTTP Live Streaming » (HLS) d'Apple, avec le fichier de lecture qui contient les adresses URL des segments ; - celles qui ne contiennent pas directement les références des segments, mais contiennent deux informations complémentaires : un gabarit d'URI (par exemple un gabarit d'URL, ou « URL template » en anglais) et une liste d'identifiants de segments (par exemple une liste d'informations d'horodatage (timestamps), une liste d'index, etc). C'est le dispositif de lecture qui reconstruit la référence (par exemple l'URL) de chaque segment en combinant le gabarit et l'identifiant (timestamp) de ce segment. C'est par exemple le cas dans la solution « Smooth Streaming » (SS) de Microsoft, avec une liste de lecture (appelée « client manifest ») qui contient des informations telles que des types de flux, des paramètres, des débits et des informations d'horodatages de segment (timestamps).
Dans le cas de la diffusion d'un contenu en VOD, la liste de lecture contient des informations (références directes ou indirectes) sur tous les segments du contenu. Dans le cas de la diffusion d'un programme en direct (« Live streaming »), ce n'est pas possible : dans la solution HLS d'Apple, la liste de lecture est téléchargée de manière répétée par le client (dispositif de lecture) qui dispose ainsi en permanence d'une liste mise à jour des derniers segments disponibles ; dans la solution SS de Microsoft, chaque segment contient des informations (informations de chaînage) permettant au client d'accéder au segment suivant (ou à quelques segments suivants), donc aucun téléchargement de mise à jour de la liste de lecture n'est nécessaire. Il existe plusieurs applications qui nécessitent une adaptation (i.e. une personnalisation) du contenu de la liste de lecture à chaque utilisateur (dispositif de lecture), notamment : - l'insertion de publicités (« Ad insertion ») : le contenu final lu par le dispositif de lecture comprend des segments de publicités qui sont introduits entre certains segments du contenu initial et/ou à la place de certains segments du contenu initial. Un serveur de décision pour les publicités (ADS, pour « Ad Decision Server » en anglais) peut être utilisé pour décider quelle publicité insérer pour chaque client (par exemple en fonction de la zone géographique dans laquelle il se trouve). Les segments de publicités peuvent être fournis par un serveur de publicités (« Ad Server ») ; et - la substitution de programmes («Program substitution ») : dans certaines situations, des droits sur les contenus n'autorisent pas la diffusion d'un programme dans une région, et il est donc nécessaire de fournir au dispositif de lecture un programme de substitution. Par exemple, un événement sportif dans un stade peut être diffusé au niveau national mais doit, au niveau local (par exemple dans la ville où il a lieu), être bloqué et remplacé par un autre contenu pour ne pas faire baisser la fréquentation du stade. Pour effectuer une telle adaptation du contenu de la liste de lecture, un dispositif intermédiaire, aussi appelé « dispositif de manipulation de liste de lecture » (« playlist manipulator » ou « splicer » en anglais), agit entre le serveur (fournissant la liste de lecture initiale et les segments) et le dispositif de lecture. Dans le cas où la liste de lecture contient directement les références des segments (cas de la solution HLS d'Apple, avec une liste de lecture comprenant une liste d'URL de segments), le dispositif intermédiaire modifie la liste de lecture en introduisant des URL de segments de publicité. Ceci est fait en fonction d'informations fournies par le dispositif de lecture (dans la requête de demande de liste) et relatives par exemple à l'utilisateur (localisation géographique, sexe, âge, etc.). Dans la solution HLS, pour un contenu en VOD, le dispositif intermédiaire insère par exemple des références (URL) de segments de publicités, au début de la liste de lecture retournée au dispositif de lecture (ou bien à un autre endroit de la liste de lecture, indiquée par une information d'opportunité de placement (P01, pour « Placement Opportunity Information » en anglais)). Ces références pointent vers des segments d'une ou plusieurs publicités, ciblées par exemple en fonction de la zone géographique de l'utilisateur du dispositif de lecture.
Dans la solution HLS, pour un contenu en direct (« live streaming »), le segmenteur insère par exemple des marqueurs spécifiques qui sont associés à certaines références de segments, dans la liste de lecture, et permettent d'identifier le début et la fin de l'insertion de segments de publicité dans le contenu d'origine. Le dispositif intermédiaire peut ensuite remplacer les références de segments préalablement marquées, par des références de segments de publicité. Ces dernières pointent vers des segments d'une ou plusieurs publicités, ciblées par exemple en fonction de la zone géographique de l'utilisateur du dispositif de lecture. Dans le cas où la liste de lecture ne contient pas directement les références des segments (cas de la solution SS de Microsoft, avec une liste de lecture comprenant un gabarit d'URL et une liste d'identifiants de segments), le dispositif intermédiaire ne peut pas introduire directement dans la liste de lecture des modifications visant à introduire des références vers des segments de publicité localisés sur un serveur différent de celui stockant les segments du contenu demandé par l'utilisateur (contenu VOD ou programme en direct). En effet, la liste de lecture ne permet au dispositif de lecture de générer que des références (URL) pointant vers l'emplacement qui est inscrit ("hard-coded") dans le gabarit (URL template). Pour cette raison, dans les implémentations connues, l'insertion de publicité dans une liste de lecture basée sur un gabarit (i.e. comprenant un gabarit et une liste d'identifiants de segments) est réalisée en ajoutant des informations additionnelles dans la liste de lecture, indiquant qu'une coupure publicitaire se produit à un certain point temporel. Ainsi, le dispositif de lecture peut effectuer une logique d'insertion de publicité, en contactant un serveur de publicités qui lui retourne des segments de publicité à lire pendant la coupure publicitaire, à la place des segments du contenu d'origine. Un inconvénient de cette dernière technique est que c'est le dispositif de lecture qui effectue, au final, la personnalisation du contenu. Pour gérer ce mécanisme, le dispositif de lecture doit donc être adapté (« customized player »). Ceci le rend plus coûteux à déployer, puisque cela requiert un développement particulier et des charges de maintenance. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier cet inconvénient de l'état de la technique. Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique permettant, dans le cas où la liste de lecture ne contient pas directement les références des segments (mais contient un gabarit d'URI et une liste d'identifiants de segments), d'effectuer une personnalisation de la liste de lecture (et donc du contenu lu par le dispositif de lecture), sans que cela nécessite que le dispositif de lecture soit adapté pour effectuer lui-même la personnalisation du contenu. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit compatible avec le mécanisme (discuté plus haut) de chaînage de segments, dans le cas de la diffusion d'un programme en direct (« Live streaming »).
Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui s'appuie sur un protocole de communication client-serveur simple, par exemple le protocole HTTP. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit simple à mettre en oeuvre et peu coûteuse. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion de listes de lecture personnalisées du type comprenant un gabarit d'identifiant uniforme de ressource et une liste d'identifiants de segments. Ce procédé comprend une première phase de gestion, par un premier dispositif intermédiaire, d'une requête de demande de liste, transmise par un dispositif de lecture et paramétrée avec un identifiant d'un premier contenu, et un identifiant de groupe définissant un groupe d'au moins un utilisateur ou au moins un dispositif de lecture, la première phase comprenant les étapes suivantes : a) obtention d'une liste de lecture initiale comprenant d'une part un premier gabarit d'identifiant uniforme de ressource pointant vers un premier serveur et pré-paramétré avec l'identifiant du premier contenu, et d'autre part une première liste d'identifiants de segments, chaque identifiant de segment de la première liste permettant, quand il est utilisé comme paramètre du premier gabarit, de générer un identifiant uniforme de ressource pointant vers un segment du premier contenu ; b) construction d'une liste de lecture finale, comprenant d'une part un deuxième gabarit d'identifiant uniforme de ressource pointant vers un second dispositif intermédiaire, confondu ou non avec le premier dispositif intermédiaire, et pré- paramétré avec l'identifiant du premier contenu et l'identifiant de groupe, et d'autre part une deuxième liste d'identifiants de segments virtuels, chaque identifiant de segment virtuel permettant, quand il est utilisé comme paramètre du deuxième gabarit, de générer un identifiant uniforme de ressources pointant vers un desdits segments virtuels, chaque segment virtuel étant associé soit à un segment du premier contenu soit à un segment alternatif d'un ensemble de segments alternatifs compris dans au moins un contenu alternatif ; c) transmission de la liste de lecture finale au dispositif de lecture. Ce mode de réalisation particulier de l'invention repose sur une approche tout à fait nouvelle et inventive consistant, pour le premier dispositif intermédiaire (« dispositif de manipulation de liste de lecture », aussi appelé « playlist manipulator » ou « splicer » en anglais), à construire une liste de lecture finale permettant au dispositif de lecture de générer des URI pointant vers des segments virtuels gérés par le second dispositif intermédiaire (qui est soit distinct soit confondu avec le premier dispositif intermédiaire). Dans une deuxième phase décrite ci-après, le dispositif de lecture utilise la liste de lecture finale pour générer, pour chaque segment virtuel dont la liste de lecture finale comprend un identifiant, une requête de demande de segment pointant vers le second dispositif intermédiaire et paramétrée avec l'identifiant de ce segment virtuel. Grâce à ce mécanisme, c'est le premier dispositif intermédiaire qui personnalise la liste de lecture initiale (malgré le fait que celle-ci est du type comprenant un gabarit d'URI et une liste d'identifiants de segments). Le dispositif de lecture ne nécessite aucune adaptation (il n'effectue pas lui-même la personnalisation de la liste de lecture initiale, ni la personnalisation du contenu). Il suffit par exemple que le dispositif de lecture soit conforme au protocole HTTP. Comme expliqué plus haut, la présente invention se place dans le cadre du streaming adaptatif, y compris : - le cas le plus fréquent, dans lequel il existe plusieurs débits disponibles pour chaque segment (avec soit plusieurs listes de lecture associées chacune à un débit distinct, soit une liste de lecture unique dont le gabarit d'URI comprend un identifiant de débit (exemple: http://server/cnn/{bitrate}/{timesta m p})), - mais aussi le cas particulier, dans lequel il n'existe qu'un seul débit disponible pour chaque segment (donc une seule liste de lecture). Dans un souci de simplification de l'exposé de l'invention, l'aspect débit n'est pas discuté, du fait qu'il n'a pas d'impact sur le mécanisme proposé : - dans la première phase : o dans le cas multi-débit avec une liste de lecture distincte pour chaque débit : on suppose que la liste de lecture finale, et donc également la liste de lecture initiale, sont associées à un débit donné. Si plusieurs débits sont possibles, il suffit d'appliquer le procédé proposé, pour chaque débit possible (de sorte à générer une liste de lecture finale pour chaque débit possible); o dans le cas multi-débit avec une liste de lecture unique pour tous les débits : on suppose que la liste de lecture finale, et donc également la liste de lecture initiale, possèdent un gabarit d'URI comprenant un identifiant de débit (« bit rate identifier »). - dans la deuxième phase : o dans le cas multi-débit avec une liste de lecture distincte pour chaque débit :on suppose que la requête de demande de segment est spécifique à un débit donné (parmi éventuellement plusieurs débits possibles); o dans le cas multi-débit avec une liste de lecture unique pour tous les débits : on suppose que la requête de demande de segment est paramétrée avec une valeur particulière de l'identifiant de débit (correspondant à l'un des débits possibles).
Selon une caractéristique particulière, le premier contenu appartient au groupe comprenant des contenus de vidéo à la demande et des contenus diffusés en direct. Selon une caractéristique particulière, l'étape b) comprend une étape de stockage d'informations permettant, pour chaque identifiant de segment virtuel de la deuxième liste, qui identifie un segment virtuel associé à un segment donné du premier contenu ou un segment donné dudit au moins un contenu alternatif : d'obtenir un identifiant uniforme de ressource pointant vers ledit segment donné, à partir d'un n-uplet comprenant ledit identifiant de segment virtuel de la deuxième liste, l'identifiant de groupe et l'identifiant du premier contenu.
Les informations stockées sont utilisées ultérieurement, lors de la seconde phase discutée ci-après. Dans une variante, cette étape de stockage n'est pas effectuée (l'association est alors déterminée à nouveau lors de la seconde phase discutée ci-après). Dans une première mise en oeuvre particulière de la première phase (application « insertion de publicités » ou application « substitution de programmes »), la liste de lecture initiale comprend en outre au moins une information de changement, relative à la possibilité d'insérer un ou plusieurs segments alternatifs dans le premier contenu ou de remplacer un ou plusieurs segments du premier contenu par un ou plusieurs segments alternatifs. L'étape b) comprend les étapes suivantes : - en fonction dudit identifiant de groupe et pour chaque information de changement, obtention d'une liste de lecture d'un contenu alternatif donné, comprenant d'une part un troisième gabarit d'identifiant uniforme de ressource, pointant vers un serveur de contenus alternatifs confondu ou non avec le premier serveur, et pré-paramétré avec l'identifiant dudit contenu alternatif donné, et d'autre part une troisième liste d'identifiants de segments alternatifs dudit contenu alternatif donné ; - création de ladite deuxième liste d'identifiants de segment virtuels, en combinant la première liste d'identifiants de segments avec la ou chaque troisième liste d'identifiants de segments alternatifs, en fonction de la ou chaque information de changement.
Selon une caractéristique particulière, l'étape obtention d'une liste de lecture d'un contenu alternatif donné, en fonction dudit identifiant de groupe et pour chaque information de changement, comprend les étapes suivantes : - obtention, par un mécanisme de décision interne au premier dispositif intermédiaire ou auprès d'un serveur de décision, d'un identifiant de contenu alternatif, en fonction de l'identifiant de groupe et d'un identifiant de ladite information de changement ; - obtention de ladite liste de lecture du alternatif donné, possédant l'identifiant de contenu alternatif obtenu. Selon une caractéristique particulière, chaque contenu alternatif appartient au groupe comprenant : des contenus vidéos, notamment des contenus publicitaires ; et des contenus diffusés en direct.
Dans un premier cas particulier (application « insertion de publicités ») de la première mise en oeuvre, ladite au moins une information de changement est une opportunité de placement, indiquant une possibilité de placement d'un contenu publicitaire dans le premier contenu.
Dans un second cas particulier (application « substitution de programmes ») de la première mise en oeuvre, ladite au moins une information de changement est une information de blocage, indiquant une période de blocage pendant laquelle le premier contenu doit être remplacé par un contenu alternatif. Dans une deuxième mise en oeuvre particulière de la première phase (application « marquage » ou « watermarking » en anglais), l'identifiant de chaque contenu alternatif est identique à l'identifiant du premier contenu. Le premier contenu et chaque contenu alternatif comprennent des segments identiques, exceptée la présence, dans chaque segment de même rang dudit premier contenu et dudit contenu alternatif, d'un tatouage numérique distinct. Chaque contenu alternatif est associé à une autre liste de lecture distincte, comprenant d'une part un autre gabarit d'identifiant uniforme de ressource et d'autre part une autre liste d'identifiants de segments alternatifs dudit contenu alternatif. Chaque autre liste de lecture se distingue de la liste de lecture initiale : parce que le premier gabarit d'identifiant uniforme de ressources est pré- paramétré avec un identifiant de variante de contenu qui est différent d'un autre identifiant de variante de contenu avec lequel est pré-paramétré ledit autre gabarit d'identifiant uniforme de ressources ; et/ou parce que la première liste d'identifiants de segments est différente de ladite autre liste d'identifiants de segments.
Selon une caractéristique particulière, le procédé comprend une deuxième phase de gestion, par le second dispositif intermédiaire, d'une requête de demande de segment, transmise par le dispositif de lecture et paramétrée avec l'identifiant du premier contenu, l'identifiant de groupe, et l'un desdits identifiants de segments virtuels, la deuxième phase comprenant les étapes suivantes : i) identification d'un segment en fonction des paramètres de ladite requête de demande de segment, le segment identifié étant soit un segment dudit premier contenu soit un segment alternatif dudit au moins un contenu alternatif ; ii) détermination d'un identifiant uniforme de ressources pointant vers le segment identifié ; et iii-a) transmission au dispositif de lecture, de l'identifiant uniforme de ressources déterminé ; ou iii-b) transmission au dispositif de lecture, du segment pointé par l'identifiant uniforme de ressources déterminé.
Selon une caractéristique particulière, dans l'étape i), le second dispositif intermédiaire utilise les informations préalablement stockées dans l'étape de stockage. Selon une variante, dans l'étape i), le second dispositif intermédiaire exécute un algorithme déterministe, qui prend en entrée l'identifiant du premier contenu, l'identifiant de groupe et l'identifiant de segment virtuel avec lesquels est paramétrée la requête de demande de segment, et qui génère en sortie le segment identifié. Avantageusement, dans le cas de l'application « insertion de publicités » ou de l'application « substitution de programmes », la deuxième phase comprend en outre une étape d'obtention d'informations de chaînage décrivant au moins un segment virtuel qui suit, dans la deuxième liste d'identifiants de segments virtuels, le segment virtuel pointé par ladite requête de demande de segment. L'étape iii-a) est précédée d'une étape de copie, par insertion ou remplacement, desdites informations de chaînage dans l'identifiant uniforme de ressources pointant vers le segment identifié. En réponse à une requête de demande de segment transmise par le dispositif de lecture et paramétrée avec l'identifiant uniforme de ressources transmis par le second dispositif intermédiaire, le premier serveur ou le serveur de contenus alternatifs copie, par insertion ou remplacement, lesdites informations de chaînage dans le segment identifié, avant de le transmettre au dispositif de lecture. Selon une caractéristique particulière, la deuxième phase comprend en outre une étape d'obtention d'informations de chaînage décrivant au moins un segment virtuel qui suit, dans la deuxième liste d'identifiants de segments virtuels, le segment virtuel pointé par ladite requête de demande de segment. L'étape iii-b) est précédée d'une étape de copie, par insertion ou remplacement, desdites informations de chaînage dans le segment pointé par l'identifiant uniforme de ressources déterminé. Avantageusement, dans le cas de l'application « marquage» (« watermarking »), dans l'étape i), le second dispositif intermédiaire exécute un algorithme déterministe, qui prend en entrée l'identifiant du premier contenu, l'identifiant de groupe et l'identifiant du segment virtuel pointé, et qui génère en sortie une information indiquant si le segment associé au segment virtuel pointé par ladite requête de demande de segment est un segment du premier contenu ou un segment alternatif.
Dans un autre mode de réalisation de l'invention, il est proposé un produit programme d'ordinateur qui comprend des instructions de code de programme pour la mise en oeuvre du procédé précité (dans l'un quelconque de ses différents modes de réalisation), lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation de l'invention, il est proposé un médium de stockage lisible par ordinateur et non transitoire, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé précité (dans l'un quelconque de ses différents modes de réalisation). Dans un autre mode de réalisation de l'invention, il est proposé un premier dispositif intermédiaire pour la gestion de listes de lecture personnalisées du type comprenant un gabarit d'identifiant uniforme de ressource et une liste d'identifiants de segments, caractérisé en ce qu'il comprend des moyens de gestion d'une requête de demande de liste, transmise par un dispositif de lecture et paramétrée avec un identifiant d'un premier contenu, et un identifiant de groupe définissant un groupe d'au moins un utilisateur ou au moins un dispositif de lecture, les moyens de gestion comprenant : - des moyens d'obtention d'une liste de lecture initiale comprenant d'une part un premier gabarit d'identifiant uniforme de ressource pointant vers un premier serveur et pré-paramétré avec l'identifiant du premier contenu, et d'autre part une première liste d'identifiants de segments, chaque identifiant de segment de la première liste permettant, quand il est utilisé comme paramètre du premier gabarit, de générer un identifiant uniforme de ressource pointant vers un segment du premier contenu ; des moyens de construction d'une liste de lecture finale, comprenant d'une part un deuxième gabarit d'identifiant uniforme de ressource pointant vers un second dispositif intermédiaire, confondu ou non avec le premier dispositif intermédiaire, et pré-paramétré avec l'identifiant du premier contenu et l'identifiant de groupe, et d'autre part une deuxième liste d'identifiants de segments virtuels, chaque identifiant de segment virtuel permettant, quand il est utilisé comme paramètre du deuxième gabarit, de générer un identifiant uniforme de ressources pointant vers un desdits segments virtuels, chaque segment virtuel étant associé soit à un segment du premier contenu soit à un segment alternatif d'un ensemble de segments alternatifs compris dans au moins un contenu alternatif ; des moyens de transmission de la liste de lecture finale au dispositif de lecture.
Dans un autre mode de réalisation de l'invention, il est proposé un second dispositif intermédiaire pour la gestion de listes de lecture personnalisées du type comprenant un gabarit d'identifiant uniforme de ressource et une liste d'identifiants de segments, caractérisé en ce qu'il comprend des moyens de gestion d'une requête de demande de segment, transmise par un dispositif de lecture et paramétrée avec un identifiant d'un premier contenu, un identifiant de groupe définissant un groupe d'au moins un utilisateur ou au moins un dispositif de lecture, et un identifiant de segment virtuel, les moyens de gestion comprenant : des moyens d'identification d'un segment en fonction des paramètres de ladite requête de demande de segment, le segment identifié étant soit un segment dudit premier contenu soit un segment alternatif dudit au moins un contenu alternatif ; des moyens de détermination d'un identifiant uniforme de ressources pointant vers le segment identifié ; et des moyens de transmission au dispositif de lecture, de l'identifiant uniforme de ressources déterminé ; ou des moyens de transmission au dispositif de lecture, du segment pointé par l'identifiant uniforme de ressources déterminé. Avantageusement, le premier dispositif intermédiaire et le second dispositif intermédiaire comprennent des moyens de mise en oeuvre des étapes qu'ils effectuent dans le procédé tel que décrit précédemment, dans l'un quelconque de ses différents modes de réalisation. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - les figures 1 et 2 présentent chacune un diagramme de séquence illustrant, de manière générique (figure 1) ou à travers un exemple (figure 2), la gestion d'une requête HTTP GET Playlist, dans une application d'insertion de publicités dans un contenu VOD, selon un mode de réalisation particulier de l'invention ; - les figures 3 et 4 présentent chacune un diagramme de séquence illustrant, de manière générique (figure 3) ou à travers un exemple (figure 4), la gestion d'une requête HTTP GET Segment, dans une application d'insertion de publicités dans un contenu VOD, selon un mode de réalisation particulier de l'invention, en mode « Redirect » ; - les figures 5 et 6 présentent chacune un diagramme de séquence illustrant, de manière générique (figure 5) ou à travers un exemple (figure 4), la gestion d'une requête HTTP GET Segment, dans une application d'insertion de publicités dans un contenu VOD, selon un mode de réalisation particulier de l'invention, en mode « Proxy »; - les figures 7 et 8 présentent chacune un diagramme de séquence illustrant, de manière générique (figure 7) ou à travers un exemple (figure 8), la gestion d'une requête HTTP GET Playlist, dans une application d'insertion de publicités dans un contenu de direct (Live), selon un mode de réalisation particulier de l'invention ; - les figures 9 et 10 présentent chacune un diagramme de séquence illustrant, de manière générique (figure 9) ou à travers un exemple (figure 10), la gestion d'une requête HTTP GET Segment, dans une application d'insertion de publicités dans un contenu de direct (Live), selon un mode de réalisation particulier de l'invention, en mode « Redirect » ; - les figures 11 et 12 présentent chacune un diagramme de séquence illustrant, de manière générique (figure 11) ou à travers un exemple (figure 12), la gestion d'une requête HTTP GET Segment, dans une application d'insertion de publicités dans un contenu de direct (Live), selon un mode de réalisation particulier de l'invention, en mode « Proxy » ; - les figures 13 et 14 présentent chacune un diagramme de séquence illustrant, de manière générique (figure 13) ou à travers un exemple (figure 14), la gestion d'une requête HTTP GET Playlist, dans une application de marquage (Watermarking), selon un mode de réalisation particulier de l'invention ; - les figures 15 et 16 présentent chacune un diagramme de séquence illustrant, de manière générique (figure 15) ou à travers un exemple (figure 16), la gestion d'une requête HTTP GET Segment, dans une application de marquage (Watermarking), selon un mode de réalisation particulier de l'invention, en mode « Redirect » ; - la figure 17 présente la structure du dispositif intermédiaire selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. 6.1 Application d'insertion de publicités dans un contenu VOD 6.1.1 Gestion d'une requête HTTP GET Playlist (fig. 1 et 2) On présente maintenant, de manière générique (avec la figure 1) puis à travers un exemple (avec la figure 2), la gestion d'une requête HTTP GET Playlist, dans une application d'insertion de publicités dans un contenu VOD, selon un mode de réalisation particulier de l'invention. Chacune des figures 1 et 2 présente un diagramme de séquence impliquant les entités suivantes : - un dispositif de lecture (« player » en anglais), qui émet des requêtes pour obtenir des listes de lecture (requêtes HTTP GET Playlist) et des requêtes pour obtenir des segments (requêtes HTTP GET Segment). Il lit les listes de lecture et les segments obtenus ; - un dispositif intermédiaire (« splicer » en anglais), qui agit comme un intermédiaire entre le dispositif de lecture et le dispositif intermédiaire pour certaines requêtes, notamment celles relatives aux listes de lecture et aux segments. Dans une variante (non illustrée), ce dispositif intermédiaire peut être remplacé par un premier dispositif intermédiaire, en charge notamment de la gestion des requêtes de demande de liste (HTTP GET Playlist), et un second dispositif intermédiaire, en charge notamment de la gestion des requêtes de demande de segment (HTTP GET Segment); - un serveur VOD (« VOD server » en anglais), qui reçoit des segments de contenus résultant d'une segmentation de contenus effectuée par un segmenteur (lui-même placé en aval d'un encodeur). Il met les listes de lecture et les segments à disposition du dispositif de lecture et du dispositif intermédiaire. Dans une variante (non illustrée), ce serveur VOD peut être remplacé par un premier serveur VOD, en charge notamment de la gestion des requêtes de demande de liste (HTTP GET Playlist), et un second serveur VOD, en charge notamment de la gestion des requêtes de demande de segment (HTTP GET Segment); - un serveur de publicités (« Ad server » en anglais), qui met des listes de lecture et des segments relatifs à des contenus publicitaires, à disposition du dispositif de lecture et du dispositif intermédiaire. Dans une variante (non illustrée), ce serveur de publicités peut être remplacé par un premier serveur de publicités, en charge notamment de la gestion des requêtes de demande de liste (HTTP GET Playlist), et un second de publicités, en charge notamment de la gestion des requêtes de demande de segment (HTTP GET Segment) ; et - un serveur de décision pour les publicités (ADS, pour « Ad Decision Server » en anglais), qui fournit, en fonction d'identifiants de zone géographique ou d'identifiants d'utilisateur, des informations d'opportunité de placement de coupures publicitaires (« ad break placement opportunity information » en anglais). Un réseau de fourniture de contenus (CDN, pour « Content Delivery Network » en anglais) peut être mis en oeuvre entre les entités précitées. Ce réseau CDN étant transparent vis-à-vis des mécanismes décrits ci-après, il n'est pas discuté par la suite. Dans un seul souci de simplification de la description, on considère donc ci-après que le dispositif de lecture transmet directement ses requêtes HTTP au dispositif intermédiaire, au serveur VOD et au serveur de publicités.
On présente maintenant les étapes du cas générique de la figure 1. Dans une étape 1-1, le dispositif de lecture transmet au dispositif intermédiaire une requête de demande de liste de lecture « HTTP GET playlist (asset ID, zone ID) », paramétrée avec un identifiant du contenu VOD souhaité (« asset ID ») et un identifiant de groupe comme par exemple un identifiant de zone géographique associé au dispositif de lecture (« zone ID »). Ce dernier paramètre permet de décider quel(s) contenu(s) publicitaire(s) seront fournis au dispositif de lecture. Dans une étape 1-2, le dispositif intermédiaire transmet au serveur VOD une requête de demande de liste de lecture « HTTP GET playlist (asset ID) », paramétrée avec l'identifiant du contenu VOD souhaité (« asset ID »).
Dans une étape 1-3, le serveur VOD retourne au dispositif intermédiaire la liste de lecture pour le contenu VOD souhaité (ou « liste de lecture initiale »), avec des informations d'opportunité de placement (PO, pour « Placement Opportunities » en anglais). La liste de lecture initiale comprend d'une part un premier gabarit d'URI pointant vers le serveur VOD et pré-paramétré avec l'identifiant du contenu VOD (« asset ID »), et d'autre part une première liste d'identifiants de segments VOD. Chaque identifiant de segment VOD de la première liste permet, quand il est utilisé comme paramètre du premier gabarit, de générer un URI pointant vers un segment VOD (dudit contenu VOD). Pour chaque information d'opportunité de placement définie par un identifiant (« PO ID »), le procédé comprend les étapes suivantes : - dans une étape 1-4, le dispositif intermédiaire interroge le serveur ADS, en lui fournissant l'identifiant d'opportunité de placement (« PO ID ») et l'identifiant de zone géographique « zone ID », pour connaître l'identifiant du contenu publicitaire (« ad asset ID ») à insérer pour cette zone géographique ; - dans une étape 1-5, le serveur ADS retourne au dispositif intermédiaire l'identifiant du contenu publicitaire (« ad asset ID »); - dans une étape 1-6, le dispositif intermédiaire transmet au serveur de publicités une requête de demande de liste de lecture « HTTP GET playlist (ad asset ID) », paramétrée avec l'identifiant du contenu publicitaire (« ad asset ID »); - dans une étape 1-7, le serveur de publicités retourne au dispositif intermédiaire la liste de lecture pour le contenu publicitaire. Chaque liste de lecture d'un contenu publicitaire comprend d'une part un troisième gabarit d'URI pointant vers le serveur publicitaire et pré-paramétré avec l'identifiant du contenu publicitaire, et d'autre part une troisième liste d'identifiants de segments publicitaires. Chaque identifiant de segment publicitaire permet, quand il est utilisé comme paramètre du troisième gabarit, de générer un URI pointant vers un segment publicitaire (dudit contenu publicitaire). Puis, dans une étape 1-8, le dispositif intermédiaire génère une liste de lecture finale, en combinant la liste de lecture pour le contenu VOD souhaité (cf étape 1-3) (ou « liste de lecture initiale ») et les listes de lecture pour les contenus publicitaires (cf étape 1-7), en fonction des informations d'opportunité de placement. La liste de lecture finale comprend d'une part un deuxième gabarit d'URI pointant vers le dispositif intermédiaire et pré-paramétré avec l'identifiant du contenu VOD et l'identifiant de zone géographique, et d'autre part une deuxième liste d'identifiants de segments virtuels. La deuxième liste d'identifiants de segments virtuels est obtenue en combinant la première liste d'identifiants de segments VOD (comprise dans la liste de lecture initiale) et la ou les troisièmes listes d'identifiants de segments publicitaires (comprise chacune dans une liste de lecture d'un contenu publicitaire). Chaque identifiant de segment virtuels (« Segment ID ») de la deuxième liste permet, quand il est utilisé comme paramètre du deuxième gabarit, de générer un URI pointant vers un des segments virtuels associé soit à un segment VOD, soit à un segment publicitaire. Dans l'étape 1-8, le dispositif intermédiaire effectue en outre le stockage d'informations relatives aux associations entre segments virtuels d'une part et segments VOD / segments publicitaires d'autre part. Ces informations d'associations seront utilisées ultérieurement par le dispositif intermédiaire, dans le cadre de la gestion des requêtes « HTTP GET Segment ». Plus précisément, pour chaque identifiant de segment virtuel de la deuxième liste (qui identifie un segment virtuel associé à un segment donné : segment VOD ou segment publicitaire), le dispositif intermédiaire stocke un couple associant : - un n-uplet comprenant cet identifiant de segment virtuel (« Segment ID »), l'identifiant de zone géographique (« Zone ID ») et l'identifiant du contenu VOD (« asset ID ») ; et - des informations permettant d'obtenir un URI pointant vers le segment donné, et comprenant par exemple : o si le segment donné est un segment VOD : le premier gabarit d'URI pointant vers le serveur VOD (et pré-paramétré avec l'identifiant du contenu VOD (« asset ID »)), et l'identifia nt de ce segment VOD ; o si le segment donné est un segment publicitaire : le troisième gabarit d'URI pointant vers le serveur publicitaire (et préparamétré avec l'identifiant du contenu publicitaire (« ad asset ID »)), et l'identifiant de ce segment publicitaire.
Dans une variante (« stockage partiel »), le dispositif intermédiaire ne stocke pas tous les couples précités, mais uniquement des informations permettant, dans la phase ultérieure de gestion d'une requête de demande de segment (requête HTTP GET Segment), pour chaque identifiant de segment virtuel de la deuxième liste : - d'obtenir l'URI du segment souhaité (segment VOD ou segment publicitaire), à partir d'un n-uplet comprenant l'identifiant de segment virtuel (Segment ID), l'identifiant de zone géographique (Zone ID) et l'identifiant du premier contenu (asset ID). Dans une autre variante (« sans stockage »), le stockage d'informations n'est pas effectué. Dans la phase ultérieure de gestion d'une requête de demande de segment (requête HTTP GET Segment), le dispositif intermédiaire devra effectuer à nouveau certaines action, comme par exemple obtenir à nouveau la liste de lecture initiale et la ou les listes de lecture pour le(s) contenu(s) publicitaire(s), puis les combiner pour obtenir la liste de lecture finale, à partir de laquelle il pourra retrouver les associations entre segments virtuels d'une part et segments VOD / segments publicitaires d'autre part. Dans une étape 1-9, le dispositif intermédiaire transmet la liste de lecture finale au dispositif de lecture. On présente maintenant les étapes de l'exemple de la figure 2.
Dans cet exemple, l'identifiant du contenu VOD (« asset ID ») est « titanic » et l'identifiant de zone géographique (« Zone ID ») est « Z23 ». Les étapes 2-1 à 2-3 correspondent aux étapes 1-1 à 1-3 de la figure 1. Le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de liste de lecture suivante (commande GET suivie d'une URI) : « GET http://splicer/titanic/manifest?zone=Z23 ». Les étapes 2-4 à 2-7 correspondent aux étapes 1-4 à 1-7 de la figure 1, pour une première itération de la boucle, avec l'opportunité de placement P59. Les étapes 2-8 à 2-11 correspondent aux étapes 1-4 à 1-7 de la figure 1, pour une deuxième itération de la boucle, avec l'opportunité de placement P67.
Les étapes 2-12 et 2-13 correspondent aux étapes 1-8 et 1-9 de la figure 1. Dans l'étape 2-3, la première liste d'identifiants de segments VOD (comprise dans la liste de lecture initiale) est : 0, 2, 4, 6, 8, qui sont des informations d'horodatage (« timestamps ») indiquant chacune une durée de 2s. La liste de lecture initiale comprend deux informations d'opportunité de placement (dont les identifiants sont « P59 » et « P67 ») : l'une pour une insertion d'un premier contenu publicitaire de durée 6 secondes au début du contenu VOD, l'autre pour le remplacement (entre t=4 et t=8) d'une partie du contenu VOD par un deuxième contenu publicitaire. Les étapes 2-4 à 2-7 permettent d'informer le dispositif intermédiaire que la première information d'opportunité de placement (« P59 ») concerne un premier contenu publicitaire (« A64 ») comprenant trois segments de publicité de durée 2 secondes chacun. Pour ce premier contenu publicitaire, la liste d'identifiants de segments publicitaires est : 0, 2, 4 (informations d'horodatage indiquant chacune une durée de 2s). Les étapes 2-8 à 2-11 permettent d'informer le dispositif intermédiaire que la deuxième information d'opportunité de placement (« P67 ») concerne un deuxième contenu publicitaire (« A78 ») comprenant deux segments de publicité de durée 2 secondes chacun. Pour ce deuxième contenu publicitaire, la liste d'identifiants de segments publicitaires est : 0, 2 (informations d'horodatage indiquant chacune une durée de 2s).
Dans l'étape 2-12, la deuxième liste d'identifiants de segments virtuels (comprise dans la liste de lecture finale) est : 0, 2, 4, 6, 8, 10, 12, 14 (informations d'horodatage indiquant chacune une durée de 2s), avec les correspondances (associations) suivantes : - les identifiants de segments virtuels 0, 2, 4 correspondent aux identifiants de segments publicitaires 0, 2, 4 de la liste d'identifiants pour le premier contenu publicitaire (Ad asset #1) ; - les identifiants de segments virtuels 10, 12 correspondent aux identifiants de segments publicitaires 0, 2 de la liste d'identifiants pour le deuxième contenu publicitaire (Ad asset #2) ; - les identifiants de segments virtuels 6, 8, 14 correspondent aux identifiants de segments VOD 0, 2, 8 de la liste d'identifiants pour le contenu VOD (VOD asset). Avec le modèle d'écriture de chaque ligne suivant : (« identifiant de segments virtuels » = « identifiant de contenu » I « identifiant de segment (VOD ou publicitaire) »), les correspondances (« mapping ») précitées peuvent également être synthétisées comme suit : 0 = Ad asset #1 I 0 2 = Ad asset #1 I 2 4 = Ad asset #1 I 4 6 = VOD asset I 0 8 = VOD asset 12 = Ad asset #2 I 0 12 = Ad asset #2 I 2 14 = VOD asset I 8 Dans l'étape 2-13, le dispositif intermédiaire retourne au dispositif de lecture la 10 liste de lecture finale comprenant : - le gabarit d'URI: http://splicer/titanic/{timestamp}?zone=Z23; et - la liste d'identifiants de segments virtuels 0,2,4,6,8,10,12,14. 6.1.2 Gestion d'une requête HTTP GET Segment en mode « Redirect » (fig. 3 et 4) On présente maintenant, de manière générique (avec la figure 3) puis à travers un exemple (avec la figure 4), la gestion d'une requête HTTP GET segment, dans une application d'insertion de publicités dans un contenu VOD, selon un mode de réalisation particulier de l'invention, en mode « Redirect ».
On présente maintenant les étapes du cas générique de la figure 3. Dans une étape 3-1, le dispositif de lecture transmet au dispositif intermédiaire une requête de demande de segment « HTTP GET segment (asset ID, zone ID, segment ID) », paramétrée avec un n-uplet comprenant l'identifiant du contenu VOD souhaité (« asset ID »), l'identifiant de zone géographique (« zone ID ») et l'identifiant d'un des segments virtuels (« segment ID », qui est une information d'horodatage (« timestamp ») dans l'exemple présenté plus haut) de la liste de lecture finale que le dispositif intermédiaire lui a préalablement transmise (cf figures 1 et 2). Le fait que la liste de lecture finale préalablement transmise par le dispositif intermédiaire comprenne des identifiants de segments virtuels (et non pas des identifiants de segments réels, segments VOD par exemple) est transparent pour le dispositif de lecture. Ce dernier a un fonctionnement classique, basé sur des requêtes HTTP classiques. Dans une étape 3-2, le dispositif intermédiaire identifie le segment (c'est-à-dire retrouve le contenu (VOD ou publicitaire) et l'identifiant de segment (VOD ou publicitaire)) qu'il a préalablement associé au n-uplet avec lequel est paramétrée la requête de demande de segment. En d'autres termes, le dispositif intermédiaire traduit le n-uplet « asset ID + zone ID + segment ID » en un couple « real asset ID + segment ID », où « real asset ID » est l'identifiant du contenu VOD (« asset ID ») ou l'identifiant du contenu publicitaire (« ad asset ID »). Pour cela, le dispositif intermédiaire utilise les informations d'associations stockées à l'étape 1-8 de la figure 1. Dans une étape 3-3, le dispositif intermédiaire détermine un URI pointant vers le segment identifié à l'étape 3-2. Dans une étape 3-4, le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI déterminé à l'étape 3-3. Dans une étape 3-5, le dispositif de lecture interprète la réponse de type « HTTP Redirect » puis transmet une requête de demande de segment « HTTP GET segment » pointant vers l'URI déterminé à l'étape 3-3, c'est-à-dire soit vers un segment VOD du serveur VOD, soit vers un segment publicitaire du serveur de publicités. Dans une étape 3-6, le serveur interrogé (serveur VOD ou serveur de publicité) retourne le segment demandé (segment VOD ou segment publicitaire) au dispositif de lecture. On présente maintenant les étapes de l'exemple de la figure 4.
Dans cet exemple, l'identifiant du contenu VOD (« asset ID ») est « titanic » et l'identifiant de zone géographique (« Zone ID ») est « Z23 ». Les étapes 4-1 à 4-6 correspondent aux étapes 3-1 à 3-6 de la figure 3, pour le traitement d'une première requête dans laquelle le dispositif de lecture requiert le segment (segment VOD ou segment publicitaire) associé au segment virtuel dont l'identifiant est 8. Dans l'étape 4-1, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/titanic/8?zone=Z23 ». Dans l'étape 4-4, le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI « http:fivodserver/titanic/2 » (URI du segment VOD appartenant au contenu VOD « titanic » (stocké sur le serveur de VOD) et dont l'identifiant est 2). Les étapes 4-7 à 4-12 correspondent aux étapes 3-1 à 3-6 de la figure 3, pour le traitement d'une deuxième requête dans laquelle le dispositif de lecture requiert le segment (segment VOD ou segment publicitaire) associé au segment virtuel dont l'identifiant est 10. Dans l'étape 4-7, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/titanic/10?zone=Z23 ». Dans l'étape 4-10, le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI « http:fiadserver/A78/0 » (URI du segment publicitaire appartenant au deuxième contenu publicitaire « A78» (stocké sur le serveur de publicité) et dont l'identifiant est 0). 6.1.3 Gestion d'une requête HTTP GET Segment en mode « Proxy » (fig. 5 et 6) On présente maintenant, de manière générique (avec la figure 5) puis à travers un exemple (avec la figure 6), la gestion d'une requête HTTP GET segment, dans une application d'insertion de publicités dans un contenu VOD, selon un mode de réalisation particulier de l'invention, en mode « Proxy » On présente maintenant les étapes du cas générique de la figure 5. Les étapes 5-1 à 5-3 sont identiques aux étapes 3-1 à 3-3 de la figure 3. Dans une étape 5-4, le dispositif intermédiaire transmet une requête de demande de segment « HTTP GET segment » pointant vers l'URI déterminé à l'étape 5- 3, c'est-à-dire soit vers un segment VOD du serveur VOD, soit vers un segment publicitaire du serveur de publicités. Dans une étape 5-5, le serveur interrogé (serveur VOD ou serveur de publicité) retourne le segment demandé (segment VOD ou segment publicitaire) au dispositif intermédiaire.
Dans une étape 5-6, le dispositif intermédiaire retourne le segment demandé (segment VOD ou segment publicitaire) au dispositif de lecture.
On présente maintenant les étapes de l'exemple de la figure 6. Dans cet exemple, l'identifiant du contenu VOD (« asset ID ») est « titanic » et l'identifiant de zone géographique (« Zone ID ») est « Z23 ». Les étapes 6-1 à 6-6 correspondent aux étapes 5-1 à 5-6 de la figure 5, pour le traitement d'une première requête dans laquelle le dispositif de lecture requiert le segment (segment VOD ou segment publicitaire) associé au segment virtuel dont l'identifiant est 8. Dans l'étape 6-1, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/titanic/8?zone=Z23 ». Dans l'étape 6-4, le dispositif intermédiaire transmet au serveur VOD la requête de demande de segment suivante : « GET http://vodserver/titanic/2 » (commande GET suivie d'une URI du segment VOD appartenant au contenu VOD « titanic » (stocké sur le serveur de VOD) et dont l'identifiant est 2). Dans l'étape 6-5, le serveur VOD retourne au dispositif intermédiaire le segment obtenu. Dans l'étape 6-6, le dispositif intermédiaire retourne au dispositif de lecture le segment obtenu. Les étapes 6-7 à 6-12 correspondent aux étapes 5-1 à 5-6 de la figure 3, pour le traitement d'une deuxième requête dans laquelle le dispositif de lecture requiert le segment (segment VOD ou segment publicitaire) associé au segment virtuel dont l'identifiant est 10. Dans l'étape 6-7, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/titanic/10?zone=Z23 ». Dans l'étape 6-10, le dispositif intermédiaire transmet au serveur de publicité la requête de demande de segment suivante : « GET http://adserver/A78/0 » (commande GET suivie d'une URI du segment publicitaire appartenant au deuxième contenu publicitaire « A78» (stocké sur le serveur de publicité) et dont l'identifiant est 0). Dans l'étape 6-11, le serveur publicitaire retourne au dispositif intermédiaire le segment obtenu. Dans l'étape 6-12, le dispositif intermédiaire retourne au dispositif de lecture le segment obtenu. 6.2 Application d'insertion de publicités dans un contenu de direct (Live) 6.2.1 Gestion d'une requête HTTP GET Playlist (fig. 7 et 8) On présente maintenant, de manière générique (avec la figure 7) puis à travers un exemple (avec la figure 8), la gestion d'une requête HTTP GET Playlist, dans une application d'insertion de publicités dans un contenu de direct (Live), selon un mode de réalisation particulier de l'invention. Chacune des figures 7 et 8 présente un diagramme de séquence impliquant les mêmes entités que sur les figures 1 et 2, à l'exception du remplacement du serveur VOD par un serveur de direct (« Live server »). Dans cette application, le contenu souhaité est diffusé en direct (« Live » en anglais) sur un canal. Il est identifié par l'identifiant de ce canal (« channel ID »), éventuellement complété par une indication de période temporelle (« time period ») pour les segments souhaités. L'indication de période temporelle est optionnelle et peut être déterminée implicitement par le serveur de direct (« Live server »). Différentes périodes temporelles peuvent être définies, notamment (mais non exclusivement) : - le segment le plus proche de l'heure courante (c'est-à-dire le segment généré le plus récemment, ou « live edge » en anglais) et les segments jusqu'à N secondes en arrière par rapport à ce segment ; - les segments générés entre une heure de début et une heure de fin ; - les segments générés après une certaine heure de début et jusqu'à l'heure courante (c'est-à-dire jusqu'au segment généré le plus récemment). On présente maintenant les étapes du cas générique de la figure 7.
Dans une étape 7-1, le dispositif de lecture transmet au dispositif intermédiaire une requête de demande de liste de lecture « HTTP GET playlist (channel ID, zone ID, time period) », paramétrée avec l'identifiant du canal souhaité (« channel ID »), l'identifiant de zone géographique associé au dispositif de lecture (« zone ID ») et l'indication de période temporelle (« time period »).
Dans une étape 7-2, le dispositif intermédiaire transmet au serveur de direct une requête de demande de liste de lecture « HTTP GET playlist (channel ID, time period) », paramétrée avec l'identifiant du canal souhaité (« asset ID ») et l'indication de période temporelle (« time period »). Dans une étape 7-3, le serveur de direct retourne au dispositif intermédiaire la liste de lecture pour les segments de direct souhaités (c'est-à-dire sur le canal souhaité et dans la période temporelle souhaitée), avec des informations d'opportunité de placement (PO, pour « Placement Opportunities » en anglais). Cette liste de lecture est appelée « liste de lecture initiale » et comprend d'une part un premier gabarit d'URI pointant vers le serveur de direct et pré-paramétré avec l'identifiant du canal souhaité, et d'autre part une première liste d'identifiants de segments de direct. Chaque identifiant de segment de direct de la première liste permet, quand il est utilisé comme paramètre du premier gabarit, de générer un URI pointant vers un segment de direct (c'est-à-dire un segment du contenu diffusé en direct sur le canal choisi). Pour chaque information d'opportunité de placement définie par un identifiant (« PO ID »), le procédé comprend des étapes 7-4 à 7-7 qui sont identiques aux étapes 1- 4 à 1-7 de la figure 1. Puis, dans une étape 7-8, le dispositif intermédiaire génère une liste de lecture finale, en combinant la liste de lecture pour les segments de direct souhaités (cf étape 7-3) (ou « liste de lecture initiale ») et les listes de lecture pour les contenus publicitaires (cf étape 7-7), en fonction des informations d'opportunité de placement.
La liste de lecture finale comprend d'une part un deuxième gabarit d'URI pointant vers le dispositif intermédiaire et pré-paramétré avec l'identifiant du canal souhaité et l'identifiant de zone géographique, et d'autre part une deuxième liste d'identifiants de segments virtuels. La deuxième liste d'identifiants de segments virtuels est obtenue en combinant la première liste d'identifiants de segments de direct (comprise dans la liste de lecture initiale) et la ou les troisièmes listes d'identifiants de segments publicitaires (comprise chacune dans une liste de lecture d'un contenu publicitaire). Chaque identifiant de segment virtuels (« Segment ID ») de la deuxième liste permet, quand il est utilisé comme paramètre du deuxième gabarit, de générer un URI pointant vers un des segments virtuels associé soit à un segment de direct, soit à un segment publicitaire. Dans l'étape 7-8, le dispositif intermédiaire effectue en outre le stockage d'informations relatives aux associations entre segments virtuels d'une part et segments de direct / segments publicitaires d'autre part. Ces informations d'associations seront utilisées ultérieurement par le dispositif intermédiaire, dans le cadre de la gestion des requêtes « HTTP GET Segment ». Plus précisément, pour chaque identifiant de segment virtuel de la deuxième liste (qui identifie un segment virtuel associé à un segment donné : segment de direct ou segment publicitaire), le dispositif intermédiaire stocke un couple associant : - un n-uplet comprenant cet identifiant de segment virtuel (« Segment ID »), l'identifiant de zone géographique (« Zone ID ») et l'identifiant du canal (« channel ID ») ; et - des informations permettant d'obtenir un URI pointant vers le segment donné, et comprenant par exemple : o si le segment donné est un segment de direct : le premier gabarit d'URI pointant vers le serveur de direct (et pré-paramétré avec l'identifiant du canal (« channel ID »)), et l'identifiant de ce segment de direct ; o si le segment donné est un segment publicitaire : le troisième gabarit d'URI pointant vers le serveur publicitaire (et préparamétré avec l'identifiant du contenu publicitaire (« ad asset ID »)), et l'identifiant de ce segment publicitaire. Comme dans l'application d'insertion de publicités dans un contenu de VOD, les variantes « stockage partiel » ou « sans stockage » peuvent être mises en oeuvre. Dans une étape 7-9, le dispositif intermédiaire transmet la liste de lecture finale au dispositif de lecture.
On présente maintenant les étapes de l'exemple de la figure 8. Dans cet exemple, l'identifiant du canal (« channel ID ») est « cnn » et l'identifiant de zone géographique (« Zone ID ») est « Z23 ». Les étapes 8-1 à 8-3 correspondent aux étapes 7-1 à 7-3 de la figure 7. Le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de liste de lecture suivante (commande GET suivie d'une URI) : « GET http://splicer/cnn/manifest?zone=Z23 ». Les étapes 8-4 à 8-7 correspondent aux étapes 7-4 à 7-7 de la figure 7, pour une itération de la boucle avec l'opportunité de placement P67. Les étapes 8-8 et 8-9 correspondent aux étapes 7-8 et 7-9 de la figure 7.
Dans l'étape 8-3, la première liste d'identifiants de segments de direct (comprise dans la liste de lecture initiale) est : 100, 102, 103,5, 104, 106, 107,5, 108, qui sont des informations d'horodatage (« timestamps ») avec respectivement les durées : 2s, 1,5s, 0,5s, 2s, 1,5s, 0,5s. La liste de lecture initiale comprend une information d'opportunité de placement (dont l'identifiant est « P67 ») pour le remplacement (entre t=103,5 et t=107,5) d'une partie du contenu de direct par un contenu publicitaire. Les étapes 8-4 à 8-7 permettent d'informer le dispositif intermédiaire que l'information d'opportunité de placement (« P67 ») concerne un contenu publicitaire (« A78 ») comprenant deux segments de publicité de durée 2 secondes chacun. Pour ce contenu publicitaire, la liste d'identifiants de segments publicitaires est : 0, 2 (informations d'horodatage indiquant chacune une durée de 2s). Dans l'étape 8-8, la deuxième liste d'identifiants de segments virtuels (comprise dans la liste de lecture finale) est : 100, 102, 103,5, 105,5, 107,5, 108 (informations d'horodatage avec respectivement les durées : 2s, 1,5s, 2s, 2s, 0,5s), avec les correspondances (associations) suivantes : - les identifiants de segments virtuels 103,5, 105,5 correspondent aux identifiants de segments publicitaires 0, 2, de la liste d'identifiants pour le contenu publicitaire (« Ad asset ») ; - les identifiants de segments virtuels 100, 102, 107,5, 108 correspondent aux identifiants de segments de direct 100, 102, 107,5, 108 de la liste d'identifiants pour le contenu de direct (« Live »). Avec le modèle d'écriture de chaque ligne suivant : (« identifiant de segments virtuels » = « identifiant de contenu » I « identifiant de segment (de direct ou publicitaire) (durée) »), les correspondances (« mapping ») précitées peuvent également être synthétisées comme suit : 100 = Live 1100 (2s) 102 = Live 1102 (1,5s) 103,5 = Ad asset I 0 (2s) 105,5 = Ad asset 12 (2s) 107,5 = Live 1107,5 (0,5s) 108 = Live 1108 (2s) Dans l'étape 8-9, le dispositif intermédiaire retourne au dispositif de lecture la liste de lecture finale comprenant : - I e gabarit d'URI http://splicer/cnn/{timestamp}?zone=Z23; et - la liste d'identifiants de segments virtuels : 100, 102, 103,5, 105,5, 107,5, 108. 6.2.2 Gestion d'une requête HTTP GET Segment en mode « Redirect » (fig. 9 et 10) On présente maintenant, de manière générique (avec la figure 9) puis à travers un exemple (avec la figure 10), la gestion d'une requête HTTP GET segment, dans une application d'insertion de publicités dans un contenu de direct (Live), selon un mode de réalisation particulier de l'invention, en mode « Redirect ». On présente maintenant les étapes du cas générique de la figure 9. Dans une étape 9-1, le dispositif de lecture transmet au dispositif intermédiaire une requête de demande de segment « HTTP GET segment (channel ID, zone ID, segment ID) », paramétrée avec un n-uplet comprenant l'identifiant du canal souhaité (« channel ID »), l'identifiant de zone géographique (« zone ID ») et l'identifiant d'un des segments virtuels (« segment ID », qui est une information d'horodatage (« timestamp ») dans l'exemple présenté plus haut) de la liste de lecture finale que le dispositif intermédiaire lui a préalablement transmise (cf figures 7 et 8).
Le fait que la liste de lecture finale préalablement transmise par le dispositif intermédiaire comprenne des identifiants de segments virtuels (et non pas des identifiants de segments réels, segments de direct par exemple) est transparent pour le dispositif de lecture. Ce dernier a un fonctionnement classique, basé sur des requêtes HTTP classiques.
Dans une étape 9-2, le dispositif intermédiaire identifie le segment (c'est-à-dire retrouve le contenu (de direct ou publicitaire) et l'identifiant de segment (de direct ou publicitaire)) qu'il a préalablement associé au n-uplet avec lequel est paramétrée la requête de demande de segment. En d'autres termes, le dispositif intermédiaire traduit le n-uplet « channel ID + zone ID + segment ID » en un couple « real asset ID + segment ID », où « real asset ID » est l'identifiant du contenu de direct (« channel ID ») ou l'identifiant du contenu publicitaire (« ad asset ID »). Pour cela, le dispositif intermédiaire utilise les informations d'associations stockées à l'étape 7-8 de la figure 7. Dans une étape 9-3, le dispositif intermédiaire détermine un URI pointant vers le segment identifié à l'étape 9-2, et comprenant des informations de chaînage (« lookahead information » en anglais). Les informations de chaînage décrivent au moins un segment virtuel qui suit, dans la liste d'identifiant de segments virtuels (comprise dans la liste de lecture finale), le segment virtuel pointé par la requête de demande de segment transmise à l'étape 9-1. Dans une étape 9-4, le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI déterminé à l'étape 9-3 (et comprenant les informations de chaînage). Dans une étape 9-5, le dispositif de lecture interprète la réponse de type « HTTP Redirect » puis transmet une requête de demande de segment « HTTP GET segment » pointant vers l'URI déterminé à l'étape 9-3 (c'est-à-dire soit vers un segment de direct du serveur de direct, soit vers un segment publicitaire du serveur de publicités), et comprenant les informations de chaînage. Dans une étape 9-6, le serveur interrogé interprète les informations de chaînage et obtient un segment modifié comme suit : - si le serveur interrogé est le serveur de direct, il remplace les informations de chaînage déjà présentes dans le segment de direct par les informations de chaînage comprises dans la requête transmise à l'étape 9-5 ; - si le serveur interrogé est le serveur de publicité, il insère dans le segment publicitaire les informations de chaînage comprises dans la requête transmise à l'étape 9-5. Dans une étape 9-7, le serveur interrogé retourne le segment modifié (segment de direct modifié ou segment publicitaire modifié) au dispositif de lecture. Dans l'étape 9-6 décrite ci-dessus, on a considéré que les segments de direct sont chaînés, tandis que les segments de publicités ne le sont pas. D'autres configurations sont envisageables : par exemple, les segments de direct peuvent ne pas être chaînés (dans ce cas, le dispositif de lecture doit télécharger de manière répétée la liste de lecture) ; ou bien les segments de publicités peuvent être chaînés. Dans une variante, les informations de chaînage sont omises dans les étapes 9-3 à 9-6, si le dispositif intermédiaire détecte que le segment identifié à l'étape 9-2 et le "au moins un segment virtuel qui suit" sont tous associés à des segments de direct. En effet, dans ce cas, il n'est pas nécessaire que le dispositif intermédiaire détermine des informations de chaînage, ni que celles-ci soient transmises dans les étapes 9-4 et 9-5, puisqu'elles sont identiques aux informations de chaînage que le serveur interrogé (serveur de direct en l'espèce) va placer dans le segment de direct avant de le retourner au dispositif de lecture. Dans une autre variante, le chaînage s'effectue sans informations explicites de chaînage. Le chaînage est alors implicite : par exemple, l'identifiant du segment virtuel suivant (dans la liste d'identifiant de segments virtuels de la liste de lecture finale) est une information d'horodatage obtenue (par le dispositif de lecture) à partir de la durée du segment virtuel courant (identifié à l'étape 9-2) (cette durée étant écrite dans le segment virtuel courant). Dans cette variante, aucun mécanisme supplémentaire relatif au chaînage n'est nécessaire dans le cadre de la présente invention. On présente maintenant les étapes de l'exemple de la figure 10. Dans cet exemple, l'identifiant du canal (« channel ID ») est « cnn » et l'identifiant de zone géographique (« Zone ID ») est « Z23 ». En reprenant l'exemple de la figure 8, les informations de chaînage (portant sur deux segments suivants) pour les segments de direct sont - pour le segment de direct dont I 'identifiant est 100 : 102 (1,5s), 103.5 (0,5s) ; - pour le segment de direct dont I 'identifiant est 102 : 103,5 (0,5s), 104 (2s) ; - pour le segment de direct dont I 'identifiant est 103,5 : 104 (2s), 106 (1,5s) ; - pour le segment de direct dont I 'identifiant est 104 : 106 (1,5s), 107,5 (0,5s) ; - pour le segment de direct dont I 'identifiant est 106 : 107,5 (0,5s), 108 (2s) ; - pour le segment de direct dont I 'identifiant est 107,5 : 108 (2s), 110 (2s) ; - pour le segment de direct dont I 'identifiant est 108 : 110 (2s), 112 (2s).
Les informations de chaînage (portant sur deux segments suivants) pour les segments virtuels sont : - pour le segment virtuel dont l'identifiant est 100: 102 (1,5s), 103.5 (2s); - pour le segment virtuel dont l'identifiant est 102 : 103,5 (2s), 105,5 (2s); - pour le segment virtuel dont l'identifiant est 103,5 : pour le segment virtuel dont l'identifiant est 105,5 : pour le segment virtuel dont l'identifiant est 107,5 : 105,5 (2s), 107,5 (0,5s); (2s); ; - 107,5 (0,5s), 108 108 (2s), 110 (2s) - - pour le segment virtuel dont l'identifiant est 108 : 110 (2s), 112 (2s). Les étapes 10-1 à 10-7 correspondent aux étapes 9-1 à 9-7 de la figure 9, pour le traitement d'une première requête dans laquelle le dispositif de lecture requiert le segment (segment de direct ou segment publicitaire) associé au segment virtuel dont l'identifiant est 102. Dans l'étape 10-1, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/cnn/102?zone=Z23 ». Dans l'étape 10-4, le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI « http://liveserver/cnn/102?1a=103.5,2,105.5,2 » (URI du segment de direct appartenant au canal « cnn » et dont l'identifiant est 102 ; avec en outre des informations de chaînage relatives aux deux segments virtuels suivants : le premier possède l'identifiant 103,5 (durée 2s) et le second l'identifiant 105,5 (durée 2s)). Dans l'étape 10-6, le serveur de direct remplace les informations de chaînage déjà présentes dans le segment de direct (dont l'identifiant est 102) par les informations de chaînage (« 103.5,2,105.5,2 »), dans le segment de direct demandé. Les étapes 10-8 à 10-14 correspondent aux étapes 9-1 à 9-7 de la figure 9, pour le traitement d'une deuxième requête dans laquelle le dispositif de lecture requiert le segment (segment de direct ou segment publicitaire) associé au segment virtuel dont l'identifiant est 105,5. Dans l'étape 10-8, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/cnn/105,5?zone=Z23 ». Dans l'étape 10-11, le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI « http://adserver/A78/2?1a=107.5,0.5,108,2 » (URI du segment publicitaire appartenant au contenu publicitaire « A78 » et dont l'identifiant est 2; avec en outre des informations de chaînage pour les deux segments virtuels suivants : celui dont l'identifiant est 107,5 (durée 0,5s) et celui dont l'identifiant est 108 (durée 2s)). Dans l'étape 10-13, le serveur de publicités insère les informations de chaînage (« 107.5,0.5,108,2 ») dans le segment publicitaire demandé. 6.2.3 Gestion d'une requête HTTP GET Segment en mode « Proxy » (fig. 11 et 12) On présente maintenant, de manière générique (avec la figure 11) puis à travers un exemple (avec la figure 12), la gestion d'une requête HTTP GET segment, dans une application d'insertion de publicités dans un contenu de direct (live), selon un mode de réalisation particulier de l'invention, en mode « Proxy » On présente maintenant les étapes du cas générique de la figure 11. Les étapes 11-1 et 11-2 sont identiques aux étapes 9-1 et 9-2 de la figure 9.
Dans une étape 11-3, le dispositif intermédiaire détermine un URI pointant vers le segment identifié à l'étape 11-2 (pas d'insertion ou de remplacement d'informations de chaînage à ce stade, contrairement à l'étape 9-3 de la figure 9). Dans une étape 11-4, le dispositif intermédiaire transmet une requête de demande de segment « HTTP GET segment » pointant vers l'URI déterminé à l'étape 11-3, c'est-à-dire soit vers un segment de direct du serveur de direct, soit vers un segment publicitaire du serveur de publicités. Dans une étape 11-5, le serveur interrogé (serveur de direct ou serveur de publicité) retourne le segment demandé (segment de direct ou segment publicitaire) au dispositif intermédiaire.
Dans une étape 11-6, le dispositif intermédiaire détermine des informations de chaînage, qui décrivent au moins un segment virtuel qui suit, dans la liste d'identifiant de segments virtuels (comprise dans la liste de lecture finale), le segment virtuel pointé par la requête de demande de segment transmise à l'étape 11-1. Dans une étape 11-7, le dispositif intermédiaire obtient un segment modifié en plaçant les informations de chaînage (déterminées à l'étape 11-6) dans le segment retourné à l'étape 11-5. Si le segment retourné est un segment de direct, il s'agit d'un remplacement des informations de chaînage déjà présentes dans le segment de direct par les informations de chaînage déterminées à l'étape 11-6. Si le segment retourné est un segment publicitaire, il s'agit d'une insertion des informations de chaînage déterminées à l'étape 11-6.
Dans l'étape 11-7 décrite ci-dessus, on a considéré que les segments de direct sont chaînés, tandis que les segments de publicités ne le sont pas. D'autres configurations sont envisageables : par exemple, les segments de direct peuvent ne pas être chaînés (dans ce cas, le dispositif de lecture doit télécharger de manière répétée la liste de lecture) ; ou bien les segments de publicités peuvent être chaînés. Dans une variante, les informations de chaînage sont omises dans les étapes 116 et 11-7, si le dispositif intermédiaire détecte que le segment identifié à l'étape 11-2 et le "au moins un segment virtuel qui suit" sont tous associés à des segments de direct. En effet, dans ce cas, il n'est pas nécessaire que le dispositif intermédiaire détermine des informations de chaînage, puisqu'elles sont identiques aux informations de chaînage que le serveur interrogé (serveur de direct en l'espèce) a fournies au dispositif intermédiaire à l'étape 11-5. Dans une autre variante, le chaînage s'effectue sans informations explicites de chaînage. Le chaînage est alors implicite : par exemple, l'identifiant du segment virtuel suivant (dans la liste d'identifiant de segments virtuels de la liste de lecture finale) est une information d'horodatage obtenue (par le dispositif de lecture) à partir de la durée du segment virtuel courant (identifié à l'étape 11-2) (cette durée étant écrite dans le segment virtuel courant). Dans cette variante, aucun mécanisme supplémentaire relatif au chaînage n'est nécessaire dans le cadre de la présente invention.
Dans une étape 11-8, le dispositif intermédiaire retourne le segment modifié (à l'étape 11-7) au dispositif de lecture. On présente maintenant les étapes de l'exemple de la figure 12. Dans cet exemple, l'identifiant du canal (« channel ID ») est « cnn » et l'identifiant de zone géographique (« Zone ID ») est « Z23 ».
Les étapes 12-1 à 12-8 correspondent aux étapes 11-1 à 11-8 de la figure 11, pour le traitement d'une première requête dans laquelle le dispositif de lecture requiert le segment (segment de direct ou segment publicitaire) associé au segment virtuel dont l'identifiant est 102. Dans l'étape 12-1, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/cnn/102?zone=Z23 ». Dans l'étape 12-4, le dispositif intermédiaire transmet au serveur de direct la requête de demande de segment suivante : « GET http://liveserver/cnn/102 » (commande GET suivie d'une URI du segment de direct appartenant au canal « cnn » (fourni par le serveur de direct) et dont l'identifiant est 102). Dans l'étape 12-5, le serveur de direct retourne au dispositif intermédiaire le segment demandé. Dans l'étape 12-6, le dispositif intermédiaire détermine, pour le segment virtuel dont l'identifiant est 102, les informations d'horodatage relatives aux deux segments virtuels suivants : le premier possède l'identifiant 103,5 (durée 2s) et le second l'identifiant 105,5 (durée 2s). Dans l'étape 127, le dispositif intermédiaire remplace les informations de chaînage déjà présentes dans le segment de direct (reçu à l'étape 12-5) par les informations de chaînage (« 103.5,2,105.5,2 ») déterminées à l'étape 12-6. Dans l'étape 12-8, le dispositif intermédiaire retourne au dispositif de lecture le segment de direct modifié résultant de l'étape 12-7. Les étapes 12-9 à 12-16 correspondent aux étapes 11-1 à 11-8 de la figure 11, pour le traitement d'une deuxième requête dans laquelle le dispositif de lecture requiert le segment (segment de direct ou segment publicitaire) associé au segment virtuel dont l'identifiant est 105,5. Dans l'étape 12-9, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/cnn/105,5?zone=Z23 ». Dans l'étape 12-12, le dispositif intermédiaire transmet au serveur de publicités la requête de demande de segment suivante : « GET httpliadserver/A78/102 » (commande GET suivie d'une URI du segment publicitaire appartenant au contenu publicitaire « A78 » (stocké par le serveur de publicité) et dont l'identifiant est 105,5). Dans l'étape 12-13, le serveur de publicités retourne au dispositif intermédiaire le segment publicitaire demandé. Dans l'étape 12-14, le dispositif intermédiaire détermine, pour le segment virtuel dont l'identifiant est 105,5, les informations d'horodatage relatives aux deux segments virtuels suivants : le premier possède l'identifiant 107,5 (durée 0,5s) et le second l'identifiant 108 (durée 2s). Dans l'étape 12-15, le dispositif intermédiaire insère dans le segment publicitaire (reçu à l'étape 12-13) les informations de chaînage (« 107.5,0.5,108,2 ») déterminées à l'étape 12-14. Dans l'étape 12-16, le dispositif intermédiaire retourne au dispositif de lecture le segment de direct modifié résultant de l'étape 12-15. 6.3 Application de substitution de programme (« geographical blackout ») On présente maintenant une application de substitution de programme, selon un mode de réalisation particulier de l'invention. Cette application est aussi appelée « application de blocage géographique » (en anglais, « geographical blackout » ou « sports blackout »). Son principe est très similaire à celui de l'application d'insertion de publicités dans un contenu de direct (Live) (cf figures 7 à 12), excepté le fait que : - plutôt que d'utiliser des informations d'opportunité de placement qui sont présentes, dans la liste de lecture initiale relative à un contenu diffusé en direct sur un canal, pour indiquer les possibilités de placement de publicités dans ce contenu, - le dispositif intermédiaire utilise des informations de blocage (« blackout information » en anglais) qui sont présentes, dans la liste de lecture initiale relative à un contenu diffusé en direct sur un canal, pour indiquer si ce contenu doit être bloqué et remplacé par un contenu de substitution. Pour chaque période de blocage, une information de blocage (qui possède un identifiant (« blackout ID »)) indique quels segments du canal demandé appartiennent à cette période de blocage. Le rôle du dispositif intermédiaire est de garantir que les dispositifs de lecture d'une certaine zone géographique ne reçoivent pas les segments du canal demandé, mais à la place des segments d'un autre contenu (par exemple des segments d'un autre canal). Les principales différences avec l'application d'insertion de publicités dans un contenu de direct (Live) sont : - la durée (c'est-à-dire l'heure de fin) de la période de blocage est généralement inconnue au moment où le dispositif intermédiaire a besoin de réaliser le remplacement de contenu, tandis que pour I 'insertion d'une publicité, l'information d'opportunité de placement est connue à l'avance ; - le contenu n'est pas remplacé pour la plupart des zones géographiques, tandis que pour I 'insertion d'une publicité, le remplacement est plus ou moins systématique ; - le contenu à bloquer est généralement remplacé par un autre contenu de direct (« live stream »), plutôt que par un ou plusieurs contenus publicitaires de durées finies. Cependant, il est aussi possible de remplacer le contenu à bloquer par un contenu VOD lu en boucle (qui simule un contenu de direct) ; - l'application de substitution de programme s'applique uniquement au cas « en direct » (live), pas au cas VOD. Cette application introduit une nouvelle entité : un serveur de décision de blocage (BDS, pour « Blackout Decision Server »), mais il est équivalent au serveur ADS (« Ad Decision Server ») dans l'application d'insertion de publicités.
Le fonctionnement de l'application de substitution de programme est décrit ci- dessous seulement brièvement car il se déduit de celui de l'application d'insertion de publicités dans un contenu de direct (Live), présenté en détail ci-dessus en relation avec les figures 7 à 12. On passe de l'un à l'autre en remplaçant le serveur ADS par le serveur BDS, en supprimant le serveur de publicités et en remplaçant les informations d'opportunités de placement par les informations de blocage. Pour cette raison, il n'a pas de figures spécifiques à l'application de substitution de programme. 6.3.1 Gestion d'une requête HTTP GET Playlist Le dispositif de lecture transmet au dispositif intermédiaire une requête de demande de liste de lecture « HTTP GET playlist (channel ID, zone ID, time period) », paramétrée avec l'identifiant du canal souhaité (« channel ID »), l'identifiant de zone géographique associé au dispositif de lecture (« zone ID ») et l'indication de période temporelle (« time period »). Puis, le dispositif intermédiaire transmet au serveur de direct une requête de demande de liste de lecture « HTTP GET playlist (channel ID, time period) », paramétrée avec l'identifiant du canal souhaité (« asset ID ») et l'indication de période temporelle (« time period »). Le serveur de direct retourne au dispositif intermédiaire la liste de lecture pour les segments de direct souhaités (c'est-à-dire sur le canal souhaité et dans la période temporelle souhaitée), avec des informations de blocage (« blackout information » en anglais). Cette liste de lecture est appelée « liste de lecture initiale ».
Pour chaque information de blocage définie par un identifiant (« Blackout ID »), le dispositif intermédiaire interroge le serveur de décision BDS (en fournissant les identifiants « Blackout ID » et « Zone ID ». En retour, ce dernier indique au dispositif intermédiaire si le dispositif de lecture doit recevoir un contenu de substitution, et dans l'affirmative lequel, en précisant l'identifiant de canal (« Channel ID ») s'il s'agit d'un contenu de direct (live) (le canal de substitution et le canal d'origine peuvent être fournis par le même serveur de direct ou par des serveurs distincts), ou l'identifiant de contenu (« asset ID ») s'il s'agit d'un contenu VOD (fourni par un serveur VOD). Ensuite, le dispositif intermédiaire génère une liste de lecture finale. Pour cela, il détermine, au sein du contenu de substitution, le segment qui est le plus proche, en « temps réel écoulé » (« wall-clock time » en anglais), du premier segment se trouvant dans la période de blocage. Puis, pour obtenir la liste d'identifiants de segments virtuels (comprise dans la liste de lecture finale), le dispositif intermédiaire enlève (de la liste d'identifiants de segments comprise dans la liste de lecture initiale) les identifiants de segments (« timestamps ») qui sont dans la plage de blocage et les remplace par les identifiants de segments (« timestamps ») du contenu de substitution. Par exemple : - si la liste de lecture initiale contient les identifiants de segment 100, 102, 104, 106, 108, 110, - si les segments 104, 106 sont dans la période de blocage, et - si la liste de lecture du contenu de substitution contient les identifiants de segment 200, 202, 204, 205,5, 207,5, 209,5, avec le segment dont l'identifiant est 204 correspondant au segment le plus proche, en « temps réel écoulé » (« wall-clock time »), du premier segment de la période de blocage (c'est-à-dire celui dont l'identifiant est 100) ; - alors la liste de lecture finale contient les identifiants de segments virtuels 100, 102, 104, 105,5, 108, 110, avec les correspondances (associations) suivantes : o les identifiants de segments virtuels 100, 102, 108, 110 correspondent aux identifiants de segments de direct 100, 102, 108, 110 contenus dans la liste de lecture initiale ; o les identifiants de segments virtuels 104, 105,5 correspondent aux identifiants de segments de substitution 204, 205,5 de la liste de lecture du contenu de substitution (détails de calcul : 104=204+(104-204) et 105,5=205,5+(104-204)). Avec le modèle d'écriture de chaque ligne suivant : (« identifiant de segments virtuels » = « identifiant de contenu » I « identifiant de segment (de direct ou de substitution) (durée) »), les correspondances (« mapping ») précitées peuvent également être synthétisées comme suit : 100 = Live I 100 (2s) 102 = Live I 102 (2s) 104 = Replace 1204(1,5s) 105,5 = Replace I 205,5 (2s) 108 = Live I 108 (2s) 110 = Live I 110 (2s) Enfin, le dispositif intermédiaire transmet la liste de lecture finale au dispositif de lecture. 6.3.2 Gestion d'une requête HTTP GET Segment (en mode « Redirect » ou « Proxy ») Le dispositif de lecture transmet au dispositif intermédiaire une requête de demande de segment « HTTP GET segment (channel ID, zone ID, segment ID) », paramétrée avec un n-uplet comprenant l'identifiant du canal souhaité (« channel ID »), l'identifiant de zone géographique (« zone ID ») et l'identifiant d'un des segments virtuels (« segment ID ») de la liste de lecture finale que le dispositif intermédiaire lui a préalablement transmise. Le dispositif intermédiaire identifie le segment (c'est-à-dire retrouve le contenu (de direct ou de substitution) et l'identifiant de segment (de direct ou de substitution)) qu'il a préalablement associé au n-uplet avec lequel est paramétrée la requête de demande de segment.
Le dispositif intermédiaire détermine un URI pointant vers le segment identifié. Il détermine également des informations de chaînage, décrivant au moins un segment virtuel qui suit, dans la liste d'identifiant de segments virtuels (comprise dans la liste de lecture finale), le segment virtuel pointé par la requête de demande de segment.
Comme dans l'application d'insertion de publicités dans un contenu de direct (Live), deux modes peuvent être envisagés pour permettre au dispositif de lecture de recevoir le segment demandé (segment de direct ou segment de substitution), après modification de ce dernier (de façon qu'il contienne les informations de chaînage) : le mode « Redirect » (cf figure 9 et 10) et le mode « Proxy » (cf figures 11 et 12).
Dans le mode « Redirect », le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI déterminé (pointant vers le segment identifié et comprenant les informations de chaînage). Le dispositif de lecture interprète la réponse de type « HTTP Redirect » puis transmet une requête de demande de segment « HTTP GET segment » pointant vers l'URI déterminé. Le serveur interrogé (pointé par l'URI déterminé) interprète les informations de chaînage et obtient un segment modifié, contenant les informations de chaînage reçues avec l'URI déterminé. Enfin, le serveur interrogé retourne le segment modifié au dispositif de lecture. Dans le mode « Proxy », le dispositif intermédiaire transmet une requête de demande de segment « HTTP GET segment » pointant vers l'URI déterminé (pointant vers le segment identifié). Le serveur interrogé (pointé par l'URI déterminé) retourne le segment demandé au dispositif intermédiaire. Le dispositif intermédiaire obtient un segment modifié en plaçant les informations de chaînage dans le segment retourné par le serveur interrogé. Enfin, le dispositif intermédiaire retourne le segment modifié au dispositif de lecture. 6.4 Application de marquage (« watermarking ») 6.4.1 Gestion d'une requête HTTP GET Playlist (fig. 13 et 14) On présente maintenant, de manière générique (avec la figure 13) puis à travers un exemple (avec la figure 14), la gestion d'une requête HTTP GET Playlist, dans une application de marquage (aussi appelé « tatouage numérique » ou « watermarking » en anglais), selon un mode de réalisation particulier de l'invention. Dans ce qui précède, on a présenté : - une application d'insertion de publicités (« Ad insertion »), dans laquelle une liste de lecture finale est obtenue par le dispositif intermédiaire, en combinant une liste de lecture initiale (pour un contenu VOD ou un contenu de direct (live)) et une ou plusieurs listes de lectures chacune pour un contenu publicitaire ; - une application de substitution géographique (« geographical blackout »), dans laquelle une liste de lecture finale est obtenue par le dispositif intermédiaire, en combinant une liste de lecture initiale (pour un contenu de direct (live)) et une ou plusieurs listes de lectures chacune pour un contenu de substitution. Dans l'application de marquage, une liste de lecture finale est également obtenue par le dispositif intermédiaire, en combinant plusieurs listes de lecture. Mais, dans cette application on combine N (avec N supérieur ou égal à deux) listes de lecture relatives à N contenus particuliers (appelés ci-après premier contenu et autre(s) contenu(s)) (par « contenu », on entend ici, comme dans ce qui précède, soit un contenu VOD, soit un contenu de direct (Live)) : - ils possèdent le même identifiant de contenu (asset ID), appelé ci-après « identifiant de contenu commun »; - ils comprennent des segments identiques (même contenu de segment, même durée), exceptée la présence, dans chaque segment de même rang des N contenus, d'un tatouage numérique (« watermark » en anglais) distinct. En d'autres termes, les N contenus sont N variantes d'un même contenu initial, et sont visuellement identiques à l'oeil nu ; - la liste de lecture associée au premier contenu (c'est-à-dire à la première variante du contenu initial), comprend un premier gabarit d'URI pointant vers un serveur et pré-paramétré avec l'identifiant de contenu commun et un premier identifiant de variante de contenu (alt ID = 1); - la liste de lecture associée à chaque autre contenu (c'est-à-dire à chaque autre variante du contenu initial), comprend un autre gabarit d'URI pointant vers le serveur précité (ou, dans une variante, vers un autre serveur) et pré-paramétré avec l'identifiant de contenu commun et un second identifiant de variante de contenu (alt ID = 2). En d'autres termes, les segments des N flux sont disponibles à des URIs différents. Par exemple, dans le cas N=2, avec « Al » l'identifiant de contenu commun, le premier contenu contient trois segments (dont les identifiants de segments sont 0, 2, 4) aux URIs suivants : - http://server/A1/v1/0, - htt p lise rve r/Al/v1/2, - http://server/A1/v1/4, et le second contenu contient également trois segments (dont les identifiants de segments sont également 0, 2, 4) aux URIs suivants : - http://server/A1/v2/0, - htt p lise rve r/Al/v2/2, - http://server/A1/v2/4. Dans cet exemple, « v1» et « v2 » correspondent aux premier et second identifiants de variante de contenu.
Dans ce qui précède, les listes de lecture associées aux différents contenus se distinguent parce que chaque gabarit est pré-paramétré avec un identifiant de variante de contenu qui est différent. Dans une variante, elles se distinguent parce que la liste d'identifiants de segments est différente d'une liste de lecture à l'autre. On présente maintenant les étapes du cas générique de la figure 13 (dans le mode de réalisation où N=2 et les listes de lecture associées aux différents contenus se distinguent parce que chaque gabarit est pré-paramétré avec un identifiant de variante de contenu qui est différent). Dans une étape 13-1, le dispositif de lecture transmet au dispositif intermédiaire une requête de demande de liste de lecture « HTTP GET playlist (asset ID, user ID) », paramétrée avec un identifiant de contenu VOD (« asset ID ») et un identifiant de groupe comme par exemple un identifiant d'utilisateur (« user ID »). Ce dernier paramètre permet de décider comment seront marqués (tatoués numériquement) les segments qui seront fournis au dispositif de lecture. Pour chaque variante du contenu VOD souhaité, définie par un identifiant (« alt ID »), le procédé comprend les étapes suivantes : - dans une étape 13-2, le dispositif intermédiaire transmet au serveur VOD une requête de demande de liste de lecture « HTTP GET playlist (asset ID, alt ID) », paramétrée avec l'identifiant du contenu VOD (« asset ID ») et l'identifiant de ladite variante (« alt ID »); - dans une étape 13-3, le serveur VOD retourne au dispositif intermédiaire la liste de lecture pour ladite variante du contenu VOD souhaité. Cette liste de lecture comprend d'une part un gabarit d'URI pointant vers le serveur VOD et pré-paramétré avec l'identifiant de contenu VOD (« asset ID ») et l'identifiant de ladite variante (« alt ID »), et d'autre part une liste d'identifiants de segments VOD. Chaque identifiant de segment VOD permet, quand il est utilisé comme paramètre du gabarit précité, de générer un URI pointant vers un segment VOD de ladite variante du contenu VOD). Puis, dans une étape 13-4, le dispositif intermédiaire génère une liste de lecture finale, en fonction des listes de lecture des deux variantes du contenu VOD souhaité. La liste de lecture finale comprend d'une part un deuxième gabarit d'URI pointant vers le dispositif intermédiaire et pré-paramétré avec l'identifiant de contenu VOD (asset ID) et l'identifiant d'utilisateur (user ID), et d'autre part une liste d'identifiants de segments virtuels. La liste d'identifiants de segments virtuels est identique aux deux listes (elles-mêmes identiques entre elles) d'identifiants de segments VOD des deux variantes du contenu VOD. Chaque identifiant de segment virtuels (« Segment ID ») permet, quand il est utilisé comme paramètre du deuxième gabarit, de générer un URI pointant vers un des segments virtuels associé soit à un segment VOD du premier contenu (c'est-à-dire de la première variante du contenu VOD), soit à un segment VOD du second contenu (c'est-à-dire de la deuxième variante du contenu VOD).
Dans une étape 13-5, le dispositif intermédiaire transmet la liste de lecture finale au dispositif de lecture.
On présente maintenant les étapes de l'exemple de la figure 14. Dans cet exemple, l'identifiant de contenu VOD (« asset ID ») est « Al » et l'identifiant d'utilisateur (« user ID ») est « U76 ». L'étape 14-1 correspond à l'étape 13-1 de la figure 13. Le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de liste de lecture suivante (commande GET suivie d'une URI) : « GET http://splicer/A1/manifest?user=U76 ». Les étapes 14-2 et 14-3 correspondent aux étapes 13-2 et 13-3 de la figure 13, pour une première itération de la boucle (avec « alt ID » = 1), pour le premier contenu (c'est-à-dire la première variante du contenu VOD). Dans l'étape 14-3, la liste de lecture retournée par le serveur comprend : - la liste d'identifiants de segments : 0, 2, 4, qui sont des informations d'horodatage (« timestamps ») indiquant chacune une durée de 2s ; - le gabarit d'URI : http://server/A1/{timestamp}?alt=1. Les étapes 14-4 et 14-5 correspondent aux étapes 13-2 et 13-3 de la figure 13, pour une deuxième itération de la boucle (avec « alt ID » = 2), pour le second contenu (c'est-à-dire la seconde variante du contenu VOD). Dans l'étape 14-5, la liste de lecture retournée par le serveur comprend : - la liste d'identifiants de segments : 0, 2, 4 (identique à la liste d'identifiants de segments reçue à l'étapes 14-3) ; - le gabarit d'URI : http://server/A1/{timestamp}?alt=2 Les étapes 14-6 et 14-7 correspondent aux étapes 13-4 et 13-5 de la figure 13. La liste de lecture finale comprend : - la liste d'identifiants de segments virtuels : 0, 2, 4 (identique aux deux listes d'identifiants de segments reçues aux étapes 14-3 et 14-5); - le gabarit d'URI : http://splicer/A1/{timestamp}?user=76 Les explications données ci-dessus, en relation avec les figures 13 et 14, dans le cas d'un contenu VOD, sont aisément et directement transposables au cas d'un contenu diffusé en direct sur un canal. L'identifiant de contenu VOD (« asset ID ») est alors remplacé par l'identifiant du canal (« channel ID »), éventuellement complété par une indication de période temporelle (« time period ») pour les segments souhaités. 6.4.2 Gestion d'une requête HTTP GET Segment en mode « Redirect » (fig. 15 et 16) On présente maintenant, de manière générique (avec la figure 15) puis à travers un exemple (avec la figure 16), la gestion d'une requête HTTP GET Segment, dans l'application de marquage (Watermarking), selon un mode de réalisation particulier de l'invention, en mode « Redirect ». On présente maintenant les étapes du cas générique de la figure 15. Dans une étape 15-1, le dispositif de lecture transmet au dispositif intermédiaire une requête de demande de segment « HTTP GET segment (asset ID, segment ID, user ID) », paramétrée avec un n-uplet comprenant l'identifiant de contenu VOD (« asset ID »), l'identifiant d'utilisateur (« user ID ») et l'identifiant d'un des segments virtuels (« segment ID », qui est une information d'horodatage (« timestamp ») dans l'exemple présenté plus haut) de la liste de lecture finale que le dispositif intermédiaire lui a préalablement transmise (cf figures 13 et 14). Le fait que la liste de lecture finale préalablement transmise par le dispositif intermédiaire comprenne des identifiants de segments virtuels (et non pas des identifiants de segments réels, segments VOD par exemple) est transparent pour le dispositif de lecture. Ce dernier a un fonctionnement classique, basé sur des requêtes HTTP classiques. Dans une étape 15-2, le dispositif intermédiaire détermine l'identifiant de variante (« alt ID ») associé au n-uplet avec lequel est paramétrée la requête de demande de segment. Cet identifiant de variante indique dans lequel des premier et second contenus se trouve le segment à fournir au dispositif de lecture. On rappelle que le premier contenu et le second contenu sont deux variantes d'un même contenu VOD initial. En d'autres termes, le dispositif intermédiaire traduit (algorithme déterministe) le n-uplet « asset ID + user ID + segment ID » en « alt ID», où « alt ID » est l'identifiant de la première variante (« alt ID » = 1) ou l'identifiant de la seconde variante (« alt ID » = 2).
Dans une étape 15-3, le dispositif intermédiaire détermine un URI pointant vers le segment identifié par les identifiants « asset ID » et « segment ID », ainsi que par l'identifiant de variante (« alt ID ») déterminé à l'étape 15-2. Dans une étape 15-4, le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI déterminé à l'étape 15-3. Dans une étape 15-5, le dispositif de lecture interprète la réponse de type « HTTP Redirect » puis transmet une requête de demande de segment « HTTP GET segment » pointant vers l'URI déterminé à l'étape 15-3, c'est-à-dire soit vers un segment VOD du premier contenu (c'est-à-dire de la première variante du contenu VOD), soit à un segment VOD du second contenu (c'est-à-dire de la deuxième variante du contenu VOD). Dans une étape 15-6, le serveur interrogé retourne le segment demandé au dispositif de lecture. Ainsi, le contenu réellement fourni au dispositif de lecture, comprend une succession de segments tatoués chacun selon l'une des deux marques. C'est équivalent au transport, par le contenu réellement fourni, d'un canal caché où chaque segment transporte un bit de marquage (par exemple « 0 » si ce segment vient du premier contenu et « 1 » si ce segment vient du second contenu). Les bits successifs de ce canal caché sont fonction de l'algorithme déterministe utilisé par le dispositif intermédiaire. Ce canal caché permet par exemple de vérifier ultérieurement d'où provient un contenu dont dispose un utilisateur. On présente maintenant les étapes de l'exemple de la figure 16. Dans cet exemple, l'identifiant de contenu (« asset ID ») est « Al » et l'identifiant d'utilisateur (« user ID ») est « U76 ».
Les étapes 16-1 à 16-6 correspondent aux étapes 15-1 à 15-6 de la figure 15, pour le traitement d'une requête dans laquelle le dispositif de lecture requiert le segment VOD associé au segment virtuel dont l'identifiant est 2. Dans l'étape 16-1, le dispositif de lecture transmet au dispositif intermédiaire la requête de demande de segment suivante (commande GET suivie d'une URI) : « GET http://splicer/A1/2?user=U76 ». Dans l'étape 16-4, le dispositif intermédiaire répond au dispositif de lecture avec une réponse de type « HTTP Redirect » vers l'URI « http://server/A1/2?alt=2 » (URI du segment VOD appartenant au second contenu (c'est-à-dire la seconde variante du contenu « Al », comme indiqué par « alt=2 ») et dont l'identifiant est 2).
Les explications données ci-dessus, en relation avec les figures 15 et 16, dans le cas d'un contenu VOD, sont aisément et directement transposables au cas d'un contenu diffusé en direct sur un canal. L'identifiant de contenu VOD (« asset ID ») est alors remplacé par l'identifiant du canal (« channel ID »), éventuellement complété par une indication de période temporelle (« time period ») pour les segments souhaités.
Avec cette application de marquage (Watermarking), aucun mécanisme de manipulation des informations de chaînage n'est nécessaire dans le cas d'un contenu diffusé en direct sur un canal (live), contrairement à l'application d'insertion de publicités (cf figures 9 et 10). En effet, deux segments de même rang des deux contenus (par exemple les deux segments dont l'identifiant de segment est 4) contiennent les mêmes informations de chaînage, qui n'ont donc pas besoin d'être modifiées. On rappelle en effet que les premier et second contenus contiennent des segments identiques, exceptée la présence, dans chaque segment de même rang des deux contenus, d'un tatouage numérique distinct. 6.4.3 Gestion d'une requête HTTP GET Segment en mode « Proxy » Pour la gestion d'une requête HTTP GET segment, dans l'application de marquage (watermarking) d'un contenu VOD ou de direct (Live), la présente invention s'applique également en mode « Proxy ». Ce cas n'est pas décrit en détail (ni représenté sur des figures) car il peut aisément être déduit du cas en mode « Redirect » des figures 15 et 16, de la même manière que pour l'application d'insertion de publicités : - le cas en mode « Proxy » des figures 5 et 6 est déduit du cas en mode « Redirect » des figures 3 et 4 (pour un contenu VOD), et - le cas en mode « Proxy » des figures 11 et 12 est déduit du cas en mode « Redirect » des figures 9 et 10 (pour un contenu de direct (Live)). 6.5 Structure du dispositif intermédiaire (fig. 17) La figure 17 présente la structure simplifiée d'un dispositif intermédiaire mettant en oeuvre le procédé selon l'invention (dans l'un quelconque des modes de réalisation particuliers décrits ci-dessus en relation avec les figures 1 à 16). Ce dispositif intermédiaire comprend une mémoire RAM 173, une unité de traitement 171, équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur stocké dans une mémoire ROM 172. A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire RAM 173 avant d'être exécutées par le processeur de l'unité de traitement 171. L'unité de traitement 171 reçoit en entrée divers messages 170 provenant des autres entités (dispositif de lecture, serveur VOD, serveur de direct, serveur ADS, serveur de publicités, serveur de direct, etc.), et notamment les requêtes de demande de liste de lecture (HTTP GET playlist) et les requêtes de demande de segment (HTTP GET segment) transmises par le dispositif de lecture. Le processeur de l'unité de traitement 171 effectue les traitements nécessaires (selon les instructions du programme 172), et génère en sortie divers messages 174 vers les autres entités, et notamment les réponses aux requêtes précitées (HTTP GET playlist et HTTP GET segment) transmises par le dispositif de lecture. Cette figure 17 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser les différents algorithmes détaillés ci-dessus, en relation avec les figures 1 à 16. En effet, la technique de l'invention se réalise indifféremment : - sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou - sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel). Dans le cas où l'invention est implantée sur une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur. 6.6 Variantes diverses Il est clair que de nombreux autres modes de réalisation de l'invention peuvent être envisagés. On peut notamment prévoir diverses variantes découlant de : - l'ordre dans lequel la séquence d'actions se produit. Par exemple, avant que le dispositif de lecture émette sa requête de demande de liste de lecture (HTTP GET playlist), le dispositif intermédiaire peut obtenir les listes de lecture fournies par les serveurs (serveur VOD, serveur de direct, serveur de publicités, ...) et les mettre en cache. De même, il peut mettre en cache des décisions fournies par les serveurs de décision (ADS, BDS) afin d'éviter des requêtes identiques vers ces serveurs ; - certaines entités peuvent être fusionnées (par exemple les fonctions du serveur ADS ou BDS peuvent être intégrées dans le dispositif intermédiaire) ; - des messages peuvent être inversés (par exemple, les serveurs (serveur VOD, serveur de direct, serveur de publicités, ...) peuvent « pousser » (« push » en anglais) les listes de lecture au dispositif intermédiaire) ; - le protocole HTTP peut être remplacé par un autre protocole de communication client-serveur ne nécessitant pas de serveur spécialisé ; - quelle que soit l'application, la présente invention peut être appliquée avec n'importe quel type d'identifiant de groupe (et pas uniquement « Zone Id » ou « User Id »), dès lors qu'il définit un groupe d'au moins un utilisateur ou au moins un dispositif de lecture. Par exemple, outre un identifiant de zone géographique (« zone ID »), il peut s'agir d'un identifiant d'une catégorie d'utilisateurs (« hommes », « femmes », « abonnés premium », « abonnés basiques », etc.) ou un identifiant d'une catégorie de dispositifs de lecture ; - etc.

Claims (19)

  1. REVENDICATIONS1. Procédé de gestion de listes de lecture personnalisées du type comprenant un gabarit d'identifiant uniforme de ressource et une liste d'identifiants de segments, caractérisé en ce qu'il comprend une première phase de gestion, par un premier dispositif intermédiaire, d'une requête de demande de liste, transmise (1-1,
  2. 2-1, 7-1, 8- 1, 13-1, 14-1-) par un dispositif de lecture et paramétrée avec un identifiant d'un premier contenu, et un identifiant de groupe définissant un groupe d'au moins un utilisateur ou au moins un dispositif de lecture, la première phase comprenant les étapes suivantes : a) obtention (1-2 et 1-3, 2-2 et 2-3, 7-2 et 7-3, 8-2 et 8-3, 13-2 et 13-3, 14-2 et 14-3) d'une liste de lecture initiale comprenant d'une part un premier gabarit d'identifiant uniforme de ressource pointant vers un premier serveur et préparamétré avec l'identifiant du premier contenu, et d'autre part une première liste d'identifiants de segments, chaque identifiant de segment de la première liste permettant, quand il est utilisé comme paramètre du premier gabarit, de générer un identifiant uniforme de ressource pointant vers un segment du premier contenu ; b) construction (1-4 à 1-8, 2-4 à 2-12, 7-4 à 7-8, 8-4 à 8-8, 13-4, 14-4 à 14-6) d'une liste de lecture finale, comprenant d'une part un deuxième gabarit d'identifiant uniforme de ressource pointant vers un second dispositif intermédiaire, confondu ou non avec le premier dispositif intermédiaire, et pré-paramétré avec l'identifiant du premier contenu et l'identifiant de groupe, et d'autre part une deuxième liste d'identifiants de segments virtuels, chaque identifiant de segment virtuel permettant, quand il est utilisé comme paramètre du deuxième gabarit, de générer un identifiant uniforme de ressources pointant vers un desdits segments virtuels, chaque segment virtuel étant associé soit à un segment du premier contenu soit à un segment alternatif d'un ensemble de segments alternatifs compris dans au moins un contenu alternatif ; c) transmission (1-9, 2-13, 7-9, 8-9, 13-5, 14-7) de la liste de lecture finale au dispositif de lecture.2. Procédé selon la revendication 1, caractérisé en ce que le premier contenu appartient au groupe comprenant des contenus de vidéo à la demande et des contenus diffusés en direct.
  3. 3. Procédé selon l'une quelconque des revendications 1 à 2, caractérisé en ce que l'étape b) comprend une étape de stockage (1-8, 7-8) d'informations permettant, pour chaque identifiant de segment virtuel de la deuxième liste, qui identifie un segment virtuel associé à un segment donné du premier contenu ou un segment donné dudit au moins un contenu alternatif : d'obtenir un identifiant uniforme de ressource pointant vers ledit segment donné, à partir d'un n-uplet comprenant ledit identifiant de segment virtuel de la deuxième liste, l'identifiant de groupe et l'identifiant du premier contenu.
  4. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la liste de lecture initiale comprend en outre au moins une information de changement, relative à la possibilité d'insérer un ou plusieurs segments alternatifs dans le premier contenu ou de remplacer un ou plusieurs segments du premier contenu par un ou plusieurs segments alternatifs, et en ce que l'étape b) comprend les étapes suivantes : en fonction dudit identifiant de groupe et pour chaque information de changement, obtention (1-4 à 1-7, 2-4 à 2-11, 7-4 à 7-7, 8-4 à 8-7) d'une liste de lecture d'un contenu alternatif donné, comprenant d'une part un troisième gabarit d'identifiant uniforme de ressource, pointant vers un serveur de contenus alternatifs confondu ou non avec le premier serveur, et pré-paramétré avec l'identifiant dudit contenu alternatif donné, et d'autre part une troisième liste d'identifiants de segments alternatifs dudit contenu alternatif donné ; création (1-8, 2-12, 7-8, 8-8) de ladite deuxième liste d'identifiants de segment virtuels, en combinant la première liste d'identifiants de segments avec la ou chaque troisième liste d'identifiants de segments alternatifs, en fonction de la ou chaque information de changement.
  5. 5. Procédé selon la revendication 4, caractérisé en ce que l'étape obtention d'une liste de lecture d'un contenu alternatif donné, en fonction dudit identifiant de groupe et pour chaque information de changement, comprend les étapes suivantes : obtention (1-4 et 1-5, 2-4 et 2-5, 2-8 et 2-9, 7-4 et 7-5, 8-4 et 8-5), par un mécanisme de décision interne au premier dispositif intermédiaire ou auprès d'un serveur de décision, d'un identifiant de contenu alternatif, en fonction de l'identifiant de groupe et d'un identifiant de ladite information de changement ; obtention (1-6 et 1-7, 2-6 et 2-7, 2-10 et 2-11, 7-6 et 7-7, 8-6 et 8-7) de ladite liste de lecture du alternatif donné, possédant l'identifiant de contenu alternatif obtenu.
  6. 6. Procédé selon l'une quelconque des revendications 4 et 5, caractérisé en ce que chaque contenu alternatif appartient au groupe comprenant : des contenus vidéos, notamment des contenus publicitaires ; et des contenus diffusés en direct.
  7. 7. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce que ladite au moins une information de changement est une opportunité de placement, indiquant une possibilité de placement d'un contenu publicitaire dans le premier contenu.
  8. 8. Procédé selon l'une quelconque des revendications 4 à 6, caractérisé en ce que ladite au moins une information de changement est une information de blocage, indiquant une période de blocage pendant laquelle le premier contenu doit être remplacé par un contenu alternatif.
  9. 9. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que l'identifiant de chaque contenu alternatif est identique à l'identifiant du premier contenu, en ce que le premier contenu et chaque contenu alternatif comprennent des segments identiques, exceptée la présence, dans chaque segment de même rang dudit premier contenu et dudit contenu alternatif, d'un tatouage numérique distinct, en ce que chaque contenu alternatif est associé à une autre liste de lecture distincte, comprenant d'une part un autre gabarit d'identifiant uniforme de ressource et d'autre part une autre liste d'identifiants de segments alternatifs dudit contenu alternatif,et en ce que chaque autre liste de lecture se distingue de la liste de lecture initiale : parce que le premier gabarit d'identifiant uniforme de ressources est préparamétré avec un identifiant de variante de contenu qui est différent d'un autre identifiant de variante de contenu avec lequel est pré-paramétré ledit autre gabarit d'identifiant uniforme de ressources ; et/ou parce que la première liste d'identifiants de segments est différente de ladite autre liste d'identifiants de segments.
  10. 10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce qu'il comprend une deuxième phase de gestion, par le second dispositif intermédiaire, d'une requête de demande de segment, transmise (3-1, 4-1, 5-1, 6-1, 9-1, 10-1,
  11. 11-1,
  12. 12-1, 15-1, 16-1) par le dispositif de lecture et paramétrée avec l'identifiant du premier contenu, l'identifiant de groupe, et l'un desdits identifiants de segments virtuels, la deuxième phase comprenant les étapes suivantes : i) identification (3-2, 4-2, 4-8, 5-2, 6-2, 6-8, 9-2, 10-2, 10-9, 11-2, 12-2, 12-10, 15-2, 16-2) d'un segment en fonction des paramètres de ladite requête de demande de segment, le segment identifié étant soit un segment dudit premier contenu soit un segment alternatif dudit au moins un contenu alternatif ; ii) détermination (3-3, 4-3, 4-9, 5-3, 6-3, 6-9, 9-3, 10-3, 10-10, 11-3, 12-3, 12-11, 15- 3, 16-3) d'un identifiant uniforme de ressources pointant vers le segment identifié ; et iii-a) transmission (3-4, 4-4, 4-10, 9-4, 10-4, 10-11, 15-4, 16-4) au dispositif de lecture, de l'identifiant uniforme de ressources déterminé ; ou iii-b) transmission (5-6, 6-6, 6-12, 11-812-8, 12-16) au dispositif de lecture, du segment pointé par l'identifiant uniforme de ressources déterminé. 11. Procédé selon la revendication 10, quand elle dépend de la revendication 3, caractérisé en ce que, dans l'étape i), le second dispositif intermédiaire utilise les informations préalablement stockées dans l'étape de stockage. 12. Procédé selon la revendication 10, quand elle dépend de la revendication 3, caractérisé en ce que, dans l'étape i), le second dispositif intermédiaire exécute un algorithme déterministe, qui prend en entrée l'identifiant du premier contenu,l'identifiant de groupe et l'identifiant de segment virtuel avec lesquels est paramétrée la requête de demande de segment, et qui génère en sortie le segment identifié.
  13. 13. Procédé selon l'une quelconque des revendications 10 à 12, quand elle dépend de l'une quelconque des revendications 4 à 8, caractérisé en ce que la deuxième phase comprend en outre une étape d'obtention (9-3, 10-3, 10-10) d'informations de chaînage décrivant au moins un segment virtuel qui suit, dans la deuxième liste d'identifiants de segments virtuels, le segment virtuel pointé par ladite requête de demande de segment, et en ce que l'étape iii-a) est précédée d'une étape de copie (9-3, 10-3, 10-10), par insertion ou remplacement, desdites informations de chaînage dans l'identifiant uniforme de ressources pointant vers le segment identifié, et en ce que, en réponse à une requête de demande de segment transmise par le dispositif de lecture et paramétrée avec l'identifiant uniforme de ressources transmis par le second dispositif intermédiaire, le premier serveur ou le serveur de contenus alternatifs copie (9-6, 10-6, 10-13), par insertion ou remplacement, lesdites informations de chaînage dans le segment identifié, avant de le transmettre au dispositif de lecture.
  14. 14. Procédé selon l'une quelconque des revendications 10 à 12, quand elle dépend de l'une quelconque des revendications 4 à 8, caractérisé en ce que la deuxième phase comprend en outre une étape d'obtention (11-6, 12-6, 12-14) d'informations de chaînage décrivant au moins un segment virtuel qui suit, dans la deuxième liste d'identifiants de segments virtuels, le segment virtuel pointé par ladite requête de demande de segment, et en ce que l'étape iii-b) est précédée d'une étape de copie (11-7, 12-7, 12-15), par insertion ou remplacement, desdites informations de chaînage dans le segment pointé par l'identifiant uniforme de ressources déterminé.
  15. 15. Procédé selon la revendication 10, quand elle dépend de la revendication 9, caractérisé en ce que, dans l'étape i), le second dispositif intermédiaire exécute un algorithme déterministe, qui prend en entrée l'identifiant du premier contenu, l'identifiant de groupe et l'identifiant du segment virtuel pointé, et qui génère en sortie une information indiquant si le segment associé au segment virtuel pointé par laditerequête de demande de segment est un segment du premier contenu ou un segment alternatif.
  16. 16. Produit programme d'ordinateur, comprenant des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 15, lorsque ledit programme est exécuté sur un ordinateur.
  17. 17. Médium de stockage lisible par ordinateur et non transitoire, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur ou un processeur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 15.
  18. 18. Premier dispositif intermédiaire pour la gestion de listes de lecture personnalisées du type comprenant un gabarit d'identifiant uniforme de ressource et une liste d'identifiants de segments, caractérisé en ce qu'il comprend des moyens de gestion d'une requête de demande de liste, transmise par un dispositif de lecture et paramétrée avec un identifiant d'un premier contenu, et un identifiant de groupe définissant un groupe d'au moins un utilisateur ou au moins un dispositif de lecture, les moyens de gestion comprenant : - des moyens d'obtention d'une liste de lecture initiale comprenant d'une part un premier gabarit d'identifiant uniforme de ressource pointant vers un premier serveur et pré-paramétré avec l'identifiant du premier contenu, et d'autre part une première liste d'identifiants de segments, chaque identifiant de segment de la première liste permettant, quand il est utilisé comme paramètre du premier gabarit, de générer un identifiant uniforme de ressource pointant vers un segment du premier contenu ; - des moyens de construction d'une liste de lecture finale, comprenant d'une part un deuxième gabarit d'identifiant uniforme de ressource pointant vers un second dispositif intermédiaire, confondu ou non avec le premier dispositif intermédiaire, et pré-paramétré avec l'identifiant du premier contenu et l'identifiant de groupe, et d'autre part une deuxième liste d'identifiants de segments virtuels, chaque identifiant de segment virtuel permettant, quand il est utilisé comme paramètre du deuxième gabarit, de générer un identifiant uniforme de ressources pointant vers un desdits segments virtuels, chaquesegment virtuel étant associé soit à un segment du premier contenu soit à un segment alternatif d'un ensemble de segments alternatifs compris dans au moins un contenu alternatif ; des moyens de transmission de la liste de lecture finale au dispositif de lecture.
  19. 19. Second dispositif intermédiaire pour la gestion de listes de lecture personnalisées du type comprenant un gabarit d'identifiant uniforme de ressource et une liste d'identifiants de segments, caractérisé en ce qu'il comprend des moyens de gestion d'une requête de demande de segment, transmise par un dispositif de lecture et paramétrée avec un identifiant d'un premier contenu, un identifiant de groupe définissant un groupe d'au moins un utilisateur ou au moins un dispositif de lecture, et un identifiant de segment virtuel, les moyens de gestion comprenant : des moyens d'identification d'un segment en fonction des paramètres de ladite requête de demande de segment, le segment identifié étant soit un segment dudit premier contenu soit un segment alternatif dudit au moins un contenu alternatif ; des moyens de détermination d'un identifiant uniforme de ressources pointant vers le segment identifié ; et des moyens de transmission au dispositif de lecture, de l'identifiant uniforme de ressources déterminé ; ou des moyens de transmission au dispositif de lecture, du segment pointé par l'identifiant uniforme de ressources déterminé.
FR1354503A 2013-05-17 2013-05-17 Procede de gestion de listes de lecture personnalisees du type comprenant un gabarit d'uri et une liste d'identifiants de segments. Active FR3005820B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1354503A FR3005820B1 (fr) 2013-05-17 2013-05-17 Procede de gestion de listes de lecture personnalisees du type comprenant un gabarit d'uri et une liste d'identifiants de segments.
US14/281,560 US9710473B2 (en) 2013-05-17 2014-05-19 Method for managing personalized playing lists of the type comprising a URL template and a list of segment identifiers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1354503A FR3005820B1 (fr) 2013-05-17 2013-05-17 Procede de gestion de listes de lecture personnalisees du type comprenant un gabarit d'uri et une liste d'identifiants de segments.

Publications (2)

Publication Number Publication Date
FR3005820A1 true FR3005820A1 (fr) 2014-11-21
FR3005820B1 FR3005820B1 (fr) 2015-05-29

Family

ID=48782501

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1354503A Active FR3005820B1 (fr) 2013-05-17 2013-05-17 Procede de gestion de listes de lecture personnalisees du type comprenant un gabarit d'uri et une liste d'identifiants de segments.

Country Status (2)

Country Link
US (1) US9710473B2 (fr)
FR (1) FR3005820B1 (fr)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9131125B2 (en) * 2008-03-13 2015-09-08 The Directv Group, Inc. Method and apparatus for redirecting a receiving device in the event of a programming blackout
US9432431B2 (en) * 2014-03-18 2016-08-30 Accenture Global Servicse Limited Manifest re-assembler for a streaming video channel
US10599705B2 (en) * 2014-03-20 2020-03-24 Gracenote Digital Ventures, Llc Retrieving and playing out media content for a personalized playlist including a content placeholder
US20150347415A1 (en) * 2014-05-30 2015-12-03 Apple Inc. Http live streaming dateranges
US20160080470A1 (en) * 2014-09-12 2016-03-17 Net2.TV, LTD. Server-side playlist stitching
US9112849B1 (en) 2014-12-31 2015-08-18 Spotify Ab Methods and systems for dynamic creation of hotspots for media control
US20170102837A1 (en) * 2015-10-07 2017-04-13 Spotify Ab Dynamic control of playlists using wearable devices
US10212171B2 (en) 2015-10-07 2019-02-19 Spotify Ab Dynamic control of playlists
US20170142172A1 (en) * 2015-11-13 2017-05-18 Le Holdings (Beijing) Co., Ltd. Video Player for Multiple Cameras, Playing System and Playing Method
CN105898370A (zh) * 2015-11-13 2016-08-24 乐视云计算有限公司 用于多机位的视频播放器、播放系统及播放方法
CN109690674B (zh) * 2016-09-08 2021-05-11 索尼公司 信息处理装置、信息处理方法和程序
CN108965097A (zh) * 2017-05-17 2018-12-07 北京博瑞彤芸文化传播股份有限公司 一种资讯信息的处理方法
US10652300B1 (en) * 2017-06-16 2020-05-12 Amazon Technologies, Inc. Dynamically-generated encode settings for media content
US10839053B2 (en) * 2018-01-12 2020-11-17 Cisco Technology, Inc. Secure watermark for an adaptive bitrate client
US10904309B1 (en) * 2018-03-05 2021-01-26 .Amazon Technologies, Inc. Managing storage and transmission data size in video packaging systems
CN110290049B (zh) * 2019-05-20 2023-03-24 深圳壹账通智能科技有限公司 消息推送方法、服务器及计算机可读存储介质
IT201900013227A1 (it) * 2019-07-29 2021-01-29 Sky Italia S R L Metodo, dispositivo, sistema, programma per elaboratore e supporto per programma per generare un canale lineare in streaming (Canale lineare in streaming)
CN112584255B (zh) * 2020-12-04 2023-05-26 广州虎牙科技有限公司 一种流媒体数据的播放方法、装置、计算机设备和存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120290644A1 (en) * 2010-01-18 2012-11-15 Frederic Gabin Methods and Arrangements for HTTP Media Stream Distribution
WO2013033565A1 (fr) * 2011-08-31 2013-03-07 Qualcomm Incorporated Procédés de signalisation de commutation fournissant une commutation améliorée entre représentations pour diffusion en flux http adaptative

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7668842B2 (en) * 2002-10-16 2010-02-23 Microsoft Corporation Playlist structure for large playlists
US8914833B2 (en) * 2011-10-28 2014-12-16 Verizon Patent And Licensing Inc. Video session shifting using a provider network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120290644A1 (en) * 2010-01-18 2012-11-15 Frederic Gabin Methods and Arrangements for HTTP Media Stream Distribution
WO2013033565A1 (fr) * 2011-08-31 2013-03-07 Qualcomm Incorporated Procédés de signalisation de commutation fournissant une commutation améliorée entre représentations pour diffusion en flux http adaptative

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
GERARD FERNANDO ET AL: "DASH Evaluation Experiment #4: Delivery Format Addressing", 94. MPEG MEETING; 11-10-2010 - 15-10-2010; GUANGZHOU; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11),, no. M18012, 28 October 2010 (2010-10-28), XP030046602 *
GERARD FERNANDO ET AL: "HTTP Streaming of MPEG Media - Response to CfP", 93. MPEG MEETING; 26-7-2010 - 30-7-2010; GENEVA; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11),, no. M17756, 22 July 2010 (2010-07-22), XP030046346 *

Also Published As

Publication number Publication date
US20140365491A1 (en) 2014-12-11
US9710473B2 (en) 2017-07-18
FR3005820B1 (fr) 2015-05-29

Similar Documents

Publication Publication Date Title
FR3005820A1 (fr) Procede de gestion de listes de lecture personnalisees du type comprenant un gabarit d'uri et une liste d'identifiants de segments.
US10735800B2 (en) Rendering content and time-shifted playback operations for personal over-the-top network video recorder
EP2200258A1 (fr) Procédé de distribution d'un contenu vers un utilisateur
FR2851389A1 (fr) Procede et dispositif de gestion de requetes dans une architecture du type client-serveur
EP2936783B1 (fr) Technique de communication dans un réseau de communication centré sur les informations
FR3094166A1 (fr) Procédé de gestion de contenus multimédia et dispositif pour la mise en œuvre du procédé
FR2944933A1 (fr) Procede de diffusion de donnees numeriques.
EP3942837A1 (fr) Procédé de gestion de contenus multimédia et dispositif pour la mise en oeuvre du procédé
FR3005386A1 (fr) Procede et dispositif de fourniture d’une partie deja diffusee d’un flux multimedia, terminal utilisateur, programme d’ordinateur et medium de stockage correspondants
EP1997040A1 (fr) Procédé, dispositif et système de gestion d'informations structurées au sein d'une scène graphique
FR2952204A1 (fr) Procede de generation d'un flux web et un systeme associe
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'ordinateur correspondants
EP3205067B1 (fr) Diffusion de contenus en streaming dans un réseau pair à pair
FR3096541A1 (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.
FR2956787A1 (fr) Procede et serveur pour detecter un programme video recu par un usager
WO2023208688A1 (fr) Gestion de la restitution d'un contenu multimédia
WO2021105585A1 (fr) Procédé de gestion d'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'ordinateur correspondants
EP1441526A1 (fr) Procédé d'enregistrement thématique de contenus numériques à diffusion programmée
WO2021209706A1 (fr) Gestion de l'accès à des contenus numériques accessibles en téléchargement progressif adaptatif et encodés selon une méthode d'encodage à débit variable, en fonction d'une charge réseau
FR3030982A1 (fr) Procede d'enregistrement automatique de contenus video recommandes, dispositif et produit programme d'ordinateur associes.
EP4109905A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique en mode économiseur d'écran
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.
FR3001354A1 (fr) Procede et dispositif de fourniture d’un contenu multimedia, equipement source de diffusion,terminal utilisateur, programmed’ordinateur et medium destockage correspondants
US20170054780A1 (en) Real-time file generation and delivery
FR3093885A1 (fr) procédé de gestion du téléchargement d’images associées à des sauts d’images susceptibles d’être réalisés lors d’une lecture accélérée d’un contenu multimédia.

Legal Events

Date Code Title Description
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

PLFP Fee payment

Year of fee payment: 8

TP Transmission of property

Owner name: MK SYSTEMS USA INC., US

Effective date: 20201210

TP Transmission of property

Owner name: MK SYSTEMS USA INC., US

Effective date: 20201216

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11