EP3245794A1 - Method for transmitting a data flow using a direct broadcasting protocol - Google Patents

Method for transmitting a data flow using a direct broadcasting protocol

Info

Publication number
EP3245794A1
EP3245794A1 EP16700626.1A EP16700626A EP3245794A1 EP 3245794 A1 EP3245794 A1 EP 3245794A1 EP 16700626 A EP16700626 A EP 16700626A EP 3245794 A1 EP3245794 A1 EP 3245794A1
Authority
EP
European Patent Office
Prior art keywords
client
data stream
server
segments
stream
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
EP16700626.1A
Other languages
German (de)
French (fr)
Inventor
Frédéric SODI
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.)
Sagemcom Broadband SAS
Original Assignee
Sagemcom Broadband SAS
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 Sagemcom Broadband SAS filed Critical Sagemcom Broadband SAS
Publication of EP3245794A1 publication Critical patent/EP3245794A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • 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
    • 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/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • 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
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 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, manipulating MPEG-4 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2355—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages
    • H04N21/2358—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages for generating different versions, e.g. for different recipient devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • 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/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25825—Management of client data involving client display capabilities, e.g. screen resolution of a mobile phone
    • 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/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25833—Management of client data involving client hardware characteristics, e.g. manufacturer, processing or storage capabilities
    • 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/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H04N21/25858—Management of client data involving client software characteristics, e.g. OS identifier
    • 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 transmitting a data stream using a live broadcast protocol is a method of transmitting a data stream using a live broadcast protocol.
  • the present invention relates to a method for transmitting a data stream using a live broadcast protocol, for example the HTTP-based live streaming protocol ("HTTP Live Streaming (HLS)" in English terminology, Informational Internet Draft, R. Pantos, Apple Inc., October 14, 2014, draft-pantos-http-live-streaming-14).
  • HTTP Live Streaming HLS
  • the invention further relates to a server device, a client device and a system implementing said method.
  • HLS live streaming
  • a broadcast of a data stream using the HLS protocol begins with a receipt by the server of an HTTP request from a client. This request requests a broadcast of one of the data streams available on the server. We let's call this data flow, initial data flow.
  • the server then initiates a decomposition of the initial data stream into segments. Each segment represents a display time less than or equal to a constant set by the HLS protocol.
  • Each segment is associated with an address such as a URI (uniform resource identifier, "Uniform Resource Identifier" in English terminology) allowing a customer to obtain the segment.
  • URI uniform resource identifier
  • each segment is associated with a sequence number and a duration, which makes it possible to reorder the segments.
  • the server creates a text file called playlist file ("playlist file" in English terminology) in a format specified by the HLS protocol.
  • playlist file (playlist file” in English terminology) in a format specified by the HLS protocol.
  • the URI, sequence number, and duration of each segment that the server wants to make available to a client appear in the playlist file.
  • a URI is then created for the playlist file to allow a client to obtain the playlist file.
  • the playlist file can be updated by the server based on availability of the segments constituting the data stream.
  • the end of a data stream is indicated in the playlist file by a particular segment called the final segment.
  • the HLS protocol makes it possible to broadcast streams of real-time data, i.e. data streams created as and when broadcast, or pre-existing data streams in full before the start of the broadcast.
  • the playlist file is supplied with information (URI address, sequence number, duration) relating to new segments, the information relating to the oldest segments being able to be removed from said playlist file.
  • the playlist file may include information relating to each segment constituting the data stream.
  • HLS In order to respond to multiple clients with different capabilities, HLS allows a server to create multiple different versions of the same initial data stream. Each data stream thus created, hereinafter referred to as the first data stream, is decomposed into segments. A playlist file is then created for each first data stream.
  • the server creates a master playlist file ("master playlist file" in English terminology), containing the URIs of each of the files playlist and for each file playlist, the server inserts a description of the first corresponding data stream.
  • the description of a first data stream includes, for example, a bit rate of the first data stream.
  • the server associates the master playlist file with a URI, thus allowing a client to obtain the master playlist file.
  • a client of a session broadcasting a data stream according to the HLS protocol obtains, for example, when opening an HTTP connection with a server, a description of each data stream available on the server. This description allows the client to select one of the available data streams on the server.
  • the client transmits information representative of the selected data stream to the server and receives a corresponding URI address from a corresponding playlist file (or master list file). selected data stream.
  • the selected data flow then corresponds to the initial data flow from the server point of view.
  • the client transmits to the server an HTTP request containing the URI address of the playlist file (respectively of the master playlist file) in order to receive said playlist file (respectively said master list file).
  • the client When the client receives a master playlist file, the client selects a first data stream compatible with said client's capabilities using the description associated with each first stream of data contained in the master playlist file. The client then transmits an HTTP request to the server containing the URI address of the playlist file corresponding to the first selected data stream. As soon as it obtains a read list file, the client can transmit HTTP requests to the server each containing a URI of a segment it wishes to receive. Each segment is requested in an order dependent on its sequence number.
  • a client that has received a master playlist file has varying capabilities, such as variable rate capabilities, it can alternate between several first streams of data based on its capabilities at a given time.
  • the server is responsible for defining adaptation parameters to be applied to the initial data stream to obtain each first data stream.
  • the definition of the adaptation parameters is done without consultation with a client by taking into account the capacities of the types of customers belonging to a set of predefined types of customers.
  • the HLS protocol was initially defined for a context in which a server had to stream a data stream to a large number of clients. Letting the server set adaptation parameters based on a set of predefined client types is particularly consistent in this context since, for a computational cost question, it is impossible for a server to generate as many first data streams as there are different clients.
  • a disadvantage of the HLS protocol is that a client that has capabilities different from the types of clients belonging to the predefined set of client types, can not receive a stream of data optimized for its capabilities. It has no choice but to fall back on a first data flow corresponding to a type of clients of the set of predefined types of customers.
  • HLS has been used in contexts other than the initial context for which it was defined.
  • HLS protocol was typically used to broadcast data flows to clients that actually correspond to a type of client belonging to the predefined set of client types, it is now used for other clients with different capabilities. those of the customer types from the predefined set of customer types.
  • the HLS protocol is now used to broadcast live data streams in networks with a small number of clients.
  • a streaming data streaming protocol that allows fine-tuning of a data stream to a client that does not match a type of client of the predefined set of client types. It is particularly desirable that this live streaming protocol is compatible with the HLS protocol.
  • the present invention relates to a method for transmitting a data stream between a server and a client using a live broadcast protocol, the method comprising the following steps implemented by the server: obtain an initial data flow; receiving a request for descriptive information for the initial data flow from said client; verify that at least one piece of information representing a capacity of said client has been received from said client; if no information representative of a capacity of said client has been received: adapting the initial data stream to obtain a plurality of first data streams, each first data stream being adapted to respective capacities of a type of clients belonging to to a set of predefined client types; break down into segments, so-called first segments, each first data flow ; and, transmitting to said client a first descriptive information enabling the client to request a transmission of first segments of at least a first data stream; and if at least one piece of information representing a capacity of said client has been received: adapting said initial data stream to each received capacity in order to obtain a second data stream; decomposing into segments, called
  • the second client receives a second data stream finely adapted to its capabilities.
  • the live broadcast protocol is the HTTP-based live broadcast protocol.
  • the method according to the invention can therefore be implemented by servers and clients able to implement the HTTP-based live broadcast protocol.
  • the second descriptive information is in the form of a playlist file compatible with the live broadcast protocol.
  • a client who could read a playlist file compatible with the live broadcast protocol would therefore read the file reading list containing the second descriptive information.
  • the transmission of the second descriptive information comprises a transmission to the client of a loading address of the playlist file compatible with the live broadcast protocol.
  • the server transmits the play list file compatible with the live broadcast protocol to the client, following receipt from the client of an HTTP request containing said loading address.
  • the server transmits a second segment following reception, from the client, of an HTTP request containing a loading address corresponding to said second segment, said loading address having been obtained from the list file of playback compatible with the live broadcast protocol.
  • the client capabilities include a supported video compression format and / or a supported audio compression format and / or a supported image compression format and / or a supported subtitle format and / or a type of network used and / or a reception rate and / or a maximum supported image resolution and / or a supported number of audio channels.
  • an adaptation of said initial data stream comprises transcoding to reduce a bit rate of said video stream and / or a resolution of the video stream. images of said video stream and / or an image frequency of said video stream and / or a transformation of said video stream to ensure compatibility with a second video compression format, and when said initial data stream comprises an encoded audio stream in a first audio compression format, an adaptation of said initial data stream comprises a transcoding for reducing a bit rate of said audio stream and / or a number of audio channels and / or a transformation of said audio stream to ensure compatibility with a second audio compression format.
  • the invention relates to a server-type device capable of transmitting a data stream using a live broadcast protocol, comprising the following means: obtaining means for obtaining a data stream initial; receiving means for receiving a request for descriptive information for the initial data stream from a client; verification means for verifying that at least one piece of information representing a capacity of said client has been received; means implemented when no information representative of a capacity of said client has been received comprising: adaptation means for adapting the initial data stream to obtain a plurality of first data streams, each first data stream being adapted respective capabilities of a type of clients belonging to a set of predefined client types; decomposition means for splitting into segments, so-called first segments, each first data stream; and, transmission means for transmitting to a client a first descriptive information enabling the client to request a transmission of the first segments of at least a first data stream; means implemented when at least one piece of information representing a capacity of said client has been received comprising: adaptation means for adapting said initial data stream to each received
  • the invention relates to a client device capable of receiving a data stream using the HTTP-based live broadcasting protocol, comprising the following means: transmission means for transmitting at least information representative of a capacity of said client device to a server; means for receiving a text file compatible with the HTTP-based live broadcast protocol, the text file corresponding to an initial data file and making it possible to obtain segment loading addresses corresponding to a data stream, said second stream data, resulting from an adaptation by the server of the initial data stream to each capacity of said client type device; transmission means for transmitting a request containing a loading address of a segment of the second data stream, the loading address having been obtained from the text file compatible with the HTTP-based live broadcast protocol; receiving means for receiving the segment corresponding to the transmitted request.
  • the invention relates to a system for transmitting a data stream comprising a server according to the second aspect and at least one client according to the third aspect.
  • the invention relates to a computer program, comprising instructions for implementing, by a device, the method according to the first aspect, when said program is executed by a processor of the device.
  • the invention relates to storage means, storing a computer program comprising instructions for implementing, by a device, the method according to the first aspect, when said program is executed by a processor of said device.
  • FIG. 1 schematically illustrates an exemplary system in which is implemented a data transmission method using a live broadcast protocol
  • FIG. 2A schematically illustrates an example of a hardware architecture of a client device embodying the invention
  • FIG. 2B schematically illustrates an example of a hardware architecture of a server device embodying the invention
  • FIG. 3A schematically illustrates an example of implementation of a method according to the invention
  • FIG. 3B and 3C schematically illustrate an example of implementation of the HLS protocol method by a server
  • FIG. 3D schematically illustrates an example of implementation of a HLS protocol method by a client
  • FIG. 4A and 4B schematically illustrate an example of a server implementation of a streaming method of a data stream for fine-tuning the data flow to a client's capabilities
  • FIG. 4C schematically illustrates an example of a implementation by a client of the streaming method of a data stream for fine-tuning the data flow to the capabilities of the client.
  • the invention is described in the context of the HLS protocol.
  • the invention is, however, adapted to other protocols or methods of streaming live data between a server and at least one client having a similar operation to the HLS protocol.
  • the invention is described in the context of a local area network ("Local Area Network") in which a multimedia server ("set top box” in English terminology) obtains a data stream. from a network, such as the Internet, through a gateway ("gateway" in English terminology) and broadcasts data flows to clients of the local network.
  • the invention is, however, adapted to other contexts in which a server diffuses through a network a data stream to at least one client.
  • Fig. 1 schematically illustrates an exemplary system in which is implemented a data transmission method using a live broadcast protocol.
  • the system comprises a network gateway 12 connected by a network link 11, such as an Ethernet link, to a network 10, such as the Internet network.
  • the network gateway 12 is an entry point to a local area network.
  • This local area network comprises a server 14, such as a multimedia server or a TV decoder, connected to the network gateway 12 by a network link 13 such as an Ethernet link, a wireless link or a CPL link. Online Carrier).
  • the server 14 is connected to a client 16 by a network link 15, such as an Ethernet link, a wireless link or a PLC link.
  • the client 16 may be for example a television, a computer, a tablet or a smart phone ("smart phone" in English terminology).
  • the network gateway 12 receives data flows encapsulated in packets
  • Each data stream is then extracted from the packets by the network gateway 12 and supplied to the server 14 in the form of an MPEG TS transport stream ("Moving Picture Expert Group Transport Stream part 1", ISO / IEC 13818-1).
  • Each MPEG TS transport stream may contain at least one video stream and / or at least one audio stream and / or at least one metadata stream such as a subtitle stream.
  • the server 14 When the client 16 selects an initial data stream available on the server 14, the server 14 generates a plurality of first data streams according to a method that we describe in relation to FIG. 3B. After selection by the client 16 of one of the first data streams, a broadcast of the first selected data stream, according to a method described in relation to FIGS. 3C and 3D, is implemented.
  • Figs. 4A, 4B and 4C describe a variant of the methods described in relation to FIGS. 3A, 3B and 3C, this variant allowing a fine adaptation of an initial data flow to a client that does not correspond to a type of client of the set of predefined client types.
  • Fig. 3A schematically illustrates an example of implementation of a method according to the invention.
  • the server 14 obtains a set of data streams.
  • This set of data streams can, for example, be obtained from a memory of the server 14 or provided by the network gateway 12.
  • Information representing the data streams available on the server 14 is then broadcast to the client 16.
  • Client 16 selects one of the available data streams, and transmits information representing the selected data stream to the server 14. The data stream selected by the client 16 then becomes the original data stream.
  • the server 14 receives the information representing the selected data stream transmitted by the client 16.
  • the reception of the information representing the selected data stream acts as a receipt of a descriptive information request for the initial data flow.
  • the server 14 verifies that it has received information representative of the capabilities of the client 16.
  • the information representative of the capabilities of the client 16 may have been received prior to the reception of the information representing the data flow. selected or the server may, following the receipt of the information representing the selected data stream, wait for reception of at least one piece of information representative of the capabilities of the client 16 for a predefined time.
  • the server 14 If after a period equal to the predefined time the server 14 has received no information representative of the capabilities of the client 16, it implements the HLS protocol in a step 33.
  • An example of implementation of the HLS protocol by the server 14 is described in relation with FIGS. 3B and 3C.
  • the server 14 finds that it has received at least one piece of information representative of the capabilities of the client 16, it implements, during a step 34, a method allowing a fine adaptation of the flow of initial data to the capabilities of the client 16.
  • a method allowing a fine adaptation of the flow of initial data to the capabilities of the client 16.
  • the server 14 broadcasts the information representing the available data streams on the server 14 before actually receiving the corresponding data streams. It is then the receipt by the server of the descriptive information request for a data flow that triggers the effective obtaining by the server 14 of the requested data stream.
  • Figs. 3B and 3C schematically illustrate an example of implementation of the HLS protocol by the server 14.
  • the server 14 adapts the initial data stream to obtain a plurality of first data streams.
  • Each first data stream is adapted to respective capabilities of a type of clients belonging to a set of predefined client types.
  • the capabilities of a customer include for example:
  • a client can support one or more of the following video compression formats: MPEG-2 (ISO / IEC 13818-2), MPEG-4 Part 2 (ISO / IEC 14496-2), H264 / AVC (ISO / IEC 14496) -10 - MPEG-4 Part 10, advanced video coding ("Advanced Video Coding" / ITU-T H.264), HEVC (ISO / IEC 23008-2 - MPEG-H Part 2, High Efficiency Video Coding (High Efficiency Video Coding) ) / ITU-T H.265),
  • a client can support one or more of the following audio compression formats: MP3 (MPEG-1 Level III), AAC (Advanced Audio Coding), Advanced Audio Coding (English),
  • a client can support one or more of the following image compression formats:
  • JPEG (ISO / IEC 10918-1 / ITU-T Recommendation T.81), JPEG2000 (ISO / IEC 15444-1),
  • Ethernet Ethernet
  • Wi-Fi Wi-Fi
  • PLC Packet Control Protocol
  • transcoding may be applied to the video stream to reduce a bit rate of said video stream and / or to reduce an image resolution of said video stream and / or reducing a frame rate of said video stream and / or transforming said video stream to provide compatibility with a second video compression format.
  • transcoding may be applied to the audio stream to reduce a rate of said audio stream and / or to reduce a number of channels of said audio stream and / or or transforming said audio stream to provide compatibility with a second audio compression format.
  • Other types of adaptation may include deleting a subtitle stream when a client type of the predefined client type set is not able to decode the subtitle stream.
  • the server 14 breaks down into segments, called first segments, each first data stream.
  • the server 14 associates each segment to information representative of said segment comprising a URI address, a sequence number and a size of said segment.
  • the server 14 transmits to the client 16, a first descriptive information making it possible to obtain, for each first data stream, at least one characteristic of said first data stream and for each first segment, an address of loading said first segment.
  • the first descriptive information allows the client 16 to request a transmission of first segments based on capabilities of the client 16 to obtain a version of the initial data stream adapted to said capabilities.
  • the server 14 creates a read list file for each first data stream. For each first data stream, the server 14 inserts the information representative of each segment of said first data stream that it wishes to make accessible to the client 16 in the read list file corresponding to said first data stream. Following the creation of the playlist files, the server 14 allocates a URI to each playlist file. A master read list file is then created, in which the server 14 inserts, for each first data stream, the URI address of the read list file corresponding to said first data stream and a description of said first data stream.
  • a description of a first data stream included in a master list file may, for example, indicate for which type of clients of the set of predefined client types the first data stream has been adapted and / or a bit rate.
  • the server 14 associates a URI address to the master list file and sends this URI address to the client 16 in step 305.
  • This URI is, for the client 16, the first descriptive information to obtain a version of the initial data flow.
  • the server 14 receives from the client 16, an HTTP request containing the URI of the master playlist file. Following reception of this request, the server 14 transmits the master reading list file to the client 16 so that it selects one of the first data streams. Following this selection, the server 14 receives an HTTP request containing the URI address of the playlist file corresponding to the first selected data stream. In a step 312, the server 14 transmits to the client 16 the playlist file corresponding to the selected data stream.
  • the server 14 checks whether it has received an HTTP request containing a URI address of a first segment requested by the client 16. If this is the case, in a step 315, the server 14 transmits the first segment requested from the client 16 and returns to step 313. If no HTTP request for a new segment is received for a predefined duration or the last transmitted segment is a final segment of the first data stream, the server 14 terminates the broadcast of the first data stream during a step 314.
  • Fig. 3D schematically illustrates an example of implementation of the protocol
  • Client 16 is assumed to have selected an initial data stream from a set of data streams available on server 14. In this example, client 16 has not transmitted its capabilities to server 14. Client 16 has therefore received the URI address of the master read list file corresponding to the selected initial data stream transmitted in step 305.
  • a step 321 at a time chosen, for example, by a user of the client 16, the client 16 transmits an HTTP request to the server 14 containing the URI address of the master reading list file corresponding to the initial data stream that it selected.
  • the client 16 receives from the server 14, said master list file.
  • Client 16 selects a first data stream from among the first data streams mentioned in the master list file using the descriptions of each first data stream. During this selection, the client 16 compares the capabilities of said client 16 with the information contained in the descriptions of each first data stream. If the client 16 corresponds to a type of clients included in the set of predefined client types, the client 16 selects the first data stream corresponding to this type of clients from the predefined set. If the client 16 does not correspond to a type of client represented in the set of predefined client types, the client 16 chooses a first data stream having characteristics as close as possible to the capabilities of the client 16.
  • the client 16 After selecting one of the first data streams, the client 16 transmits to the server 14 a request containing the URI address of the playlist file corresponding to the first selected data stream.
  • the client 16 receives the playlist file corresponding to the first data stream that it has selected.
  • the client 16 searches in the playlist file for a first segment to request the server 14.
  • the client 16 requests for the first time a first segment for the first data stream that he has selected, the client 16 generally selects the first segment having the lowest sequence number in the playlist file it has received.
  • the client 16 transmits an HTTP request to the server 14 containing the URI address of said first selected segment.
  • the client 16 receives said first segment and provides this first segment to a decoding module supporting a decoding of the first segment.
  • the client 16 checks whether the broadcast of the initial data stream that it has selected must be continued.
  • the broadcast of a data stream may, for example, be controlled by a user of the client 16. If the broadcast is to be continued, the client 16 again implements step 323 and requests the first segment following the first segment previously requested, ie the first segment having a sequence number incremented by one relative to the sequence number of the previously requested first segment. If the broadcast does not have to be continued, the client 16 terminates it during a step 327.
  • the client 16 may transmit to the server 14 an HTTP request containing all the URIs contained in the master playlist file. In this manner the client 16 receives each read list file corresponding to the initial data stream that it has selected.
  • the client 16 selects a first data stream compatible with the capabilities of the client 16 found at the time of the implementation of step 326. client 16 then selects the next segment to request from the server in the playlist file corresponding to the first data stream selected in step 326.
  • the exemplary implementation of the HLS protocol described in relation to FIGS. 3B, 3C and 3D shows that the current HLS protocol does not allow a fine adaptation of the data flow to the capabilities of the client 16.
  • Figs. 4A and 4B schematically illustrate an example of an implementation by the server 14 of a streaming method of a data stream allowing a fine tuning of the data flow to the capabilities of a customer. This process corresponds to the step 34 described in connection with FIG. 3A.
  • step 402 in the same way that the server 14 had adapted the initial data stream to the respective capabilities of the client types of the set of predefined client types to obtain the first data streams, the Server 14 adjusts the initial data stream to each capacity of the client 16 received to obtain a second data stream.
  • the server 14 breaks down into segments, called second segments, the second data stream.
  • Each second segment is associated with a URI.
  • the server 14 transmits to the client 16 a second descriptive information for obtaining, for each second segment, the URI address of said second segment.
  • the second descriptive information allows the client 16 to request a transmission of the second segments to obtain the second data stream.
  • step 404 the server 14 creates a playlist file and inserts the URIs, sequence numbers and durations of the second segments. The server 14 then allocates a URI address to the playlist file thus created.
  • step 405 the URI address of the playlist file containing the URIs of the second segments is transmitted to the client 16.
  • the URI address of the playlist file containing the URIs of the second segments corresponds to the second information. descriptive allowing the client 16 to request a transmission of the second segments to obtain the second data stream.
  • the server 14 receives an HTTP request from the client 16 containing the URI address of the playlist file containing the URIs of the second segments.
  • the server 14 transmits the read list file containing the URIs of the second segments to the client 16.
  • a step 415 following a reception, during a step 413, of an HTTP request containing a URI of a second segment from the client 16, the server 14 transmits to the client 16 the second segment corresponding to said URI address.
  • the URI address of said second segment was obtained by the client 16 from the playlist file transmitted by the server 14. If, in step 413, no HTTP request for a new segment is received for a predefined duration or the last transmitted segment is an end segment of the second data stream, the server 14 terminates the broadcast of the second data stream. data flow during a step 414.
  • Fig. 4C schematically illustrates an example of a implementation by a client of the streaming method of a data stream allowing a fine adaptation of the data flow to the capabilities of the client.
  • the client 16 transmits to the server 14 information representative of its capabilities.
  • a step 421 at a time chosen, for example, by a user of the client 16, the client 16 transmits an HTTP request to the server 14 containing the URI address of the playlist file containing the URIs of the second segments. In return, the client 16 receives from the server 14, said read list file during a step 422.
  • the client 16 searches the playlist file for a second segment to request from the server 14.
  • the client 16 requests for the first time a second segment, the client 16 generally selects the second segment having the number of the second segment. lowest sequence in the playlist file it received.
  • the client 16 transmits an HTTP request to the server 14 containing the URI address of said second selected segment.
  • the client 16 receives said second segment and provides this second segment to a decoding module supporting a decoding of the second segment.
  • a step 426 the client 16 checks whether the broadcast of the initial data stream that it has selected must be continued. If the broadcast is to be continued, the client 16 again implements step 423 and requests the second segment following the previously requested segment, ie the second segment having a sequence number incremented by one relative to the sequence number of the second segment previously requested. If the broadcast is not to be continued, the client 16 terminates it during a step 427.
  • the client 16 can open an HTTP connection with the server 14 to transmit its capabilities. This connection can be closed by the server upon receipt of the capabilities of the client 16.
  • the method described in connection with FIG. 4C could be implemented by a second client not shown in FIG. 1. In this case the client 16 would be compatible with the HLS protocol while the second client would be compatible with the HLS protocol and the method described in relation to FIGS. 4A, 4B and 4C.
  • the server 14 also generates first data streams as described in relation with step 302.
  • the server 14 also generates first segments such as described in connection with step 303.
  • the server 14 also generates a read list file for each first data stream as described in connection with step 304.
  • the URI addresses of the list files corresponding to the first data stream and the second data stream are inserted in a master playlist file.
  • the URI address of the master playlist file is transmitted to the client 16.
  • the client 16 can choose from the first data stream and the second data stream, the flow of the master file. data most appropriate to its capabilities at a given moment.
  • another client than the client 16 could also receive the master list file and choose from among the first data streams and the second data stream, the data flow most appropriate to its capabilities.
  • the client 16 may send the server 14 new information representative of its capabilities at regular intervals or when its capabilities have evolved significantly compared to the latest capabilities sent.
  • the sending of new information representative of the capabilities of the client 16 causes a new adaptation of the initial data stream by the server 14 to generate a new second data stream adapted to the new capabilities.
  • Fig. 2A illustrates schematically an example of a hardware architecture of a client device implementing the HLS protocol and / or the method described in relation to FIG. 4C.
  • the client 16 then comprises, connected by a communication bus 165: a processor or CPU ("Central Processing Unit” in English) 160; random access memory RAM ("Random Access Memory”) 161; a ROM (Read Only Memory) 162; a a storage unit or a storage medium reader, such as an SD card reader (“Secure Digital”) 163; a set 164 of connection interfaces for connecting the client 16 to the server 14.
  • a processor or CPU Central Processing Unit
  • RAM Random Access Memory
  • ROM Read Only Memory
  • storage unit or a storage medium reader such as an SD card reader (“Secure Digital”) 163
  • set 164 of connection interfaces for connecting the client 16 to the server 14.
  • the processor 160 is capable of executing instructions loaded into the RAM 161 from the ROM 162, an external memory (not shown), a storage medium, such as an SD card, or a memory card. communication network. When client 16 is turned on, processor 160 is able to read instructions from RAM 161 and execute them. These instructions form a computer program causing the processor 160 to implement all or some of the methods described in relation to FIGS. 3C and 4C.
  • Fig. 2B schematically illustrates an example of a hardware architecture of a server device embodying the invention.
  • the server 14 then comprises, connected by a communication bus 145: a processor or CPU ("Central Processing Unit” in English) 140; random access memory RAM ("Random Access Memory”) 141; ROM (Read Only Memory) 142; a storage unit or a storage medium reader, such as a SD card reader (“Secure Digital”) 143; a set 144 of connection interfaces for connecting the server 14 to the client 16 and to the network gateway 12.
  • a communication bus 145 a processor or CPU ("Central Processing Unit" in English) 140; random access memory RAM ("Random Access Memory”) 141; ROM (Read Only Memory) 142; a storage unit or a storage medium reader, such as a SD card reader (“Secure Digital”) 143; a set 144 of connection interfaces for connecting the server 14 to the client 16 and to the network gateway 12.
  • the processor 140 is capable of executing loaded instructions in the RAM
  • the processor 140 When the server 14 is powered up, the processor 140 is able to read instructions from RAM 141 and execute them. These instructions form a computer program causing the processor 140 to implement all or some of the methods described in relation to FIGS. 3A, 3B, 4A and 4B.
  • All or part of the algorithm described in relation to FIGS. 3A, 3B, 3C, 4A, 4B and 4C can be implemented in software form by executing a set of instructions by a programmable machine, such as a DSP ("Digital Signal Processor” in English) or a microcontroller, or be implemented in hardware form by a machine or a dedicated component, such as an FPGA ("Field Programmable Gate Array” in English) or an ASIC ("Application-Specific Integrated Circuit”).
  • a programmable machine such as a DSP ("Digital Signal Processor” in English) or a microcontroller
  • FPGA Field Programmable Gate Array
  • ASIC Application-Specific Integrated Circuit

Abstract

The invention relates to a method for transmitting a data flow between a server and a client using the HTTP-based direct broadcasting protocol, comprising the following steps implemented by the server following the reception of at least one information message representing a capacity of said client: adapting (402) an initial data flow to each received capacity in order to obtain a suitable data flow; decomposing (403) the suitable data flow into segments; and transmitting (404, 405) a descriptive information message to the client, allowing a loading address to be obtained for each segment, for loading each respective segment, said descriptive information allowing the client to request from the server a transmission of the segments in order to obtain the suitable data flow.

Description

Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct.  A method of transmitting a data stream using a live broadcast protocol.
La présente invention concerne un procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct, comme par exemple le protocole de diffusion en direct basé sur HTTP (« HTTP Live Streaming (HLS) » en terminologie anglo-saxonne, Informational Internet Draft, R. Pantos, Apple Inc., October 14, 2014, draft-pantos-http-live-streaming-14). L'invention concerne de plus un dispositif serveur, un dispositif client et un système mettant en œuvre ledit procédé. The present invention relates to a method for transmitting a data stream using a live broadcast protocol, for example the HTTP-based live streaming protocol ("HTTP Live Streaming (HLS)" in English terminology, Informational Internet Draft, R. Pantos, Apple Inc., October 14, 2014, draft-pantos-http-live-streaming-14). The invention further relates to a server device, a client device and a system implementing said method.
Il est connu des protocoles de diffusion en direct (« streaming » en terminologie anglo-saxonne) de flux de données entre un serveur et un client dans lesquels la diffusion d'un flux de données est à l'initiative du client. C'est le cas par exemple du protocole de diffusion en direct basé sur HTTP, appelé par la suite protocole HLS. Le protocole HLS permet de diffuser en direct des flux audio, des flux vidéo, des flux de métadonnées ou des flux combinant plusieurs types de flux de données.  It is known protocols live streaming ("streaming" in English terminology) data flows between a server and a client in which the dissemination of a data stream is at the initiative of the customer. This is the case, for example, of the HTTP-based live broadcast protocol, hereafter called the HLS protocol. HLS provides live streaming of audio streams, video streams, metadata streams, or streams that combine multiple types of data streams.
Une diffusion d'un flux de données utilisant le protocole HLS débute par une réception par le serveur d'une requête HTTP en provenance d'un client. Cette requête demande une diffusion d'un des flux de données disponibles sur le serveur. Nous appelons par la suite ce flux de données, flux de données initial. Le serveur lance alors une décomposition du flux de données initial en segments. Chaque segment représente une durée d'affichage inférieure ou égale à une constante fixée par le protocole HLS. Chaque segment est associé à une adresse telle qu'une URI (identifiant uniforme de ressource, « Uniform Ressource Identifier » en terminologie anglo-saxonne) permettant à un client d'obtenir le segment. Par ailleurs, chaque segment est associé à un numéro de séquence et à une durée, ce qui permet de réordonner les segments. Suite au lancement de la décomposition, le serveur crée un fichier texte appelé fichier liste de lecture («playlist file » en terminologie anglo-saxonne) selon un format spécifié par le protocole HLS. L'adresse URI, le numéro de séquence et la durée de chaque segment que le serveur souhaite rendre disponibles pour un client apparaissent dans le fichier liste de lecture. Une adresse URI est ensuite créée pour le fichier liste de lecture, de manière à permettre à un client d'obtenir le fichier liste de lecture. Le fichier liste de lecture peut être mis à jour par le serveur en fonction d'une disponibilité des segments constituant le flux de données. La fin d'un flux de données est indiqué dans le fichier liste de lecture par un segment particulier appelé segment final. A broadcast of a data stream using the HLS protocol begins with a receipt by the server of an HTTP request from a client. This request requests a broadcast of one of the data streams available on the server. We let's call this data flow, initial data flow. The server then initiates a decomposition of the initial data stream into segments. Each segment represents a display time less than or equal to a constant set by the HLS protocol. Each segment is associated with an address such as a URI (uniform resource identifier, "Uniform Resource Identifier" in English terminology) allowing a customer to obtain the segment. In addition, each segment is associated with a sequence number and a duration, which makes it possible to reorder the segments. Following the launch of the decomposition, the server creates a text file called playlist file ("playlist file" in English terminology) in a format specified by the HLS protocol. The URI, sequence number, and duration of each segment that the server wants to make available to a client appear in the playlist file. A URI is then created for the playlist file to allow a client to obtain the playlist file. The playlist file can be updated by the server based on availability of the segments constituting the data stream. The end of a data stream is indicated in the playlist file by a particular segment called the final segment.
Le protocole HLS permet de diffuser des flux de données temps réel, i.e. des flux de données créés au fur et à mesure de la diffusion, ou des flux de données préexistant intégralement avant le début de la diffusion. Dans le cas de flux de données temps réel, le fichier liste de lecture est alimenté en cours de diffusion par des informations (adresse URI, numéro de séquence, durée) relatives à de nouveaux segments, les informations relatives aux segments les plus anciens pouvant être retirées dudit fichier liste de lecture. Dans le cas d'un flux de données préexistant, le fichier liste de lecture peut comprendre des informations relatives à chaque segment constituant le flux de données.  The HLS protocol makes it possible to broadcast streams of real-time data, i.e. data streams created as and when broadcast, or pre-existing data streams in full before the start of the broadcast. In the case of real-time data streams, the playlist file is supplied with information (URI address, sequence number, duration) relating to new segments, the information relating to the oldest segments being able to be removed from said playlist file. In the case of a pre-existing data stream, the playlist file may include information relating to each segment constituting the data stream.
Afin de répondre à de multiples clients ayant des capacités différentes, le protocole HLS permet à un serveur de créer plusieurs versions différentes d'un même flux de données initial. Chaque flux de données ainsi créé, appelé par la suite premier flux de données, est décomposé en segments. Un fichier liste de lecture est alors créé pour chaque premier flux de données. Dans ce cas, le serveur crée un fichier liste de lecture maître (« master playlist file » en terminologie anglo-saxonne), contenant les URI de chacun des fichiers liste de lecture et pour chaque fichier liste de lecture, le serveur insère une description du premier flux de données correspondant. La description d'un premier flux de données comprend par exemple, un débit du premier flux de données. Le serveur associe le fichier liste de lecture maître à un URI, permettant ainsi à un client d'obtenir le fichier liste de lecture maître. In order to respond to multiple clients with different capabilities, HLS allows a server to create multiple different versions of the same initial data stream. Each data stream thus created, hereinafter referred to as the first data stream, is decomposed into segments. A playlist file is then created for each first data stream. In this case, the server creates a master playlist file ("master playlist file" in English terminology), containing the URIs of each of the files playlist and for each file playlist, the server inserts a description of the first corresponding data stream. The description of a first data stream includes, for example, a bit rate of the first data stream. The server associates the master playlist file with a URI, thus allowing a client to obtain the master playlist file.
De son côté, un client d'une session de diffusion d'un flux de données selon le protocole HLS obtient, par exemple, lors d'une ouverture d'une connexion HTTP avec un serveur, une description de chaque flux de données disponible sur le serveur. Cette description permet au client de sélectionner un des flux de données disponibles sur le serveur. Lorsqu'il a sélectionné un des flux de données, le client transmet une information représentative du flux de données sélectionné au serveur et reçoit en retour une adresse URI d'un fichier liste de lecture (ou d'un fichier liste de lecture maître) correspondant audit flux de données sélectionné. Le flux de données sélectionné correspond alors au flux de données initial du point de vue du serveur. Le client transmet alors au serveur une requête HTTP contenant l'adresse URI du fichier liste de lecture (respectivement du fichier liste de lecture maître) afin de recevoir ledit fichier liste de lecture (respectivement ledit fichier liste de lecture maître). Lorsque le client reçoit un fichier liste de lecture maître, le client sélectionne un premier flux de données compatible avec des capacités dudit client en utilisant la description associée à chaque premier flux de données contenu dans le fichier liste de lecture maître. Le client transmet ensuite une requête HTTP au serveur contenant l'adresse URI du fichier liste de lecture correspondant au premier flux de données sélectionné. Dès qu'il obtient un fichier liste de lecture, le client peut transmettre des requêtes HTTP au serveur contenant chacune une adresse URI d'un segment qu'il souhaite recevoir. Chaque segment est demandé dans un ordre dépendant de son numéro de séquence. Lorsqu'un client ayant reçu un fichier liste de lecture maître possède des capacités variables, par exemple des capacités de débit variable, il peut alterner entre plusieurs premiers flux de données en fonction de ses capacités à un instant donné.  For its part, a client of a session broadcasting a data stream according to the HLS protocol obtains, for example, when opening an HTTP connection with a server, a description of each data stream available on the server. This description allows the client to select one of the available data streams on the server. When it has selected one of the data streams, the client transmits information representative of the selected data stream to the server and receives a corresponding URI address from a corresponding playlist file (or master list file). selected data stream. The selected data flow then corresponds to the initial data flow from the server point of view. The client then transmits to the server an HTTP request containing the URI address of the playlist file (respectively of the master playlist file) in order to receive said playlist file (respectively said master list file). When the client receives a master playlist file, the client selects a first data stream compatible with said client's capabilities using the description associated with each first stream of data contained in the master playlist file. The client then transmits an HTTP request to the server containing the URI address of the playlist file corresponding to the first selected data stream. As soon as it obtains a read list file, the client can transmit HTTP requests to the server each containing a URI of a segment it wishes to receive. Each segment is requested in an order dependent on its sequence number. When a client that has received a master playlist file has varying capabilities, such as variable rate capabilities, it can alternate between several first streams of data based on its capabilities at a given time.
Dans le protocole HLS, le serveur se charge de définir des paramètres d'adaptation à appliquer au flux de données initial pour obtenir chaque premier flux de données. La définition des paramètres d'adaptation se fait sans concertation avec un client en prenant en compte des capacités de types de clients appartenant à un ensemble de type de clients prédéfini. Le protocole HLS a été défini initialement pour un contexte dans lequel un serveur devait diffuser en direct un flux de données à un grand nombre de clients. Laisser le serveur définir les paramètres d'adaptation sur la base d'un ensemble de types de clients prédéfini est particulièrement cohérent dans ce contexte puisque, pour une question de coût calculatoire, il est impossible pour un serveur de générer autant de premiers flux de données qu'il y a de clients différents. Un inconvénient du protocole HLS est donc qu'un client qui aurait des capacités différentes des types de clients appartenant à l'ensemble de types de clients prédéfini, ne peut pas recevoir un flux de données optimisé pour ses capacités. Il n'a d'autre choix que de se rabattre sur un premier flux de données correspondant à un type de clients de l'ensemble de types de clients prédéfini. In the HLS protocol, the server is responsible for defining adaptation parameters to be applied to the initial data stream to obtain each first data stream. The definition of the adaptation parameters is done without consultation with a client by taking into account the capacities of the types of customers belonging to a set of predefined types of customers. The HLS protocol was initially defined for a context in which a server had to stream a data stream to a large number of clients. Letting the server set adaptation parameters based on a set of predefined client types is particularly consistent in this context since, for a computational cost question, it is impossible for a server to generate as many first data streams as there are different clients. A disadvantage of the HLS protocol is that a client that has capabilities different from the types of clients belonging to the predefined set of client types, can not receive a stream of data optimized for its capabilities. It has no choice but to fall back on a first data flow corresponding to a type of clients of the set of predefined types of customers.
Au fil des années, le protocole HLS a été utilisé dans d'autres contextes que le contexte initial pour lequel il a été défini. Ainsi, alors que le protocole HLS était généralement utilisé pour diffuser des flux de données à des clients correspondant effectivement à un type de clients appartenant à l'ensemble de types de clients prédéfini, il est maintenant utilisé pour d'autres clients ayant des capacités différentes de celles des types de clients de l'ensemble de types de clients prédéfini. Par ailleurs, le protocole HLS est maintenant utilisé pour diffuser en direct des flux de données dans des réseaux comportant un faible nombre de clients.  Over the years, HLS has been used in contexts other than the initial context for which it was defined. Thus, while the HLS protocol was typically used to broadcast data flows to clients that actually correspond to a type of client belonging to the predefined set of client types, it is now used for other clients with different capabilities. those of the customer types from the predefined set of customer types. In addition, the HLS protocol is now used to broadcast live data streams in networks with a small number of clients.
Il est souhaitable de pallier ces inconvénients de l'état de la technique.  It is desirable to overcome these disadvantages of the state of the art.
Il est notamment souhaitable de fournir un protocole de diffusion en direct de flux de données permettant une adaptation fine d'un flux de données à un client ne correspondant pas à un type de clients de l'ensemble de types de clients prédéfini. Il est particulièrement souhaitable que ce protocole de diffusion en direct de flux de données soit compatible avec le protocole HLS.  In particular, it is desirable to provide a streaming data streaming protocol that allows fine-tuning of a data stream to a client that does not match a type of client of the predefined set of client types. It is particularly desirable that this live streaming protocol is compatible with the HLS protocol.
Il est de plus souhaitable de fournir une solution qui soit simple à mettre en œuvre et à faible coût.  It is further desirable to provide a solution that is simple to implement and low cost.
Selon un premier aspect de la présente invention, la présente invention concerne un procédé de transmission d'un flux de données entre un serveur et un client utilisant un protocole de diffusion en direct, le procédé comprenant les étapes suivantes mises en œuvre par le serveur : obtenir un flux de données initial ; recevoir une demande d'informations descriptives pour le flux de données initial de la part dudit client ; vérifier qu'au moins une information représentative d'une capacité dudit client a été reçue en provenance dudit client ; si aucune information représentative d'une capacité dudit client n'a été reçue : adapter le flux de données initial pour obtenir une pluralité de premiers flux de données, chaque premier flux de données étant adapté à des capacités respectives d'un type de clients appartenant à un ensemble de types de clients prédéfinis ; décomposer en segments, dits premier segments, chaque premier flux de données ; et, transmettre audit client une première information descriptive permettant au client de demander une transmission de premiers segments d'au moins un premier flux de données; et si au moins une information représentative d'une capacité dudit client a été reçue : adapter ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ; décomposer en segments, dits seconds segments, le second flux de données ; et, transmettre au client une seconde information descriptive permettant au client de demander une transmission de seconds segments du second flux de données. According to a first aspect of the present invention, the present invention relates to a method for transmitting a data stream between a server and a client using a live broadcast protocol, the method comprising the following steps implemented by the server: obtain an initial data flow; receiving a request for descriptive information for the initial data flow from said client; verify that at least one piece of information representing a capacity of said client has been received from said client; if no information representative of a capacity of said client has been received: adapting the initial data stream to obtain a plurality of first data streams, each first data stream being adapted to respective capacities of a type of clients belonging to to a set of predefined client types; break down into segments, so-called first segments, each first data flow ; and, transmitting to said client a first descriptive information enabling the client to request a transmission of first segments of at least a first data stream; and if at least one piece of information representing a capacity of said client has been received: adapting said initial data stream to each received capacity in order to obtain a second data stream; decomposing into segments, called second segments, the second data stream; and, transmitting to the client a second descriptive information enabling the client to request a transmission of second segments of the second data stream.
De cette manière, le second client reçoit un second flux de données adapté finement à ses capacités.  In this way, the second client receives a second data stream finely adapted to its capabilities.
Dans un mode de réalisation, le protocole de diffusion en direct est le protocole de diffusion en direct basé sur HTTP.  In one embodiment, the live broadcast protocol is the HTTP-based live broadcast protocol.
Le procédé selon l'invention peut donc être mis en œuvre par des serveurs et des clients aptes à mettre en œuvre le protocole de diffusion en direct basé sur HTTP.  The method according to the invention can therefore be implemented by servers and clients able to implement the HTTP-based live broadcast protocol.
Dans un mode de réalisation, la seconde information descriptive est mise sous forme d'un fichier liste de lecture compatible avec le protocole de diffusion en direct.  In one embodiment, the second descriptive information is in the form of a playlist file compatible with the live broadcast protocol.
Un client qui saurait lire un fichier liste de lecture compatible avec le protocole de diffusion en direct saurait donc lire le fichier liste de lecture contenant la seconde information descriptive.  A client who could read a playlist file compatible with the live broadcast protocol would therefore read the file reading list containing the second descriptive information.
Dans un mode de réalisation, la transmission de la seconde information descriptive comprend une transmission au client d'une adresse de chargement du fichier liste de lecture compatible avec le protocole de diffusion en direct.  In one embodiment, the transmission of the second descriptive information comprises a transmission to the client of a loading address of the playlist file compatible with the live broadcast protocol.
Dans un mode de réalisation, le serveur transmet le fichier liste de lecture compatible avec le protocole de diffusion en direct au client, suite à une réception, en provenance du client, d'une requête HTTP contenant ladite adresse de chargement.  In one embodiment, the server transmits the play list file compatible with the live broadcast protocol to the client, following receipt from the client of an HTTP request containing said loading address.
Dans un mode de réalisation, le serveur transmet un second segment suite à une réception, en provenance du client, d'une requête HTTP contenant une adresse de chargement correspondant audit second segment, ladite adresse de chargement ayant été obtenue à partir du fichier liste de lecture compatible avec le protocole de diffusion en direct.  In one embodiment, the server transmits a second segment following reception, from the client, of an HTTP request containing a loading address corresponding to said second segment, said loading address having been obtained from the list file of playback compatible with the live broadcast protocol.
Dans un mode de réalisation, les capacités du client comprennent un format de compression vidéo supporté et/ou un format de compression audio supporté et/ou un format de compression d'image supporté et/ou un format de sous-titres supporté et/ou un type de réseau utilisé et/ou un débit de réception et/ou une résolution maximum d'image supportée et/ou un nombre de canaux audio supporté. In one embodiment, the client capabilities include a supported video compression format and / or a supported audio compression format and / or a supported image compression format and / or a supported subtitle format and / or a type of network used and / or a reception rate and / or a maximum supported image resolution and / or a supported number of audio channels.
Dans un mode de réalisation, lorsque ledit flux de données initial comprend un flux vidéo encodé dans un premier format de compression de vidéo, une adaptation dudit flux de données initial comprend un transcodage permettant de réduire un débit dudit flux vidéo et/ou une résolution d'images dudit flux vidéo et/ou une fréquence d'image dudit flux vidéo et/ou une transformation dudit flux vidéo afin d'assurer une compatibilité avec un second format de compression vidéo, et lorsque ledit flux de données initial comprend un flux audio encodé dans un premier format de compression audio, une adaptation dudit flux de données initial comprend un transcodage permettant de réduire un débit dudit flux audio et/ou un nombre de canaux audio et/ou une transformation dudit flux audio afin d'assurer une compatibilité avec un second format de compression audio.  In one embodiment, when said initial data stream comprises a video stream encoded in a first video compression format, an adaptation of said initial data stream comprises transcoding to reduce a bit rate of said video stream and / or a resolution of the video stream. images of said video stream and / or an image frequency of said video stream and / or a transformation of said video stream to ensure compatibility with a second video compression format, and when said initial data stream comprises an encoded audio stream in a first audio compression format, an adaptation of said initial data stream comprises a transcoding for reducing a bit rate of said audio stream and / or a number of audio channels and / or a transformation of said audio stream to ensure compatibility with a second audio compression format.
Selon un deuxième aspect de la présente invention, l'invention concerne un dispositif de type serveur apte à transmettre un flux de données en utilisant un protocole de diffusion en direct, comprenant les moyens suivants : des moyens d'obtention pour obtenir un flux de données initial ; des moyens de réception pour recevoir une demande d'information descriptive pour le flux de données initial de la part d'un client ; des moyens de vérification pour vérifier qu'au moins une information représentative d'une capacité dudit client a été reçue ; des moyens mis en œuvre lorsqu' aucune information représentative d'une capacité dudit client a été reçue comprenant : des moyens d'adaptation pour adapter le flux de données initial pour obtenir une pluralité de premiers flux de données, chaque premier flux de données étant adapté à des capacités respectives d'un type de clients appartenant à un ensemble de type de clients prédéfinis ; des moyens de décomposition pour décomposer en segments, dits premiers segments, chaque premier flux de données ; et, des moyens de transmission pour transmettre à un client une première information descriptive permettant au client de demander une transmission des premiers segments d'au moins un premier flux de données; des moyens mis en œuvre lorsqu'au moins une information représentative d'une capacité dudit client a été reçue comprenant : des moyens d'adaptation pour adapter ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ; des moyens de décomposition pour décomposer en segments, dits seconds segments, le second flux de données ; et, des moyens de transmission pour transmettre au client une seconde information descriptive permettant au client de demander une transmission de seconds segments du second flux de données. According to a second aspect of the present invention, the invention relates to a server-type device capable of transmitting a data stream using a live broadcast protocol, comprising the following means: obtaining means for obtaining a data stream initial; receiving means for receiving a request for descriptive information for the initial data stream from a client; verification means for verifying that at least one piece of information representing a capacity of said client has been received; means implemented when no information representative of a capacity of said client has been received comprising: adaptation means for adapting the initial data stream to obtain a plurality of first data streams, each first data stream being adapted respective capabilities of a type of clients belonging to a set of predefined client types; decomposition means for splitting into segments, so-called first segments, each first data stream; and, transmission means for transmitting to a client a first descriptive information enabling the client to request a transmission of the first segments of at least a first data stream; means implemented when at least one piece of information representing a capacity of said client has been received comprising: adaptation means for adapting said initial data stream to each received capacity in order to obtain a second data stream; decomposition means for breaking into segments, called second segments, the second data stream; and, transmission means for transmitting to the customer a second information descriptive description enabling the client to request transmission of second segments of the second data stream.
Selon un troisième aspect de la présente invention, l'invention concerne un dispositif de type client apte à recevoir un flux de données en utilisant le protocole de diffusion en direct basé sur HTTP, comprenant les moyens suivants : des moyens de transmission pour transmettre au moins une information représentative d'une capacité dudit dispositif de type client à un serveur ; des moyens pour recevoir un fichier texte compatible avec le protocole de diffusion en direct basé sur HTTP, le fichier texte correspondant à un fichier de données initial et permettant d'obtenir des adresses de chargement de segments correspondant à un flux de données, dit second flux de données, résultant d'une adaptation par le serveur du flux de données initial à chaque capacité dudit dispositif de type client ; des moyens de transmission pour transmettre une requête contenant une adresse de chargement d'un segment du second flux de données, l'adresse de chargement ayant été obtenue à partir du fichier texte compatible avec le protocole de diffusion en direct basé sur HTTP ; des moyens de réception pour recevoir le segment correspondant à la requête transmise.  According to a third aspect of the present invention, the invention relates to a client device capable of receiving a data stream using the HTTP-based live broadcasting protocol, comprising the following means: transmission means for transmitting at least information representative of a capacity of said client device to a server; means for receiving a text file compatible with the HTTP-based live broadcast protocol, the text file corresponding to an initial data file and making it possible to obtain segment loading addresses corresponding to a data stream, said second stream data, resulting from an adaptation by the server of the initial data stream to each capacity of said client type device; transmission means for transmitting a request containing a loading address of a segment of the second data stream, the loading address having been obtained from the text file compatible with the HTTP-based live broadcast protocol; receiving means for receiving the segment corresponding to the transmitted request.
Selon un quatrième aspect de la présente invention, l'invention concerne un système de transmission d'un flux de données comprenant un serveur selon le deuxième aspect et au moins un client selon le troisième aspect.  According to a fourth aspect of the present invention, the invention relates to a system for transmitting a data stream comprising a server according to the second aspect and at least one client according to the third aspect.
Selon un cinquième aspect de la présente invention, l'invention concerne un programme d'ordinateur, comprenant des instructions pour mettre en œuvre, par un dispositif, le procédé selon le premier aspect, lorsque ledit programme est exécuté par un processeur du dispositif.  According to a fifth aspect of the present invention, the invention relates to a computer program, comprising instructions for implementing, by a device, the method according to the first aspect, when said program is executed by a processor of the device.
Selon un sixième aspect de la présente invention, l'invention concerne des moyens de stockage, stockant un programme d'ordinateur comprenant des instructions pour mettre en œuvre, par un dispositif, le procédé selon le premier aspect, lorsque ledit programme est exécuté par un processeur dudit dispositif.  According to a sixth aspect of the present invention, the invention relates to storage means, storing a computer program comprising instructions for implementing, by a device, the method according to the first aspect, when said program is executed by a processor of said device.
Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels :  The characteristics of the invention mentioned above, as well as others, will appear more clearly on reading the following description of an exemplary embodiment, said description being given in relation to the attached drawings, among which:
- la Fig. 1 illustre schématiquement un exemple de système dans lequel est mis en œuvre un procédé de transmission de données utilisant un protocole de diffusion en direct ; - la Fig. 2A illustre schématiquement un exemple d'architecture matérielle d'un dispositif client mettant en œuvre l'invention ; FIG. 1 schematically illustrates an exemplary system in which is implemented a data transmission method using a live broadcast protocol; FIG. 2A schematically illustrates an example of a hardware architecture of a client device embodying the invention;
- la Fig. 2B illustre schématiquement un exemple d'architecture matérielle d'un dispositif serveur mettant en œuvre l'invention ;  FIG. 2B schematically illustrates an example of a hardware architecture of a server device embodying the invention;
- La Fig. 3A illustre schématiquement un exemple de mise en œuvre d'un procédé selon l'invention ;  FIG. 3A schematically illustrates an example of implementation of a method according to the invention;
- les Figs. 3B et 3C illustrent schématiquement un exemple de mise en œuvre du procédé de type protocole HLS par un serveur ;  - Figs. 3B and 3C schematically illustrate an example of implementation of the HLS protocol method by a server;
- la Fig. 3D illustre schématiquement un exemple de mise en œuvre d'un procédé de type protocole HLS par un client ;  FIG. 3D schematically illustrates an example of implementation of a HLS protocol method by a client;
- les Figs. 4A et 4B illustrent schématiquement un exemple d'une mise en œuvre par un serveur d'un procédé de diffusion en direct d'un flux de données permettant une adaptation fine du flux de données à des capacités d'un client; et,  - Figs. 4A and 4B schematically illustrate an example of a server implementation of a streaming method of a data stream for fine-tuning the data flow to a client's capabilities; and,
- la Fig. 4C illustre schématiquement un exemple d'une mise en œuvre par un client du procédé de diffusion en direct d'un flux de données permettant une adaptation fine du flux de données aux capacités du client.  FIG. 4C schematically illustrates an example of a implementation by a client of the streaming method of a data stream for fine-tuning the data flow to the capabilities of the client.
Par la suite l'invention est décrite dans le cadre du protocole HLS. L'invention est toutefois adaptée à d'autres protocoles ou procédés de diffusion en direct de flux de données entre un serveur et au moins un client possédant un fonctionnement similaire au protocole HLS. Par ailleurs, l'invention est décrite dans le cadre d'un réseau local (« Local Area Network » en terminologie anglo-saxonne) dans lequel un serveur multimédia (« set top box » en terminologie anglo-saxonne) obtient un flux de données à partir d'un réseau, tel que le réseau internet, à travers une passerelle réseau (« gateway » en terminologie anglo-saxonne) et diffuse des flux de données vers des clients du réseau local. L'invention est toutefois adaptée à d'autres contextes dans lesquels un serveur diffuse à travers un réseau un flux de données vers au moins un client.  In the following the invention is described in the context of the HLS protocol. The invention is, however, adapted to other protocols or methods of streaming live data between a server and at least one client having a similar operation to the HLS protocol. Furthermore, the invention is described in the context of a local area network ("Local Area Network") in which a multimedia server ("set top box" in English terminology) obtains a data stream. from a network, such as the Internet, through a gateway ("gateway" in English terminology) and broadcasts data flows to clients of the local network. The invention is, however, adapted to other contexts in which a server diffuses through a network a data stream to at least one client.
La Fig. 1 illustre schématiquement un exemple de système dans lequel est mis en œuvre un procédé de transmission de données utilisant un protocole de diffusion en direct. Le système comprend une passerelle réseau 12 reliée par un lien réseau 11, tel qu'un lien Ethernet, à un réseau 10, tel que le réseau Internet. La passerelle réseau 12 est un point d'entrée vers un réseau local. Ce réseau local comprend un serveur 14, tel qu'un serveur multimédia ou un décodeur TV, connecté à la passerelle réseau 12 par un lien réseau 13 tel qu'un lien Ethernet, un lien sans fils ou un lien CPL (Courant Porteur en Ligne). Le serveur 14 est relié à un client 16 par un lien réseau 15, tel qu'un lien Ethernet, un lien sans fils ou un lien CPL. Le client 16 peut être par exemple un téléviseur, un ordinateur, une tablette ou un téléphone intelligent (« smart phone » en terminologie anglo-saxonne). Fig. 1 schematically illustrates an exemplary system in which is implemented a data transmission method using a live broadcast protocol. The system comprises a network gateway 12 connected by a network link 11, such as an Ethernet link, to a network 10, such as the Internet network. The network gateway 12 is an entry point to a local area network. This local area network comprises a server 14, such as a multimedia server or a TV decoder, connected to the network gateway 12 by a network link 13 such as an Ethernet link, a wireless link or a CPL link. Online Carrier). The server 14 is connected to a client 16 by a network link 15, such as an Ethernet link, a wireless link or a PLC link. The client 16 may be for example a television, a computer, a tablet or a smart phone ("smart phone" in English terminology).
La passerelle réseau 12 reçoit des flux de données encapsulés dans des paquets The network gateway 12 receives data flows encapsulated in packets
TCP (protocole de contrôle de transmission, « Transmission Control Protocol », RFC 793), RTP (protocole de transmission temps réel, « Real-time Transmission Protocol », RFC 1889) ou UDP (protocole de datagramme utilisateur, « User Datagram Protocol » en terminologie anglo-saxonne). Chaque flux de données est ensuite extrait des paquets par la passerelle réseau 12 et fourni au serveur 14 sous forme de flux de transport MPEG TS (« Moving Picture Expert Group Transport Stream part 1 », ISO/IEC 13818-1). Chaque flux de transport MPEG TS peut contenir au moins un flux vidéo et/ou au moins un flux audio et/ou au moins un flux de métadonnées tel qu'un flux de sous titres. Lorsque le client 16 choisit un flux de données initial disponible sur le serveur 14, le serveur 14 génère une pluralité de premiers flux de données selon un procédé que nous décrivons en relation avec la Fig. 3B. Après une sélection par le client 16 d'un des premier flux de données, une diffusion du premier flux de données sélectionné, selon un procédé décrit en relation avec les Figs. 3C et 3D, est mise en œuvre. TCP (Transmission Control Protocol, RFC 793), RTP (Real-time Transmission Protocol, RFC 1889), or UDP (User Datagram Protocol) in Anglo-Saxon terminology). Each data stream is then extracted from the packets by the network gateway 12 and supplied to the server 14 in the form of an MPEG TS transport stream ("Moving Picture Expert Group Transport Stream part 1", ISO / IEC 13818-1). Each MPEG TS transport stream may contain at least one video stream and / or at least one audio stream and / or at least one metadata stream such as a subtitle stream. When the client 16 selects an initial data stream available on the server 14, the server 14 generates a plurality of first data streams according to a method that we describe in relation to FIG. 3B. After selection by the client 16 of one of the first data streams, a broadcast of the first selected data stream, according to a method described in relation to FIGS. 3C and 3D, is implemented.
Les Figs. 4A, 4B et 4C décrivent une variante des procédés décrits en relation avec les Figs. 3A, 3B et 3C, cette variante permettant une adaptation fine d'un flux de données initial à un client ne correspondant pas à un type de clients de l'ensemble de types de clients prédéfini.  Figs. 4A, 4B and 4C describe a variant of the methods described in relation to FIGS. 3A, 3B and 3C, this variant allowing a fine adaptation of an initial data flow to a client that does not correspond to a type of client of the set of predefined client types.
La Fig. 3A illustre schématiquement un exemple de mise en œuvre d'un procédé selon l'invention.  Fig. 3A schematically illustrates an example of implementation of a method according to the invention.
Dans une étape 30, le serveur 14 obtient un ensemble de flux de données. Cet ensemble de flux de données peut, par exemple, être obtenu à partir d'une mémoire du serveur 14 ou fourni par la passerelle réseau 12. Une information représentant les flux de données disponibles sur le serveur 14 est alors diffusée au client 16. Le client 16 sélectionne l'un des flux de données disponible, et transmet une information représentant le flux de données sélectionné au serveur 14. Le flux de données sélectionné par le client 16 devient alors le flux de données initial.  In a step 30, the server 14 obtains a set of data streams. This set of data streams can, for example, be obtained from a memory of the server 14 or provided by the network gateway 12. Information representing the data streams available on the server 14 is then broadcast to the client 16. Client 16 selects one of the available data streams, and transmits information representing the selected data stream to the server 14. The data stream selected by the client 16 then becomes the original data stream.
Lors d'une étape 31, le serveur 14 reçoit l'information représentant le flux de données sélectionné transmise par le client 16. La réception de l'information représentant le flux de données sélectionné fait office de réception d'une demande d'informations descriptives pour le flux de données initial. In a step 31, the server 14 receives the information representing the selected data stream transmitted by the client 16. The reception of the information representing the selected data stream acts as a receipt of a descriptive information request for the initial data flow.
Dans une étape 32, le serveur 14 vérifie qu'il a reçu une information représentative des capacités du client 16. L'information représentative des capacités du client 16 a pu avoir été reçue préalablement à la réception de l'information représentant le flux de données sélectionné ou le serveur peut, à la suite de la réception de l'information représentant le flux de données sélectionné, se mettre en attente de réception d'au moins une information représentative des capacités du client 16 pendant un temps prédéfini.  In a step 32, the server 14 verifies that it has received information representative of the capabilities of the client 16. The information representative of the capabilities of the client 16 may have been received prior to the reception of the information representing the data flow. selected or the server may, following the receipt of the information representing the selected data stream, wait for reception of at least one piece of information representative of the capabilities of the client 16 for a predefined time.
Si après une durée égale au temps prédéfini le serveur 14 n'a reçu aucune information représentative des capacités du client 16, il met en œuvre le protocole HLS lors d'une étape 33. Un exemple de mise en œuvre du protocole HLS par le serveur 14 est décrit en relation avec les Figs. 3B et 3C.  If after a period equal to the predefined time the server 14 has received no information representative of the capabilities of the client 16, it implements the HLS protocol in a step 33. An example of implementation of the HLS protocol by the server 14 is described in relation with FIGS. 3B and 3C.
Si, lors de l'étape 32, le serveur 14 constate qu'il a reçu au moins une information représentative des capacités du client 16, il met en œuvre, lors d'une étape 34, un procédé permettant une adaptation fine du flux de données initial aux capacités du client 16. Un exemple de mise en œuvre par le serveur 14 du procédé permettant une adaptation fine du flux de données initial aux capacités du client 16 est décrit en relation avec les Figs. 4 A et 4B.  If, during step 32, the server 14 finds that it has received at least one piece of information representative of the capabilities of the client 16, it implements, during a step 34, a method allowing a fine adaptation of the flow of initial data to the capabilities of the client 16. An example of implementation by the server 14 of the method for fine-tuning the initial data stream to the capabilities of the client 16 is described in relation to FIGS. 4A and 4B.
Dans un mode de réalisation, le serveur 14 diffuse l'information représentant les flux de données disponibles sur le serveur 14 avant d'avoir reçu effectivement les flux de données correspondants. C'est alors la réception par le serveur de la demande d'informations descriptives pour un flux de données qui déclenche l'obtention effective par le serveur 14 du flux de données demandé.  In one embodiment, the server 14 broadcasts the information representing the available data streams on the server 14 before actually receiving the corresponding data streams. It is then the receipt by the server of the descriptive information request for a data flow that triggers the effective obtaining by the server 14 of the requested data stream.
Les Figs. 3B et 3C illustrent schématiquement un exemple de mise en œuvre du protocole HLS par le serveur 14.  Figs. 3B and 3C schematically illustrate an example of implementation of the HLS protocol by the server 14.
Dans une étape 302, le serveur 14 adapte le flux de données initial pour obtenir une pluralité de premiers flux de données. Chaque premier flux de données est adapté à des capacités respectives d'un type de clients appartenant à un ensemble de types de clients prédéfinis. Les capacités d'un client comprennent par exemple :  In a step 302, the server 14 adapts the initial data stream to obtain a plurality of first data streams. Each first data stream is adapted to respective capabilities of a type of clients belonging to a set of predefined client types. The capabilities of a customer include for example:
- un format de compression vidéo supporté. Un client peut par exemple supporter un ou plusieurs des formats de compression vidéo suivants : MPEG-2 (ISO/IEC 13818-2), MPEG-4 partie 2 (ISO/CEI 14496-2), H264/AVC (ISO/IEC 14496-10 - MPEG-4 Part 10, codage vidéo avancé (« Advanced Video Coding » en terminologie anglo-saxonne) / ITU-T H.264), HEVC (ISO/IEC 23008-2 - MPEG-H Part 2, codage vidéo haute efficacité (High Effîciency Video Coding en terminologie anglo-saxonne) / ITU-T H.265), - a supported video compression format. For example, a client can support one or more of the following video compression formats: MPEG-2 (ISO / IEC 13818-2), MPEG-4 Part 2 (ISO / IEC 14496-2), H264 / AVC (ISO / IEC 14496) -10 - MPEG-4 Part 10, advanced video coding ("Advanced Video Coding" / ITU-T H.264), HEVC (ISO / IEC 23008-2 - MPEG-H Part 2, High Efficiency Video Coding (High Efficiency Video Coding) ) / ITU-T H.265),
- un format de compression audio supporté. Un client peut par exemple supporter un ou plusieurs des formats de compression audio suivants : MP3(MPEG-1 niveau III), AAC (Codage Audio Avancé, « Advanced Audio Coding » en terminologie anglo-saxonne),  - a supported audio compression format. For example, a client can support one or more of the following audio compression formats: MP3 (MPEG-1 Level III), AAC (Advanced Audio Coding), Advanced Audio Coding (English),
- un format de compression d'images supporté. Un client peut par exemple supporter un ou plusieurs des formats de compression d'image suivants : - a supported image compression format. For example, a client can support one or more of the following image compression formats:
JPEG (ISO/CEI 10918-1/UIT-T Recommandation T.81), JPEG2000 (ISO/CEI 15444-1), JPEG (ISO / IEC 10918-1 / ITU-T Recommendation T.81), JPEG2000 (ISO / IEC 15444-1),
si le client possède des moyens de décodage de sous-titres,  if the customer has means for decoding subtitles,
- un type de réseau utilisé par le client : Ethernet, Wi-Fi, CPL,  - a type of network used by the customer: Ethernet, Wi-Fi, PLC,
- un débit de réception,  - a reception rate,
une résolution maximum d'images supportée par le client,  a maximum image resolution supported by the client,
- un nombre de canaux audio supporté par le client.  - a number of audio channels supported by the client.
Plusieurs types d'adaptation peuvent être appliqués à un flux de données initial lors de l'obtention des premiers sous-flux de données. Lorsqu'un flux de données initial comprend un flux vidéo encodé dans un premier format de compression de vidéo, un transcodage peut être appliqué au flux vidéo afin de réduire un débit dudit flux vidéo et/ou de réduire une résolution d'images dudit flux vidéo et/ou de réduire une fréquence d'images dudit flux vidéo et/ou de transformer ledit flux vidéo afin d'assurer une compatibilité avec un second format de compression vidéo. Lorsqu'un flux de données initial comprend un flux audio encodé dans un premier format de compression audio, un transcodage peut être appliqué au flux audio afin de réduire un débit dudit flux audio et/ou de réduire un nombre de canaux dudit flux audio et/ou de transformer ledit flux audio afin d'assurer une compatibilité avec un second format de compression audio. D'autres types d'adaptation peuvent comprendre une suppression d'un flux de sous-titres lorsqu'un type de clients de l'ensemble de types de clients prédéfini n'est pas en capacité de décoder ledit flux de sous titres.  Several types of adaptation can be applied to an initial data stream when obtaining the first sub-data flows. When an initial data stream includes a video stream encoded in a first video compression format, transcoding may be applied to the video stream to reduce a bit rate of said video stream and / or to reduce an image resolution of said video stream and / or reducing a frame rate of said video stream and / or transforming said video stream to provide compatibility with a second video compression format. When an initial data stream includes an audio stream encoded in a first audio compression format, transcoding may be applied to the audio stream to reduce a rate of said audio stream and / or to reduce a number of channels of said audio stream and / or or transforming said audio stream to provide compatibility with a second audio compression format. Other types of adaptation may include deleting a subtitle stream when a client type of the predefined client type set is not able to decode the subtitle stream.
Dans une étape 303, le serveur 14 décompose en segments, dits premiers segments, chaque premier flux de données. Lors de l'étape 303, le serveur 14 associe chaque segment à une information représentative dudit segment comprenant une adresse URI, un numéro de séquence et une taille dudit segment. In a step 303, the server 14 breaks down into segments, called first segments, each first data stream. In step 303, the server 14 associates each segment to information representative of said segment comprising a URI address, a sequence number and a size of said segment.
Lors d'étapes 304 et 305, le serveur 14 transmet au client 16, une première information descriptive permettant d'obtenir, pour chaque premier flux de données, au moins une caractéristique dudit premier flux de données et pour chaque premier segment, une adresse de chargement dudit premier segment. La première information descriptive permet au client 16 de demander une transmission de premiers segments en fonction de capacités du client 16 afin d'obtenir une version du flux de données initial adaptée auxdites capacités.  During steps 304 and 305, the server 14 transmits to the client 16, a first descriptive information making it possible to obtain, for each first data stream, at least one characteristic of said first data stream and for each first segment, an address of loading said first segment. The first descriptive information allows the client 16 to request a transmission of first segments based on capabilities of the client 16 to obtain a version of the initial data stream adapted to said capabilities.
Lors de l'étape 304, le serveur 14 crée un fichier liste de lecture pour chaque premier flux de données. Pour chaque premier flux de données, le serveur 14 insère l'information représentative de chaque segment dudit premier flux de données qu'il souhaite rendre accessible au client 16 dans le fichier liste de lecture correspondant audit premier flux de données. Suite à la création des fichiers liste de lecture, le serveur 14 alloue une adresse URI à chaque fichier liste de lecture. Un fichier liste de lecture maître est ensuite créé, dans lequel le serveur 14 insère, pour chaque premier flux de données, l'adresses URI du fichier liste de lecture correspondant audit premier flux de données et une description dudit premier flux de données. Une description d'un premier flux de données comprise dans un fichier liste de lecture maître peut, par exemple, indiquer pour quel type de clients de l'ensemble de types de clients prédéfini le premier flux de données a été adapté et/ou un débit du premier flux de données et/ou une résolution d'image d'un flux vidéo contenu dans le premier flux de données et/ou une fréquence d'image d'un flux vidéo contenu dans le premier flux de données et/ou un nombre de canaux audio d'un flux audio contenu dans le premier flux de données. Par la suite, le serveur 14 associe une adresse URI au fichier liste de lecture maître et envoie cette adresse URI au client 16 lors de l'étape 305. Cette adresse URI étant, pour le client 16, la première information descriptive permettant d'obtenir une version du flux de données initial.  In step 304, the server 14 creates a read list file for each first data stream. For each first data stream, the server 14 inserts the information representative of each segment of said first data stream that it wishes to make accessible to the client 16 in the read list file corresponding to said first data stream. Following the creation of the playlist files, the server 14 allocates a URI to each playlist file. A master read list file is then created, in which the server 14 inserts, for each first data stream, the URI address of the read list file corresponding to said first data stream and a description of said first data stream. A description of a first data stream included in a master list file may, for example, indicate for which type of clients of the set of predefined client types the first data stream has been adapted and / or a bit rate. the first data stream and / or an image resolution of a video stream contained in the first data stream and / or an image rate of a video stream contained in the first data stream and / or a number audio channels of an audio stream contained in the first data stream. Subsequently, the server 14 associates a URI address to the master list file and sends this URI address to the client 16 in step 305. This URI is, for the client 16, the first descriptive information to obtain a version of the initial data flow.
Dans une étape 31 1, le serveur 14 reçoit en provenance du client 16, une requête HTTP contenant l'URI du fichier liste de lecture maître. Suite à la réception de cette requête, le serveur 14 transmet le fichier liste de lecture maître au client 16 pour qu'il sélectionne un des premiers flux de données. Suite à cette sélection, le serveur 14 reçoit une requête HTTP contenant l'adresse URI du fichier liste de lecture correspondant au premier flux de données sélectionné. Lors d'une étape 312, le serveur 14 transmet au client 16 le fichier liste de lecture correspondant au flux de données sélectionné. In a step 31 1, the server 14 receives from the client 16, an HTTP request containing the URI of the master playlist file. Following reception of this request, the server 14 transmits the master reading list file to the client 16 so that it selects one of the first data streams. Following this selection, the server 14 receives an HTTP request containing the URI address of the playlist file corresponding to the first selected data stream. In a step 312, the server 14 transmits to the client 16 the playlist file corresponding to the selected data stream.
Dans une étape 313, le serveur 14 vérifie s'il a reçu une requête HTTP contenant une adresse URI d'un premier segment demandé par le client 16. Si c'est le cas, lors d'une étape 315, le serveur 14 transmet le premier segment demandé au client 16 et retourne à l'étape 313. Si aucune requête HTTP pour un nouveau segment n'est reçue pendant une durée prédéfinie ou que le dernier segment transmis est un segment final du premier flux de données, le serveur 14 met fin à la diffusion du premier flux de données au cours d'une étape 314.  In a step 313, the server 14 checks whether it has received an HTTP request containing a URI address of a first segment requested by the client 16. If this is the case, in a step 315, the server 14 transmits the first segment requested from the client 16 and returns to step 313. If no HTTP request for a new segment is received for a predefined duration or the last transmitted segment is a final segment of the first data stream, the server 14 terminates the broadcast of the first data stream during a step 314.
La Fig. 3D illustre schématiquement un exemple de mise en œuvre du protocole Fig. 3D schematically illustrates an example of implementation of the protocol
HLS par le client 16. Le client 16 est supposé avoir sélectionné un flux de données initial parmi un ensemble de flux de données disponibles sur le serveur 14. Dans cet exemple, le client 16 n'a pas transmis ses capacités au serveur 14. Le client 16 a donc reçu l'adresse URI du fichier liste de lecture maître correspondant au flux de données initial sélectionné transmise lors de l'étape 305. HLS by Client 16. Client 16 is assumed to have selected an initial data stream from a set of data streams available on server 14. In this example, client 16 has not transmitted its capabilities to server 14. Client 16 has therefore received the URI address of the master read list file corresponding to the selected initial data stream transmitted in step 305.
Dans une étape 321, à un moment choisi, par exemple, par un utilisateur du client 16, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI du fichier liste de lecture maître correspondant au flux de données initial qu'il a sélectionné. En retour, le client 16 reçoit de la part du serveur 14, ledit fichier liste de lecture maître. Le client 16 sélectionne alors un premier flux de données parmi les premiers flux de données mentionnés dans le fichier liste de lecture maître en utilisant les descriptions de chaque premier flux de données. Lors de cette sélection, le client 16 compare les capacités dudit client 16 avec les informations contenues dans les descriptions de chaque premier flux de données. Si le client 16 correspond à un type de clients compris dans l'ensemble de types de clients prédéfini, le client 16 choisit le premier flux de données correspondant à ce type de clients de l'ensemble prédéfini. Si le client 16 ne correspond pas à un type de clients représenté dans l'ensemble de types de clients prédéfinis, le client 16 choisit un premier flux de données ayant des caractéristiques les plus proches possibles des capacités du client 16.  In a step 321, at a time chosen, for example, by a user of the client 16, the client 16 transmits an HTTP request to the server 14 containing the URI address of the master reading list file corresponding to the initial data stream that it selected. In return, the client 16 receives from the server 14, said master list file. Client 16 then selects a first data stream from among the first data streams mentioned in the master list file using the descriptions of each first data stream. During this selection, the client 16 compares the capabilities of said client 16 with the information contained in the descriptions of each first data stream. If the client 16 corresponds to a type of clients included in the set of predefined client types, the client 16 selects the first data stream corresponding to this type of clients from the predefined set. If the client 16 does not correspond to a type of client represented in the set of predefined client types, the client 16 chooses a first data stream having characteristics as close as possible to the capabilities of the client 16.
Après avoir sélectionné un des premiers flux de données, le client 16 transmet au serveur 14 une requête contenant l'adresse URI du fichier liste de lecture correspondant au premier flux de données sélectionné.  After selecting one of the first data streams, the client 16 transmits to the server 14 a request containing the URI address of the playlist file corresponding to the first selected data stream.
Lors d'une étape 322, le client 16 reçoit le fichier liste de lecture correspondant au premier flux de données qu'il a sélectionné. Dans une étape 323, le client 16 recherche dans le fichier liste de lecture un premier segment à demander au serveur 14. Lorsque le client 16 demande pour la première fois un premier segment pour le premier flux de données qu'il a sélectionné, le client 16 sélectionne en général le premier segment ayant le numéro de séquence le plus faible dans le fichier liste de lecture qu'il a reçu. In a step 322, the client 16 receives the playlist file corresponding to the first data stream that it has selected. In a step 323, the client 16 searches in the playlist file for a first segment to request the server 14. When the client 16 requests for the first time a first segment for the first data stream that he has selected, the client 16 generally selects the first segment having the lowest sequence number in the playlist file it has received.
Dans une étape 324, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI dudit premier segment sélectionné.  In a step 324, the client 16 transmits an HTTP request to the server 14 containing the URI address of said first selected segment.
Dans une étape 325, le client 16 reçoit ledit premier segment et fournit ce premier segment à un module de décodage prenant en charge un décodage du premier segment.  In a step 325, the client 16 receives said first segment and provides this first segment to a decoding module supporting a decoding of the first segment.
Dans une étape 326, le client 16 vérifie si la diffusion du flux de données initial qu'il a sélectionné doit être poursuivie. La diffusion d'un flux de données peut, par exemple, être contrôlée par un utilisateur du client 16. Si la diffusion doit être poursuivie, le client 16 met de nouveau en œuvre l'étape 323 et demande le premier segment suivant le premier segment précédemment demandé, i.e. le premier segment ayant un numéro de séquence incrémenté d'une unité par rapport au numéro de séquence du premier segment précédemment demandé. Si la diffusion ne doit pas être poursuivie, le client 16 y met fin lors d'une étape 327.  In a step 326, the client 16 checks whether the broadcast of the initial data stream that it has selected must be continued. The broadcast of a data stream may, for example, be controlled by a user of the client 16. If the broadcast is to be continued, the client 16 again implements step 323 and requests the first segment following the first segment previously requested, ie the first segment having a sequence number incremented by one relative to the sequence number of the previously requested first segment. If the broadcast does not have to be continued, the client 16 terminates it during a step 327.
Dans un mode de réalisation adapté à un client ayant des capacités variant dans le temps, lors de l'étape 321, le client 16 peut transmettre au serveur 14 une requête HTTP contenant toutes les adresses URI contenues dans le fichier liste de lecture maître. De cette manière le client 16 reçoit chaque fichier liste de lecture correspondant au flux de données initial qu'il a sélectionné. Lors de l'étape 326, si la diffusion du flux de données initial doit être poursuivie, le client 16 sélectionne un premier flux de données compatible avec des capacités du client 16 constatées au moment de la mise en œuvre de l'étape 326. Le client 16 sélectionne ensuite le prochain segment à demander au serveur dans le fichier liste de lecture correspondant au premier flux de données sélectionné lors de l'étape 326.  In an embodiment adapted to a client having time-varying capabilities, in step 321, the client 16 may transmit to the server 14 an HTTP request containing all the URIs contained in the master playlist file. In this manner the client 16 receives each read list file corresponding to the initial data stream that it has selected. In step 326, if the broadcast of the initial data stream is to be continued, the client 16 selects a first data stream compatible with the capabilities of the client 16 found at the time of the implementation of step 326. client 16 then selects the next segment to request from the server in the playlist file corresponding to the first data stream selected in step 326.
L'exemple de mise en œuvre du protocole HLS décrit en relation avec les Figs. 3B, 3C et 3D montre que le protocole HLS actuel ne permet pas une adaptation fine du flux de données aux capacités du client 16.  The exemplary implementation of the HLS protocol described in relation to FIGS. 3B, 3C and 3D shows that the current HLS protocol does not allow a fine adaptation of the data flow to the capabilities of the client 16.
Les Figs. 4A et 4B illustrent schématiquement un exemple d'une mise en œuvre par le serveur 14 d'un procédé de diffusion en direct d'un flux de données permettant une adaptation fine du flux de données aux capacités d'un client. Ce procédé correspond à l'étape 34 décrite en relation avec la Fig. 3A. Figs. 4A and 4B schematically illustrate an example of an implementation by the server 14 of a streaming method of a data stream allowing a fine tuning of the data flow to the capabilities of a customer. This process corresponds to the step 34 described in connection with FIG. 3A.
Dans une étape 402 suivant l'étape 32, de la même manière que le serveur 14 avait adapté le flux de données initial aux capacités respectives des types de clients de l'ensemble de types de clients prédéfini pour obtenir les premiers flux de données, le serveur 14 adapte le flux de données initial à chaque capacité du client 16 reçue pour obtenir un second flux de données.  In a step 402 following step 32, in the same way that the server 14 had adapted the initial data stream to the respective capabilities of the client types of the set of predefined client types to obtain the first data streams, the Server 14 adjusts the initial data stream to each capacity of the client 16 received to obtain a second data stream.
Dans une étape 403, le serveur 14 décompose en segments, dits seconds segments, le second flux de données. Chaque second segment est associé à une adresse URI.  In a step 403, the server 14 breaks down into segments, called second segments, the second data stream. Each second segment is associated with a URI.
Lors d'étapes 404 et 405, le serveur 14 transmet au client 16 une seconde information descriptive permettant d'obtenir, pour chaque second segment, l'adresse URI dudit second segment. La seconde information descriptive permet au client 16 de demander une transmission des seconds segments afin d'obtenir le second flux de données.  During steps 404 and 405, the server 14 transmits to the client 16 a second descriptive information for obtaining, for each second segment, the URI address of said second segment. The second descriptive information allows the client 16 to request a transmission of the second segments to obtain the second data stream.
Lors de l'étape 404, le serveur 14 crée un fichier liste de lecture et y insère les adresses URI, les numéros de séquence et les durées des seconds segments. Le serveur 14 alloue ensuite une adresse URI au fichier liste de lecture ainsi créé.  In step 404, the server 14 creates a playlist file and inserts the URIs, sequence numbers and durations of the second segments. The server 14 then allocates a URI address to the playlist file thus created.
Lors de l'étape 405, l'adresse URI du fichier liste de lecture contenant les adresses URI des seconds segments est transmise au client 16. L'adresse URI du fichier liste de lecture contenant les adresses URI des seconds segments correspond à la seconde information descriptive permettant au client 16 de demander une transmission des seconds segments afin d'obtenir le second flux de données.  In step 405, the URI address of the playlist file containing the URIs of the second segments is transmitted to the client 16. The URI address of the playlist file containing the URIs of the second segments corresponds to the second information. descriptive allowing the client 16 to request a transmission of the second segments to obtain the second data stream.
Dans une étape 411, le serveur 14 reçoit une requête HTTP en provenance du client 16 contenant l'adresse URI du fichier liste de lecture contenant les adresses URI des second segments.  In a step 411, the server 14 receives an HTTP request from the client 16 containing the URI address of the playlist file containing the URIs of the second segments.
Dans une étape 412, le serveur 14 transmet le fichier liste de lecture contenant les adresse URI des seconds segments au client 16.  In a step 412, the server 14 transmits the read list file containing the URIs of the second segments to the client 16.
Dans une étape 415, suite à une réception, lors d'une étape 413, d'une requête HTTP contenant une adresse URI d'un second segment en provenance du client 16, le serveur 14 transmet au client 16 le second segment correspondant à ladite adresse URI. L'adresse URI dudit second segment a été obtenue par le client 16 à partir du fichier liste de lecture transmis par le serveur 14. Si, lors de l'étape 413, aucune requête HTTP pour un nouveau segment n'est reçue pendant une durée prédéfinie ou que le dernier segment transmis est un segment final du second flux de données, le serveur 14 met fin à la diffusion du second flux de données au cours d'une étape 414. In a step 415, following a reception, during a step 413, of an HTTP request containing a URI of a second segment from the client 16, the server 14 transmits to the client 16 the second segment corresponding to said URI address. The URI address of said second segment was obtained by the client 16 from the playlist file transmitted by the server 14. If, in step 413, no HTTP request for a new segment is received for a predefined duration or the last transmitted segment is an end segment of the second data stream, the server 14 terminates the broadcast of the second data stream. data flow during a step 414.
La Fig. 4C illustre schématiquement un exemple d'une mise en œuvre par un client du procédé de diffusion en direct d'un flux de données permettant une adaptation fine du flux de données aux capacités du client.  Fig. 4C schematically illustrates an example of a implementation by a client of the streaming method of a data stream allowing a fine adaptation of the data flow to the capabilities of the client.
Dans une étape 420, le client 16 transmet au serveur 14 une information représentative de ses capacités.  In a step 420, the client 16 transmits to the server 14 information representative of its capabilities.
Dans une étape 421, à un moment choisi, par exemple, par un utilisateur du client 16, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI du fichier liste de lecture contenant les adresses URI des seconds segments. En retour, le client 16 reçoit de la part du serveur 14, ledit fichier liste de lecture lors d'une étape 422.  In a step 421, at a time chosen, for example, by a user of the client 16, the client 16 transmits an HTTP request to the server 14 containing the URI address of the playlist file containing the URIs of the second segments. In return, the client 16 receives from the server 14, said read list file during a step 422.
Dans une étape 423, le client 16 recherche dans le fichier liste de lecture un second segment à demander au serveur 14. Lorsque le client 16 demande pour la première fois un second segment, le client 16 sélectionne en général le second segment ayant le numéro de séquence le plus faible dans le fichier liste de lecture qu'il a reçu.  In a step 423, the client 16 searches the playlist file for a second segment to request from the server 14. When the client 16 requests for the first time a second segment, the client 16 generally selects the second segment having the number of the second segment. lowest sequence in the playlist file it received.
Dans une étape 424, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI dudit second segment sélectionné.  In a step 424, the client 16 transmits an HTTP request to the server 14 containing the URI address of said second selected segment.
Dans une étape 425, le client 16 reçoit ledit second segment et fournit ce second segment à un module de décodage prenant en charge un décodage du second segment.  In a step 425, the client 16 receives said second segment and provides this second segment to a decoding module supporting a decoding of the second segment.
Dans une étape 426, le client 16 vérifie si la diffusion du flux de données initial qu'il a sélectionné doit être poursuivie. Si la diffusion doit être poursuivie, le client 16 met de nouveau en œuvre l'étape 423 et demande le second segment suivant le segment précédemment demandé, i.e. le second segment ayant un numéro de séquence incrémenté d'une unité par rapport au numéro de séquence du second segment précédemment demandé. Si la diffusion ne doit pas être poursuivie, le client 16 y met fin lors d'une étape 427.  In a step 426, the client 16 checks whether the broadcast of the initial data stream that it has selected must be continued. If the broadcast is to be continued, the client 16 again implements step 423 and requests the second segment following the previously requested segment, ie the second segment having a sequence number incremented by one relative to the sequence number of the second segment previously requested. If the broadcast is not to be continued, the client 16 terminates it during a step 427.
Dans un mode de réalisation, le client 16 peut ouvrir une connexion HTTP avec le serveur 14 pour transmettre ses capacités. Cette connexion peut être fermée par le serveur dès réception des capacités du client 16. Dans un mode de réalisation, le procédé décrit en relation avec la Fig. 4C pourrait être mis en œuvre par un second client non représenté dans la Fig. 1. Dans ce cas le client 16 serait compatible avec le protocole HLS alors que le second client serait compatible avec le protocole HLS et le procédé décrit en relation avec les Figs. 4A, 4B et 4C. In one embodiment, the client 16 can open an HTTP connection with the server 14 to transmit its capabilities. This connection can be closed by the server upon receipt of the capabilities of the client 16. In one embodiment, the method described in connection with FIG. 4C could be implemented by a second client not shown in FIG. 1. In this case the client 16 would be compatible with the HLS protocol while the second client would be compatible with the HLS protocol and the method described in relation to FIGS. 4A, 4B and 4C.
Dans un mode de réalisation, lors de l'étape 402, le serveur 14 génère aussi des premiers flux de données tels que décrits en relation avec l'étape 302. Lors de l'étape 403, le serveur 14 génère aussi des premiers segments tels que décrits en relation avec l'étape 303. Lors de l'étape 404, le serveur 14 génère aussi un fichier liste de lecture pour chaque premier flux de données tel que décrit en relation avec l'étape 304. Les adresses URI des fichiers liste de lecture correspondant aux premiers flux de données et au second flux de données sont insérées dans un fichier liste de lecture maître. Lors de l'étape 405, l'adresse URI du fichier liste de lecture maître est transmise au client 16. Dans ce mode de réalisation, le client 16 peut choisir parmi les premiers flux de données et le second flux de données, le flux de données le plus approprié à ses capacités à un instant donné. Dans ce mode de réalisation, un autre client que le client 16 pourrait aussi recevoir le fichier liste de lecture maître et choisir parmi les premiers flux de données et le second flux de données, le flux de données le plus approprié à ses capacités. Ainsi, un client qui n'implémenterait pas le procédé décrit en relation avec la Fig. 4C, mais uniquement le protocole HLS, pourrait recevoir le second flux de données si ses capacités sont plus proches de celles du client 16 que de celles des types de clients de l'ensemble de types de clients prédéfini.  In one embodiment, during step 402, the server 14 also generates first data streams as described in relation with step 302. In step 403, the server 14 also generates first segments such as described in connection with step 303. In step 404, the server 14 also generates a read list file for each first data stream as described in connection with step 304. The URI addresses of the list files corresponding to the first data stream and the second data stream are inserted in a master playlist file. In step 405, the URI address of the master playlist file is transmitted to the client 16. In this embodiment, the client 16 can choose from the first data stream and the second data stream, the flow of the master file. data most appropriate to its capabilities at a given moment. In this embodiment, another client than the client 16 could also receive the master list file and choose from among the first data streams and the second data stream, the data flow most appropriate to its capabilities. Thus, a customer who would not implement the method described in connection with FIG. 4C, but only the HLS protocol, could receive the second data stream if its capabilities are closer to those of the client 16 than to those of the client types of the predefined set of client types.
Dans un mode de réalisation, le client 16 peut envoyer au serveur 14 de nouvelles informations représentatives de ses capacités à intervalles réguliers ou lorsque ses capacités ont évolué de manière significative par rapport aux dernières capacités envoyées. L'envoi de nouvelles informations représentatives des capacités du client 16 provoque une nouvelle adaptation du flux de données initial par le serveur 14 pour générer un nouveau second flux de données adapté aux nouvelles capacités.  In one embodiment, the client 16 may send the server 14 new information representative of its capabilities at regular intervals or when its capabilities have evolved significantly compared to the latest capabilities sent. The sending of new information representative of the capabilities of the client 16 causes a new adaptation of the initial data stream by the server 14 to generate a new second data stream adapted to the new capabilities.
La Fig. 2 A illustre schématiquement un exemple d'architecture matérielle d'un dispositif client mettant en œuvre le protocole HLS et/ou le procédé décrit en relation avec la Fig. 4C. Nous prenons ici l'exemple du client 16. Le client 16 comprend alors, reliés par un bus de communication 165 : un processeur ou CPU (« Central Processing Unit » en anglais) 160 ; une mémoire vive RAM (« Random Access Memory » en anglais) 161 ; une mémoire morte ROM (« Read Only Memory » en anglais) 162 ; une unité de stockage ou un lecteur de support de stockage, tel qu'un lecteur de cartes SD (« Secure Digital » en anglais) 163 ; un ensemble 164 d'interfaces de connexion permettant de connecter le client 16 au serveur 14. Fig. 2A illustrates schematically an example of a hardware architecture of a client device implementing the HLS protocol and / or the method described in relation to FIG. 4C. We take here the example of the client 16. The client 16 then comprises, connected by a communication bus 165: a processor or CPU ("Central Processing Unit" in English) 160; random access memory RAM ("Random Access Memory") 161; a ROM (Read Only Memory) 162; a a storage unit or a storage medium reader, such as an SD card reader ("Secure Digital") 163; a set 164 of connection interfaces for connecting the client 16 to the server 14.
Le processeur 160 est capable d'exécuter des instructions chargées dans la RAM 161 à partir de la ROM 162, d'une mémoire externe (non représentée), d'un support de stockage, tel qu'une carte SD, ou d'un réseau de communication. Lorsque le client 16 est mis sous tension, le processeur 160 est capable de lire de la RAM 161 des instructions et de les exécuter. Ces instructions forment un programme d'ordinateur causant la mise en œuvre, par le processeur 160, de tout ou partie des procédés décrits en relation avec les Figs. 3C et 4C.  The processor 160 is capable of executing instructions loaded into the RAM 161 from the ROM 162, an external memory (not shown), a storage medium, such as an SD card, or a memory card. communication network. When client 16 is turned on, processor 160 is able to read instructions from RAM 161 and execute them. These instructions form a computer program causing the processor 160 to implement all or some of the methods described in relation to FIGS. 3C and 4C.
La Fig. 2B illustre schématiquement un exemple d'architecture matérielle d'un dispositif serveur mettant en œuvre l'invention. Nous prenons ici l'exemple du serveur 14. Le serveur 14 comprend alors, reliés par un bus de communication 145 : un processeur ou CPU (« Central Processing Unit » en anglais) 140 ; une mémoire vive RAM (« Random Access Memory » en anglais) 141 ; une mémoire morte ROM (« Read Only Memory » en anglais) 142 ; une unité de stockage ou un lecteur de support de stockage, tel qu'un lecteur de cartes SD (« Secure Digital » en anglais) 143 ; un ensemble 144 d'interfaces de connexion permettant de connecter le serveur 14 au client 16 et à la passerelle réseau 12.  Fig. 2B schematically illustrates an example of a hardware architecture of a server device embodying the invention. We take here the example of the server 14. The server 14 then comprises, connected by a communication bus 145: a processor or CPU ("Central Processing Unit" in English) 140; random access memory RAM ("Random Access Memory") 141; ROM (Read Only Memory) 142; a storage unit or a storage medium reader, such as a SD card reader ("Secure Digital") 143; a set 144 of connection interfaces for connecting the server 14 to the client 16 and to the network gateway 12.
Le processeur 140 est capable d'exécuter des instructions chargées dans la RAM The processor 140 is capable of executing loaded instructions in the RAM
141 à partir de la ROM 142, d'une mémoire externe (non représentée), d'un support de stockage, tel qu'une carte SD, ou d'un réseau de communication. Lorsque le serveur 14 est mis sous tension, le processeur 140 est capable de lire de la RAM 141 des instructions et de les exécuter. Ces instructions forment un programme d'ordinateur causant la mise en œuvre, par le processeur 140, de tout ou partie des procédés décrits en relation avec les Figs. 3A, 3B, 4A et 4B. 141 from the ROM 142, an external memory (not shown), a storage medium, such as an SD card, or a communication network. When the server 14 is powered up, the processor 140 is able to read instructions from RAM 141 and execute them. These instructions form a computer program causing the processor 140 to implement all or some of the methods described in relation to FIGS. 3A, 3B, 4A and 4B.
Tout ou partie de l'algorithme décrit en relation avec les Figs. 3A, 3B, 3C, 4A, 4B et 4C peut être implémenté sous forme logicielle par exécution d'un ensemble d'instructions par une machine programmable, telle qu'un DSP (« Digital Signal Processor » en anglais) ou un microcontrôleur, ou être implémenté sous forme matérielle par une machine ou un composant dédié, tel qu'un FPGA (« Field- Programmable Gâte Array » en anglais) ou un ASIC (« Application-Specifîc Integrated Circuit » en anglais). RECEIVED BLANK UPON FILING All or part of the algorithm described in relation to FIGS. 3A, 3B, 3C, 4A, 4B and 4C can be implemented in software form by executing a set of instructions by a programmable machine, such as a DSP ("Digital Signal Processor" in English) or a microcontroller, or be implemented in hardware form by a machine or a dedicated component, such as an FPGA ("Field Programmable Gate Array" in English) or an ASIC ("Application-Specific Integrated Circuit"). RECEIVED BLANK UPON FILING

Claims

REVENDICATIONS
1) Procédé de transmission d'un flux de données entre un client et un serveur utilisant un protocole de diffusion en direct, le procédé étant caractérisé en ce qu'il comprend les étapes suivantes mises en œuvre par le serveur : 1) A method of transmitting a data stream between a client and a server using a live broadcast protocol, the method being characterized in that it comprises the following steps implemented by the server:
obtenir (30) un flux de données initial ;  obtain (30) an initial data stream;
recevoir (31) une demande d'informations descriptives pour le flux de données initial de la part dudit client ;  receiving (31) a request for descriptive information for the initial data flow from said client;
vérifier (32) qu'au moins une information représentative d'une capacité dudit client a été reçue en provenance dudit client ;  verify (32) that at least one piece of information representing a capacity of said client has been received from said client;
si aucune information représentative d'une capacité dudit client n'a été reçue : adapter (302) le flux de données initial pour obtenir une pluralité de premiers flux de données, chaque premier flux de données étant adapté à des capacités respectives d'un type de client appartenant à un ensemble de types de client prédéfinis ;  if no information representative of a capacity of said client has been received: adapting (302) the initial data stream to obtain a plurality of first data streams, each first data stream being adapted to respective capacities of a type client belonging to a set of predefined client types;
décomposer (303) en segments, dits premier segments, chaque premier flux de données ; et,  decomposing (303) into segments, referred to as first segments, each first data stream; and,
transmettre (304, 305) audit client une première information descriptive permettant au client de demander (324) une transmission de premiers segments d'au moins un premier flux de données;  transmitting (304, 305) to said client a first descriptive information enabling the client to request (324) a transmission of first segments of at least a first data stream;
et si au moins une information représentative d'une capacité dudit client a été reçue :  and if at least one piece of information representing a capacity of said client has been received:
adapter (402) ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ;  adapting (402) said initial data stream to each received capacity to obtain a second data stream;
décomposer (403) en segments, dits seconds segments, le second flux de données ; et,  decomposing (403) into segments, called second segments, the second data stream; and,
transmettre (404, 405) au client une seconde information descriptive permettant au client de demander (424) une transmission de seconds segments du second flux de données.  transmitting (404, 405) to the client a second descriptive information enabling the client to request (424) a transmission of second segments of the second data stream.
2) Procédé selon la revendication 1, caractérisé en ce que le protocole de diffusion en direct est le protocole de diffusion en direct basé sur HTTP. 3) Procédé selon la revendication 2, caractérisé en ce que la seconde information descriptive est mise sous forme d'un fichier liste de lecture compatible avec le protocole de diffusion en direct (404). 4) Procédé selon la revendication 3, caractérisé en ce que la transmission de la seconde information descriptive comprend une transmission (405) au client d'une adresse de chargement du fichier liste de lecture compatible avec le protocole de diffusion en direct. 5) Procédé selon la revendication 4, caractérisé en ce que le serveur transmet2) Method according to claim 1, characterized in that the live broadcast protocol is the HTTP-based live broadcast protocol. 3) Method according to claim 2, characterized in that the second descriptive information is in the form of a playlist file compatible with the live broadcast protocol (404). 4) Method according to claim 3, characterized in that the transmission of the second descriptive information comprises a transmission (405) to the client of a loading address of the playlist file compatible with the live broadcast protocol. 5) Method according to claim 4, characterized in that the server transmits
(412) le fichier liste de lecture compatible avec le protocole de diffusion en direct au client, suite à une réception (411), en provenance du client, d'une requête HTTP contenant ladite adresse de chargement. (412) the playlist file compatible with the live broadcast protocol to the client, following receipt (411) from the client of an HTTP request containing said loading address.
6) Procédé selon la revendication 5, caractérisé en ce que le serveur transmet (415) un second segment suite à une réception (413), en provenance du client, d'une requête HTTP contenant une adresse de chargement correspondant audit second segment, ladite adresse de chargement ayant été obtenue à partir du fichier texte compatible avec le protocole de diffusion en direct. 6) Method according to claim 5, characterized in that the server transmits (415) a second segment following a reception (413), from the client, an HTTP request containing a loading address corresponding to said second segment, said loading address having been obtained from the text file compatible with the live broadcast protocol.
7) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les capacités du client comprennent un format de compression vidéo supporté et/ou un format de compression audio supporté et/ou un format de compression d'image supporté et/ou un format de sous-titres supporté et/ou un type de réseau utilisé et/ou un débit de réception et/ou une résolution maximum d'image supporté et/ou un nombre de canaux audio supporté. A method as claimed in any one of the preceding claims, characterized in that the client capabilities include a supported video compression format and / or a supported audio compression format and / or a supported image compression format and / or a supported subtitle format and / or a type of network used and / or a reception rate and / or a maximum supported image resolution and / or a supported number of audio channels.
8) Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, lorsque ledit flux de données initial comprend un flux vidéo encodé dans un premier format de compression de vidéo, une adaptation dudit flux de données initial comprend un transcodage permettant de réduire un débit dudit flux vidéo et/ou une résolution d'images dudit flux vidéo et/ou une fréquence d'image dudit flux vidéo et/ou une transformation dudit flux vidéo afin d'assurer une compatibilité avec un second format de compression vidéo, et lorsque ledit flux de données initial comprend un flux audio encodé dans un premier format de compression audio, une adaptation dudit flux de données initial comprend un transcodage permettant de réduire un débit dudit flux audio et/ou un nombre de canaux audio et/ou une transformation dudit flux audio afin d'assurer une compatibilité avec un second format de compression audio. 8) Method according to any one of the preceding claims, characterized in that, when said initial data stream comprises a video stream encoded in a first video compression format, an adaptation of said initial data stream comprises a transcoding to reduce a bit rate of said video stream and / or an image resolution of said video stream and / or an image rate of said video stream and / or a transformation of said video stream to ensure compatibility with a second video compression format, and when said initial data stream comprises an audio stream encoded in a first audio compression format, an adaptation of said initial data stream comprises transcoding to reduce a bit rate of said audio stream and / or a number of audio channels and / or a transformation of said audio stream to ensure compatibility with a second audio compression format.
9) Dispositif de type serveur apte à transmettre un flux de données en utilisant un protocole de diffusion en direct, comprenant les moyens suivants : 9) A server type device capable of transmitting a data stream using a live broadcast protocol, comprising the following means:
des moyens d'obtention (30) pour obtenir un flux de données initial ;  obtaining means (30) for obtaining an initial data stream;
des moyens de réception (31) pour recevoir une demande d'information descriptive pour le flux de données initial de la part d'un client ;  receiving means (31) for receiving a descriptive information request for the initial data stream from a client;
des moyens de vérification (32) pour vérifier qu'au moins une information représentative d'une capacité dudit client a été reçue ;  verification means (32) for verifying that at least one piece of information representing a capacity of said client has been received;
des moyens (33) mis en œuvre lorsqu'aucune information représentative d'une capacité dudit client a été reçue comprenant :  means (33) implemented when no information representative of a capacity of said client has been received comprising:
des moyens d'adaptation (302) pour adapter le flux de données initial pour obtenir une pluralité de premiers flux de données, chaque premier flux de données étant adapté à des capacités respectives d'un type de client appartenant à un ensemble de types de clients prédéfinis ;  adaptation means (302) for adapting the initial data stream to obtain a plurality of first data streams, each first data stream being adapted to respective capabilities of a type of client belonging to a set of client types predefined;
des moyens de décomposition (303) pour décomposer en segments, dits premiers segments, chaque premier flux de données ; et,  decomposition means (303) for breaking into segments, called first segments, each first data stream; and,
des moyens de transmission (304, 305) pour transmettre à un client une première information descriptive permettant au client de demander (324) une transmission des premiers segments d'au moins un premier flux de données;  transmission means (304, 305) for transmitting to a client a first descriptive information enabling the client to request (324) a transmission of the first segments of at least a first data stream;
des moyens (34) mis en œuvre lorsqu'au moins une information représentative d'une capacité dudit client a été reçue comprenant :  means (34) implemented when at least one piece of information representing a capacity of said client has been received comprising:
des moyens d'adaptation (402) pour adapter ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ;  adaptation means (402) for adapting said initial data stream to each received capacity to obtain a second data stream;
des moyens de décomposition (403) pour décomposer en segments, dits seconds segments, le second flux de données ; et,  decomposition means (403) for splitting into segments, said second segments, the second data stream; and,
des moyens de transmission (404, 405) pour transmettre au client une seconde information descriptive permettant au client de demander (424) une transmission de seconds segments du second flux de données. 10) Dispositif de type client apte à recevoir un flux de données en utilisant le protocole de diffusion en direct basé sur HTTP, comprenant les moyens suivants : des moyens de transmission pour transmettre au moins une information représentative d'une capacité dudit dispositif de type client à un serveur ; transmission means (404, 405) for transmitting to the client a second descriptive information enabling the client to request (424) a transmission of second segments of the second data stream. 10) Client type device adapted to receive a data stream using the HTTP-based live broadcast protocol, comprising the following means: transmission means for transmitting at least one piece of information representative of a capacity of said client type device to a server;
des moyens pour recevoir un fichier texte compatible avec le protocole de diffusion en direct basé sur HTTP, le fichier texte correspondant à un fichier de données initial et permettant d'obtenir des adresses de chargement de segments correspondant à un flux de données, dit second flux de données, résultant d'une adaptation par le serveur du flux de données initial à chaque capacité dudit dispositif de type client ;  means for receiving a text file compatible with the HTTP-based live broadcast protocol, the text file corresponding to an initial data file and making it possible to obtain segment loading addresses corresponding to a data stream, said second stream data, resulting from an adaptation by the server of the initial data stream to each capacity of said client type device;
des moyens de transmission pour transmettre une requête contenant une adresse de chargement d'un segment du second flux de données, l'adresse de chargement ayant été obtenue à partir du fichier texte compatible avec le protocole de diffusion en direct basé sur HTTP ; et,  transmission means for transmitting a request containing a loading address of a segment of the second data stream, the loading address having been obtained from the text file compatible with the HTTP-based live broadcast protocol; and,
des moyens de réception pour recevoir le segment correspondant à la requête transmise.  receiving means for receiving the segment corresponding to the transmitted request.
11) Système de transmission d'un flux de données comprenant un serveur selon la revendication 9 et au moins un client selon la revendication 10. 11) System for transmitting a data stream comprising a server according to claim 9 and at least one client according to claim 10.
12) Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions pour mettre en œuvre, par un dispositif, le procédé selon l'une quelconque des revendications 1 à 8, lorsque ledit programme est exécuté par un processeur du dispositif. 12) computer program, characterized in that it comprises instructions for implementing, by a device, the method according to any one of claims 1 to 8, when said program is executed by a processor of the device.
13) Moyens de stockage, caractérisés en ce qu'ils stockent un programme d'ordinateur comprenant des instructions pour mettre en œuvre, par un dispositif, le procédé selon l'une quelconque des revendications 1 à 8, lorsque ledit programme est exécuté par un processeur dudit dispositif. 13) Storage means, characterized in that they store a computer program comprising instructions for implementing, by a device, the method according to any one of claims 1 to 8, when said program is executed by a processor of said device.
EP16700626.1A 2015-01-16 2016-01-14 Method for transmitting a data flow using a direct broadcasting protocol Withdrawn EP3245794A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1550342A FR3031862B1 (en) 2015-01-16 2015-01-16 METHOD FOR TRANSMITTING A DATA STREAM USING DIRECT DIFFUSION PROTOCOL
PCT/EP2016/050697 WO2016113364A1 (en) 2015-01-16 2016-01-14 Method for transmitting a data flow using a direct broadcasting protocol

