EP3245794A1 - Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct - Google Patents

Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct

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)
English (en)
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/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • 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
    • 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
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements 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 or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Graphics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Procédé de transmission d'un flux de données entre un serveur et un client utilisant le protocole de diffusion en direct basé sur HTTP comprenant les étapes suivantes, mises en œuvre par le serveur, suite à une réception d'au moins une information représentative d'une capacité dudit client : adapter (402) un flux de données initial à chaque capacité reçue afin d'obtenir un flux de données adapté; décomposer (403) en segments le flux de données adapté; transmettre (404, 405) au client une information descriptive permettant d'obtenir, pour chaque segment, une adresse de chargement dudit segment, ladite information descriptive permettant au client de demander au serveur une transmission des segments afin d'obtenir le flux de données adapté.

Description

Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct.
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é.
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.
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.
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.
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.
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é.
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.
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.
Il est souhaitable de pallier ces inconvénients de l'état de la technique.
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.
Il est de plus souhaitable de fournir une solution qui soit simple à mettre en œuvre et à faible coût.
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.
De cette manière, le second client reçoit un second flux de données adapté finement à ses capacités.
Dans un mode de réalisation, le protocole de diffusion en direct est le protocole de diffusion en direct basé sur HTTP.
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.
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.
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.
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.
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.
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.
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é.
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.
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.
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.
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.
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.
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.
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 :
- 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 ;
- la Fig. 2B illustre schématiquement un exemple d'architecture matérielle d'un dispositif serveur mettant en œuvre l'invention ;
- La Fig. 3A illustre schématiquement un exemple de mise en œuvre d'un procédé selon l'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 ;
- la Fig. 3D illustre schématiquement un exemple de mise en œuvre d'un procédé de type protocole HLS par un 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,
- 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.
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.
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).
La passerelle réseau 12 reçoit des flux de données encapsulés dans des paquets
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.
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.
La Fig. 3A illustre schématiquement un exemple de mise en œuvre d'un procédé selon l'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.
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.
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.
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.
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.
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é.
Les Figs. 3B et 3C illustrent schématiquement un exemple de mise en œuvre du protocole HLS par le serveur 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 :
- 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),
- 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),
- un format de compression d'images supporté. Un client peut par exemple supporter un ou plusieurs des formats de compression d'image suivants :
JPEG (ISO/CEI 10918-1/UIT-T Recommandation T.81), JPEG2000 (ISO/CEI 15444-1),
si le client possède des moyens de décodage de sous-titres,
- un type de réseau utilisé par le client : Ethernet, Wi-Fi, CPL,
- un débit de réception,
une résolution maximum d'images supportée par le client,
- un nombre de canaux audio supporté par le 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.
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.
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.
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.
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é.
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.
La Fig. 3D illustre schématiquement un exemple de mise en œuvre du protocole
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.
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.
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é.
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.
Dans une étape 324, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI dudit premier segment sélectionné.
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.
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.
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.
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.
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.
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.
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.
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.
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éé.
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.
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.
Dans une étape 412, le serveur 14 transmet le fichier liste de lecture contenant les adresse URI des seconds segments au 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.
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.
Dans une étape 420, le client 16 transmet au serveur 14 une information représentative de ses capacités.
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.
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.
Dans une étape 424, le client 16 transmet une requête HTTP au serveur 14 contenant l'adresse URI dudit second segment sélectionné.
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.
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.
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.
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.
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.
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.
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.
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.
Le processeur 140 est capable d'exécuter des instructions chargées dans la 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.
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

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 :
obtenir (30) un flux de données initial ;
recevoir (31) une demande d'informations descriptives pour le flux de données initial de la part dudit client ;
vérifier (32) 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 (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 ;
décomposer (303) en segments, dits premier segments, chaque premier flux de données ; et,
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;
et si au moins une information représentative d'une capacité dudit client a été reçue :
adapter (402) ledit flux de données initial à chaque capacité reçue afin d'obtenir un second flux de données ;
décomposer (403) en segments, dits seconds segments, le second flux de données ; et,
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.
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 transmet
(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.
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.
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é.
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.
9) 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 (30) pour obtenir un flux de données initial ;
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 ;
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 ;
des moyens (33) mis en œuvre lorsqu'aucune information représentative d'une capacité dudit client a été reçue comprenant :
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 ;
des moyens de décomposition (303) pour décomposer en segments, dits premiers segments, chaque premier flux de données ; et,
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;
des moyens (34) mis en œuvre lorsqu'au moins une information représentative d'une capacité dudit client a été reçue comprenant :
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 ;
des moyens de décomposition (403) pour décomposer en segments, dits seconds segments, le second flux de données ; et,
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 ;
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 ; et,
des moyens de réception pour recevoir le segment correspondant à la requête transmise.
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.
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.
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.
EP16700626.1A 2015-01-16 2016-01-14 Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct Withdrawn EP3245794A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1550342A FR3031862B1 (fr) 2015-01-16 2015-01-16 Procede de transmission d'un flux de donnees utilisant un protocole de diffusion en direct.
PCT/EP2016/050697 WO2016113364A1 (fr) 2015-01-16 2016-01-14 Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct

Publications (1)

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

Family

ID=53269627

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16700626.1A Withdrawn EP3245794A1 (fr) 2015-01-16 2016-01-14 Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct

Country Status (6)

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

Families Citing this family (4)

* 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 (zh) * 2020-07-06 2024-01-30 青岛海尔科技有限公司 一种数据的接收方法
CN115334059B (zh) * 2022-08-10 2025-06-06 北京飞讯数码科技有限公司 一种音视频互通方法、装置、设备及存储介质
CN117097813B (zh) * 2023-10-19 2024-01-26 广州宇中网络科技有限公司 协议适配方法、装置、设备及存储介质

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 (zh) * 2011-02-24 2012-07-25 深信服网络科技（深圳）有限公司 一种网络视频加载的加速方法、设备及系统
CN103650451B (zh) * 2011-07-07 2016-10-19 瑞典爱立信有限公司 网络容量优化的自适应http流播
EP2566172A1 (fr) * 2011-09-02 2013-03-06 Thomson Licensing Procédé et appareil pour le transcodage adaptatif d'un flux multimédia
US8762452B2 (en) * 2011-12-19 2014-06-24 Ericsson Television Inc. Virtualization in adaptive stream creation and delivery
WO2013098317A1 (fr) * 2011-12-29 2013-07-04 Koninklijke Kpn N.V. Contrôle de diffusion en flux de contenu initié par le réseau
US9584573B2 (en) * 2012-08-29 2017-02-28 Ericsson Ab Streaming policy management system and method
WO2014058431A1 (fr) * 2012-10-11 2014-04-17 Affirmed Networks, Inc. Extension d'un jeu de flux de données et transcodage de vidéos sur internet s'adaptant au protocole http dans un réseau mobile
CN102932670B (zh) * 2012-11-29 2015-09-02 百视通网络电视技术发展有限责任公司 一种流媒体切片方法及系统
EP2744215A1 (fr) * 2012-12-17 2014-06-18 Thomson Licensing Procédé de transmission en continu de contenu AV et procédé de présentation de contenu AV
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 (fr) * 2014-11-27 2016-06-03 Orange Procede de composition d’une representation video intermediaire

Also Published As

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

Similar Documents

Publication Publication Date Title
FR2864407A1 (fr) Procede et dispositif de transmission continue d'une video dans un reseau de communication
EP3072303B1 (fr) Diffusion adaptative de contenus multimedia
EP2947888B1 (fr) Procédé de téléchargement adaptatif de contenus numériques pour plusieurs écrans
EP3245794A1 (fr) Procédé de transmission d'un flux de données utilisant un protocole de diffusion en direct
FR2902266A1 (fr) Procede et dispositif de repartition de la bande passante de communication
EP2767060B1 (fr) Passerelle, et procédé, programme d'ordinateur et moyens de stockage correspondants
EP3461135A1 (fr) Procédé de gestion du droit d'accès à un contenu numérique
WO2020259911A1 (fr) Procédé de gestion du téléchargement progressif adaptatif (has) d'un contenu numérique diffusé en temps réel, gestionnaire, terminal lecteur de flux multimédia et programme d'ordinateur correspondants
FR3081274A1 (fr) Gestion du telechargement progressif adaptatif d'un contenu numerique au sein d'un terminal de restitution d'un reseau de communication local.
FR3054765B1 (fr) Procede pour la lecture sur un equipement d'un contenu multimedia avec un retard cible par rapport au direct inferieur a un retard maximal donne
FR2923970A1 (fr) Procede et dispositif de formation, de transfert et de reception de paquets de transport encapsulant des donnees representatives d'une sequence d'images
WO2021058910A1 (fr) Gestion du téléchargement progressif adaptatif d'un contenu numérique sur réseau mobile avec sélection d'un débit d'encodage maximum autorisé en fonction d'un godet de données
WO2014155017A1 (fr) Transcodage et diffusion adaptative de contenus multimédia
EP3675505B1 (fr) Procede et systeme de distribution d'un contenu audiovisuel
EP4734527A1 (fr) Procédé de gestion de l accès, par un dispositif de lecture, à des contenus segmentés
FR3096210A1 (fr) Procédé de transmission d’un contenu numérique ayant plusieurs versions accessibles depuis un serveur de contenus à destination d’un terminal de restitution.
EP4564823A1 (fr) Passerelle pour encodage local de contenus de télévision numérique terrestre en segments de contenus adaptatifs sur http (has)
EP4465639A1 (fr) Procédé de gestion du traitement d'un flux vidéo dans un réseau local
EP2553900B1 (fr) Transmission de flux de données adaptable
EP3481069A1 (fr) Procédé et système de traitement d'un contenu multimédia dans un réseau de zone métropolitaine
EP4521753A1 (fr) Procédé de gestion du traitement d'un flux vidéo dans un réseau local
FR3147677A1 (fr) procédé de gestion de l’accès à un contenu multimédia et de la lecture de ce contenu.
FR3138020A1 (fr) Streaming vidéo adaptatif hybride amélioré
FR3155115A1 (fr) procédé de gestion de l’accès à des fichiers de description associés à un contenu diffusé en temps réel.
FR3124344A1 (fr) Procédé de gestion d’accès à des contenus téléchargés en mode de téléchargement adaptatif.

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: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20210803