EP3135042A1 - 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 - Google Patents

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

Info

Publication number
EP3135042A1
EP3135042A1 EP15725772.6A EP15725772A EP3135042A1 EP 3135042 A1 EP3135042 A1 EP 3135042A1 EP 15725772 A EP15725772 A EP 15725772A EP 3135042 A1 EP3135042 A1 EP 3135042A1
Authority
EP
European Patent Office
Prior art keywords
representation
segment
terminal
server
segments
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
EP15725772.6A
Other languages
German (de)
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
Publication of EP3135042A1 publication Critical patent/EP3135042A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/254—Management at additional data server, e.g. shopping server, rights management server
    • H04N21/2541—Rights Management
    • 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/80—Responding to QoS
    • 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
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network 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/63—Control 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/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network 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/63—Control 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/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • a method of managing the selection of segment representation of multimedia content transmitted over a communication network is a method of managing the selection of segment representation of multimedia content transmitted over a communication network.
  • the invention relates to a method for selecting the representation of the segments of a multimedia content transmitted over a communication network.
  • Multimedia content means any audio or video content, or more generally any other digital content.
  • the invention relates more specifically to the transmission and reception of multimedia content over a network, in particular the continuous downloading, also called streaming, of multimedia content over a network.
  • URI Uniform Resource Identifier
  • representation of a content here is meant a particular way of creating a flow of data representative of a content.
  • a data stream created with an encoding rate is an example of a particular representation of the content.
  • a client terminal To access multimedia content, a client terminal usually uses a universal address (URI). Such an address provides both access to the content and indications on the associated protocol to consume it (by consume, for example, in the case of a video content, download / receive the content and then possibly decode it, then view it).
  • a URI is a string that identifies a physical or abstract resource.
  • the syntax of a URI address complies with a set of standards issued by the Internet Engineering Task Force (IETF), including the specification RFC 3986 (specification: Uniform Resource Identifier (URI): Generic Syntax).
  • IETF Internet Engineering Task Force
  • RFC 3986 Specification: Uniform Resource Identifier (URI): Generic Syntax).
  • URI Uniform Resource Identifier
  • Such a universal address will take the form dvb: // contained, rtsp: // content 2, HTTP: // content3, ftp: // content4, etc.
  • Access to multimedia content is triggered by a request, through a URI address.
  • a classic illustration is a video-on-demand service:
  • a first step is for the terminal to download a document describing the Session Description Protocol (SDP) via an HTTP (Hyper Text Transport Protocol) protocol, a client-server communication protocol developed for Internet networks and in particular the Web;
  • SDP Session Description Protocol
  • HTTP Hyper Text Transport Protocol
  • the service actually starts, that is to say that the client terminal can receive and display the video, thanks to the information provided in the document (in this example, the SDP).
  • the document may be a computer file or a set of descriptive information of the content accessible to a certain address.
  • this type of access to the service may require the presence of a server (particularly in the case of a point-to-point communication or “unicast”) or not (in the case of a point-to-multipoint communication type "Broadcast” or “multicast”).
  • the HTTP protocol is of the point-to-point type ("unicast"), and therefore implies the presence of a server in order to process the request of a client called an HTTP client.
  • Reading content according to the "HTTP adaptive streaming" technique for a given client terminal consists of:
  • - then analyze and gather the data segments to decode them to read the content.
  • the client terminal it is up to the client terminal to select the representation for each segment of media data according to parameters internal to the client (eg measured bandwidth, terminal capabilities, etc.); in particular, the client terminal selects for each segment a given encoding rate. If the bandwidth measured by the client is sufficient, the client will most often select a high encoding rate.
  • the adaptation decision only to the client terminal prevents the content distributor from having control of its platform (servers), its network, and services.
  • the major risk for the distributor is having to serve too many segment access requests with a high encoding rate. The consequence would be a saturation of network bandwidth or HTTP servers. It can also result in a drop in the rendering quality on the client terminal.
  • the representation is chosen by the server or any component of a broadcast platform (ex: CDN proxy).
  • the content addressed to the client may correspond to a segment of a bit rate different from that requested by the client, and this to adapt to network conditions for example.
  • the inventors have found that this mechanism is problematic for the terminal because the decoding parameters are potentially different from one representation (bit rate) to another, and the terminal then has no way of knowing that the received segment corresponds to a different representation. of the requested one. This results in errors in the decoding of the received segments.
  • the invention offers a solution that does not have the drawbacks of the state of the art.
  • the subject of the invention is a method of managing the representation of the data segments of a content received by a terminal from a server, the method comprising a step of obtaining a document from which are generated universal addresses, an address being associated with a representation of the relevant segment chosen by the terminal from among several representations described in the document , the segment being able to be received from the server and decoded by the terminal, characterized in that it comprises the following steps at the terminal:
  • the representation of the segments transmitted by the server is always a desired representation by the server; the server therefore has control over the choice of representations; in addition, the terminal is notified of the change of representation made by the server through information indicating this change.
  • the terminal can then take into account the information and adapt its operation, in particular by correctly parameterizing the parameters related to the decoding of the received segments; this without causing decoding errors and therefore segment restitution related to the fact that the representation of the segments received is not compatible with the current setting used for decoding the media segments.
  • the segment received according to the second representation is transmitted in a message including an http header and a useful part including the segment.
  • the information is included in the http header.
  • a segment includes a first portion including fields and a second portion including at least one encoded segment.
  • the information is included in a field (B-evt) of said first part.
  • the invention relates to a terminal able to receive segments of a content, the terminal having access to a document from which universal addresses are generated, to an address being associated with a representation of a segment concerned. chosen by the terminal from among several representations described in the document, characterized in that it comprises
  • a module for receiving said at least one segment according to a second representation, and information relating to the second representation
  • a processing module adapted to take into account the information for the decoding of the received segment.
  • the processing module takes into account the information indicating the representation chosen by the server so as to decode the said at least one segment received without generating decoding errors.
  • the invention relates to a method of sending, by a server, segments of a content according to a given respective representation, characterized in that it comprises the following steps: a reception step a request to access at least one segment according to a first selected representation,
  • the invention relates to a server capable of transmitting segments of a content on a network, characterized in that it comprises
  • the invention relates to a computer program comprising code instructions which, when the program is executed by a processor performs the steps of the method running on the terminal defined above.
  • the invention relates to a computer program comprising code instructions which, when the program is executed by a processor performs the steps of the method running on the server defined above.
  • FIG. 1 represents a streaming architecture based on the use of the HTTP protocol on the Internet according to one embodiment of the invention.
  • Figures 2 and 3 show the circuits of the equipment involved in the method of the invention.
  • Figure 4 shows a timing diagram according to an embodiment of the invention.
  • FIG. 5 represents an exemplary embodiment of the composition of a data stream transmitted by the server to the terminal following a request from the terminal to receive segments.
  • FIG. 1 represents a SYS computer system including a client terminal 1, a service platform 3, and a content server 8, able to provide content on request from the client terminal 1.
  • the terminal, the platform and the server communicates via an Internet network 2.
  • the terminal 1 comprises physical and / or software resources, in particular:
  • a rendering module such as an ECR screen
  • a first communication module COM1 for communicating with the network 2.
  • the server 8 comprises
  • a second storage module MEM2 in particular storing one or more CNT contents
  • a second communication module COM2 for communicating with the network 2.
  • the second module included in the server, is connected to the second processor CPU2 through a second bus BUS2.
  • buses described above have the function of ensuring the transfer of digital data between the various circuits connected to the microprocessor by a bus.
  • the bus in question includes a data bus and a control bus.
  • the memories described above are permanent memories accessible in writing and reading, for example flash type.
  • the terminals also include a respective RAM (not shown) for unsustainably storing calculation data used in implementing a method according to embodiments. These memories are not shown in the drawings because they are useless for the disclosure of the invention.
  • the architecture chosen to illustrate the invention is a so-called "streaming" architecture based on the use of the HTTP protocol.
  • the client terminal (1) wishes to communicate with a content server (8) to download multimedia content composed of one or more media (audio, video, etc.).
  • the terminal (1) first queries a service platform (3) to obtain the address (here, the URL, but more generally, a universal address of the URI type) of the description document 4 of the multimedia content (y); in the following, this document is a file of type MPD (y.mpd).
  • the general operation of an MPEG DASH session consists, for each representation, in first downloading an initialization segment which contains the decoding parameters; These parameters may be different depending on the representation.
  • the description file MPD
  • MPD makes it possible in particular to generate addresses of the initialization and media segments for each representation of a medium;
  • a terminal wishes to download and decode a media segment of a flow representation Vi, it must first obtain the initialization segment corresponding to the representation of flow Vi.
  • This initialization segment contains in particular the decoding parameters which will have to be used to decode the content of the media segments of the representation of bitrate Vi.
  • the customer retrieves the initialization segment corresponding to the representation of the debit target and initialize the decoder before decoding the downloaded media segments of that same representation.
  • the one transmits to the customer the identification of the representation to which belongs the segment sent to the customer, so that the customer can be notified of the change of representation and thus can obtain the initialization segment corresponding to the received segment.
  • the client is therefore aware of the representation chosen by the server and can therefore adapt its operation (selection of the initialization segment and therefore of the decoding parameters) for the decoding of the received media segments.
  • the service platform (3) responds by providing the terminal with the address of the file 4; in the example it is the URL "HTTP://x.com/y.mpd” symbolizing a file y type "mpd” which can be downloaded on the content server (8) "x.com ".
  • Description file 4 makes it possible to generate addresses of media segments
  • This construction implements a prior universal address resolution (URI) mechanism described in RFC 3986 mentioned above.
  • the client terminal must interpret certain fields and modify them appropriately to construct the first universal address (URL or URI) of the media segment.
  • URI universal address resolution
  • This URI address resolution is done according to the BaseURL element, which may be present at different levels of the file 4 hierarchy.
  • the URLs are built using the two fields "BaseUrl”("HTTP: // x.com/” and “video /”) and "SegmentTemplate”.
  • the "SegmentTemplate” specified by the MPEG / DASH standard is a generic method for building intermediate addresses (URIs) from different identifiers, in our example:
  • the first two URLs of access to the first two video segments for a quality (or bitrate) of 500 kbps (Kilo Bits per second) are here:
  • HTTP // x.com/video/500000/0.mp4v
  • each representation corresponds to a respective flow.
  • HTTP // x.com/video/500000/0.mp4v
  • HTTP // x.com/video/2000000/0.mp4v are two possible representations of the first segment, one corresponding to a bit rate of 500kbps the other at 2000kbps
  • Figure 4 is a schematic view of the exchanges taking place between the terminal, the platform and the content server.
  • a first step ET1 the terminal 1 interrogates the service platform 3 to obtain the address (here, the URL, but more generally, a universal address of the URI type) of the description document 4 of the multimedia content (y); in the following, this document is a file of type MPD (y.mpd).
  • the service platform (3) responds by supplying the terminal with the address of the file 4, in the example it is the URL
  • the terminal REQ (4) requires the server 8 to download the description file 4.
  • a fourth step ET4 the terminal receives and stores the description file 4.
  • the terminal (1) accesses the first segment by virtue of the first URL1 described above:
  • HTTP // x.com/video/2000000/0.mp4v.
  • the server 8 transmits a first Fl / 2000k data stream, including the first segments.
  • the terminal can decode the received segments and return them.
  • the terminal (1) requires access to the second segment through the second URL2 described above:
  • HTTP // x.com/video/2000000/180180.mp4v.
  • the server 8 On receipt of the download request of the second segment, during an eighth step ET8, the server 8 transmits to the terminal 1 the second segment F2 / 500k, including the second segment with a bit rate less than that requested by the terminal (1) .
  • the representation provided by the server does not match that requested by the terminal.
  • the rate chosen by the server corresponds to the rate vl (500k) if one refers to the description file in appendix 1.
  • the server in addition to a transmitted segment, also provides the terminal with information relating to the representation of the transmitted segment. This information is intended to be read before the decoding of the received segment so that the decoding parameters are adapted to the received segment.
  • the server transmits segments in the form of an http response, by means of an http header and a useful part (called payload in the standard).
  • the provision of information relating to the representation chosen by the server can be performed in different ways. Two variants will illustrate two possible cases.
  • the information on the representation can be inserted in the http header of the response of the server to the terminal.
  • the header is for example the following:
  • a field arbitrarily named “representation” indicates the representation transmitted by the server.
  • the value “vl” corresponds to a value defined in the description file (see appendix 1).
  • the "Representation" field can provide the exact value of the flow used.
  • this "Representation” field is added to indicate the representation to which the segment contained in the payload (useful part) of the http response belongs.
  • Another way of informing the client of the representation chosen by the server, corresponding to a second variant, is to insert the information into the media segment, more precisely into a field named "box event" included in the segment SG.
  • an SG media segment includes:
  • MPEG DASH Dynamic Adaptive Streaming over HTTP - ISO / IEC 23009-1: 2012 (E)
  • MPEG DASH for Dynamic Adaptive Streaming over HTTP - ISO / IEC 23009-1: 2012 (E)
  • E Dynamic Adaptive Streaming over HTTP - ISO / IEC 23009-1: 2012 (E)
  • the representation indication can be inserted into a field named "box event" of the HD part.
  • the terminal upon receipt of the segment SG, the terminal first interprets these fields ⁇ ⁇ Event "" and can then adapt the parameterization for the decoding of the received segment (F2 / 500k).
  • the HD fields are the encoded data of the current segment. Note that these fields are not at the beginning of the frame in all cases, but can be found elsewhere in the segment.
  • the one is received by the terminal.
  • the rest of the process depends on the variant chosen.
  • the terminal extracts the information representative of the representation. After extraction, the terminal adapts the decoding parameters and then decodes the segment and restores it.
  • the terminal interprets the media segment. By interpreting the latter, the terminal first interprets the so-called "box event" fields included in the segment and in a second time the segment. The terminal is therefore aware of the representation and can therefore adapt the parameterization of the decoding as for the first variant.
  • the terminal is aware of the representation chosen by the server and can therefore adapt its operation for decoding.
  • the terminal comprises, in addition to the elements described above with reference to FIG.
  • a processing module adapted to take into account the information for the decoding of the received segment.
  • the server comprises, in addition to the elements described above with reference to FIG.
  • a module for transmitting said at least one segment according to a second representation, and information relating to the second representation.
  • module used in this document may correspond to either a software component or a hardware component, or still to a set of hardware and / or software components, able to implement the function or functions described for the module.

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 pour le décodage du segment reçu.

Description

Procédé de gestion de la sélection de la représentation des segments d'un contenu multimédia transmis sur un réseau de communication.
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 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 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 normes édictées par l'IETF {Internet Engineering Task Forcé), 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://contenul, rtsp: //contenu 2, 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 : proxy 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 pour 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 pour 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 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 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 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 œuvre 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).
Le fonctionnement général d'une session MPEG DASH consiste, pour chaque représentation, à télécharger en premier lieu un segment d'initialisation qui contient les paramètres de décodage ; Ces paramètres pouvant être différent selon la représentation. A cet effet, le fichier de description (MPD) permet notamment de générer des adresses des segments d'initialisation et de média pour chaque représentation d'un média ; Lorsqu'un terminal souhaite télécharger et décoder un segment média d'une représentation de débit Vi, il doit dans un premiers temps obtenir le segment d'initialisation correspondant à la représentation de débit Vi. Ce segment d'initialisation contient notamment les paramètres de décodage qui devront être utilisés pour décoder le contenu des segments média de la représentation de débit Vi.
A noter que si pendant une session, le client bascule sur un débit Vj puis bascule à nouveau sur le débit Vi, le client peut réutiliser le segment d'initialisation précédemment téléchargé et stocké en mémoire.
Ainsi, à chaque changement de débit à l'initiative du client, le client récupère le segment d'initialisation correspondant à la représentation du débit cible et initialise le décodeur avant de décoder les segments média téléchargés de cette même représentation.
Ainsi, comme on le verra plus tard, dans le cas où le changement de débit est à l'initiative du serveur, celui transmet au client l'identification de la représentation à laquelle appartient le segment envoyé au client, afin que le client puisse être notifié du changement de représentation et ainsi puisse obtenir le segment d'initialisation correspondant au segment reçu. A ce stade on verra que le client a donc connaissance de la représentation choisie par le serveur et peut en conséquence adapter son fonctionnement (sélection du segment d'initialisation et donc des paramètres de décodage) pour le décodage des segments média reçus.
Suite à l'interrogation du terminal, 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 œuvre 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 :
• $Tïme$ : à 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 Fl/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 vl (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 soient 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-4ee49099bl2b2"
Accept-Ranges: bytes
Content-Length: 3290
Access-Control-Allow-Origin: *
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/plain
Représentation: VI'
Dans notre exemple, un champ nommé arbitrairement « représentation » indique la représentation transmise par le serveur. La valeur « vl » 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 « Représentation » 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 λΒοχ 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 pour 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 œuvre la ou les fonctions décrites pour le module.
Annexe 1

Claims

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 pour le décodage du segment reçu.
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.
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.
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 pour le décodage du segment reçu.
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.
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.
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.
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.
EP15725772.6A 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 Withdrawn EP3135042A1 (fr)

Applications Claiming Priority (2)

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.
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

Publications (1)

Publication Number Publication Date
EP3135042A1 true EP3135042A1 (fr) 2017-03-01

Family

ID=51293084

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15725772.6A Withdrawn 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

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
KR102499231B1 (ko) * 2015-04-30 2023-02-13 소니그룹주식회사 수신 장치, 송신 장치 및 데이터 처리 방법
CN114727134B (zh) * 2016-12-30 2024-02-06 谷歌有限责任公司 中断经不可侵犯清单协议提供的流传输内容的系统和方法
EP3393129A1 (fr) * 2017-04-21 2018-10-24 Alcatel-Lucent España, S.A. Distribution de contenu multimédia à retard réduit

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130173737A1 (en) * 2011-12-29 2013-07-04 Nokia Corporation Method and apparatus for flexible caching of delivered media

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2433426A4 (fr) * 2009-05-19 2013-08-28 Beaumaris Networks Inc Procédés, dispositif et support lisible par ordinateur pour un débit binaire adaptatif géré pour récupération de bande passante
US8918533B2 (en) * 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US20130179588A1 (en) * 2011-09-21 2013-07-11 General Instrument Corporation Adaptive streaming to multicast and constrained-fidelity constant bit rate encoding

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130173737A1 (en) * 2011-12-29 2013-07-04 Nokia Corporation Method and apparatus for flexible caching of delivered media

Also Published As

Publication number Publication date
FR3020542A1 (fr) 2015-10-30
WO2015162376A1 (fr) 2015-10-29
US20170127103A1 (en) 2017-05-04

Similar Documents

Publication Publication Date Title
EP2907315B1 (fr) Heritage de parametres d'identifiant universel de ressource (uri)
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
EP3135042A1 (fr) 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
EP2513788A1 (fr) Pre-chargement de contenu entre un serveur de contenu et au moins un terminal
EP3646196B1 (fr) Procédé et dispositif de téléchargement de contenu audiovisuel
EP3496407A1 (fr) Procédé de gestion de la consommation électrique d'un dispositif électronique
EP3245794A1 (fr) Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct
EP3231190B1 (fr) Procédé et dispositifs permettant une transmission d'un flux de données selon un mode de transmission multipoint
EP3370394A1 (fr) Dispositif d'accès à adressage multiple
EP2957104B1 (fr) Procédé de sélection de la représentation des segments d'un contenu multimédia transmis sur un réseau de communication
WO2019220034A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique au sein d'un terminal de restitution d'un réseau de communication local
EP3461135A1 (fr) Procédé de gestion du droit d'accès à un contenu numérique
EP3092767A1 (fr) Procédé pour adapter le comportement d'une mémoire cache, et mémoire cache correspondante
FR3148887A1 (fr) Procédé de gestion du traitement d’un flux vidéo dans un réseau local.
WO2021058910A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données
WO2014155017A1 (fr) Transcodage et diffusion adaptative de contenus multimédia
FR3015164A1 (fr) Procede de reservation d'une bande passante dans un reseau pour l'execution d'un service sur un terminal utilisateur
WO2016087750A1 (fr) Procédé de gestion du droit d'accès a un contenu numérique
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.
EP4734527A1 (fr) Procédé de gestion de l accès, par un dispositif de lecture, à des contenus segmentés
EP4564823A1 (fr) Passerelle pour encodage local de contenus de télévision numérique terrestre en segments de contenus adaptatifs sur http (has)
FR3154566A1 (fr) procédé de gestion de l’accès à des fichiers de description associés à un contenu diffusé en temps réel.
EP2879352A1 (fr) Contrôle de la diffusion de contenus multimedia
EP3721637A1 (fr) Procédé de gestion des connexions d'un dispositif électronique
EP2724518A1 (fr) Transcodage d'un contenu reference par un serveur de contenus

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20161121

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

RIN1 Information on inventor provided before grant (corrected)

Inventor name: BERTHELOT, BERTRAND

Inventor name: HOUZE, PATRICE

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20171128

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20180609