WO2020048268A1 - 媒体流的实时递送方法、实时接收方法、服务器及客户端 - Google Patents

媒体流的实时递送方法、实时接收方法、服务器及客户端 Download PDF

Info

Publication number
WO2020048268A1
WO2020048268A1 PCT/CN2019/098871 CN2019098871W WO2020048268A1 WO 2020048268 A1 WO2020048268 A1 WO 2020048268A1 CN 2019098871 W CN2019098871 W CN 2019098871W WO 2020048268 A1 WO2020048268 A1 WO 2020048268A1
Authority
WO
WIPO (PCT)
Prior art keywords
media
time
media stream
segment
unit
Prior art date
Application number
PCT/CN2019/098871
Other languages
English (en)
French (fr)
Inventor
姜红旗
Original Assignee
北京开广信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from CN201811033268.XA external-priority patent/CN110881018B/zh
Priority claimed from CN201811032231.5A external-priority patent/CN110545492B/zh
Application filed by 北京开广信息技术有限公司 filed Critical 北京开广信息技术有限公司
Publication of WO2020048268A1 publication Critical patent/WO2020048268A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests

Definitions

  • the present application relates to the technical field of digital information transmission, and in particular, to a real-time delivery method, a real-time reception method, a server, and a client of a media stream.
  • RTP Real-time Transport Protocol
  • RTSP Real-Time Streaming Protocol
  • RTMP Real-Time Messaging Protocol
  • HTTP HyperText Transfer Protocol
  • HAS Hyper Stream Transfer Protocol
  • HTTP adaptive streaming includes multiple solutions: HLS (HTTP Live Streaming) proposed by Apple, Smooth Streaming proposed by Microsoft, HTTP Dynamic Streaming (HDS) proposed by Adobe, and DASH (Dynamic Adaptive) proposed by MPEG. Streaming over HTTP, HTTP-based dynamic adaptive streaming).
  • HLS HTTP Live Streaming
  • HDS HTTP Dynamic Streaming
  • DASH Dynamic Adaptive
  • the common feature of these HTTP adaptive streaming schemes is that the media stream is cut into short-term (2s-10s) media fragments, and an index file or a manifest file (such as the m3u8 playlist and MPD file in DASH), and then save it to each Web server.
  • the client obtains the URL (Uniform Resource Locator, Uniform Resource Locator) access address of these media clips by accessing the playlist or manifest file, and then can use the standard HTTP protocol to download these media clips one by one and play them.
  • the main difference between these solutions is the difference between the package format and the manifest file format used by the media clips.
  • HTTP adaptive streaming can make full use of existing Internet Web cache facilities (such as CDN and various Web cache servers), and can support large-scale user access.
  • existing Internet Web cache facilities such as CDN and various Web cache servers
  • HTTP adaptive streaming has become the mainstream method for real-time streaming media delivery on the Internet.
  • the length of the media segment cannot adapt to the dynamically changing network transmission.
  • the current HAS schemes use a pre-segmentation method, that is, the server generates a media segment and its manifest file according to a preset duration and submits it to the web server.
  • setting a large fragment duration means increasing the delay of real-time transmission; when the network transmission bandwidth is insufficient and the delay is large, setting a small fragment duration means frequent file requests , Increase the burden on the server and network transmission overhead. Because the transmission bandwidth and transmission delay on the Internet are dynamically changed, a fixed-length pre-segmentation method cannot achieve optimal transmission.
  • the manifest file adds transmission delay and overhead.
  • the client needs to get the manifest file first to get the URL of the media clip.
  • the manifest file takes a period of time to be transmitted to the client, the manifest file obtained by the client cannot reflect the current generation of the latest media fragments.
  • the manifest file is blocked or the transmission error occurs, the user will be blocked Quick access to media clips, reducing the performance of real-time streaming media delivery.
  • This application is intended to solve at least one of the technical problems in the related technology.
  • the first purpose of this application is to propose a method for real-time delivery of media streams, which can effectively reduce the delay and overhead of media stream transmission and further improve the transmission performance of real-time media streams.
  • the second purpose of this application is to propose a real-time receiving method for media streams.
  • a third object of the present application is to provide a real-time delivery server for media streams.
  • the fourth purpose of this application is to propose a real-time receiving client for media streams.
  • a fifth object of the present application is to propose a computer device.
  • a sixth object of the present application is to propose a non-transitory computer-readable storage medium.
  • a seventh object of the present application is to propose a computer program product.
  • an embodiment of the first aspect of the present application proposes a method for real-time delivery of a media stream, where the media stream is a sequence of media units generated in real time, wherein each media unit is associated with a generation time and / or A sequence number indicating a generation sequence.
  • the method includes the following steps: receiving a media segment request sent by a client, wherein the media segment request does not carry or carry at least one control parameter, and the control parameter includes an indication of a target media stream to be transmitted.
  • a first type of parameter and a second type of parameter indicating a candidate media unit to be transmitted generating a media segment according to the media segment request, wherein the target media stream to be transmitted is determined according to the first type of parameter, and
  • the second type of parameter determines the candidate media unit to be transmitted, and encapsulates the candidate media unit to be transmitted into the media segment; and sends the media segment to the client.
  • the method for real-time delivery of a media stream in the embodiment of the present application generates a media segment in real time according to a client's request and returns it to the client to implement real-time media stream segmentation according to the client's needs.
  • the length of the media segment will be automatically adapted.
  • the network transmission bandwidth changes.
  • the client can control the length of the media segment by actively requesting it. Since each media segment is triggered by the client's request, the manifest file is no longer needed, and the client does not need to request and parse the manifest file.
  • the client can obtain the latest media stream faster, reducing the transmission delay of the real-time media stream, on the other hand, it also reduces the transmission overhead and processing overhead brought by the manifest file, thereby effectively reducing the media stream transmission delay. Time and overhead, further improving the transmission performance of real-time media streams.
  • the method for real-time delivery of a media stream may also have the following additional technical features:
  • the generating a media segment according to the media segment request further includes: if the media segment request does not carry the first type of parameter, the target media to be transmitted The stream is a media stream designated by default; if the second segment parameter is not carried in the media segment request, the candidate media unit includes a media unit designated by default, and the media unit designated by default is The media units in which the sequence numbers of all and the latest media units in the target media stream are smaller than a first preset value, or the media units in which the generation interval of all and the latest media units in the target media stream is less than a second preset value.
  • the candidate media unit to be transmitted includes all media units in the target media stream that simultaneously satisfy all constraint conditions corresponding to the second type of parameters.
  • the second type of parameter includes a starting sequence number
  • the constraint condition corresponding to the starting sequence number is: if the starting sequence number is valid, the sequence number of the candidate media unit After the starting sequence number, or equal to the starting sequence number.
  • the second type of parameter includes a start time
  • the constraint condition corresponding to the start time is: if the start time is valid, the generation time of the candidate unit After the start time.
  • the second type of parameters includes the number of units, and the constraint condition corresponding to the number of units is: if the number of units is valid, the The number does not exceed the number of units; further, if other second-type parameters carried in the media segment request do not limit the range of candidate media units, the sequence number interval between the candidate media unit and the latest media unit is smaller than the number of units number.
  • the second type of parameter includes a segment duration
  • a constraint condition corresponding to the segment duration is: if the segment duration is valid, the candidate media unit includes The generation interval between the earliest generated unit and the latest generated unit is less than the segment duration; further, if other second-type parameters carried in the media segment request do not limit the range of candidate media units, the candidate media units The generation time interval with the latest media unit is less than the segment duration.
  • the first type of parameter includes a media stream identifier to specify the target media stream to be transmitted.
  • the encapsulating the candidate media unit to be transmitted into the media segment further includes: obtaining media stream index information, and encapsulating the media stream index information into all media segments.
  • the media stream index information includes multiple media stream description information belonging to the same content
  • the media stream description information includes a media stream identifier and a media stream bit rate.
  • an embodiment of the second aspect of the present application provides a method 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 A sequence number indicating the generation sequence, the method includes: sending a media segment request to a server, the media segment request does not carry or carry at least one control parameter, and the control parameter includes a first type of parameter and an indication indicating a target media stream to be transmitted The second type of parameters of the candidate media unit to be transmitted; receiving a media segment fed back by the server, wherein the media segment is generated by the server according to the media segment request and encapsulates a candidate specifying the target media stream Media unit; parsing the media segment, wherein the media unit is parsed out according to the media segment and a reception report of the media unit is generated; and a new media segment request is generated according to the reception report of the media unit, wherein The control parameters carried in the new media segment request are described.
  • the server by continuously sending a media segment request to a server, the server generates a media segment according to the received media segment request and returns it to the client, and uses the parameters carried in the request and the interval between sending requests
  • the server uses the parameters carried in the request and the interval between sending requests
  • To control the content and duration of media segments, and media segments generated on demand can better adapt to the dynamic network transmission environment. Since each media segment is triggered by a client request, there is no longer a need for a manifest file, and no Parsing the manifest file, on the one hand, can get the latest media stream faster, reducing the transmission delay of the real-time media stream, on the other hand, it also reduces the transmission overhead and processing overhead brought by the manifest file, thereby effectively reducing the transmission delay. And overhead, further improving the transmission performance of real-time media streams.
  • an embodiment of the third aspect of the present application proposes a real-time delivery server for a media stream, where the media stream is a sequence of media units generated in real time, wherein each media unit is associated with a generation time and / or A sequence number indicating a generation sequence
  • the server includes: a client interface component, configured to receive a media segment request sent by a client and return a corresponding media segment, wherein the media segment request does not carry or carry at least one control parameter,
  • the control parameters include a first type of parameter indicating a target media stream to be transmitted and a second type of parameter indicating a candidate media unit to be transmitted;
  • a media segment generating component generates a media segment according to the media segment request, wherein according to the media segment request,
  • the first type of parameters determines the target media stream to be transmitted, the candidate media units to be transmitted are determined according to the second type of parameters, and the candidate media units to be transmitted are encapsulated into the media segment, and passed
  • the client interface component sends the media segment to
  • the real-time delivery server for the media stream in the embodiment of the present application generates a media segment in real time according to the client's request and returns it to the client to implement real-time media stream delivery segmented according to the client's needs.
  • the length of the media segment will be automatically adapted.
  • the network transmission bandwidth changes.
  • the client can control the length of the media segment by actively requesting it. Since each media segment is triggered by the client's request, the manifest file is no longer needed, and the client does not need to request and parse the manifest file.
  • the client can obtain the latest media stream faster, reducing the transmission delay of the real-time media stream, on the other hand, it also reduces the transmission overhead and processing overhead brought by the manifest file, thereby effectively reducing the media stream transmission delay. Time and overhead, further improving the transmission performance of real-time media streams.
  • the real-time delivery server for media streams may also have the following additional technical features:
  • the media segment generating component is further configured to: when the media segment request does not carry the first type of parameter, the target media stream to be transmitted is a default designated When the media stream does not carry the second type of parameter in the media segment request, the candidate media unit includes a media unit designated by default, and the media unit designated by default is the target media stream
  • the sequence interval of all and latest media units is smaller than the first preset value, or is the media unit in which the generation interval of all and latest media units in the target media stream is smaller than the second preset value.
  • the candidate media unit to be transmitted includes all media units in the target media stream that simultaneously satisfy all constraint conditions corresponding to the second type of parameters.
  • the second type of parameter includes a starting sequence number
  • the constraint condition corresponding to the starting sequence number is: if the starting sequence number is valid, the sequence number of the candidate media unit After the starting sequence number, or equal to the starting sequence number.
  • the second type of parameter includes a start time
  • the constraint condition corresponding to the start time is: if the start time is valid, the generation time of the candidate unit After the start time.
  • the second type of parameters includes the number of units, and the constraint condition corresponding to the number of units is: if the number of units is valid, the The number does not exceed the number of units; further, if other second-type parameters carried in the media segment request do not limit the range of candidate media units, the sequence number interval between the candidate media unit and the latest media unit is smaller than the number of units number.
  • the second type of parameter includes a segment duration
  • a constraint condition corresponding to the segment duration is: if the segment duration is valid, the candidate media unit includes The generation interval between the earliest generated unit and the latest generated unit is less than the segment duration; further, if other second-type parameters carried in the media segment request do not limit the range of candidate media units, the candidate media units The generation time interval with the latest media unit is less than the segment duration.
  • the first type of parameter includes a media stream identifier to specify the target media stream to be transmitted.
  • the media segment generation component is further configured to obtain media stream index information and encapsulate the media stream index information into the media segment, wherein the media stream The index information includes multiple media stream description information belonging to the same content, and the media stream description information includes a media stream identifier and a media stream bit rate.
  • the method further includes: at least one real-time media stream generating component, configured to generate or receive one or more real-time media streams from other devices by itself.
  • an embodiment of the fourth aspect of the present application proposes a real-time receiving client 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.
  • the client includes a server interface component for sending a media segment request to the server.
  • the media segment request does not carry or carry at least one control parameter, and the control parameter includes an indication of a target media to be transmitted.
  • the client receiving a media stream in real time continuously sends a media segment request to the server, and the server generates a media segment according to the received media segment request and returns it to the client. Interval to control the content and duration of media segments.
  • On-demand generated media segments can better adapt to the dynamic network transmission environment. Since each media segment is triggered by a client's request, there is no longer a need for a manifest file or a request. And parsing the manifest file, on the one hand, you can get the latest media stream faster, reduce the transmission delay of the real-time media stream, and on the other hand, reduce the transmission and processing overhead caused by the manifest file, thereby effectively reducing the transmission delay. Time and overhead, further improving the transmission performance of real-time media streams.
  • an embodiment of the fifth aspect of the present application provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the processor executes the program, A method for real-time delivery of a media stream as described in the above embodiment, or a method for real-time reception of a media stream as described in the above embodiment is implemented.
  • the embodiment of the sixth aspect of the present application proposes a non-transitory computer-readable storage medium, and when the program is executed by a processor, the method for real-time delivery of a media stream as described in the foregoing embodiment is implemented, or as described above.
  • the example describes a method for receiving a media stream in real time.
  • an embodiment of the seventh aspect of the present application proposes a computer program product.
  • the instructions in the computer program product are executed by a processor, the method for real-time delivery of a media stream as described in the foregoing embodiment is performed, or A method for receiving a media stream in real time as described in the above embodiment.
  • FIG. 1 is a flowchart of a method for real-time delivery of a media stream according to an embodiment of the present application
  • FIG. 2 is a schematic diagram of a real-time transmission process of a client continuously submitting a media segment request according to an embodiment of the present application
  • FIG. 3 is a flowchart of a method for receiving a media stream in real time according to an embodiment of the present application
  • FIG. 4 is a schematic diagram of a real-time transmission process of a client continuously submitting a media segment request carrying a starting sequence number according to an embodiment of the present application
  • FIG. 5 is a schematic structural diagram of a real-time delivery server for media streams according to an embodiment of the present application
  • FIG. 6 is a schematic structural diagram of a real-time delivery server for media streams according to a specific embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of a real-time receiving client for a media stream according to an embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of a real-time receiving client for media streams according to a specific embodiment of the present application.
  • the transmission process of the media stream can be described by a general client-server model: the media stream generated in real time is delivered by the server to the client.
  • the server and client here refer to logical functional entities, where the server is a functional entity that sends media streams and the client is a functional entity that receives media streams. Servers and clients can exist on any network node.
  • Each transmitted media stream is a sequence of media units generated in real time.
  • the corresponding media units of different media streams can be selected by themselves.
  • the media stream is a byte stream generated in real time, one byte can be selected as the media unit;
  • the media stream is an audio stream or video stream obtained through real-time sampling, the original audio frame or video frame can be selected as the media Unit;
  • the media stream is a real-time sampled and encoded audio stream or video stream, you can choose the encoded audio frame, encoded video frame, or Access Unit as the media unit;
  • the media stream is a
  • real-time sampling, encoding, and packaging of audio or video streams you can choose the encapsulated transmission packet (such as RTP packets, PES / PS / TS packets, etc.) as the media unit;
  • the media stream is a real-time sampling, encoding, and packaging
  • pre-segmented audio or video streams you can select a segmented media segment (such as the TS format segment used in the
  • Each media unit can be associated with a generation time, which is usually a time stamp.
  • Each media unit can also be associated with a serial number, which can be used to indicate the order in which the media units were generated. When the serial number is used to indicate the order in which the media unit is generated, the meaning of the serial number needs to be defined according to the specific media unit.
  • the serial number of the media unit is the byte serial number; when the media unit is an audio frame or a video frame, the serial number of the media unit is the frame serial number; when the media unit is a transmission packet, the serial number of the media unit Is the packet sequence number; when the media unit is a stream segment, the sequence number of the media unit is the segment sequence number (such as the Media Sequence of each TS segment in the HLS).
  • a sequence number indicating the generation sequence and a generation time can be associated at the same time.
  • the RTP header has an existing sequence number (Sequence Number) field to indicate the RTP packet.
  • Sequence Number Sequence Number
  • Timestramp field to indicate the generation time of the media data encapsulated in the RTP.
  • multiple consecutive RTP packets may correspond to the same generation time, but their sequence numbers are unique.
  • the method in the embodiment of the present application can be implemented for any kind of real-time media stream.
  • the embodiments of the present application will respectively select an RTP real-time media stream or an MPEG2-TS real-time media stream to explain the implementation method of the embodiments of the present application.
  • the media unit is an RTP packet.
  • the sequence number of the RTP packet is selected as the sequence number of the media unit.
  • the packet sequence number of the RTP packet is a 16-bit field with a maximum value of 65535.
  • For continuously generated RTP The sequence number of the packet is cyclically counted. If the sequence number of the current packet is Seq, the sequence number of the next packet is (Seq + 1)% 65536.
  • the sequence number is subject to its bit length in practice.
  • the generation time of the media unit can be used to determine whether the serial number has a circular count, so as to accurately determine the sequential relationship between the serial numbers of the two media units and the interval between them.
  • Each TS segment can include multiple media frames, and then divide these segments into The sequence number is generated.
  • the time stamp of the first media frame contained in each segment indicates the generation time of the segment.
  • a server push method is used: once there is a new media unit on the server, it is actively sent to the client.
  • the method in the embodiment of the present application is similar to various HTTP adaptive streams (such as HLS, smooth stream, MPEG-DASH), and adopts a client pull method, but the difference lies in the existing various HTTP adaptive streams.
  • the client requests or pulls the segmented segments according to the manifest file, and each segment can be identified by a URL.
  • the media segment is not pre-segmented, but the server according to the client The request from the client is generated instantly, and the client can control the content and duration of the media segment.
  • FIG. 1 is a flowchart of a method for real-time delivery of a media stream according to an embodiment of the present application.
  • the method for real-time delivery of a media stream is a sequence of media units generated in real time. Each media unit is associated with a generation time and / or a serial number indicating a generation sequence.
  • the method includes the following steps: :
  • step S101 a media segment request sent by a client is received, wherein the media segment request does not carry or carry at least one control parameter, and the control parameter includes a first type of parameter indicating a target media stream to be transmitted and a candidate indicating to be transmitted The second type of parameters of the media unit.
  • the media segment request may not carry any of the first type parameters and the second type parameters, and new parameters may be defined according to the needs of further implementation.
  • the control parameters that can be used as the first type parameters include: media stream identifier, Media stream names, etc.
  • the control parameters that can be used as the second type of parameters include: start sequence number, start time, number of units, segment duration, etc.
  • Media segment requests can be submitted using any protocol, such as the common HTTP, TCP, and UDP protocols.
  • HTTP protocol such as the common HTTP, TCP, and UDP protocols.
  • HTTP-GET or HTTP-POST method can also be used.
  • control parameters need to be encapsulated into a string or byte stream in a certain way and sent to the server.
  • the control parameters can be encapsulated into a URL as a string.
  • HTTP-GET An example of a media segment request using HTTP-GET is as follows:
  • the parameter names streamID, seqBegin, timeBegin, unitCount, and segDuration respectively represent the media stream identifier, starting sequence number, starting time, unit number, and segment duration.
  • the server can use a web server to receive the media segment request from the client, extract the corresponding control parameters from the requested URL, and classify the control parameters: if it is a media stream identifier, this parameter is the first type of parameter; If it is the start sequence number, start time, number of units, and segment duration, it is the second type of parameter.
  • a media segment is generated according to the media segment request, wherein a target media stream to be transmitted is determined according to the first type of parameters, a candidate media unit to be transmitted is determined according to the second type of parameters, and the candidate media unit to be transmitted is encapsulated.
  • a target media stream to be transmitted is determined according to the first type of parameters
  • a candidate media unit to be transmitted is determined according to the second type of parameters
  • the candidate media unit to be transmitted is encapsulated.
  • the server can obtain the control parameters carried in the media segment request, and then can determine the target media stream to be transmitted according to the first type of parameters therein, and determine the second type of parameters carried by the server.
  • the candidate media units to be transmitted are finally encapsulated into media segments.
  • one or more media units can be encapsulated into media segments by using a custom encapsulation protocol.
  • a simple encapsulation protocol is as follows: a media segment is composed of a segment header and a segment payload, and the segment payload is formed by concatenating several media units.
  • the header indicates the starting position and length of each media unit.
  • step S103 the media segment is sent to the client.
  • the server can select an appropriate method to send the media segment to the client according to the protocol used by the client's media segment request. For example, when the received media segment request uses the HTTP GET method, it can be sent through an HTTP GET response message. Generated media segment: Put the media segment into the entity body of the HTTP response message.
  • the server When the server receives continuous media segment requests from the client, the server will continuously generate new media segments according to the client's request. These new media segments encapsulate several recently generated media units, and the client parses these media segments. The media units of the real-time media stream can be recovered, and the real-time transmission of the media stream from the server to the client is realized. This process is shown in FIG. 2.
  • the method of the embodiment of the present application no longer needs a manifest file, thereby reducing transmission delay and saving overhead.
  • the client can adjust the frequency of sending requests to control the length of the media segment to better adapt to changes in network bandwidth.
  • Embodiment 2 will be described in detail below. In the following embodiments, a description will be given of how a server generates a media segment according to a media segment request.
  • generating a media segment according to a media segment request further includes: if the media segment request does not carry the first type of parameter, the target media stream to be transmitted is a media stream designated by default; if The media segment request does not carry the second type of parameter.
  • the candidate media unit includes the media unit specified by default.
  • the media unit specified by default is the media with the sequence number interval of all and latest media units in the target media stream less than the first preset value. Unit, or a media unit in which all and latest media units in the target media stream have a generation interval that is less than a second preset value.
  • the media unit is an RTP packet
  • each RTP packet carries a packet sequence number.
  • the packet number of the newly generated RTP packet is 1020
  • the first preset value is 20.
  • the server can select from the existing real-time media stream One is the target media stream, and the candidate media units to be sent include the 20 most recently generated RTP packets in the target media stream (packet numbers from 1001 to 1020).
  • the media unit is a TS segment, and each TS segment is associated with a generation time, which is the time stamp of the first media frame in the TS segment. It is assumed that the generation time of the newly generated TS segment is 33000 (unit is microsecond), and the second preset value is 3000.
  • the server receives a media segment request without any parameters, such as [req1]
  • the server One of the real-time media streams is selected as the target media stream
  • each media segment request sent by a user will return several media units generated recently.
  • the server continues to receive the media segment request, it will continue to deliver the most recently generated media unit to the client.
  • Embodiment 3 In the following embodiments, how a server determines a candidate media unit to be transmitted according to a second type of parameter will be described.
  • the candidate media to be transmitted includes all media units in the target media stream that simultaneously satisfy all constraints corresponding to the second type of parameters.
  • the constraint condition corresponding to the starting sequence number is: if the starting sequence number is valid, the sequence number of the candidate media unit is after the starting sequence number, or equal to the starting sequence number.
  • the constraint condition for the start time is: if the start time is valid, the generation time of the candidate unit is after the start time.
  • the constraint condition corresponding to the number of units is: if the number of units is valid, the number of candidate media units does not exceed the number of units; further, if other second-type parameters carried by the media segment request do not limit the range of candidate media units, The sequence interval between the candidate media unit and the latest media unit is smaller than the number of units.
  • the constraint condition corresponding to the segment duration is: if the segment duration is valid, the generation interval between the earliest generated unit and the latest generated unit among the candidate media units is shorter than the segment duration;
  • the validity and invalidity of the second type of parameters mentioned above refers to whether the value of the parameter is within a specified range. Taking the starting sequence number as an example, the value of the starting sequence number cannot exceed the sequence number of the current latest media unit. On the other hand, to ensure real-time, the starting sequence value cannot be earlier than the sequence number of an existing media unit. Starting numbers within the above range are valid. If a second-type parameter is invalid, it is equivalent to not carrying the second-type parameter. When all the second-type parameters are invalid, the candidate media unit to be transmitted is a media unit designated by default.
  • the media unit is an RTP packet, and each RTP packet carries a packet sequence number. Assume that the packet number of the newly generated RTP packet is 1020.
  • the server receives the following media segment request:
  • This request only carries a second type of parameter: the starting sequence number.
  • the candidate media units to be sent include these 16 RTPs. package;
  • This request only carries a second type of parameter: the number of units. Since no other second type of parameter indicates the range of the media unit, the serial number of the candidate media unit and the serial number of the latest media unit should be less than 8, that is, the candidate unit to be sent Including 8 RTP packets (packet numbers from 1013 to 1020);
  • the request carries two second-type parameters: the starting sequence number and the number of units.
  • the candidate unit must meet two constraints.
  • the first constraint is that the sequence number of the candidate media unit should be greater than or equal to 1010.
  • the second condition is that the number of candidate media units should not exceed 5.
  • the media unit is a TS segment, and each TS segment is associated with a generation time, which is the timestamp of the first media frame in the TS segment.
  • the latest TS segment generation time is 33000 (in microseconds) when the server receives the following media segment request:
  • the request carries two parameters of the second type: the start time and the segment duration.
  • the constraint condition corresponding to the start time is that the generation time of the TS segment should be greater than 31000.
  • the generation interval between the earliest generated unit and the latest generated unit among candidate media units is less than 3000.
  • the client can obtain the most recently generated media unit by continuously submitting media segment requests and carrying the second type of parameters, such as the start serial number or start time, to realize the real-time transmission of the media stream.
  • Figure 2 A schematic diagram of the process of real-time transmission of media streams by continuously submitting media segment requests with start numbers is given.
  • the client can also control the content and duration of the generated media segments by the number of units and segment duration.
  • Embodiment 4 In the following embodiment, how to determine a target media stream when the server generates a media segment will be described.
  • the first type of parameter includes a media stream identifier to specify a target media stream to be transmitted.
  • the first type of parameter includes the media stream identifier
  • determining the target media stream to be transmitted includes: When the first type of parameter carried in the media segment request includes only the media stream identifier, the target media stream is specified by the media stream identifier .
  • the server can assign an identifier to each real-time media stream to distinguish the different real-time media streams and specify one of them as the default target media stream; if the server When there is only one real-time media stream, the media stream is the default target media stream.
  • the default target media stream is sent to the client; when When the first type of parameters carried in the received media segment request includes the media stream identifier (such as the media segment requests req2, req7 to req8, and req11 to req12 listed in Example 1), the target media stream corresponds to the media stream identifier. Live media streaming.
  • Embodiment 5 multi-rate adaptive self-time media stream delivery will be described.
  • encapsulating the candidate media unit to be transmitted into a media segment further includes: obtaining media stream index information and encapsulating the media stream index information into the media segment, wherein the media stream index
  • the information includes multiple media stream description information belonging to the same content, and the media stream description information includes a media stream identifier and a media stream bit rate.
  • the media stream index information of the content is established; this media stream index information is actually It includes the mapping relationship between the media stream identifier and the media stream bit rate.
  • the media stream index information corresponding to the same content is displayed: the content includes three real-time media streams, of which media stream 1 (identified as 1000, code rate 8Mbps) HD stream, media stream 2 (identified as 1001, code rate is 2Mbps) is SD stream, media stream 3 (identified as 1002, code rate is 500Kbps) is mobile SD stream.
  • Media stream identification Media stream bit rate 601 8000Kbps 602 2000Kbps 603 500Kbps
  • the server queries the media stream index table and finds that there are media stream 2 and media stream 3 from the same content source. At this time, the server may use the above media stream index information as A control message is encapsulated into a media segment along with other media units.
  • the client can select the requested target from multiple media streams belonging to the same content according to the media stream index information and the network transmission situation.
  • the media stream index information remains unchanged for a long period of time, it is not necessary to encapsulate the media stream index information in each media segment.
  • the media stream index information can be encapsulated into the selected media segments at intervals. Or encapsulated in the first few media segments sent to the client.
  • a media segment is generated in real time according to a request from a client and returned to the client to implement real-time media stream delivery segmented according to the client's needs.
  • the client can control the length of the media segment by actively requesting it. When the transmission bandwidth between the client and the server is sufficient and the delay is small, the client can make a request more quickly.
  • Shorter media segments reduce real-time transmission delay; when the transmission bandwidth between the client and server is insufficient and the delay is large, the client can extend the interval for submitting requests to obtain longer media segments and reduce requests To reduce the transmission overhead; because each media segment is triggered by a client request, the manifest file is no longer needed, and the client does not need to request and parse the manifest file.
  • the client can obtain the latest media stream faster , Reducing the transmission delay of the real-time media stream, on the other hand, it also reduces the Transmission overhead and processing overhead, thereby effectively reducing the delay and overhead of media stream transmission, and further improving the transmission performance of real-time media streams.
  • FIG. 3 is a flowchart of a method for receiving a media stream in real time according to an embodiment of the present application.
  • the real-time receiving method for a media stream is a sequence of media units generated in real time. Each media unit is associated with a generation time and / or a serial number indicating a generation sequence.
  • the method includes the following steps:
  • a media segment request is sent to the server.
  • 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 first media parameter indicating a candidate media unit to be transmitted.
  • Second-class parameters Second-class parameters.
  • the second type of parameters includes one or more of a start sequence number, a unit number, a start time, and a segment duration.
  • Media segment requests can be submitted using any protocol, such as the common HTTP, TCP, and UDP protocols.
  • HTTP protocol such as the common HTTP, TCP, and UDP protocols.
  • HTTP-GET or HTTP-POST method can also be used.
  • control parameters need to be encapsulated into a string or byte stream in a certain way and sent to the server.
  • the control parameters can be encapsulated into a URL as a string.
  • HTTP-GET An example of a media segment request using HTTP-GET is as follows:
  • the parameter names streamID, seqBegin, timeBegin, unitCount, and segDuration respectively represent the media stream identifier, starting sequence number, starting time, unit number, and segment duration.
  • step S302 a media segment fed back by the server is received, wherein the media segment is generated by the server according to the media segment request and encapsulates a candidate media unit specifying a target media stream.
  • the client can use the same protocol as the media segment request to receive the media segment returned by the server. For example, when the client uses HTTP GET to send the media segment request, the client can receive the media segment through the HTTP GET response message.
  • step S303 the media segment is parsed, and the media unit is parsed according to the media segment, and a reception report of the media unit is generated.
  • parsing the received media segment includes: parsing the media unit from the received media segment to generate a media unit reception report; parsing the media segment is the reverse process of media segment encapsulation, so first of all, determine the server side Encapsulation protocol, which can be agreed by the server and client before transmitting the media stream.
  • the server uses the following custom encapsulation protocol: a media segment has a segment header and a segment payload, the segment payload is formed by concatenating several media units, and the segment header indicates the starting position and length of each media unit. At this time, for the client, the start position and length of each media unit can be obtained through the segment header first, and then each media unit is parsed from the segment payload.
  • the media unit is an RTP packet
  • the serial number and generation time of each media unit can be obtained from the header of each RTP packet. According to the serial number and generation time of the successfully received RTP packet, a media unit reception report can be generated. .
  • step S304 a new media segment request is generated according to the reception report of the media unit, where a control parameter carried in the new media segment request is determined.
  • generating a new media segment request according to the report received by the media unit includes determining a control parameter carried in the media segment request.
  • the client can obtain the current real-time media stream reception progress through the media unit receiving report.
  • the client In order to achieve continuous reception of the real-time media stream, the client generates a new media segment request.
  • the client controls the content of the media segment to be received next time to ensure the receiving efficiency of the media stream.
  • steps S301 and S304 are only for convenience of description, and are not used to limit the execution order of the methods.
  • sending a media segment request to the server further includes: if no media unit sent by the server is received, sending an initial media segment request to the server; and if a new media segment is generated according to the reception report Request, a new media segment request is sent to the server.
  • the client when the client does not receive any media unit, it sends an initial media segment request to the server; when the client generates a new media segment request according to the media unit reception report, it sends a newly generated media segment request to the server.
  • the initial media segment request does not carry any second-type parameters, or includes one of the following second-type parameters: start sequence number, number of units, start time, and segment duration.
  • the client when the client does not receive any media unit, it sends an initial media segment request to the server; when the client generates a new media segment request based on the media unit reception report, it sends a new generation to the server immediately or at a specified time Media segment request.
  • RTP real-time stream reception Take RTP real-time stream reception as an example.
  • 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).
  • the server may encapsulate a fixed number of recent real-time media streams (such as 3) RTP packets into media segments and return to the client.
  • the client When the client receives the first media segment returned by the server, the client parses the media segment to obtain a media unit reception report, which can learn which media units have been received, and then request in the newly generated media segment, including, Set the control parameters in the new media segment request to ensure that the next requested media unit is required by the client. In order to control the duration of the next media segment, the client can send a newly generated media segment request to the server immediately or through a delay.
  • the initial media segment request may include a second type of control parameter: a start sequence number.
  • the starting sequence number can indicate the sequence number from which the client expects to receive the media unit.
  • the starting sequence number is used to indicate the sequence number of the media unit the client expects to start from; the value of the starting sequence number can be arbitrarily specified, such as 0.
  • the start serial number may be valid, that is, the start serial number is the serial number of the most recently generated media unit, but when the start serial number is invalid, the server will automatically select the media unit specified as the media segment by default.
  • 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 the client expects to receive, such as 10.
  • the initial media segment request may include a second type of control parameter: a start time.
  • the start time is used to indicate the time point at which the client expects the media unit to start; the start time value can be arbitrarily specified, such as 0.
  • the start time may be valid, that is, the start time of the latest media unit generation time is within a specified range, or it may be invalid. When the start time is invalid, the server will automatically select the media unit specified as the media segment by default.
  • the initial media segment request may include a second type of control parameter: segment duration.
  • segment duration is used to indicate how long the client expects to receive the media unit produced recently.
  • the client can obtain the latest media unit of the real-time media stream, regardless of whether it carries the second type of control parameters, so as to understand the current real-time media stream sending progress, and generate a new media segment. Request for conditions.
  • the client when it does not receive any media units, it can also understand the generation of real-time media streams based on direct interaction with the server, such as directly obtaining the serial number of the latest media unit of the real-time media stream, so that the initial media segment can be set The second type of parameter in the request.
  • the reception report includes a serial number of a media unit that is currently successfully received, and if the second type of parameters carried in the new media segment request includes a start serial number, the value of the start serial number is the current Sequence number of the next unit that received the latest media unit that was successfully received.
  • the media unit reception report indicates the serial number of the media unit that is currently successfully received; generating a new media segment request according to the media unit reception report includes: the second type of parameters carried in the new media segment request includes the starting sequence number;
  • the serial number value is the serial number value of the next unit of the latest media unit that has been successfully received.
  • the serial number value of the next unit is the serial number value of the original unit plus 1. If the serial number is circularly counted, you need to determine whether the result exceeds If the upper limit is exceeded, the serial number value of the next unit should be recounted.
  • the client's media unit reception report is generated by the client after parsing the media segment returned by the server, and is used to describe the reception of the media unit on the client, which can be used as a reference for generating a new media segment request.
  • each media unit is an RTP packet
  • the serial number of the media unit is the serial number of the RTP packet.
  • a media segment can encapsulate multiple RTP packets.
  • the client parses the RTP packet from the received media segment the RTP packet header can obtain the packet sequence number of the RTP packet. Assume that a media segment encapsulates 3 RTP packets with packet sequence numbers from 20 to 22.
  • the client When the client successfully receives this media segment, it can obtain a media unit reception report by parsing the media segment. A list of received RTP packet sequence numbers: ⁇ 20, 21, 22 ⁇ . At this time, when the client generates a new media segment request, it can carry a second type of parameter: the starting sequence number. Through the unit receiving report, it can be known that the serial number of the latest media unit is 22, then the serial number of the next media unit should be 23, and the starting serial number carried in the new media segment request value is 23.
  • Figure 4 shows the transmission process of the client continuously submitting the starting sequence number.
  • the reception report includes the generation time of the media unit that is currently successfully received, and if the second type of parameters carried in the new media segment request includes the start time, the value of the start time is Generation time of the latest media unit that is currently successfully received.
  • each media unit is a TS segment.
  • a TS segment encapsulates multiple media frames of a fixed time period, such as about 1 second, and the first media frame contained in each segment. The timestamp indicates when the fragment was generated.
  • the serial numbers and generation times of all TS segments can be encapsulated in the head of the media segment.
  • the client When the client receives the returned media segment, it can parse multiple TS segments from it, and obtain the serial number and generation time of each TS segment through the media segment header. Assume that a media segment encapsulates three TS segments with packet sequence numbers from 101 to 103. When the client successfully receives this media segment, by parsing the media segment, a media unit reception report can be obtained. A list of the received TS segment numbers and their generation time: ⁇ (101, 15000), (102, 20000), (103, 25000) ⁇ . At this time, when the client generates a new media segment request, it can carry A second type of parameter: the start time. The value of the start time is the start time of the latest media unit that is currently successfully received. When the server receives this request, the generation time of the encapsulated media unit when the server generates the media segment must be after this start time. In this way, by continuously submitting the media segment request carrying the start time, the client can obtain the latest unsuccessfully received media unit.
  • the method before receiving the media segment feedback from the server, the method further includes: after sending the media segment request, detecting the feedback time of the media segment; if the feedback time exceeds a preset time, terminating the receiving of the current Media segments, and the parsed media segments are incompletely received media segments.
  • the media segment returned by the receiving server must be completed before a set reception time, and if the reception time is not completed, the reception of the current media segment is terminated; parsing the received media segment includes the incompletely received Parsing of media segments.
  • the client After the client sends a media segment request to the server, it transfers to receiving the media segment request returned by the server. If the network transmission conditions between the server and the client are good, the media segment can be sent to the client normally. However, if the network transmission conditions between the server and the client are unstable, such as a link failure or congestion, the media segment may be incorrect or lost.
  • the client can start a timing to set the latest reception time for the media segment reception. If the requested media segment is not received after this reception time, the current media segment should be terminated. Reception of media segments, such as automatically terminating TCP or HTTP connections, parsing some of the media segments that have been received, generating a media unit reception report, and resubmitting a media segment request, so as to prevent the impact of a media segment reception failure Subsequent real-time stream reception.
  • a connection-oriented transmission protocol such as TCP or HTTP
  • bit rate adaptation when receiving a real-time media stream will be described.
  • the method further includes: receiving media stream index information sent by the server, where the media stream index information includes multiple media stream description information belonging to the same content, and the media stream description information includes the media stream Identification and media stream bit rate.
  • the client obtains the media stream index information from the server, and the media stream index information includes several media stream description information belonging to the same content; the media stream description information includes: a media stream identifier and a media stream bit rate.
  • generating a new media segment request according to the reception report of the media unit further includes: when the first type of parameters carried in the new media segment request includes a media stream identifier, according to the current transmission rate and media The stream index information determines the media stream identifier, and obtains the current transmission rate according to the reception time of the media segment.
  • generating a new media segment request according to the media unit receiving report includes: the first type of parameters carried by the new media segment request includes a media stream identifier; the media stream identifier can be obtained through the current transmission rate of the media stream and the media stream index information To decide; the current transmission rate of the media stream can be estimated based on the reception time of the media segment.
  • receiving the media stream index information sent by the server further includes: parsing and obtaining the media stream index information according to the received media segment, wherein the media stream index information is encapsulated into the media segment by the server.
  • the client parses the media stream index information from the received media segment, and the media stream index information is encapsulated by the server into the media segment sent to the client.
  • the media stream index information is actually It includes the mapping relationship between the media stream identifier and the media stream bit rate.
  • the figure shows the media stream index information corresponding to the same content (such as a live concert live broadcast): the content includes three real-time media streams, of which media stream 1 (identified as 1000, code rate 8Mbps) is high-definition code stream , Media stream 2 (identified as 1001, code rate is 2 Mbps) is SD stream, media stream 3 (identified as 1002, code rate is 500 Kbps) is mobile SD stream, as shown in Table 2.
  • Media stream identification Media stream bit rate 601 8000Kbps 602 2000Kbps 603 500Kbps
  • the client can obtain the media stream index information of the specified content from the server through various methods.
  • One method is: When the client requests any media stream, the server encapsulates the media stream index information corresponding to the media stream into a media segment and returns it to the client. The client parses the media stream from the received media segment. Index information. For example, when the client requests a real-time media stream with a media stream identifier of 601, the server finds that the media stream 601 and the other two real-time media streams 602 and 603 with the same bit rate correspond to the same content, that is, the media stream index information ⁇ ( 601,8000), (602, 2000), (603,500) ⁇ are encapsulated into the segment header of the media segment and returned to the client. The client can obtain the index information by parsing the header of the media segment. The client can also obtain the media stream index information through other methods, such as directly sending a request to the server to obtain it.
  • the client When the client finds that the requested content has multiple real-time media streams with different bit rates, it can automatically select a real-time media stream with a specific bit rate based on the current media stream transmission rate to avoid a large number of packet loss and delays to improve The receiving performance of the client.
  • the client In order to obtain the current media stream transmission rate, the client can record the reception time of each media segment.
  • the reception time of a media segment refers to the elapsed time for receiving all or part of the data of the media segment.
  • the current media stream transmission rate can be estimated by the reception time of the media segment.
  • a simple estimation method is:
  • the client can select a media stream with a code rate close to the transmission rate from the media stream index, and use its corresponding media stream identifier as the first carried in the new media segment request.
  • Class parameters For example, when a client requests a media stream 601, the actual media stream transmission rate is 3,000 Kbps measured through the received media segments. Obviously, the current media stream transmission rate is much lower than the actual bit rate of the media stream 601 at 8000 Kbps, but The actual bit rate is 2000Kbps higher than the media stream 602. Therefore, when the client generates a new media segment request, the media stream identifier carried by the client should be changed to 602 to achieve better transmission performance.
  • the second type of parameters carried in the new media segment request may also be determined according to the current receiving situation of the stream (such as the serial number and generation time of the latest media unit received).
  • the current receiving situation of the stream such as the serial number and generation time of the latest media unit received.
  • multiple real-time media streams belonging to the same content should be generated synchronously, that is, media units with the same sequence number or generation time correspond to the same content segment (such as an image or a voice, etc.).
  • the server by continuously sending a media segment request to the server, the server generates a media segment according to the received media segment request and returns it to the client, and sends the request through the parameters and the sending request.
  • the media segment generated on demand can better adapt to the dynamic network transmission environment, and the client can control the length of the media segment by actively requesting: When the client and the server transmit When the bandwidth is sufficient and the delay is small, the client can make a request faster, thereby obtaining a shorter media segment and reducing the real-time transmission delay.
  • the client can extend the interval for submitting requests, thereby obtaining longer media segments, reducing the number of requests to reduce transmission overhead; since each media segment is triggered by the client's request, there is no longer a need for a manifest file, and no request and Parsing the manifest file, on the one hand, can get the latest media stream faster, reducing the actual Transmission media stream delay, on the other hand, also reduces transmission overhead and processing overhead caused by the manifest file, thus effectively reducing the transmission delay and overhead, to further improve the transmission performance of real-time media streams.
  • FIG. 5 is a schematic structural diagram of a real-time delivery server for media streams according to an embodiment of the present application.
  • the real-time delivery server 10 of the media stream includes a client interface component 100 and a media segment generation component 200.
  • the client interface component 100 is configured to receive a media segment request sent by a client and return a corresponding media segment.
  • the media segment request does not carry or carry at least one control parameter, and the control parameter includes a target media stream indicating a target media stream to be transmitted.
  • the first type of parameters and the second type of parameters indicate candidate media units to be transmitted.
  • the media segment generation component 200 generates a media segment according to a media segment request, wherein a target media stream to be transmitted is determined according to the first type of parameters, a candidate media unit to be transmitted is determined according to the second type of parameters, and the candidate media unit to be transmitted is encapsulated.
  • Media segments are created, and media segments are sent to the client through the client interface component 100.
  • the server 10 in the embodiment of the present application generates a media segment in real time according to a client's request and returns it to the client to realize real-time media stream delivery segmented according to the client's needs, thereby effectively reducing the delay and overhead of media stream transmission and further improving Real-time media streaming performance.
  • the client interface component 100 is configured to receive a client's media segment request and send the generated media segment to the client; the media segment request can carry 0, 1 or more control parameters; the control parameters include the following categories : The first type of parameters and the second type of parameters; the first type of parameters are used to indicate the target media stream to be transmitted; the second type of parameters are used to indicate the candidate media units to be transmitted.
  • the client interface component can use any specified protocol to receive media segment requests. For example, when using the HTTP protocol, the client interface component can be a Web server that can receive any media segment request using the http protocol and return it through an HTTP response. Media segment; when using the TCP protocol, the client interface component is a TCP server and provides a fixed service port.
  • the media segment generation component 200 is configured to generate a required media segment according to a client's media segment request. Obtain the media segment request and its control parameters from the client interface component, determine the target media stream to be transmitted according to the first type of parameters, determine the candidate media units to be transmitted according to the second type of parameters, and extract from the media stream storage unit The candidate media unit to be transmitted is encapsulated into a media segment and then directly delivered to the client interface component for transmission.
  • the server 10 in the embodiment of the present application further includes at least one real-time media stream generation component, which is used to generate or receive one or more real-time media streams from other servers by itself; the media stream is generated in real time. Sequence of media units; each media unit is associated with a generation time and / or a serial number, which is used to indicate the sequence in which the media units were generated;
  • the real-time media stream generation component may include one or more processing steps for media stream generation.
  • the processing steps include, but are not limited to, real-time acquisition of media signals, encoding and compression, transmission packaging, and pre-segmentation.
  • the real-time media stream generation component can also receive real-time media streams from other devices, or convert an existing media stream file into a real-time stream.
  • the media segment generating component is further configured to: when the media segment request does not carry the first type of parameters, the target media stream to be transmitted is the media stream designated by default, and the media segment When the second type of parameter is not carried in the request, the candidate media unit includes a media unit designated by default.
  • the media unit designated by default is a media unit whose sequence interval between all and latest media units in the target media stream is smaller than the first preset value. Alternatively, it is a media unit in which the generation time interval of all and latest media units in the target media stream is less than a second preset value.
  • the candidate media unit to be transmitted include all media units in the target media stream that simultaneously meet all constraints corresponding to the second type of parameters.
  • the second type of parameter includes a starting sequence number, and a constraint condition corresponding to the starting sequence number is: if the starting sequence number is valid, the sequence number of the candidate media unit is after the starting sequence number, or equal to Starting sequence number.
  • the second type of parameter includes a start time
  • the constraint condition corresponding to the start time is: if the start time is valid, the generation time of the candidate unit is after the start time.
  • the second type of parameter includes the number of units, and the constraint condition corresponding to the number of units is: if the number of units is valid, the number of candidate media units does not exceed the number of units; further If other second-type parameters carried in the media segment request do not limit the range of candidate media units, the sequence interval between the candidate media unit and the latest media unit is less than the number of units.
  • the second type of parameter includes the segmentation duration
  • the constraint condition corresponding to the segmentation duration is: if the segmentation duration is valid, the earliest generated unit and the latest generated among the candidate media units The generation time interval of the unit is less than the segmentation time; further, if other second-type parameters carried in the media segment request do not limit the range of candidate media units, the generation time interval of the candidate media unit and the latest media unit is less than the segmentation time.
  • the first type of parameter includes a media stream identifier to specify a target media stream to be transmitted.
  • the media segment generating component is further configured to obtain media stream index information and encapsulate the media stream index information into the media segment, where the media stream index information includes information that belongs to the same content. Multiple pieces of media stream description information.
  • the media stream description information includes a media stream identifier and a media stream bit rate.
  • a media segment is generated in real time according to a client's request and returned to the client to realize real-time media stream delivery segmented according to the client's needs.
  • the duration of the media segment will be Automatically adapt to changes in network transmission bandwidth.
  • the client can control the length of the media segment by actively requesting it. When the transmission bandwidth between the client and the server is sufficient and the delay is small, the client can make a request more quickly.
  • Shorter media segments reduce real-time transmission delay; when the transmission bandwidth between the client and server is insufficient and the delay is large, the client can extend the interval for submitting requests to obtain longer media segments and reduce requests To reduce the transmission overhead; because each media segment is triggered by a client request, the manifest file is no longer needed, and the client does not need to request and parse the manifest file.
  • the client can obtain the latest media stream faster , Reducing the transmission delay of real-time media streams, on the other hand, it also reduces the Transmission overhead and processing overhead, thereby effectively reducing the delay and overhead of media stream transmission, and further improving the transmission performance of real-time media streams.
  • FIG. 7 is a schematic structural diagram of a real-time receiving client for a media stream according to an embodiment of the present application.
  • the real-time receiving client 1000 for a media stream includes a server interface component 1, a media segment analysis component 2, and a media stream transmission control component 3.
  • the server interface component 1 is configured to send a media segment request to the server.
  • the media segment request does not carry or carry at least one control parameter, and the control parameter includes a first type of parameter indicating a target media stream to be transmitted and a candidate media indicating to be transmitted.
  • the second type of parameters of the unit and receives the media segment feedback from the server, wherein the media segment is generated by the server according to the media segment request and encapsulates the candidate media unit specifying the target media stream.
  • the media segment parsing component 2 is used to parse a media segment, wherein a media unit is parsed according to the media segment and a reception report of the media unit is generated.
  • the media stream transmission control component 3 is configured to generate a new media segment request according to the reception report of the media unit, where a control parameter carried in the new media segment request is determined.
  • the client 1000 in the embodiment of the present application continuously sends a media segment request to the server, and the server generates a media segment according to the received media segment request and returns it to the client, and controls the media segment through the parameters carried in the request and the interval between sending requests.
  • the content is timely and timely, thereby effectively reducing transmission delay and overhead, and further improving the transmission performance of real-time media streams.
  • the server interface component may use the HTTP protocol to send a media segment request and receive the returned media segment.
  • the server interface component 1 can use any network transmission protocol to send media segment requests and receive media segments returned by the server, such as the UDP protocol, TCP protocol, and HTTP protocol.
  • the server interface component uses the HTTP protocol to submit a media segment request and receive the media segment returned by the server
  • the server interface component includes the function of the HTTP client: the parameters of the media segment request can be encapsulated as strings as part of the HTTP GET URL,
  • the media segment generated by the server can be encapsulated in a HTTP GET response message and returned to the client.
  • Phase 1 When the media stream transmission control component 3 does not receive any media unit reception report, an initial media segment request is generated; the initial media segment request does not carry any second-type parameters, or contains one of the following second-type parameters: Sequence number, number of units, start time, and segment duration; the values of the above-mentioned second type parameters can be specified by default.
  • the client By sending the initial media segment request, the client can receive the first media segment returned by the server, and the media segment parsing component 2 will generate a media unit reception report and send it to the media stream transmission control component 3.
  • Phase 2 When the media stream transmission control component 3 receives the media unit reception report, it will generate a new media segment request according to the content of the media unit reception report.
  • the second type of parameters carried in the generated media segment request includes the starting serial number; the value of the starting serial number is the value of the latest media unit that is currently successfully received. Sequence number of the next unit;
  • the second type of parameters carried in the generated media segment request includes the start time; the value of the start time is the latest media unit that is currently successfully received Time of generation.
  • the media stream transmission control component 3 may also support bit rate adaptation.
  • the media stream transmission control component 3 needs to first obtain the media stream index information of the content, and the media stream index information includes several media stream description information belonging to the same content; the media stream description information includes: a media stream identifier and a media stream bit rate.
  • the method for obtaining the media stream index information may be actively requested by the client, or may be actively sent by the server to the client.
  • the media stream transmission control component 3 may adjust a first type of parameter carried by the media stream request component: the media stream identifier.
  • the media stream transmission control component 3 will select the media stream identifier according to the current transmission rate of the current media stream and the media stream index information to ensure that the bit rate of the selected media stream matches the current transmission rate, in order to improve transmission reliability and reduce Transmission delay.
  • the current transmission rate of the media stream can be estimated based on the reception time of the media segment, such as monitoring the amount of data received within several time periods (such as 1 second).
  • the real-time media stream can be played while receiving.
  • a media playback component can be introduced based on the existing components.
  • the media playback component can play back the received media units in real time, as shown in Figure 8. Show:
  • the function of the media playback component may include multiple processing steps.
  • the media playback component in order to complete the playback of the RTP packet, the media playback component first needs to decapsulate from the RTP packet and recover the media frame from the RTP payload. If the media frame is compressed, it needs to be compressed. Decompress and play the original bitstream obtained after decompression.
  • the media stream transmission control component 3 is further configured to send an initial media segment request to the server when no media unit sent by the server is received, and generate a new media segment according to the reception report When requested, a new media segment request is sent to the server.
  • the second type of parameters includes one or more of a start sequence number, the number of units, a start time, and a segment time.
  • the reception report includes a serial number of a media unit that is currently successfully received, and if the second type of parameters carried in the new media segment request includes a start serial number, the value of the start serial number is the current Sequence number of the next unit that received the latest media unit that was successfully received.
  • the reception report includes the generation time of the media unit that is currently successfully received, and if the second type of parameters carried in the new media segment request includes the start time, the value of the start time is Generation time of the latest media unit that is currently successfully received.
  • the client 1000 in the embodiment of the present application before receiving the media segment feedback from the server, further includes a detection module.
  • the detection module is configured to detect the feedback time of the media segment after sending the media segment request, and terminate the reception of the current media segment when the feedback time exceeds a preset time, and the parsed media segment is an incompletely received media segment.
  • the media stream transmission control component 3 is further configured to receive media stream index information sent by the server, where the media stream index information includes multiple media stream description information belonging to the same content, and the media The stream description information includes a media stream identifier and a media stream bit rate.
  • the media stream transmission control component 3 is further configured to determine the media according to the current transmission rate and media stream index information when the first type of parameters carried in the new media segment request includes the media stream identifier. Stream identification, and get the current transmission rate based on the reception time of the media segment.
  • the media stream transmission control component 3 is further configured to parse and obtain the media stream index information according to the received media segment, wherein the media stream index information is encapsulated into the media segment by the server.
  • the server by continuously sending a media segment request to the server, the server generates a media segment according to the received media segment request and returns it to the client.
  • the requested interval controls the content and duration of the media segment.
  • the media segments generated on demand can better adapt to the dynamic network transmission environment.
  • the client can actively request to control the length of the media segment: when the client and server When the transmission bandwidth is sufficient and the delay is small, the client can make a request faster, thereby obtaining a shorter media segment and reducing the real-time transmission delay; when the transmission bandwidth between the client and the server is insufficient and the delay is large , The client can extend the interval for submitting requests, so as to get longer media segments, reduce the number of requests to reduce transmission overhead; because each media segment is triggered by the client's request, no inventory file is required, and no request is required And parsing the manifest file, on the one hand can get the latest media stream faster, reducing When the media stream transmission delay, on the other hand, also reduces transmission overhead and processing overhead caused by the manifest file, thus effectively reducing the transmission delay and overhead, to further improve the transmission performance of real-time media streams.
  • an embodiment of the present application further provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor.
  • the processor executes the program, the implementation as in the foregoing embodiment is implemented.
  • an embodiment of the present application further proposes a non-transitory computer-readable storage medium, and when the program is executed by a processor, the method for real-time delivery of a media stream as described in the foregoing embodiment is implemented, or as in the foregoing embodiment Describes the method for real-time reception of media streams.
  • an embodiment of the present application further provides a computer program product.
  • instructions in the computer program product are executed by a processor, the method for real-time delivery of a media stream as described in the foregoing embodiment is implemented, or as described above
  • the example describes a method for receiving a media stream in real time.
  • first and second are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as “first” and “second” may explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality” is at least two, for example, two, three, etc., unless it is specifically and specifically defined otherwise.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

