Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
  • H04L65/60—Network streaming of media packets
  • H04L65/75—Media network packet handling
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams 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
  • H04L65/762—Media network packet handling at the source 
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
  • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
  • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
  • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
  • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams 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 Networks & Wireless Communication (AREA)
• Computer Graphics (AREA)
• Computer Security & Cryptography (AREA)
• Information Transfer Between Computers (AREA)
• Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=53269627

Family Applications (1)

Country Status (6)

Families Citing this family (3)

Family Cites Families (16)

• 2015
  • 2015-01-16 FR FR1550342A patent/FR3031862B1/fr not_active Expired - Fee Related
• 2016
  • 2016-01-14 US US15/541,133 patent/US20180198834A1/en not_active Abandoned
  • 2016-01-14 BR BR112017014537A patent/BR112017014537A2/pt not_active IP Right Cessation
  • 2016-01-14 WO PCT/EP2016/050697 patent/WO2016113364A1/fr active Application Filing
  • 2016-01-14 EP EP16700626.1A patent/EP3245794A1/fr not_active Withdrawn
  • 2016-01-14 CN CN201680005854.6A patent/CN107211166A/zh active Pending

Also Published As

Similar Documents

Legal Events