METHOD FOR TRANSMITTING A DATA STREAM USING A STREAMING PROTOCOL

Abstract

Method for transmitting a data stream between a server and a client using the streaming protocol based on HTTP including the following steps implemented by the server following a reception of at least one item of information representing a capacity of said client: adapting an initial data stream to each capacity received in order to obtain an adapted data stream; decomposing the adapted data stream into segments; transmitting to the client an item of descriptive information making it possible to obtain, for each segment, a loading address of said segment, said descriptive information enabling the client to request from the server a transmission of the segments in order to obtain the adapted data stream.

Claims

1. A method for transmitting a data stream between a client and a server using a streaming protocol, wherein the method comprises the following steps implemented by the server: obtaining an initial data stream; receiving a request for descriptive information for the initial data stream from said client; checking that at least one item of information representing a capacity of said client has been received from said client; if no information representing a capacity of said client has been received: adapting the initial data stream in order to obtain a plurality of first data streams, each first stream being adapted to respective capacities of a client type belonging to a set of predefined client types; decomposing each first data stream into segments, referred to as first segments; and transmitting to said client a first item of descriptive information enabling the client to request a transmission of first segments of at least one first data stream; and, if at least one item of information representing a capacity of said client has been received: adapting said initial data stream to each capacity received in order to obtain a second data stream; decomposing the second data stream into segments, referred to as second segments; and transmitting to the client a second item of descriptive information enabling the client to request a transmission of second segments of the second data stream.

2. The method according to claim 1, wherein the streaming protocol is the streaming protocol based on HTTP.

3. The method according to claim 2, wherein the second item of descriptive information is put in the form of a playlist file compatible with the streaming protocol (404).

4. The method according to claim 3, wherein the transmission of the second item of descriptive information comprises a transmission to the client of a loading address of the playlist file compatible with the streaming protocol.

5. The method according to claim 4, wherein the server transmits the playlist file compatible with the streaming protocol to the client, following a reception, coming from the client, of an HTTP request containing said loading address.

6. The method according to claim 5, wherein the server transmits a second segment following a reception, coming from the client, of an HTTP request containing a loading address corresponding to said second segment, said loading address having been obtained from the text file compatible with the streaming protocol.

7. The method according to claim 1, wherein the capacities of the client comprise 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 supported maximum image resolution and/or a number of supported audio channels.

8. The method according to claim 1, wherein when said initial data stream comprises a video stream encoded in a first video compression format, an adaptation of said initial data stream comprises a transcoding for reducing a transmission rate of said video stream and/or an image resolution of said video stream and/or a transformation of said video stream so as to ensure compatibility with a second video compression format, and, when said initial data stream comprises an audio stream encoded in a first audio compression format, an adaptation of said initial data stream comprises a transcoding for reducing a transmission rate of said audio stream and/or a number of channels and/or a transformation of said audio stream in order to ensure compatibility with a second audio compression format.

9. A device of the server type able to transmit a data stream using a streaming protocol, wherein the device comprises circuitry adapted for: obtaining an initial data stream; receiving a descriptive information request for the initial data stream from a client; verifying that at least one item of information representing a capacity of said client has been received; adapting the initial data stream for obtaining a plurality of first data streams when no information representing a capacity of said client has been received, each first data stream being adapted to respective capacities of a client type belonging to a predefined set of client types; decomposing each first data stream into segments, referred to as first segments; and transmitting to a client a first item of descriptive information enabling the client to request a transmission of the first segments of at least one first data stream; adapting said initial data stream to each capacity received in order to obtain a second data stream when at least one item of information representing a capacity of said client has been received; decomposing the second data stream into segments, referred to as second segments; and transmitting to the client a second item of descriptive information enabling the client to request a transmission of second segments of the second data stream.