Publications (1)

Publication Number Publication Date
EP3245794A1 true EP3245794A1 (en) 2017-11-22

Family

ID=53269627

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16700626.1A Withdrawn EP3245794A1 (en) 2015-01-16 2016-01-14 Method for transmitting a data flow using a direct broadcasting protocol

Country Status (6)

Country Link
US (1) US20180198834A1 (en)
EP (1) EP3245794A1 (en)
CN (1) CN107211166A (en)
BR (1) BR112017014537A2 (en)
FR (1) FR3031862B1 (en)
WO (1) WO2016113364A1 (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11102259B2 (en) * 2019-01-22 2021-08-24 Apple Inc. Network system for content playback on multiple devices
CN111917511B (en) * 2020-07-06 2024-01-30 青岛海尔科技有限公司 Data receiving method
CN117097813B (en) * 2023-10-19 2024-01-26 广州宇中网络科技有限公司 Protocol adaptation method, device, equipment and storage medium

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070250308A1 (en) * 2004-08-31 2007-10-25 Koninklijke Philips Electronics, N.V. Method and device for transcoding
US8947492B2 (en) * 2010-06-18 2015-02-03 Microsoft Corporation Combining multiple bit rate and scalable video coding
US10298897B2 (en) * 2010-12-30 2019-05-21 Interdigital Madison Patent Holdings Method of processing a video content allowing the adaptation to several types of display devices
CN102111685B (en) * 2011-02-24 2012-07-25 深信服网络科技（深圳）有限公司 Acceleration method, equipment and system for network video loading
WO2013004260A1 (en) * 2011-07-07 2013-01-10 Telefonaktiebolaget L M Ericsson (Publ) Network-capacity optimized adaptive http streaming
EP2566172A1 (en) * 2011-09-02 2013-03-06 Thomson Licensing Method and apparatus for adaptive transcoding of multimedia stream
US8762452B2 (en) * 2011-12-19 2014-06-24 Ericsson Television Inc. Virtualization in adaptive stream creation and delivery
WO2013098317A1 (en) * 2011-12-29 2013-07-04 Koninklijke Kpn N.V. Network-initiated content streaming control
US9584573B2 (en) * 2012-08-29 2017-02-28 Ericsson Ab Streaming policy management system and method
WO2014058431A1 (en) * 2012-10-11 2014-04-17 Affirmed Networks, Inc. Expansion of a stream set and transcoding of http adaptive streaming videos in a mobile network
CN102932670B (en) * 2012-11-29 2015-09-02 百视通网络电视技术发展有限责任公司 A kind of Streaming Media dicing method and system
EP2744215A1 (en) * 2012-12-17 2014-06-18 Thomson Licensing Method for streaming AV content and method for presenting AV content
US9973559B2 (en) * 2013-05-29 2018-05-15 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for presenting content streams to a client device
US9544665B2 (en) * 2013-05-31 2017-01-10 Broadcom Corporation Providing multiple ABR streams using a single transcoder
US9392307B2 (en) * 2013-07-01 2016-07-12 Ericsson Ab Smart pre-load for video-on-demand in an HTTP adaptive streaming environment
FR3029381A1 (en) * 2014-11-27 2016-06-03 Orange METHOD FOR COMPOSING AN INTERMEDIATE VIDEO REPRESENTATION

Also Published As

Publication number Publication date
FR3031862B1 (en) 2017-02-17
WO2016113364A1 (en) 2016-07-21
FR3031862A1 (en) 2016-07-22
BR112017014537A2 (en) 2018-01-16
US20180198834A1 (en) 2018-07-12
CN107211166A (en) 2017-09-26

Similar Documents

Publication Publication Date Title
FR2902568A1 (en) METHOD FOR DISPLAYING A MOSAIC IMAGE WITHIN A RECEIVER FOR SELECTING AUDIOVISUAL PROGRAMS, RECEIVERS AND ASSOCIATED SERVERS
FR2902266A1 (en) METHOD AND DEVICE FOR DISTRIBUTING THE COMMUNICATION BANDWIDTH
FR2864407A1 (en) Video transmitting method for e.g. Internet, involves processing requests from client machines, to determine intersections defining common data between spatial zones of interest, and creating multipoint network session for each intersection
EP3127336A1 (en) Device and method for remotely controlling the rendering of multimedia content
EP3072303B1 (en) Adaptive broadcasting of multimedia content
EP2947888B1 (en) Adaptive method for downloading digital content for a plurality of screens
EP3245794A1 (en) Method for transmitting a data flow using a direct broadcasting protocol
FR3029381A1 (en) METHOD FOR COMPOSING AN INTERMEDIATE VIDEO REPRESENTATION
EP2767060B1 (en) Gateway, and method, computer program and storage means corresponding thereto
EP3461135A1 (en) Method for managing the access right to a digital content
WO2019220034A1 (en) Management of adaptive progressive download of a digital content within a restoration terminal of a local communication network
EP4035408A1 (en) Management of adaptive streaming of an item of digital content over a mobile network with selection of a maximum authorized encoding rate on the basis of a data bucket
EP3987820A1 (en) Method for managing adaptive progressive downloading (has) of digital content which is broadcast in real time, corresponding administrator, multimedia stream player terminal and computer program
FR2923970A1 (en) METHOD AND DEVICE FOR FORMING, TRANSFERING AND RECEIVING TRANSPORT PACKETS ENCAPSULATING DATA REPRESENTATIVE OF A SEQUENCE OF IMAGES
WO2014155017A1 (en) Transcoding and adaptive broadcasting of multimedia contents
EP3481069B1 (en) Method and system for processing multimedia content in a metropolitan area network
FR3054765B1 (en) METHOD FOR READING EQUIPMENT OF MULTIMEDIA CONTENT WITH TARGET DELAY IN RELATION TO DIRECT LESS THAN MAXIMUM DELAY GIVES
EP2282475B1 (en) Method and device for restoring multimedia content
FR3096210A1 (en) A method of transmitting digital content having several versions accessible from a content server to a playback terminal.
FR3114719A1 (en) Method for managing the reading of digital content within a multimedia content player terminal connected to a rendering device
FR3124344A1 (en) Method for managing access to content downloaded in adaptive download mode.
FR3138020A1 (en) Enhanced Hybrid Adaptive Video Streaming
EP2879352A1 (en) Control of multimedia content broadcasts
EP3866432A1 (en) Adaptable data stream transmission
EP2957104A1 (en) Method for selecting the representation of the segments of a multimedia content transmitted over a communication network

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20170802

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

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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: 20180424

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

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: 20210803