CN111654725A

CN111654725A - Real-time receiving method and client of media stream

Info

Publication number: CN111654725A
Application number: CN201910161631.4A
Authority: CN
Inventors: 姜红旗
Original assignee: Beijing Kaiguang Information Technology Co ltd
Current assignee: Beijing Kaiguang Information Technology Co ltd
Priority date: 2019-03-04
Filing date: 2019-03-04
Publication date: 2020-09-11
Anticipated expiration: 2039-03-04
Also published as: CN111654725B

Abstract

The invention discloses a real-time receiving method of a media stream and a client, wherein the method comprises the following steps: sending a media segment request to a server; receiving and analyzing the media segments fed back by the server, analyzing media units from the media segments, and generating a first receiving report of the target media stream; receiving and analyzing at least one path of pushed target media stream, wherein a media unit is analyzed from the pushed target media stream, and a second receiving report of the target media stream is generated; and generating a new media segment request according to the first receiving report and the second receiving report, wherein the control parameters carried by the new media segment request are determined. According to the receiving method of the embodiment of the invention, two modes of pulling and pushing are integrated, unicast/multicast/broadcast transmission of the media stream is supported, and the transmission efficiency and reliability of the real-time media stream are improved.

Description

Real-time receiving method and client of media stream

Technical Field

The present invention relates to the field of digital information transmission technologies, and in particular, to a real-time receiving method of a media stream and a client.

Background

With the rapid development of the internet, especially the mobile internet, the real-time transmission of multimedia data such as audio, video, and image through the internet becomes a basic requirement for many applications, and to meet this requirement, various streaming media real-time transmission technologies are proposed, and currently, the streaming media real-time transmission technologies are widely used, and mainly include three types: Real-Time transport Protocol RTP (Real-Time transport Protocol)/RTSP (Real-Time Streaming Protocol)), RTMP (Real-Time Messaging Protocol), and HTTP (HyperText transport Protocol) adaptive Streaming has (HTTP adaptive Streaming). The HTTP adaptive streaming comprises a plurality of schemes: hls (HTTP Live Streaming) by apple, Smooth Streaming by microsoft, hds (HTTP Dynamic Streaming) by Adobe, DASH (Dynamic Adaptive Streaming over HTTP) by MPEG organization.

The common feature of the above HTTP adaptive streaming schemes is to cut a media stream into media segments of short time (2s to 10s), generate an index file or a manifest file (e.g., MPD file in m3u8 playlist and DASH in HLS) describing the media segments at the same time, store the index file or the manifest file in each Web server, obtain URL (Uniform Resource Locator) access addresses of the media segments by accessing the playlist or the manifest file by a client, and then download the media segments one by one and play the media segments by using a standard HTTP protocol. The main difference between these schemes is represented by the difference between the encapsulation format and the manifest file format employed by the media segments.

Compared with RTP/RTSP and RTMP, HTTP adaptive streaming can make full use of the existing Internet Web caching facilities (such as CDN and various Web caching servers) and can support large-scale user access. Meanwhile, the client can be supported to select the fragments with proper code rates according to network conditions and terminal capability by providing the media fragments with various code rates, so that code rate self-adaption is realized. Therefore, HTTP adaptive streaming has become the mainstream way of real-time streaming media delivery on the internet at present.

However, the HTTP adaptive streaming schemes of the related art all have the following problems:

1. the duration of the media segments cannot adapt to dynamically changing network transmissions. The HAS schemes of the related art all adopt a pre-segmentation mode, that is, the server generates media segments and a manifest file thereof according to a preset time length and submits the media segments and the manifest file to the web server. When the network transmission bandwidth is sufficient and the delay is small, setting a large segment duration means increasing the delay of real-time transmission; when the network transmission bandwidth is insufficient and the delay is large, setting a small segment duration means frequent file requests, and increases the burden of the server and the network transmission overhead. Because the transmission bandwidth and the transmission delay on the internet are dynamically changed, optimal transmission cannot be realized by adopting a pre-segmentation mode with fixed time length.

2. The manifest file adds transfer delay and overhead. The client needs to obtain the manifest file first to obtain the URL address of the media segment. However, since the manifest file needs to be transmitted to the client after a period of time, the manifest file obtained by the client cannot reflect the current generation situation of the latest media segments, and in addition, when the manifest file is blocked or transmission errors occur, the fast access of the user to the media segments is blocked, which reduces the transmission performance of the real-time streaming media.

3. Multicast/broadcast delivery is not supported. When many clients simultaneously access the same real-time media stream on the server, the server needs to send data to each user once, and the processing overhead and bandwidth overhead of the server increases as the number of clients increases. If the network where the server and the client are located supports multicast or broadcast transmission, the server only needs to send once and all the clients can receive, which greatly reduces the processing overhead and bandwidth overhead of the server, but the existing adaptive transmission schemes are all based on point-to-point transmission of the HTTP protocol and do not support point-to-multipoint multicast or broadcast transmission.

Disclosure of Invention

The present invention is directed to solving, at least to some extent, one of the technical problems in the related art.

To this end, an object of the present invention is to provide a real-time receiving method for a media stream, which can simultaneously support unicast/multicast/broadcast transmission of the media stream, and improve the transmission efficiency and reliability of the real-time media stream.

A second object of the present invention is to provide a real-time receiving client for media streams.

A third object of the invention is to propose a computer device.

A fourth object of the invention is to propose a non-transitory computer-readable storage medium.

A fifth object of the invention is to propose a computer program product.

To achieve the above object, an embodiment of an aspect of the present invention provides a real-time receiving method for a media stream, where the media stream is a sequence of media units generated in real time, and each media unit is associated with a generation time and/or a sequence number indicating a generation sequence, where the method includes: sending a media segment request to a server, wherein the media segment request does not carry or carries at least one control parameter, and the control parameter comprises a first type parameter indicating a target media stream to be transmitted and a second type parameter indicating a candidate media unit to be transmitted; receiving and analyzing the media segments fed back by the server, analyzing media units from the media segments, and generating a first receiving report of a target media stream; receiving and analyzing at least one path of pushed target media stream, wherein a media unit is analyzed from the pushed target media stream, and a second receiving report of the target media stream is generated; and generating a new media segment request according to the first receiving report and the second receiving report, wherein the control parameters carried by the new media segment request are determined.

The real-time receiving method of the media stream integrates two transmission modes of pulling and pushing simultaneously. When the pull mode is adopted, the client sends a media segment request to the server, the server generates a media segment according to the received media segment request and returns the media segment to the client, the content and the duration of the media segment are controlled through parameters carried in the request and the interval of the request sending, and the media segment generated according to the requirement can better adapt to the dynamic network transmission environment. Because each media segment is generated by the request trigger of the client, the manifest file is not required any more, and the manifest file is not required to be requested and analyzed, on one hand, the latest media stream can be obtained more quickly, the transmission delay of the real-time media stream is reduced, on the other hand, the transmission overhead and the processing overhead brought by the manifest file are also reduced, and thus the transmission delay and the overhead are effectively reduced.