10. A device of the client type able to receive a data stream using the streaming protocol based on HTTP, wherein the device comprises circuitry adapted for: transmitting at least one item of information representing a capacity of said client device to a server; receiving a text file compatible with the streaming protocol based on HTTP, the text file corresponding to an initial data file and allowing to be obtained loading addresses of segments corresponding to a data stream, referred to as the second data stream, resulting from an adaptation by the server of the initial data stream to each capacity of said client-type device; 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 streaming protocol based on HTTP; and receiving the segment corresponding to the request transmitted.

11. A system for transmitting a data stream, comprising a device of server type according to claim 9 and a client device of the client type able to receive a data stream using the streaming protocol based on HTTP, wherein the client device of the client type comprises circuitry adapted for: transmitting at least one item of information representing a capacity of said client device to a server; receiving a text file compatible with the streaming protocol based on HTTP, the text file corresponding to an initial data file and allowing to be obtained loading addresses of segments corresponding to a data stream, referred to as the second data stream, resulting from an adaptation by the server of the initial data stream to each capacity of said client-type device; 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 streaming protocol based on HTTP; and receiving the segment corresponding to the request transmitted.

12. A computer program product, comprising a non-transitory computer readable medium embodying instructions for the implementation, by a device, of the method according to claim 1 when said program is executed by a processor of the device.

13. A non-transitory storage means, storing a computer program comprising instructions for the implementation, by a device, of the method according to claim 1 when said program is executed by a processor of said device.

Description

[0028] The features of the invention mentioned above, as well as others, will emerge more clearly from a reading of the following description of an example embodiment, said description being given in relation to the accompanying drawings, among which:

[0029] FIG. 1 illustrates schematically an example of a system in which a data transmission method using a streaming protocol is implemented;

[0030] FIG. 2A illustrates schematically an example of hardware architecture of a client device implementing the invention;

[0031] FIG. 2B illustrates schematically an example of hardware architecture of a server device implementing the invention;

[0032] FIG. 3A illustrates schematically an example of implementation of a method according to the invention;

[0033] FIGS. 3B and 3C illustrate schematically an example of implementation of the method of the HLS protocol type by a server;

[0034] FIG. 3D illustrates schematically an example of implementation of a method of the HLS protocol type by a client;

[0035] FIGS. 4A and 4B illustrate schematically an example of an implementation by a server of a method for streaming a data stream allowing a fine adaptation of the data stream to capacities of a client; and

[0036] FIG. 4C illustrates schematically an example of an implementation by a client of the method for streaming a data stream allowing a fine adaptation of the data stream to the capacities of the client.

[0037] Hereinafter the invention is described in the context of the HLS protocol. The invention is however suited to other protocols or methods for streaming data streams between a server and at least one client having a functioning similar to the HLS protocol. Moreover, the invention is described in the context of a local network (local area network) in which a multimedia server (set top box) obtains a data stream from a network, such as the internet, through a network gateway, and broadcasts data streams to clients of the local network. The invention is however suited to other contexts in which a server sends a data stream through a network to at least one client.

[0038] FIG. 1 illustrates schematically an example of a system in which a data transmission method using a streaming protocol is implemented. The system comprises a network gateway 12 connected by a network connection 11, such as an Ethernet connection, to a network 10 such as the internet. The network gateway 12 is an entry point to a local network. This local network comprises a server 14, such as a multimedia server or a TV decoder, connected to the network gateway 12 by a network connection 13 such as an Ethernet connection, a wireless connection or a powerline connection. The server 14 is connected to a client 16 by a network connection 15, such as an Ethernet connection, a wireless connection or a powerline connection. The client 16 may for example by a television set, a computer, a tablet or a smartphone.

