FR3020542A1 - Procede de gestion de la selection de la representation des segments d'un contenu multimedia transmis sur un reseau de communication. - Google Patents

Procede de gestion de la selection de la representation des segments d'un contenu multimedia transmis sur un reseau de communication. Download PDF

Info

Publication number
FR3020542A1
FR3020542A1 FR1453655A FR1453655A FR3020542A1 FR 3020542 A1 FR3020542 A1 FR 3020542A1 FR 1453655 A FR1453655 A FR 1453655A FR 1453655 A FR1453655 A FR 1453655A FR 3020542 A1 FR3020542 A1 FR 3020542A1
Authority
FR
France
Prior art keywords
representation
segment
terminal
server
content
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.)
Withdrawn
Application number
FR1453655A
Other languages
English (en)
Inventor
Bertrand Berthelot
Patrice Houze
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1453655A priority Critical patent/FR3020542A1/fr
Priority to EP15725772.6A priority patent/EP3135042A1/fr
Priority to PCT/FR2015/051081 priority patent/WO2015162376A1/fr
Priority to US15/301,710 priority patent/US20170127103A1/en
Publication of FR3020542A1 publication Critical patent/FR3020542A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541Rights Management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633Control signals issued by server directed to the network components or client
    • H04N21/6332Control signals issued by server directed to the network components or client directed to client
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention a trait à un procédé de gestion de la représentation des segments de données d'un contenu reçu par un terminal depuis un serveur, le procédé comportant une étape d'obtention d'un document à partir duquel sont générées des adresses universelles, à une adresse étant associée une représentation du segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, le segment étant apte à être reçu depuis le serveur et décodé par le terminal, caractérisé en ce qu'il comprend les étapes suivantes au niveau du terminal : - une étape de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation apte à être prise en compte avant le décodage du segment reçu.

Description