Further, the client may also receive a pushed target media stream from one or more servers, and the pushed target media stream may include all data or part of data of the target media stream, which may provide the following advantages: firstly, the pushed data can be transmitted by multicast/broadcast, and the client only needs to pull the media data which is not successfully pushed, so that the processing overhead and bandwidth overhead of the server are greatly reduced, and the transmission efficiency of the media stream is improved; secondly, the pull channel and the plurality of push channels can be used simultaneously, and even if one channel fails, the client can acquire the media stream from other channels, so that the reliability of media stream transmission is improved; and thirdly, the client can select the pulled media data by itself to adapt to the change of the network bandwidth, for example, the server pushes the basic media data with higher priority to all the clients, and each client determines whether to pull other low-priority data according to the condition of the respective access bandwidth.

In addition, the real-time receiving method of the media stream according to the above embodiment of the present invention may further have the following additional technical features:

optionally, in an embodiment of the present invention, the client receives the pushed target media stream by using an IP unicast or IP multicast manner.

Further, in an embodiment of the present invention, the sending the media segment request to the server further includes: if no media unit is received, sending an initial media segment request to the server; and if the new media segment request is generated according to the receiving report, sending the new media segment request to the server.

Optionally, in an embodiment of the present invention, the second type of parameter includes one or more of a start sequence number, a number of units, a start time, a segment duration, a sequence number range, a generation time range, and a priority range.

Wherein, in one embodiment of the present invention, the first reception report and the second reception report contain the serial number and/or the generation time of the media unit which is successfully received currently.

Further, in an embodiment of the present invention, the generating a new media segment request according to the first reception report and the second reception report further comprises: and when the pushed target media stream fails to be received, generating the new media segment request according to the first receiving report, wherein if the second type of parameters carried by the new media segment request comprise a starting sequence number or starting time, the value of the starting sequence number is the sequence number value of the latest media unit which is successfully received currently, and the value of the starting time is the generation time of the latest media unit which is successfully received currently.

Further, in an embodiment of the present invention, the generating a new media segment request according to the first reception report and the second reception report further comprises: determining the media units which are successfully received at the current time, determining the candidate media units which need to be pulled at the current time, and determining the second type parameters describing the range of the candidate media units.

Further, in an embodiment of the present invention, the determining the candidate media units that need to be pulled at the current time further includes: setting a latest push receiving time for each media unit to be received, wherein the candidate media units needing to be pulled at the current time comprise all or part of the media units which are not successfully received and are before the current time at the latest push receiving time.

Further, in an embodiment of the present invention, each media unit is associated with a priority, the pushed target media stream only contains media units with a specified priority range, and the candidate media units that need to be pulled at the current time include all or part of the media units with priorities that are not within the specified priority range and that have not been successfully received.

In order to achieve the above object, another embodiment of the present invention provides a client for receiving a media stream in real time, where the media stream is a sequence of media units generated in real time, and each media unit is associated with a generation time and/or a sequence number indicating a generation sequence, where the client includes: a media stream pulling component, configured to send a media segment request to a server, and receive and analyze a media segment fed back by the server, where the media segment request does not carry or carry at least one control parameter, and the control parameter includes a first type parameter indicating a target media stream to be transmitted and a second type parameter indicating a candidate media unit to be transmitted, and the analyzing the media segment includes: analyzing a media unit from the media segment and generating a first receiving report of a target media stream; the pushed media stream receiving component is used for receiving and analyzing at least one path of pushed target media stream, wherein a media unit is analyzed from the pushed target media stream, and a second receiving report of the target media stream is generated; and the media stream transmission control component is used for generating a new media segment request according to the first receiving report and the second receiving report, wherein the control parameter carried by the new media segment request is determined.

The real-time receiving client of the media stream integrates two transmission modes of pulling and pushing simultaneously. When the pull mode is adopted, the media segment request is continuously sent to the server, the server generates the media segment according to the received media segment request and returns the media segment to the client, the content and the duration of the media segment are controlled through the parameters carried in the request and the interval of the sending request, the media segment generated according to the requirement can better adapt to the dynamic network transmission environment, and because each media segment is triggered by the request of the client, a list file is not needed any more, and the list file is not needed to be requested and analyzed, on one hand, the latest media stream can be obtained more quickly, the transmission delay of the real-time media stream is reduced, on the other hand, the transmission overhead and the processing overhead brought by the list file are also reduced, so that the transmission delay and the overhead are effectively reduced, and the transmission performance of the real-time media stream is further improved.

Further, the real-time receiving client of the media stream according to the embodiment of the present invention may further receive a pushed target media stream from one or more servers, where the pushed target media stream may include all data or part of data of the target media stream. This may provide the following benefits: firstly, the pushed data can be transmitted by multicast/broadcast, so that the client only needs to pull the media data which is not successfully pushed, the processing overhead and bandwidth overhead of the server are greatly reduced, and the transmission efficiency of the media stream is improved; secondly, the pull channel and the plurality of push channels can be used simultaneously, and even if one channel fails, the client can acquire the media stream from other channels, so that the reliability of media stream transmission is improved; and thirdly, the client can select the pulled media data by itself to adapt to the change of the network bandwidth, for example, the server pushes the basic media data with higher priority to all the clients, and each client determines whether to pull other low-priority data according to the condition of the respective access bandwidth.

In addition, the real-time receiving client of the media stream according to the above embodiment of the present invention may further have the following additional technical features:

Further, in an embodiment of the present invention, the media stream pulling component is further configured to send an initial media segment request to the server when no media unit is received; and when the new media segment request is generated according to the receiving report, sending the new media segment request to the server.

Optionally, in an embodiment of the present invention, the first reception report and the second reception report contain a serial number and/or a generation time of a media unit which is successfully received currently.

Further, in an embodiment of the present invention, the media stream transmission control component is further configured to generate the new media segment request according to the first reception report when receiving the pushed target media stream fails, wherein if the second type parameter carried by the new media segment request includes a start sequence number or a start time, a value of the start sequence number is a sequence number value of a latest media unit that is currently successfully received, and a value of the start time is a generation time of the latest media unit that is currently successfully received.

Further, in an embodiment of the present invention, the media streaming control component is further configured to determine a media unit that has been successfully received at the current time, determine a candidate media unit that needs to be pulled at the current time, and determine a second type parameter describing a range of the candidate media unit.

Further, in an embodiment of the present invention, the media streaming control component is further configured to set a latest push reception time for each media unit to be received, and the candidate media units that need to be pulled at the current time include all or part of the media units that were not successfully received before the current time by the latest push reception time.

In order to achieve the above object, a third embodiment of the present invention provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the processor implements the real-time receiving method of the media stream as described in the above embodiment.