[0039] The network gateway 12 receives data streams encapsulated in TCP (transmission control protocol, RFC 793), RTP (real-time transmission protocol, RFC 1889) or UDP (user datagram protocol) packets. Each data stream is next extracted from the packets by the network gateway 12 and supplied to the server 14 in the form of MPEG TS (Moving Picture Expert Group Transport Stream Part 1, ISO/IEC 13818-1) transport streams. Each MPEG TS transport stream may contain at least one video stream and/or at least one audio stream and/or at least one metadata stream such as a subtitle stream. When the client 16 chooses an initial data stream available on the server 14, the server 14 generates a plurality of first data streams in accordance with a method that we describe in relation to FIG. 3B. After a selection by the client 16 of one of the first data streams, a broadcast of the first selected data stream, in accordance with a method described in relation to FIGS. 3C and 3D, is implemented.

[0040] 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 stream to a client not corresponding to a client type in the predefined set of client types.

[0041] FIG. 3A illustrates schematically an example of implementation of a method according to the invention.

[0042] In a step 30, the server 14 obtains a set of data streams. This set of data streams may for example be obtained from a memory of the server 14 or supplied by the network gateway 12. Information representing the data streams available on the server 14 is then sent to the client 16. The client 16 selects one of the data streams available, and transmits information representing the selected data stream to the server 14. The data stream selected by the client 16 then becomes the initial data stream.

[0043] In a step 31, the server 14 receives the information representing the selected data stream transmitted by the client 16. The reception of the information representing the selected data stream serves as reception of a request for descriptive information for the initial data stream.

[0044] In a step 32, the server 14 checks that it has received information representing the capacities of the client 16. The information representing the capacities of the client 16 could have been received prior to the reception of the information representing the selected data stream or the server may, following the reception of the information representing the selected data stream, await reception of at least one item of information representing the capacities of the client 16 for a predefined time.

[0045] If, after a duration equal to the predefined time, the server 14 has not received any information representing the capacities 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 to FIGS. 3B and 3C.

[0046] If, during step 32, the server 14 finds that it has received at least one item of information representing the capacities of the client 16, it implements, during a step 34, a method allowing a fine adaptation of the initial data stream to the capacities of the client 16. An example of implementation of the method by the server 14 allowing a fine adaptation of the initial data streams to the capacities of the client 16 is described in relation to FIGS. 4A and 4B.

[0047] In one embodiment, the server 14 broadcasts the information representing the data streams available on the server 14 before having actually received the corresponding data streams. It is then the reception by the server of the request for descriptive information for a data stream that triggers the actual obtaining by the server 14 of the data stream requested.

[0048] FIGS. 3B and 3C illustrate schematically an example of implementation of the HLS protocol by the server 14.

[0049] In a step 302, the server 14 adapts the initial data stream in order to obtain a plurality of first data streams. Each first data stream is adapted to respective capacities of a client type belonging to a set of predefined client types. The capacities of a client comprise for example: [0050] a supported video compression format. A client may for example 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-10MPEG-4 Part 10, Advanced Video Coding/ITU-T H.264), HEVC (ISO/IEC 23008-2MPEG-H Part 2, (High-Efficiency Video Coding)/ITU-T H.265), [0051] a supported audio compression format. A client may for example support one or more of the following audio compression formats: MP3 (MPEG-1 level III), AAC (Advanced Audio Coding), [0052] a supported image compression format. A client may for example support one or more of the following image compression formats: JPEG (ISO/IEC 10918-1/UIT-T recommendation T.81), JPEG 2000 (ISO/IEC 15444-1), [0053] if the client has subtitle decoding means, [0054] a type of network used by the client: Ethernet, Wi-Fi, CPL, [0055] a reception rate, [0056] the maximum image resolution supported by the client, [0057] the number of audio channels supported by the client.

[0058] A plurality of types of adaptation can be applied to an initial data stream when the first data sub-streams are obtained. When an initial data stream comprises a video stream encoded in a first video compression format, a transcoding may be applied to the video stream in order to reduce a transmission rate of said video stream and/or to reduce an image resolution of said video stream and/or to reduce an image frequency of said video stream and/or to transform said video stream so as to ensure compatibility with a second video compression format. When an initial data stream comprises an audio stream encoded in a first audio compression format, a transcoding may be applied to the audio stream in order to reduce a transmission rate of said audio stream and/or to reduce a number of channels of said audio stream and/or to transform said audio stream in order to ensure compatibility with a second audio compression format. Other types of adaptation may comprise an elimination of a subtitle stream when a client type in the predefined set of client types is not able to decode said subtitle stream.