Domaine technique L'invention se rapporte à un procédé de sélection de la représentation des segments d'un contenu multimédia transmis sur un réseau de communication. On entend par contenu multimédia tout contenu audio ou vidéo, ou plus généralement tout autre contenu numérique. L'invention concerne plus spécifiquement la transmission et la réception de contenus multimédia sur un réseau, en particulier le téléchargement continu, aussi appelé streaming, de contenus multimédia sur un réseau. Elle concerne plus précisément une communication utilisant des adresses universelles de contenus. Elle s'applique notamment à tout terminal client (dans la suite appelé simplement terminal) capable de communiquer sur un réseau de télécommunications pour accéder à un contenu multimédia via une adresse universelle, aussi appelée URI (de l'anglais Uniform Ressource identifier). On entend ici par représentation d'un contenu, une façon particulière de créer un flux de données représentatif d'un contenu. Un flux de données créé avec un débit d'encodage est un exemple d'une représentation particulière du 20 contenu. Etat de la technique Pour accéder à un contenu multimédia, un terminal client a généralement recours à une adresse universelle (URI). Une telle adresse fournit à la fois un accès au contenu et des indications sur le protocole associé pour le 25 consommer (par consommer, on entend par exemple, dans le cas d'un contenu vidéo, télécharger/recevoir le contenu pour ensuite éventuellement le décoder, puis le visualiser). Une adresse URI est une chaîne de caractères identifiant une ressource physique ou abstraite. La syntaxe d'une adresse URI respecte un ensemble de 30 normes édictées par l'IETF (Internet Engineering Task Force), et notamment la spécification RFC 3986 (spécification : Uniform Resource Identifier (URI); Generic Syntax). Une telle adresse universelle prendra par exemple la forme dvb://contenu1, rtsp://contenu2, HTTP://contenu3, ftp://contenu4, etc. L'accès au contenu multimédia est déclenché par une requête, au travers d'une adresse URI. Une illustration classique en est un service de vidéo à la demande : - une première étape consiste pour le terminal à télécharger un document décrivant les paramètres d'accès au service (SDP pour Session Description Protocol) via un protocole HTTP (de l'anglais Hyper Text Transport Protocol un protocole de communication client-serveur développé pour les réseaux Internet et en particulier le Web ; - lors d'une seconde étape, le service démarre effectivement, c'est-à-dire que le terminal client peut recevoir et afficher la vidéo, grâce aux informations fournies dans le document (dans cet exemple, le SDP). On notera que ce document peut être un fichier informatique ou un ensemble d'informations descriptives du contenu accessible à une certaine adresse. Dans la suite, on se réfèrera selon le contexte à l'expression « fichier de description » ou « document ». On notera que ce type d'accès au service peut nécessiter la présence d'un serveur (notamment dans le cas d'une communication point à point ou « unicast ») ou non (dans le cas d'une communication point vers multipoint de type « broadcast » ou « multicast »). Notamment, le protocole HTTP est de type point à point (« unicast »), et implique de ce fait la présence d'un serveur afin de traiter la requête d'un client dit client HTTP. Il est fréquent, dans ce contexte du protocole HTTP, de recourir, pour échanger les données entre le client et le serveur, à une technique de type « HTTP adaptive streaming ». Ce type de technique permet notamment d'offrir une bonne expérience utilisateur tout en tenant compte par exemple des variations de bande passante sur la liaison entre le terminal client et le serveur de contenu. Classiquement, différentes qualités peuvent être encodées pour la même vidéo, correspondant par exemple à différents débits. Chaque débit est lui-même découpé en segments temporels (ou « fragments » de contenu). La description de ces différents débits et de la segmentation, ainsi que les fragments de contenu, sont mis à disposition du terminal client sur une plateforme de service. Pour pouvoir accéder au contenu complet, il est donc nécessaire de connaître de nombreuses adresses (URI) correspondant à de multiples segments (appelés segments médias par l'homme du métier). Il existe plusieurs solutions pour faciliter la distribution d'un tel contenu en mode streaming. Ces méthodes proposent d'adresser au client un ou plusieurs fichiers de description intermédiaires, appelés aussi documents, ou manifests, ou encore ressources, contenant les adresses des différents segments aux différentes qualités du contenu multimédia. Le principe de base de ces méthodes est de mettre à disposition des contenus avec différentes variantes de débit, chacune des variantes étant disponible sous forme de segments contigus de données média qui sont téléchargeables par les clients à l'aide du protocole HTTP. La lecture d'un contenu selon la technique « HTTP adaptative streaming » pour un terminal client donné consiste à : - télécharger et analyser le document de description qui donne la description du contenu, les variantes de débits disponibles, et les moyens d'accéder aux segments de données pour chaque variante de débit ; - télécharger les segments de données, et pour chaque segment sélectionner une représentation particulière, en particulier sélectionner un débit d'encodage du segment à télécharger ; - puis analyser et rassembler les segments de données afin de les décoder pour lire le contenu. Il existe deux modes de sélection (ou d'adaptation) de la représentation des segments. Selon un premier mode, la sélection est à la charge du terminal client ; selon un second mode, la sélection est à la charge du serveur.
Selon le premier mode, c'est au terminal client de sélectionner la représentation pour chaque segment de données média en fonction de paramètres internes au client (ex : bande passante mesurée, capacités du terminal, etc.) ; en particulier, le terminal client sélectionne pour chaque segment un débit d'encodage donné. Si la bande passante mesurée par le client est suffisante, le client sélectionnera le plus souvent un débit d'encodage élevé. Cependant, le fait de laisser la décision d'adaptation uniquement au terminal client empêche le distributeur de contenu d'avoir une maîtrise de sa plate-forme (serveurs), de son réseau, et des services. Le risque majeur pour le distributeur est d'avoir à servir un nombre trop élevé de requêtes d'accès aux segments avec un débit d'encodage élevé. La conséquence serait une saturation de la bande passante réseau ou des serveurs HTTP. Il peut également en résulter une baisse de la qualité de restitution sur le terminal client . Dans le deuxième mode, la représentation est choisie par le serveur ou un composant quelconque d'une plate-forme de diffusion (ex : proew CDN). Dans cette configuration, le contenu adressé au client peut correspondre à un segment d'un débit différent de celui demandé par le client, et ceci pour s'adapter aux conditions réseau par exemple. Les inventeurs ont constaté que ce mécanisme pose problème au terminal car les paramètres de décodage sont potentiellement différents d'une représentation (débit) à une autre, et le terminal n'a alors aucun moyen de savoir que le segment reçu correspond à une représentation différente de celle demandée. Il en résulte des erreurs dans le décodage des segments reçus. L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique. L'invention A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de gestion de la représentation des segments de données d'un contenu reçu par un terminal depuis un serveur, le procédé comportant une étape d'obtention d'un document à partir duquel sont générées des adresses universelles, à une adresse étant associée une représentation du segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, le segment étant apte à être reçu depuis le serveur et décodé par le terminal, caractérisé en ce qu'il comprend les étapes suivantes au niveau du terminal : - une étape de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation apte à être prise en compte avant le décodage du segment reçu. Grâce à cette solution, la représentation des segments transmis par le serveur est toujours une représentation souhaitée par le serveur ; le serveur a donc la maîtrise du choix des représentations ; de plus, le terminal est prévenu du changement de représentation fait par le serveur par le biais d'une information indiquant ce changement. Le terminal peut alors prendre en compte l'information et adapter son fonctionnement notamment en paramétrant correctement les paramètres liés au décodage des segments reçu ; ce sans entraîner des erreurs de décodage et donc de restitution du segment lié au fait que la représentation des segments reçus n'est pas compatible avec le paramétrage courant utilisé pour le décodage des segments média. Cette solution évite aussi une mise à jour du fichier de description.
Le segment reçu selon la deuxième représentation est transmis dans un message incluant un entête http et une partie utile incluant le segment. Selon un premier mode de réalisation, l'information est incluse dans l'entête http. Un segment inclut une première partie incluant des champs et une seconde partie incluant au moins un segment codé. Selon un second mode de réalisation, l'information est incluse dans un champ (B-evt) de ladite première partie. Les modes de réalisation décrits ci-dessus ont pour avantage de rendre possible la lecture de l'information avant le début de décodage dudit au moins un segment.
Selon un aspect matériel, l'invention se rapporte à un terminal apte à recevoir des segments d'un contenu, le terminal ayant accès un document à partir duquel sont générées des adresses universelles, à une adresse étant associée une représentation d'un segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, caractérisé en ce qu'il comprend - un module de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie, - un module de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation, - un module de traitement apte à prendre en compte l'information avant le décodage du segment reçu.
On comprend ici que le module de traitement prend en compte l'information indiquant la représentation choisie par le serveur de manière à décoder ledit au moins un segment reçu sans générer d'erreurs de décodage. Selon un autre aspect fonctionnel, l'invention se rapporte à un procédé d'émission, par un serveur, de segments d'un contenu selon une représentation respective donnée, caractérisé en ce qu'il comprend les étapes suivantes : - une étape de réception d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de transmission dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième 20 représentation. Selon un autre aspect matériel, l'invention se rapporte à un serveur apte à émettre des segments d'un contenu sur un réseau, caractérisé en ce qu'il comprend - un module de réception d'une requête d'accès à au moins un segment 25 selon une première représentation choisie, - un module de transmission dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation. Selon un autre aspect matériel, l'invention se rapporte à un programme 30 d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes du procédé s'exécutant sur le terminal définies ci-dessus. Selon un autre aspect matériel, l'invention se rapporte à un programme d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes du procédé s'exécutant sur le serveur définies ci-dessus. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés. Les figures: La figure 1 représente une architecture de streaming basée sur l'utilisation du protocole HTTP sur Internet selon un mode de réalisation de l'invention. Les figures 2 et 3 représentent les circuits des équipements impliqués dans le procédé de l'invention.
La figure 4 représente un chronogramme selon un mode de réalisation de l'invention. La figure 5 représente un exemple de réalisation de la composition d'un flux de données transmis par le serveur à destination du terminal suite à une demande du terminal de recevoir des segments.
Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente un système informatique SYS incluant un terminal client 1, une plateforme de service 3, et un serveur de contenus 8, apte à fournir un contenu sur requête du terminal client 1. Dans notre exemple de réalisation, le terminal, la plateforme et le serveur communique via un réseau Internet 2. En référence à la figure 2, le terminal 1 comprend des ressources physiques et/ou logicielles, en particulier : - un processeur CPU1, - un premier module de stockage MEM1, - un module de restitution tel qu'un écran ECR, - un premier module de communication COM1 pour communiquer avec le réseau 2. Les modules décrits ci-dessus ainsi que le premier microprocesseur CPU1 sont reliés entre eux par l'intermédiaire d'un premier bus BUS1.
En référence à la figure 3, le serveur 8 comprend - un second processeur CPU2, - un second module de stockage MEM2, stockant notamment un ou plusieurs contenus CNT, - un second module de communication COM2 pour communiquer avec le réseau 2. Le second module, inclus dans le serveur, est relié au second processeur CPU2 par l'intermédiaire d'un second bus BUS2. A noter que les bus décrits ci-dessus ont pour fonction d'assurer le transfert de données numériques entre les différents circuits reliés au microprocesseur par un bus. Dans notre exemple, le bus en question inclut un bus de données et un bus de contrôle. A noter aussi que, dans notre exemple, les mémoires décrites ci-dessus sont des mémoires permanentes accessibles en écriture et lecture, par exemple de type flash.
Les terminaux incluent également une mémoire vive (non représentée) respective pour stocker de manière non durable des données de calcul utilisées lors de la mise en oeuvre d'un procédé selon des modes de réalisation. Ces mémoires ne sont pas représentées sur les dessins car inutiles pour l'exposé de l'invention.
Dans notre exemple, l'architecture choisie pour illustrer l'invention est une architecture dite « streaming » basée sur l'utilisation du protocole HTTP. Classiquement, le terminal client (1) souhaite entrer en communication avec un serveur de contenus (8) pour télécharger un contenu multimédia composé d'un ou plusieurs médias (audio, vidéo, etc.).
A noter que l'expression « terminal client » sous-entend la présence dans le terminal d'un module client. Dans notre exemple, ce module client est un programme d'ordinateur. Dans la suite de l'exemple, comme exposé ci-dessus, on se positionne dans un contexte de streaming selon la norme MPEG DASH. Le terminal (1) interroge tout d'abord une plateforme de service (3) pour obtenir l'adresse (ici, l'URL, mais de manière plus générale, une adresse universelle de type URI) du document de description 4 du contenu multimédia (y) ; dans la suite, ce document est un fichier de type MPD (y.mpd).
La plateforme de service (3) répond en fournissant au terminal l'adresse du fichier 4; dans l'exemple il s'agit de l'URL « HTTP://x.com/y.mpd » symbolisant un fichier y de type « mpd » qui peut être téléchargé sur le serveur de contenus (8) « x.com ». Un exemple de fichier de description 4 conforme à la norme MPEG DASH est présenté dans l'annexe 1. Les champs pertinents dans le contexte de l'invention, qui permettent notamment de générer les adresses universelles, sont présentés en italique. Le fichier de description 4 permet de générer des adresses de segments de média Cette construction met en oeuvre un mécanisme préalable de résolution d'adresses universelles (URI) décrit dans la RFC 3986 mentionnée ci-dessus. Le terminal client doit interpréter certains champs et les modifier de manière appropriée pour construire la première adresse universelle (URL ou URI) du segment de média.
Cette résolution d'adresse URI est faite selon l'élément BaseURL, qui peut être présent à différents niveaux de la hiérarchie du fichier 4. Dans cet exemple, les adresses URL sont construites à l'aide des deux champs « BaseUrl » (« HTTP:// x.com/ » et « video/ ») et « SegmentTemplate ». Le « SegmentTemplate » précisé par la norme MPEG/DASH est un procédé générique de construction des adresses (URI) intermédiaires à partir de différents identifiants, dans notre exemple : - $Time$ : à remplacer par le temps de début du segment de média. Ce temps est fourni par la « SegmentTimeline » qui indique ici un offset de 180180 pour chaque début de nouveau segment ; - $Number$ : à remplacer par le numéro d'ordre du segment de média désiré ; - $Bandwidth$ : à remplacer par la valeur de l'attribut « bandwidth » (bande passante) de la représentation ciblée. Ainsi, les deux premières adresses URL d'accès aux deux premiers segments vidéo pour une qualité (ou débit) de 500 kbps (Kilo Bits par seconde) sont ici : 1. HTTP:// x.com/video/500000/0.mp4v, et 2. HTTP:// x.com/video/500000/180180.mp4v A noter qu'à un même segment peut correspondre plusieurs représentations possibles. Ici, à chaque représentation correspond un débit respectif. Par exemple, HTTP:// x.com/video/500000/0.mp4v HTTP:// x.com/video/2000000/0.mp4v sont deux représentations possibles du premier segment, l'une correspondant à un débit de 500kbps l'autre à 2000kbps La figure 4 est une vue schématique des échanges ayant lieu entre le terminal, la plateforme et le serveur de contenus. On suppose que le terminal 1 souhaite recevoir un contenu (y). Lors d'une première étape ET1, le terminal 1 interroge la plateforme de service 3 pour obtenir l'adresse (ici, l'URL, mais de manière plus générale, une adresse universelle de type URI) du document de description 4 du contenu multimédia (y) ; dans la suite, ce document est un fichier de type MPD (y.mpd). Lors d'une deuxième étape ET2, la plateforme de service (3) répond en fournissant au terminal l'adresse du fichier 4, dans l'exemple il s'agit de l'URL « HTTP://x.com/y.mpd » symbolisant un contenu « y » de type « mpd » qui peut être téléchargé sur le serveur de contenus (8) « x.com ». Lors d'une troisième étape ET3, le terminal requiert REQ(4) auprès du serveur 8 un téléchargement du fichier de description 4.
Lors d'une quatrième étape ET4, le terminal reçoit et stocke le fichier de description 4. Lors d'une cinquième étape ET5, le terminal (1) accède au premier segment grâce à la première URL1 décrite ci-dessus : HTTP:// x.com/video/2000000/0.mp4v.
Lors d'une sixième étape ET6, le serveur 8 transmet un premier flux de données F1/2000k, incluant les premiers segments. A réception, le terminal peut décoder les segments reçus et les restituer. Lors d'une septième étape ET7, le terminal (1) requiert un accès au second segment grâce à la seconde URL2 décrite ci-dessus : HTTP:// x.com/video/2000000/180180.mp4v. A réception de la demande de téléchargement du second segment, lors d'une huitième étape ET8, le serveur 8 transmet au terminal 1 le second segment F2/500k, incluant le second segment avec un débit inférieur à celui demandé par le terminal (1). En d'autres mots, la représentation fournie par le serveur ne correspond pas à celle demandée par le terminal. Le débit choisi par le serveur correspond au débit v1 (500k) si on se réfère au fichier de description à l'annexe 1. Selon l'invention, en complément d'un segment transmis, le serveur fournit également au terminal une information relative à la représentation du segment transmis. Cette information a pour vocation d'être lu avant le décodage du segment reçu de manière à ce que les paramètres de décodage soit adapté au segment reçu. Rappelons que, dans la norme MPEG DASH, le serveur transmet des segments sous forme de réponse http, au moyen d'un entête http et d'une partie utile (appelée payload dans la norme).
Dans notre exemple de réalisation, la fourniture de l'information relative à la représentation choisie par le serveur peut s'effectuer de différentes manières. Deux variantes vont illustrer deux cas possibles. Selon une première variante, par exemple, l'information sur la représentation peut être insérée dans l'en-tête http de la réponse du serveur au terminal. L'entête est par exemple le suivant : HTTP/1.1 200 OK Date: Tue, 15 Apr 2014 09:16:16 GMT Server: Apache/2.2.25 (Win32) Last-Modified: Tue, 24 Dec 2013 15:02:48 GMT ETag: "200000004b4ee-cda-4ee49099b12b2" Accept-Ranges: bytes Content-Length: 3290 Access-Control-Allow-Origin: * Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/plain Representation: 'v1' Dans notre exemple, un champ nommé arbitrairement « représentation » indique la représentation transmise par le serveur. La valeur « v1 » correspond à une valeur définie dans le fichier de description (voir annexe 1). Si la valeur n'est pas présente dans le fichier de description, le champ « Représentation » peut fournir la valeur exacte du débit utilisé. En d'autres mots, ce champ « Representation » est ajouté pour indiquer la représentation à laquelle appartient le segment contenu dans la payload (partie utile) de la réponse http. Une autre manière d'informer le client de la représentation choisie par le serveur, correspondant à une deuxième variante, est d'insérer l'information dans le segment média, plus précisément dans un champ nommé « box Event » inclut dans le segment SG.
Rappelons en effet que, en référence à la figure 5, dans la norme MPEG DASH, un segment média SG comprend : - une partie HD incluant des champs HD nommés « box Event » - Une partie utile nommée DATA qui comprend des données encodées.. Rappelons que le champ nommé «Box Event » est décrit dans la norme MPEG DASH. Rappelons aussi que MPEG DASH (pour Dynamic Adaptive Streaming over HTTP - norme ISO/IEC 23009-1:2012(E)) de l'organisme de normalisation ISO/IEC est dédié au streaming de contenus multimédia sur Internet. Cette norme est incorporée par référence. Dans cette configuration, En référence à la norme MPEG DASH, l'indication de représentation peut être insérée dans un champ nommé « box Event » de la partie HD. De cette manière, A réception du segment SG, le terminal interprète dans un premier temps ces champs 'Box Event » » et peut alors adapter le paramétrage pour le décodage du segment reçu (F2/500k). Dans notre exemple, à la suite des champs HD, se trouvent les données encodées du segment courant. A noter que ces champs ne se trouvent pas au début de la trame dans tous les cas, mais peuvent se trouver ailleurs dans le segment.
Suite à l'envoi du serveur du flux F2/500k, celui est reçu par le terminal. La suite du procédé est fonction de la variante choisie. Si la première variante a été choisie, lors d'une étape, le terminal extrait l'information représentative de la représentation. Après extraction, le terminal adapte les paramètres de décodage et décode ensuite le segment et le restitue.
Si la deuxième variante a été choisie, le terminal interprète ensuite le segment média. En interprétant ce dernier, le terminal interprète dans un premier temps les champs dits « box Event » inclus dans le segment et dans un second temps le segment. Le terminal a donc connaissance de la représentation et peut donc adapter le paramétrage du décodage comme pour la première variante.
On comprend donc ici qu'à ce stade du procédé, le terminal a connaissance de la représentation choisie par le serveur et qu'il peut en conséquence adapter son fonctionnement pour le décodage. Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent y être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention. A noter que pour la réalisation du procédé de l'invention, le terminal comprend, outre les éléments décrits ci-dessus en référence à la figure 2, - un module de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie, - un module de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation, - un module de traitement apte à prendre en compte l'information avant le décodage du segment reçu. A noter aussi que pour la réalisation du procédé de l'invention, le serveur comprend, outre les éléments décrits ci-dessus en référence à la figure 3, - un module de réception d'une requête d'accès à au moins un segment selon une première représentation choisie, - un module de transmission dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation.
A noter que le te terme « module » utilisé dans ce document, peut correspondre soit à un composant logiciel, soit à un composant matériel, soit encore à un ensemble de composants matériels et/ou logiciels, aptes à mettre en oeuvre la ou les fonctions décrites pour le module.
Annexe 1 <?xml version =1.0'?> <MPD xmlns:xsi="HTTP://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:DASH:schema:MPD:2011" xsi:schemaLocation="urn:mpeg:DASH:schema:MPD:2011 DASH-MPD.xsd" type="dynamic" minimumUpdatePeriod="PT2S" timeShiftBufferDepth="PT30M" availabilityStartTime="2011-12-25T12:30:00" minBufferTime="PT4S" profiles="urn:mpeg:dash:profile:isoff-live:2011"> <13aseURL>HTTP:// xcom/</BaseURL> <Period> <!-- Video --> <AdaptationSet mimeType="video/mp4" codecs="avc1.4D401F" frameRate="30000/1001" segmentAlignment="true" startWithSAP="1"> <13aseURL>video/</BaseURL> <Segmentremplate timescale="90000" initialization="$Bandwidth$/init.mp4 media="$Bandwidth$/$Time$.mp4v"> <SegmentTimeline> <S t="0" d="180180" r="432"/> </SegmentTimeline> </SegmentTemplate> <Representation id="v1" width="640" height="480" bandwidth="500000"/> <Representation id ='v2' width="1280" height="720" bandwidth="2000000"/> </AdaptationSet> </Period> </MPD> Table 1: Exemple de fichier 4 de type MPD selon MPEG/DASH5

Claims (8)

  1. REVENDICATIONS1. Procédé de gestion de la représentation des segments de données d'un contenu reçu par un terminal depuis un serveur, le procédé comportant une étape d'obtention d'un document à partir duquel sont générées des adresses universelles, à une adresse étant associée une représentation du segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, le segment étant apte à être reçu depuis le serveur et décodé par le terminal, caractérisé en ce qu'il comprend les étapes suivantes au niveau du terminal : - une étape de transmission (ET7) d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de réception (ET8) dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation apte à être prise en compte avant le décodage du segment reçu.
  2. 2. Procédé de gestion selon la revendication 1, caractérisé en ce que le segment reçu selon la deuxième représentation est transmis dans un message incluant un entête http et une partie incluant le segment, et en ce que l'information est incluse dans l'entête http.
  3. 3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'un segment (SG) inclut une première partie (HD) incluant au moins un champs (N1,N2,...) et une seconde partie (DATA) incluant au moins un segment codé , caractérisé en ce que l'information est incluse dans un champs (N1,N2,...) de ladite première partie.
  4. 4. Terminal (1) apte à recevoir des segments d'un contenu, le terminal ayant accès un document (4) à partir duquel sont générées des adresses universelles, à une adresse étant associée une représentation d'un segment concerné choisie par le terminal parmi plusieurs représentations décrites dans le document, caractérisé en ce qu'il comprend - un module de transmission d'une requête d'accès à au moins un segment selon une première représentation choisie,- un module de réception dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation, - un module de traitement apte à prendre en compte l'information avant le décodage du segment reçu.
  5. 5. Procédé d'émission, par un serveur, de segments d'un contenu selon une représentation respective donnée, caractérisé en ce qu'il comprend les étapes suivantes : - une étape de réception (ET7) d'une requête d'accès à au moins un segment selon une première représentation choisie, - une étape de transmission (ET11) dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation.
  6. 6. Serveur (8) apte à émettre des segments d'un contenu sur un réseau, caractérisé en ce qu'il comprend - un module de réception d'une requête d'accès à au moins un segment selon une première représentation choisie, - un module de transmission dudit au moins un segment selon une deuxième représentation, et d'une information relative à la deuxième représentation.
  7. 7. Programme d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies dans l'une des revendications 1 à 3.
  8. 8. Programme d'ordinateur comportant des instructions de code qui, lorsque le programme est exécuté par un processeur réalise les étapes définies dans la revendication 5.
FR1453655A 2014-04-23 2014-04-23 Procede de gestion de la selection de la representation des segments d'un contenu multimedia transmis sur un reseau de communication. Withdrawn FR3020542A1 (fr)

Priority Applications (4)

Application Number Priority Date Filing Date Title
FR1453655A FR3020542A1 (fr) 2014-04-23 2014-04-23 Procede de gestion de la selection de la representation des segments d'un contenu multimedia transmis sur un reseau de communication.
EP15725772.6A EP3135042A1 (fr) 2014-04-23 2015-04-21 Procédé de gestion de la sélection de la représentation des segments d'un contenu multimedia transmis sur un réseau de communication
PCT/FR2015/051081 WO2015162376A1 (fr) 2014-04-23 2015-04-21 Procédé de gestion de la sélection de la représentation des segments d'un contenu multimedia transmis sur un réseau de communication
US15/301,710 US20170127103A1 (en) 2014-04-23 2015-04-21 Method for managing the selection of the representation of segments of multimedia content transmitted over a communication network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1453655A FR3020542A1 (fr) 2014-04-23 2014-04-23 Procede de gestion de la selection de la representation des segments d'un contenu multimedia transmis sur un reseau de communication.

Publications (1)

Publication Number Publication Date
FR3020542A1 true FR3020542A1 (fr) 2015-10-30

Family

ID=51293084

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1453655A Withdrawn FR3020542A1 (fr) 2014-04-23 2014-04-23 Procede de gestion de la selection de la representation des segments d'un contenu multimedia transmis sur un reseau de communication.

Country Status (4)

Country Link
US (1) US20170127103A1 (fr)
EP (1) EP3135042A1 (fr)
FR (1) FR3020542A1 (fr)
WO (1) WO2015162376A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180139490A1 (en) * 2015-04-30 2018-05-17 Sony Corporation Reception apparatus, transmission apparatus, and data processing method
KR102190880B1 (ko) * 2016-12-30 2020-12-14 구글 엘엘씨 불가침 매니페스트 프로토콜을 통해 제공되는 스트리밍 콘텐츠를 중단시키는 시스템 및 방법
EP3393129A1 (fr) 2017-04-21 2018-10-24 Alcatel-Lucent España, S.A. Distribution de contenu multimédia à retard réduit

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299552A1 (en) * 2009-05-19 2010-11-25 John Schlack Methods, apparatus and computer readable medium for managed adaptive bit rate for bandwidth reclamation
US20130179588A1 (en) * 2011-09-21 2013-07-11 General Instrument Corporation Adaptive streaming to multicast and constrained-fidelity constant bit rate encoding

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8918533B2 (en) * 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US8977704B2 (en) * 2011-12-29 2015-03-10 Nokia Corporation Method and apparatus for flexible caching of delivered media

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100299552A1 (en) * 2009-05-19 2010-11-25 John Schlack Methods, apparatus and computer readable medium for managed adaptive bit rate for bandwidth reclamation
US20130179588A1 (en) * 2011-09-21 2013-07-11 General Instrument Corporation Adaptive streaming to multicast and constrained-fidelity constant bit rate encoding

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Descriptions of Core Experiments on DASH amendment", 107. MPEG MEETING;13-1-2014 - 17-1-2014; SAN JOSE; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11),, no. N14134, 18 January 2014 (2014-01-18), XP030020872 *
THOMAS STOCKHAMMER: "Generic URN schemes including Multicast Distribution", 101. MPEG MEETING; 16-7-2012 - 20-7-2012; STOCKHOLM; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11),, no. m25998, 15 July 2012 (2012-07-15), XP030054333 *
YASUAKI TOKUMO ET AL: "DASH: Unified Solution for DASH Push Event (CE-DPE)", 104. MPEG MEETING; 22-4-2013 - 26-4-2013; INCHEON; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11),, no. m29144, 17 April 2013 (2013-04-17), XP030057675 *