一种媒体流的实时递送方法、实时接收方法及客户端，其中，方法包括：接收客户端(1000)发送的媒体段请求，其中，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数(S101)；根据媒体段请求生成媒体段，其中，根据第一类参数确定待传送的目标媒体流，根据第二类参数确定待传送的候选媒体单元，并将待传送的候选媒体单元封装成媒体段(S102)；发送媒体段至客户端(1000) (S103)。本方法根据客户端(1000)的请求来实时生成媒体段，并返回给客户端(1000)，以实现按客户端(1000)需求分段的实时媒体流递送，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。

Description

[根据细则91更正 02.08.2019]　媒体流的实时递送方法、实时接收方法、服务器及客户端
相关申请的交叉引用
本申请基于申请号为201811032231.5，申请日为2018年09月05日，以及申请号为201811033268.X，申请日为2018年09月05日申请的中国专利申请提出，并要求该中国专利申请的优先权，该中国专利申请的全部内容在此引入本申请作为参考。
技术领域
[根据细则91更正 02.08.2019]　
本申请涉及数字信息传送技术领域，特别涉及一种媒体流的实时递送方法、实时接收方法、服务器及客户端。
背景技术
随着互联网特别是移动互联网的快速发展，通过互联网来实时传送音频、视频、图像等多媒体数据成为许多应用的基本需求，为满足这一需求，人们提出了各种流媒体实时传输技术，目前得到广泛使用的主要包括三类：实时传送协议(RTP(Real-time Transport Protocol，实时传输协议)/RTSP(Real Time Streaming Protocol，实时流传输协议))、RTMP(Real Time Messaging Protocol，实时消息传送协议)和HTTP(HyperText Transfer Protocol，超文本传输协议)自适应性流传输HAS(HTTP Adaptive Streaming)。其中，HTTP自适应流传输又包括多种方案：苹果公司提出的HLS(HTTP Live Streaming)、微软提出的平滑流Smooth Streaming、Adobe提出的HDS(HTTP Dynamic Streaming)、MPEG组织提出的DASH(Dynamic Adaptive Streaming over HTTP，基于HTTP的动态自适应流)。
这些HTTP自适应性流传输方案的共同特点是将媒体流切割成短时间(2s～10s)的媒体片段，并同时生成描述这些媒体片段的索引文件或清单文件(例如HLS中的m3u8播放列表和DASH中的MPD文件)，然后将其保存到各Web服务器上，客户端通过访问播放列表或清单文件，获得这些媒体片段的URL(Uniform Resource Locator，统一资源定位符)访问地址，然后可以采用标准的HTTP协议来逐个下载这些媒体片段并进行播放。这些方案的主要区别体现在媒体片段采用的封装格式和清单文件格式的不同。
相对于RTP/RTSP和RTMP来说，HTTP自适应流传输可以充分利用现有的互联网Web缓存设施(如CDN和各种Web缓存服务器)，可以支持大规模的用户访问。同时，通过提供多种码率的媒体片段，还可以支持客户端根据网络条件和终端能力来自行选择合适码率的片段，实现码率自适应。因此，HTTP自适应流传输已成为目前互联网上实时流媒体递送的主流方式。
但是，上述的这些HTTP自适应流传输方案均存在两个问题：
问题1，媒体片段的时长无法适应动态变化的网络传输。目前的HAS方案均采用预分段的方式，即服务器按照预先设置的时长来生成媒体片段及其清单文件并提交给web服务器。当网络传输带宽充足且延时较小时，设置较大的片段时长意味着增加实时传送的延时；当网络传输带宽不足且延时较大时，设置较小的片段时长意味着频繁的文件请求，增加服务器的负担和网络传输开销。由于互联网上的传输带宽和传输延时是动态变化的，采用固定时长的预分段方式无法实现最优传输。
问题2，清单文件增加了传送延时和开销。客户端需要先得到清单文件，才能获得媒体片段的URL地址。但是由于清单文件需要经过一段时间才能传输给客户端，因此，客户端得到的清单文件并不能反映当前最新的媒体片段的生成情况，此外，当清单文件遇到阻塞或者传输出错时，将阻塞用户对媒体片段的快速访问，降低实时流媒体的传送性能。
发明内容
本申请旨在至少在一定程度上解决相关技术中的技术问题之一。
为此，本申请的第一个目的在于提出一种媒体流的实时递送方法，该方法可以有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。
本申请的第二个目的在于提出一种媒体流的实时接收方法。
本申请的第三个目的在于提出一种媒体流的实时递送服务器。
本申请的第四个目的在于提出一种媒体流的实时接收客户端。
本申请的第五个目的在于提出一种计算机设备。
本申请的第六个目的在于提出一种非临时性计算机可读存储介质。
本申请的第七个目的在于提出一种计算机程序产品。
为达到上述目的，本申请第一方面实施例提出了一种媒体流的实时递送方法，所述媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括以下步骤：接收客户端发送的媒体段请求，其中，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；根据所述媒体段请求生成媒体段，其中，根据所述第一类参数确定所述待传送的目标媒体流，根据所述第二类参数确定所述待传送的候选媒体单元，并将所述待传送的候选媒体单元封装成所述媒体段；发送所述媒体段至所述客户端。
本申请实施例的媒体流的实时递送方法，根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，媒体分段的时长将自动适应网络传输带宽的变化，客户端可以通过主动请求来***体分段的时长，由于每个媒体段是 由客户端的请求触发产生的，不再需要清单文件，客户端也不需要请求和解析清单文件，一方面客户端可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。
另外，根据本申请上述实施例的媒体流的实时递送方法还可以具有以下附加的技术特征：
进一步地，在本申请的一个实施例中，所述根据所述媒体段请求生成媒体段，进一步包括：如果所述媒体段请求不携带所述第一类参数，则所述待传送的目标媒体流为缺省指定的媒体流；如果所述的媒体段请求中不携带所述第二类参数，则所述候选媒体单元包括缺省指定的媒体单元，所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。
进一步地，在本申请的一个实施例中，如果所述的媒体段请求携带至少一个所述第二类参数，其中，所述每个第二类参数对应着候选媒体单元的至少一个约束条件，则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
进一步地，在本申请的一个实施例中，所述第二类参数包括起始序号，所述起始序号对应的约束条件为：如果所述起始序号有效，则所述候选媒体单元的序号在所述起始序号之后，或者等于所述起始序号。
进一步地，在本申请的一个实施例中，所述第二类参数包括起始时间，所述起始时间对应的约束条件为：如果所述起始时间有效，则所述候选单元的产生时间在起始时间之后。
进一步地，在本申请的一个实施例中，所述第二类参数包括单元个数，所述单元个数对应的约束条件为：如果所述单元个数有效，则所述的候选媒体单元的数目不超过所述单元个数；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的序号间隔小于所述单元个数。
进一步地，在本申请的一个实施例中，所述第二类参数包括分段时长，所述分段时长对应的约束条件为：如果所述分段时长有效，则所述的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于所述分段时长；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的产生时间间隔小于所述分段时长。
进一步地，在本申请的一个实施例中，所述第一类参数包括媒体流标识，以指定所述待传送的目标媒体流。
进一步地，在本申请的一个实施例中，所述将所述待传送的候选媒体单元封装成所述媒体段，进一步包括：获取媒体流索引信息，并将所述媒体流索引信息封装到所述媒体段中，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
为达到上述目的，本申请第二方面实施例提出了一种媒体流的实时接收方法，所述的媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括：发送媒体段请求至服务器，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；接收所述服务器反馈的媒体段，其中，所述媒体段由所述服务器根据所述媒体段请求生成，并封装有指定所述目标媒体流的候选媒体单元；解析所述媒体段，其中，根据所述媒体段中解析出媒体单元，并生成所述媒体单元的接收报告；根据所述媒体单元的接收报告生成新媒体段请求，其中，确定所述新媒体段请求携带的控制参数。
本申请实施例的媒体流的实时接收方法，通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来***体段的内容及时长，按需生成的媒体段可以更好适应动态的网络传输环境，由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，也不需要请求和解析清单文件，一方面可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
为达到上述目的，本申请第三方面实施例提出了一种媒体流的实时递送服务器，所述媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述服务器包括：客户端接口组件，用于接收客户端发送的媒体段请求并返回相应的媒体段，其中，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；媒体段生成组件，根据所述媒体段请求生成媒体段，其中，根据所述第一类参数确定所述待传送的目标媒体流，根据所述第二类参数确定所述待传送的候选媒体单元，并将所述待传送的候选媒体单元封装成所述媒体段，并通过所述客户端接口组件发送所述媒体段至所述客户端。
本申请实施例的媒体流的实时递送服务器，根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，媒体分段的时长将自动适应网络传输带宽的变化，客户端可以通过主动请求来***体分段的时长，由于每个媒体段 是由客户端的请求触发产生的，不再需要清单文件，客户端也不需要请求和解析清单文件，一方面客户端可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。
另外，根据本申请上述实施例的媒体流的实时递送服务器还可以具有以下附加的技术特征：
进一步地，在本申请的一个实施例中，所述媒体段生成组件进一步用于在所述媒体段请求不携带所述第一类参数时，所述待传送的目标媒体流为缺省指定的媒体流，并在所述的媒体段请求中不携带所述第二类参数时，所述候选媒体单元包括缺省指定的媒体单元，所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。
进一步地，在本申请的一个实施例中，如果所述的媒体段请求携带至少一个所述第二类参数，其中，所述每个第二类参数对应着候选媒体单元的至少一个约束条件，则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
进一步地，在本申请的一个实施例中，所述第二类参数包括起始序号，所述起始序号对应的约束条件为：如果所述起始序号有效，则所述候选媒体单元的序号在所述起始序号之后，或者等于所述起始序号。
进一步地，在本申请的一个实施例中，所述第二类参数包括起始时间，所述起始时间对应的约束条件为：如果所述起始时间有效，则所述候选单元的产生时间在起始时间之后。
进一步地，在本申请的一个实施例中，所述第二类参数包括单元个数，所述单元个数对应的约束条件为：如果所述单元个数有效，则所述的候选媒体单元的数目不超过所述单元个数；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的序号间隔小于所述单元个数。
进一步地，在本申请的一个实施例中，所述第二类参数包括分段时长，所述分段时长对应的约束条件为：如果所述分段时长有效，则所述的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于所述分段时长；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的产生时间间隔小于所述分段时长。
进一步地，在本申请的一个实施例中，所述第一类参数包括媒体流标识，以指定所述待传送的目标媒体流。
进一步地，在本申请的一个实施例中，所述媒体段生成组件进一步用于获取媒体流索引信息，并将所述媒体流索引信息封装到所述媒体段中，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
进一步地，在本申请的一个实施例中，还包括：至少一个实时媒体流生成组件，用于自行产生或接收来自其他装置的一个或多个实时媒体流。
为达到上述目的，本申请第四方面实施例提出了一种媒体流的实时接收客户端，所述的媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述客户端包括：服务器接口组件，用于发送媒体段请求至服务器，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数，并接收所述服务器反馈的媒体段，其中，所述媒体段由所述服务器根据所述媒体段请求生成，并封装有指定所述目标媒体流的候选媒体单元；媒体段解析组件，用于解析所述媒体段，其中，根据所述媒体段中解析出媒体单元，并生成所述媒体单元的接收报告；媒体流传输控制组件，用于根据所述媒体单元的接收报告生成新媒体段请求，其中，确定所述新媒体段请求携带的控制参数。
本申请实施例的媒体流的实时接收客户端，通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来***体段的内容及时长，按需生成的媒体段可以更好适应动态的网络传输环境，由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，也不需要请求和解析清单文件，一方面可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
为达到上述目的，本申请第五方面实施例提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时，实现如上述实施例描述的媒体流的实时递送方法，或者如上述实施例描述的媒体流的实时接收方法。
为达到上述目的，本申请第六方面实施例提出了一种非临时性计算机可读存储介质，该程序被处理器执行时实现如上述实施例描述的媒体流的实时递送方法，或者如上述实施例描述的媒体流的实时接收方法。
为达到上述目的，本申请第七方面实施例提出了一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如上述实施例描述的媒体流的实时递送方法，或者如上述实施例描述的媒体流的实时接收方法。
本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为根据本申请一个实施例的媒体流的实时递送方法的流程图；
图2为根据本申请一个实施例的客户端连续提交媒体段请求的实时传送过程示意图；
图3为根据本申请一个实施例的媒体流的实时接收方法的流程图；
图4为根据本申请一个实施例的客户端连续提交携带起始序号的媒体段请求的实时传送过程示意图；
图5为根据本申请一个实施例的媒体流的实时递送服务器的结构示意图；
图6为根据本申请一个具体实施例的媒体流的实时递送服务器的结构示意图；
图7为根据本申请一个实施例的媒体流的实时接收客户端的结构示意图；
图8为根据本申请一个具体实施例的媒体流的实时接收客户端的结构示意图。
具体实施方式
下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。
在互联网中，经常需要将各种实时产生的音频流、视频流或数据流从一个网络节点传送到另一个网络节点，这些网络节点既包括各种终端，如PC、手机、平板，也包括各种应用服务器，如视频服务器、音频服务器，将传送的这些音频流、视频流或数据流统称为媒体流。媒体流的传送过程可以用通用的客户端－服务器模型来描述：实时产生的媒体流由服务器递送给客户端。这里的服务器和客户端指的是逻辑上的功能实体，其中，服务器为发送媒体流的功能实体，客户端为接收媒体流的功能实体。服务器和客户端可存在于任何网络节点上。
每个传送的媒体流是一个实时产生的媒体单元的序列。不同的媒体流，其对应的媒体单元可以自行选择。当媒体流是一个实时产生的字节流时，可以选取一个字节为媒体单元；当媒体流是一个经过实时采样获得的音频流或视频流时，可以选取原始的音频帧或视频帧为媒体单元；当媒体流是一个经过实时采样和编码的音频流或视频流时，可以选择编码后的音频帧、编码后的视频帧或访问单元(Access Unit)为媒体单元；当媒体流是一个经过 实时采样、编码和封装的音频流或视频流时，可以选择封装后的传输包(如RTP包，PES/PS/TS包等)为媒体单元；当媒体流是一个经过实时采样、编码、封装和预分段的音频流或视频流时，可以选择一个已分割的媒体片段(如HLS协议中使用的TS格式片段、DASH协议中使用的fMP4格式片段)为媒体单元。
每个媒体单元可以关联一个产生时间，该产生时间通常为一个时间戳。每个媒体单元还可以关联一个序号，该序号可以用来表示媒体单元产生的顺序。当序号用来表示媒体单元产生的顺序时，序号的意义需要根据具体的媒体单元来定义。当媒体单元为一个字节时，媒体单元的序号为字节序号；当媒体单元为音频帧、视频帧时，媒体单元的序号为帧序号；当媒体单元为一个传输包时，媒体单元的序号为包序号；当媒体单元为一个流片段时，媒体单元的序号为片段序号(如HLS中每个TS片段的Media Sequence)。
对于一个媒体流来说，可以同时关联一个表示产生顺序的序号和一个产生时间，比如，当实时媒体流为一个RTP包流时，RTP头部既有包序号(Sequence Number)字段来指示RTP包的顺序，又有Timestramp字段来指示RTP中封装的媒体数据的产生时间。在此情况下，多个连续的RTP包可能对应相同的产生时间，但是其序号则是唯一的。
本申请实施例的方法可以针对任何一种实时媒体流来实施。在下面的实施例当中，本申请实施例将分别选择RTP实时媒体流或MPEG2-TS实时媒体流来阐述本申请实施例的实施方法。对于RTP实时流来说，媒体单元为一个RTP包，选择RTP的包序号(Sequence Number)为媒体单元的序号，RTP包的包序号为一个16位字段，最大值为65535，对于连续产生的RTP包，其序号是循环计数的，如果当前包序号为Seq，则下一个包的序号为(Seq+1)％65536，因此，序号在实现上受制于其位长，可能出现序号大小无法反映其先后顺序的情况，此时，可通过媒体单元的产生时间来判断序号是否出现循环计数，以准确判断两个媒体单元的序号的先后关系及其间隔。对于MPEG2-TS实时流来说，可以采用类似于HLS/DASH的方式，将TS流分割成固定时长比如1秒左右的TS片段，每个TS片段可包括多个媒体帧，然后将这些片段按产生顺序编上序号，作为媒体单元，每个片段中包含的第一个媒体帧的时间戳指明了该片段的产生时间。
在传统的实时流媒体协议如RTP或RTMP中，采用的是服务器推送的方式：服务器上一旦有新的媒体单元，则主动发送给客户端。本申请实施例的方法则与各种HTTP自适应流(如HLS、平滑流，MPEG-DASH)类似，采用客户端拉取的方式，但是不同点在于，现有的各种HTTP自适应流中，客户端都是根据清单文件来请求或拉取已分割好的片段，每个片段可以通过一个URL来标识，而在本申请实施例中，媒体段不是预先分割好的，而是服务器根据客户端的请求即时生成的，客户端可以***体段的内容及时长。
[根据细则91更正 02.08.2019]　
下面参照附图描述根据本申请实施例提出的媒体流的实时递送方法、实时接收方法、服务器及客户端，首先 将参照附图描述根据本申请实施例提出的媒体流的实时递送方法。
图1是本申请一个实施例的媒体流的实时递送方法的流程图。
如图1所示，该媒体流的实时递送方法，媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，方法包括以下步骤：
在步骤S101中，接收客户端发送的媒体段请求，其中，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数。
具体而言，媒体段请求可以不携带任何第一类参数和第二类参数，可以根据进一步实施的需要来定义新的参数，例如，可以作为第一类参数的控制参数包括：媒体流标识、媒体流名称等；可以作为第二类参数的控制参数包括：起始序号、起始时间、单元个数，分段时长等。
媒体段请求可以采用任何协议来提交，比如常见的HTTP协议、TCP协议、UDP协议等。当采用HTTP协议提交媒体段请求时，也可以采用HTTP-GET方式或者HTTP-POST方式。
当媒体段请求中携带控制参数时，控制参数需要采用一定的方式封装成字符串或字节流，发送给服务器。例如，当采用HTTP-GET来发送媒体段请求时，控制参数可以作为字符串封装到URL中。采用HTTP-GET的媒体段请求的示例如下：
不携带控制参数的媒体段请求：
GET“http://www.xxx-server.com/msreq”[req1]
携带一个控制参数的媒体段请求：
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？streamID＝602&seqBegin＝1020”[req7]
GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝32000”[req8]
GET“http://www.xxx-server.com/msreq？seqBegin＝1010&unitCount＝5”[req9]
GET“http://www.xxx-server.com/msreq？timeBegin＝31000&segDuration＝3000”[req10]
携带三个控制参数的媒体段请求：
GET“http://www.xxx-server.com/msreq？streamID＝601&seqBegin＝1010&unitCount＝5”[req11]
GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝33000&segDuration＝3000”[req12]
上述请求的URL中，参数名streamID、seqBegin、timeBegin、unitCount、segDuration分别代表媒体流标识、起始序号、起始时间、单元个数、分段时长。
服务器端可以采用Web服务器来接收上述客户端的媒体段请求，并从请求的URL中提取出相应的控制参数，并对控制参数进行分类：如果是媒体流标识，则该参数为第一类参数；如果为起始序号、起始时间、单元个数、分段时长，则为第二类参数。
在步骤S102中，根据媒体段请求生成媒体段，其中，根据第一类参数确定待传送的目标媒体流，根据第二类参数确定待传送的候选媒体单元，并将待传送的候选媒体单元封装成媒体段。
具体而言，服务器接收到媒体段请求后，可获取媒体段请求中携带的控制参数，然后可以根据其中的第一类参数来确定待传送的目标媒体流，根据携带的第二类参数来确定待传送的候选媒体单元，最后将待传送的候选媒体单元封装成媒体段。其中，可以采用自定义的封装协议将一个或多个媒体单元封装成媒体段，例如一个简单的封装协议如下：媒体段由段头和段净荷组成，段净荷由若干个媒体单元级联而成，段头中则指示每个媒体单元的起始位置和长度。
在步骤S103中，发送媒体段至客户端。
具体而言，服务器可以根据客户端的媒体段请求所使用的协议来选择适当的方式将媒体段发送给客户端，例如当接收的媒体段请求采用HTTP GET方式时，可以通过HTTP GET响应消息来发送生成的媒体段：将媒体段放入到HTTP响应消息的实体主体中。
当服务器接收到来自客户端的连续的媒体段请求时，服务器将根据客户端的请求来不断生成新的媒体段，这些新的媒体段中封装了最近产生的若干媒体单元，客户端解析这些媒体段，即可恢复出实时媒体流的各媒体单元，实现了媒体流从服务器到客户端的实时传送，这一过程如图2所示。
由于采用了即时生成媒体段的方式，本申请实施例的方法不再需要清单文件，从而降低传输延时和节省开销。此外，客户端可以自行调整发送请求的频率来***体段的时长，以更好的适应网络带宽的变化。
应理解，步骤S101和步骤S104的设置仅为了描述的方便，而不用于限制方法的执行 顺序。
上述是对实施例1的详细阐述，下面将对实施例2进行详细说明，以下实施例中，将对服务器如何根据媒体段请求来生成媒体段做出说明。
进一步地，在本申请的一个实施例中，根据媒体段请求生成媒体段，进一步包括：如果媒体段请求不携带第一类参数，则待传送的目标媒体流为缺省指定的媒体流；如果媒体段请求中不携带第二类参数，则候选媒体单元包括缺省指定的媒体单元，缺省指定的媒体单元为目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。
以RTP实时流为例，媒体单元为一个RTP包，每个RTP包都携带一个包序号。假定最新产生的RTP包的包序号为1020，第一预设值为20，当服务器收到一个不携带任何参数的媒体段请求时如[req1]，服务器可从现有的实时媒体流中选择一个作为目标媒体流，则待发送的候选媒体单元包括目标媒体流中最近产生的20个RTP包(包序号从1001到1020)。
以TS实时流为例，媒体单元为一个TS片段，每个TS片段都关联了一个产生时间，该产生时间为该TS片段中第一个媒体帧的时间戳。假定最新产生的TS片段的产生时间为33000(单位是微秒)，第二预设值为3000，当服务器收到一个不携带任何参数的媒体段请求时如[req1]，服务器可从现有的实时媒体流中选择一个作为目标媒体流，则待发送的候选媒体单元包括目标媒体流中最近3秒产生的TS片段，即产生时间Tp在范围(30000<Tp<＝33000)内的TS片段。
采用上述实施方式，每次用户发送的媒体段请求都会返回最近产生的若干个媒体单元。当服务器持续接受到媒体段请求后，会持续将最近产生的媒体单元递送给客户端。
实施例3，以下实施例中，将对服务器如何根据第二类参数来确定待传送的候选媒体单元进行说明。
进一步地，在本申请的一个实施例中，如果的媒体段请求携带至少一个第二类参数，其中，每个第二类参数对应着候选媒体单元的至少一个约束条件，则待传送的候选媒体单元包括目标媒体流中同时满足第二类参数对应的全部约束条件的所有媒体单元。
下面将进一步给出四种第二类参数，以及每种第二类参数对应的约束条件，具体实施时可以根据需要采用其中的一种或多种，也并不限定自行定义其他的第二类参数：
1)起始序号
起始序号对应的约束条件为：如果起始序号有效，则候选媒体单元的序号在起始序号之后，或者等于起始序号。
2)起始时间
起始时间对应的约束条件为：如果起始时间有效，则候选单元的产生时间在起始时间 之后。
3)单元个数
单元个数对应的约束条件为：如果单元个数有效，则的候选媒体单元的数目不超过单元个数；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则的候选媒体单元和最新媒体单元的序号间隔小于单元个数。
4)分段时长
分段时长对应的约束条件为：如果分段时长有效，则的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于分段时长；
上述的第二类参数有效和无效指的是参数的值是否在一个指定的范围内。以起始序号为例，该起始序号的值不能超过当前最新媒体单元的序号，另一方面，为保证实时性，起始序号的值不能是早于某个现有媒体单元的序号，在上述范围内的起始序号即为有效。如果某个第二类参数为无效，则等同于不携带这个第二类参数。当所有第二类参数均无效时，待传送的候选媒体单元为缺省指定的媒体单元。
以RTP实时流为例，媒体单元为一个RTP包，每个RTP包都携带一个包序号。假定最新产生的RTP包的包序号为1020，服务器接收到如下媒体段请求时：
1)GET“http://www.xxx-server.com/msreq？seqBegin＝1005”[req3]
该请求只携带了一个第二类参数：起始序号，满足该起始序号对应的约束条件的RTP有16个(包序号从1005到1020)，则待发送的候选媒体单元包括这16个RTP包；
2)GET“http://www.xxx-server.com/msreq？unitCount＝8”[req5]
该请求只携带一个第二类参数：单元个数，由于没有其他第二类参数指示出媒体单元的范围，则候选媒体单元的序号和最新媒体单元的序号应小于8，即待发送的候选单元包括8个RTP包(包序号从1013到1020)；
3)GET“http://www.xxx-server.com/msreq？seqBegin＝1010&unitCount＝5”[req9]
该请求携带了两个第二类参数：起始序号和单元个数，候选单元需要满足两个约束条件，第一个约束条件是候选媒体单元的序号应大于等于1010，满足该约束条件的候选媒体单元共有11个(包序号从1010到1020)，第二个条件是候选媒体单元数目应不超过5。从满足第一个约束条件的候选媒体单元中任意选出5个即可，具体实现时，可自行指定一种选取规则，如选取序号排前的5个符合约束条件的个媒体单元(包序号从1010到1014)作为待发送的候选单元。
以TS实时流为例，媒体单元为一个TS片段，每个TS片段都关联了一个产生时间，该产生时间为该TS片段中第一个媒体帧的时间戳。假定最新产生的TS片段的产生时间为 33000(单位是微秒)服务器接收到如下媒体段请求时：
1)GET“http://www.xxx-server.com/msreq？timeBegin＝31000”[req4]
该请求只携带了一个第二类参数：起始时间，该起始序号对应的约束条件是TS片段的产生时间应在起始时间之后，则候选媒体单元包括产生时间Tp在范围(31000<Tp<＝33000)内的所有TS片段；
2)GET“http://www.xxx-server.com/msreq？segDuration＝1000”[req6]
该请求只携带了一个第二类参数：分段时长。由于没有其他第二类参数指示出媒体单元的范围，因此，候选媒体单元满足的约束条件为：候选媒体单元与最新媒体单元的产生时间间隔小于1000，即候选媒体单元包括产生时间Tp范围(32000<Tp<＝33000)内的所有TS片段；
3)GET“http://www.xxx-server.com/msreq？timeBegin＝31000&segDuration＝3000”[req9]
该请求携带了两个第二类参数：起始时间和分段时长。其中，起始时间对应的约束条件是TS片段的产生时间应大于31000，则候选媒体单元包括产生时间Tp在范围(31000<Tp<＝33000)内的所有TS片段；分段时长对应的约束条件是候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于3000。显然，产生时间Tp在范围(31000<Tp<＝33000)内的所有TS片段的产生时间最大间隔不会超过2000，已同时满足了上述两个约束条件。最终，待发送的候选媒体单元即是产生时间Tp在范围(31000<Tp<＝33000)内的所有TS片段。
该实施例中，客户端可以通过连续提交媒体段请求，并通过携带的第二类参数如起始序号或起始时间，即可获得最近产生的媒体单元，实现媒体流的实时传送，图2给出了通过连续提交带起始序号的媒体段请求来实现媒体流的实时传送过程的示意图。此外，客户端还可以通过单元个数和分段时长来控制所产生的媒体段的内容和时长。
实施例4，在以下实施例中，将对服务器在生成媒体段时如何确定目标媒体流进行说明。
进一步地，在本申请的一个实施例中，第一类参数包括媒体流标识，以指定待传送的目标媒体流。
可以理解的是，第一类参数包括媒体流标识，确定待传送的目标媒体流包括：当媒体段请求中携带的第一类参数只包括媒体流标识时，目标媒体流由媒体流标识所指定。
具体而言，当服务器上存在多个实时媒体流时，服务器可以给每个实时媒体流分配一个标识，以区分不同的实时媒体流，并指定其中的一个为缺省的目标媒体流；如果服务器上只存在一个实时媒体流时，该媒体流即为缺省的目标媒体流。
当接收的媒体段请求中不携带任何第一类参数时(如实施例1中列举的媒体段请求 req1,req3～req6,req9～req10)，将缺省的目标媒体流发送给客户端；当接收的媒体段请求携带的第一类参数中包含媒体流标识时(如实施例1中列举的媒体段请求req2,req7～req8,req11～req12)，则目标媒体流为该媒体流标识所对应的实时媒体流。
实施例5，以下实施例中，将对多码率自适应的实时媒体流递送进行说明。
进一步地，在本申请的一个实施例中，将待传送的候选媒体单元封装成媒体段，进一步包括：获取媒体流索引信息，并将媒体流索引信息封装到媒体段中，其中，媒体流索引信息包含属于同一个内容的多个媒体流描述信息，媒体流描述信息包括媒体流标识和媒体流比特率。
举例而言，当服务器中存在属于同一个内容的多个实时媒体流时，可以通过不同的媒体流标识来区分这些实时流，并建立起该内容的媒体流索引信息；这个媒体流索引信息实际上包括了媒体流标识和媒体流比特率的映射关系。如表1所示，显示了同一个内容(比如一个现场演唱会直播)对应的媒体流索引信息：该内容包括了三个实时媒体流，其中媒体流1(标识为1000，码率为8Mbps)为高清码流，媒体流2(标识为1001，码率为2Mbps)为标清码流，媒体流3(标识为1002，码率为500Kbps)为移动标清流。
表1
媒体流标识 媒体流码率
601 8000Kbps
602 2000Kbps
603 500Kbps
当客户端请求媒体流标识为601的实时流时，服务器通过查询媒体流索引表，发现存在来自同一个内容源的媒体流2和媒体流3，此时，服务器可将上述媒体流索引信息作为一个控制消息，和其他媒体单元一起封装到媒体段中.
客户端可根据媒体流索引信息，根据网络传输情况从属于同一个内容的多个媒体流中选择请求的目标。一般来说，由于媒体流索引信息在一段较长时间内保持不变，所以没有必要在每个媒体段中都封装该媒体流索引信息，可以将媒体流索引信息封装到间隔选定的媒体段中，或者封装给发送给客户端的前几个媒体段中。
根据本申请实施例提出的媒体流的实时递送方法，根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，媒体分段的时长将自动适应网络传输带宽的变化，客户端可以通过主动请求来***体分段的时长，当客户端与服务器之间的传输带宽充足且延时较小时，客户端可以更快速的提出请求，从而得到时 长更短的媒体段，降低实时传输延时；当客户端与服务器之间的传输带宽不足且延时较大时，客户端可以延长提交请求的间隔，从而得到更长的媒体段，减少请求次数以降低传输开销；由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，客户端也不需要请求和解析清单文件，一方面客户端可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。
图3是本申请一个实施例的媒体流的实时接收方法的流程图。
如图3所示，该媒体流的实时接收方法，媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，方法包括以下步骤：
在步骤S301中，发送媒体段请求至服务器，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数。
其中，在本申请的一个实施例中，第二类参数包括起始序号、单元个数、起始时间和分段时长中的一项或多项。
媒体段请求可以采用任何协议来提交，比如常见的HTTP协议、TCP协议、UDP协议等。当采用HTTP协议提交媒体段请求时，也可以采用HTTP-GET方式或者HTTP-POST方式。
当媒体段请求中携带控制参数时，控制参数需要采用一定的方式封装成字符串或字节流，发送给服务器。例如，当采用HTTP-GET来发送媒体段请求时，控制参数可以作为字符串封装到URL中。采用HTTP-GET的媒体段请求的示例如下：
不携带控制参数的媒体段请求：
GET“http://www.xxx-server.com/msreq”[req1]
携带一个控制参数的媒体段请求：
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？streamID＝602&seqBegin＝1020”[req7]
GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝32000”[req8]
GET“http://www.xxx-server.com/msreq？seqBegin＝1010&unitCount＝5”[req9]
GET“http://www.xxx-server.com/msreq？timeBegin＝31000&segDuration＝3000”[req10]
携带三个控制参数的媒体段请求：
GET“http://www.xxx-server.com/msreq？streamID＝601&seqBegin＝1010&unitCount＝5”[req11]
GET“http://www.xxx-server.com/msreq？streamID＝601&timeBegin＝33000&segDuration＝3000”[req12]
上述请求的URL中，参数名streamID、seqBegin、timeBegin、unitCount、segDuration分别代表媒体流标识、起始序号、起始时间、单元个数、分段时长。
在步骤S302中，接收服务器反馈的媒体段，其中，媒体段由服务器根据媒体段请求生成，并封装有指定目标媒体流的候选媒体单元。
具体而言，客户端可以使用和发送媒体段请求相同的协议来接收服务器返回的媒体段，比如当客户端采用HTTP GET来发送媒体段请求时，即可通过HTTP GET响应消息来接收媒体段。
在步骤S303中，解析媒体段，其中，根据媒体段中解析出媒体单元，并生成媒体单元的接收报告。
具体而言，解析接收的媒体段，包括：从接收的媒体段中解析出媒体单元，生成媒体单元接收报告；媒体段的解析是媒体段封装的逆过程，因此，首先要确定服务器端所采用的封装协议，这可以由服务器端和客户端在传送媒体流之前约定。例如，服务器采用以下自定义封装协议：媒体段有段头和段净荷组成，段净荷由若干个媒体单元级联而成，段头中则指示每个媒体单元的起始位置和长度。此时，对于客户端来说，可以首先通过段头来获得各媒体单元的起始位置和长度，然后从段净荷中解析出各媒体单元。当媒体单元为RTP包时，可以从每个RTP包的包头中，即可得到每个媒体单元的序号和产生时间，根据接收成功的RTP包的序号和产生时间，即可生成媒体单元接收报告。
在步骤S304中，根据媒体单元的接收报告生成新媒体段请求，其中，确定新媒体段请求携带的控制参数。
具体而言，根据媒体单元接收报告生成新的媒体段请求，包括，确定媒体段请求携带的控制参数。客户端可以通过媒体单元接收报告得到当前实时媒体流的接收进度，为了实现实时媒体流的持续接收，客户端生成新的媒体段请求。通过调整新的媒体端请求中携带的控制参数，客户端对下次接收的媒体段的内容进行控制，以保证媒体流 的接收效率。
应理解，步骤S301和步骤S304的设置仅为了描述的方便，而不用于限制方法的执行顺序。
以下实施例中，将对客户端如何发送媒体段进行说明。
进一步地，在本申请的一个实施例中，发送媒体段请求至服务器，进一步包括：如果未收到服务器发送的任何媒体单元，则向服务器发送初始媒体段请求；如果根据接收报告生成新媒体段请求，则向服务器发送新媒体段请求。
可以理解的是，当客户端未收到任何媒体单元时，向服务器发送初始媒体段请求；当客户端根据媒体单元接收报告生成新的媒体段请求后，向服务器发送新生成的媒体段请求，其中，初始媒体段请求不携带任何第二类参数，或者包含以下第二类参数之一：起始序号、单元个数、起始时间、分段时长。
具体而言，当客户端未收到任何媒体单元时，向服务器发送初始媒体段请求；当客户端根据媒体单元接收报告生成新的媒体段请求后，立即或在指定的时间向服务器发送新生成的媒体段请求。
以RTP实时流接收为例。初始时，客户端没有收到任何媒体单元，客户端可以立即发送一个初始媒体段请求。初始媒体段请求可以不携带任何第二类参数(如前述列举的req1和req2)，此时，服务器可将实时媒体流最近产生的固定个数(如3个)RTP包封装为媒体段返回客户端，或者将实时媒体流在最近固定时间(例如2秒)内产生的RTP包封装为媒体段返回给客户端。当客户端接收到服务器返回的第一个媒体段时，客户端通过解析媒体段，获得媒体单元接收报告，从中可了解当前已经接收了哪些媒体单元，然后在新生成的媒体段请求，包括，设置新的媒体段请求中的控制参数，以保证下次请求的媒体单元是客户端所需要的。为了控制下次媒体段的时长，客户端可以立即或者通过延时一段时间向服务器发送新生成的媒体段请求。
可选择地，初始媒体段请求可包括一个第二类控制参数：起始序号。起始序号则可以指示客户端期望接收从哪个序号开始的媒体单元。起始序号用来指示客户端期望从哪个序号开始的媒体单元；起始序号的值可以任意指定，比如0。对于服务器来说，起始序号可能是有效的，即该起始序号是最近产生的媒体单元的序号，但当起始序号无效时，服务器会自动选择缺省指定的媒体单元封装为媒体段。
可选择地，初始媒体段请求可包括一个第二类控制参数：单元个数。单元个数用来指示客户端期望接收多少个最近产生的媒体单元，例如10个。
可选择地，初始媒体段请求可包括一个第二类控制参数：起始时间。起始时间用来指示客户端期望从哪个时间点开始的媒体单元；起始时间的值可以任意指定，比如0。对于 服务器来说，起始时间可能是有效的，即起始时间举例最新媒体单元的产生时间在一个指定范围内，也可能是无效的。当起始时间是无效时，服务器会自动选择缺省指定的媒体单元封装为媒体段。
可选择地，初始媒体段请求可包括一个第二类控制参数：分段时长。分段时长用来指示客户端期望接收最近多长时间内产生的媒体单元。
一般来说，通过发送初始媒体段请求给服务器，无论是否携带第二类控制参数，客户端可以得到实时媒体流的最新媒体单元，从而了解当前实时媒体流的发送进度，为生成新的媒体段请求提供条件。
此外，当客户端未收到任何媒体单元时，还可以根据与服务器的直接交互来了解实时媒体流的产生情况，比如直接获得实时媒体流的最新媒体单元的序号，这样，可以设置初始媒体段请求中的第二类参数。
以下实施例中，将对客户端如何根据媒体单元接收报告来生成媒体段请求进行说明。
进一步地，在本申请的一个实施例中，接收报告包含当前接收成功的媒体单元的序号，其中，如果新媒体段请求携带的第二类参数包括起始序号，则起始序号的值为当前接收成功的最新媒体单元的下一个单元的序号值。
可以理解的是，媒体单元接收报告指示了当前接收成功的媒体单元的序号；根据媒体单元接收报告生成新的媒体段请求包括：新媒体段请求携带的第二类参数包括起始序号；起始序号的值为当前接收成功的最新媒体单元的下一个单元的序号值，通常来讲，下一个单元的序号值就是在原单元序号值加1，如果序号是循环计数的，则要判断结果是否超过其上限，如果超过，则下一个单元的序号值应重新计数。
具体而言，客户端的媒体单元接收报告由客户端在解析服务器返回的媒体段后产生，用来描述客户端上媒体单元的接收情况，可作为生成新的媒体段请求的参考。以RTP实时流接收为例，每个媒体单元为一个RTP包，媒体单元的序号即为RTP包的序号。一个媒体段可以封装多个RTP包。当客户端从接收的媒体段中解析出RTP包时，通过RTP包头，即可得到该RTP包的包序号。假设一个媒体段中封装了包序号从20到22的3个RTP包，则当客户端完全成功接收这个媒体段时，通过解析媒体段，可以获得一个媒体单元接收报告，该报告即是由成功接收的RTP包序号构成的一个列表：{20，21，22}，此时，客户端生成新的媒体段请求时，可以携带一个第二类参数：起始序号。通过单元接收报告，可知最新媒体单元的序号为22，那么下一个媒体单元的序号应为23，则新媒体段请求中携带的起始序号的值为23。图4给出了客户端连续提交起始序号的传输过程。
以下实施例中，将对客户端如何根据媒体单元接收报告来生成媒体段请求进行说明。
进一步地，在本申请的一个实施例中，接收报告包含当前接收成功的媒体单元的产生 时间，其中，如果新媒体段请求携带的第二类参数包括起始时间，则起始时间的值为当前接收成功的最新媒体单元的产生时间。
具体而言，以TS实时流接收为例，每个媒体单元为一个TS片段，一个TS片段封装了固定时间段如1秒左右的多个媒体帧，每个片段中包含的第一个媒体帧的时间戳指明了该片段的产生时间。当一个媒体段封装多个TS片段时，可在该媒体段的头部封装所有TS片段的序号及产生时间。
当客户端接收到返回的媒体段时，可从中解析出多个TS片段，并通过媒体段头，得到每个TS片段的序号及产生时间。假设一个媒体段中封装了包序号从101到103的3个TS片段，则当客户端完全成功接收这个媒体段时，通过解析媒体段，可以获得一个媒体单元接收报告，该报告即是由成功接收的TS片段的序号及其产生时间构成的一个列表：{(101，15000)，(102，20000)，(103，25000)}，此时，客户端生成新的媒体段请求时，可以携带一个第二类参数：起始时间。起始时间的取值即为当前成功接收的最新媒体单元的起始时间。当服务器接收到此请求时，服务器生成媒体段时封装的媒体单元的产生时间必须在此起始时间之后。这样，通过连续提交携带起始时间的媒体段请求，客户端可获得最新产生的未成功接收的媒体单元。
以下实施例中，将对客户端接收媒体段的过程进行说明。
进一步地，在本申请的一个实施例中，在接收服务器反馈的媒体段之前，还包括：在发送媒体段请求后，检测媒体段的反馈时间；如果反馈时间超过预设时间，则终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
可以理解的是，接收服务器返回的媒体段必须在一个设定的接收时间之前完成，如果到达该接收时间而未完成，则终止当前媒体段的接收；解析接收的媒体段包括对未完全接收的媒体段的解析。
具体而言，当客户端向服务器发送了媒体段请求后，转入了对服务器返回的媒体段请求的接收。如果服务器和客户端之间的网络传输条件很好，媒体段是能够正常的发送给客户端的。但是，如果服务器和客户端之间的网络传输条件不稳定时，例如发生了链路故障或拥塞等，可能导致媒体段出现错误或丢失。
当媒体段采用TCP或HTTP等面向连接的传输协议时，一旦发生错误，则会启动重传，这种重传可能持续较长时间，从而无法保证实时媒体流传送的实时特性。因此，客户端在发送完媒体段请求后，可以启动一个定时，给媒体段的接收设定一个最迟的接收时间，如果到达此接收时间仍未接收完所请求的媒体段，则应终止当前媒体段的接收，比如自动终止TCP或HTTP连接，并对已接收的部分媒体段进行解析，生成媒体单元接收报告，并重新提交媒体段请求，这样，可以防止由于某个媒体段的接收故障影响后续的实时流接收。
以下实施例中，将对实时媒体流接收时的码率自适应进行说明。
进一步地，在本申请的一个实施例中，还包括：接收服务器发送的媒体流索引信息，其中，媒体流索引信息包含属于同一个内容的多个媒体流描述信息，媒体流描述信息包括媒体流标识和媒体流比特率。
可以理解的是，客户端从服务器获得媒体流索引信息，媒体流索引信息包含了属于同一个内容的若干个媒体流描述信息；媒体流描述信息包括：媒体流标识和媒体流比特率。
其中，在本申请的一个实施例中，根据媒体单元的接收报告生成新媒体段请求，进一步包括：在新媒体段请求携带的第一类参数包括媒体流标识时，则根据当前传输速率和媒体流索引信息确定媒体流标识，并根据媒体段的接收时间得到当前传输速率。
可以理解的是，根据媒体单元接收报告生成新的媒体段请求包括：新的媒体段请求携带的第一类参数包括媒体流标识；媒体流标识可以通过媒体流的当前传输速率及媒体流索引信息来决定；媒体流的当前传输速率可根据媒体段的接收时间来估计。
进一步地，在本申请的一个实施例中，接收服务器发送的媒体流索引信息，进一步包括：根据接收的媒体段解析得到媒体流索引信息，其中，媒体流索引信息由服务器封装到媒体段中。
可以理解的是，客户端从服务器获得媒体流索引信息的方法：客户端从接收的媒体段中解析出媒体流索引信息，媒体流索引信息由服务器封装到发送给客户端的媒体段中。
具体而言，当服务器中存在属于同一个内容的多个实时媒体流时，可以通过不同的媒体流标识来区分这些实时流，并建立起该内容的媒体流索引信息；这个媒体流索引信息实际上包括了媒体流标识和媒体流比特率的映射关系。图中显示了同一个内容(比如一个现场演唱会直播)对应的媒体流索引信息：该内容包括了三个实时媒体流，其中媒体流1(标识为1000，码率为8Mbps)为高清码流，媒体流2(标识为1001，码率为2Mbps)为标清码流，媒体流3(标识为1002，码率为500Kbps)为移动标清流，如表2所示。
表2
媒体流标识 媒体流码率
601 8000Kbps
602 2000Kbps
603 500Kbps
客户端可以通过各种方法从服务器获得指定内容的媒体流索引信息。其中一种方法是：将客户端请求任一个媒体流时，服务器将该媒体流所对应的媒体流索引信息封装到媒体段中返回给客户端，客户端从接收的媒体段中解析出媒体流索引信息。举例来说，当客户端 请求媒体流标识为601的实时媒体流，服务器发现媒体流601和其他两个码率的实时媒体流602和603都对应同一个内容，即将该媒体流索引信息{(601,8000)，(602，2000)，(603，500)}封装到媒体段的段头，返回给客户端。客户端解析媒体段的段头，即可获得该索引信息。客户端还可通过其他方法来获得媒体流索引信息，比如直接向服务器发送请求来获取等等。
当客户端发现所请求的内容存在多个码率的实时媒体流时，可以根据当前的媒体流传输速率来自动选择特定码率的实时媒体流，避免出现大量的丢包和延时，以提高客户端的接收性能。为了获得当前的媒体流传输速率，客户端可以记录每个媒体段的接收时间。媒体段的接收时间，是指接收媒体段的全部或部分数据所经过的时间。通过媒体段的接收时间可以估算出当前的媒体流传输速率，一种简单的估算方法是：
媒体流传输速率＝接收数据量/接收时长；
一旦获得了当前的媒体流传输速率，客户端可以从媒体流索引中选择一个码率与该传输速率接近的媒体流，并将其对应的媒体流标识作为新的媒体段请求中携带的第一类参数。例如，当客户端请求媒体流601时，通过接收的媒体段来测算，其实际的媒体流传输速率为3000Kbps，显然，当前的媒体流传输速率远低于媒体流601的实际码率8000Kbps，但高于媒体流602的实际码率2000Kbps，因此，客户端生成新的媒体段请求时，应该将携带的媒体流标识更改为602，以达到较好的传输性能。
当发生媒体流标识的更改时，还可以根据当前码流的接收情况(如接收到的最新媒体单元的序号和产生时间)来确定新的媒体段请求所携带的第二类参数。为了实现完全的平滑切换，属于同一个内容的多个实时媒体流应该是同步产生的，即拥有相同序号或产生时间的媒体单元对应着相同的内容片段(如同一个图像或一段语音等)。
根据本申请实施例提出的媒体流的实时接收方法，通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来***体段的内容及时长，按需生成的媒体段可以更好适应动态的网络传输环境，客户端可以通过主动请求来***体分段的时长：当客户端与服务器之间的传输带宽充足且延时较小时，客户端可以更快速的提出请求，从而得到时长更短的媒体段，降低实时传输延时；当客户端与服务器之间的传输带宽不足且延时较大时，客户端可以延长提交请求的间隔，从而得到更长的媒体段，减少请求次数以降低传输开销；由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，也不需要请求和解析清单文件，一方面可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
其次参照附图描述根据本申请实施例提出的媒体流的实时递送服务器。
图5是本申请一个实施例的媒体流的实时递送服务器的结构示意图。
如图5所示，该媒体流的实时递送服务器10包括：客户端接口组件100和媒体段生成组件200。
其中，客户端接口组件100用于接收客户端发送的媒体段请求并返回相应的媒体段，其中，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数。媒体段生成组件200根据媒体段请求生成媒体段，其中，根据第一类参数确定待传送的目标媒体流，根据第二类参数确定待传送的候选媒体单元，并将待传送的候选媒体单元封装成媒体段，并通过客户端接口组件100发送媒体段至客户端。本申请实施例的服务器10根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。
具体而言，客户端接口组件100用于接收客户端的媒体段请求，以及将生成的媒体段发送给客户端；媒体段请求可以携带0个、1个或多个控制参数；控制参数包括以下类别：第一类参数和第二类参数；第一类参数用于指示待传送的目标媒体流；第二类参数用于指示待传送的候选媒体单元。客户端接口组件可以采用任何指定的协议来接收媒体段请求，例如，当采用HTTP协议时，客户端接口组件可以是一个Web服务器，可以接收任何采用http协议的媒体段请求并且通过HTTP响应来返回媒体段；当采用TCP协议时，客户端接口组件是一个TCP服务器，并提供一个固定的服务端口。
媒体段生成组件200用于根据客户端的媒体段请求来生成所需的媒体段。从客户端接口组件获取媒体段请求及其控制参数，根据第一类参数来确定待传送的目标媒体流，根据第二类参数来确定待传送的候选媒体单元，从媒体流存储单元中提取出待传送的候选媒体单元，将其封装成媒体段，然后直接交由客户端接口组件来发送。
进一步，如图6所示，本申请实施例的服务器10还包括至少一个实时媒体流生成组件，用于自行产生或接收来自其他服务器的一个或多个实时媒体流；媒体流是一个实时产生的媒体单元的序列；每个媒体单元都关联有一个产生时间和/或一个序号，序号用来表示媒体单元产生的顺序；
具体而言，实时媒体流生成组件可能包括媒体流生成的一个或多个处理步骤，例如，处理步骤包括但不限于：媒体信号的实时采集、编码压缩、传输封装和预分段。此外，实时媒体流生成组件还可以接收来自其他装置的实时媒体流，或者将一个已存在的媒体流文件转换成实时流。
进一步地，在本申请的一个实施例中，媒体段生成组件进一步用于在媒体段请求不携 带第一类参数时，待传送的目标媒体流为缺省指定的媒体流，并在的媒体段请求中不携带第二类参数时，候选媒体单元包括缺省指定的媒体单元，缺省指定的媒体单元为目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。
进一步地，在本申请的一个实施例中，如果媒体段请求携带至少一个第二类参数，其中，每个第二类参数对应着候选媒体单元的至少一个约束条件，则待传送的候选媒体单元包括目标媒体流中同时满足第二类参数对应的全部约束条件的所有媒体单元。
进一步地，在本申请的一个实施例中，第二类参数包括起始序号，起始序号对应的约束条件为：如果起始序号有效，则候选媒体单元的序号在起始序号之后，或者等于起始序号。
进一步地，在本申请的一个实施例中，第二类参数包括起始时间，起始时间对应的约束条件为：如果起始时间有效，则候选单元的产生时间在起始时间之后。
进一步地，在本申请的一个实施例中，第二类参数包括单元个数，单元个数对应的约束条件为：如果单元个数有效，则的候选媒体单元的数目不超过单元个数；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则的候选媒体单元和最新媒体单元的序号间隔小于单元个数。
进一步地，在本申请的一个实施例中，第二类参数包括分段时长，分段时长对应的约束条件为：如果分段时长有效，则的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于分段时长；进一步，如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则的候选媒体单元和最新媒体单元的产生时间间隔小于分段时长。
进一步地，在本申请的一个实施例中，第一类参数包括媒体流标识，以指定待传送的目标媒体流。
进一步地，在本申请的一个实施例中，媒体段生成组件进一步用于获取媒体流索引信息，并将媒体流索引信息封装到媒体段中，其中，的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，的媒体流描述信息包括媒体流标识和媒体流比特率。
需要说明的是，前述对媒体流的实时递送方法实施例的解释说明也适用于该实施例的媒体流的实时递送服务器，此处不再赘述。
根据本申请实施例提出的媒体流的实时递送服务器，根据客户端的请求来实时生成媒体段，并返回给客户端，以实现按客户端需求分段的实时媒体流递送，媒体分段的时长将自动适应网络传输带宽的变化，客户端可以通过主动请求来***体分段的时长，当客户端与服务器之间的传输带宽充足且延时较小时，客户端可以更快速的提出请求，从而得到时长更短的媒体段，降低实时传输延时；当客户端与服务器之间的传输带宽不足且延时较 大时，客户端可以延长提交请求的间隔，从而得到更长的媒体段，减少请求次数以降低传输开销；由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，客户端也不需要请求和解析清单文件，一方面客户端可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效降低媒体流传输延时和开销，进一步提高实时媒体流的传输性能。
图7是本申请一个实施例的媒体流的实时接收客户端的结构示意图。
如图7所示，该媒体流的实时接收客户端1000包括：服务器接口组件1、媒体段解析组件2和媒体流传输控制组件3。
其中，服务器接口组件1用于发送媒体段请求至服务器，媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数，并接收服务器反馈的媒体段，其中，媒体段由服务器根据媒体段请求生成，并封装有指定目标媒体流的候选媒体单元。媒体段解析组件2用于解析媒体段，其中，根据媒体段中解析出媒体单元，并生成媒体单元的接收报告。媒体流传输控制组件3用于根据媒体单元的接收报告生成新媒体段请求，其中，确定新媒体段请求携带的控制参数。本申请实施例的客户端1000通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来***体段的内容及时长，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
在本申请的一个实施例中，服务器接口组件可以使用HTTP协议来发送媒体段请求并接收返回的媒体段。
对于客户端来讲，服务器接口组件1可以采用任何网络传输协议来发送媒体段请求及接收服务器返回的媒体段，如UDP协议，TCP协议和HTTP协议等。当服务器接口组件采用HTTP协议来提交媒体段请求并接收服务器返回的媒体段时，该服务器接口组件包含了HTTP客户端的功能：媒体段请求的参数可以封装为字符串作为HTTP GET的URL的一部分，而服务器生成的媒体段可封装到HTTP GET的响应消息中返回给客户端。
以下实施例中，将对媒体流传输控制组件中生成媒体段请求的方法进行说明。媒体段请求的生成可划分为两个阶段：
阶段1：当媒体流传输控制组件3未收到任何媒体单元接收报告时，生成初始媒体段请求；初始媒体段请求不携带任何第二类参数，或者包含以下第二类参数之一：起始序号、单元个数、起始时间、分段时长；上述第二类参数的值可缺省指定。通过发送初始媒体段请求，客户端可以接收到服务器返回的第一个媒体段，媒体段解析组件2则会产生媒体单元接收报告，发送给媒体流传输控制组件3。
阶段2：当媒体流传输控制组件3接收到媒体单元接收报告时，将根据媒体单元接收报告的内容来生成新的媒体段请求。
当接收的媒体单元接收报告指示了当前接收成功的媒体单元的序号时，生成的媒体段请求中携带的第二类参数包括起始序号；起始序号的值为当前接收成功的最新媒体单元的下一个单元的序号值；
当接收的媒体单元接收报告指示了当前接收成功的媒体单元的产生时间时，生成的媒体段请求中携带的第二类参数包括起始时间；起始时间的值为当前接收成功的最新媒体单元的产生时间。
以下实施例中，将对媒体流传输控制组件中支持码率自适应的媒体段请求的生成方法进行说明。
当同一个内容包括多个不同码率的实时媒体流时，媒体流传输控制组件3还可以支持码率自适应。媒体流传输控制组件3需要首先获得该内容的媒体流索引信息，媒体流索引信息包含了属于同一个内容的若干个媒体流描述信息；媒体流描述信息包括：媒体流标识和媒体流比特率。获取媒体流索引信息的方法可以由客户端主动请求，也可以由服务器主动发送给客户端。
在获得媒体流索引信息后，媒体流传输控制组件3在生成媒体段请求时，可以调整其携带的第一类参数：媒体流标识。媒体流传输控制组件3将根据当前媒体流的当前传输速率和媒体流索引信息来选择媒体流标识，保证所选择的媒体流的比特率与当前传输速率相匹配，以提高传输的可靠性并减少传输延时。媒体流的当前传输速率可根据媒体段的接收时间来估计，比如监测若干个时间段内(比如1秒)接收的数据量。
以下实施例中，将对一种用于客户端接收实时媒体流的方法进行说明。
在一些应用场景中，实时媒体流可以一边接收一边播放，为了支持上述功能，可以在现有的组件基础上引入一个媒体回放组件，由媒体回放组件来实时回放接收的媒体单元，如图8所示：
在具体实现过程中，媒体回放组件的功能可以包含多个处理步骤。以媒体单元为RTP包为例，为了完成RTP包的播放，媒体回放组件首先需要从RTP包中解封装，从RTP净荷中恢复媒体帧，如果该媒体帧采用了压缩，则需要对其进行解压缩，并对解压缩后得到的原始码流进行播放。
进一步地，在本申请的一个实施例中，媒体流传输控制组件3进一步用于在未收到服务器发送的任何媒体单元时，向服务器发送初始媒体段请求，并在根据接收报告生成新媒体段请求时，向服务器发送新媒体段请求。
进一步地，在本申请的一个实施例中，第二类参数包括起始序号、单元个数、起始时 间和分段时长中的一项或多项。
进一步地，在本申请的一个实施例中，接收报告包含当前接收成功的媒体单元的序号，其中，如果新媒体段请求携带的第二类参数包括起始序号，则起始序号的值为当前接收成功的最新媒体单元的下一个单元的序号值。
进一步地，在本申请的一个实施例中，接收报告包含当前接收成功的媒体单元的产生时间，其中，如果新媒体段请求携带的第二类参数包括起始时间，则起始时间的值为当前接收成功的最新媒体单元的产生时间。
进一步地，在本申请的一个实施例中，在接收服务器反馈的媒体段之前，本申请实施例的客户端1000还包括：检测模块。其中，检测模块用于在发送媒体段请求后，检测媒体段的反馈时间，并在反馈时间超过预设时间时，终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
进一步地，在本申请的一个实施例中，媒体流传输控制组件3进一步用于接收服务器发送的媒体流索引信息，其中，媒体流索引信息包含属于同一个内容的多个媒体流描述信息，媒体流描述信息包括媒体流标识和媒体流比特率。
进一步地，在本申请的一个实施例中，媒体流传输控制组件3进一步用于在新媒体段请求携带的第一类参数包括媒体流标识时，则根据当前传输速率和媒体流索引信息确定媒体流标识，并根据媒体段的接收时间得到当前传输速率。
进一步地，在本申请的一个实施例中，媒体流传输控制组件3进一步用于根据接收的媒体段解析得到媒体流索引信息，其中，媒体流索引信息由服务器封装到媒体段中。
需要说明的是，前述对媒体流的实时接收方法实施例的解释说明也适用于该实施例的媒体流的实时接收客户端，此处不再赘述。
根据本申请实施例提出的媒体流的实时接收客户端，通过持续向服务器发送媒体段请求，服务器根据接收的媒体段请求来生成媒体段并返回给客户端，并通过请求中携带的参数及发送请求的间隔来***体段的内容及时长，按需生成的媒体段可以更好适应动态的网络传输环境，客户端可以通过主动请求来***体分段的时长：当客户端与服务器之间的传输带宽充足且延时较小时，客户端可以更快速的提出请求，从而得到时长更短的媒体段，降低实时传输延时；当客户端与服务器之间的传输带宽不足且延时较大时，客户端可以延长提交请求的间隔，从而得到更长的媒体段，减少请求次数以降低传输开销；由于每个媒体段是由客户端的请求触发产生的，不再需要清单文件，也不需要请求和解析清单文件，一方面可以更快速的获得最新的媒体流，减少了实时媒体流的传输延时，另一方面，也降低了清单文件带来的传输开销和处理开销，从而有效减少传输延时和开销，进一步提高实时媒体流的传输性能。
为了实现上述实施例，本申请实施例还提出了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行程序时，实现如上述实施例描述的媒体流的实时递送方法，或者如上述实施例描述的媒体流的实时接收方法。
为了实现上述实施例，本申请实施例还提出了一种非临时性计算机可读存储介质，该程序被处理器执行时实现如上述实施例描述的媒体流的实时递送方法，或者如上述实施例描述的媒体流的实时接收方法。
为了实现上述实施例，本申请实施例还提出了一种计算机程序产品，当计算机程序产品中的指令由处理器执行时，执行如上述实施例描述的媒体流的实时递送方法，或者如上述实施例描述的媒体流的实时接收方法。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (40)

  1. 一种媒体流的实时递送方法，其特征在于，所述媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括以下步骤：
    接收客户端发送的媒体段请求，其中，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；
    根据所述媒体段请求生成媒体段，其中，根据所述第一类参数确定所述待传送的目标媒体流，根据所述第二类参数确定所述待传送的候选媒体单元，并将所述待传送的候选媒体单元封装成所述媒体段；以及
    发送所述媒体段至所述客户端。
  2. 根据权利要求1所述的媒体流的实时递送方法，其特征在于，所述根据所述媒体段请求生成媒体段，进一步包括：
    如果所述媒体段请求不携带所述第一类参数，则所述待传送的目标媒体流为缺省指定的媒体流；
    如果所述的媒体段请求中不携带所述第二类参数，则所述候选媒体单元包括缺省指定的媒体单元，所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。
  3. 根据权利要求1所述的媒体流的实时递送方法，其特征在于，所述根据媒体段请求生成媒体段，进一步包括：
    如果所述媒体段请求携带至少一个所述第二类参数，其中，所述每个第二类参数对应着候选媒体单元的至少一个约束条件，则所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
  4. 根据权利要求3所述的媒体流的实时递送方法，其特征在于，所述第二类参数包括起始序号，所述起始序号对应的约束条件为：
    如果所述起始序号有效，则所述候选媒体单元的序号在所述起始序号之后，或者等于所述起始序号。
  5. 根据权利要求3所述的媒体流的实时递送方法，其特征在于，所述第二类参数包括起始时间，所述起始时间对应的约束条件为：
    如果所述起始时间有效，则所述候选单元的产生时间在起始时间之后。
  6. 根据权利要求3所述的媒体流的实时递送方法，其特征在于，所述第二类参数包括单元个数，所述单元个数对应的约束条件为：
    如果所述单元个数有效，则所述的候选媒体单元的数目不超过所述单元个数；
    如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的序号间隔小于所述单元个数。
  7. 根据权利要求3所述的媒体流的实时递送方法，其特征在于，所述第二类参数包括分段时长，所述分段时长对应的约束条件为：
    如果所述分段时长有效，则所述的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于所述分段时长；
    如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的产生时间间隔小于所述分段时长。
  8. 根据权利要求1所述的媒体流的实时递送方法，其特征在于，所述第一类参数包括媒体流标识，以指定所述待传送的目标媒体流。
  9. 根据权利要求8所述的媒体流的实时递送方法，其特征在于，所述将所述待传送的候选媒体单元封装成所述媒体段，进一步包括：
    获取媒体流索引信息，并将所述媒体流索引信息封装到所述媒体段中，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
  10. 一种媒体流的实时接收方法，其特征在于，所述的媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述方法包括：
    发送媒体段请求至服务器，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；
    接收所述服务器反馈的媒体段，其中，所述媒体段由所述服务器根据所述媒体段请求生成，并封装有指定所述目标媒体流的候选媒体单元；
    解析所述媒体段，其中，根据所述媒体段中解析出媒体单元，并生成所述媒体单元的接收报告；以及
    根据所述媒体单元的接收报告生成新媒体段请求，其中，确定所述新媒体段请求携带的控制参数。
  11. 根据权利要求10所述的媒体流的实时接收方法，其特征在于，所述发送媒体段请求至服务器，进一步包括：
    如果未收到所述服务器发送的任何媒体单元，则向所述服务器发送初始媒体段请求；
    如果根据所述接收报告生成所述新媒体段请求，则向所述服务器发送所述新媒体段请求。
  12. 根据权利要求10所述的媒体流的实时接收方法，其特征在于，所述第二类参数包括起始序号、单元个数、起始时间和分段时长中的一项或多项。
  13. 根据权利要求12所述的媒体流的实时接收方法，其特征在于，所述接收报告包含当前接收成功的媒体单元的序号，其中，
    如果所述新媒体段请求携带的第二类参数包括起始序号，则所述起始序号的值为所述当前接收成功的最新媒体单元的下一个单元的序号值。
  14. 根据权利要求12所述的媒体流的实时接收方法，其特征在于，所述接收报告包含当前接收成功的媒体单元的产生时间，其中，
    如果所述新媒体段请求携带的第二类参数包括起始时间，则所述起始时间的值为所述当前接收成功的最新媒体单元的产生时间。
  15. 根据权利要求10所述的媒体流的实时接收方法，其特征在于，在接收所述服务器反馈的媒体段之前，还包括：
    在发送所述媒体段请求后，检测所述媒体段的反馈时间；
    如果所述反馈时间超过预设时间，则终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
  16. 根据权利要求10所述的媒体流的实时接收方法，其特征在于，还包括：
    接收所述服务器发送的媒体流索引信息，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
  17. 根据权利要求16所述的媒体流的实时接收方法，其特征在于，所述根据所述媒体单元的接收报告生成新媒体段请求，进一步包括：
    在所述新媒体段请求携带的第一类参数包括所述媒体流标识时，则根据当前传输速率和所述媒体流索引信息确定所述媒体流标识，并根据所述媒体段的接收时间得到所述当前传输速率。
  18. 根据权利要求16或17所述的媒体流的实时接收方法，其特征在于，所述接收所述服务器发送的媒体流索引信息，进一步包括：
    根据接收的媒体段解析得到所述媒体流索引信息，其中，所述的媒体流索引信息由所述服务器封装到所述媒体段中。
  19. 一种媒体流的实时递送服务器，其特征在于，所述媒体流为实时产生的媒体单元的序列，其中，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述服务器包括：
    客户端接口组件，用于接收客户端发送的媒体段请求并返回相应的媒体段，其中，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数；
    媒体段生成组件，根据所述媒体段请求生成媒体段，其中，根据所述第一类参数确定所述待传送的目标媒体流，根据所述第二类参数确定所述待传送的候选媒体单元，并将所述待传送的候选媒体单元封装成所述媒体段，并通过所述客户端接口组件发送所述媒体段至所述客户端。
  20. 根据权利要求19所述的媒体流的实时递送服务器，其特征在于，所述媒体段生成组件进一步用于在所述媒体段请求不携带所述第一类参数时，所述待传送的目标媒体流为缺省指定的媒体流，并在所述的媒体段请求中不携带所述第二类参数时，所述候选媒体单元包括缺省指定的媒体单元，所述缺省指定的媒体单元为所述目标媒体流中所有和最新媒体单元的序号间隔小于第一预设值的媒体单元，或者为所述目标媒体流中所有和最新媒体单元的产生时间间隔小于第二预设值的媒体单元。
  21. 根据权利要求19所述的媒体流的实时递送服务器，其特征在于，所述的媒体段生成组件进一步用于在所述的媒体段请求中携带至少一个所述第二类参数时，其中，所述每个第二类参数对应着候选媒体单元的至少一个约束条件，所述待传送的候选媒体单元包括所述目标媒体流中同时满足所述第二类参数对应的全部约束条件的所有媒体单元。
  22. 根据权利要求21所述的媒体流的实时递送服务器，其特征在于，所述第二类参数包括起始序号，所述起始序号对应的约束条件为：如果所述起始序号有效，则所述候选媒体单元的序号在所述起始序号之后，或者等于所述起始序号。
  23. 根据权利要求21所述的媒体流的实时递送服务器，其特征在于，所述第二类参数包括起始时间，所述起始时间对应的约束条件为：如果所述起始时间有效，则所述候选单元的产生时间在起始时间之后。
  24. 根据权利要求21所述的媒体流的实时递送服务器，其特征在于，所述第二类参数包括所述单元个数，所述单元个数对应的约束条件为：
    如果所述单元个数有效，则所述的候选媒体单元的数目不超过所述单元个数；
    如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的序号间隔小于所述单元个数。
  25. 根据权利要求21所述的媒体流的实时递送服务器，其特征在于，所述第二类参数包括分段时长，所述分段时长对应的约束条件为：
    如果所述分段时长有效，则所述的候选媒体单元中最早产生的单元和最晚产生的单元的产生时间间隔小于所述分段时长；
    如果媒体段请求携带的其他第二类参数未限定候选媒体单元的范围时，则所述的候选媒体单元和最新媒体单元的产生时间间隔小于所述分段时长。
  26. 根据权利要求19所述的媒体流的实时递送服务器，其特征在于，所述第一类参数包括媒体流标识，以指定所述待传送的目标媒体流。
  27. 根据权利要求26所述的媒体流的实时递送服务器，其特征在于，所述媒体段生成组件进一步用于获取媒体流索引信息，并将所述媒体流索引信息封装到所述媒体段中，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
  28. 根据权利要求19所述的媒体流的实时递送服务器，其特征在于，还包括：
    至少一个实时媒体流生成组件，用于自行产生或接收来自其他装置的一个或多个实时媒体流。
  29. 一种媒体流的实时接收客户端，其特征在于，所述的媒体流为实时产生的媒体单元的序列，每个媒体单元关联有一个产生时间和/或一个指示产生顺序的序号，所述客户端包括：
    服务器接口组件，用于发送媒体段请求至服务器，所述媒体段请求不携带或携带至少一个控制参数，且控制参数包括指示待传送的目标媒体流的第一类参数和指示待传送的候选媒体单元的第二类参数，并接收所述服务器反馈的媒体段，其中，所述媒体段由所述服务器根据所述媒体段请求生成，并封装有指定所述目标媒体流的候选媒体单元；
    媒体段解析组件，用于解析所述媒体段，其中，根据所述媒体段中解析出媒体单元，并生成所述媒体单元的接收报告；以及
    媒体流传输控制组件，用于根据所述媒体单元的接收报告生成新媒体段请求，其中，确定所述新媒体段请求携带的控制参数。
  30. 根据权利要求29所述的媒体流的实时接收方法，其特征在于，所述媒体流传输控制组件进一步用于在未收到所述服务器发送的任何媒体单元时，向所述服务器发送初始媒体段请求，并在根据所述接收报告生成所述新媒体段请求时，向所述服务器发送所述新媒体段请求。
  31. 根据权利要求29所述的媒体流的实时接收客户端，其特征在于，所述第二类参数包括起始序号、单元个数、起始时间和分段时长中的一项或多项。
  32. 根据权利要求31所述的媒体流的实时接收客户端，其特征在于，所述接收报告包含当前接收成功的媒体单元的序号，其中，
    如果所述新媒体段请求携带的第二类参数包括起始序号，则所述起始序号的值为所述当前接收成功的最新媒体单元的下一个单元的序号值。
  33. 根据权利要求31所述的媒体流的实时接收客户端，其特征在于，所述接收报告包含当前接收成功的媒体单元的产生时间，其中，
    如果所述新媒体段请求携带的第二类参数包括起始时间，则所述起始时间的值为所述当前接收成功的最新媒体单元的产生时间。
  34. 根据权利要求29所述的媒体流的实时接收客户端，其特征在于，在接收所述服务器反馈的媒体段之前，还包括：
    检测模块，用于在发送所述媒体段请求后，检测所述媒体段的反馈时间，并在所述反馈时间超过预设时间时，终止接收当前媒体段，且解析的媒体段为未完全接收的媒体段。
  35. 根据权利要求29所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件进一步用于接收所述服务器发送的媒体流索引信息，其中，所述的媒体流索引信息包含属于同一个内容的多个媒体流描述信息，所述的媒体流描述信息包括媒体流标识和媒体流比特率。
  36. 根据权利要求35所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件进一步用于在所述新媒体段请求携带的第一类参数包括所述媒体流标识时，则根据当前传输速率和所述媒体流索引信息确定所述媒体流标识，并根据所述媒体段的接收时间得到所述当前传输速率。
  37. 根据权利要求35或36所述的媒体流的实时接收客户端，其特征在于，所述媒体流传输控制组件进一步用于根据接收的媒体段解析得到所述媒体流索引信息，其中，所述的媒体流索引信息由所述服务器封装到所述媒体段中。
  38. 一种计算机设备，其特征在于，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时，实现如权利要求1-9中任一所述的方法，或者如权利要求10-18中任一所述的方法。
  39. 一种非临时性计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1-9中任一所述的方法，或者如权利要求10-18中任一所述的方法。
  40. 一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如权利要求1-9中任一所述的方法，或者如权利要求10-18中任一所述的方法。