[0059] In a step 303, the server 14 decomposes each first data stream into segments, referred to as first segments. During step 303, the server 14 associates each segment with information representing said segment comprising a URI address, a sequence number and a size of said segment.

[0060] During steps 304 and 305, the server 14 transmits to the client 16 a first item of descriptive information allowing to obtain, for each first data stream, at least one characteristic of said first data stream and for each first segment a loading address of said first segment. The first item of descriptive information enables the client 16 to request a transmission of first segments according to capacities of the client 16 in order to obtain a version of the initial data stream adapted to said capacities.

[0061] During step 304, the server 14 creates a playlist file for each first data stream. For each first data stream, the server 14 inserts the information representing each segment of said first data stream that it wishes to make accessible to the client 16 in the playlist file corresponding to said first data stream. Following the creation of the playlist files, the server 14 allocates a URI address to each playlist file. A master playlist file is next created, in which the server 14, for each first data stream, inserts the URI addresses of the playlist 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 playlist file may, for example, indicate for which client type in the predefined set of client types the first data stream was adapted and/or a transmission rate of the first data stream and/or an image resolution of a video stream contained in the first data stream and/or an image frequency of a video stream contained in the first data stream and/or a number of audio channels of an audio stream contained in the first data stream. Hereinafter, the server 14 associates a URI address with the master playlist file and sends this URI address to the client 16 in a step 305. This URI address being, for the client 16, the first item of descriptive information making it possible to obtain a version of the initial data stream.

[0062] In a step 311, the server 14 receives, coming from the client 16, an HTTP request containing the URI of the master playlist file. Following the reception of this request, the server 14 transmits the master playlist 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 data stream selected.

[0063] In a step 312, the server 14 transmits to the client 16 the playlist file corresponding to the data stream selected.

[0064] In a step 313, the server 14 checks that it has received an HTTP request containing a URI address of a first segment requested by the client 16. If such is the case, during a step 315, the server 14 transmits the first requested segment to the client 16 and returns to step 313. If no HTTP request for a new segment is received during a predefined time or the last segment transmitted is a final segment of the first data stream, the server 14 ends the broadcasting of the first data stream during a step 314.

[0065] FIG. 3D illustrates schematically an example of implementation of the HLS protocol by the client 16. The client 16 is supposed to have selected an initial data stream from a set of data streams available in the server 14. In this example, the client 16 has not transmitted its capacities to the server 14. The client 16 has therefore received the URI address of the master playlist file corresponding to the selected initial data stream transmitted during step 305.

[0066] In a step 321, at a moment 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 playlist file corresponding to the initial data stream that it selected. In return, the client 16 receives said master playlist file from the server 14. The client 16 then selects a first data stream from the first data streams mentioned in the master playlist file using the descriptions of each first data stream. During this selection, the client 16 compares the capacities of said client 16 with the information contained in the descriptions of each first data stream. If the client 16 corresponds to a client type included in the predefined set of client types, the client 16 chooses the first data stream corresponding to this client type in the predefined set. If the client 16 does not correspond to a client type represented in the set of predefined client types, the client 16 chooses a first data stream having characteristics as close as possible to the capacities of the client 16.

[0067] After having selected 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 data stream selected.

[0068] In a step 322, the client 16 receives the playlist file corresponding to the first data stream that it selected.

[0069] In a step 323, the client 16 seeks in the playlist file a first segment to be requested to the server 14. When the client 16 for the first time requests a first segment for the first data stream that it selected, the client 16 in general selects the first segment having the lowest sequence number in the playlist file that it received.