Also Published As

Publication number Publication date
US20170127103A1 (en) 2017-05-04
EP3135042A1 (fr) 2017-03-01
WO2015162376A1 (fr) 2015-10-29

Similar Documents

Publication Publication Date Title
US10999340B2 (en) Cloud-based video delivery
JP6221142B2 (ja) メディアコンテンツに適応ストリーミングを実行するための方法及び装置
US9392307B2 (en) Smart pre-load for video-on-demand in an HTTP adaptive streaming environment
EP2907315B1 (fr) Heritage de parametres d&#39;identifiant universel de ressource (uri)
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
US20150256862A1 (en) Configurable digital content storage
FR3020542A1 (fr) Procede de gestion de la selection de la representation des segments d&#39;un contenu multimedia transmis sur un reseau de communication.
EP3496407A1 (fr) Procédé de gestion de la consommation électrique d&#39;un dispositif électronique
WO2019002729A1 (fr) Procédé et dispositif de téléchargement de contenu audiovisuel
EP3231190B1 (fr) Procédé et dispositifs permettant une transmission d&#39;un flux de données selon un mode de transmission multipoint
EP2651123A1 (fr) Dispositif client d&#39;enregistrement vidéo personnel, dispositif d&#39;enregistrement vidéo personnel en réseau et procédés de fonctionnement d&#39;un dispositif client d&#39;enregistrement vidéo personnel et d&#39;un dispositif d&#39;enregistrement vidéo personnel en réseau.
FR3031862A1 (fr) Procede de transmission d&#39;un flux de donnees utilisant un protocole de diffusion en direct.
EP2957104B1 (fr) Procédé de sélection de la représentation des segments d&#39;un contenu multimédia transmis sur un réseau de communication
WO2014155017A1 (fr) Transcodage et diffusion adaptative de contenus multimédia
US10750216B1 (en) Method and apparatus for providing peer-to-peer content delivery
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
Episkopos Peer-to-Peer video content delivery optimization service in a distributed network
EP2879352A1 (fr) Contrôle de la diffusion de contenus multimedia
WO2019110906A1 (fr) Procédé de gestion des connexions d&#39;un dispositif électronique
WO2016087750A1 (fr) Procédé de gestion du droit d&#39;accès a un contenu numérique
FR3001353A1 (fr) Procede et dispositif de fourniture d’un contenu multimedia, equipement source de diffusion, programme d’ordinateur et medium de stockage correspondants.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20151030

ST Notification of lapse

Effective date: 20161230