WO2019019370A1 - 一种音视频的直播处理方法、存储介质和一种移动终端 - Google Patents

一种音视频的直播处理方法、存储介质和一种移动终端 Download PDF

Info

Publication number
WO2019019370A1
WO2019019370A1 PCT/CN2017/104528 CN2017104528W WO2019019370A1 WO 2019019370 A1 WO2019019370 A1 WO 2019019370A1 CN 2017104528 W CN2017104528 W CN 2017104528W WO 2019019370 A1 WO2019019370 A1 WO 2019019370A1
Authority
WO
WIPO (PCT)
Prior art keywords
streaming media
data
mobile terminal
connection request
target
Prior art date
Application number
PCT/CN2017/104528
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
Application filed by 平安科技（深圳）有限公司 filed Critical 平安科技（深圳）有限公司
Publication of WO2019019370A1 publication Critical patent/WO2019019370A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/4363—Adapting the video stream to a specific local network, e.g. a Bluetooth® network
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/437—Interfacing the upstream path of the transmission network, e.g. for transmitting client requests to a VOD server
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols

Definitions

  • the present application relates to the field of data transmission technologies, and in particular, to a live broadcast processing method for audio and video, a storage medium, and a mobile terminal.
  • the current practice on the web side is to use the RTMP protocol or the HLS protocol as the audio and video transmission protocol and the streaming server to complete the data transmission, using the browser's audio/video tag of the mobile terminal. Video playback.
  • the RTMP protocol is not applicable to most mobile terminal browsers; the HLS protocol is prone to delays due to the slicing file mechanism, and is not suitable for scenarios with high latency requirements such as interaction and live broadcast.
  • the embodiment of the present application provides a live broadcast processing method for audio and video, a storage medium, and a mobile terminal, which can reduce the delay of data transmission and improve the real performance of audio and video live broadcast.
  • a live broadcast processing method for audio and video including:
  • the mobile terminal acquires a play address of the websocket protocol from the service background according to the input live command, where the play address is maintained by the service background and points to a streaming media server;
  • the mobile terminal establishes a WE based on the obtained play address and the streaming media server.
  • the mobile terminal sends a target connection request to the streaming media server, where the target connection request includes information of a connection object;
  • the mobile terminal acquires a first data packet from the streaming media server by using the data transmission link; the first data packet is that the streaming media server extracts a corresponding flow according to the information of the connection object.
  • Media data and using the websocket protocol to perform data encapsulation on the extracted streaming media data;
  • the mobile terminal decapsulates the first data packet to obtain streaming media data corresponding to the connection object;
  • the streaming media data includes audio data and/or video data;
  • the mobile terminal performs decoding and playing on the streaming media data through an html5-based browser.
  • a computer readable storage medium is stored, the computer readable storage medium storing computer readable instructions executed by a processor to implement live broadcast processing of audio and video The steps of the method.
  • a mobile terminal including a memory, a processor, and computer readable instructions stored in the memory and executable on the processor, the processor executing the computer Read the command to achieve the following steps:
  • the mobile terminal acquires a play address of the websocket protocol from the service background according to the input live command, where the play address is maintained by the service background and points to a streaming media server;
  • the mobile terminal establishes a data transmission link based on the websocket protocol between the broadcast address and the streaming media server according to the obtained play address;
  • the mobile terminal sends a target connection request to the streaming media server, where the target connection request includes information of a connection object;
  • the mobile terminal acquires a first data packet from the streaming media server by using the data transmission link; the first data packet is that the streaming media server extracts a corresponding flow according to the information of the connection object.
  • Media data and using the websocket protocol to perform data encapsulation on the extracted streaming media data;
  • the mobile terminal decapsulates the first data packet to obtain streaming media data corresponding to the connection object;
  • the streaming media data includes audio data and/or video data;
  • the mobile terminal performs decoding and playing on the streaming media data through an html5-based browser.
  • a live broadcast processing device for audio and video, including: [0023] a play address obtaining module, configured to obtain a play address of a websocket protocol from a service background according to the input live command, where the play address is maintained by the service background and directed to a streaming media server;
  • a transmission link establishing module configured to establish a data transmission link based on a websocket protocol between the streaming address server and the streaming media server according to the obtained playing address;
  • a request sending module configured to send a target connection request to the streaming media server, where the target connection request includes information of a connection object
  • a data packet obtaining module configured to acquire, by using the data transmission link, a first data packet from the streaming media server, where the first data packet is extracted by the streaming media server according to information about the connection object Corresponding streaming media data, and using the websocket protocol to perform data encapsulation on the extracted streaming media data;
  • a data packet decapsulation module configured to decapsulate the first data packet to obtain streaming media data corresponding to the connection object; and the streaming media data includes audio data and/or video data;
  • a decoding play module configured to decode the streaming media data by using an html5-based browser, and the beneficial effects of the invention
  • the mobile terminal acquires a play address of the websoc ket protocol from the service background according to the input live command, where the play address is maintained by the service background and points to a streaming media server;
  • the mobile terminal establishes a data transmission link based on the websocket protocol between the broadcast address server and the streaming media server; and then the mobile terminal sends a target connection request to the streaming media server, where the target connection request is sent And including, by the mobile terminal, the first data packet from the streaming media server by using the data transmission link; the first data packet is extracted by the streaming media server according to the information of the connection object Corresponding streaming media data, and using the websocket protocol to perform data encapsulation on the extracted streaming media data; and then, the mobile terminal decapsulates the first data packet to obtain a streaming media corresponding to the connected object Data;
  • the streaming media data includes audio data and/or video data;
  • the mobile terminal decodes and plays the streaming media data through a browser based on htm
  • the server transmits the streaming data through the data transmission link based on the websocket protocol, supports the mobile terminal mobile terminal based on the websocket protocol, and continuously completes the transmission of the streaming media data, and the browser on the mobile terminal.
  • the new features of html5 can reduce the delay of data transmission and improve the reality of audio and video broadcast.
  • FIG. 1 is a flowchart of an embodiment of a live broadcast processing method for audio and video in an embodiment of the present application
  • FIG. 2 is a schematic flowchart of a streaming media server acquiring streaming media data in a live broadcast processing method for audio and video according to an embodiment of the present disclosure
  • FIG. 3 is a schematic diagram of a principle of a streaming media server according to an embodiment of the present application.
  • FIG. 4 is a schematic flowchart of adjusting a cache space in an application scenario in a live broadcast processing method for audio and video in the embodiment of the present application;
  • FIG. 5 is a schematic diagram of data transmission between a mobile terminal, a streaming media server, and a central node in an embodiment of the present application;
  • FIG. 6 is a schematic diagram of a process of decoding and playing back RTMP stream data in an application scenario according to an audio and video live processing method in an embodiment of the present application;
  • FIG. 7 is a structural diagram of an embodiment of an audio and video live broadcast processing apparatus according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a mobile terminal according to an embodiment of the present disclosure.
  • the embodiment of the present application provides a live broadcast processing method for audio and video, a storage medium, and a mobile terminal, which are used to solve the problem that the existing mobile terminal browser has a high delay in audio and video broadcast.
  • An embodiment of a live broadcast processing method for audio and video in an embodiment of the present application includes:
  • the mobile terminal obtains a play address of the websocket protocol from the service background according to the input live command, where the play address is maintained by the service background and points to a streaming media server.
  • the browser on the mobile terminal adopts the html5 standard, so that the browser on the mobile terminal can be supported for multimedia playback and other functions.
  • the mobile terminal (client) performs data transmission with the streaming media server, and the streaming media server provides the response support of the streaming media data by using the websocket protocol, so that the mobile terminal can continuously obtain the corresponding streaming media data and perform live broadcast of audio and video. Reduce the delay of data transmission and improve the reality of audio and video broadcast.
  • the user may click on a live broadcast trigger event of an audio or video, such as a link address of a live video, on the page displayed by the browser of the mobile terminal, thereby generating a corresponding
  • the live broadcast link request (that is, the live broadcast command input above)
  • the mobile terminal may apply for the play address of the corresponding websocket protocol to the service background according to the live broadcast link request.
  • the service background can be deployed on a local server or a remote server.
  • the service background pre-maintains the play address of multiple websocket protocols that may be used.
  • the address format of these play addresses is "ws : ⁇ +ip Address ", if it is the secure mode of the Websocket protocol, the address format can be "wss: //+ip address”.
  • the ip address in the play address points to a streaming server, and the address of the streaming server is the ip address.
  • the streaming media server in this embodiment may be deployed in a CDN (Content Distribution Network) network.
  • CDN Content Distribution Network
  • the distribution of different connection requests to different servers by the CDN network improves the quality of service of each server while mitigating and optimizing the overall service pressure of each server.
  • the streaming media server pointed to by the play address is determined by the following steps: the scheduling center of the CDN network determines the node servers according to the network connection between the mobile terminal and each node server on the CDN network. One of the node servers serves as the streaming server.
  • node servers can be deployed on one CDN network, and these node servers Also known as the edge node (ie, the service node closest to the client access in the CDN network), the scheduling center of the CDN network performs unified scheduling management.
  • the CDN network may be based on a network connection between the mobile terminal and each node server.
  • the node server acts as a streaming server that provides services to the mobile terminal.
  • the mobile terminal establishes a data transmission link based on a websocket protocol between the broadcast address and the streaming media server according to the obtained play address.
  • the mobile terminal may establish a data transmission link based on the websocket protocol between the broadcast address and the streaming media server according to the obtained play address. Specifically, the mobile terminal may send an access request to the streaming media server, and the streaming media server may complete establishment of a data transmission link with the mobile terminal by using a websocket service program preset on the streaming media server.
  • the websocket service program is pre-deployed on the CDN network, and is automatically synchronized to the respective node servers in a binary file form through an internal service update channel of the CDN network.
  • the websocket service program is executed in the form of a binary file, which can greatly reduce the cost and cost of deploying the extension of the websocket service program on each node server of the CDN network, and improve the deployment and update efficiency of the service program.
  • the mobile terminal sends a target connection request to the streaming media server, where the target connection request includes information about a connection object.
  • the mobile terminal may send a target connection request to the streaming media server.
  • the target connection request may include information about the connection object, where the connection object refers to an address or a unique identifier of the object that the target connection request needs to request to connect and obtain the streaming media data, and the streaming media server may depend on the connection object.
  • the corresponding audio and video data is found in the server local or network.
  • connection object here is the object pointed by the live broadcast instruction, that is, the user wants to watch a live broadcast audio, a live video, or a live video corresponding to the content broadcasted by the audio and video through the mobile terminal.
  • the sequential execution order is not distinguished between the above steps 101, 102, and 103, and the above steps 101 and 103 can be performed simultaneously.
  • the mobile terminal can directly send the target connection request to the service background, so that the service background feeds back the play address to the mobile terminal, and the service background can simultaneously deliver the target connection request to the streaming media server, which is equivalent to the mobile
  • the terminal indirectly sends the target connection request to the streaming server.
  • the mobile terminal it only needs to perform one action to implement the above steps 101 and 103.
  • the above step 102 can also be performed after the step 103.
  • the mobile terminal does not need to wait for the execution of the step 102 to complete the data.
  • the target connection request is sent to the streaming server.
  • the streaming server can receive the target connection request and prepare the corresponding streaming media data for acquisition and transmission before step 102.
  • the mobile terminal may directly send a target connection request to the scheduling center, and the scheduling center allocates a corresponding streaming media server to the mobile terminal. And sending the target connection request to the streaming server. After receiving the target connection request, the streaming server establishes the above data transmission link with the mobile terminal.
  • the mobile terminal acquires a first data packet from the streaming media server by using the data transmission link, where the first data packet is corresponding to the streaming media server according to the information of the connection object.
  • the streaming media server After the mobile terminal sends the target connection request to the streaming media server, the streaming media server performs the following steps to obtain corresponding streaming media data according to the target connection request, as shown in FIG. 2
  • the streaming media server receives a target connection request from the mobile terminal.
  • the streaming media server creates a target event processor corresponding to the target connection request, where the target event processor uses a websocket protocol to perform data transmission with the mobile terminal.
  • the streaming media server queries whether the connection object of the other connection request is the same as the connection object of the target connection request, if yes, step 204 is performed, and if not, step 205 is performed;
  • the streaming media server reuses streaming media data in a buffer queue corresponding to the first connection request. Go to the target event processor, so that the target event processor sends the multiplexed streaming media data to the mobile terminal; the first connection request refers to the connection object in the other connection request and the The connection request of the target connection request is the same connection request;
  • the streaming media server creates a new buffer queue corresponding to the target connection request.
  • the streaming media server extracts a corresponding stream according to information about the connection object of the target connection request.
  • the streaming media server distributes the extracted streaming media data to the target event processor by using the new buffer queue, so that the target event processor sends the extracted streaming media data to the target event processor.
  • the mobile terminal The mobile terminal.
  • each event processor data transmission is performed by each event processor with each different connection request.
  • the streaming server can pre-create each Handler, that is, each event handler, by using the websocket package in the officially maintained standard package go.net of the go language.
  • These event handlers can primarily target HTTP requests.
  • the streaming server may bind the ws address (for example, ws://.. Jws/stream_name, the address represents a flow, and the stre am_name represents an arbitrary flow name) to the Handler, a ws address, respectively. Bind a Handler
  • the target connection request may trigger an idle handler on the streaming server, and the triggered handler then associates with the target connection request, and the handler acts as
  • the target event processor uses the websocket protocol to perform data transmission with the mobile terminal.
  • connection object of the connection request already exists on the streaming media server is the same as the connection object of the target connection request, it indicates that the target connection request needs to be acquired.
  • the streaming media data has been acquired in advance by another connection request, and the streaming media data obtained by another connection request is currently being cached on the streaming media server. Therefore, the streaming media server does not need to re-acquire the same streaming media data for the target connection request, and directly reuses the streaming media data obtained by the other connection request to be provided to the mobile terminal.
  • the connection object of the connection request is found to be the same as the connection object of the target connection request, the process may be performed.
  • the streaming media server may pre-establish a streaming media connection pool, where the streaming media connection pool is used to store and manage the current flow management object of each connection request, and the flow management object record There is information about the connection object of the connection request corresponding thereto.
  • the foregoing step 203 may be specifically: the streaming media server querying whether the connection object of the other connection management request in the streaming media connection pool has the same connection object as the target connection request.
  • the streaming media server may further register the flow management object corresponding to the target connection request into the office.
  • the streaming media connection pool may be further registered.
  • the streaming media connection pool on the streaming media server can be created by using the go language map object, and stores the currently connected StreamManager information, that is, the flow management object.
  • the streaming connection pool can allocate an in-pool connection object Conn to the StreamManager, and the in-pool connection object Conn is used to identify the target connection request corresponding to the StreamManager.
  • the StreamManager can also record information about the connection object of the corresponding connection request, where the connection object can be distinguished according to stream_name.
  • the streaming server finds that the stream_names of the two StreamManager records in the current streaming media connection pool are the same, it can be considered that the connection requests corresponding to the two StreamManagers have the same connection object, that is, between the two connection requests.
  • Streaming media data can be reused.
  • the previous connection request since the previous connection request usually has a corresponding buffer queue, the latter connection request can directly share an existing buffer queue with the previous connection request.
  • the StreamM anager corresponding to the target connection request needs to be registered into the The streaming media connection pool is used to subsequently establish a buffer queue corresponding to the target connection request.
  • step 204 it can be understood that when there is a first connection request that can be multiplexed, the streaming data in the buffer queue corresponding to the first connection request is handed over to the target event processor, thereby target event processing.
  • the device sends the streaming media data to the mobile terminal to implement fast acquisition of the streaming media data.
  • the data media server can provide the streaming media data support service to the mobile terminal more efficiently. It should be noted that due to the relationship between the mobile terminal and the streaming server The data transmission link of the websocket protocol is adopted. Therefore, before the target event processor sends the streaming media data, the data packet is encapsulated by the websocket protocol to obtain the first data packet, and then the first data packet is transmitted through the data. A link is sent to the mobile terminal.
  • step 205 it can be understood that, when the connection object that does not have other connection request is the same as the connection object of the target connection request, the streaming server needs to provide a new buffer queue for the target connection request. In order to obtain streaming media data for the target connection request.
  • the buffer server may be configured to store a buffer queue corresponding to each connection request. And, in order to improve the utilization of the buffer and ensure that the streaming media server provides the quality and efficiency of the streaming media data service, the streaming media server may adjust the size of the buffer according to the current streaming media data acquisition speed; wherein, the current The faster the streaming data is acquired, the smaller the adjusted buffer is. The slower the current streaming data acquisition speed is, the larger the adjusted buffer is.
  • the streaming server since the case where the buffer queue multiplexing between each connection request, the streaming server so create a new buffer queue inch, can only create the corresponding connection pool registered in streaming StreamManag e r Buffer queue. It can be understood that if the target connection request can multiplex the buffer queue of other connection requests, the StreamManager corresponding to the target connection request does not need to register the inbound media connection pool; conversely, if the target connection request has no other connection request that can be reused In the buffer queue, the StreamManager corresponding to the target connection request is registered in the streaming media connection pool. Therefore, the streaming media server creates a corresponding buffer queue for the StreamManager registered in the streaming media connection pool, that is, the streaming server is unable to adopt the data.
  • the multiplexing method obtains the connection request of the streaming media data to create a corresponding buffer queue.
  • the information of the connection object of the target connection request may be a storage address or a unique identifier of a certain audio and video data
  • the streaming media server may use the information of the connection object from the server local or network. Find the corresponding audio and video data.
  • the streaming media server may obtain a corresponding buffer queue through the StreamManager, and then establish an RTMP with the node server where the connection object is located through the buffer queue. Connected so that it can be streamed from the node server to the buffer queue.
  • the streaming media data obtained by the streaming may be buffered in the streaming media service in the format of the RTMP data packet. Corresponding buffer queue on the server.
  • the streaming server may pre-establish an RTMP connection pool, the RTMP connection.
  • the pool is used to manage these RTM connections.
  • RTMP and websocket stream services can be combined in program design, or shared memory can be provided for cross-process access, so that buffered data of RTMP connection can be obtained from the existing RTMP connection pool on the node server, to the maximum extent.
  • the multiplexed streaming media data on the streaming media server is not specifically limited in this embodiment.
  • step 207 it should be noted that, since the websock et protocol data transmission link is used between the mobile terminal and the streaming media server, the target event processor needs to adopt the websocket protocol to send these streaming media data.
  • the streaming media data is encapsulated to obtain a first data packet, and then the first data packet is sent to the mobile terminal through a data transmission link.
  • the streaming media server may further be configured with a statistical data collection process Data collector and a streaming media monitoring process monitor.
  • the streaming server can establish a Monitor through Go prediction, and register the remote procedure call through the RPC (remote procedure call) mechanism, which will connect the statistics (RTMP connection number, each buffer queue size, network connection status, client request IP, The number of abnormal times, CPU usage, etc. is passed as a parameter to the Monitor for statistics.
  • the Monitor is responsible for collecting parameter information and judging whether it is necessary to initiate an alarm signal to the dispatch center of the CDN network according to these parameter information. In addition, it can also pass the CDN internal letter. Let the channel (for example: HTTP or TCP connection) submit the Websocket stream connection status of the streaming server to the dispatch center according to the CDN internal data transfer protocol.
  • the monitor may report to the dispatching center according to the severity of the fault.
  • the monitor can also collect relevant system information and attempt to restart the websocket service to ensure high availability of the websocket service.
  • the scheduling center of the CDN network can adjust the current service pressure of each node server according to the feedback information of the Monitor, thereby improving the service quality of each node server in the CDN network as much as possible, especially Alleviate the service pressure of each node server in a special segment (such as a busy network).
  • the foregoing steps 201-207 mainly describe the processing procedure of the streaming media server after receiving the target connection request from the streaming media server.
  • the processing procedure of the streaming media server is not limited to the foregoing steps 201-207. It should be understood that the content described in the foregoing steps 201-207 is not a limitation on the working steps of the streaming media server in this embodiment.
  • the transmission rate of the data transmission link is not affected by the receiving end (mobile terminal), and the mobile terminal may preset a certain size of the buffer space. Used to cache the first packet received.
  • the live broadcast processing method of the audio and video further includes:
  • the mobile terminal caches the obtained first data packet in a preset cache space.
  • the mobile terminal performs statistics on a current transmission rate of each data transmission link and a status of the cache space.
  • the mobile terminal adjusts a size of the buffer space according to the transmission rate and a state of the cache space.
  • the mobile terminal may also perform state statistics, such as a cardon rate, a transmission rate, and a jitter, on each link in the first data packet, and then perform a data frame loss according to the result of the state statistics. Accelerate the catch-up operation of decoding, rendering, etc. to dynamically adjust the available cache space for the first packet.
  • state statistics such as a cardon rate, a transmission rate, and a jitter
  • the mobile terminal dynamically adjusts the size of the buffer space. Generally speaking, if the current transmission rate is large, it indicates that the network status is good, and the buffer space can be appropriately reduced; If the current transmission rate is small, it indicates that the network status is poor. Therefore, in order to ensure the liveness of the live broadcast, the buffer space should be moderately increased.
  • the mobile terminal decapsulates the first data packet to obtain streaming media data corresponding to the connection object, where the streaming media data includes audio data and/or video data.
  • the mobile terminal performs decoding and playing on the streaming media data by using an html5-based browser.
  • the first data packet is encapsulated by the websocket protocol
  • the mobile terminal needs to decapsulate the data by using the websocket protocol to obtain the first data packet.
  • Streaming data in a packet which can be frequency data and / Or video data.
  • the mobile terminal can decode and play the streaming media data through an html5 based browser.
  • the streaming media data may be specifically RTMP stream data.
  • the streaming media server is one of the node servers of the CDN network; the streaming media server extracts corresponding streaming media data according to the information of the connection object of the target connection request, specifically: the streaming media server according to the The information of the connection object of the target connection request pulls the corresponding RTMP stream data from the central node of the CD N network.
  • the streaming media server Before the streaming media server sends the first data packet to the mobile terminal, the streaming media server performs data encapsulation on the extracted RTMP stream data by using a websocket protocol, to obtain the first The data packet, after the mobile terminal receives and decapsulates the first data packet, obtains RTMP stream data in the first data packet. Therefore, the mobile terminal needs to decode and play the RTMP stream data according to the RTMP protocol through an html5 based browser.
  • the streaming media server is an edge node server in the CDN network, and obtains streaming media data, and the streaming media server first pulls corresponding streaming media data from a central node of the CDN network.
  • the communication process adopts the RTMP protocol; after the streaming media data is obtained, the streaming media data is encapsulated into a first data packet by using a websocket protocol, and then the first data packet is sent to the mobile terminal, and the transmitted communication process adopts a websocket protocol. . After the mobile terminal (ie, the client) obtains the first data packet, the first data packet is unpacked and decoded, and the audio and video broadcast can be realized.
  • the mobile terminal may receive the first data packet from the streaming media server after the websocket server receives the web data packet through the websocket client.
  • the RTMP stream data after the first packet is unpacked is received in the onMessage callback of the Websocket, and placed in the queue to be demultiplexed.
  • the mobile terminal first receives the audio and video metadata frame, and the mobile terminal parses the metadata information to perform corresponding audio and video decoding parameter configuration.
  • the normal data frame of the audio and video is received, and the mobile terminal distinguishes the audio and video data types, and after decapsulation, the media encoded data is respectively placed in the decoding queue of the corresponding media type.
  • the mobile terminal starts the media decoding worker thread, and each stream can establish a decoding thread according to the corresponding media type.
  • video data the mobile terminal can use the H.264 decoding library Boardway.js, new The Decoder object is configured and decoded.
  • audio data the mobile terminal calls the AudioContext's decodeAudioData for decoding, and puts the decoded data into the output queue.
  • the video data is used to render the decoded YUV video frame from the output queue through the rendering thread, and the WebGL (the drawing standard combined with javascript and OpenGL ES 2.0) is called to draw on the Canvas.
  • the mobile terminal connects the decoded array to the AudioSourceNode through the AudioContext for playback.
  • the audio and video synchronization judgment is required to perform feedback adjustment before rendering and playing.
  • the mobile terminal may use the audio and video synchronization strategy algorithm to perform audio and video data frame determination, and based on the audio time, on the basis of ensuring the sequential playback of the audio data, according to the result, it is judged whether to catch up or Discard some of the decoded video frames, ensuring simultaneous audio and video output on the day.
  • the mobile terminal outputs the audio and video through the browser, and can also implement multi-picture and mixing control.
  • multi-screen control can be implemented in two ways, one is to create a single canvas, the multi-stream picture is limited according to the viewport to define the drawing range; the other is to create a canvas separately, which is convenient for controlling the display position separately, in establishing the canvas. Then get the context of WebGL, set the rendered texture for the picture to draw.
  • the mobile terminal can create multiple AudioBufferSources through the AudioContext, connect the decoded data of the corresponding stream to the corresponding AudioBufferSource, and then realize the mixing output, and also separately control the sound parameters of a certain stream.
  • a live broadcast processing method for audio and video provided by this embodiment is compared with the existing RTMP streaming technology.
  • RTMP stream data is demultiplexed and decoded mainly by the Flash player on the browser PC side, and the mobile terminal does not have corresponding player support due to the system platform. If it needs to support the direct transmission of RTMP stream data, it must be processed. Browser long connection and compatibility issues; compared with the existing HLS streaming technology, the stream data is actually a tiled slice file, the m3u8 description file is used to update the slice file link address, and the player downloads the corresponding slice file in advance. The effect of continuous playback is realized, but the mechanism of file slicing is easy to cause the playability to be less strong, and the delay is usually more than 10s, which greatly affects the reality of audio and video live broadcast.
  • the live broadcast processing method of the audio and video provided in this embodiment can realize full-duplex communication based on the Websocket protocol, and can customize the transmission data format, and the transmission can improve security, and the mainstream browsing of the mobile terminal currently on the market. Both have good support for the Websocket protocol, just one HTTP request Continuous audio and video data transmission to avoid synchronization delay, the effect is good.
  • the method uses H.264 decoding of the video data and then uses Canvas to draw, which can support multiple picture drawing; the audio data can be directly sent to the AudioContext for AAC decoding and playing. It can support multi-channel playback, make full use of the hardware acceleration capability of mobile terminals, and further improve the realism of audio and video live broadcast.
  • FIG. 7 is a structural diagram of an embodiment of a live broadcast processing apparatus for audio and video in an embodiment of the present application.
  • a live broadcast processing device for audio and video includes:
  • the play address obtaining module 701 is configured to obtain a play address of the websocket protocol from the service background according to the input live command, where the play address is maintained by the service background and directed to a streaming media server;
  • the transmission link establishing module 702 is configured to establish a data transmission link based on the websocket protocol between the streaming address server and the streaming media server according to the obtained play address;
  • the request sending module 703 is configured to send a target connection request to the streaming media server, where the target connection request includes information about the connection object.
  • a data packet obtaining module 704 configured to acquire, by using the data transmission link, a first data packet from the streaming media server, where the first data packet is information that is used by the streaming media server according to the connection object. Extracting corresponding streaming media data, and using the websocket protocol to perform data encapsulation on the extracted streaming media data;
  • a data packet decapsulation module 705, configured to decapsulate the first data packet to obtain streaming media data corresponding to the connection object;
  • the streaming media data includes audio data and/or video data;
  • the decoding play module 706 is configured to perform decoding and playing of the streaming media data by using an html5-based browser.
  • the streaming media server pointed to by the play address is determined by the following steps:
  • a scheduling center of the CDN network is according to the mobile terminal and each node server on the CDN network
  • the network connection condition determines one of the node servers as the streaming server.
  • the streaming media server performs the following steps:
  • the streaming server receives the target connection request from the mobile terminal
  • the streaming media server creates a target event processor corresponding to the target connection request, and the target event processor uses the websocket protocol to perform data transmission with the mobile terminal;
  • the streaming media server queries whether the connection object of the other connection request is the same as the connection object of the target connection request;
  • the streaming server multiplexes the streaming media data in the buffer queue corresponding to the first connection request to the target event.
  • the target event processor sends the multiplexed streaming media data to the mobile terminal;
  • the first connection request refers to a connection between the connection object and the target connection request in the other connection request The same connection request for the object;
  • the streaming server creates a new buffer queue corresponding to the target connection request, according to the target connection request.
  • the information of the connection object extracts corresponding streaming media data, and distributes the extracted streaming media data to the target event processor through the new buffer queue, so that the target event processor will extract the extracted streaming media.
  • Data is sent to the mobile terminal.
  • the streaming media server may be one of the node servers of the CDN network
  • the extracting, by the streaming media server, the corresponding streaming media data according to the information of the connection object of the target connection request may be: the streaming media server, according to the information of the connection object of the target connection request, from the CDN network.
  • the central node pulls the corresponding RTMP stream data;
  • the streaming media server Before the streaming media server sends the first data packet to the mobile terminal, the streaming media server performs data encapsulation on the extracted RTMP stream data by using a websocket protocol, to obtain the first a data packet;
  • the decoding and playing module is specifically configured to: the mobile terminal according to an RT5 based browser according to an RTMP
  • the protocol decodes and plays the RTMP stream data.
  • the live broadcast processing device of the audio and video may further include:
  • a cache module configured to cache the obtained first data packet in a preset cache space
  • a state statistics module configured to perform statistics on a current transmission rate of each data transmission link and a state of the cache space
  • a cache space adjustment module configured to adjust a size of the cache space according to the transmission rate and a state of the cache space; wherein, the larger the current transmission rate, the smaller the adjusted cache space; The smaller the current transmission rate, the larger the adjusted buffer space.
  • the mobile terminal 8 of this embodiment includes: a processor 80, a memory 81, and computer readable instructions 82 stored in the memory 81 and executable on the processor 80, for example, performing audio and video The program of the live processing method.
  • the processor 80 executes the computer readable instructions 82 to implement the steps in the live processing method embodiment of the respective audio and video, such as steps 101 to 106 shown in FIG.
  • the processor 80 executes the computer readable instructions 82 to implement the functions of the modules/units in the various apparatus embodiments described above, such as the functions of the modules 701 to 706 shown in FIG.
  • the computer readable instructions 82 may be partitioned into one or more modules/units, the one or more modules/units being stored in the memory 81 and by the processor 80 is executed to complete the application.
  • the one or more modules/units may be a series of computer readable instruction instruction segments capable of performing a particular function, the instruction segments being used to describe the execution of the computer readable instructions 82 in the mobile terminal 8.
  • the mobile terminal 8 may be a computing device such as a mobile phone or a tablet computer.
  • the mobile terminal can include, but is not limited to, a processor 80, a memory 81.
  • FIG. 8 is merely an example of the mobile terminal 8, and does not constitute a limitation of the mobile terminal 8, and may include more or less components than those illustrated, or combine some components, or different components.
  • the mobile terminal may further include an input/output device, a network access device, a bus, and the like.
  • the processor 80 may be a central processing unit (CPU), or may be another general-purpose processor, a digital signal processor (DSP), or an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), ready-to-use programmable gate array (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • the general purpose processor may be a microprocessor or the processor or any conventional processor or the like.
  • the memory 81 may be an internal storage unit of the mobile terminal 8, such as a hard disk or a memory of the mobile terminal 8.
  • the memory 81 may also be an external storage device of the mobile terminal 8, such as a plug-in hard disk provided on the mobile terminal 8, and a smart memory card (Smart Media Card,
  • the memory 81 may also include both an internal storage unit of the mobile terminal 8 and an external storage device.
  • the memory 81 is for storing the computer readable instructions and other programs and data required by the mobile terminal.
  • the memory 81 can also be used to temporarily store data that has been output or is about to be output.
  • each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
  • the integrated unit if implemented in the form of a software functional unit and sold or used as a standalone product, may be stored in a computer readable storage medium.
  • a computer readable storage medium A number of instructions are included to cause a computer device (which may be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present application.
  • the foregoing storage medium includes: a U disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and the like, which can store program codes. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

一种音视频的直播处理方法，用于解决现有移动终端浏览器在音视频直播时延时较高的问题。该方法包括：移动终端根据输入的直播指令从业务后台获取websocket协议的播放地址；根据播放地址与所述流媒体服务器之间建立基于websocket协议的数据传输链路；向所述流媒体服务器发送目标连接请求；通过所述数据传输链路从所述流媒体服务器上获取第一数据包；对所述第一数据包进行解封装，得到与所述连接对象对应的流媒体数据；所述流媒体数据包括音频数据和/或视频数据；通过基于html5的浏览器对所述流媒体数据进行解码播放。

Description

一种音视频的直播处理方法、 存储介质和一种移动终端
[0001] 本申请申明享有 2017年 7月 24日递交的申请号为 201710605501.6、 名称为 "一种 音视频的直播处理方法、 存储介质和一种移动终端"中国专利申请的优先权， 该 中国专利申请的整体内容以参考的方式结合在本申请中。
技术领域
[0002] 本申请涉及数据传输技术领域， 尤其涉及一种音视频的直播处理方法、 存储介 质和一种移动终端。
背景技术
[0003] 随着移动终端业务的快速发展， 以及高速移动网络的铺设， 越来越多的用户通 过移动终端来收看音视频的直播。
[0004] 在移动终端接收音视频直播数据方面， 目前在 web端的普遍做法为采用 RTMP 协议或 HLS协议作为音视频传输协议与流媒体服务器完成数据传输， 利用移动终 端的浏览器 audio/video标签进行视频播放。 但是， RTMP协议不适用于大部分移 动终端的浏览器； HLS协议因切片文件机制容易导致延吋过长， 不适用于互动、 直播等对吋延要求较高的场景。
[0005] 因此， 寻找一种适用于移动终端上进行低延吋的音视频直播的方法成为本领域 技术人员亟需解决的问题。
技术问题
[0006] 本申请实施例提供了一种音视频的直播处理方法、 存储介质和一种移动终端， 能够减少数据传输的吋延， 提高音视频直播的实吋性。
问题的解决方案
技术解决方案
[0007] 第一方面， 提供了一种音视频的直播处理方法， 包括：
[0008] 移动终端根据输入的直播指令从业务后台获取 websocket协议的播放地址， 所述 播放地址由所述业务后台维护并指向一个流媒体服务器；
[0009] 所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立基于 we bsocket协议的数据传输链路；
[0010] 所述移动终端向所述流媒体服务器发送目标连接请求， 所述目标连接请求包括 连接对象的信息；
[0011] 所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数据包； 所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒 体数据， 并采用 websocket协议对提取到的流媒体数据进行数据封装得到；
[0012] 所述移动终端对所述第一数据包进行解封装， 得到与所述连接对象对应的流媒 体数据； 所述流媒体数据包括音频数据和 /或视频数据；
[0013] 所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播放。
[0014] 第二方面， 提供了一种计算机可读存储介质， 所述计算机可读存储介质存储有 计算机可读指令， 所述计算机可读指令被处理器执行吋实现上述的音视频的直 播处理方法的步骤。
[0015] 第三方面， 提供了一种移动终端， 包括存储器、 处理器以及存储在所述存储器 中并可在所述处理器上运行的计算机可读指令， 所述处理器执行所述计算机可 读指令吋实现如下步骤：
[0016] 移动终端根据输入的直播指令从业务后台获取 websocket协议的播放地址， 所述 播放地址由所述业务后台维护并指向一个流媒体服务器；
[0017] 所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立基于 we bsocket协议的数据传输链路；
[0018] 所述移动终端向所述流媒体服务器发送目标连接请求， 所述目标连接请求包括 连接对象的信息；
[0019] 所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数据包； 所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒 体数据， 并采用 websocket协议对提取到的流媒体数据进行数据封装得到；
[0020] 所述移动终端对所述第一数据包进行解封装， 得到与所述连接对象对应的流媒 体数据； 所述流媒体数据包括音频数据和 /或视频数据；
[0021] 所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播放。
[0022] 第四方面， 提供了一种音视频的直播处理装置， 包括： [0023] 播放地址获取模块， 用于根据输入的直播指令从业务后台获取 websocket协议的 播放地址， 所述播放地址由所述业务后台维护并指向一个流媒体服务器；
[0024] 传输链路建立模块， 用于根据获取到的所述播放地址与所述流媒体服务器之间 建立基于 websocket协议的数据传输链路；
[0025] 请求发送模块， 用于向所述流媒体服务器发送目标连接请求， 所述目标连接请 求包括连接对象的信息；
[0026] 数据包获取模块， 用于通过所述数据传输链路从所述流媒体服务器上获取第一 数据包； 所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相 应的流媒体数据， 并采用 websocket协议对提取到的流媒体数据进行数据封装得 到；
[0027] 数据包解封装模块， 用于对所述第一数据包进行解封装， 得到与所述连接对象 对应的流媒体数据； 所述流媒体数据包括音频数据和 /或视频数据；
[0028] 解码播放模块， 用于通过基于 html5的浏览器对所述流媒体数据进行解码播放 发明的有益效果
有益效果
[0029] 从以上技术方案可以看出， 本申请实施例具有以下优点：
[0030] 本申请实施例中， 首先， 移动终端根据输入的直播指令从业务后台获取 websoc ket协议的播放地址， 所述播放地址由所述业务后台维护并指向一个流媒体服务 器； 然后， 所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间 建立基于 websocket协议的数据传输链路； 接着， 所述移动终端向所述流媒体服 务器发送目标连接请求， 所述目标连接请求包括连接对象的信息； 所述移动终 端通过所述数据传输链路从所述流媒体服务器上获取第一数据包； 所述第一数 据包为所述流媒体服务器根据所述连接对象的信息提取相应的流媒体数据， 并 采用 websocket协议对提取到的流媒体数据进行数据封装得到； 再之， 所述移动 终端对所述第一数据包进行解封装， 得到与所述连接对象对应的流媒体数据； 所述流媒体数据包括音频数据和 /或视频数据； 最后， 所述移动终端通过基于 htm 15的浏览器对所述流媒体数据进行解码播放。 通过上述步骤， 移动终端与流媒体 服务器之间通过基于 websocket协议的数据传输链路进行流媒体数据的传输， 基 于 websocket协议对移动终端移动终端的高度支持， 可持续完成流媒体数据的传 输， 再加上该移动终端上的浏览器基于 html5标准建立， 禾 html5的新特征， 可 以减少数据传输的吋延， 提高音视频直播的实吋性。
对附图的简要说明
附图说明
[0031] 为了更清楚地说明本申请实施例中的技术方案， 下面将对实施例或现有技术描 述中所需要使用的附图作简单地介绍， 显而易见地， 下面描述中的附图仅仅是 本申请的一些实施例， 对于本领域普通技术人员来讲， 在不付出创造性劳动性 的前提下， 还可以根据这些附图获得其他的附图。
[0032] 图 1为本申请实施例中一种音视频的直播处理方法一个实施例流程图；
[0033] 图 2为本申请实施例中一种音视频的直播处理方法中流媒体服务器获取流媒体 数据的流程示意图；
[0034] 图 3为本申请实施例中流媒体服务器的原理示意图；
[0035] 图 4为本申请实施例中一种音视频的直播处理方法在一个应用场景下调整缓存 空间的流程示意图；
[0036] 图 5为本申请实施例中移动终端、 流媒体服务器和中心节点之间的数据传输示 意图；
[0037] 图 6为本申请实施例中一种音视频的直播处理方法在一个应用场景下对 RTMP流 数据的解码播放过程的示意图；
[0038] 图 7为本申请实施例中一种音视频的直播处理装置一个实施例结构图；
[0039] 图 8为本申请一实施例提供的移动终端的示意图。
本发明的实施方式
[0040] 本申请实施例提供了一种音视频的直播处理方法、 存储介质和一种移动终端， 用于解决现有移动终端浏览器在音视频直播吋延吋较高的问题。
[0041] 为使得本申请的发明目的、 特征、 优点能够更加的明显和易懂， 下面将结合本 申请实施例中的附图， 对本申请实施例中的技术方案进行清楚、 完整地描述， 显然， 下面所描述的实施例仅仅是本申请一部分实施例， 而非全部的实施例。 基于本申请中的实施例， 本领域普通技术人员在没有做出创造性劳动前提下所 获得的所有其它实施例， 都属于本申请保护的范围。
[0042] 请参阅图 1， 本申请实施例中一种音视频的直播处理方法一个实施例包括：
[0043] 101、 移动终端根据输入的直播指令从业务后台获取 websocket协议的播放地址 ， 所述播放地址由所述业务后台维护并指向一个流媒体服务器；
[0044] 本实施例中， 移动终端上的浏览器采用 html5标准， 从而可以支持移动终端上 的浏览器进行多媒体的播放以及其它功能。 该移动终端 （客户端） 通过与流媒 体服务器进行数据传输， 由流媒体服务器采用 websocket协议提供流媒体数据的 响应支持， 从而移动终端可以持续获取到相应的流媒体数据并进行音视频的直 播， 减少数据传输的吋延的同吋提高音视频直播的实吋性。
[0045] 对于上述步骤 101， 用户可以在移动终端的浏览器展示的页面上， 点击某个音 频或视频的直播触发事件， 例如某个视频直播的链接地址， 从而即可在移动终 端生成相应的直播链接请求 （即上述输入的直播指令） ， 移动终端可以根据该 直播链接请求向业务后台申请对应的 websocket协议的播放地址。 可以理解的是 ， 该业务后台可以部署在本地服务器上或者远程服务器上， 该业务后台预先维 护了多路可能用到的 websocket协议的播放地址， 这些播放地址的地址格式为 "ws ：〃 +ip地址"， 若为安全方式的 Websocket协议， 则地址格式可以为" wss: //+ip地址 "。 其中， 这些播放地址中的 ip地址指向一个流媒体服务器， 该流媒体服务器的 地址即为该 ip地址。
[0046] 进一步地， 为了避免过多的连接请求均集中在一台服务器上， 导致服务器压力 过大的问题， 本实施例中的流媒体服务器可以部署在一个 CDN (内容分发网络 ) 网络中， 由 CDN网络将不同连接请求分发至不同的服务器上， 在缓解和优化 各个服务器的整体服务压力的同吋提高了各个服务器的服务质量。 为此， 所述 播放地址所指向的流媒体服务器通过以下步骤确定： CDN网络的调度中心根据 所述移动终端与所述 CDN网络上各个节点服务器之间的网络连接情况确定所述 各个节点服务器中的一个节点服务器作为所述流媒体服务器。
[0047] 可以理解的是， 一个 CDN网络上可以部署有多个节点服务器， 这些节点服务器 也称为边缘节点 （即， CDN网络中离客户端访问最近的服务节点） ， 由 CDN网 络的调度中心进行统一的调度管理。 当某个移动终端需要与 CDN网络上的节点 服务器通信吋 （可以有业务后台告知， 或者直接由调度中心担当上述的业务后 台） ， CDN网络可以根据该移动终端与各个节点服务器之间的网络连接情况， 采用就近原则和服务器的负载情况， 比如哪个节点服务器与移动终端在网络线 路上距离更近、 和 /或哪个节点服务器当前的服务压力较小等， 从而从各个节点 服务器中确定出其中一个节点服务器作为给所述移动终端提供服务的流媒体服 务器。
[0048] 102、 所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建立 基于 websocket协议的数据传输链路；
[0049] 在移动终端获取到所述播放地址之后， 该移动终端可以根据获取到的所述播放 地址与所述流媒体服务器之间建立基于 websocket协议的数据传输链路。 具体地 ， 移动终端可以向流媒体服务器发送接入请求， 流媒体服务器可以通过预设在 所述流媒体服务器上的 websocket服务程序完成与所述移动终端之间的数据传输 链路的建立。 其中， 所述 websocket服务程序预先部署在所述 CDN网络上， 并通 过所述 CDN网络的内部服务更新渠道以二进制文件形式自动同步到所述各个节 点服务器上。 可以理解的是， websocket服务程序以二进制文件的形式被执行， 可以大大减少 websocket服务程序在 CDN网络的各个节点服务器上部署扩展的代 价和成本， 提高服务程序的部署、 更新效率。
[0050] 103、 所述移动终端向所述流媒体服务器发送目标连接请求， 所述目标连接请 求包括连接对象的信息；
[0051] 移动终端在获取到输入的直播指令之后， 该移动终端可以向该流媒体服务器发 送目标连接请求。 其中， 该目标连接请求中可以包括连接对象的信息， 这里说 的连接对象指的是该目标连接请求需要请求连接并获取流媒体数据的对象的地 址或者唯一标识， 流媒体服务器可以依据连接对象从服务器本地或者网络中寻 找到相应的音视频数据。
[0052] 可以理解的是， 这里的连接对象即为上述直播指令所指向的对象， 也即用户希 望通过移动终端观看音视频直播的内容所对应的某个直播音频、 直播视频或者 某个网络直播间的地址等等。
[0053] 需要说明的是， 上述步骤 101、 102和 103之间不区分先后执行顺序， 且上述步 骤 101和 103可以同吋执行。 可以理解的是， 该移动终端可以直接发送目标连接 请求至业务后台， 从而业务后台向移动终端反馈播放地址， 并且业务后台可以 同吋将该目标连接请求交给该流媒体服务器， 相当于该移动终端间接地发送该 目标连接请求至流媒体服务器。 对于移动终端来说， 其只需执行一个动作即可 实现上述的步骤 101和 103。 另一方面， 上述步骤 102也可以在步骤 103之后执行 ， 由上述内容可知， 若目标连接请求是由业务后台交给该流媒体服务器的， 则 该移动终端无需等待步骤 102执行完毕， 建立好数据传输链路后再发送目标连接 请求至流媒体服务器。 该流媒体服务器可以在步骤 102之前接收到目标连接请求 并做好相应的流媒体数据的获取和传输准备。
[0054] 特别地， 在一个应用场景下， 若该业务后台就是上述 CDN网络的调度中心， 则 移动终端可以直接发送目标连接请求给调度中心， 调度中心为该移动终端分配 对应的流媒体服务器， 并且将该目标连接请求发送给流媒体服务器。 流媒体服 务器接收到该目标连接请求之后， 与该移动终端建立上述的数据传输链路。
[0055] 104、 所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一数 据包； 所述第一数据包为所述流媒体服务器根据所述连接对象的信息提取相应 的流媒体数据， 并采用 websocket协议对提取到的流媒体数据进行数据封装得到
[0056] 本实施例中， 在移动终端向所述流媒体服务器发送目标连接请求之后， 流媒体 服务器根据该目标连接请求执行下列步骤来获取相应的流媒体数据， 如图 2所示
[0057] 201、 流媒体服务器接收来自移动终端的目标连接请求；
[0058] 202、 所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理器 ， 所述目标事件处理器采用 websocket协议与所述移动终端进行数据传输；
[0059] 203、 所述流媒体服务器査询是否已存在其它连接请求的连接对象与所述目标 连接请求的连接对象相同， 若是， 则执行步骤 204， 若否， 则执行步骤 205 ;
[0060] 204、 所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体数据复用 至所述目标事件处理器， 以便于所述目标事件处理器将复用得到的流媒体数据 发送给所述移动终端； 所述第一连接请求是指所述其它连接请求中连接对象与 所述目标连接请求的连接对象相同的连接请求；
[0061] 205、 所述流媒体服务器创建一个与所述目标连接请求对应的新的缓冲队列； [0062] 206、 所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应的 流媒体数据；
[0063] 207、 所述流媒体服务器将提取得到的流媒体数据通过所述新的缓冲队列分发 至所述目标事件处理器， 以便于所述目标事件处理器将提取得到的流媒体数据 发送给所述移动终端。
[0064] 对于上述步骤 202， 在该流媒体服务器中， 通过各个事件处理器来分别与各个 不同的连接请求进行数据传输。 具体地， 该流媒体服务器可以预先利用 go语言 的官方维护的标准包 go.net中的 websocket包来创建各个 Handler, 即各个事件处理 器。 这些事件处理器可以主要针对 HTTP请求。 其中， 该流媒体服务器可以将采 用特定规则设置的 ws地址 （例如 ws://.. Jws/stream_name,该地址代表一路流， stre am_name代表任意流名称） 分别绑定这些 Handler, —个 ws地址绑定一个 Handler
[0065] 当该流媒体服务器接收到该目标连接请求之后， 该目标连接请求可以触发流媒 体服务器上的一个空闲的 handler, 触发的这个 handler随即与该目标连接请求建 立对应关系， 并且该 handler作为目标事件处理器采用 websocket协议与所述移动 终端进行数据传输。
[0066] 对于步骤 203， 基于快速获取流媒体数据方面的考虑， 若流媒体服务器上已存 在某个连接请求的连接对象与该目标连接请求的连接对象相同， 则表示该目标 连接请求需要获取的流媒体数据已被另一个连接请求提前获取到， 而另一个连 接请求获取的这些流媒体数据目前正缓存在该流媒体服务器上。 因此， 该流媒 体服务器无需另外再为目标连接请求重新获取相同的流媒体数据， 直接将另一 个连接请求获取的流媒体数据重复利用， 提供给该移动终端即可。 反之， 若流 媒体服务器査询后发现并不存在某个连接请求的连接对象与所述目标连接请求 的连接对象相同， 则可以执行步骤 205。 [0067] 进一步地， 如图 3所示， 所述流媒体服务器可以预先建立流媒体连接池， 所述 流媒体连接池用于存储和管理当前各路连接请求的流管理对象， 流管理对象记 录有与其对应的连接请求的连接对象的信息。 其中， 上述步骤 203可以具体为： 所述流媒体服务器査询所述流媒体连接池的各个流管理对象中是否已存在其它 连接请求的连接对象与所述目标连接请求的连接对象相同。
[0068] 若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相同， 则在 步骤 205之前， 所述流媒体服务器还可以将所述目标连接请求对应的流管理对象 注册进所述流媒体连接池。
[0069] 参阅图 3， 该流媒体服务器上的流媒体连接池可以通过 go语言的 map对象创建， 存储当前连接的 StreamManager信息， 即流管理对象。 每个连接请求对应的 Strea mManager成功建立之后， 流媒体连接池可以为该 StreamManager分配一个池内连 接对象 Conn， 该池内连接对象 Conn用于标识该 StreamManager对应的目标连接请 求。 另外， 该 StreamManager还可以记录有对应的连接请求的连接对象的信息， 这里的连接对象可以根据 stream—name进行区分。 因此， 若流媒体服务器査找到 当前流媒体连接池中两个 StreamManager记录的 stream_name相同， 则可以认为这 两个 StreamManager对应的连接请求具有相同的连接对象， 也即代表这两个连接 请求之间的流媒体数据可以复用。 对于这里所说的复用， 由于前一个连接请求 通常已建立有对应的缓冲队列， 因此后一个连接请求直接可以与前一个连接请 求共用一个已有的缓冲队列即可。
[0070] 反之， 若不存在两个连接请求具有相同的连接对象吋， 表明当前的目标连接请 求无法利用一个已有的缓冲队列， 因此， 需要将该目标连接请求对应的 StreamM anager注册进所述流媒体连接池， 以便于后续建立该目标连接请求对应的缓冲队 列。
[0071] 对于上述步骤 204， 可以理解的是， 当存在可以复用的第一连接请求吋， 将该 第一连接请求对应缓冲队列中的流媒体数据交给目标事件处理器， 从而目标事 件处理器将这些流媒体数据发送给移动终端， 实现了流媒体数据的快速获取； 由于采用了数据复用的方式， 该流媒体服务器可以更加高效地为该移动终端提 供流媒体数据的支持服务。 需要说明的是， 由于移动终端与流媒体服务器之间 采用 websocket协议数据传输链路， 因此， 目标事件处理器在发送这些流媒体数 据之前， 需要采用 websocket协议对这些流媒体数据进行数据封装后得到第一数 据包， 然后将第一数据包通过数据传输链路发送给所述移动终端。
[0072] 对于步骤 205， 可以理解的是， 当不存在其它连接请求的连接对象与所述目标 连接请求的连接对象相同吋， 则流媒体服务器需要为该目标连接请求提供一个 新的缓冲队列， 以便于为该目标连接请求获取流媒体数据。
[0073] 其中， 进一步地， 所述流媒体服务器可以预先建立缓冲区， 所述缓冲区用于存 放各路连接请求对应的缓冲队列。 并且， 为了提高缓冲区的利用率以及保证流 媒体服务器提供流媒体数据服务的质量、 效率， 所述流媒体服务器可以根据当 前的流媒体数据获取速度调整所述缓冲区的大小； 其中， 当前的流媒体数据获 取速度越快， 则调整后的所述缓冲区越小； 当前的流媒体数据获取速度越慢， 则调整后的所述缓冲区越大。
[0074] 需要说明的是， 由于各个连接请求之间存在缓冲队列复用的情况， 因此流媒体 服务器在创建新的缓冲队列吋， 可以只为在流媒体连接池中注册的 StreamManag er创建对应的缓冲队列。 可以理解的是， 若目标连接请求可以复用其它连接请求 的缓冲队列， 则该目标连接请求对应的 StreamManager无需注册进流媒体连接池 ； 反之， 若目标连接请求没有可以复用的其它连接请求的缓冲队列， 则该目标 连接请求对应的 StreamManager注册进该流媒体连接池， 因此， 流媒体服务器为 流媒体连接池中注册的 StreamManager创建对应的缓冲队列， 也即相当于流媒体 服务器为无法采用数据复用方式获取到流媒体数据的连接请求创建对应的缓冲 队列。
[0075] 对于步骤 206， 可以理解的是， 目标连接请求的连接对象的信息可以是某个音 视频数据的存储地址或者唯一标识等， 流媒体服务器可以根据这个连接对象的 信息从服务器本地或者网络中寻找到相应的音视频数据。
[0076] 特别地， 若该连接对象存放于其它节点服务器上， 如图 3所示， 该流媒体服务 器可以通过 StreamManager获取对应的缓冲队列， 然后通过该缓冲队列与连接对 象所在的节点服务器建立 RTMP连接， 从而可以从该节点服务器上取流至缓冲队 列中。 其中， 取流得到的流媒体数据可以以 RTMP数据包的格式缓存在流媒体服 务器上对应的缓冲队列。
[0077] 如图 3所示， 为了便于管理各个缓冲队列与 CDN网络中的其它节点服务器或网 络中的其它服务器之间的 RTMP连接， 该流媒体服务器可以预先建立一个 RTMP 连接池， 该 RTMP连接池用于管理这些 RTM连接。 另外， 还可以结合 RTMP和 we bsocket流服务在程序上统一设计， 或者提供共享内存进行跨进程访问， 从而可 以实现 RTMP连接的缓冲数据从节点服务器上现有的 RTMP连接池中获取， 达到 最大限度地复用流媒体服务器上的流媒体数据， 对此本实施例不作具体限定。
[0078] 对于步骤 207， 需要说明的是， 由于移动终端与流媒体服务器之间采用 websock et协议数据传输链路， 因此， 目标事件处理器在发送这些流媒体数据之前， 需要 采用 websocket协议对这些流媒体数据进行数据封装后得到第一数据包， 然后将 第一数据包通过数据传输链路发送给所述移动终端。
[0079] 进一步地， 在流媒体服务器预先建立有流媒体连接池、 缓冲区和 /或 RTMP连接 池的基础上， 该流媒体服务器还可以设置有统计数据收集进程 Data collector和流 媒体监控进程 monitor 流媒体服务器可以通过 Go预言建立 Monitor, 并通过 RPC (remote procedure call远程过程调用） 机制注册远程过程调用， 将连接统计数据 (RTMP连接数、 各个缓冲队列大小、 网络连接情况、 客户端请求 IP、 异常次数 、 CPU使用率等） 作为参数传递给 Monitor进行统计， Monitor负责收集参数信息 并根据这些参数信息判断是否需要向 CDN网络的调度中心发起报警信号； 另外 ， 其还可以定吋通过 CDN内部信令通道 (例如： HTTP或 TCP连接)， 按照 CDN内 部数据传输协议， 提交该流媒体服务器的 Websocket流连接状态至调度中心。
[0080] 当流媒体数据获取不正常或者是某个节点服务器出现访问故障吋， Monitor可 以按照故障的严重程度及吋上报至调度中心。 另外， 当 websocket服务程序崩溃 吋， 该 Monitor还可以收集相关的系统信息， 并对 websocket服务程序尝试进行重 启操作， 以保证 websocket服务程序的高可用性。
[0081] 可以理解的是， CDN网络的调度中心根据 Monitor的反馈信息可以对各个节点 服务器当前的服务压力进行及吋的调整， 从而尽可能地提高 CDN网络中各个节 点服务器的服务质量， 尤其是缓解在特殊吋段 （比如网络繁忙吋段） 各个节点 服务器的服务压力。 [0082] 上述步骤 201~207主要从流媒体服务器一端描述该流媒体服务器在接收到目标 连接请求之后的处理过程， 在本实施例中， 流媒体服务器的处理步骤并不限于 上述步骤 201~207， 应当理解的是， 上述步骤 201~207描述的内容不是对本实施 例中流媒体服务器的工作步骤作出的限定。
[0083] 进一步地， 为了提高移动终端接收第一数据包的接收能力， 保证数据传输链路 的传输速率不受接收端 （移动终端） 的影响， 该移动终端可以预先设定一定大 小的缓存空间用于缓存接收到的第一数据包。 如图 4所示， 所述音视频的直播处 理方法还包括：
[0084] 401、 所述移动终端将获取到的第一数据包缓存在预设的缓存空间中；
[0085] 402、 所述移动终端实吋统计当前各个数据传输链路的传输速率和所述缓存空 间的状态；
[0086] 403、 所述移动终端根据所述传输速率和所述缓存空间的状态调整所述缓存空 间的大小； 其中， 当前的传输速率越大， 则调整后的所述缓存空间越小； 当前 的传输速率越小， 则调整后的所述缓存空间越大。
[0087] 对于上述步骤 401~403， 移动终端还可以对缓冲第一数据包中的各个环节进行 状态统计， 比如卡顿率、 传输速率、 抖动等， 然后根据状态统计的结果进行丢 数据帧或者加速解码、 渲染等追赶操作， 以动态调整缓存第一数据包的可用缓 存空间。
[0088] 可以理解的是， 移动终端在动态调整缓冲空间的大小吋， 一般来说， 若当前的 传输速率较大， 则表明网络状态较好， 此吋缓存空间可以适当地调小； 反之， 若当前的传输速率较小， 则表明网络状态较差， 此吋为了保证直播的实吋性， 缓存空间应当适度调大。
[0089] 105、 所述移动终端对所述第一数据包进行解封装， 得到与所述连接对象对应 的流媒体数据； 所述流媒体数据包括音频数据和 /或视频数据；
[0090] 106、 所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播放。
[0091] 对于上述步骤 105和 106， 可以理解的是， 第一数据包采用 websocket协议进行数 据封装， 移动终端在获取到第一数据包之后， 也需要采用 websocket协议对其进 行解封装， 得到第一数据包中的流媒体数据， 这些流媒体数据可以为频数据和 / 或视频数据。 在得到流媒体数据之后， 移动终端可以通过基于 html5的浏览器对 所述流媒体数据进行解码播放。
[0092] 进一步地， 对于上述步骤 105和 106， 这些流媒体数据可以具体为 RTMP流数据 。 所述流媒体服务器为 CDN网络的各个节点服务器中的一个节点服务器； 所述 流媒体服务器根据所述目标连接请求的连接对象的信息提取相应的流媒体数据 具体为： 所述流媒体服务器根据所述目标连接请求的连接对象的信息从所述 CD N网络的中心节点拉取相应的 RTMP流数据。 其中， 在所述流媒体服务器将所述 第一数据包发送给所述移动终端之前， 所述流媒体服务器对拉取到的所述 RTMP 流数据采用 websocket协议进行数据封装， 得到所述第一数据包， 移动终端接收 并解封装该第一数据包之后， 可以得到第一数据包中的 RTMP流数据。 因此， 所 述移动终端需要通过基于 html5的浏览器根据 RTMP协议对所述 RTMP流数据进行 解码播放。
[0093] 如图 5所示， 该流媒体服务器为 CDN网络中的一个边缘节点服务器， 获取流媒 体数据吋， 该流媒体服务器先从 CDN网络的中心节点拉取相应的流媒体数据， 这个拉取的通信过程采用 RTMP协议； 拉取得到流媒体数据之后， 将这些流媒体 数据使用 websocket协议封装成第一数据包， 然后发送第一数据包给移动终端， 这个发送的通信过程则采用 websocket协议。 移动终端 （即客户端） 获取到这些 第一数据包之后， 对这些第一数据包进行解包、 解码输出， 即可实现音视频的 直播。
[0094] 对于上述步骤 106， 如图 6所示， 当该流媒体数据为 RTMP流数据吋， 移动终端 可以在 websocket服务端接收到来自流媒体服务器的第一数据包之后， 通过 webso cket客户端在 Websocket的 onMessage回调中接收所述第一数据包解包后的 RTMP 流数据， 并放入待解复用队列。 然后， 移动终端根据 RTMP协议的定义， 首先接 收到音视频元数据帧， 移动终端解析出元数据信息， 进行相应的音视频解码参 数配置。 其次接收音视频的普通数据帧， 移动终端区分音视频数据类型， 解封 装后得到媒体编码数据分别放入对应媒体类型的解码队列中。
[0095] 接着， 移动终端启动媒体解码 worker线程， 每路流均可以根据相应媒体类型建 立解码线程。 对于视频数据， 移动终端可以采用 H.264解码库 Boardway.js, 新建 Decoder对象进行配置及解码。 而对于音频数据， 移动终端则调用 AudioContext 的 decodeAudioData进行解码， 将解码后的数据放入输出队列。 其中， 视频数据 通过渲染线程， 从输出队列中取出解码后的 YUV视频帧， 调用 WebGL (javaScri pt和 OpenGL ES 2.0结合的绘图标准） 绘制到 Canvas上。 对于音频数据， 移动终 端将解码数组通过 AudioContext连接到 AudioSourceNode进行播放， 另外， 还需 在渲染及播放之前进行音视频同步判断进行反馈调节。
[0096] 在音视频同步过程中， 移动终端可以采用音视频同步策略算法进行音视频数据 帧判断， 以音频吋间为基准， 在保证音频数据顺序播放的基础上， 根据结果进 行判断是否追赶或者丢弃某些解码后的视频帧， 从而确保了音频和视频在吋间 上的同步输出。
[0097] 另外， 移动终端通过浏览器输出这些音视频吋， 还可以实现多画面和混音控制 。 其中， 多画面控制可通过两种方式实现， 一种为创建一个单独的 canvas , 多路 流的画面根据 viewport来限定绘制范围； 另一种则分别创建 canvas , 便于单独控 制显示位置， 在建立 canvas之后获取 WebGL的上下文， 设置渲染纹理进行画面绘 制。 在音频方面， 移动终端可以通过 AudioContext创建多个 AudioBufferSource, 将对应流的解码数据连接到对应的 AudioBufferSource, 即可实现混音输出， 也便 于单独控制某路流的声音参数。
[0098] 本实施例提供的一种音视频的直播处理方法， 与现有的 RTMP流媒体技术相比
， RTMP流数据在浏览器 PC端主要通过 Flash播放器来进行解复用及解码， 而移 动端由于系统平台的原因， 没有相应的播放器支持， 如需支持 RTMP流数据的直 接传输则要处理浏览器长连接及兼容性等问题； 与现有的 HLS流媒体技术相比， 其流数据实际为分块切片文件， 使用 m3u8描述文件更新切片文件链接地址， 播 放器通过预先下载相应的切片文件实现连续播放的效果， 但是由于文件切片的 机制容易导致播放的实吋性不强， 延吋通常达到 10s以上， 极大地影响了音视频 直播的实吋性。
[0099] 而在本实施例提供的音视频的直播处理方法基于 Websocket协议可实现传输全 双工通信， 可自定义传输数据格式， 传输可提高安全性， 同吋目前市面上移动 终端的主流浏览器均对 Websocket协议有较好支持， 只需经过一次 http请求即可 持续进行音视频数据传输， 避免同步延迟， 实吋效果佳。 另外， 对第一数据包 进行解封装后， 本方法对视频数据采用 H.264解码后再利用 Canvas进行绘制， 可 支持多个画面绘制； 对音频数据则可以直接送给 AudioContext进行 AAC解码播放 ， 可支持多路播放， 充分利用了移动终端的硬件加速能力， 进一步提高音视频 直播的实吋性。
[0100] 应理解， 上述实施例中各步骤的序号的大小并不意味着执行顺序的先后， 各过 程的执行顺序应以其功能和内在逻辑确定， 而不应对本申请实施例的实施过程 构成任何限定。
[0101] 上面主要描述了一种音视频的直播处理方法， 下面将对一种音视频的直播处理 装置进行详细描述。
[0102] 图 7示出了本申请实施例中一种音视频的直播处理装置一个实施例结构图。
[0103] 本实施例中， 一种音视频的直播处理装置包括：
[0104] 播放地址获取模块 701， 用于根据输入的直播指令从业务后台获取 websocket协 议的播放地址， 所述播放地址由所述业务后台维护并指向一个流媒体服务器；
[0105] 传输链路建立模块 702， 用于根据获取到的所述播放地址与所述流媒体服务器 之间建立基于 websocket协议的数据传输链路；
[0106] 请求发送模块 703， 用于向所述流媒体服务器发送目标连接请求， 所述目标连 接请求包括连接对象的信息；
[0107] 数据包获取模块 704， 用于通过所述数据传输链路从所述流媒体服务器上获取 第一数据包； 所述第一数据包为所述流媒体服务器根据所述连接对象的信息提 取相应的流媒体数据， 并采用 websocket协议对提取到的流媒体数据进行数据封 装得到；
[0108] 数据包解封装模块 705， 用于对所述第一数据包进行解封装， 得到与所述连接 对象对应的流媒体数据； 所述流媒体数据包括音频数据和 /或视频数据；
[0109] 解码播放模块 706， 用于通过基于 html5的浏览器对所述流媒体数据进行解码播 放。
[0110] 进一步地， 所述播放地址所指向的流媒体服务器通过以下步骤确定：
[0111] CDN网络的调度中心根据所述移动终端与所述 CDN网络上各个节点服务器之间 的网络连接情况确定所述各个节点服务器中的一个节点服务器作为所述流媒体 服务器。
[0112] 进一步地， 在所述请求发送模块向所述流媒体服务器发送目标连接请求之后， 所述流媒体服务器执行如下步骤：
[0113] 流媒体服务器接收来自移动终端的目标连接请求；
[0114] 所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理器， 所述 目标事件处理器采用 websocket协议与所述移动终端进行数据传输；
[0115] 所述流媒体服务器査询是否已存在其它连接请求的连接对象与所述目标连接请 求的连接对象相同；
[0116] 若已存在其它连接请求的连接对象与所述目标连接请求的连接对象相同， 则所 述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体数据复用至所述目 标事件处理器， 以便于所述目标事件处理器将复用得到的流媒体数据发送给所 述移动终端； 所述第一连接请求是指所述其它连接请求中连接对象与所述目标 连接请求的连接对象相同的连接请求；
[0117] 若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相同， 则所 述流媒体服务器创建一个与所述目标连接请求对应的新的缓冲队列， 根据所述 目标连接请求的连接对象的信息提取相应的流媒体数据， 并将提取得到的流媒 体数据通过所述新的缓冲队列分发至所述目标事件处理器， 以便于所述目标事 件处理器将提取得到的流媒体数据发送给所述移动终端。
[0118] 进一步地， 所述流媒体服务器可以为 CDN网络的各个节点服务器中的一个节点 服务器；
[0119] 所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应的流媒体 数据具体可以为： 所述流媒体服务器根据所述目标连接请求的连接对象的信息 从所述 CDN网络的中心节点拉取相应的 RTMP流数据；
[0120] 在所述流媒体服务器将所述第一数据包发送给所述移动终端之前， 所述流媒体 服务器对拉取到的所述 RTMP流数据采用 websocket协议进行数据封装， 得到所述 第一数据包；
[0121] 所述解码播放模块具体用于： 所述移动终端通过基于 html5的浏览器根据 RTMP 协议对所述 RTMP流数据进行解码播放。
[0122] 进一步地， 所述音视频的直播处理装置还可以包括：
[0123] 缓存模块， 用于将获取到的第一数据包缓存在预设的缓存空间中；
[0124] 状态统计模块， 用于实吋统计当前各个数据传输链路的传输速率和所述缓存空 间的状态；
[0125] 缓存空间调整模块， 用于根据所述传输速率和所述缓存空间的状态调整所述缓 存空间的大小； 其中， 当前的传输速率越大， 则调整后的所述缓存空间越小； 当前的传输速率越小， 则调整后的所述缓存空间越大。
[0126] 图 8是本申请一实施例提供的移动终端的示意图。 如图 8所示， 该实施例的移动 终端 8包括： 处理器 80、 存储器 81以及存储在所述存储器 81中并可在所述处理器 80上运行的计算机可读指令 82， 例如执行音视频的直播处理方法的程序。 所述 处理器 80执行所述计算机可读指令 82吋实现上述各个音视频的直播处理方法实 施例中的步骤， 例如图 1所示的步骤 101至 106。 或者， 所述处理器 80执行所述计 算机可读指令 82吋实现上述各装置实施例中各模块 /单元的功能， 例如图 7所示模 块 701至 706的功能。
[0127] 示例性的， 所述计算机可读指令 82可以被分割成一个或多个模块 /单元， 所述 一个或者多个模块 /单元被存储在所述存储器 81中， 并由所述处理器 80执行， 以 完成本申请。 所述一个或多个模块 /单元可以是能够完成特定功能的一系列计算 机可读指令指令段， 该指令段用于描述所述计算机可读指令 82在所述移动终端 8 中的执行过程。
[0128] 所述移动终端 8可以是手机、 平板电脑等计算设备。 所述移动终端可包括， 但 不仅限于， 处理器 80、 存储器 81。 本领域技术人员可以理解， 图 8仅仅是移动终 端 8的示例， 并不构成对移动终端 8的限定， 可以包括比图示更多或更少的部件 ， 或者组合某些部件， 或者不同的部件， 例如所述移动终端还可以包括输入输 出设备、 网络接入设备、 总线等。
[0129] 所述处理器 80可以是中央处理单元 (Central Processing Unit, CPU) , 还可以是其 他通用处理器、 数字信号处理器（Digital Signal Processor, DSP)、 专用集成电路 (Application Specific Integrated Circuit， ASIC)、 现成可编程门阵列 (Field-Programmable Gate Array , FPGA)或者其他可编程逻辑器件、 分立门或者 晶体管逻辑器件、 分立硬件组件等。 通用处理器可以是微处理器或者该处理器 也可以是任何常规的处理器等。
[0130] 所述存储器 81可以是所述移动终端 8的内部存储单元， 例如移动终端 8的硬盘或 内存。 所述存储器 81也可以是所述移动终端 8的外部存储设备， 例如所述移动终 端 8上配备的插接式硬盘， 智能存储卡 （Smart Media Card,
SMC) ， 安全数字 （Secure Digital, SD) 卡， 闪存卡 （Flash Card) 等。 进一步 地， 所述存储器 81还可以既包括所述移动终端 8的内部存储单元也包括外部存储 设备。 所述存储器 81用于存储所述计算机可读指令以及所述移动终端所需的其 他程序和数据。 所述存储器 81还可以用于暂吋地存储已经输出或者将要输出的 数据。
[0131] 另外， 在本申请各个实施例中的各功能单元可以集成在一个处理单元中， 也可 以是各个单元单独物理存在， 也可以两个或两个以上单元集成在一个单元中。 上述集成的单元既可以采用硬件的形式实现， 也可以采用软件功能单元的形式 实现。
[0132] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用 吋， 可以存储在一个计算机可读取存储介质中。 基于这样的理解， 本申请的技 术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分 可以以软件产品的形式体现出来， 该计算机软件产品存储在一个存储介质中， 包括若干指令用以使得一台计算机设备 （可以是个人计算机， 服务器， 或者网 络设备等） 执行本申请各个实施例所述方法的全部或部分步骤。 而前述的存储 介质包括： U盘、 移动硬盘、 只读存储器 （ROM, Read-Only Memory) 、 随机 存取存储器 （RAM, Random Access Memory) 、 磁碟或者光盘等各种可以存储 程序代码的介质。
[0133] 以上所述， 以上实施例仅用以说明本申请的技术方案， 而非对其限制； 尽管参 照前述实施例对本申请进行了详细的说明， 本领域的普通技术人员应当理解： 其依然可以对前述各实施例所记载的技术方案进行修改， 或者对其中部分技术 特征进行等同替换； 而这些修改或者替换， 并不使相应技术方案的本质脱离本 申请各实施例技术方案的精神和范围

Claims

权利要求书
[权利要求 1] 一种音视频的直播处理方法， 其特征在于， 包括：
移动终端根据输入的直播指令从业务后台获取 websocket协议的播放 地址， 所述播放地址由所述业务后台维护并指向一个流媒体服务器； 所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建 立基于 websocket协议的数据传输链路；
所述移动终端向所述流媒体服务器发送目标连接请求， 所述目标连接 请求包括连接对象的信息；
所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一 数据包； 所述第一数据包为所述流媒体服务器根据所述连接对象的信 息提取相应的流媒体数据， 并采用 websocket协议对提取到的流媒体 数据进行数据封装得到；
所述移动终端对所述第一数据包进行解封装， 得到与所述连接对象对 应的流媒体数据； 所述流媒体数据包括音频数据和 /或视频数据； 所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播 放。
[权利要求 2] 根据权利要求 1所述的音视频的直播处理方法， 其特征在于， 所述播 放地址所指向的流媒体服务器通过以下步骤确定： CDN网络的调度中心根据所述移动终端与所述 CDN网络上各个节点 服务器之间的网络连接情况确定所述各个节点服务器中的一个节点服 务器作为所述流媒体服务器。
[权利要求 3] 根据权利要求 1所述的音视频的直播处理方法， 其特征在于， 在所述 移动终端向所述流媒体服务器发送目标连接请求之后， 还包括： 流媒体服务器接收来自移动终端的目标连接请求； 所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理 器， 所述目标事件处理器采用 websocket协议与所述移动终端进行数 据传输；
所述流媒体服务器査询是否已存在其它连接请求的连接对象与所述目 标连接请求的连接对象相同；
若已存在其它连接请求的连接对象与所述目标连接请求的连接对象相 同， 则所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体 数据复用至所述目标事件处理器， 以便于所述目标事件处理器将复用 得到的流媒体数据发送给所述移动终端； 所述第一连接请求是指所述 其它连接请求中连接对象与所述目标连接请求的连接对象相同的连接 请求；
若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相 同， 则所述流媒体服务器创建一个与所述目标连接请求对应的新的缓 冲队列， 根据所述目标连接请求的连接对象的信息提取相应的流媒体 数据， 并将提取得到的流媒体数据通过所述新的缓冲队列分发至所述 目标事件处理器， 以便于所述目标事件处理器将提取得到的流媒体数 据发送给所述移动终端。
[权利要求 4] 根据权利要求 3所述的音视频的直播处理方法， 其特征在于， 所述流 媒体服务器为 CDN网络的各个节点服务器中的一个节点服务器； 所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应 的流媒体数据具体为： 所述流媒体服务器根据所述目标连接请求的连 接对象的信息从所述 CDN网络的中心节点拉取相应的 RTMP流数据； 在所述流媒体服务器将所述第一数据包发送给所述移动终端之前， 所 述流媒体服务器对拉取到的所述 RTMP流数据采用 websocket协议进行 数据封装， 得到所述第一数据包；
所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播 放具体为： 所述移动终端通过基于 html5的浏览器根据 RTMP协议对所 述 RTMP流数据进行解码播放。
[权利要求 5] 根据权利要求 1至 4中任一项所述的音视频的直播处理方法， 其特征在 于， 所述音视频的直播处理方法还包括：
所述移动终端将获取到的第一数据包缓存在预设的缓存空间中； 所述移动终端实吋统计当前各个数据传输链路的传输速率和所述缓存 空间的状态；
所述移动终端根据所述传输速率和所述缓存空间的状态调整所述缓存 空间的大小； 其中， 当前的传输速率越大， 则调整后的所述缓存空间 越小； 当前的传输速率越小， 则调整后的所述缓存空间越大。
[权利要求 6] —种计算机可读存储介质， 所述计算机可读存储介质存储有计算机可 读指令， 其特征在于， 所述计算机可读指令被处理器执行吋实现如下 步骤：
移动终端根据输入的直播指令从业务后台获取 websocket协议的播放 地址， 所述播放地址由所述业务后台维护并指向一个流媒体服务器； 所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建 立基于 websocket协议的数据传输链路；
所述移动终端向所述流媒体服务器发送目标连接请求， 所述目标连接 请求包括连接对象的信息；
所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一 数据包； 所述第一数据包为所述流媒体服务器根据所述连接对象的信 息提取相应的流媒体数据， 并采用 websocket协议对提取到的流媒体 数据进行数据封装得到；
所述移动终端对所述第一数据包进行解封装， 得到与所述连接对象对 应的流媒体数据； 所述流媒体数据包括音频数据和 /或视频数据； 所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播 放。
[权利要求 7] 根据权利要求 6所述的计算机可读存储介质， 其特征在于， 所述播放 地址所指向的流媒体服务器通过以下步骤确定：
CDN网络的调度中心根据所述移动终端与所述 CDN网络上各个节点 服务器之间的网络连接情况确定所述各个节点服务器中的一个节点服 务器作为所述流媒体服务器。
[权利要求 8] 根据权利要求 6所述的计算机可读存储介质， 其特征在于， 在所述移 动终端向所述流媒体服务器发送目标连接请求之后， 还包括： 流媒体服务器接收来自移动终端的目标连接请求；
所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理 器， 所述目标事件处理器采用 websocket协议与所述移动终端进行数 据传输；
所述流媒体服务器査询是否已存在其它连接请求的连接对象与所述目 标连接请求的连接对象相同；
若已存在其它连接请求的连接对象与所述目标连接请求的连接对象相 同， 则所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体 数据复用至所述目标事件处理器， 以便于所述目标事件处理器将复用 得到的流媒体数据发送给所述移动终端； 所述第一连接请求是指所述 其它连接请求中连接对象与所述目标连接请求的连接对象相同的连接 请求；
若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相 同， 则所述流媒体服务器创建一个与所述目标连接请求对应的新的缓 冲队列， 根据所述目标连接请求的连接对象的信息提取相应的流媒体 数据， 并将提取得到的流媒体数据通过所述新的缓冲队列分发至所述 目标事件处理器， 以便于所述目标事件处理器将提取得到的流媒体数 据发送给所述移动终端。
[权利要求 9] 根据权利要求 8所述的计算机可读存储介质， 其特征在于， 所述流媒 体服务器为 CDN网络的各个节点服务器中的一个节点服务器； 所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应 的流媒体数据具体为： 所述流媒体服务器根据所述目标连接请求的连 接对象的信息从所述 CDN网络的中心节点拉取相应的 RTMP流数据； 在所述流媒体服务器将所述第一数据包发送给所述移动终端之前， 所 述流媒体服务器对拉取到的所述 RTMP流数据采用 websocket协议进行 数据封装， 得到所述第一数据包；
所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播 放具体为： 所述移动终端通过基于 html5的浏览器根据 RTMP协议对所 述 RTMP流数据进行解码播放。
[权利要求 10] 根据权利要求 6至 9中任一项所述的计算机可读存储介质， 其特征在于 ， 所述计算机可读指令被处理器执行吋还包括： 所述移动终端将获取到的第一数据包缓存在预设的缓存空间中； 所述移动终端实吋统计当前各个数据传输链路的传输速率和所述缓存 空间的状态；
所述移动终端根据所述传输速率和所述缓存空间的状态调整所述缓存 空间的大小； 其中， 当前的传输速率越大， 则调整后的所述缓存空间 越小； 当前的传输速率越小， 则调整后的所述缓存空间越大。
[权利要求 11] 一种移动终端， 包括存储器、 处理器以及存储在所述存储器中并可在 所述处理器上运行的计算机可读指令， 其特征在于， 所述处理器执行 所述计算机可读指令吋实现如下步骤：
移动终端根据输入的直播指令从业务后台获取 websocket协议的播放 地址， 所述播放地址由所述业务后台维护并指向一个流媒体服务器； 所述移动终端根据获取到的所述播放地址与所述流媒体服务器之间建 立基于 websocket协议的数据传输链路；
所述移动终端向所述流媒体服务器发送目标连接请求， 所述目标连接 请求包括连接对象的信息；
所述移动终端通过所述数据传输链路从所述流媒体服务器上获取第一 数据包； 所述第一数据包为所述流媒体服务器根据所述连接对象的信 息提取相应的流媒体数据， 并采用 websocket协议对提取到的流媒体 数据进行数据封装得到；
所述移动终端对所述第一数据包进行解封装， 得到与所述连接对象对 应的流媒体数据； 所述流媒体数据包括音频数据和 /或视频数据； 所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播 放。
12根据权利要求 11所述的移动终端， 其特征在于， 所述播放地址所 指向的流媒体服务器通过以下步骤确定：
CDN网络的调度中心根据所述移动终端与所述 CDN网络上各个节点 服务器之间的网络连接情况确定所述各个节点服务器中的一个节点服 务器作为所述流媒体服务器。
[权利要求 13] 根据权利要求 11所述的移动终端， 其特征在于， 在所述移动终端向所 述流媒体服务器发送目标连接请求之后， 还包括： 流媒体服务器接收来自移动终端的目标连接请求； 所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理 器， 所述目标事件处理器采用 websocket协议与所述移动终端的移动 终端进行数据传输；
所述流媒体服务器査询是否已存在其它连接请求的连接对象与所述目 标连接请求的连接对象相同；
若已存在其它连接请求的连接对象与所述目标连接请求的连接对象相 同， 则所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体 数据复用至所述目标事件处理器， 以便于所述目标事件处理器将复用 得到的流媒体数据发送给所述移动终端； 所述第一连接请求是指所述 其它连接请求中连接对象与所述目标连接请求的连接对象相同的连接 请求；
若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相 同， 则所述流媒体服务器创建一个与所述目标连接请求对应的新的缓 冲队列， 根据所述目标连接请求的连接对象的信息提取相应的流媒体 数据， 并将提取得到的流媒体数据通过所述新的缓冲队列分发至所述 目标事件处理器， 以便于所述目标事件处理器将提取得到的流媒体数 据发送给所述移动终端。
[权利要求 14] 根据权利要求 13所述的移动终端， 其特征在于， 所述流媒体服务器为
CDN网络的各个节点服务器中的一个节点服务器； 所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应 的流媒体数据具体为： 所述流媒体服务器根据所述目标连接请求的连 接对象的信息从所述 CDN网络的中心节点拉取相应的 RTMP流数据； 在所述流媒体服务器将所述第一数据包发送给所述移动终端之前， 所 述流媒体服务器对拉取到的所述 RTMP流数据采用 websocket协议进行 数据封装， 得到所述第一数据包；
所述移动终端通过基于 html5的浏览器对所述流媒体数据进行解码播 放具体为： 所述移动终端通过基于 html5的浏览器根据 RTMP协议对所 述 RTMP流数据进行解码播放。
[权利要求 15] 根据权利要求 11至 14中任一项所述的移动终端， 其特征在于， 所述处 理器执行所述计算机可读指令吋还包括：
所述移动终端将获取到的第一数据包缓存在预设的缓存空间中； 所述移动终端实吋统计当前各个数据传输链路的传输速率和所述缓存 空间的状态；
所述移动终端根据所述传输速率和所述缓存空间的状态调整所述缓存 空间的大小； 其中， 当前的传输速率越大， 则调整后的所述缓存空间 越小； 当前的传输速率越小， 则调整后的所述缓存空间越大。
[权利要求 16] —种音视频的直播处理装置， 其特征在于， 包括：
播放地址获取模块， 用于根据输入的直播指令从业务后台获取 websoc ket协议的播放地址， 所述播放地址由所述业务后台维护并指向一个 流媒体服务器；
传输链路建立模块， 用于根据获取到的所述播放地址与所述流媒体服 务器之间建立基于 websocket协议的数据传输链路； 请求发送模块， 用于向所述流媒体服务器发送目标连接请求， 所述目 标连接请求包括连接对象的信息；
数据包获取模块， 用于通过所述数据传输链路从所述流媒体服务器上 获取第一数据包； 所述第一数据包为所述流媒体服务器根据所述连接 对象的信息提取相应的流媒体数据， 并采用 websocket协议对提取到 的流媒体数据进行数据封装得到；
数据包解封装模块， 用于对所述第一数据包进行解封装， 得到与所述 连接对象对应的流媒体数据； 所述流媒体数据包括音频数据和 /或视 频数据；
解码播放模块， 用于通过基于 html5的浏览器对所述流媒体数据进行 解码播放。
[权利要求 17] 根据权利要求 16所述的音视频的直播处理装置， 其特征在于， 所述播 放地址所指向的流媒体服务器通过以下步骤确定： CDN网络的调度中心根据所述移动终端与所述 CDN网络上各个节点 服务器之间的网络连接情况确定所述各个节点服务器中的一个节点服 务器作为所述流媒体服务器。
[权利要求 18] 根据权利要求 16所述的音视频的直播处理装置， 其特征在于， 在所述 请求发送模块向所述流媒体服务器发送目标连接请求之后， 所述流媒 体服务器执行如下步骤：
流媒体服务器接收来自移动终端的目标连接请求； 所述流媒体服务器创建一个与所述目标连接请求对应的目标事件处理 器， 所述目标事件处理器采用 websocket协议与所述移动终端进行数 据传输；
所述流媒体服务器査询是否已存在其它连接请求的连接对象与所述目 标连接请求的连接对象相同；
若已存在其它连接请求的连接对象与所述目标连接请求的连接对象相 同， 则所述流媒体服务器将第一连接请求对应的缓冲队列中的流媒体 数据复用至所述目标事件处理器， 以便于所述目标事件处理器将复用 得到的流媒体数据发送给所述移动终端； 所述第一连接请求是指所述 其它连接请求中连接对象与所述目标连接请求的连接对象相同的连接 请求；
若不存在其它连接请求的连接对象与所述目标连接请求的连接对象相 同， 则所述流媒体服务器创建一个与所述目标连接请求对应的新的缓 冲队列， 根据所述目标连接请求的连接对象的信息提取相应的流媒体 数据， 并将提取得到的流媒体数据通过所述新的缓冲队列分发至所述 目标事件处理器， 以便于所述目标事件处理器将提取得到的流媒体数 据发送给所述移动终端。
[权利要求 19] 根据权利要求 18所述的音视频的直播处理装置， 其特征在于， 所述流 媒体服务器为 CDN网络的各个节点服务器中的一个节点服务器； 所述流媒体服务器根据所述目标连接请求的连接对象的信息提取相应 的流媒体数据具体为： 所述流媒体服务器根据所述目标连接请求的连 接对象的信息从所述 CDN网络的中心节点拉取相应的 RTMP流数据； 在所述流媒体服务器将所述第一数据包发送给所述移动终端之前， 所 述流媒体服务器对拉取到的所述 RTMP流数据采用 websocket协议进行 数据封装， 得到所述第一数据包；
所述解码播放模块具体用于： 所述移动终端通过基于 html5的浏览器 根据 RTMP协议对所述 RTMP流数据进行解码播放。
[权利要求 20] 根据权利要求 16至 19中任一项所述的音视频的直播处理装置， 其特征 在于， 所述音视频的直播处理装置还包括：
缓存模块， 用于将获取到的第一数据包缓存在预设的缓存空间中； 状态统计模块， 用于实吋统计当前各个数据传输链路的传输速率和所 述缓存空间的状态；
缓存空间调整模块， 用于根据所述传输速率和所述缓存空间的状态调 整所述缓存空间的大小； 其中， 当前的传输速率越大， 则调整后的所 述缓存空间越小； 当前的传输速率越小， 则调整后的所述缓存空间越 大。
PCT/CN2017/104528 2017-07-24 2017-09-29 一种音视频的直播处理方法、存储介质和一种移动终端 WO2019019370A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710605501.6 2017-07-24
CN201710605501.6A CN107483972B (zh) 2017-07-24 2017-07-24 一种音视频的直播处理方法、存储介质和一种移动终端

Publications (1)

Publication Number Publication Date
WO2019019370A1 true WO2019019370A1 (zh) 2019-01-31

Family

ID=60595385

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/104528 WO2019019370A1 (zh) 2017-07-24 2017-09-29 一种音视频的直播处理方法、存储介质和一种移动终端

Country Status (2)

Country Link
CN (1) CN107483972B (zh)
WO (1) WO2019019370A1 (zh)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111556126A (zh) * 2020-04-24 2020-08-18 杭州浮云网络科技有限公司 模型管理方法、系统、计算机设备和存储介质
CN112039961A (zh) * 2020-08-13 2020-12-04 深圳市创凯智能股份有限公司 流媒体系统、数据流收集方法以及存储介质
CN112333529A (zh) * 2020-11-02 2021-02-05 广州华多网络科技有限公司 直播流加载方法及其装置、设备、介质
CN112383788A (zh) * 2020-11-11 2021-02-19 成都威爱新经济技术研究院有限公司 一种基于智能ai技术的直播实时图像提取系统及方法
CN112804542A (zh) * 2020-12-31 2021-05-14 武汉兴图新科电子股份有限公司 应用于云视频融合平台的浏览器点播视音频的方法及终端
CN113271316A (zh) * 2021-06-09 2021-08-17 腾讯科技（深圳）有限公司 多媒体数据的传输控制方法和装置、存储介质及电子设备
CN113766266A (zh) * 2021-09-10 2021-12-07 阿波罗智联(北京)科技有限公司 音视频处理方法、装置、设备以及存储介质
CN113840161A (zh) * 2020-06-23 2021-12-24 龙芯中科技术股份有限公司 流媒体传输方法、接收方法、装置、电子设备及储存介质
CN113973212A (zh) * 2021-09-10 2022-01-25 佛山中科云图智能科技有限公司 在线无人机直播方法、装置、存储介质以及电子设备
CN114025244A (zh) * 2021-10-08 2022-02-08 中移（杭州）信息技术有限公司 音视频推送方法、装置、设备及计算机可读存储介质
CN114143625A (zh) * 2021-11-24 2022-03-04 成都小步创想慧联科技有限公司 一种部标车载设备对讲的方法、装置以及系统
CN114173205A (zh) * 2021-12-06 2022-03-11 倍智智能数据运营有限公司 一种在小程序上播放rtsp音视频流的方法
CN114286189A (zh) * 2021-12-16 2022-04-05 康佳集团股份有限公司 超高清多路直播显示处理方法、系统、智能终端及介质
CN114339270A (zh) * 2020-10-12 2022-04-12 腾讯科技（深圳）有限公司 直播中发放物品的控制方法、系统、电子设备及存储介质
CN114363281A (zh) * 2021-12-31 2022-04-15 阿里巴巴（中国）有限公司 消息传输方法、系统、设备、存储介质及程序产品
CN114374855A (zh) * 2022-01-05 2022-04-19 烽火通信科技股份有限公司 直播花屏诊断方法、装置、设备及可读存储介质
CN114727131A (zh) * 2022-03-28 2022-07-08 慧之安信息技术股份有限公司 基于机器学习的流媒体推流性能提升方法和装置
CN115103215A (zh) * 2022-06-16 2022-09-23 招商银行股份有限公司 直播的质检方法、系统、Web服务器及存储介质
CN116055658A (zh) * 2023-01-10 2023-05-02 北京市博汇科技股份有限公司 网站及app的多画面实时图像帧融合监测方法及系统
CN116600010A (zh) * 2023-07-17 2023-08-15 腾讯科技（深圳）有限公司 一种数据传输方法、装置、设备、存储介质及程序产品
CN116827914A (zh) * 2023-04-19 2023-09-29 广州好智信息技术有限公司 一种用于移动端的视频信息防劫持、盗取的方法及系统

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108206972B (zh) * 2018-01-02 2019-10-25 武汉斗鱼网络科技有限公司 直播间人气处理方法、装置、服务器及存储介质
CN108200480A (zh) * 2018-02-07 2018-06-22 广州市千钧网络科技有限公司 一种游戏直播互动方法、相关设备及系统
CN108718311A (zh) * 2018-05-18 2018-10-30 深圳市腾讯网络信息技术有限公司 移动终端的网页直播方法、装置及系统
CN110545484B (zh) * 2018-05-29 2021-12-14 北京字节跳动网络技术有限公司 一种用于媒体播放的缓冲队列管理方法、装置及存储介质
CN110620959B (zh) * 2018-06-20 2020-12-25 杭州海康威视数字技术股份有限公司 一种数据处理方法、装置、电子设备、系统及存储介质
CN108966006A (zh) * 2018-07-24 2018-12-07 上海小蚁科技有限公司 视频的播放方法、浏览器设备及可读存储介质
CN109640123A (zh) * 2018-11-27 2019-04-16 平安科技（深圳）有限公司 直播流的推送方法、装置、计算机设备及存储介质
CN109672902A (zh) * 2018-12-25 2019-04-23 百度在线网络技术（北京）有限公司 一种视频抽帧方法、装置、电子设备和存储介质
CN110121112A (zh) * 2019-05-14 2019-08-13 重庆商勤科技有限公司 一种基于浏览器的视频播放控制方法、系统及装置
CN110557655B (zh) * 2019-09-06 2021-10-26 卓米私人有限公司 一种视频画面显示方法、装置、电子设备及存储介质
CN110944225B (zh) * 2019-11-20 2022-10-04 武汉长江通信产业集团股份有限公司 一种基于html5的不同帧率音视频的同步方法及装置
CN111510738B (zh) * 2020-04-26 2023-08-11 北京字节跳动网络技术有限公司 一种直播中音频的传输方法及装置
CN111757136A (zh) * 2020-06-29 2020-10-09 北京百度网讯科技有限公司 网页音频直播方法、装置、设备和存储介质
CN112073809B (zh) * 2020-08-09 2022-08-09 富盛科技股份有限公司 一种支持浏览器播放任意编码格式视频的方法
CN112039899B (zh) * 2020-09-01 2022-08-02 深圳创维数字技术有限公司 虚拟现实系统控制方法、系统和存储介质
CN114339268B (zh) * 2020-10-10 2023-08-29 腾讯科技（深圳）有限公司 一种直播数据处理方法、装置和计算机可读存储介质
CN112601114B (zh) * 2020-12-14 2023-03-21 杭州当虹科技股份有限公司 一种基于钩子回调的gb28181按需拉流实现方法
CN114979783B (zh) * 2021-02-26 2024-04-09 华为技术有限公司 一种音视频播放方法、装置和电子设备
CN113068059B (zh) * 2021-03-22 2022-12-13 平安普惠企业管理有限公司 视频直播方法、装置、设备及存储介质
CN114401307A (zh) * 2022-01-19 2022-04-26 平安国际智慧城市科技股份有限公司 数据请求方法、系统及存储介质
CN115242760B (zh) * 2022-07-20 2023-12-26 深圳市灵镜技术有限公司 一种基于WebRTC的SFU系统及方法
CN116233085A (zh) * 2023-05-08 2023-06-06 深圳市微智体技术有限公司 一种多终端的流媒体传输方法、系统及流媒体服务器集群

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103079089A (zh) * 2012-12-27 2013-05-01 合一网络技术(北京)有限公司 一种用于将视频文件动态生成为ts文件的装置及方法
CN105872587A (zh) * 2015-11-25 2016-08-17 乐视云计算有限公司 视频请求的处理方法及装置
US20170171287A1 (en) * 2014-02-13 2017-06-15 Koninklijke Kpn N.V. Requesting multiple chunks from a network node on the basis of a single request message

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103702238B (zh) * 2013-12-23 2017-11-28 华为终端有限公司 一种多屏视频共享方法及终端、服务器
CN104244108A (zh) * 2014-09-24 2014-12-24 上海网达软件股份有限公司 一种直播方法及系统
CN105743973B (zh) * 2016-01-22 2019-05-10 上海科牛信息科技有限公司 一种多人多设备实时同步云协作方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103079089A (zh) * 2012-12-27 2013-05-01 合一网络技术(北京)有限公司 一种用于将视频文件动态生成为ts文件的装置及方法
US20170171287A1 (en) * 2014-02-13 2017-06-15 Koninklijke Kpn N.V. Requesting multiple chunks from a network node on the basis of a single request message
CN105872587A (zh) * 2015-11-25 2016-08-17 乐视云计算有限公司 视频请求的处理方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ZHANG, WEN: "The Research and Implementation of TCP/RTMP/WebSocket Protocol Conversion in Video Conference System", MASTER'S DEGREE THESIS OF SOUTH CHINA UNIVERSITY OF TECHNOLOGY, 28 April 2016 (2016-04-28), pages 38 - 40 *

Cited By (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111556126B (zh) * 2020-04-24 2023-04-18 杭州浮云网络科技有限公司 模型管理方法、系统、计算机设备和存储介质
CN111556126A (zh) * 2020-04-24 2020-08-18 杭州浮云网络科技有限公司 模型管理方法、系统、计算机设备和存储介质
CN113840161A (zh) * 2020-06-23 2021-12-24 龙芯中科技术股份有限公司 流媒体传输方法、接收方法、装置、电子设备及储存介质
CN113840161B (zh) * 2020-06-23 2023-07-25 龙芯中科技术股份有限公司 流媒体传输方法、接收方法、装置、电子设备及储存介质
CN112039961A (zh) * 2020-08-13 2020-12-04 深圳市创凯智能股份有限公司 流媒体系统、数据流收集方法以及存储介质
CN112039961B (zh) * 2020-08-13 2023-08-08 深圳市创凯智能股份有限公司 流媒体系统、数据流收集方法以及存储介质
CN114339270B (zh) * 2020-10-12 2024-01-09 腾讯科技（深圳）有限公司 直播中发放物品的控制方法、系统、电子设备及存储介质
CN114339270A (zh) * 2020-10-12 2022-04-12 腾讯科技（深圳）有限公司 直播中发放物品的控制方法、系统、电子设备及存储介质
CN112333529B (zh) * 2020-11-02 2022-08-05 广州华多网络科技有限公司 直播流加载方法及其装置、设备、介质
CN112333529A (zh) * 2020-11-02 2021-02-05 广州华多网络科技有限公司 直播流加载方法及其装置、设备、介质
CN112383788A (zh) * 2020-11-11 2021-02-19 成都威爱新经济技术研究院有限公司 一种基于智能ai技术的直播实时图像提取系统及方法
CN112804542A (zh) * 2020-12-31 2021-05-14 武汉兴图新科电子股份有限公司 应用于云视频融合平台的浏览器点播视音频的方法及终端
CN113271316A (zh) * 2021-06-09 2021-08-17 腾讯科技（深圳）有限公司 多媒体数据的传输控制方法和装置、存储介质及电子设备
CN113271316B (zh) * 2021-06-09 2022-09-13 腾讯科技（深圳）有限公司 多媒体数据的传输控制方法和装置、存储介质及电子设备
CN113973212A (zh) * 2021-09-10 2022-01-25 佛山中科云图智能科技有限公司 在线无人机直播方法、装置、存储介质以及电子设备
CN113766266B (zh) * 2021-09-10 2024-02-13 阿波罗智联(北京)科技有限公司 音视频处理方法、装置、设备以及存储介质
CN113766266A (zh) * 2021-09-10 2021-12-07 阿波罗智联(北京)科技有限公司 音视频处理方法、装置、设备以及存储介质
CN114025244A (zh) * 2021-10-08 2022-02-08 中移（杭州）信息技术有限公司 音视频推送方法、装置、设备及计算机可读存储介质
CN114143625A (zh) * 2021-11-24 2022-03-04 成都小步创想慧联科技有限公司 一种部标车载设备对讲的方法、装置以及系统
CN114143625B (zh) * 2021-11-24 2024-03-12 成都小步创想慧联科技有限公司 一种部标车载设备对讲的方法、装置以及系统
CN114173205A (zh) * 2021-12-06 2022-03-11 倍智智能数据运营有限公司 一种在小程序上播放rtsp音视频流的方法
CN114286189B (zh) * 2021-12-16 2023-12-05 康佳集团股份有限公司 超高清多路直播显示处理方法、系统、智能终端及介质
CN114286189A (zh) * 2021-12-16 2022-04-05 康佳集团股份有限公司 超高清多路直播显示处理方法、系统、智能终端及介质
CN114363281B (zh) * 2021-12-31 2024-06-04 阿里巴巴（中国）有限公司 消息传输方法、系统、设备、存储介质及程序产品
CN114363281A (zh) * 2021-12-31 2022-04-15 阿里巴巴（中国）有限公司 消息传输方法、系统、设备、存储介质及程序产品
CN114374855B (zh) * 2022-01-05 2023-05-23 烽火通信科技股份有限公司 直播花屏诊断方法、装置、设备及可读存储介质
CN114374855A (zh) * 2022-01-05 2022-04-19 烽火通信科技股份有限公司 直播花屏诊断方法、装置、设备及可读存储介质
CN114727131A (zh) * 2022-03-28 2022-07-08 慧之安信息技术股份有限公司 基于机器学习的流媒体推流性能提升方法和装置
CN115103215A (zh) * 2022-06-16 2022-09-23 招商银行股份有限公司 直播的质检方法、系统、Web服务器及存储介质
CN115103215B (zh) * 2022-06-16 2024-05-28 招商银行股份有限公司 直播的质检方法、系统、Web服务器及存储介质
CN116055658B (zh) * 2023-01-10 2024-06-04 北京市博汇科技股份有限公司 网站及app的多画面实时图像帧融合监测方法及系统
CN116055658A (zh) * 2023-01-10 2023-05-02 北京市博汇科技股份有限公司 网站及app的多画面实时图像帧融合监测方法及系统
CN116827914A (zh) * 2023-04-19 2023-09-29 广州好智信息技术有限公司 一种用于移动端的视频信息防劫持、盗取的方法及系统
CN116600010B (zh) * 2023-07-17 2023-10-10 腾讯科技（深圳）有限公司 一种数据传输方法、装置、设备、存储介质及程序产品
CN116600010A (zh) * 2023-07-17 2023-08-15 腾讯科技（深圳）有限公司 一种数据传输方法、装置、设备、存储介质及程序产品

Also Published As

Publication number Publication date
CN107483972B (zh) 2019-05-07
CN107483972A (zh) 2017-12-15

Similar Documents

Publication Publication Date Title
WO2019019370A1 (zh) 一种音视频的直播处理方法、存储介质和一种移动终端
WO2023024834A9 (zh) 一种游戏数据处理方法、装置及存储介质
WO2019019371A1 (zh) 一种流媒体数据的传输方法、存储介质和流媒体服务器
US9674252B2 (en) System and method for efficient delivery of repetitive multimedia content
CN103200461B (zh) 一种多台播放终端同步播放系统及播放方法
CN108347622B (zh) 多媒体数据推送方法、装置、存储介质及设备
WO2017088484A1 (zh) 基于云计算的实时离屏渲染方法、装置及系统
WO2019128800A1 (zh) 一种内容服务的实现方法、装置及内容分发网络节点
WO2021179557A1 (zh) 视频流播放方法、系统、终端及存储介质
WO2014139269A1 (zh) 基于虚拟桌面的视频播放、处理方法及装置
KR20130140192A (ko) 실시간 비디오 검출기
WO2020216279A1 (zh) 一种媒体流发送方法、装置和设备
WO2012171507A1 (zh) 向客户端传输数据文件的方法和装置
US20170019197A1 (en) System for synchronous playback of media using a hybrid bluetooth™ and wi-fi network
US11863841B2 (en) Video playing control method and system
US20150046568A1 (en) Method and system for playing multicast over-the-top (ott) content streams
CN104093088A (zh) 实现自适应流媒体播放控制的系统及方法
WO2017101370A1 (zh) 直播视频的处理方法及装置
CN108494792A (zh) 一种flash播放器播放hls视频流的转换系统及其工作方法
CN107547517B (zh) 音视频节目录制方法和网络设备及计算机装置
CN113824925A (zh) 一种web无插件视频监控系统和方法
WO2016197955A1 (zh) 多媒体流组播方法和装置
CN114025191A (zh) 一种基于Nginx-rtmp的webrtc低延迟直播方法及系统
WO2015077983A1 (zh) 在家庭网络中播放媒体的装置和方法
US20140226561A1 (en) Method and apparatus for video or multimedia content delivery

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: 17919252

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17919252

Country of ref document: EP

Kind code of ref document: A1

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 17.03.2020)

122 Ep: pct application non-entry in european phase

Ref document number: 17919252

Country of ref document: EP

Kind code of ref document: A1