[0070] In a step 324, the client 16 transmits an HTTP request to the server 14 containing the URI address of said first segment selected.

[0071] In a step 325, the client 16 receives said first segment and supplies this first segment to a decoding module responsible for decoding of the first segment.

[0072] In a step 326, the client 16 checks whether the broadcasting of the initial data stream that it selected must be continued. The broadcasting of a data stream may, for example, be controlled by a user of the client 16. If the broadcasting must be continued, the client 16 once again implements step 323 and requests the first segment following the first segment previously requested, i.e. the first segment having a sequence number incremented by one unit with respect to the sequence number of the first segment previously requested. If the broadcasting must not be continued, the client 16 ends it in a step 327.

[0073] In an embodiment suited to a client having capacities varying over time, during step 321 the client 16 can transmit to the server 14 an HTTP request containing all the URI addresses contained in the master playlist file. In this way, the client 16 receives each playlist file corresponding to the initial data stream that it selected. During step 326, if the broadcasting of the initial data stream must be continued, the client 16 selects a first data stream compatible with capacities of the client 16 found at the time of implementation of step 326. The client 16 next selects the next segment to be requested to the server in the playlist file corresponding to the first data stream selected during step 326.

[0074] The example 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 stream to the capacities of the client 16.

[0075] FIGS. 4A and 4B illustrate schematically an example of an implementation by the server 14 of a method for streaming a data stream allowing a fine adaptation of the data stream to the capacities of a client. This method corresponds to step 34 described in relation to FIG. 3A.

[0076] In a step 402 following step 32, in the same way as the server 14 had adapted the initial data stream to the respective capacities of the client types in the predefined set of client types for obtaining the first data streams, the server 14 adapts the initial data stream to each capacity of the client 16 received for obtaining a second data stream.

[0077] In a step 403, the server 14 decomposes the second data stream into segments, referred to as second segments. Each second segment is associated with a URI address.

[0078] During steps 404 and 405, the server 14 transmits to the client 16 a second item of descriptive information making it possible to obtain, for each second segment, the URI address of said second segment. The second item of descriptive information enables the client 16 to request a transmission of the second segments in order to obtain the second data stream.

[0079] In step 404, the server 14 creates a playlist file and inserts therein the URI addresses, the sequence numbers and the durations of the second segments. The server 14 next allocates a URI address to the playlist file thus created.

[0080] During step 405, the URI address of the playlist file containing the URI addresses of the second segment is transmitted to the client 16. The URI address of the playlist file containing the URI addresses of the second segments corresponds to the second item of descriptive information enabling the client 16 to request a transmission of the second segments in order to obtain the second data stream.

[0081] In a step 411, the server 14 receives an HTTP request coming from the client 16 containing the URI address of the playlist file containing the URI addresses of the second segments.

[0082] In a step 412, the server 14 transmits the playlist file containing the URI addresses of the second segments to the client 16.

[0083] In a step 415, following a reception, in a step 413, of an HTTP request containing a URI address of a second segment coming 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.

[0084] If during step 413 no HTTP request for a new segment is received during a predetermined time or the last segment transmitted is a final segment of the second data stream, the server 14 ends the broadcasting of the second data stream during a step 414.

[0085] FIG. 4C illustrates schematically an example of an implementation by a client of the method for streaming a data stream allowing a fine adaptation of the data stream to the capacities of the client.

[0086] In a step 420, the client 16 transmits to the server 14 information representing its capacities.

[0087] In a step 421, at a moment 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 URI addresses of the second segments. In return, the client 16 receives said playlist file from the server 14 during a step 422.

[0088] In a step 423, the client 16 seeks in the playlist file a second segment to be requested from the server 14. When the client 16 first requests a second segment, the client 16 in general selects the second segment having the lowest sequence number in the playlist file that it has received.

[0089] In a step 424, the client 16 transmits an HTTP request to the server 14 containing the URI address of said second segment selected.