To achieve the above object, a fourth aspect of the present invention provides a non-transitory computer readable storage medium, which when executed by a processor, implements a real-time receiving method for a media stream as described in the above embodiments.

To achieve the above object, a fifth embodiment of the present invention provides a computer program product, wherein when the instructions in the computer program product are executed by a processor, the real-time receiving method of a media stream as described in the above embodiments is performed.

Additional aspects and advantages of the invention will be set forth in part in the description which follows and, in part, will be obvious from the description, or may be learned by practice of the invention.

Drawings

The foregoing and/or additional aspects and advantages of the present invention will become apparent and readily appreciated from the following description of the embodiments, taken in conjunction with the accompanying drawings of which:

fig. 1 is a flowchart of a real-time receiving method of a media stream according to an embodiment of the present invention;

fig. 2 is a schematic diagram of hybrid unicast/multicast/broadcast delivery according to one embodiment of the present invention;

FIG. 3 is a diagram illustrating a delivery process of a client pull media stream when a push failure is received according to an embodiment of the present invention;

fig. 4 is a schematic diagram illustrating a transmission process of a client receiving a media stream in a pull and push manner according to an embodiment of the present invention;

fig. 5 is a schematic diagram illustrating a transmission process of a client receiving a media stream in a pull and push manner according to an embodiment of the present invention;

fig. 6 is a schematic structural diagram of a real-time receiving client of a media stream according to an embodiment of the present invention;

fig. 7 is a schematic structural diagram of a real-time receiving client of a media stream according to an embodiment of the present invention.

Detailed Description

Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings, wherein like or similar reference numerals refer to the same or similar elements or elements having the same or similar function throughout. The embodiments described below with reference to the drawings are illustrative and intended to be illustrative of the invention and are not to be construed as limiting the invention.

In the internet, it is often necessary to transmit various real-time generated audio, video or data streams from one network node to another, the network nodes including both various terminals such as PCs, mobile phones, tablets and various application servers such as video servers and audio servers, and the transmitted audio, video or data streams are collectively referred to as media streams. The delivery process of a media stream can be described in a general client-server model: the media stream generated in real time is delivered by the server to the client. The server and the client refer to logical functional entities, where the server is a functional entity that transmits a media stream, and the client is a functional entity that receives a media stream. Further, the server can be divided into a pull server and a push server according to functions, wherein the push server can actively send media stream data, and the pull server needs to send the media stream data after receiving a request of the client. The server and the client can exist on any network node, and the pull server and the push server can also coexist on the same server or network node.

Each transmitted media stream is a sequence of media units generated in real time. Different media streams, their corresponding media units can be selected by themselves. When the media stream is a byte stream generated in real time, a byte can be selected as a media unit; when the media stream is an audio stream or a video stream obtained through real-time sampling, an original audio frame or a video frame can be selected as a media unit; when the media stream is an audio stream or a video stream which is sampled and encoded in real time, an encoded audio frame, an encoded video frame or an Access Unit (Access Unit) can be selected as a media Unit; when the media stream is an audio stream or a video stream that is sampled, encoded and encapsulated in real time, the encapsulated transport packets (e.g., RTP packets, PES/PS/TS packets, etc.) may be selected as media units; when the media stream is an audio or video stream that is sampled, encoded, encapsulated, and pre-segmented in real-time, a segmented media segment (e.g., a TS format segment used in HLS protocol, fMP4 format segment used in DASH protocol) may be selected as a media unit.

Each media unit may be associated with a generation time, which is typically a timestamp. Each media unit may also be associated with a sequence number that may be used to indicate the order in which the media units were generated. When sequence numbers are used to indicate the order in which the media units are generated, the meaning of the sequence numbers need to be defined in terms of the specific media unit. When the media unit is a byte, the serial number of the media unit is a byte serial number; when the media units are audio frames and video frames, the serial numbers of the media units are frame serial numbers; when the media unit is a transmission packet, the sequence number of the media unit is a packet sequence number; when the Media unit is a stream segment, the Sequence number of the Media unit is a segment Sequence number (e.g., Media Sequence of each TS segment in HLS).

For a media stream, a Sequence Number indicating a generation Sequence and a generation time may be associated at the same time, for example, when the real-time media stream is an RTP packet stream, the RTP header has both a Sequence Number (Sequence Number) field to indicate the Sequence of the RTP packet and a timestamp field to indicate the generation time of the media data encapsulated in the RTP. In this case, multiple consecutive RTP packets may correspond to the same generation time, but their sequence numbers are unique.

The method of the embodiments of the present invention may be implemented for any kind of real-time media stream. In the following embodiments, the RTP real-time media stream is selected to illustrate the implementation method of the embodiments of the present invention. For an RTP real-time stream, a media unit is an RTP packet, a packet Sequence Number (Sequence Number) of the RTP is selected as a Sequence Number of the media unit, the packet Sequence Number of the RTP packet is a 16-bit field, the maximum value is 65535, the Sequence Number of a continuously generated RTP packet is circularly counted, and if the Sequence Number of the current packet is Seq, the Sequence Number of the next packet is (Seq + 1)% 65536, so that the Sequence Number is limited by the bit length in implementation, the situation that the Sequence Number size cannot reflect the Sequence order of the next packet possibly occurs, at the moment, whether the Sequence Number circularly counts or not can be judged according to the generation time of the media unit, and the Sequence relation and the interval of the Sequence numbers of the two media units can be accurately judged.

In a conventional real-time streaming media protocol such as RTP or RTMP, a server push method is adopted: and the server actively sends the new media unit to the client once the new media unit exists. In various HTTP adaptive streaming (e.g., HLS, smooth streaming, MPEG-DASH) schemes, a client pull is used. In the method of the embodiment of the invention, the client can simultaneously pull the media stream and receive the media stream pushed by the server. In addition, in the existing various HTTP adaptive streams, the client requests or pulls the segmented segments according to the manifest file, each segment may be identified by one URL, but in the embodiment of the present invention, the media segments are not segmented in advance, but are generated by the server in real time according to the request of the client, and the client may control the content and duration of the pulled media segments.

The following describes a real-time receiving method and a client for a media stream according to an embodiment of the present invention with reference to the drawings, and first, the real-time receiving method for a media stream according to an embodiment of the present invention will be described with reference to the drawings.

Fig. 1 is a flowchart of a real-time receiving method of a media stream according to an embodiment of the present invention.

As shown in fig. 1, the real-time receiving method of a media stream is a sequence of media units generated in real time, each media unit being associated with a generation time and/or a sequence number indicating a generation sequence, and the method includes the following steps:

in step S101, a media segment request is sent to a server, where the media segment request does not carry or carries at least one control parameter, and the control parameter includes a first type parameter indicating a target media stream to be transmitted and a second type parameter indicating a candidate media unit to be transmitted.

It will be appreciated that the media segment request may be submitted using any protocol, such as the common HTTP protocol, TCP protocol, UDP protocol, RTP protocol, QUIC protocol, and the like. When the media segment request is submitted by adopting an HTTP protocol, an HTTP-GET mode or an HTTP-POST mode can also be adopted.

When the media segment request carries control parameters, the control parameters need to be packaged into a character string or a byte stream in a certain way and sent to the server. For example, when HTTP-GET is used to send media segment requests, the control parameters may be encapsulated as a string into a URL. An example of a media segment request with HTTP-GET is as follows:

media segment request without control parameters:

GET“http://www.xxx-server.com/msreq”[req1]

media segment request carrying a control parameter:

GET“http://www.xxx-server.com/msreq？streamID＝601”[req2]

GET“http://www.xxx-server.com/msreq？seqBegin＝1005”[req3]

GET“http://www.xxx-server.com/msreq？timeBegin＝31000”[req4]

GET“http://www.xxx-server.com/msreq？unitCount＝8”[req5]

GET“http://www.xxx-server.com/msreq？segDuration＝1000”[req6]

GET“http://www.xxx-server.com/msreq？seqRange＝1010-1015”[req7]

GET“http://www.xxx-server.com/msreq？timeRange＝31000-32000”[req8]

GET“http://www.xxx-server.com/msreq？priorityRange＝1-2”[req9]

media segment request carrying two control parameters:

GET“http://www.xxx-server.com/msreq？streamID＝602&seqBegin＝1020”[req10]

GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝32000”[req11]

GET“http://www.xxx-server.com/msreq？seqBegin＝1010&unitCount＝5”[req12]

GET“http://www.xxx-server.com/msreq？timeBegin＝31000&segDuration＝3000”[req13]

GET“http://www.xxx-server.com/msreq？seqBegin＝1010&priorityRange＝1-2”[req14]

media segment requests carrying three control parameters:

GET“http://www.xxx-server.com/msreq？streamID＝601&seqBegin＝1010&unitCount＝5”[req15]

GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝33000&segDuration＝3000”[req16]

in the URL of the request, the parameter names streamID, seqBegin, timebegingin, unitCount, segDuration, seqRange, timeRange, and priorityrrange respectively represent the media stream identifier, start sequence number, start time, unit number, segment duration, sequence number range, generation time range, and priority range.

In step S102, the media segment fed back by the server is received and parsed, and a media unit is parsed from the media segment, and a first reception report of the target media stream is generated.

In particular, the client may receive the media segment returned by the server using the same protocol as the protocol used for sending the media segment request, for example, when the client sends the media segment request using HTTP GET, the media segment may be received through an HTTP GET response message.

The parsing of the media segment is the reverse process of the media segment encapsulation, so the encapsulation protocol adopted by the server side is determined first, which can be agreed by the server side and the client side before the media stream is transmitted. For example, the server employs the following custom encapsulation protocol: the media segment is composed of a segment header and a segment payload, the segment payload is formed by cascading a plurality of media units, and the segment header indicates the initial position and the length of each media unit. At this time, for the client, the start position and length of each media unit may be obtained by the segment header first, and then each media unit may be parsed from the segment payload. When the media unit is an RTP packet, the sequence number and the generation time of each media unit can be obtained from the packet header of each RTP packet, and a media unit receiving report can be generated according to the sequence number and the generation time of the RTP packet successfully received.

In step S103, at least one pushed target media stream is received and parsed, where a media unit is parsed from the pushed target media stream, and a second reception report of the target media stream is generated.

For a media stream with a media unit being an RTP packet, the server may actively send the RTP packet to the client by using a UDP protocol, and the client may obtain the sequence number and the generation time of the media unit by analyzing the received RTP packet, and generate a second reception report of the target media stream.

In step S104, a new media segment request is generated according to the first reception report and the second reception report, wherein the control parameters carried by the new media segment request are determined.

Specifically, the client may obtain the receiving progress of the current real-time media stream through the first receiving report and the second receiving report, and in order to implement continuous receiving of the real-time media stream, the client generates a new media segment request. By adjusting the control parameters carried in the new media end request, the client controls the content of the media segment pulled next time, so as to ensure the receiving efficiency of the media stream.

The method can simultaneously support the pulling and pushing of the media stream, and when the media stream is pulled, the capability of acquiring the media segment according to the request of the client is realized, the expense and the time delay caused by adopting the list file are avoided, and the transmission efficiency of the media stream is improved.

It should be understood that the steps S101 to S104 are provided for convenience of description only and are not used to limit the execution order of the method, and in a specific implementation, the above steps may be executed as independent processing procedures.

In the following embodiments, a method for receiving a pushed target media stream by a client will be described.

Optionally, in an embodiment of the present invention, the client receives the pushed target media stream in an IP unicast or IP multicast manner.

In particular, in the existing Internet, in order to support access to media streams by large-scale users, a service provider generally uses a plurality of cache servers for establishing media streams in an area close to the users, or uses a distribution server provided by a CDN network operator, in addition to an origin server. From the source server, the cache server and the distribution server of these media streams, a corresponding pull server and push server may be allocated for each client. The pushed target media stream may come from any of the above servers that cache the target media stream. As shown in fig. 2, in one embodiment, the client 201 receives the target media streams from 4 servers simultaneously, including a pull server 202 and three push servers 203/204/205.

The push server 203 and the pull server 202 may be implemented in the same server node. For the pull server 202, the client may use HTTP-GET to obtain the requested media segment, and for the push server 203, the UDP/RTP protocol or the RTMP protocol may be directly used to push the media stream to the client, and the client receives the pushed media stream in an IP unicast manner. In this case, the client needs to agree with the server on the IP address and the receiving port number at which it receives the push media stream.

The push server 204 is used for multicast push, and can transmit the media stream to all the clients in a multicast group through an IP multicast protocol, and the clients receive the pushed media stream by using IP multicast. In this case, the client needs to agree with the server on the IP multicast address and the receiving port number at which it receives the push media stream.

The push server 205 is used for broadcast push, and may send the target media stream to the client through a broadcast network, such as an MBMS network in 3G/4G or a digital broadcast network such as DVB-C or DVB-T, and the client may receive the pushed media stream by using IP multicast or other methods (such as IPDC method in the digital broadcast network).

From the above embodiments, the method of the embodiments of the present invention may support a unicast/multicast/broadcast manner to receive the pushed target media stream, and the client receives the media stream by comprehensively using multiple approaches, thereby further improving the reliability of media stream transmission.

In the following embodiments, a description will be made of transmission of a media segment request.

Further, in one embodiment of the present invention, sending the media segment request to the server further comprises: if no media unit is received, sending an initial media segment request to the server; if a new media segment request has been generated from the reception report, the new media segment request is sent to the server.

It will be appreciated that when the client does not receive any media unit, an initial media segment request is sent to the server; after the client generates a new media segment request according to the media unit receiving report, the client sends the newly generated media segment request to the server, wherein the initial media segment request does not carry any second type of parameters or contains one of the following second type of parameters: start sequence number, number of units, start time, and segment duration.

Specifically, when the client does not receive any media unit, an initial media segment request is sent to the server; and after the client generates a new media segment request according to the media unit receiving report, immediately or at a specified time, sending the newly generated media segment request to the server.

Take RTP real-time streaming reception as an example. Initially, the client does not receive any media units, and the client can immediately send an initial media segment request. The initial media segment request may not carry any second type of parameters (such as req1 and req2 listed above), at which point the server may encapsulate a fixed number (e.g., 3) of RTP packets recently generated by the real-time media stream as media segments for return to the client, or encapsulate RTP packets generated by the real-time media stream within a last fixed time (e.g., 2 seconds) as media segments for return to the client. When the client receives the first media segment returned by the server, the client obtains the first receiving report of the media stream by analyzing the media segment, so that the client can know which media units are received currently, and then generates a new media segment request, including setting control parameters in the new media segment request, so as to ensure that the media units requested next time are required by the client. In order to control the duration of the next media segment, the client may send a newly generated media segment request to the server immediately or by delaying for a period of time.

Alternatively, the initial media segment request may include a second type of control parameter: the starting sequence number. The starting sequence number may then indicate from which sequence number the client desires to receive the media unit. The start sequence number is used to indicate the media unit from which the client desires to start; the value of the start sequence number may be arbitrarily specified, such as 0. For the server, the start sequence number may be valid, i.e. the sequence number of the most recently generated media unit, but when the start sequence number is invalid, the server automatically selects the default specified media unit to be encapsulated as a media segment.

Alternatively, the initial media segment request may include a second type of control parameter: the number of units. The number of units is used to indicate how many recently generated media units, e.g. 3, the client desires to receive.

Alternatively, the initial media segment request may include a second type of control parameter: the start time. The start time is used to indicate the point in time from which the client desires the media unit to start; the value of the start time may be arbitrarily specified, such as 0. The start time may be valid for the server, i.e. the start time, e.g. the generation time of the latest media unit, is within a specified range, or invalid. When the start time is invalid, the server will automatically select the default designated media unit to be packaged as a media segment.

Alternatively, the initial media segment request may include a second type of control parameter: the segment duration. The segment duration is used to indicate how recently the client desires to receive the media units generated.

Generally speaking, by sending the initial media segment request to the server, the client can obtain the latest media unit of the real-time media stream no matter whether the server carries the second type of control parameter or not, so as to know the generation progress of the current real-time media stream and provide conditions for generating a new media segment request.

In addition, when the client does not receive any media unit, the client can also know the generation condition of the real-time media stream according to the direct interaction with the server, for example, directly obtain the sequence number of the latest media unit of the real-time media stream, so that the second type of parameter in the initial media segment request can be set.

In the following embodiments, how a client generates a media segment request according to a reception report of a media stream will be described.

In specific implementation, the media unit may be parsed from either the received media segment or the pushed media stream, and the sequence number and/or the generation time corresponding to the media unit may be directly parsed from the data of the media unit or the header of the media segment, so as to generate a first receiving report or a second receiving report of the media stream. In other embodiments, the reception report may also include more content, such as other characteristics of the media unit, such as the size of the media unit, the time of reception of the media unit at the client, and so forth.

Further, in one embodiment of the present invention, generating a new media segment request based on the first reception report and the second reception report further comprises: and when the receiving of the pushed target media stream fails, generating a new media segment request according to the first receiving report, wherein if the second type of parameters carried by the new media segment request comprise a starting sequence number or a starting time, the value of the starting sequence number is the sequence number value of the latest media unit which is successfully received currently, and the value of the starting time is the generation time of the latest media unit which is successfully received currently.

Specifically, when receiving the pushed target media stream fails, it means that a transmission link from the push server to the client fails, the client cannot receive the pushed target media stream, and cannot generate the second reception report, and the client generates the new media segment request according to the first reception report. Here, for simplicity, it is assumed that the client receives the pulled media segments using the HTTP protocol and that the media units in the media segments are arranged in the generation order.

When the first reception report only contains the generation time of the media unit, the second type of parameter carried by the new media segment request includes the start time, and the value of the start time is the generation time of the latest media unit which is successfully received currently, the request means: the generation time of the candidate media units contained in the client's desired media segment should be after the start time.

When the first reception report contains the sequence numbers of the media units, the second type of parameter carried by the new media segment request includes a start sequence number, and the value of the start time is the start sequence number of the latest media unit which is successfully received currently, the request means: the sequence number of the candidate media units contained in the client's desired media segment follows the starting sequence number.

As an embodiment shown in fig. 3, taking RTP real-time stream reception as an example, each media unit is an RTP packet, and the sequence number of the media unit is the sequence number of the RTP packet. One media segment may encapsulate multiple RTP packets. When the client analyzes the RTP packet from the received media segment, the packet sequence number of the RTP packet can be obtained through the RTP packet header. When the client completely successfully receives a media segment MS2, a media unit reception report can be obtained by parsing the media segment, which is a list consisting of the sequence numbers of the successfully received media units: {21, 22, 23}, at this time, when the client generates a new media segment request, it may carry a second type of parameter: the starting sequence number. By the unit receiving the report, it can be known that the sequence number of the latest media unit is 23, and then the value of the start sequence number carried in the new media segment request is 23. For the server, when receiving the media segment request, the server encapsulates all existing media units with sequence numbers after 23 into new media segments and sends the new media segments to the client, and the client starts to analyze the media segments after receiving the fed-back media segments to generate a new media segment request and sends the new media segment request to the server. Fig. 3 shows the transmission process of the client continuously submitting the start sequence numbers.

It can be seen from the above embodiments that the server generates media segments according to the received media segment request and returns the media segments to the client, and controls the content and duration of the media segments according to the parameters carried in the request and the interval of the transmission request, and the media segments generated as needed can better adapt to the dynamic network transmission environment.

Further, in one embodiment of the present invention, generating a new media segment request based on the first reception report and the second reception report further comprises: determining the media units which are successfully received at the current time, determining the candidate media units which need to be pulled at the current time, and determining the second type parameters describing the range of the candidate media units.

Specifically, since the first receiving report and the second receiving report already include the serial number and/or the generation time of the media unit which is successfully received currently, the media unit which is successfully received currently can be obtained by summarizing the two receiving reports. On the other hand, once the candidate media units that need to be pulled at the current time are determined, suitable parameters of the second type, including: start sequence number, number of units, start time, segment duration, sequence number range, generation time range, and priority range. Two implementation methods will be given below for how to determine the candidate media units that need to be pulled at the current time.

Further, in an embodiment of the present invention, determining a candidate media unit that needs to be pulled at the current time further includes: setting a latest pushing and receiving time for each media unit to be received, wherein the candidate media units needing to be pulled at the current time comprise all or part of the media units which are not successfully received and have the latest pushing and receiving time before the current time.

Specifically, the pushed media stream received by the client comes from a certain push server. In general, to minimize latency, the push server pushes a media unit to the client immediately after the media unit is generated. When the link between the client and the server is in a normal state, the time when the media unit is pushed from the server to the client, i.e. the delivery delay of the media unit, is stable for a period of time, so that the delivery delay of the media unit from the server to the client is predictable, and therefore, a latest push receiving time can be set for each media unit to be received.

A method of setting the latest push reception time is briefly described below.

It is assumed that media units are generated periodically on the server side and that the size of the media units is comparable. At the client, the time of receipt is recorded for each pushed media unit received. Assuming that the receiving time of the media unit with sequence number i is TR (i), the receiving time of the media unit with sequence number i +1 is TR (i +1), and the receiving time of the media unit with sequence number k is TR (k), we can calculate the delay variation rate j (k) of each media unit from i +1 to k relative to the media unit with sequence number i:

J(i+1)＝(TR(i+1)-TR(i))/1；

J(i+2)＝(TR(i+2)-TR(i))/2；

……；

J(k)＝(TR(k)-TR(i))/(k-i)；

weighting the jitter rate to obtain an average delay change rate Jv in a time period:

Jv＝a(1)*J(i+1)+a(2)*J(i+2)+....+a(k-i)*J(k)；

wherein a (1) + a (2) +. + a (k-i) ═ 1;

taking this average delay variation rate Jv as the estimated values of J (k +1), J (k +2), … …, and J (k + m), the predicted value TRe of the reception time for the media unit with sequence number (k + m) is:

TRe(k+m)＝TR(i)+(k+m-i)*Jv；

the latest push reception time TRp of a media unit with sequence number (k + m) may be set as:

TRp(k+m)＝TRe(k+m)+T0；

wherein, T0 is to add an additional amount to the original prediction time to accommodate the delay jitter of the network.

Thus, whenever more than two pushed media units are received, a latest push reception time can be determined for the subsequent media units by the above formula.

When the client receives multiple pushed media streams simultaneously, the latest push reception time of a media unit may be calculated separately in each pushed media stream, and the maximum value thereof may be selected as the final value of the latest push reception time of the media unit.

The client can determine which unit has the latest push receiving time before the current time in all the media units which are not successfully received according to the first receiving report and the second receiving report of the media stream, and then select part or all of the units to pull according to needs. Wherein the following are encountered: the network transmission bandwidth is not enough, or the capacity of the receiving buffer is not enough, or some media units have no need to be pulled, and the client can only select part of the media units to pull.

As an embodiment shown in fig. 4, taking RTP real-time stream reception as an example, each media unit is an RTP packet, and the sequence number of the media unit is the sequence number of the RTP packet. The client receives the media stream in a push and pull manner at the same time. After receiving the pushed media units U20 and U21, the client may set the latest push receiving time of the media units to be received (U22, U23, U24, etc.), and when receiving the media unit U23, the client finds that the latest push receiving time of the media unit U22 is already out of time, and sends a media segment request to pull the media unit U22. The client side continuously receives the pushed media units (U23, U24, U25), the latest pull time of the media units to be received (U26, U27, U28 and the like) is set when the media unit U25 is received, and when the client side finds that the latest push receiving time of the media unit U26 is overtime, the client side initiates a media segment request to pull the media unit U26; when the client finds that the latest push receiving time of the media unit U27 is overtime, at this time, the client continues to wait because the pull of U26 has not been successful; when the client successfully receives the U26, and finds that the latest push receiving time of the media units U27 and U28 is overtime at this time, a media segment request is initiated to pull the U27 and U28.

It can be seen from the above implementation method that through cooperation of pulling and pushing, the client only needs to pull all or part of the media units that failed in pushing, which can reduce the processing overhead of the server and improve the reliability of media stream delivery.

Further, in an embodiment of the present invention, each media unit is associated with a priority, the pushed target media stream only contains media units with a specified priority range, and the candidate media units that need to be pulled at the current time include all or part of the media units with unsuccessfully received priorities that are not within the specified priority range.

Specifically, when the target media stream can be transmitted by two ways, i.e., push and pull, the push server and the pull server can be divided, for example, the push server is responsible for pushing the data with high priority to all the clients, and for the data with low priority, each client pulls the data according to the needs or network conditions. In this case, the client may receive the pushed media unit and the pulled media unit concurrently and merge them together to obtain the target media stream.

As shown in fig. 5, in an embodiment, the media units correspond to three priorities, the push server is responsible for pushing all the media units with priority 3 directly to the clients, for each client, only the media units with priority 1 and priority 2 need to be pulled, and the media segment request of the client carries two second-type control parameters: a starting sequence number and a priority range, wherein the priority range comprises: priority 1 and priority 2, the starting sequence number is: the latest sequence number value in the currently received media unit of priority 1 and priority 2. When the server receives the request, all the media units with the sequence numbers behind the initial sequence number and the priority of 1 or 2 in all the newly generated media units are taken as candidate media units, packaged into media segments and fed back to the client.

It can be seen from the above embodiments that the client can receive the target media stream by comprehensively using push and pull modes, thereby improving the transmission efficiency of the media stream.

According to the real-time receiving method of the media stream, two transmission modes of pulling and pushing are integrated at the same time. When the pull mode is adopted, the client sends a media segment request to the server, the server generates a media segment according to the received media segment request and returns the media segment to the client, the content and the duration of the media segment are controlled through parameters carried in the request and the interval of the request sending, and the media segment generated according to the requirement can better adapt to the dynamic network transmission environment. Because each media segment is generated by the request trigger of the client, the manifest file is not required any more, and the manifest file is not required to be requested and analyzed, on one hand, the latest media stream can be obtained more quickly, the transmission delay of the real-time media stream is reduced, on the other hand, the transmission overhead and the processing overhead brought by the manifest file are also reduced, and thus the transmission delay and the overhead are effectively reduced.

In addition, the client may also receive a pushed target media stream from one or more servers, and the pushed target media stream may include all or part of data of the target media stream, which may bring the following advantages: firstly, the pushed data can be transmitted by multicast/broadcast, and the client only needs to pull the media data which is not successfully pushed, so that the processing overhead and bandwidth overhead of the server are greatly reduced, and the transmission efficiency of the media stream is improved; secondly, the pull channel and the plurality of push channels can be used simultaneously, and even if one channel fails, the client can acquire the media stream from other channels, so that the reliability of media stream transmission is improved; and thirdly, the client can select the pulled media data by itself to adapt to the change of the network bandwidth, for example, the server pushes the basic media data with higher priority to all the clients, and each client determines whether to pull other low-priority data according to the condition of the respective access bandwidth.

Next, a real-time receiving client of a media stream proposed according to an embodiment of the present invention is described with reference to the drawings.

Fig. 6 is a schematic structural diagram of a real-time receiving client of a media stream according to an embodiment of the present invention.

As shown in fig. 6, the real-time receiving client 10 of the media stream includes: a media stream pulling component 120, a push media stream receiving component 121 and a media stream transmission control component 122.

Wherein a media stream is a sequence of media units generated in real time, each media unit being associated with a generation time and/or a sequence number indicating the order of generation. Specifically, the media stream pulling component 120 is configured to send a media segment request to the server, and receive and analyze a media segment fed back by the server, where the media segment request does not carry or carry at least one control parameter, and the control parameter includes a first type parameter indicating a target media stream to be transmitted and a second type parameter indicating a candidate media unit to be transmitted, and analyzing the media segment includes: and resolving the media unit from the media segment and generating a first receiving report of the target media stream. The pushed media stream receiving component 121 is configured to receive and parse at least one pushed target media stream, where a media unit is parsed from the pushed target media stream, and a second receiving report of the target media stream is generated. The media streaming control component 122 is configured to generate a new media segment request according to the first reception report and the second reception report, wherein a control parameter carried by the new media segment request is determined. The client 10 of the embodiment of the present invention can integrate two transmission modes of pulling and pushing at the same time, when pulling is adopted, a media segment request is continuously sent to the server, the server generates a media segment according to the received media segment request and returns the media segment to the client, and the content and duration of the media segment are controlled by the parameters carried in the request and the interval of the sending request, so as to effectively reduce transmission delay and overhead.

In one embodiment of the invention, the media stream pull component 120 may send media segment requests and receive media segments back using the HTTP protocol. That is, for the client, the media stream pulling component 120 may employ any network transport protocol to send the media segment request and receive the server-returned media segments, such as UDP, RTP, QUIC, TCP, HTTP and the like. When the server interface component submits the media segment request and receives the media segment returned by the server by adopting the HTTP protocol, the server interface component comprises the functions of the HTTP client: the parameters of the media segment request may be encapsulated as a string as part of the URL of the HTTP GET, and the server-generated media segment may be encapsulated into a response message of the HTTP GET and returned to the client.

In the following embodiments, a method for a client to receive a real-time media stream will be described.

In one embodiment of the present invention, the real-time media stream can be played while being received, and in order to support the above functions, a media stream playback component 123 can be introduced on the basis of the existing components, and the received media units are played back in real time by the media stream playback component 123, as shown in fig. 7:

in a particular implementation, the functionality of the media stream playback component 123 can comprise a plurality of processing steps. Taking the media unit as an RTP packet as an example, in order to complete playing of the RTP packet, the media stream playback component 123 first needs to decapsulate the RTP packet, recover the media frame from the RTP payload, and if the media frame is compressed, decompress the media frame, and play the original code stream obtained after decompression.

Further, in one embodiment of the present invention, the media stream pulling component 120 is further configured to send an initial media segment request to the server when no media unit is received; when a new media segment request has been generated from the reception report, the new media segment request is sent to the server.

Optionally, in one embodiment of the present invention, the first reception report and the second reception report contain the serial number and/or the generation time of the media unit that is currently successfully received.

Further, in an embodiment of the present invention, the media streaming control component 122 is further configured to generate a new media segment request according to the first reception report when the receiving of the pushed target media stream fails, wherein if the second type parameter carried by the new media segment request includes a start sequence number or a start time, a value of the start sequence number is a sequence number value of a latest media unit that is currently successfully received, and a value of the start time is a generation time of the latest media unit that is currently successfully received.

Further, in an embodiment of the present invention, the media streaming control component 122 is further configured to determine a media unit that has been successfully received at the current time, determine a candidate media unit that needs to be pulled at the current time, and determine a second type parameter describing a range of the candidate media unit.

Further, in an embodiment of the present invention, the media streaming control component 122 is further configured to set a latest push reception time for each media unit to be received, and the candidate media units that need to be pulled at the current time include all or part of the media units that were not successfully received before the current time by the latest push reception time.

It should be noted that the foregoing explanation on the embodiment of the real-time receiving method for a media stream is also applicable to the real-time receiving client for a media stream in this embodiment, and details are not described here again.

According to the embodiment of the invention, the client side for receiving the media stream in real time integrates two transmission modes of pulling and pushing. When the pull mode is adopted, the media segment request is continuously sent to the server, the server generates the media segment according to the received media segment request and returns the media segment to the client, the content and the duration of the media segment are controlled through the parameters carried in the request and the interval of the sending request, the media segment generated according to the requirement can better adapt to the dynamic network transmission environment, and because each media segment is triggered by the request of the client, a list file is not needed any more, and the list file is not needed to be requested and analyzed, on one hand, the latest media stream can be obtained more quickly, the transmission delay of the real-time media stream is reduced, on the other hand, the transmission overhead and the processing overhead brought by the list file are also reduced, so that the transmission delay and the overhead are effectively reduced, and the transmission performance of the real-time media stream is further improved.

In addition, the real-time receiving client of the media stream in the embodiment of the present invention may also receive a pushed target media stream from one or more servers, where the pushed target media stream may include all data or part of data of the target media stream. This may provide the following benefits: firstly, the pushed data can be transmitted by multicast/broadcast, so that the client only needs to pull the media data which is not successfully pushed, the processing overhead and bandwidth overhead of the server are greatly reduced, and the transmission efficiency of the media stream is improved; secondly, the pull channel and the plurality of push channels can be used simultaneously, and even if one channel fails, the client can acquire the media stream from other channels, so that the reliability of media stream transmission is improved; and thirdly, the client can select the pulled media data by itself to adapt to the change of the network bandwidth, for example, the server pushes the basic media data with higher priority to all the clients, and each client determines whether to pull other low-priority data according to the condition of the respective access bandwidth.

In order to implement the foregoing embodiments, an embodiment of the present invention further provides a computer device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, and when the processor executes the computer program, the real-time receiving method of the media stream described in the foregoing embodiments is implemented.

In order to implement the foregoing embodiments, the present invention further provides a non-transitory computer readable storage medium, and the program is executed by a processor to implement the real-time receiving method of the media stream as described in the foregoing embodiments.

In order to implement the above embodiments, an embodiment of the present invention further provides a computer program product, and when instructions in the computer program product are executed by a processor, the real-time receiving method of a media stream as described in the above embodiments is performed.

Furthermore, the terms "first", "second" and "first" are used for descriptive purposes only and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In the description of the present invention, "a plurality" means at least two, e.g., two, three, etc., unless specifically limited otherwise.

In the present invention, unless otherwise expressly stated or limited, the terms "mounted," "connected," "secured," and the like are to be construed broadly and can, for example, be fixedly connected, detachably connected, or integrally formed; can be mechanically or electrically connected; they may be directly connected or indirectly connected through intervening media, or they may be connected internally or in any other suitable relationship, unless expressly stated otherwise. The specific meanings of the above terms in the present invention can be understood by those skilled in the art according to specific situations.

In the present invention, unless otherwise expressly stated or limited, the first feature "on" or "under" the second feature may be directly contacting the first and second features or indirectly contacting the first and second features through an intermediate. Also, a first feature "on," "over," and "above" a second feature may be directly or diagonally above the second feature, or may simply indicate that the first feature is at a higher level than the second feature. A first feature being "under," "below," and "beneath" a second feature may be directly under or obliquely under the first feature, or may simply mean that the first feature is at a lesser elevation than the second feature.

In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above are not necessarily intended to refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, various embodiments or examples and features of different embodiments or examples described in this specification can be combined and combined by one skilled in the art without contradiction.

Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention, and that variations, modifications, substitutions and alterations can be made to the above embodiments by those of ordinary skill in the art within the scope of the present invention.

Claims

1. A real-time receiving method of a media stream, wherein the media stream is a sequence of media units generated in real-time, each media unit being associated with a generation time and/or a sequence number indicating a generation order, and wherein the method comprises:

sending a media segment request to a server, wherein the media segment request does not carry or carries at least one control parameter, and the control parameter comprises a first type parameter indicating a target media stream to be transmitted and a second type parameter indicating a candidate media unit to be transmitted;

receiving and analyzing the media segments fed back by the server, analyzing media units from the media segments, and generating a first receiving report of a target media stream;

receiving and analyzing at least one path of pushed target media stream, wherein a media unit is analyzed from the pushed target media stream, and a second receiving report of the target media stream is generated; and

and generating a new media segment request according to the first receiving report and the second receiving report, wherein the control parameters carried by the new media segment request are determined.

2. The method of claim 1, wherein the client receives the pushed target media stream by using IP unicast or IP multicast.

3. The real-time receiving method of a media stream according to claim 1, wherein the sending a media segment request to a server further comprises:

if no media unit is received, sending an initial media segment request to the server;

and if the new media segment request is generated according to the receiving report, sending the new media segment request to the server.

4. The method of claim 1, wherein the second type of parameter comprises one or more of a start sequence number, a number of units, a start time, a segment duration, a sequence number range, a generation time range, and a priority range.

5. The method of claim 1, wherein the first reception report and the second reception report contain the sequence number and/or generation time of the media unit that is successfully received currently.

6. The real-time receiving method of a media stream according to claim 5, wherein the generating a new media segment request according to the first reception report and the second reception report further comprises:

and when the pushed target media stream fails to be received, generating the new media segment request according to the first receiving report, wherein if the second type of parameters carried by the new media segment request comprise a starting sequence number or starting time, the value of the starting sequence number is the sequence number value of the latest media unit which is successfully received currently, and the value of the starting time is the generation time of the latest media unit which is successfully received currently.

7. The real-time receiving method of a media stream according to claim 5, wherein the generating a new media segment request according to the first reception report and the second reception report further comprises:

determining the media units which are successfully received at the current time, determining the candidate media units which need to be pulled at the current time, and determining the second type parameters describing the range of the candidate media units.

8. The method of claim 7, wherein the determining the candidate media units that need to be pulled at the current time further comprises:

setting a latest push receiving time for each media unit to be received, wherein the candidate media units needing to be pulled at the current time comprise all or part of the media units which are not successfully received and are before the current time at the latest push receiving time.

9. The method as claimed in claim 7, wherein each media unit is associated with a priority, the pushed target media stream contains only media units with a specified priority range, and the candidate media units that need to be pulled at the current time include all or some of the media units with priorities not within the specified priority range that have not been successfully received.

10. A client for receiving a media stream in real time, wherein the media stream is a sequence of media units generated in real time, each media unit being associated with a generation time and/or a sequence number indicating a generation order, and wherein the client comprises:

a media stream pulling component, configured to send a media segment request to a server, and receive and analyze a media segment fed back by the server, where the media segment request does not carry or carry at least one control parameter, and the control parameter includes a first type parameter indicating a target media stream to be transmitted and a second type parameter indicating a candidate media unit to be transmitted, and the analyzing the media segment includes: analyzing a media unit from the media segment and generating a first receiving report of a target media stream;

the pushed media stream receiving component is used for receiving and analyzing at least one path of pushed target media stream, wherein a media unit is analyzed from the pushed target media stream, and a second receiving report of the target media stream is generated;

and the media stream transmission control component is used for generating a new media segment request according to the first receiving report and the second receiving report, wherein the control parameter carried by the new media segment request is determined.

11. The client of claim 10, wherein the client receives the pushed target media stream by using IP unicast or IP multicast.

12. The real-time receiving client of a media stream according to claim 10, wherein the media stream pulling component is further configured to send an initial media segment request to the server when no media unit is received; and when the new media segment request is generated according to the receiving report, sending the new media segment request to the server.

13. The client of claim 10, wherein the second type of parameters includes one or more of a start sequence number, a number of units, a start time, a segment duration, a sequence number range, a generation time range, and a priority range.

14. The client of claim 10, wherein the first reception report and the second reception report contain the sequence number and/or generation time of the media unit that is successfully received currently.

15. The real-time receiving client of a media stream according to claim 14, wherein the media stream transmission control component is further configured to generate the new media segment request according to the first reception report when the receiving of the pushed target media stream fails, wherein if the second type parameter carried by the new media segment request includes a start sequence number or a start time, a value of the start sequence number is a sequence number value of a latest media unit that is currently successfully received, and a value of the start time is a generation time of the latest media unit that is currently successfully received.

16. The real-time receiving client of media stream according to claim 14, wherein the media streaming control component is further configured to determine a media unit that has been successfully received at the current time, determine a candidate media unit that needs to be pulled at the current time, and determine a second type parameter describing a range of the candidate media unit.

17. The real-time receiving client of media stream according to claim 16, wherein the media streaming control component is further configured to set a latest push reception time for each media unit to be received, and wherein the candidate media units that need to be pulled at the current time include all or some of the media units that were not successfully received before the current time by the latest push reception time.

18. The client of claim 16, wherein each media unit is associated with a priority, the pushed target media stream contains only media units with a specified priority range, and the candidate media units that need to be pulled at the current time include all or some of the media units with priorities not within the specified priority range that have not been successfully received.

19. A computer device comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein the processor when executing the program implements the method of any one of claims 1-9.

20. A non-transitory computer-readable storage medium, on which a computer program is stored, which, when executed by a processor, implements the method of any one of claims 1-9.

21. A computer program product in which instructions, when executed by a processor, perform the method of any one of claims 1-9.