PCT/CN2019/098871 2018-09-05 2019-08-01 媒体流的实时递送方法、实时接收方法、服务器及客户端 WO2020048268A1 (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201811032231.5 2018-09-05
CN201811033268.X 2018-09-05
CN201811033268.XA CN110881018B (zh) 2018-09-05 2018-09-05 媒体流的实时接收方法及客户端
CN201811032231.5A CN110545492B (zh) 2018-09-05 2018-09-05 媒体流的实时递送方法及服务器

Publications (1)

Publication Number Publication Date
WO2020048268A1 true WO2020048268A1 (zh) 2020-03-12

Family

ID=69721583

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/098871 WO2020048268A1 (zh) 2018-09-05 2019-08-01 媒体流的实时递送方法、实时接收方法、服务器及客户端

Country Status (1)

Country Link
WO (1) WO2020048268A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102118253A (zh) * 2009-12-30 2011-07-06 华为技术有限公司 一种发送媒体文件的方法、***及装置
US20120272281A1 (en) * 2011-04-22 2012-10-25 Samsung Electronics Co., Ltd. Method and apparatus for transmitting media data, and method and apparatus for receving media data
CN104080014A (zh) * 2013-03-28 2014-10-01 浙江大华技术股份有限公司 一种实时视频处理方法和装置
CN104581208A (zh) * 2015-01-30 2015-04-29 百度在线网络技术（北京）有限公司 一种用于视频点播以及用于辅助视频点播的方法和装置
CN106604062A (zh) * 2016-12-01 2017-04-26 中央电视台 一种流媒体点播方法及装置
CN107888993A (zh) * 2016-09-30 2018-04-06 华为技术有限公司 一种视频数据的处理方法及装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102118253A (zh) * 2009-12-30 2011-07-06 华为技术有限公司 一种发送媒体文件的方法、***及装置
US20120272281A1 (en) * 2011-04-22 2012-10-25 Samsung Electronics Co., Ltd. Method and apparatus for transmitting media data, and method and apparatus for receving media data
CN104080014A (zh) * 2013-03-28 2014-10-01 浙江大华技术股份有限公司 一种实时视频处理方法和装置
CN104581208A (zh) * 2015-01-30 2015-04-29 百度在线网络技术（北京）有限公司 一种用于视频点播以及用于辅助视频点播的方法和装置
CN107888993A (zh) * 2016-09-30 2018-04-06 华为技术有限公司 一种视频数据的处理方法及装置
CN106604062A (zh) * 2016-12-01 2017-04-26 中央电视台 一种流媒体点播方法及装置

Similar Documents

Publication Publication Date Title
US10439910B2 (en) Low-latency streaming
EP3090523B1 (en) Content delivery
TWI668982B (zh) 用於多媒體和檔案傳輸的傳輸介面的方法及伺服器設備、及用於記錄相關指令於其上的電腦可讀取儲存媒體
CN106233735B (zh) 管理多播视频传送的方法
CN108141455B (zh) 用于媒体数据的流式发射的期限信令
US10412461B2 (en) Media streaming with latency minimization
WO2009143748A1 (zh) 一种数据传输的方法、***及装置
EP2710778B1 (en) Method for dynamic adaptation of the reception bitrate and associated receiver
US10735485B2 (en) Technique for adaptive streaming of temporally scaling media segment levels
CN110086797B (zh) 媒体流的实时接收方法、客户端、计算机设备和存储介质
CN110072128B (zh) 媒体流的实时推送方法及服务器
WO2019185372A1 (en) Congestion response for timely media delivery
CN110881018B (zh) 媒体流的实时接收方法及客户端
WO2020098455A1 (zh) 媒体流的实时递送方法及服务器
WO2011143916A1 (zh) 媒体适配的方法和装置
CN111193686B (zh) 媒体流的递送方法及服务器
JP2016500504A (ja) 低レイテンシ・ストリーミング
CN110545492B (zh) 媒体流的实时递送方法及服务器
WO2020048268A1 (zh) 媒体流的实时递送方法、实时接收方法、服务器及客户端
CN111654725B (zh) 媒体流的实时接收方法及客户端
WO2020216035A1 (zh) 媒体流的实时推送方法、实时接收方法、服务器及客户端
GB2572357A (en) Congestion response for timely media delivery
TW202215853A (zh) 用於適應性位元率多播的修復機制
CN113873343A (zh) 媒体流的自适应实时递送方法及服务器

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19857444

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 08.07.2021)

122 Ep: pct application non-entry in european phase

Ref document number: 19857444

Country of ref document: EP

Kind code of ref document: A1