[0090] In a step 425, the client 16 receives said second segment and supplies this second segment to a decoding module responsible for decoding the second segment.

[0091] In a step 426, the client 16 checks whether the broadcasting of the initial data stream that it selected must be continued. If the broadcasting must be continued, the client 16 once again executes step 423 and requests the second segment following the previously requested segment, i.e. the second segment having a sequence number incremented by one unit with respect to the sequence number of the second segment previously requested. If the broadcasting must not be continued, the client 16 ends it during a step 427.

[0092] In one embodiment, the client 16 can open an HTTP connection with the server 14 in order to transmit its capacities. This connection can be closed by the server as soon as the capacities of the client 16 are received.

[0093] In one embodiment, the method described in relation to 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 whereas the second client would be compatible with the HLS protocol and the method described in relation to FIGS. 4A, 4B and 4C.

[0094] In one embodiment, during step 402, the server 14 also generates first data streams as described in relation to step 302. During step 403, the server 14 also generates first segments as described in relation to step 303. During step 404, the server 14 also generates a playlist file for each first data stream as described in relation to step 304. The URI addresses of the playlist files corresponding to the first data streams and to the second data stream are inserted in a master playlist file. During step 405, the URI address of the master playlist file is transmitted to the client 16. In this embodiment, the client 16 can choose, from the first data streams and the second data streams, the data stream most appropriate to its capacities at a given instant. In this embodiment, a client other than the client 16 could also receive the master playlist file and choose, from the first data streams and the second data stream, the data stream most appropriate to its capacities. Thus a client not implementing the method described in relation to FIG. 3 but only the HLS protocol, could receive the second data stream if its capacities are closer to those of the client 16 than to those of the client types in the predefined set of client types.

[0095] In one embodiment, the client 16 can send to the server 14 new information representing its capacities at regular intervals or when its capacities have changed significantly with respect to the last capacities sent. The sending of new information representing capacities of the client 16 causes a new adaptation of the initial data stream by the server 14 in order to generate a new second data stream adapted to the new capacities.

[0096] FIG. 2A illustrates schematically an example of hardware architecture of a client device implementing the HLS protocol and/or the method described in relation to FIG. 4C. We take here the example of the client 16. The client 16 then comprises, connected by a communication bus 165: a processor or CPU (central processing unit) 160; a random access memory (RAM) 161; a read only memory (ROM) 162; a storage unit or storage-medium reader, such an as SD (secure digital) card reader 163; a set 164 of connection interfaces for connecting the client 16 to the server 14.

[0097] The processor 160 is capable of executing instructions loaded in the RAM 161 from the ROM 162, from an external memory (not shown), from a storage medium such as an SD card, or from a communication network. When the client 16 is powered up, the processor 160 is capable of reading instructions from the RAM 161 and executing them. These instructions form a computer program causing the implementation, by the processor 160, of all or some of the methods described in relation to FIGS. 3C and 4C.

[0098] FIG. 2B illustrates schematically an example of hardware architecture of a server device implementing the invention. We take here the example of the server 14. The server 14 then comprises, connected by a communication bus 145: a processor or CPU (central processing unit) 140; a random access memory (RAM) 141; a read only memory (ROM) 142; a storage unit or storage-medium reader, such an as SD (secure digital) card reader 143; a set 144 of connection interfaces for connecting the server 14 to the client 16 and to the network gateway 12.

[0099] The processor 140 is capable of executing instructions loaded in the RAM 141 from the ROM 142, from an external memory (not shown), from a storage medium such as an SD card, or from a communication network. When the server 14 is powered up, the processor 140 is capable of reading instructions from the RAM 141 and executing them. These instructions form a computer program causing the implementation, by the processor 140, of all or some of the methods described in relation to FIGS. 3A, 3B, 4A and 4B.

[0100] 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 the execution of a set of instructions by a programmable machine such as a DSP (digital signal processor) or a microcontroller, or be implement in hardware form by a machine or a dedicated component such as an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit).