WO2021185302A1 - 基于云手机的直播和配置方法以及相关装置和*** - Google Patents

基于云手机的直播和配置方法以及相关装置和*** Download PDF

Info

Publication number
WO2021185302A1
WO2021185302A1 PCT/CN2021/081451 CN2021081451W WO2021185302A1 WO 2021185302 A1 WO2021185302 A1 WO 2021185302A1 CN 2021081451 W CN2021081451 W CN 2021081451W WO 2021185302 A1 WO2021185302 A1 WO 2021185302A1
Authority
WO
WIPO (PCT)
Prior art keywords
cloud
live broadcast
phone
live
content
Prior art date
Application number
PCT/CN2021/081451
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 CN202010387298.1A external-priority patent/CN113497945B/zh
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Publication of WO2021185302A1 publication Critical patent/WO2021185302A1/zh

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21Server components or server architectures
    • H04N21/218Source of audio or video content, e.g. local disk arrays
    • H04N21/2187Live feed
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server

Definitions

  • This application relates to the field of cloud computing, and in particular to a live broadcast and configuration method based on cloud mobile phones, and related devices and systems.
  • Video live broadcasting has become one of the industries with the highest traffic share in the Internet. Live broadcasting platforms with a large number of user groups have emerged in the live broadcasting industry. The degree of overlap between them is not high, which leads to the fact that for most anchors, compared with live broadcasts on a single platform, live broadcasts on multiple platforms at the same time can quickly gain more audiences, and thus bring more live broadcast revenue.
  • a host needs to use multiple mobile phones to perform simultaneous live broadcasts on multiple live broadcast platforms.
  • the host installs different types of live broadcast applications for each mobile phone.
  • the different types of live broadcast applications serve different live broadcast platforms.
  • the live video obtained by each mobile phone is sent to the corresponding live broadcast platform via the live application running on the mobile phone via the Internet.
  • Viewers of different live broadcast platforms use their own mobile phones to view The corresponding live broadcast platform pulls the video content to realize multi-platform live broadcast.
  • each new live broadcast platform host must purchase a mobile phone, which leads to higher live broadcast costs; secondly, each mobile phone needs to be placed at a different angle, and the host cannot face each other at the same time. Two mobile phones make the interaction effect poor; and when multiple mobile phones share the network, it is easy to cause network congestion, which will cause live broadcast jams and reduce user experience.
  • This application provides a cloud-based mobile phone-based live broadcast and configuration method, as well as related devices and systems, which are used to solve the problems of high cost, poor interaction effect, and prone to jams when the anchor conducts live broadcast on multiple platforms.
  • a cloud-based mobile phone-based live broadcast method is provided.
  • the method is applied to a live broadcast system.
  • the live broadcast system includes a content distribution service node and at least two cloud mobile phones.
  • the at least two cloud mobile phones are respectively connected to different live broadcast platforms.
  • the content distribution service node is provided with a streaming address and a streaming address, and the method includes the following steps: first, the content distribution service node receives the live content sent by the anchor terminal to the streaming address, and associates the live content with the streaming address, where: The live content is generated by the anchor terminal, and then at least two cloud mobile phones pull the live content from the streaming address, and send the live content to different live broadcast platforms.
  • the host terminal after the host terminal generates the live content, it pushes it to the push address of the content distribution service node.
  • the content distribution service node can pull the live content from the push address and associate the live content with
  • at least two cloud mobile phones pull the live content from the streaming address and send the live content to different live broadcast platforms for video live broadcast, which can achieve the purpose of multiple cloud mobile phones sharing the live content generated by the anchor terminal for live broadcast ,
  • the host does not need to purchase a new host terminal to serve different live broadcast platforms, instead it is realized by cloud mobile phones, and the rental price of cloud mobile phones is lower than the purchase price of the host terminal, which can solve the problem that the host users need to purchase multiple anchors for multi-platform live broadcasting.
  • At least two cloud mobile phones in the cloud so that different live broadcast platforms can obtain the same live content from the corresponding cloud mobile phones for video live broadcast, which can improve the interactive effect between the host and the audience on different platforms, and only upload is required during the live broadcast
  • the occupied network bandwidth is lower than uploading multiple channels of live content, which can effectively solve the problem of live broadcast jams.
  • the live broadcast system further includes a cloud mobile phone management node.
  • the above method further includes the following steps: the cloud mobile phone management node receives the anchor terminal The sent cloud phone creation information, where the cloud phone creation information includes specification information of at least two cloud phones, so that the cloud phone management node creates at least two cloud phones according to the cloud phone creation information, and then sends the push address to the anchor terminal , Set the streaming address to at least two cloud phones mentioned above.
  • the host before the host starts the live broadcast, the host can create a corresponding number of cloud phones according to the type of live broadcast platform required.
  • a cloud phone is connected to a specific type of live broadcast platform, so that multiple cloud phones are connected to different live broadcasts.
  • Platform connection multiple cloud mobile phones pull live content from the content distribution service node, so as to realize multi-platform live broadcast.
  • the cloud mobile phone management node sets the streaming address of the content distribution service node before the first virtual camera and the second virtual camera.
  • the above method further includes the following steps: the cloud mobile phone management node creates the content distribution service Node, and configure the above-mentioned push address and the above-mentioned pull address for the content distribution service node.
  • the cloud phone management node can create a cloud phone in the cloud phone resource pool of the data center, and create a content distribution service node in the virtual machine resource pool of the data center, so that at least two cloud phones applied for by the same user can
  • a dedicated content distribution service node a user account corresponds to a content distribution service node one-to-one, and the live broadcast traffic between multiple users will not conflict and avoid the occurrence of live broadcast jams.
  • both cloud mobile phones and content distribution service nodes are virtual resources provided by public clouds, which greatly reduces the cost of multi-platform live broadcasting.
  • the cloud phone creation information includes the specification information of the first cloud phone and the specification information of the second cloud phone
  • the specification information of the first cloud phone includes the information of the first live broadcast application and the information of the first virtual camera.
  • Information, the specification information of the second cloud mobile phone includes the information of the second live broadcast application and the information of the second virtual camera.
  • the cloud phone management node can create the first cloud phone and the second cloud phone in the cloud phone resource pool according to the cloud phone creation information, where the first cloud phone is set with the first virtual camera and the first live broadcast application, and the second cloud phone is set with The second virtual camera and the second live broadcast application.
  • the first live broadcast application serves the first live broadcast platform
  • the second live broadcast application serves the second live broadcast platform.
  • the first live broadcast platform and the second live broadcast platform are different live broadcast platforms.
  • the streaming address It is set on the first virtual camera and the second virtual camera.
  • the cloud phone management node creates the first cloud phone and the second cloud phone according to the cloud phone creation information, and then sets the streaming address to the first virtual camera of the first cloud phone and the second virtual camera of the second cloud phone.
  • Camera so that when the host starts live broadcast, the host terminal pushes the live content to the push address of the content distribution service node, and the content distribution service node associates the live content with the pull address.
  • the first virtual camera and the second virtual The camera can pull the live content from the streaming address, so that both the first cloud mobile phone and the second cloud mobile phone can obtain the live content sent by the host terminal, so that multiple cloud mobile phones can share the live content collected by the host terminal camera for live broadcasting.
  • the purpose is to solve the high cost of multi-platform live broadcast system, poor interactive effect and prone to jams.
  • the cloud phone management node creates the first cloud phone and the second cloud phone in the cloud phone resource pool according to the cloud phone creation information, and can also set the first driver for the first cloud phone.
  • a driver is used to control the first virtual camera to send the live content pulled by the first virtual camera from the streaming address to the first live application when receiving the first camera call instruction generated by the first live application.
  • a second driver can also be set for the second cloud mobile phone, where the second driver is used to control the second virtual camera to send the second camera call instruction generated by the second live application to the second live application The live content pulled by the second virtual camera from the streaming address.
  • the above implementation is implemented so that when the live application on the cloud mobile phone sends a camera call instruction to the virtual camera, the virtual camera returns the live content pulled from the streaming address to the live application, and the live application has no sense of the source of the live content, and then This achieves the purpose of returning the live broadcast content generated by the anchor terminal to the live broadcast application for live video without modifying the live broadcast application.
  • the live broadcast application is generally provided by a third-party live broadcast platform, and the video live broadcast method of this application does not need to modify the live broadcast application, the live broadcast platform for third parties has universal applicability.
  • the cloud mobile phone management node can receive the live broadcast start command sent by the anchor terminal, and then start the first live broadcast application and the second live broadcast application according to the live broadcast start command, where the first live broadcast
  • the first camera calling instruction is generated after the application is started
  • the second camera calling instruction is generated after the second live application is started.
  • the cloud phone management node can start the live broadcast application in each cloud phone.
  • the live broadcast application sends a camera call instruction to the virtual camera of the cloud phone where it is located, and the virtual camera sends the live broadcast
  • the application returns the live content pulled from the streaming address, so that each live application can obtain the live content generated by the host terminal, thereby realizing the purpose of live broadcast of the live content generated by one host terminal on multiple live platforms.
  • At least two cloud mobile phones pull live content from the streaming address and send the live content to different live broadcasting platforms, including: the first virtual camera pulls the live content from the streaming address, The first live broadcast application obtains the live content from the first virtual camera and sends the live content to the first live broadcast platform; the second virtual camera pulls the live content from the streaming address, and the second live application obtains the live content from the second virtual camera and sends it to the first live broadcast platform.
  • the live broadcast content is sent to the second live broadcast platform.
  • the content distribution service node receives the live content generated by the host terminal, and then associates the live content with the streaming address.
  • the virtual cameras of each cloud mobile phone are pulled from the streaming address of the content distribution service node.
  • the live broadcast application on each cloud mobile phone can send the live content obtained from the virtual camera to the corresponding live broadcast platform for video live broadcast, so that the live content generated by one anchor terminal can be broadcast live on multiple live broadcast platforms.
  • the method further includes the following steps: the content distribution service node receives the control flow sent by the anchor terminal to the push streaming address, and sends the control flow to the first cloud mobile phone and the second cloud mobile phone, respectively ,
  • the control flow can be a command flow, used to control the switch of the front and rear cameras of the host terminal, camera focus, contrast, brightness, etc.
  • the live broadcast application is provided by a third-party live broadcast platform. If the live broadcast application fails to receive the control flow sent by the camera while it is running, it may be considered that the camera is malfunctioning, and the live broadcast application may report an error to the operating system or fail to operate normally. , But because the camera provided by the cloud mobile phone is a virtual camera, the virtual camera cannot provide control flow to the live application, which makes the live application report an error or cannot run normally.
  • the host terminal can send the control flow of the local camera
  • the content distribution service node sends the control flow to the virtual camera of each cloud mobile phone
  • the virtual camera can return the control flow of the host terminal to the live application, so that the virtual camera of the cloud mobile phone can send the target camera to the live application Control flow to ensure the normal operation of the live broadcast application.
  • the live broadcast application is generally provided by a third-party live broadcast platform, and the video live broadcast method of this application does not need to modify the live broadcast application, the live broadcast platform for third parties has universal applicability.
  • the live content includes video streams and audio streams.
  • the camera of the live terminal collects the host’s video stream, the microphone of the live terminal collects the host’s audio stream, and the live terminal synthesizes the video stream and audio stream into the live content.
  • This program is especially suitable for the scene of live performance by the anchor.
  • the live content may also include another audio and video stream, which combines the audio and video stream generated when the host terminal runs the application and the audio stream generated by the host narration collected by the microphone.
  • This program is especially suitable for online game live broadcast, online classroom, design software teaching and other scenarios.
  • the virtual camera on the cloud mobile phone receives the call instruction sent by the live streaming platform, and before returning the live content pulled from the streaming address to the live streaming platform, it can first pull the previous from the streaming address.
  • the taken live content is formatted and converted into a format that can be recognized by the live broadcast application.
  • the video stream in the live content is converted into the original format audio and video data collected by the main broadcast terminal camera, and then it is returned to the live broadcast platform.
  • the implementation of the foregoing implementation manner can avoid the problem of application error reporting due to the fact that the live broadcast application cannot recognize the format of the live broadcast content returned by the virtual camera. Since the live broadcast application is generally provided by a third-party live broadcast platform, and the video live broadcast method of this application does not need to modify the live broadcast application, the live broadcast platform for third parties has universal applicability.
  • the content distribution service node after the content distribution service node pulls the live content and control stream sent by the host terminal from the streaming address, it can also perform secondary transcoding on the live content according to the bit rate requirements of each cloud mobile phone. For example, the first live broadcast application on the first cloud mobile phone requires live content with bit rate A, and the second live broadcast application on the second cloud mobile phone requires live content with bit rate B. At this time, the content distribution service node can also use the code of each cloud mobile phone.
  • the live content is transcoded a second time, the live content of bit rate A and the live content of bit rate B are obtained, and all the live content of the two bit rates are pushed to the streaming address for the first cloud mobile phone
  • the first virtual camera pulls the live content of bit rate A from the streaming address
  • the second virtual camera of the second cloud mobile phone pulls the live content of bit rate B from the streaming address, where the bit rate of each cloud mobile phone
  • the requirement may be that after the cloud mobile phone management node creates the first cloud mobile phone and the second cloud mobile phone, they are stored in the database of the content distribution service node when the content distribution service node is created.
  • the implementation of the foregoing implementation manners can make the cloud mobile phone-based live broadcast method provided in this application applicable to various live broadcast platforms with bitrate requirements, and has universal applicability for third-party live broadcast platforms.
  • a cloud phone-based live broadcast configuration method includes the following steps: a cloud phone management node receives cloud phone creation information sent by an anchor terminal, wherein the cloud phone creation information includes the information of at least two cloud phones The specification information enables the cloud phone management node to create at least two cloud phones based on the cloud phone creation information.
  • the above-mentioned at least two cloud phones are connected to different live broadcast platforms, and then the push stream address is sent to the host terminal, and the push stream address is generated by the host terminal
  • the destination address of the live content is set to the above-mentioned at least two cloud phones, and the streaming address is used to provide the live content for the at least two cloud phones to pull.
  • the cloud phone management node creates the first cloud phone and the second cloud phone according to the cloud phone creation information, and then sets the streaming address to the first virtual camera of the first cloud phone and the second cloud phone.
  • the second virtual camera so that when the host starts live broadcast, the host terminal pushes the live content to the push address of the content distribution service node, and the content distribution service node associates the live content with the pull address.
  • the first virtual camera can pull live content from the streaming address, so that both the first cloud phone and the second cloud phone can obtain the live content sent by the anchor terminal, so that multiple cloud phones share the live content collected by the anchor terminal camera
  • live broadcasting solves the high cost of multi-platform live broadcasting system, poor interactive effects, and prone to jams.
  • the above method further includes the following steps: the cloud mobile phone management node creates a content distribution service node and sets it for the content distribution service node Push stream address and pull stream address.
  • the cloud phone management node can create a cloud phone in the cloud phone resource pool of the data center, and create a content distribution service node in the virtual machine resource pool of the data center, so that the same At least two cloud phones applied by users can have a dedicated content distribution service node, and each user's live broadcast traffic will not conflict, avoiding the occurrence of live broadcast jams, and the cloud phone and content distribution service nodes are both public clouds
  • the virtual resources provided greatly reduce the cost of multi-platform live broadcasting.
  • the cloud phone creation information includes the specification information of the first cloud phone and the specification information of the second cloud phone
  • the specification information of the first cloud phone includes the first live broadcast that needs to be set on the first cloud phone.
  • the specification information of the second cloud phone includes the information of the second live application that needs to be set on the second cloud phone and the information that needs to be set on the second cloud phone. Information about the second virtual camera.
  • the cloud phone management node when it creates at least two cloud phones based on the cloud phone creation information, it can first create the first cloud phone and the second cloud phone in the cloud phone resource pool according to the cloud phone creation information, where the first cloud phone is set with The first virtual camera and the first live broadcast application, the second cloud mobile phone is provided with a second virtual camera and a second live broadcast application, the first live broadcast application serves the first live broadcast platform, the second live broadcast application serves the second live broadcast platform, the first The live broadcast platform and the second live broadcast platform are different live broadcast platforms, and the streaming address is set to the first virtual camera and the second virtual camera.
  • the cloud phone management node creates the first cloud phone and the second cloud phone according to the cloud phone creation information, and then sets the streaming address to the first virtual camera of the first cloud phone and the second virtual camera of the second cloud phone.
  • Camera so that when the host starts live broadcast, the host terminal pushes the live content to the live content distribution service node’s push address, and the content distribution service node associates the live content with the pull address.
  • the first virtual camera and the second Second the virtual camera can pull the live content from the streaming address, so that each cloud mobile phone can obtain the live content shot by the host terminal, so that multiple cloud mobile phones can share the live content collected by the host terminal camera for live broadcasting. It solves the high cost of multi-platform live broadcast system, poor interactive effect, and prone to jams.
  • the cloud phone management node creates the first cloud phone and the second cloud phone in the cloud phone resource pool according to the cloud phone creation information, and can also set the first driver for the first cloud phone.
  • a driver is used to control the first virtual camera to send the live content pulled by the first virtual camera from the streaming address to the first live application when receiving the first camera invocation instruction generated by the first live application.
  • a second driver can also be set for the second cloud mobile phone, where the second driver is used to control the second virtual camera to send the second camera call instruction generated by the second live application to the second live application The live content pulled by the second virtual camera from the streaming address.
  • the above implementation is implemented so that when the live application on the cloud mobile phone sends a camera call instruction to the virtual camera, the virtual camera returns the live content pulled from the streaming address to the live application, and the live application has no sense of the source of the live content, and then It achieves the purpose of returning the live content collected by the anchor terminal to the live streaming application for live video without modifying the live broadcast application. Since the live broadcast application is generally provided by a third-party live broadcast platform, and the video live broadcast method of this application does not need to modify the live broadcast application, the live broadcast platform for third parties has universal applicability.
  • the cloud mobile phone management node can receive the live broadcast start command sent by the anchor terminal, and then start the first live broadcast application and the second live broadcast application according to the live broadcast start command, where the first live broadcast
  • the first camera calling instruction is generated after the application is started
  • the second camera calling instruction is generated after the second live application is started.
  • the cloud phone management node can start the live broadcast application in each cloud phone.
  • the live broadcast application sends a camera call instruction to the virtual camera of the cloud phone where it is located, and the virtual camera sends the live broadcast
  • the application returns the live content pulled from the streaming address, so that each live application can obtain the live content generated by the host terminal, thereby realizing the purpose of live broadcast of the live content generated by one host terminal on multiple live platforms.
  • a live broadcast system in a third aspect, includes a content distribution service node and at least two cloud mobile phones.
  • the at least two cloud mobile phones are connected to different live broadcast platforms. Pull the stream address.
  • the content distribution service node may be used to receive live content sent by the anchor terminal to the streaming address, and associate the live content with the streaming address. It should be understood that the live content here is generated by the anchor terminal.
  • At least two cloud phones are used to separately pull live content from the streaming address and send the live content to different live broadcast platforms.
  • the third aspect or any implementation manner of the third aspect is a system implementation corresponding to the first aspect or any implementation manner of the first aspect, and the description in the first aspect or any implementation manner of the first aspect is applicable to the third aspect Or any implementation of the third aspect, which will not be repeated here.
  • a cloud phone management node including: a receiving unit configured to receive cloud phone creation information sent by an anchor terminal, where the cloud phone creation information includes the specification information of the first cloud phone and the second cloud phone. The specification information of the mobile phone.
  • a creating unit configured to create the first cloud phone and the second cloud phone in the cloud phone resource pool according to the cloud phone creation information, wherein the first cloud phone is provided with a first live application and a first virtual camera , The second cloud mobile phone is provided with a second live broadcast application and a second virtual camera, and the first live broadcast application and the second live broadcast application serve different live broadcast platforms.
  • a sending unit the sending unit is configured to send a push stream address to the host terminal, where the push stream address is a destination address of the live content sent by the host terminal.
  • a setting unit the setting unit is configured to set a streaming address on the first virtual camera and the second virtual camera, and the streaming address is used to provide the live content for the first virtual camera and the second virtual camera to pull Pick.
  • the fourth aspect or any implementation manner of the fourth aspect is implemented by the device corresponding to the second aspect or any implementation manner of the second aspect, and the description in the second aspect or any implementation manner of the second aspect is applicable to the fourth aspect Or any implementation manner of the fourth aspect, which will not be repeated here.
  • a computer-readable storage medium including instructions, which when executed on a computing device, cause the computing device to perform the method described in the first aspect or the second aspect.
  • a computing device including a processor and a memory, and when the processor executes the code in the memory, the computing device realizes the method described in the first or second aspect.
  • a computer program product is provided.
  • the computer program product is read and executed by a computing device, the method described in the first aspect or the second aspect is implemented.
  • Figure 1 is a schematic diagram of the structure of a multi-platform live broadcast system
  • Figure 2 is a schematic diagram of the structure of the live broadcast system provided by the present application.
  • Figure 3 is a schematic structural diagram of the cloud mobile phone creation system provided by the present application.
  • FIG. 4 is a schematic flow chart of a live configuration method based on a cloud mobile phone provided by the present application
  • FIGS. 5-9 are schematic diagrams of some user interface embodiments in the live configuration method of cloud mobile phone provided by the present application.
  • FIG. 10 is a schematic flowchart of a live broadcast method based on a cloud mobile phone provided by the present application.
  • FIG. 11 is a schematic diagram of an embodiment of a user interface in the live broadcast method of a cloud mobile phone provided by the present application.
  • FIG. 12 is a schematic structural diagram of a cloud mobile phone management node provided by this application.
  • Fig. 13 is a schematic structural diagram of a computing device provided by the present application.
  • Cloud Phone A container with a mobile phone operating system and a virtual mobile phone function that runs on a physical server. Its essence is to transfer applications on the mobile phone to a physical server in a public cloud data center. Cloud phones are isolated from each other and do not interfere with each other. Cloud phones can install local phone applications. These applications run on cloud phones. The audio and video streams generated during the operation can be sent to the local phone for display and playback. The control commands generated according to the displayed and played audio and video streams can also be sent to the cloud mobile phone, and the cloud mobile phone controls the running state of the application according to the control command, so that the application of the local mobile phone can be transferred to the cloud mobile phone to run. Therefore, the local mobile phone does not need a lot of Installing applications that consume hardware resources can reduce the weight of applications. Moreover, because the reference runs on cloud phones, local phones do not need to be configured with higher hardware configurations, and users can operate applications with higher hardware configuration requirements.
  • Virtual Camera A program that uses software and other technologies to simulate a real camera in a cloud mobile phone to deceive application software so that it can use the camera normally.
  • Push The process by which the audio and video stream generating device transmits the packaged live content in the collection stage to the server.
  • Public cloud The core attribute of public cloud is shared resource service, which refers to the cloud infrastructure and services provided by third-party providers to users that can be used through public networks (such as the Internet). Users pay for cloud infrastructure and services. Access to the service.
  • Push Address The audio and video stream generating device needs to transmit the packaged live content during the acquisition phase to the designated address of the server during the push phase.
  • the designated address is the push address
  • the push address can include the public network IP Address, port number, and Uniform Resource Locator (URL), for example, the push address can be rtsp://10.0.10.1:554/live1, where 10.0.10.1 can be the content distribution service node 320
  • the public IP address of, 554 can be the port number
  • /live1 is the URL of the directory where the live content is stored in the file system of the server.
  • the server When the live content needs to be on the server in the pull phase, the server will place the live content to the server’s pull address and notify the audio and video stream playback device.
  • the audio and video stream playback device can download Pull the streaming address to pull live content, and the pull address can also include the public IP address, port number, and URL.
  • the streaming address can be rtsp://10.0.10.1:554/live2, where 10.0.10.1 can be the public IP address of the content distribution service node 320, 554 can be the port number, and /live2 is the live content
  • the URL of the directory stored in the server's file system.
  • a content delivery network refers to adding a new network architecture to the existing Internet to cache the content of the source site to the "edge" of the network closest to the user in advance, so that the user You can get the content you need nearby to improve the response speed of users visiting the website.
  • the content distribution service node of the present application has the function of an intermediate cache node or an edge cache node in the content distribution network, and can be used to cache and publish live content.
  • live broadcast platforms with a large number of user groups have emerged in the live broadcast industry.
  • the users of each live broadcast platform have a certain degree of stickiness to the platform. Therefore, the degree of overlap between the user groups of different platforms is not high, which leads to the In other words, compared to live broadcasting on a single platform, live broadcasting on multiple platforms at the same time can quickly gain more viewers, which will also bring more live broadcast revenue.
  • the live broadcast platform application will monopolize the mobile phone camera resources.
  • a host needs to purchase multiple mobile phones. Each mobile phone runs a different live broadcast application and focuses the camera on the host from different angles. , So as to achieve multi-platform live broadcast.
  • FIG. 1 is a schematic diagram of the architecture of a multi-platform live broadcast system.
  • the multi-platform live broadcast system 100 includes an anchor terminal, a live broadcast platform, and a playback device.
  • the anchor terminal, the live broadcast platform, and the playback device are connected to the network 150.
  • the network 150 may be a wired network or a wireless network, or a mixture of the two, which is not specifically limited in this application.
  • FIG. 1 uses two anchor terminals (respectively the anchor terminal 1 and the anchor terminal 2) and two live broadcast platforms (respectively the first live broadcast platform 131 and the second live broadcast platform 132) as an example for illustration.
  • the anchor can operate the anchor terminal 1 and the anchor terminal 2.
  • the anchor is the provider of live broadcast content. Specifically, it can be responsible for participating in a series of planning, editing, recording, production, and audience interaction in the Internet or activities, and is responsible for it. People who preside over the work, such as game anchors, cargo anchors, online class teachers, sports event organizers, news anchors, etc.
  • the host terminal may be a computing device that includes a camera and can install a live broadcast application, such as a smart phone, a handheld processing device, a tablet computer, a mobile notebook, a virtual reality device, an integrated handheld, and so on.
  • a live broadcast application such as a smart phone, a handheld processing device, a tablet computer, a mobile notebook, a virtual reality device, an integrated handheld, and so on.
  • the same type of live broadcast application serves the same live broadcast platform, and the terminal installed with the same type of live broadcast application can establish a network connection with the same live broadcast platform. Specifically, the terminal installed with the same type of live broadcast application can pull live broadcasts from the same live broadcast platform Content, or push the live broadcast content to the live broadcast platform.
  • the first live broadcast application 412 serves the first live broadcast platform 131
  • the second live broadcast application 422 serves the second live broadcast platform 132.
  • the first live broadcast platform 131 and the second live broadcast platform 132 are different from each other and can be different
  • the network service provider provides that the first live broadcast application 412 and the second live broadcast application 422 are different types of live broadcast applications serving different live broadcast platforms.
  • each host terminal When the host starts the live broadcast, multiple host terminals need to be set at different angles.
  • the camera of each host terminal is focused on the host, and each host terminal only runs one live broadcast application.
  • the host terminal 1 in Figure 1 includes camera 1 and the first live broadcast.
  • the application 412, the host terminal 2 includes a camera 2 and a second live broadcast application 422.
  • the live broadcast application of each host terminal can first obtain the live content (step 1).
  • the live content can include the audio and video streams collected by the host terminal’s camera and microphone, or the host The display interface of the terminal.
  • the live broadcast platform can pull the live content from the corresponding push address to perform live video (step 2).
  • the first live broadcast application 412 can push the live content collected by camera 1 to the ingest address 1 of the server of the first live broadcast platform 131
  • the second live broadcast application 422 can push the live content collected by camera 2 to
  • the second live broadcast platform 132 server ’s push stream address 2
  • the first live platform 131 server obtains the live content 1 collected by camera 1 from the push stream address 1, so as to realize the live broadcast of the anchor on the first live platform 131 and the second live platform 132
  • the server obtains the live content 2 collected by the camera 2 from the streaming address 2 to realize the live video broadcast of the anchor on the second live broadcast platform 132.
  • the live broadcast platform associates the above live content to the streaming address of the live broadcast platform, so that the playback device installed with the live broadcast application pulls the live content from the streaming address of the corresponding platform, so that the viewers who watch the live broadcast can use the playback device See the live broadcast content of the host (step 3).
  • the playback device 1 that installs the first live broadcast application 412 can pull the live content 1 from the streaming address 1 of the first live broadcast platform 131
  • the playback device 2 that installs the anchor application 2 can download the live broadcast content from the second live broadcast platform.
  • the live content 2 is pulled from the streaming address 2 of 132, so as to realize the live video broadcast of the anchor on the first live broadcast platform 131 and the second live broadcast platform 132.
  • the multi-platform live broadcast system shown in Figure 1 can realize the multi-platform live broadcast requirements of the anchor, it has many drawbacks.
  • the anchor needs to purchase multiple anchor terminals and install a live broadcast application on each anchor terminal.
  • the live broadcast application serves different live broadcast platforms.
  • each live broadcast application will call the local camera to collect audio and video. Therefore, if the hardware capability of the camera is poor, such as low pixels, the live broadcast effect of the platform will be very high.
  • each anchor terminal needs to be placed in a different angle, and each anchor The camera of the terminal is focused on the anchor, and it is difficult for the anchor to face each anchor terminal at the same time, resulting in poor interactive effects in multi-platform live broadcasting; moreover, multiple anchor terminals share the network for multi-channel audio and video collection, which is likely to cause network congestion and then live broadcast
  • the stuck condition reduces the user experience.
  • this application provides a live broadcast system 200, which only needs one anchor terminal to meet the anchor's multi-platform live broadcast requirements.
  • the live broadcast system 200 provided by the present application includes a cloud phone management node 310, a content distribution service node 320, and at least two cloud phones.
  • the at least two cloud phones are, for example, the cloud phone 410 and the cloud phone 420 in FIG. .
  • the anchor 110 only needs one anchor terminal 120 installed with the cloud mobile phone application 122 to implement multiple live broadcast platforms (FIG. 2 uses two live broadcast platforms, namely, the first live broadcast platform 131 and the first live broadcast platform 131). Take the second live broadcast platform 141 as an example.
  • this application does not limit the number of platforms and the number of cloud phones) for the purpose of simultaneous live broadcast.
  • the description of the host 110, the host terminal 120, the live broadcast platform 130, and the playback device 140 can refer to the embodiment of FIG. 1, and the details are not repeated here.
  • the following mainly describes the cloud mobile phone management node 310, the content distribution service node 320, and at least two cloud mobile phones in detail.
  • a cloud phone application 122 is installed on the anchor terminal 120.
  • the cloud phone application 122 obtains the cloud phone creation information input by the anchor 110 at the anchor terminal 120, and sends the cloud phone creation information to the cloud phone management node 310.
  • the cloud phone creation information includes the cloud phone. 410 specification information and cloud phone 420 specification information; on the other hand, the cloud phone application 122 can also be used to obtain live content, and then send it to the streaming address of the content distribution service node 320 for the content distribution service node 320 Pull live content from the push stream address.
  • the live content can include video stream and audio stream.
  • the camera of the live terminal collects the host’s video stream, the microphone of the live terminal collects the host’s audio stream, and the live terminal synthesizes the video stream and audio stream into live content. This solution is especially suitable for the host.
  • the scene of a live performance The scene of a live performance.
  • the live content may also include another audio and video stream, which combines the audio and video stream generated when the host terminal runs the application and the audio stream generated by the host narration collected by the microphone.
  • This program is especially suitable for online game live broadcast, online classroom, design software teaching and other scenarios.
  • the specification information of the cloud phone 410 includes the information of the first live application 412 of the cloud phone 410 that needs to be set on the cloud phone 410 and the information of the first virtual camera 411 that needs to be set on the cloud phone 410
  • the specification information of the cloud phone 420 includes information about the Set the information of the second live application 422 and the information of the second virtual camera 421 on the cloud phone 420.
  • the specification information includes at least: setting the first live application X and deploying the first virtual camera 411, and the specification information of the cloud phone 2 includes at least: setting the second live application Y and deploying the second virtual camera.
  • the specification information may also include cloud phone processor performance parameters, memory performance parameters, billing methods, etc. required by the user, and may also include account password information of the anchor in each live broadcast application, etc., which is not specifically limited in this application.
  • the cloud mobile phone application 123 is implemented through a browser; it can also be an application in the form of a client/server (Client/Server, C/S), that is, an application that runs independently on a terminal or computing device. It can be accessed through a client that has been downloaded and installed in advance, and this application does not limit the specific form of the cloud mobile phone application 123.
  • C/S client/server
  • the cloud phone management node 310 is mainly used to create at least two cloud phones in the cloud phone resource pool according to the cloud phone creation information sent by the anchor terminal 120, and respectively deploy corresponding live broadcast applications. Each cloud phone is connected to a different live broadcast platform. . Then create the content distribution service node 320 corresponding to the above-mentioned at least two cloud mobile phones, and allocate the push address and the pull address to the content distribution service node 320, and send the push address of the content distribution service node 320 to the anchor terminal 120, so that The live content collected by the anchor terminal 120 can be sent to the content distribution service node 320 through the streaming address, and then the streaming address of the content distribution service node 320 is set in the created at least two cloud mobile phones, so that at least Two cloud mobile phones can pull live content from the streaming address, and send the live content to the connected live broadcast platform for live video, so as to achieve the purpose of one anchor terminal to broadcast live on multiple live broadcast platforms.
  • the specification information of the cloud phone 410 includes the information of the first live application 412 that needs to be set on the cloud phone 410 and the information of the first virtual camera 411 that needs to be set on the cloud phone 410.
  • the specification information includes the information of the second live application 422 that needs to be set in the cloud mobile phone 420 and the information of the second virtual camera 421 that needs to be set in the cloud mobile phone 420. Therefore, the cloud phone management node 310 can create a cloud phone 410 and a cloud phone 420 according to the cloud phone management information.
  • the cloud phone 410 is provided with a first live application 412 and a first virtual camera 411
  • the cloud phone 420 is provided with a second live broadcast.
  • the cloud phone management node 310 may also set the streaming address of the content distribution service node in the first virtual camera 411 of the cloud phone 410 and the second virtual camera 421 of the cloud phone 420, so as to provide the first virtual camera 411 of the cloud phone 410.
  • the second virtual camera 421 of the cloud phone 420 can pull live content from the streaming address.
  • the cloud mobile phone management node 310 may be a server used to manage resources in a public cloud, and may be a general physical server, for example, a physical server, such as an ARM server or an X86 server, or a combination of general physical servers.
  • network functions virtualization network functions virtual ization, NFV
  • NFV network functions virtualization
  • VM virtual machine
  • a virtual machine means a complete hardware system functions, run a full computer system through software simulation in a completely isolated environment, This application is not specifically limited.
  • the content distribution service node 320 is mainly used to receive the anchor terminal 120 to send live content to the streaming address of the content distribution service node 320, and associate the live content to the streaming address of the content distribution service node 320 for the first time of the cloud mobile phone 410.
  • the virtual camera 411 and the second virtual camera 421 of the cloud phone 420 pull the live content generated by the anchor terminal 120 from the streaming address.
  • the content distribution service node 320 may be a virtual machine created by the cloud phone management node 310 in the virtual machine resource pool.
  • the virtual machine resource pool may include multiple virtual machines of different specifications, and the cloud phone management node 310 may select a suitable virtual machine as the content distribution service node of the cloud phone 410 and the cloud phone 420 according to the usage of the virtual machines in the resource pool. 320, and configure the streaming address and the streaming address for it.
  • the content distribution service node 320 may also be a physical server, and the embodiment of the present application does not limit its implementation manner.
  • the cloud phone 410 and the cloud phone 420 are respectively connected to different live broadcast platforms, and are used to pull live content from the streaming address of the content distribution service node 320 described above, and send the live content to different live broadcast platforms.
  • the cloud phone 410 is provided with a first live application 412 and a first virtual camera 411.
  • the first virtual camera 411 is used to pull live content from the streaming address and send the live content to the first live application 412.
  • the live broadcast application 412 is used to send live broadcast content to the first live broadcast platform 131 for live video broadcast on the first live broadcast platform 131.
  • the cloud phone 420 is provided with a second live application 422 and a second virtual camera 421, where the second virtual camera 421 is used to pull live content from the streaming address and send the live content to the second live application 422, the second live application 422 It is used to send live broadcast content to the second live broadcast platform 132 to perform live video on the second live broadcast platform 132.
  • cloud mobile phone 410 and a cloud mobile phone 420 is a combination of a container (Container) based on a common physical server technology virtual phone, virtual phone refers to a software emulation of a complete hardware system function, running in a completely isolated environment Complete mobile phone system.
  • container Container
  • virtual phone refers to a software emulation of a complete hardware system function, running in a completely isolated environment Complete mobile phone system.
  • the cloud phone management node 310 will also set a first driver for the cloud phone 410 and a second driver for the cloud phone 420, where the first driver is used to control the first virtual camera 411 to receive
  • the first driver is used to control the first virtual camera 411 to receive
  • the second driver is used to control the second virtual camera 421
  • the live broadcast content pulled by the second virtual camera 421 from the streaming address is sent to the second live broadcast application 422.
  • the cloud phone management node 310 receives the live broadcast start command sent by the anchor terminal 120, it can start the first live application 412 of the cloud phone 410 and the second live application 422 of the cloud phone 420 according to the live broadcast start command.
  • the application 412 is started, the first camera call command can be generated, and the second live application 422 can generate the second camera call command after starting.
  • the live broadcast application program can obtain the live broadcast content pulled by the cloud phone 410 and cloud phone 420 from the above-mentioned streaming address without any modification, so as to realize a live broadcast on a host terminal with 120 multiple platforms, making the live broadcast system provided by this application universal Sex is very high.
  • push and pull streams can be realized through a variety of communication protocols, such as Real Time Messaging Protocol (RTMP), Http Live Streaming (HLS), and instant messaging from the network (Real Time Messaging Protocol, RTMP).
  • RTMP Real Time Messaging Protocol
  • HHS Http Live Streaming
  • RTMP Real Time Messaging Protocol
  • WebRTC Web Real-Time Communication
  • the cloud phone management node 310 is used as a resource management server on the public cloud, and based on the cloud phone creation information sent by the anchor terminal 120, the cloud phone 410 and the cloud phone 420 are created in the cloud phone resource pool, and the corresponding deployment
  • the first live application 412 and the second live application 422 are described, and the specific process of creating the content distribution service node 320 in the virtual machine resource pool is described.
  • FIG. 3 is a schematic structural diagram of a cloud phone creation system 300.
  • the system 300 may include a cloud phone management node 310, a cloud phone resource pool 400, and a virtual machine resource pool 500, where the cloud phone resource pool 400 And the virtual machine resource pool 500 includes at least one physical server ( Figure 3 takes the virtual machine resource pool including the server 501 and the server 502, and the cloud mobile phone resource pool including the server 401 and the server 402 as an example), the physical server may be a general The physical server, for example, an ARM server or an X86 server, is not specifically limited in this application.
  • each server in the cloud mobile phone resource pool 400 includes a cloud mobile phone management agent node (such as cloud mobile phone management agent node 4013 and cloud mobile phone management agent node 4023), hardware resources (such as hardware resource 4012 and hardware resources 4022), operating system (OS) (such as operating system 4014 and operating system 4024), and at least one cloud phone (such as cloud phone 410, cloud phone 420, cloud phone 21, cloud phone 22, etc.) , Where each cloud phone shares hardware resources and operating systems with other cloud phones on the server in the form of a container (for example, cloud phone 410 shares hardware resources 4012 and 420 with cloud phones 420 on server 401 in the form of container 11).
  • Operating system 4014 the number of servers, the number of containers, and the types of hardware resources shown in FIG. 3 are only for illustration, and this application does not make specific limitations.
  • the cloud phone management node 310 is used to receive the cloud phone creation information sent by the anchor terminal 120, and is also used to receive the server information of the server 401 sent by the cloud phone management agent node 4013 on the server 401, and the cloud phone management agent node on the server 402 The server information of the server 402 sent by 4023 in real time.
  • the cloud phone management node 310 can combine the cloud phone creation information and the current server information of each server (server 401 and server 402), select a suitable server, and send a creation request to the cloud phone management agent node on the server.
  • the request contains After the specification information of the cloud phone 410 and/or the cloud phone 420 to be created, the corresponding cloud phone is created through the cloud phone management agent node.
  • the cloud phone management node 310 combines various server information and cloud phone creation information, and selects the server 401 to create the cloud phone 410 and the cloud phone 420, then the cloud phone management node 310 can send to the cloud phone management agent node 4013 of the server 401
  • the creation request contains the specification information of the cloud phone 410 and the cloud phone 420 to be created, so that the cloud phone management agent node 4013 can create the cloud phone 410 and the cloud phone 420 in the server 401 in response to the creation request.
  • the server information may include the use of hardware resources on the server, the occupancy of the container, etc., such as the server's hardware processing capacity, storage margin information, information about currently available input and output devices, etc., and may also include the current server The temperature information, failure rate, historical resource consumption information, etc., to prevent the server from affecting the operation of other services after the creation of the cloud phone in response to the creation information of the cloud phone. It should be understood that the above examples are only for illustration and cannot constitute a specific limitation.
  • the cloud mobile phone management agent node on each server can be used to monitor and collect server information of the server, and report the server information to the cloud mobile phone management node 310 in real time.
  • the cloud phone management agent node 4013 on the server 401 can monitor and collect the server information of the server 401
  • the cloud phone management agent node 4023 on the server 402 can monitor and collect the server information of the server 402
  • the cloud phone management agent node can also monitor and collect the server information of the server 402.
  • the creation request contains the specification information of the cloud phone 410 and/or the cloud phone 420 that needs to be created, and the cloud phone management agent node 412 can create the corresponding cloud according to the specification information
  • the cloud phone management node 310 determines that the server 401 creates the cloud phone 410, and the server 402 creates the cloud phone 420 according to the specification information of the cloud phone 410 in the cloud phone creation information and the server information sent by each cloud phone management agent node.
  • the cloud phone management agent node 4013 on the server 401 can receive the specification information of the cloud phone 410 sent by the cloud phone management node 310, and complete the creation of the cloud phone 410 according to the specification information, and the cloud phone management agent node 4023 on the server 402 can The specification information of the cloud phone 420 sent by the cloud phone management node 310 is received, and the creation of the cloud phone 420 is completed according to the specification information. It should be understood that the above examples are only for illustration and cannot constitute a specific limitation.
  • the cloud phone management agent node can create a container on the server according to the received cloud phone specification information, and set the hardware and software required by the cloud phone specification information for the container.
  • the operating system of the container is The operating system required by cloud phones. For example, after the cloud phone management agent node 4013 receives the creation information of the cloud phone 410 sent by the cloud phone management node 310, the cloud phone management agent node 4013 can create a container on the server 401 according to the specification information of the cloud phone 410.
  • the container contains the first live broadcast application 412 that the cloud phone 410 needs to deploy, as well as the operating system core libraries and system libraries required by the first live broadcast application 412, such as functional function libraries, three-dimensional graphics processing libraries (such as Open GLES), and media Media Libraries, Input Manager, etc.
  • the cloud phone 410 can share hardware resources and operating systems with other cloud phones on the server 401 (such as the cloud phone 420 and the cloud phone 3 in FIG. 3), so as to realize the creation of the cloud phone 410.
  • the cloud phone 420 can be completed. The creation of, I won’t go into details here.
  • Hardware resources may include various available hardware resources of the server, such as processors, memory, network cards, etc., and may also include other hardware resources that may be required by cloud mobile phones, which are not specifically limited in this application.
  • the operating system (such as operating system 4014 and operating system 4024) may be an operating system applicable to various mobile phones, such as an Android operating system, which is not specifically limited in this application. It should be noted that the operating system can be an official complete operating system, or an operating system that has been modified for individual driver modules of the official complete operating system in order to adapt to the operating mode of the server. This application does not specifically limit it.
  • Cloud phones share hardware resources and operating systems with other cloud phones on the server in the form of containers.
  • Each container can include the applications required by the cloud phone and the dependent resources required by each application, as well as the dependent resources required by the application. It can be the core library and system library in the foregoing content.
  • the container in which each cloud mobile phone is located uses hardware resources and operating systems, but does not monopolize the hardware resources, but shares hardware resources and operating systems with the containers in which other cloud mobile phones are located. In other words, each container does not have its own kernel, and the application process in the container runs directly on the kernel of the server.
  • the cloud phone management agent node creates the cloud phone according to the received specification information of the cloud phone that needs to be created, It is only necessary to package the applications required by the cloud phone and the dependent resources of the application.
  • the created cloud phones can run independently on the host hardware without virtualization, creating an independent sandbox for the application. Operating environment.
  • the cloud mobile phone management node and the cloud mobile phone management agent node deployed on each server can be implemented based on container management systems such as Kubernetes and Docker, which are not specifically limited in this application.
  • the cloud phone management node 310 creates the cloud phone 410 and the cloud phone 420 according to the cloud phone creation information.
  • the cloud phone Create a system combine the server information fed back by the cloud phone management agent node on each server, select a suitable server in the cloud phone resource pool, and send the cloud phone 410 creation information to the cloud phone management agent node of the server for cloud phone 410
  • the cloud phone management agent node can create a container 11 according to the first live application to be deployed in the creation information of the cloud phone 410, and the container 11 contains the first live application to be deployed by the cloud phone 410 and the first live application
  • the creation of the cloud phone 420 can be completed, and the created cloud phone 420 will share the hardware resources 4012 and the operating system 4014 with the cloud phone 410 on the server 401 in the
  • Each server in the virtual machine resource pool 500 (such as server 501 and service 502) includes hardware resources (such as hardware resources 5012 and hardware resources 5022), operating systems (such as operating systems 5013 and 5023), and at least one virtual machine ( For example, virtual machine 11 to virtual machine 1x, and virtual machine 21 to virtual machine 2y, where x and y are natural numbers).
  • hardware resources such as hardware resources 5012 and hardware resources 5022
  • operating systems such as operating systems 5013 and 5023
  • at least one virtual machine For example, virtual machine 11 to virtual machine 1x, and virtual machine 21 to virtual machine 2y, where x and y are natural numbers.
  • VM is a general physical servers binding NFV virtual machine technology
  • the virtual machine refers to a computer system running a complete completely isolated environment with complete hardware system functions by software simulation.
  • the operating system also includes a virtual machine manager.
  • the operating system 5013 of the server 501 may include a virtual machine manager 5014
  • the operating system 5023 of the server 502 may include a virtual machine manager 5024.
  • the virtual machine manager is used to receive a virtual machine creation request sent by the cloud mobile phone management node 310, and the request contains the specification information of the virtual machine that needs to be created.
  • the virtual machine manager 5024 may create a virtual machine in the server in response to the aforementioned virtual machine creation request.
  • the virtual machine manager 5014 of the server 501 can receive the creation request for creating the content distribution service node 320 sent by the cloud phone management node 310, and in response to the above creation request, create the virtual machine 11 as the content distribution service node 320, and Configure the streaming address and ingesting address for it. It should be understood that the above examples are only for illustration and cannot constitute a specific limitation.
  • the above-mentioned virtual machine manager may be implemented by a virtual machine monitor (VMM), a hypervisor, or may be implemented by other software capable of realizing platform virtualization, which is not specifically limited in this application.
  • VMM virtual machine monitor
  • hypervisor hypervisor
  • the live broadcast system 200 shown in FIG. 2 can send the received live broadcast content generated by the host terminal 120 to multiple cloud mobile phones by the content distribution service node 320 after the host 110 starts the live broadcast, and each cloud mobile phone is installed There is a live broadcast application, so that the live broadcast application on each cloud mobile phone can send the live content obtained from the virtual camera to the corresponding live broadcast platform for video live broadcast.
  • the host only needs to use a host terminal 120 with the cloud mobile application installed. , You can achieve the purpose of live broadcast on multiple platforms at the same time, thereby solving the problem of high cost, poor interactive effect and prone to jams in the multi-platform live broadcast system.
  • This application provides a live broadcast method and configuration method based on cloud mobile phones, which are applied to the live broadcast system 200 shown in FIG. 2.
  • the live broadcast system 200 includes a content distribution service node 320, a cloud mobile phone 410, and a cloud mobile phone 420.
  • the cloud mobile phone 410 is set There are a first live broadcast application and a first virtual camera.
  • the cloud phone 420 is provided with a second live broadcast application and a second virtual camera.
  • the first live broadcast application and the second live broadcast application serve different live broadcast platforms.
  • This method enables the anchor 110 to start to realize the live video of multiple platforms through one anchor terminal after setting the cloud mobile phone application on the anchor terminal, which solves the problem of high cost, poor interaction effect and prone to stuck in the multi-platform live broadcast system. The situation.
  • the cloud-based mobile phone-based live broadcast configuration method includes the following steps:
  • the cloud phone management node 310 receives the cloud phone creation information sent by the anchor terminal 120, where the cloud phone creation information includes specification information of at least two cloud phones.
  • the at least two cloud phones may be the cloud phone 410 and the cloud phone 420 in the foregoing content
  • the cloud phone creation information may include the specification information of the cloud phone 410 and the specification information of the cloud phone 420.
  • the specification information of the cloud phone 410 includes the information of the first live application that needs to be set on the cloud phone 410 and the information of the first virtual camera.
  • the specification information of the cloud phone 420 includes the information and the information of the second live application that needs to be set on the cloud phone 420. 2.
  • Information about the virtual camera For the specific description of the specification information, reference may be made to the embodiment in FIG. 2, and details are not described herein again.
  • the cloud phone management node 310 creates at least two cloud phones according to the cloud phone creation information, and the aforementioned at least two cloud phones are connected to different live broadcast platforms.
  • the cloud phone management node 310 creates a cloud phone 410 and a cloud phone 420 in the cloud phone resource pool according to the cloud phone creation information, where the cloud phone 410 is provided with the first live application and the first virtual camera, and the cloud phone 420 is provided with a second live broadcast application and a second virtual camera, and the first live broadcast application and the second live broadcast application serve different live broadcast platforms.
  • the specific process of creating a cloud mobile phone can refer to the embodiment in FIG. 3, which will not be repeated here.
  • the cloud mobile phone management node 310 sends the streaming address to the host terminal 120, and the streaming address is the destination address of the live content generated by the host terminal 120.
  • the push stream address is the push stream address of the content distribution service node 320
  • the cloud phone management node 310 sends the push stream address to the anchor terminal 120, so that after the anchor starts the live broadcast, the anchor terminal 120 can push the generated live content To the push address of the content distribution service node 320, so that the content distribution service node 320 can pull live content from the push address, and associate the live content with its own pull address for the at least two cloud mobile phones mentioned above Pull the live content from the streaming address, so that each cloud mobile phone can send the live content to the live broadcast platform connected to it, thereby realizing the live video broadcast of one anchor terminal on multiple live streaming platforms, thereby solving the cost of the multi-platform live broadcast system High, poor interactive effect and prone to stuttering.
  • the cloud phone management node 310 sets the streaming address to at least two cloud phones, and the streaming address is used to provide live content for the at least two cloud phones to pull.
  • the streaming address is the streaming address of the content distribution service node 320.
  • the cloud mobile phone management node 310 directly configures the streaming address to the first virtual camera of the cloud mobile phone 410 and the second virtual camera of the cloud mobile phone 420, so that after the host starts the live broadcast, the first virtual camera and the second virtual camera
  • the live content can be pulled from the streaming address, and each cloud mobile phone can obtain the live content generated by the anchor terminal, so that multiple cloud mobile phones share the live content generated by the anchor terminal 120 for live broadcasting, thereby solving the problem of multi-platform live broadcasting.
  • the system cost is high, the interaction effect is poor, and it is prone to jams.
  • the above method further includes the following steps: the cloud mobile phone management node 310 receives the live broadcast start command sent by the anchor terminal 120, and starts the first live application in the first cloud mobile phone and the second cloud mobile phone according to the live broadcast start command.
  • the second live broadcast application wherein the first camera call instruction is generated when the first live broadcast application is started, and the second camera call instruction is generated when the second live broadcast application is started.
  • the cloud phone management node can start the live broadcast application in each cloud phone, so that the live broadcast application sends a camera call instruction to the virtual camera of the cloud phone where it is located, and the virtual camera returns from the streaming address.
  • the obtained live broadcast content enables each live broadcast application to obtain the live broadcast content generated by the anchor terminal, thereby realizing the purpose of one anchor terminal performing live broadcast on multiple live broadcast platforms.
  • step S430 specifically, after the cloud phone management node 310 creates the cloud phone 410 and the cloud phone 420 in the cloud phone resource pool according to the cloud phone creation information, before receiving the above live broadcast start command, the above method further includes the following steps: cloud The mobile phone management node 310 sets a first driver for the cloud mobile phone 410, and the first driver is used to control the first virtual camera to send the first virtual camera slave to the first live broadcast application when it receives the first camera call instruction generated by the first live broadcast application.
  • the live broadcast application sends the live broadcast content pulled by the second virtual camera from the streaming address.
  • step S420 in the process of creating the cloud phone by the cloud phone management node 310, the first driver can be set for the cloud phone 410, and the second driver can be set for the cloud phone 420, so that the first live application on the cloud phone 410 can be transferred to the first virtual phone.
  • the first virtual camera returns the live content pulled from the streaming address, so as to achieve the purpose of "Hook" (Application Programming Interface, API), and then achieve the goal of not modifying
  • Hook Application Programming Interface, API
  • the first driver and the second driver can be written in accordance with the operating system interface standards of the cloud phone 410 and the cloud phone 420, and the input and output format only needs to meet the operating system interface standard, for example, the Android operating system interface standard.
  • the live broadcast content generated by the anchor terminal 120 can be returned to the live broadcast application for video live broadcast without modifying the live broadcast application, making the cloud mobile phone-based live broadcast method of the present application more universal.
  • the virtual camera on the cloud mobile phone receives the call instruction sent by the live streaming platform, and before returning the live content pulled by the streaming address to the live streaming platform, it can first pull the previous from the streaming address Format conversion of the live broadcast content, convert it into a format that the live broadcast application can recognize, such as the original format audio and video data collected by the host’s terminal camera, and then return it to the live broadcast platform, so as to achieve without modifying the live broadcast application.
  • the purpose of returning the live broadcast content generated by the anchor terminal 120 to the live broadcast application for live video broadcast makes the cloud mobile phone-based live broadcast method of the present application more universal.
  • step S440 that is, before the cloud mobile phone management node 310 sets the streaming address to the first virtual camera and the second virtual camera, the above method further includes the following steps: the cloud mobile phone management node 310 creates information in the virtual machine according to the cloud mobile phone creation information input by a user.
  • a content distribution service node 320 is created in the resource pool, and the content distribution service node 320 is configured with a streaming address and a streaming address.
  • the cloud phone management node 310 is a resource management server in the public cloud. It can create a cloud phone in the cloud phone resource pool, or create a content distribution service node in the virtual machine resource pool, so that one user account and one content can be created.
  • both the cloud mobile phone and the content distribution service node are virtual resources, and the cost is relatively low.
  • step S440 that is, after the cloud phone management node 310 has created the content distribution service node 320, the cloud phone 410, and the cloud phone 420, it may generate binding information, which includes the created binding information.
  • the streaming address and streaming address of the content distribution service node 320, the address information of the cloud phone 410, the address information of the cloud phone 420, the address information of the anchor terminal 120, etc., the cloud phone management node 310 also sends the above-mentioned binding information to the created
  • the content distribution service node 320 receives the live content sent by the anchor terminal 120 in step S310, it can determine whether the live content pulled from the push stream address comes from the binding information according to the binding information
  • the host terminal 120 avoids the possibility of streaming live content by other host users’ cloud phones, and improves the security of data transmission.
  • the content distribution service node 310 may also send the control flow to each cloud phone according to the cloud phone address in the binding information, and may also transcode the live content according to the code rate requirement of each cloud phone in the binding information. This makes the cloud-based mobile phone-based video live broadcast method provided in this application applicable to various live broadcast platforms, and has better universal applicability.
  • the anchor uses the cloud mobile phone application on the anchor terminal 120 (take the cloud mobile phone application named "cloud live” as an example) to create a cloud mobile phone 410 and a cloud Mobile phone 420, and install the first live application 412 on the cloud mobile phone 410, and install the second live application 422 on the cloud mobile phone 420 as an example.
  • the user operates the anchor terminal 120 to create the cloud mobile phone.
  • some exemplary graphical user interfaces are illustrated in FIG.
  • FIG. 5 exemplarily shows an exemplary user interface 10 on the anchor terminal 120 for displaying applications installed by the anchor terminal 120.
  • the user interface 10 may include: a status bar 201, a calendar indicator 202, a weather indicator 203, a tray 204 with commonly used application icons, a navigation bar 205, and other application icons. in:
  • the status bar 201 may include: one or more signal strength indicators 201A for mobile communication signals (also called cellular signals), and one or more signal strength indicators 201C for wireless fidelity (Wi-Fi) signals , Battery status indicator 201D, time indicator 201E.
  • signal strength indicators 201A for mobile communication signals (also called cellular signals)
  • signal strength indicators 201C for wireless fidelity (Wi-Fi) signals
  • Battery status indicator 201D for wireless fidelity (Wi-Fi) signals
  • time indicator 201E time indicator
  • the calendar indicator 202 can be used to indicate the current time, such as date, day of the week, hour and minute information, and so on.
  • the weather indicator 203 can be used to indicate the type of weather, such as cloudy to clear, light rain, etc., and can also be used to indicate information such as temperature.
  • the tray 204 with icons of commonly used application programs can display: a phone icon 204A, a contact icon 204B, a short message icon 204C, and a camera icon 204D.
  • the navigation bar 205 may include system navigation keys such as a return key 205A, a home screen key 205B, and a multi-task key 205C.
  • system navigation keys such as a return key 205A, a home screen key 205B, and a multi-task key 205C.
  • the anchor terminal 120 may display the previous page of the current page.
  • the anchor terminal 120 may display the home interface.
  • the anchor terminal 120 may display the task recently opened by the user.
  • the naming of each navigation key can also be other, which is not limited in this application. Not limited to virtual keys, each navigation key in the navigation bar 205 can also be implemented as a physical key.
  • Other application icons may include, for example, an icon 206 for mutual transfer, an icon 207 for a gallery, an icon 208 for music, an icon 209 for applications, an icon 210 for mailboxes, an icon 211 for cloud live broadcast, an icon 212 for a memo, and an icon 213 for settings.
  • the user interface 10 may also include a page indicator 214.
  • the icons of other applications may be distributed on multiple pages, and the page indicator 216 may be used to indicate the application in which page the user is currently browsing. The user can swipe the area of other application icons left and right to browse application icons in other pages.
  • the user interface 10 exemplarily shown in FIG. 5 may be a home screen. It can be understood that FIG. 5 only exemplarily shows the user interface on the anchor terminal 120, and should not constitute a limitation to the embodiment of the present application.
  • the user can click the icon 211 of the cloud live broadcast on the user interface 10.
  • the anchor terminal 120 detects the aforementioned user operation, and in response to the aforementioned user operation, the anchor terminal 120 displays the user main interface 11 of the cloud live broadcast.
  • the user interface 11 may include: an application title bar 301, a control 302, a search box 303, a tray 304 of commonly used controls, and multiple live display boxes, among which:
  • the application title bar 301 can be used to indicate that the current page is used to display the cloud live broadcast interface of the anchor terminal 120.
  • the presentation form of the application title bar 301 may be text information, icons or other forms.
  • the control 302 may receive a user operation (for example, a touch operation), and in response to the detected user operation, the anchor terminal 120 may display a page for logging in or switching a cloud live broadcast account.
  • a user operation for example, a touch operation
  • the search box 303 can be used to search for a setting item matching the character according to the character input by the user.
  • the tray 304 of commonly used controls can display: home control icon 304A, recommended control icon 304B, start live control icon 304C, chat control icon 304D, and my control icon 304E.
  • the aforementioned control icons can all accept user operations (such as touch operations).
  • the anchor terminal 120 can display a response page.
  • the home control icon 304A can be used to display the home page of the cloud live broadcast. It is recommended
  • the control icon 304B can be used to display the page recommended for the user
  • the live broadcast control icon 304C can be used to display the user's live broadcast page
  • the chat control icon 304D can be used to display the user's chat page
  • the my control icon 304E can be used to display the account center page.
  • a plurality of live broadcast display frames may be, for example, a live broadcast display frame 305 and a live broadcast display frame 306.
  • the live broadcast display frame is used to display the live video screen of the live broadcast room or the cover of the live broadcast room.
  • FIG. 6 only exemplarily shows the interface of the cloud live broadcast application on the anchor terminal 120, and should not constitute a limitation to the embodiment of the present application.
  • the user can click on the my control icon 304E in the tray 304 of commonly used controls.
  • the anchor terminal 120 detects the user operation, and in response to the user operation, the anchor terminal 120 may display the icon shown in FIG.
  • the user interface 12 may include: a return control 801, a member center 802, an account 803, an avatar 804, an exit control 811, and multiple items. in,
  • the return control 801 can receive a user operation (such as a touch operation).
  • a user operation such as a touch operation
  • the anchor terminal 120 can exit the user interface 12 of the account center and display the previous user interface of the user interface 12, such as the user interface 11.
  • the member center 802 may receive a user operation (for example, a touch operation), and in response to the detected user operation, the anchor terminal 120 may display a user interface of the member center.
  • a user operation for example, a touch operation
  • the logout control 811 can receive a user operation (for example, a touch operation), and in response to the detected user operation, the anchor terminal 120 can log out of the current cloud live broadcast account.
  • a user operation for example, a touch operation
  • Multiple items may be, for example, a cloud phone creation item 805, an account and security item 806, a my wallet item 807, a my favorite item 808, a message center item 809, and a setting item 810.
  • the above multiple items can receive user operations (such as touch operations).
  • the anchor terminal 120 can display a response page.
  • the cloud phone creation item 805 can display the user interface 13.
  • FIG. 7 only exemplarily shows the user interface of the account center on the anchor terminal 120, and should not constitute a limitation to the embodiment of the present application.
  • the user can click the cloud phone creation item to start creating the cloud phone.
  • the anchor terminal 120 detects the user operation, and in response to the user operation, the anchor terminal 120 may display the cloud phone as shown in FIG. User interface created by mobile phone 13.
  • the user interface 13 may include: multiple cloud phone specification configuration sub-interfaces and a new control 905, among which,
  • the new control 905 is used to receive user operations (such as touch operations).
  • the anchor terminal 120 can add a cloud phone specification configuration sub-interface on the user interface 13, such as the cloud phone 3 specification configuration sub-interface .
  • cloud phone specification configuration sub-interfaces may be, for example, cloud phone 410 specification configuration sub-interface 901 and cloud phone 420 specification configuration sub-interface 903.
  • the above-mentioned cloud phone specification configuration sub-interface includes multiple input boxes and multiple creation controls.
  • the input box is used to receive the specification parameters input by the user, such as processor specifications, memory specifications, operating systems, resolutions, deployment applications and whether The configuration of the camera, etc., may also include other specifications, which are not specifically limited in this application.
  • the creation control is used to receive a user's operation (for example, a touch operation), and in response to the detected user operation, the anchor terminal 120 may create a cloud phone of the specifications set in the cloud phone specification configuration sub-interface.
  • the user can click the input box corresponding to the processor specification in the cloud phone 410 specification configuration sub-interface 901, and enter the processor specification of the cloud phone 410 to be created, such as the 2-core processor shown in FIG. 8, and the user can click In the input box corresponding to the operating system, enter the operating system type of the cloud phone 410 to be created, such as the Android operating system in Figure 8.
  • the user can click the input box corresponding to the deployed application and enter the application to be deployed on the cloud phone 410 to be created It is the first live broadcast application 412.
  • input boxes corresponding to other specifications can be input, and details are not described here.
  • the user can click the click to create control on the sub-interface of each cloud phone specification configuration to create the cloud phone.
  • the user enters the input boxes in the cloud phone 410 specification configuration sub-interface 901 according to the creation requirements, and inputs the input boxes in the cloud phone 420 specification configuration sub-interface 902, and clicks create control 902 and create control
  • the cloud mobile phone application ie, cloud live broadcast
  • the cloud mobile phone application will generate the user's cloud mobile phone creation information in the foregoing content
  • the cloud mobile phone creation information will be sent by the anchor terminal 120 to the cloud mobile phone management node 310 (ie, the cloud mobile phone management node 310 in the embodiment of FIG. 4).
  • Step S410) the cloud phone management node 310 can create the cloud phone 410 and the cloud phone 420 in the cloud phone resource pool according to the cloud phone creation information (that is, step S420 in the embodiment of FIG. 4), wherein the cloud phone 410 is set with the first A live application and a first virtual camera, and the cloud phone 420 is provided with a second live application and a second virtual camera. Then, the cloud mobile phone management node 310 may send the streaming address to the host terminal 120, which is the destination address of the live content sent by the host terminal 120 (ie, step S430 in the embodiment of FIG. 4).
  • the cloud mobile phone management node 310 sets the streaming address to the first virtual camera and the second virtual camera, and the streaming address is used to provide live content for the first virtual camera and the second virtual camera to pull (ie, the implementation in FIG. 4 Example of step S440).
  • the cloud phone management node 310 creates the cloud phone 410 and the cloud phone 420 in the cloud phone resource pool according to the cloud phone creation information, and also sets the cloud phone 410 with the first driver and the cloud phone 420 with the second driver.
  • the virtual camera of each cloud phone can pull the live content from the above-mentioned streaming address and send the live content to the live application, so that the live application can send the live content to the corresponding live broadcast platform , So as to realize the live broadcast of one host terminal 120 on multiple live broadcast platforms.
  • FIG. 8 only exemplarily shows the user interface 13 created by the cloud phone on the anchor terminal 120, and should not constitute a limitation to the embodiment of the present application.
  • the anchor terminal 120 detects the user operation, and in response to the user operation, sends the user's cloud phone creation information to the cloud phone management node 310, and the cloud phone management node After 310 executes the live configuration method of the cloud mobile phone described in the embodiment of FIG. 5, the anchor terminal 120 may display the user interface 14 of the cloud mobile phone successfully created as shown in FIG. 9. It should be understood that if the cloud mobile phone service is a paid service, after the user clicks on the create control, the anchor terminal 120 may also first display a payment page for the user to make a payment. If the payment is successful, the user interface 14 is displayed, which is not specifically limited in this application.
  • the user interface 14 may include: a successful creation icon 1001 and multiple cloud phone display sub-interfaces. in,
  • the successful creation icon 1001 is used to remind the user that the cloud mobile phone is successfully created.
  • the multiple cloud phone display sub-interfaces are used to display part of the information of the cloud phone currently created by the user.
  • the multiple cloud phone display sub-interfaces may be, for example, the display sub-interface 1002 of the cloud phone 410 and the display sub-interface 1003 of the cloud phone 420.
  • Each cloud phone display sub-interface can include configuration controls, shutdown controls, connection controls, and restart controls. Among them,
  • the configuration controls (for example, the configuration control 1002A and the configuration control 1003A) are used to re-configure the specifications of the cloud mobile phone.
  • the shutdown controls (for example, shutdown control 1002B and shutdown control 1003B) are used to turn off the cloud mobile phone.
  • connection controls for example, the connection control 1002C and the connection control 1003C
  • the connection controls are used to enter the user interface of the cloud mobile phone, such as the user interface of the first live broadcast application 412 for settings, such as logging in to the account of the first live broadcast application 412, etc., this application will not go into details .
  • the restart control (for example, the connection control 1002D and the connection control 1003D) are used to restart the cloud mobile phone.
  • FIGS. 8-9 only exemplarily show the cloud phone creation user interface 13 on the anchor terminal 120 and the cloud phone creation user interface 14 and should not constitute a limitation to the embodiment of the present application.
  • the host can input live broadcast requirements (such as how many cloud phones to create, what live broadcast applications to deploy, etc.) into the cloud mobile phone application of the host terminal 120.
  • live broadcast requirements such as how many cloud phones to create, what live broadcast applications to deploy, etc.
  • the host terminal 120 After the user needs are packaged into cloud phone creation information, the cloud phone creation information can be sent to the cloud phone management node 130, so that the cloud phone management node 310 creates multiple cloud phones according to the live broadcast requirements before the live broadcast of the host, and in each cloud phone
  • the corresponding live broadcast platform is deployed on the Internet, and the streaming address of the content distribution service node 320 is set for each cloud mobile phone.
  • the content distribution service node 320 associates the received live content generated by the anchor terminal 120 with its own Pull streaming address for each cloud mobile phone to pull live content from the streaming address, and send the obtained live content to the corresponding live broadcast platform for video live broadcast, so that the host only needs to use one host with cloud mobile application installed
  • the terminal 120 can realize simultaneous live broadcast on multiple platforms, thereby solving the problems of high cost, poor interaction effect, and prone to jams in a multi-platform live broadcast system.
  • the cloud-based mobile phone-based live broadcast method includes the following steps:
  • the content distribution service node 320 receives the live content sent by the anchor terminal 120 to the streaming address, and associates the live content with the streaming address, where the live content is generated by the anchor terminal 120.
  • the live content includes video stream and audio stream.
  • the camera of the live terminal collects the video stream about the anchor, the microphone of the live terminal collects the audio stream about the anchor, and the live terminal combines the video stream and audio stream into the live content. This solution is especially suitable for the anchor The scene of a live performance.
  • the live content may also include another audio and video stream, which combines the audio and video stream generated when the host terminal runs the application and the audio stream generated by the host narration collected by the microphone.
  • This program is especially suitable for online game live broadcast, online classroom, design software teaching and other scenarios.
  • the streaming address and the streaming address are the addresses of the content distribution service node 320
  • the streaming address is used for the cloud phone 410 and the cloud phone 420 to pull live content from the streaming address
  • the streaming address is used for the anchor
  • the terminal 120 sends live content to the content distribution service node 320.
  • the ingest address and the ingest address can include the public IP address, port number, and URL.
  • the ingest address can be rtsp://10.0.10.1:554/live1, where 10.0.10.1 can be Is the public IP address of the content distribution service node 320, 554 can be the port number, /live1 is the URL of the directory where the live content is stored in the server file system; the streaming address can be rtsp://10.0.10.1:554/live2, Among them, 10.0.10.1 may be the public IP address of the content distribution service node 320, 554 may be the port number, and /live2 is the URL of the directory where the live content is stored in the server file system.
  • the streaming address and the streaming address may also be other forms of network addresses that can be used for addressing in the network, and this application does not specifically limit them.
  • the content distribution service node 320 associates the live content with the streaming address of the content distribution service node 320 through multiple communication protocols, such as RTMP, HLS, WebRTC protocol, etc. in the foregoing content, and may also include others.
  • RTMP Real-Time Transport
  • HLS High Speed Downlink Transport Layer
  • WebRTC protocol WebRTC protocol
  • the protocol for audio, video and data communication between the streaming media and the server can be implemented, and this application does not specifically limit it.
  • the first virtual camera of the cloud phone 410 pulls the live content from the streaming address.
  • the streaming address is the first virtual camera set on the cloud phone 410 by the cloud phone management node 310 during the cloud phone creation stage.
  • the process of the cloud phone creation stage can be implemented with reference to step S410-step S430 and FIGS. 4-9. Detailed description of the case.
  • the process of the first virtual camera to pull live content from the streaming address can be implemented through multiple communication protocols, such as the RTMP protocol, HLS protocol, WebRTC protocol, etc. in the foregoing content, and other protocols that can implement streaming media and
  • the protocol for audio, video and data communication between servers is not specifically limited in this application.
  • the first live broadcast application of the cloud phone 410 obtains live broadcast content from the first virtual camera, and sends the live broadcast content to the first live broadcast platform.
  • the first live broadcast application can send a first camera call request to the first virtual camera, and then the first virtual camera returns the live content pulled from the streaming address to the first live broadcast application, so that the live broadcast on each cloud phone All applications can pull the live broadcast content of the host, thereby achieving the purpose of the host to perform multi-platform live broadcasting through one host terminal 120.
  • the method for the first live broadcast application to send the live content to the first live broadcast platform may be: push the live content to the push address of the first live broadcast platform, so that the first live broadcast platform can obtain the live content from the push address
  • step S340 The second virtual camera pulls the live content from the streaming address. For details, please refer to the above step S320, which will not be repeated here.
  • the second live broadcast application obtains live broadcast content from the second virtual camera, and sends the live broadcast content to the second live broadcast platform. For details, please refer to the above step S330, which will not be repeated here.
  • step S320-step S330 and step S340-step S350 may be performed at the same time, or may not be performed at the same time, and this application is not specifically limited.
  • the above method further includes the following steps: the content distribution service node receives the control flow sent by the anchor terminal to the push streaming address, and sends the control flow to the first cloud mobile phone and the second cloud mobile phone, respectively, wherein,
  • the control flow can be a command flow, which is used to control the switching of the front and rear cameras of the host terminal, and the focus, contrast, and brightness of the cameras.
  • the live broadcast application is provided by a third-party live broadcast platform. If the live broadcast application fails to receive the control flow sent by the camera while it is running, it may be considered that the camera is malfunctioning, and the live broadcast application may report an error to the operating system or fail to operate normally. , But because the camera provided by the cloud mobile phone is a virtual camera, the virtual camera cannot provide control flow to the live application, which makes the live application report an error or cannot run normally.
  • the host terminal can send the control flow of the local camera
  • the content distribution service node sends the control flow to the virtual camera of each cloud mobile phone
  • the virtual camera can return the control flow of the host terminal to the live application, so that the virtual camera of the cloud mobile phone can send the target camera to the live application Control flow to ensure the normal operation of the live broadcast application.
  • the live broadcast application is generally provided by a third-party live broadcast platform, and the video live broadcast method of this application does not need to modify the live broadcast application, the live broadcast platform for third parties has universal applicability.
  • the cloud mobile phone application on the anchor terminal 120 can encode the video data collected by the camera and the audio data collected by the microphone and encapsulate the live content, and send the live content to the streaming address for the cloud mobile 410 and the cloud mobile 420 to pull. Then, the control instruction is encoded and encapsulated into a control flow. According to the network addresses of the cloud phone 410 and cloud phone 420, the control flow is directly sent to the cloud phone 410 and cloud phone 420, thereby avoiding the need for individual live broadcast platform applications to obtain The video live broadcast can only be carried out under the condition of camera control authority, so that the cloud mobile phone-based live broadcast method provided in this application has better universality and is suitable for more live broadcast platforms.
  • the sending sequence of the live broadcast content and the control stream may be performed simultaneously or sequentially, which is not specifically limited in this application.
  • the network addresses of the cloud phone 410 and the cloud phone 420 may be the binding information stored in the content distribution service node 320 when the content distribution service node 320 is created after the cloud phone management node 310 creates the cloud phone 410 and the cloud phone 420 In the description of the binding information, reference may be made to the content in the foregoing embodiment in FIG. 4, and details are not repeated here.
  • the content distribution service node 320 can also perform secondary transcoding of the live content according to the bit rate requirements of each cloud mobile phone, such as cloud
  • the first live broadcast application on the mobile phone 410 requires live content at bit rate A
  • the second live broadcast application of cloud mobile phone 420 requires live content at bit rate B.
  • the content distribution service node 320 can also according to the bit rate requirements of each cloud mobile phone,
  • the live content is transcoded a second time to obtain the live content of bitrate A and the live content of bitrate B, and all the live content of the two bitrates are pushed to the streaming address for the first virtual of the cloud phone 410
  • the camera pulls the live content with code rate A from the streaming address
  • the second virtual camera of the cloud phone 420 pulls the live content with code rate B from the streaming address, so that the cloud-based mobile phone-based live broadcast method provided in this application can be applied For various live broadcast platforms with bitrate requirements, the solution is more universal.
  • the bit rate requirement of each cloud mobile phone may be that after the cloud mobile phone management node 310 creates the cloud mobile phone 410 and the cloud mobile phone 420, it is stored in the binding information of the content distribution service node 320 when the content distribution service node 320 is created.
  • the anchor uses the cloud mobile phone application on the anchor terminal 120 (the cloud mobile phone application is named "Live" as an example), create a cloud phone 410 and a cloud phone 420, install the first live application 412 on the cloud phone 410, and install the second live application 422 on the cloud phone 420, and then start a multi-platform video live broadcast.
  • the cloud mobile phone application is named "Live" as an example
  • create a cloud phone 410 and a cloud phone 420 create a cloud phone 410 and a cloud phone 420, install the first live application 412 on the cloud phone 410, and install the second live application 422 on the cloud phone 420, and then start a multi-platform video live broadcast.
  • the following describes some exemplary graphical user interfaces after the user starts the live broadcast during the process from step S310 to step S340.
  • the user can return to the user interface 11 to start the live video broadcast. Specifically, the user can click the icon 211 of the cloud live broadcast in the manner described in the embodiment in FIG. Click the return control 801 in the upper left corner to return to the previous user interface of the current user interface until the user interface 11 is returned.
  • the anchor terminal 120 detects the user operation, and in response to the user operation, the anchor terminal 120 may display the user interface 15 that is being broadcast live as shown in FIG. 11.
  • the user interface 15 includes a live broadcast status bar 1101, a cloud phone status bar 1102, a zoom control 1103, a live broadcast window 1104, a chat window 1105, and a common control tray 1106, among which,
  • the live broadcast status bar 1101 is used to display the live broadcast status of the user, including the live broadcast status of various platforms. For example, as shown in Figure 11, the live broadcast is being broadcast on platform 1 and the live broadcast is being broadcast on platform 2.
  • the expression of the live broadcast status bar 1101 can be text information, icons Or other forms, this application is not specifically limited.
  • the cloud phone status bar 1102 is used to display the operating status of the user's cloud phone.
  • the cloud phone 410 shown in FIG. 11 is running, and the cloud phone 420 is running.
  • the live broadcast status bar 1101 can be in the form of text messages, icons or other forms. This application is not specifically limited.
  • the zoom out control 1103 is used to receive a user operation (such as a touch operation).
  • a user operation such as a touch operation
  • the anchor terminal 120 may shrink the interface of the cloud live broadcast for the user to perform other operations, such as opening a mailbox to check new emails.
  • the live broadcast window 1104 is used to display live broadcast content.
  • the chat window 1105 is used to display chat records of multiple platform users.
  • the common control tray 1106 includes multiple common controls, such as a beauty control 1106A, an end live control 1106B, and a switching control 1106C.
  • the beauty control 1106A is used to beautify the live broadcast screen
  • the end live control 1106B is used to end the current live broadcast
  • the switching control 1106C is used to switch the front and rear cameras.
  • FIG. 11 only exemplarily shows the user interface 15 on the host terminal 120 that is being broadcast live, and should not constitute a limitation to the embodiment of the present application.
  • the host terminal when the user clicks the start live broadcast control 304C in the user interface 11, the host terminal will send the live content generated by the host terminal 120 to the cloud phone management node 310. Specifically, the host terminal can follow The streaming address of the content distribution service node 320 previously sent by the cloud mobile phone management node 310 sends the live content to the content distribution service node 320, so that the content distribution service node 320 sends the live content to the streaming address for the first virtual camera And the second virtual camera pulls the live content from the streaming address.
  • the anchor terminal When the user clicks the start live broadcast control 304C in the user interface 11, the anchor terminal will also send a live broadcast start command to the cloud phone management node 310, so that the cloud phone management node 310 starts the live broadcast application in the cloud phone 410 according to the live broadcast command.
  • the live application 2 in the Heyun mobile phone 420 the first camera call instruction is generated when the live application 1 is started, and the second camera call instruction is generated when the live application 2 is started.
  • the live application 1 sends the first camera call instruction to the first virtual camera, and the first driver in the first virtual camera can return to the live application 1 the live content previously pulled from the streaming address, so that the live application 1 can obtain the host
  • the live broadcast content generated by the terminal 120 completes the video live broadcast of the first live broadcast platform, and similarly, the video live broadcast of the second live broadcast platform can be completed.
  • the cloud mobile phone live broadcast method adopted in the embodiment of this application allows the user to create only the required cloud phone before the live broadcast, and after binding the live broadcast platform, the user can start more with a very simple and convenient operation.
  • Platform live broadcast no need to buy new anchor terminal to serve different live broadcast platforms, instead it is realized by cloud mobile phone, and the rental price of cloud mobile phone is lower than the purchase price of anchor terminal, which can solve the need for anchor users to purchase multiple anchors when broadcasting on multiple platforms
  • the terminal causes the problem of high cost, and during the live broadcast process, only the live broadcast content generated by one anchor terminal needs to be used and sent to the content distribution service node 320, and the live content is distributed to different live broadcasts through the content distribution service node 320.
  • At least two cloud mobile phones connected to the platform enable different live broadcast platforms to obtain the same live content from the corresponding cloud mobile phones for video live broadcast, which can improve the interaction between the anchor and the audience on different platforms, and only one upload is required during the live broadcast.
  • Live content which occupies lower network bandwidth than multi-channel live content, can effectively solve the problem of live broadcast freezes.
  • FIG. 12 is a schematic structural diagram of a cloud mobile phone management node 600 provided by the present application.
  • the cloud mobile phone management node 600 may be the cloud mobile phone management node 310 in the foregoing content.
  • the cloud mobile phone management node 600 provided by the present application may include:
  • the receiving unit 610 is configured to receive cloud phone creation information sent by the anchor terminal 120, where the cloud phone creation information includes specification information of at least two cloud phones;
  • the creating unit 620 is configured to create at least two cloud phones according to the cloud phone creation information, where at least two cloud phones are connected to different live broadcast platforms;
  • the sending unit 630 is configured to send the streaming address to the host terminal 120, where the streaming address is the destination address of the live content generated by the host terminal 120;
  • the setting unit 640 is configured to set the streaming address to at least two cloud phones, and the streaming address is used to provide live content for the at least two cloud phones to pull.
  • the creating unit 620 is further configured to create the content distribution service node 320 after the receiving unit 610 receives the cloud phone creation information sent by the anchor terminal, and set the streaming address and the streaming address for the content distribution service node 320.
  • the cloud phone creation information includes the specification information of the first cloud phone and the specification information of the second cloud phone
  • the specification information of the first cloud phone includes the information of the first live broadcast application that needs to be set on the first cloud phone and The information of the first virtual camera that needs to be set in the first cloud phone
  • the specification information of the second cloud phone includes the information of the second live broadcast application that needs to be set on the second cloud phone and the second virtual camera that needs to be set on the second cloud phone.
  • the creation unit 620 is configured to create a first cloud phone and a second cloud phone in the cloud phone resource pool according to the cloud phone creation information, where the first cloud phone is provided with the first live application and the first virtual camera, and the second cloud phone
  • the cloud mobile phone is provided with a second live broadcast application and a second virtual camera.
  • the first live broadcast application and the second live broadcast application serve different live broadcast platforms;
  • the setting unit 640 is used to set the streaming address to the first virtual camera of the first cloud mobile phone And the second virtual camera of the second cloud phone.
  • the setting unit 640 is used to set a first driver for the first cloud phone and a second driver for the second cloud phone, where the first driver is used to control the first virtual camera to receive the first live broadcast.
  • the first camera call instruction generated by the application sends to the first live application the live content pulled by the first virtual camera from the streaming address.
  • the second driver is used to control the second virtual camera to receive the second generated by the second live application.
  • the camera calls the instruction the live broadcast content pulled by the second virtual camera from the streaming address is sent to the second live broadcast application.
  • the node further includes a starting unit 650, and the receiving unit 610 is further configured to receive a live broadcast starting command sent by the anchor terminal 120; the starting unit 650 is used to start the first live broadcast application and the cloud in the cloud phone 410 according to the live broadcast starting command.
  • the second live broadcast application in the mobile phone 420, wherein a first camera call instruction is generated after the first live broadcast application is started, and a second camera call instruction is generated when the second live broadcast application is started.
  • FIG. 12 is an exemplary division method, which is not specifically limited in this application.
  • the cloud phone management node 600 After the cloud phone management node 600 creates the first cloud phone and the second cloud phone according to the cloud phone creation information, it sets the streaming address to the first virtual camera of the first cloud phone and the second virtual camera of the second cloud phone. In this way, When the host starts the live broadcast, the host terminal 120 pushes the live content to the streaming address of the content distribution service node 320, and the content distribution service node 320 associates the live content with the streaming address. At this time, the first virtual camera and the second virtual camera The live content can be pulled from the streaming address, so that both the first cloud mobile phone and the second cloud mobile phone can obtain the live content sent by the anchor terminal 120, so that multiple cloud mobile phones can share the live content collected by the anchor terminal camera for live broadcasting.
  • the purpose is to solve the high cost of multi-platform live broadcast system, poor interactive effect and prone to jams.
  • FIG. 13 is a schematic structural diagram of a computing device 900 provided by an embodiment of this application.
  • the computing device 900 may be the cloud mobile phone management node 310 in the embodiment of FIG. 2 to FIG. 11 and the cloud mobile phone management node 600 in the embodiment of FIG. 12.
  • the computing device 900 includes a processor 910, a communication interface 920, and a memory 930.
  • the processor 910, the communication interface 920, and the memory 930 may be connected to each other through an internal bus 940, and may also communicate through other means such as wireless transmission.
  • the connection via a bus 940 is taken as an example.
  • the bus 940 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus.
  • PCI Peripheral Component Interconnect
  • EISA Extended Industry Standard Architecture
  • the bus 940 can be divided into an address bus, a data bus, a control bus, and the like. For ease of presentation, only one thick line is used in FIG. 13, but it does not mean that there is only one bus or one type of bus.
  • the processor 910 may be composed of at least one general-purpose processor, such as a central processing unit (CPU), or a combination of a CPU and a hardware chip.
  • the aforementioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (Programmable Logic Device, PLD), or a combination thereof.
  • the above-mentioned PLD may be a complex programmable logic device (Complex Programmable Logic Device, CPLD), a field programmable logic gate array (Field-Programmable Gate Array, FPGA), a general array logic (Generic Array Logic, GAL), or any combination thereof.
  • the processor 910 executes various types of digital storage instructions, such as software or firmware programs stored in the memory 930, which enables the computing device 900 to provide a wide variety of services.
  • the memory 930 is used to store program codes, which are controlled by the processor 910 to execute, so as to execute the processing steps of the cloud phone management node 310 in any of the embodiments in FIG. 2 to FIG. 11.
  • the program code may include one or more software modules.
  • the one or more software modules can be the software modules provided in the embodiment shown in FIG. 12, such as a receiving unit, a creating unit, a sending unit, and a setting unit.
  • the receiving unit can be used to receive the cloud mobile phone creation sent by the anchor terminal 120.
  • the creation unit can be used to create at least two cloud phones according to the cloud phone creation information
  • the sending unit can be used to send the push address of the content distribution service node to the anchor terminal
  • the setting unit can be used to send the content distribution service node's
  • the streaming address is set in at least two cloud mobile phones, which can be used to perform S410-step S440 and optional steps of the foregoing method, and can also be used to perform other cloud mobile phone management nodes 310 described in the embodiments of FIGS. 2-12. The steps performed are not repeated here.
  • the present embodiment may be a common physical server implementations, e.g., the ARM X86 server or servers, may be based on a common physical server technology binding NFV virtual machine implemented by the virtual machine software means simulation of a complete hardware system functions, a complete computer system to run in a completely isolated environment, the present application is not particularly limited.
  • the ARM X86 server or servers may be based on a common physical server technology binding NFV virtual machine implemented by the virtual machine software means simulation of a complete hardware system functions, a complete computer system to run in a completely isolated environment, the present application is not particularly limited.
  • the memory 930 may include a volatile memory (Volatile Memory), such as a random access memory (Random Access Memory, RAM); the memory 1030 may also include a non-volatile memory (Non-Volatile Memory), such as a read-only memory ( Read-Only Memory (ROM), Flash Memory (Flash Memory), Hard Disk Drive (HDD), or Solid-State Drive (SSD); the memory 930 may also include a combination of the above types.
  • the memory 930 may store program codes, and may specifically include program codes for executing other steps described in the embodiments of FIG. 2 to FIG. 11, and details are not described herein again.
  • the communication interface 920 may be a wired interface (such as an Ethernet interface), an internal interface (such as a high-speed serial computer expansion bus (Peripheral Component Interconnect express, PCIe) bus interface), a wired interface (such as an Ethernet interface), or a wireless interface (for example, a cellular network interface or the use of a wireless local area network interface) to communicate with other devices or modules.
  • a wired interface such as an Ethernet interface
  • PCIe Peripheral Component Interconnect express
  • FIG. 13 is only a possible implementation manner of the embodiment of the present application.
  • the computing device may also include more or fewer components, which is not limited here.
  • Regarding the content that is not shown or described in the embodiments of the present application please refer to the relevant descriptions in the embodiments described in FIG. 2 to FIG. 11, which will not be repeated here.
  • the computing device shown in FIG. 13 may also be a computer cluster composed of at least one server, which is not specifically limited in this application.
  • An embodiment of the present application also provides a computer-readable storage medium, which stores instructions in the computer-readable storage medium, and when the computer-readable storage medium runs on a processor, the method flow shown in FIGS. 2 to 11 is implemented.
  • the embodiment of the present application also provides a computer program product.
  • the computer program product runs on a processor, the method flow shown in FIGS. 2 to 11 is realized.
  • the above-mentioned embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination.
  • the above-mentioned embodiments may be implemented in the form of a computer program product in whole or in part.
  • the computer program product includes at least one computer instruction.
  • the computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.
  • the computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from a website, computer, server, or data center.
  • the computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes at least one set of available media.
  • the usable medium may be a magnetic medium (for example, a floppy disk, a hard disk, and a magnetic tape), an optical medium (for example, a high-density digital video disc (Digital Video Disc, DVD)), or a semiconductor medium.
  • the semiconductor medium may be an SSD.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种基于云手机(410,420)的直播和配置方法以及相关装置和***(100),其中的方法包括以下步骤:内容分发服务节点(320)接收主播终端(120)向内容分发服务节点(320)的推流地址发送的直播内容,并将直播内容关联至内容分发服务节点(320)的拉流地址,其中,直播内容是由主播终端(120)产生的,至少两个云手机(410,420)分别从内容分发服务节点(320)的拉流地址拉取直播内容,并将直播内容发送至不同的直播平台(131,132),由此可以实现多个云手机(410,420)共用主播终端(120)产生的直播内容进行直播的目的,进而解决了多平台直播***成本高、互动效果差以及容易出现卡顿的情况。

Description

基于云手机的直播和配置方法以及相关装置和*** 技术领域
本申请涉及云计算领域,尤其涉及基于云手机的直播和配置方法以及相关装置和***。
背景技术
视频直播已经成为互联网中流量占比最高的行业之一,直播行业涌现出拥有大量用户群体的直播平台,每个直播平台的用户对直播平台都具有一定的粘性,因此不同直播平台的用户群体之间重叠程度不高,这就导致了对于大部分主播来说,相对于固定在单一平台直播,同时在多个平台进行直播可以快速获得更多的观众,也就带来更多的直播收益。
通常情况下,一个主播在多个直播平台进行同步直播,需要使用多台手机,主播为每台手机安装不同种类的直播应用,其中不同种类的直播应用分别服务于不同的直播平台,主播还需将每台手机的摄像头设置以合适角度以分别获取直播视频,每个手机获取的直播视频通过手机中运行的直播应用经互联网发送至对应的直播平台,不同直播平台的观众通过自身使用的手机在对应的直播平台拉取视频内容,从而实现多平台直播。
然而上述多平台直播方案具有很多弊端:首先,每新增一个直播平台主播就要购买一台手机,导致直播成本升高;其次,每个手机需要放置在不同的角度,主播难以同时正对每台手机,使得互动效果较差;并且,多台手机共用网络时,容易造成网络拥堵,进而造成直播卡顿,降低用户使用体验。
发明内容
本申请提供了基于云手机的直播和配置方法以及相关装置和***,用于解决主播进行多平台直播时成本高、互动效果差以及容易卡顿等问题。
第一方面,提供了一种基于云手机的直播方法,该方法应用于直播***,该直播***包括内容分发服务节点和至少两个云手机,至少两个云手机分别与不同的直播平台连接,内容分发服务节点设置有推流地址和拉流地址,该方法包括以下步骤:首先,内容分发服务节点接收主播终端向推流地址发送的直播内容,并将直播内容关联至拉流地址,其中,直播内容是由主播终端产生,然后,至少两个云手机分别从拉流地址拉取直播内容,并将直播内容发送至不同的直播平台。
实施第一方面描述的方法,主播终端产生直播内容之后,将其推流至内容分发服务节点的推流地址,内容分发服务节点可以从推流地址拉取到直播内容,并将直播内容关联至拉流地址中,至少两个云手机从该拉流地址拉取直播内容并将直播内容发送至不同的直播平台进行视频直播,可以实现多个云手机共用主播终端产生的直播内容进行直播的目的,由于主播无需购买新的主播终端以服务不同的直播平台,取而代之以云手机实现,而云手机的租用价格比主播终端的购买价格低,可解决主播用户进行多平台直播时需购买多个主播终端而造成的成本较高的问题,并且在直播过程中,仅需采用一台主播终端产生直播内 容并发送至内容分发服务节点,通过内容分发服务节点将直播内容分发到与不同的直播平台连接的至少两个云手机,使得不同的直播平台可从对应的云手机中获取到相同的直播内容进行视频直播,可提高主播与不同平台的观众之间的互动效果,且直播过程中仅需上传一路直播内容,占用的网络带宽相对于上传多路直播内容而言较低,可有效解决直播卡顿问题。
在一种可能的实现方式中,直播***还包括云手机管理节点,在内容分发服务节点接收主播终端向推流地址发送的直播内容之前,上述方法还包括以下步骤:云手机管理节点接收主播终端发送的云手机创建信息,其中,该云手机创建信息包括至少两个云手机的规格信息,使得云手机管理节点根据云手机创建信息创建至少两个云手机,然后将推流地址发送至主播终端,将拉流地址设置于上述至少两个云手机。
实施上述实现方式,在主播开始直播之前,主播可根据所需的直播平台的种类创建对应数量的云手机,一个云手机与一个特定种类的直播平台连接,使得多个云手机分别与不同的直播平台连接,多个云手机分别从内容分发服务节点拉取直播内容,从而实现多平台直播。
在一种可能的实现方式中,云手机管理节点将内容分发服务节点的拉流地址设置于第一虚拟摄像头和第二虚拟摄像头之前,上述方法还包括以下步骤:云手机管理节点创建内容分发服务节点,并为该内容分发服务节点配置上述推流地址和上述拉流地址。
实施上述实现方式,云手机管理节点可以在数据中心的云手机资源池中创建云手机,在数据中心的虚拟机资源池中创建内容分发服务节点,使得同一个用户申请的至少两个云手机可以拥有一个专用的内容分发服务节点,一个用户账号和一个内容分发服务节点一一对应,多个用户之间的直播流量不会产生冲突,避免直播卡顿情况的出现。并且,云手机和内容分发服务节点均为公有云提供的虚拟资源,使得多平台直播的成本大大降低。
在一种可能的实现方式中,云手机创建信息包括第一云手机的规格信息和第二云手机的规格信息,第一云手机的规格信息包括第一直播应用的信息和第一虚拟摄像头的信息,第二云手机的规格信息包括第二直播应用的信息和第二虚拟摄像头的信息。云手机管理节点可以根据云手机创建信息在云手机资源池创建第一云手机和第二云手机,其中,第一云手机设置有第一虚拟摄像头和第一直播应用,第二云手机设置有第二虚拟摄像头和第二直播应用,第一直播应用服务于第一直播平台,第二直播应用服务于第二直播平台,第一直播平台与第二直播平台是不同的直播平台,拉流地址被设置于第一虚拟摄像头和第二虚拟摄像头。
实施上述实现方式,云手机管理节点根据云手机创建信息创建第一云手机和第二云手机之后,将拉流地址设置于第一云手机的第一虚拟摄像头和第二云手机的第二虚拟摄像头,这样,当主播开始直播后,主播终端将直播内容推流至内容分发服务节点的推流地址,内容分发服务节点将直播内容关联至拉流地址,此时第一虚拟摄像头、第二虚拟摄像头可以从该拉流地址拉取直播内容,使得第一云手机和第二云手机都可以获取到主播终端发送的直播内容,从而实现多个云手机共用主播终端摄像头采集的直播内容进行直播的目的,进而解决了多平台直播***成本高、互动效果差以及容易出现卡顿的情况。
在一种可能的实现方式中,云手机管理节点根据云手机创建信息在云手机资源池创建 第一云手机和第二云手机之后,还可以为第一云手机设置第一驱动,其中,第一驱动用于控制第一虚拟摄像头在接收到第一直播应用产生的第一摄像头调用指令的情况下向第一直播应用发送第一虚拟摄像头从拉流地址拉取的直播内容。同理,还可以为第二云手机设置第二驱动,其中,第二驱动用于控制第二虚拟摄像头在接收到第二直播应用产生的第二摄像头调用指令的情况下向第二直播应用发送第二虚拟摄像头从拉流地址拉取的直播内容。
实施上述实现方式,使得云手机上的直播应用向虚拟摄像头发送摄像头调用指令的情况下,虚拟摄像头向直播应用返回从拉流地址拉取的直播内容,直播应用对直播内容的来源无感知,进而实现在不修改直播应用的情况下,达到将主播终端产生的直播内容返回给直播应用进行视频直播的目的。由于直播应用一般为第三方的直播平台提供,而本申请的视频直播方法无需修改直播应用,因此针对第三方的直播平台具有普遍适用性。
在一种可能的实现方式中,当主播开始直播后,云手机管理节点可以接收主播终端发送的直播启动命令,然后根据直播启动命令启动第一直播应用和第二直播应用,其中,第一直播应用启动后产生上述第一摄像头调用指令,第二直播应用启动后产生上述第二摄像头调用指令。
实施上述实现方式,当用户开始直播时,云手机管理节点可以启动各个云手机中的直播应用,直播应用在启动时,向各自所处的云手机的虚拟摄像头发送摄像头调用指令,虚拟摄像头向直播应用返回从拉流地址拉取的直播内容,使得各个直播应用都可以获取到主播终端产生的直播内容,从而实现一个主播终端产生的直播内容在多个直播平台进行直播的目的。
在一种可能的实现方式中,至少两个云手机分别从拉流地址拉取直播内容,并将直播内容发送至不同的直播平台,包括:第一虚拟摄像头从拉流地址拉取直播内容,第一直播应用从第一虚拟摄像头获取直播内容并将直播内容发送至第一直播平台;第二虚拟摄像头从拉流地址拉取直播内容,第二直播应用从第二虚拟摄像头获取直播内容并将直播内容发送至第二直播平台。
实施上述实现方式,主播开始直播后,内容分发服务节点接收到主播终端产生的直播内容,然后将直播内容关联至拉流地址,各个云手机的虚拟摄像头分别从内容分发服务节点的拉流地址拉取直播内容,每个云手机上的直播应用可以将从虚拟摄像头处获取到的直播内容分别发送给对应的直播平台进行视频直播,从而实现一个主播终端产生的直播内容在多个直播平台进行直播的目的,进而解决了多平台直播***成本高、互动效果差以及容易出现卡顿的问题。
在一种可能的实现方式中,该方法还包括以下步骤:内容分发服务节点接收该主播终端向推流地址发送的控制流,并将该控制流分别发送至第一云手机和第二云手机,其中,控制流可以是指令流,用于控制主播终端前后置摄像头的切换,摄像头调焦、对比度、亮度等。
在一些情况下,直播应用为第三方的直播平台提供,直播应用在运行时若不能接收到摄像头发送的控制流,有可能会认为摄像头发生故障,直播应用可能会向操作***报错或不能正常运行,但是云手机所能提供的摄像头由于是虚拟摄像头,虚拟摄像头无法向直播应用提供控制流,从而使得直播应用报错或不能正常运行,实施上述实现方式,主播终端 可以将本机摄像头的控制流发送给内容分发服务节点,内容分发服务节点将控制流发送至每个云手机的虚拟摄像头,虚拟摄像头可以向直播应用返回主播终端的控制流,从而使得云手机的虚拟摄像头可以向直播应用发送针对摄像头的控制流,从而保证直播应用正常运行。由于直播应用一般为第三方的直播平台提供,而本申请的视频直播方法无需修改直播应用,因此针对第三方的直播平台具有普遍适用性。
在一种可能的实现方式中,直播内容包括视频流和音频流,直播终端的摄像头采集主播的视频流,直播终端的麦克风采集主播的音频流,直播终端将视频流和音频流合成为直播内容,该方案尤其适用于主播现场表演的场景。
在其他实施例中,直播内容还可以包括另外一种音视频流,该音视频流结合了主播终端运行应用时产生的音视频流和麦克风采集的由主播旁述产生的音频流的音视频流,该方案尤其适用于在线游戏直播,在线课堂,设计软件教学等场景。
在一种可能的实现方式中,云手机上的虚拟摄像头接收到直播平台发送的调用指令,在向直播平台返回由拉流地址拉取的直播内容之前,可以先将之前从拉流地址中拉取的直播内容进行格式转换,将其转换为直播应用能够识别的格式,比如将直播内容中的视频流转换为主播终端摄像头采集的原格式音视频数据,然后再将其返回给直播平台。
实施上述实现方式,可以避免由于直播应用无法识别虚拟摄像头返回的直播内容的格式,出现应用报错的问题。由于直播应用一般为第三方的直播平台提供,而本申请的视频直播方法无需修改直播应用,因此针对第三方的直播平台具有普遍适用性。
在一种可能的实现方式中,内容分发服务节点从拉流地址拉取到主播终端发送的直播内容和控制流之后,还可以根据各个云手机的码率需求对直播内容进行二次转码,比如第一云手机上的第一直播应用需要码率A的直播内容,第二云手机的第二直播应用需要码率B的直播内容,此时内容分发服务节点还可以根据各个云手机的码率需求,对直播内容进行二次转码,获得码率A的直播内容和码率B的直播内容,并将两种码率的直播内容全部推流到拉流地址,以供第一云手机的第一虚拟摄像头从该拉流地址拉取码率A的直播内容,第二云手机的第二虚拟摄像头从该拉流地址拉取码率B的直播内容,其中,各个云手机的码率需求可以是云手机管理节点创建第一云手机和第二云手机之后,创建内容分发服务节点时存储于该内容分发服务节点的数据库中。
实施上述实现方式,可以使得本申请提供的基于云手机的直播方法能够适用于各种***率需求的直播平台,针对第三方的直播平台具有普遍适用性。
第二方面,提供了一种基于云手机的直播配置方法,该方法包括以下步骤:云手机管理节点接收主播终端发送的云手机创建信息,其中,该云手机创建信息包括至少两个云手机的规格信息,使得云手机管理节点根据云手机创建信息创建至少两个云手机,上述至少两个云手机与不同的直播平台连接,然后将推流地址发送至主播终端,推流地址为主播终端产生的直播内容的目的地址,再将拉流地址设置于上述至少两个云手机,该拉流地址用于提供直播内容以供至少两个云手机拉取。
实施第二方面描述的方法,云手机管理节点根据云手机创建信息创建第一云手机和第二云手机之后,将拉流地址设置于第一云手机的第一虚拟摄像头和第二云手机的第二虚拟摄像头,这样,当主播开始直播后,主播终端将直播内容推流至内容分发服务节点的推流 地址,内容分发服务节点将直播内容关联至拉流地址,此时第一虚拟摄像头、第二虚拟摄像头可以从该拉流地址拉取直播内容,使得第一云手机和第二云手机都可以获取到主播终端发送的直播内容,从而实现多个云手机共用主播终端摄像头采集的直播内容进行直播的目的,进而解决了多平台直播***成本高、互动效果差以及容易出现卡顿的情况。
直播平台在一种可能的实现方式中,云手机管理节点接收主播终端发送的云手机创建信息之后,上述方法还包括以下步骤:云手机管理节点创建内容分发服务节点,并为内容分发服务节点设置推流地址和拉流地址。
实施上述实现方式,作为用于管理云手机的节点,云手机管理节点可以在数据中心的云手机资源池中创建云手机,在数据中心的虚拟机资源池中创建内容分发服务节点,使得同一个用户申请的至少两个云手机可以拥有一个专用的内容分发服务节点,每个用户的直播流量不会产生冲突,避免直播卡顿情况的出现,并且,云手机和内容分发服务节点均为公有云提供的虚拟资源,使得多平台直播的成本大大降低。
在一种可能的实现方式中,云手机创建信息包括第一云手机的规格信息和第二云手机的规格信息,第一云手机的规格信息包括需设置在第一云手机需的第一直播应用的信息和需设置在第一云手机的第一虚拟摄像头的信息,第二云手机的规格信息包括需设置在第二云手机的第二直播应用的信息和需设置在第二云手机的第二虚拟摄像头的信息。因此,云手机管理节点根据云手机创建信息创建至少两个云手机时,可以先根据云手机创建信息在云手机资源池创建第一云手机和第二云手机,其中,第一云手机设置有第一虚拟摄像头和第一直播应用,第二云手机设置有第二虚拟摄像头和第二直播应用,第一直播应用服务于第一直播平台,第二直播应用服务于第二直播平台,第一直播平台与第二直播平台是不同的直播平台,将拉流地址设置于第一虚拟摄像头和第二虚拟摄像头。
实施上述实现方式,云手机管理节点根据云手机创建信息创建第一云手机和第二云手机之后,将拉流地址设置于第一云手机的第一虚拟摄像头和第二云手机的第二虚拟摄像头,这样,当主播开始直播后,主播终端将直播内容推流至直播内容内容分发服务节点的推流地址,内容分发服务节点将直播内容关联至拉流地址,此时第一虚拟摄像头、第二虚拟摄像头可以从拉流地址拉取直播内容,使得每个云手机都可以获取到主播终端拍摄到的直播内容,从而实现多个云手机共用主播终端摄像头采集的直播内容进行直播的目的,进而解决了多平台直播***成本高、互动效果差以及容易出现卡顿的情况。
在一种可能的实现方式中,云手机管理节点根据云手机创建信息在云手机资源池创建第一云手机和第二云手机之后,还可以为第一云手机设置第一驱动,其中,第一驱动用于控制第一虚拟摄像头在接收到第一直播应用产生的第一摄像头调用指令的情况下向第一直播应用发送第一虚拟摄像头从拉流地址拉取的所述直播内容。同理,还可以为第二云手机设置第二驱动,其中,第二驱动用于控制第二虚拟摄像头在接收到第二直播应用产生的第二摄像头调用指令的情况下向第二直播应用发送第二虚拟摄像头从拉流地址拉取的所述直播内容。
实施上述实现方式,使得云手机上的直播应用向虚拟摄像头发送摄像头调用指令的情况下,虚拟摄像头向直播应用返回从拉流地址拉取的直播内容,直播应用对直播内容的来源无感知,进而实现在不修改直播应用的情况下,达到将主播终端采集的直播内容返回给 直播应用进行视频直播的目的。由于直播应用一般为第三方的直播平台提供,而本申请的视频直播方法无需修改直播应用,因此针对第三方的直播平台具有普遍适用性。
在一种可能的实现方式中,当主播开始直播后,云手机管理节点可以接收主播终端发送的直播启动命令,然后根据直播启动命令启动第一直播应用和第二直播应用,其中,第一直播应用启动后产生上述第一摄像头调用指令,第二直播应用启动后产生上述第二摄像头调用指令。
实施上述实现方式,当用户开始直播时,云手机管理节点可以启动各个云手机中的直播应用,直播应用在启动时,向各自所处的云手机的虚拟摄像头发送摄像头调用指令,虚拟摄像头向直播应用返回从拉流地址拉取的直播内容,使得各个直播应用都可以获取到主播终端产生的直播内容,从而实现一个主播终端产生的直播内容在多个直播平台进行直播的目的。
第三方面,提供了一种直播***,该直播***包括内容分发服务节点和至少两个云手机,至少两个云手机分别与不同的直播平台连接,该内容分发服务节点设置有推流地址和拉流地址。其中,内容分发服务节点可以用于接收主播终端向推流地址发送的直播内容,并将直播内容关联至拉流地址,应理解,这里的直播内容是由主播终端产生的。而至少两个云手机则用于分别从拉流地址拉取直播内容,并将直播内容发送至不同的直播平台。
第三方面或第三方面任意一种实现方式是第一方面或第一方面任意一种实现方式对应的***实现,第一方面或第一方面任意一种实现方式中的描述适用于第三方面或第三方面任意一种实现方式,在此不再赘述。
第四方面,提供了一种云手机管理节点,包括:接收单元,该接收单元用于接收主播终端发送的云手机创建信息,该云手机创建信息包括第一云手机的规格信息和第二云手机的规格信息。创建单元,该创建单元用于根据该云手机创建信息在云手机资源池创建该第一云手机和该第二云手机,其中,该第一云手机设置有第一直播应用和第一虚拟摄像头,该第二云手机设置有第二直播应用和第二虚拟摄像头,该第一直播应用和该第二直播应用服务于不同的直播平台。发送单元,该发送单元用于将推流地址发送至该主播终端,该推流地址为该主播终端发送的直播内容的目的地址。设置单元,该设置单元用于将拉流地址设置于该第一虚拟摄像头和该第二虚拟摄像头,该拉流地址用于提供该直播内容以供该第一虚拟摄像头和该第二虚拟摄像头拉取。
第四方面或第四方面任意一种实现方式是第二方面或第二方面任意一种实现方式对应的装置实现,第二方面或第二方面任意一种实现方式中的描述适用于第四方面或第四方面任意一种实现方式,在此不再赘述。
第五方面,提供了一种计算机可读存储介质,包括指令,当该指令在计算设备上运行时,使得该计算设备执行如第一方面或第二方面描述的方法。
第六方面,提供了一种计算设备,包括处理器和存储器,该处理器执行该存储器中的代码时,使得计算设备实现如第一方面或第二方面描述的方法。
第七方面,提供了一种计算机程序产品,当该计算机程序产品被计算设备读取并执行时,实现如第一方面或第二方面描述的方法。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍。
图1是一种多平台直播***的结构示意图;
图2是本申请提供的直播***的结构示意图;
图3是本申请提供的云手机创建***的结构示意图;
图4是本申请提供的基于云手机的直播配置方法的流程示意图;
图5-图9是本申请提供的云手机的直播配置方法中一些用户界面的实施例的示意图;
图10是本申请提供的基于云手机的直播方法的流程示意图;
图11是本申请提供的云手机的直播方法中用户界面的实施例的示意图;
图12是本申请提供的一种云手机管理节点的结构示意图;
图13是本申请提供的一种计算设备的结构示意图。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
为了便于理解本申请实施例,首先,对本申请涉及的部分数据进行解释说明。
云手机(Cloud Phone):一种在物理服务器中运行的带有手机操作***,同时具有虚拟手机功能的容器,其本质是将手机上的应用转移到公有云数据中心的物理服务器中运行,不同的云手机之间相互隔离,互不干扰,云手机可以安装本地手机的应用,该些应用在云手机中运行,运行过程中产生的音视频流可发送至本地手机进行显示及播放,本地手机根据显示和播放的音视频流产生的控制命令也可以发送至云手机,云手机根据控制命令控制应用的运行状态,从而可将本地手机的应用转移到云手机中运行,因此,本地手机无需大量安装耗费硬件资源的应用,可以实现应用的轻量化,并且,由于引用在云手机运行,本地手机无需设置有较高的硬件配置也可以让用户操作具有较高硬件配置需求的应用。
虚拟摄像头(Virtual Camera):云手机中通过软件等技术模拟真实摄像机,欺骗应用软件,使其可以正常使用摄像头的程序。
推流(Push):音视频流产生设备将采集阶段封包好的直播内容传输到服务器的过程。
拉流(Pull):服务器上已有的直播内容,音视频流播放设备将其拉取到本地的过程。
公有云:公有云的核心属性是共享资源服务,是指第三方供应商为用户提供的能够通过公共网络(比如因特网(Internet))使用的云端基础设施和服务,用户通过付费获得云端基础设施和服务的使用权限。
推流地址(Push Address):音视频流产生设备在推流阶段需要将采集阶段封包好的直播内容传输到服务器的指定地址,该指定地址即为推流地址,推流地址可以包括公网IP地址、端口号以及统一资源定位符(Uniform Resource Locator,URL),举例来说,推流地址可以是rtsp://10.0.10.1:554/live1,其中,10.0.10.1可以是内容分发服务节点320 的公网IP地址,554可以是端口号,/live1为直播内容存放在服务器文件***中的目录URL。
拉流地址(Pull Address):在拉流阶段需要在服务器上已有直播内容的情况下,服务器将直播内容放置到服务器的拉流地址并通知音视频流播放设备,音视频流播放设备可从拉流地址拉取直播内容,拉流地址也可以包括公网IP地址、端口号以及URL。举例来说,拉流地址可以是rtsp://10.0.10.1:554/live2,其中,10.0.10.1可以是内容分发服务节点320的公网IP地址,554可以是端口号,/live2为直播内容存放在服务器文件***中的目录URL。
内容分发网络(Content Delivery Network,CDN):内容分发网络指的是通过现有的互联网中增加一层新的网络架构,将源站的内容提前缓存至最接近用户的网络“边缘”,使得用户可以就近取得所需的内容,提高用户访问网站的响应速度。本申请的内容分发服务节点具有内容分发网络中的一个中间缓存节点或边缘缓存节点的功能,可用于缓存并发布直播内容。
其次,对本申请涉及的应用场景进行简要说明。
近年来,直播行业涌现出拥有大量用户群体的直播平台,每个直播平台的用户对平台都具有一定的粘性,因此不同平台的用户群体之间重叠程度不高,这就导致了对于大部分主播来说,相对于固定在单一平台直播,同时在多个平台进行直播可以快速获得更多的观众,也就带来更多的直播收益。
通常情况下,直播平台应用程序会独占手机摄像头资源,一个主播为了实现在多个平台进行直播,需要购买多台手机,每台手机运行不同的直播应用程序并从不同的角度将摄像头对焦于主播,从而实现多平台直播。
例如,图1是一种多平台直播***的架构示意图。如图1所示,多平台直播***100包括主播终端、直播平台以及播放设备。其中,主播终端、直播平台以及播放设备接入网络150。网络150可以是有线网络也可以是无线网络,或者是二者的混合,本申请不作具体限定。需要说明的,图1以2个主播终端(分别是主播终端1和主播终端2)以及2个直播平台(分别是第一直播平台131和第二直播平台132)为例进行了说明。
其中,主播可操作主播终端1和主播终端2,主播是直播内容提供方,具体可以指在互联网或活动中,负责参与一系列策划、编辑、录制、制作、观众互动等工作,并由本人担当主持工作的人,比如游戏主播、带货主播、网课教师、体育赛事主办方、新闻主持人等。
主播终端可以是包含摄像头且可以安装直播应用的计算设备,比如智能手机、掌上处理设备、平板电脑、移动笔记本、虚拟现实设备、一体化掌机等等。
相同类型的直播应用服务于同一直播平台,安装有相同类型的直播应用的终端可与同一直播平台建立网络连接,具体地,安装有相同类型的直播应用的终端可从同一直播平台中拉取直播内容,或将直播内容推送至该直播平台。
在本实施例中,第一直播应用412服务于第一直播平台131,第二直播应用422服务于第二直播平台132,第一直播平台131和第二直播平台132互不相同,可由不同的网络服务提供商提供,第一直播应用412和第二直播应用422为服务于不同的直播平台的不同 类型的直播应用。
当主播开始直播时,多台主播终端需设置在不同角度,每台主播终端的摄像头对焦于主播,每台主播终端只运行一个直播应用,比如图1中主播终端1包括摄像头1和第一直播应用412,主播终端2包括摄像头2和第二直播应用422。如图1所示,主播开始多平台直播后,每台主播终端的直播应用可以先获取直播内容(步骤1),直播内容可以包括主播终端的摄像头、麦克风采集的音视频流,也可以包括主播终端的显示界面。将直播内容推流(Push)到对应的第一直播平台131的推流地址,使得直播平台可以从对应的推流地址中拉取直播内容,从而进行视频直播(步骤2)。以图1为例,第一直播应用412可以将摄像头1采集的直播内容推流至第一直播平台131服务器的推流地址1,第二直播应用422可以将摄像头2采集的直播内容推流至第二直播平台132服务器的推流地址2,然后第一直播平台131服务器从推流地址1获取摄像头1采集的直播内容1,实现主播在第一直播平台131的视频直播,第二直播平台132服务器从推流地址2获取摄像头2采集的直播内容2,实现主播在第二直播平台132的视频直播。
直播平台将上述直播内容关联至直播平台的拉流地址中,以供安装有直播应用的播放设备从对应平台的拉流地址中拉取(Pull)直播内容,使得观看直播的观众可以通过播放设备看到主播的直播内容(步骤3)。仍以图1为例,安装第一直播应用412的播放设备1可以从第一直播平台131的拉流地址1中拉取直播内容1,安装主播应用2的播放设备2可以从第二直播平台132的拉流地址2中拉取直播内容2,从而实现主播在第一直播平台131和第二直播平台132的视频直播。
综上可知,图1所示的多平台直播***虽然能够实现主播的多平台直播需求,但是存在诸多弊端,首先,主播需要购买多个主播终端,在每个主播终端上安装一个直播应用,不同的直播应用服务于不同的直播平台。参考前述内容可知,在进行多平台直播过程中,每个直播应用将会调用本机摄像头进行音视频采集,因此如果摄像头的硬件能力差,比如像素很低,那么该平台的直播效果就会很差,这就导致主播需要多平台直播时,必须购买多个配置较高的主播终端,导致多平台直播的成本非常的高;其次,每个主播终端需要放置在不同的角度,将每个主播终端的摄像机对焦于主播,主播难以同时正对每台主播终端,造成多平台直播中的互动效果差;并且,多台主播终端共用网络进行多路音视频采集,容易造成网络拥堵,进而造成直播卡顿情况,降低用户使用体验。
为了解决上述多平台直播***成本高、互动效果差以及容易出现卡顿的情况,本申请提供了一种直播***200,该***200只需要一台主播终端即可满足主播的多平台直播需求。
如图2所示,本申请提供的直播***200包括云手机管理节点310、内容分发服务节点320以及至少两个云手机,至少两个云手机例如为图2中的云手机410和云手机420。在图2所示的直播***200中,主播110只需要一台安装了云手机应用122的主播终端120即可实现多个直播平台(图2以2个直播平台即第一直播平台131和第二直播平台141为例,具体实现中,本申请不对平台数量以及云手机数量进行限制)同时直播的目的。需要说明的,主播110、主播终端120、直播平台130以及播放设备140的描述可以参考图1实 施例,这里不再展开赘述。下面主要对云手机管理节点310、内容分发服务节点320以及至少两个云手机进行详细说明。
主播终端120上安装有云手机应用122,云手机应用122获取主播110在主播终端120输入的云手机创建信息,并将云手机创建信息发送给云手机管理节点310,云手机创建信息包括云手机410的规格信息和云手机420的规格信息;另一方面,云手机应用122还可以用于获取直播内容,然后将其发送至内容分发服务节点320的推流地址,以供内容分发服务节点320从推流地址拉取直播内容。
其中直播内容可以包括视频流和音频流,直播终端的摄像头采集主播的视频流,直播终端的麦克风采集主播的音频流,直播终端将视频流和音频流合成为直播内容,该方案尤其适用于主播现场表演的场景。
在其他实施例中,直播内容还可以包括另外一种音视频流,该音视频流结合了主播终端运行应用时产生的音视频流和麦克风采集的由主播旁述产生的音频流的音视频流,该方案尤其适用于在线游戏直播,在线课堂,设计软件教学等场景。
其中,云手机410的规格信息包括云手机410需设置在云手机410的第一直播应用412的信息和需设置在云手机410的第一虚拟摄像头411的信息,云手机420的规格信息包括需设置在云手机420的第二直播应用422的信息和第二虚拟摄像头421的信息,比如用户需要在直播平台X和直播平台Y进行直播,那么用户可以创建2个云手机,云手机1的规格信息至少包括:设置第一直播应用X并部署第一虚拟摄像头411,云手机2的规格信息至少包括:设置第二直播应用Y并部署第二虚拟摄像头。具体实现中,规格信息还可以包括用户需求的云手机处理器性能参数、存储器性能参数、计费方式等等,还可以包括主播在各个直播应用的账号密码信息等等,本申请不作具体限定。
需要说明的,云手机应用123通过浏览器实现;也可以是客户端/服务端(Client/Server,C/S)形式的应用程序,也就是独立运行在终端或者计算设备上的应用程序,用户可以通过提前下载并安装好的客户端进行访问,本申请不对云手机应用123的具体形式进行限定。
云手机管理节点310主要用于根据主播终端120发送的云手机创建信息,在云手机资源池中创建至少两个云手机,并分别部署对应的直播应用,每个云手机与不同的直播平台连接。然后创建上述至少两个云手机对应的内容分发服务节点320,并为该内容分发服务节点320分配推流地址和拉流地址,将内容分发服务节点320的推流地址发送给主播终端120,使得主播终端120采集到的直播内容可以通过该推流地址发送到内容分发服务节点320处,再将内容分发服务节点320的拉流地址设置于创建的至少两个云手机中,以供创建的至少两个云手机可以从拉流地址拉取直播内容,并将直播内容发送给与其相连的直播平台进行视频直播,从而实现一个主播终端在多个直播平台直播的目的。
具体实现中,参考前述内容可知,云手机410的规格信息包括需设置在云手机410的第一直播应用412的信息和需设置在云手机410的第一虚拟摄像头411的信息,云手机420的规格信息包括需设置在云手机420的第二直播应用422的信息和需设置在云手机420的第二虚拟摄像头421的信息。因此,云手机管理节点310可以根据云手机管理信息,创建云手机410和云手机420,其中,云手机410设置有第一直播应用412和第一虚拟摄像头 411,云手机420设置有第二直播应用422和第二虚拟摄像头421。云手机管理节点310还可以将内容分发服务节点的拉流地址设置于云手机410的第一虚拟摄像头411和云手机420的第二虚拟摄像头421中,以供云手机410的第一虚拟摄像头411以及云手机420的第二虚拟摄像头421可以从拉流地址拉取直播内容。
具体实现中,云手机管理节点310可以是公有云中用于管理资源的服务器,具体可以是通用的物理服务器,例如,物理服务器,如ARM服务器或者X86服务器,也可以是基于通用的物理服务器结合网络功能虚拟化(Network Functions Virtual ization,NFV)技术实现的虚拟机(Virtual Machine,VM),虚拟机指通过 软件模拟的具有完整 硬件***功能的、运行在一个完全 隔离环境中的完整 计算机***,本申请不作具体限定。
内容分发服务节点320主要用于接收主播终端120向内容分发服务节点320的推流地址发送直播内容,并将直播内容关联至内容分发服务节点320的拉流地址,以供云手机410的第一虚拟摄像头411以及云手机420的第二虚拟摄像头421从该拉流地址拉取主播终端120产生的直播内容。
具体实现中,内容分发服务节点320可以是云手机管理节点310在虚拟机资源池创建的虚拟机。其中,虚拟机资源池可以包括多个不同规格的虚拟机,云手机管理节点310可以根据资源池中的虚拟机使用情况,选择合适的虚拟机作为云手机410和云手机420的内容分发服务节点320,并为其配置推流地址和拉流地址。
在另外一些示例中,内容分发服务节点320也可以是物理服务器,本申请实施例对其实现方式不作限定。
云手机410和云手机420分别与不同的直播平台连接,用于从上述内容分发服务节点320的拉流地址中拉取直播内容,并将直播内容发送至不同的直播平台。具体地,云手机410设置有第一直播应用412和第一虚拟摄像头411,其中,第一虚拟摄像头411用于从拉流地址拉取直播内容并发送直播内容至第一直播应用412,第一直播应用412用于将直播内容发送至第一直播平台131以在第一直播平台131进行视频直播。云手机420设置有第二直播应用422和第二虚拟摄像头421,其中,第二虚拟摄像头421用于从拉流地址拉取直播内容并发送直播内容至第二直播应用422,第二直播应用422用于将直播内容发送至第二直播平台132以在第二直播平台132进行视频直播。
具体实现中,云手机410以及云手机420是基于通用的物理服务器结合容器( Container)技术实现的虚拟手机,虚拟手机指通过 软件模拟的具有完整 硬件***功能的、运行在一个完全 隔离环境中的完整手机***。
在一实施例中,第一直播平台131在启动后,将会向第一虚拟摄像头411发送第一摄像头调用指令,同理,第二直播平台132在启动后,将会向第二虚拟摄像头421发送第二摄像头调用指令。因此,云手机管理节点310在创建云手机的过程中,还会为云手机410设置第一驱动,为云手机420设置第二驱动,其中,第一驱动用于控制第一虚拟摄像头411在接收到第一直播应用412产生的第一摄像头调用指令时向第一直播应用412发送第一虚拟摄像头411从拉流地址拉取的直播内容,同理,第二驱动用于控制第二虚拟摄像头421在接收到第二直播应用422产生的第二摄像头调用指令时向第二直播应用422发送第二虚拟摄像头421从拉流地址拉取的直播内容。这样,当云手机管理节点310在接收到主播终 端120发送的直播启动命令后,可以根据直播启动命令启动云手机410的第一直播应用412和云手机420的第二直播应用422,第一直播应用412启动后可以产生第一像头调用指令,第二直播应用422启动后可以产生第二摄像头调用指令,由于云手机410中设置了第一驱动、云手机420中设置了第二驱动,因此直播应用程序可以在不进行任何修改的情况下,获得云手机410和云手机420从上述拉流地址中拉取的直播内容,实现一个主播终端120多平台直播,使得本申请提供的直播***通用性很高。
具体实现中,可以通过多种通信协议实现推流和拉流,比如实时消息传输协议(Real Time Messaging Protocol,RTMP)、流媒体实时传输协议(Http Live Streaming,HLS)、源自网络即时通信(Web Real-Time Communication,WebRTC)等等,还可以包括其他能够实现流媒体与服务器之间进行音视频和数据通信的协议,本申请不作具体限定。
下面结合图3,对上述云手机管理节点310作为公有云上管理资源的服务器,根据主播终端120发送的云手机创建信息,在云手机资源池中创建云手机410和云手机420,分别部署对应的第一直播应用412和第二直播应用422,并在虚拟机资源池创建内容分发服务节点320的具体流程进行说明。
图3是一种云手机创建***300的结构示意图,如图3所示,该***300可以包括云手机管理节点310、云手机资源池400以及虚拟机资源池500,其中,云手机资源池400和虚拟机资源池500中包括至少一个物理服务器(图3以虚拟机资源池包括服务器501和服务器502、云手机资源池包括服务器401和服务器402为例进行了举例说明),物理服务器可以是通用的物理服务器,例如,ARM服务器或X86服务器,本申请不作具体限定。
其中,云手机资源池400中的每一个服务器(比如服务器401和服务器402)包括一个云手机管理代理节点(例如云手机管理代理节点4013以及云手机管理代理节点4023)、硬件资源(比如硬件资源4012和硬件资源4022)、操作***(Operating System,OS)(比如操作***4014和操作***4024)以及至少一个云手机(比如云手机410、云手机420、云手机21和云手机22等等),其中,每一个云手机以容器(Container)的形式与服务器上其他的云手机共享硬件资源和操作***(比如云手机410以容器11的形式与服务器401上的云手机420共享硬件资源4012和操作***4014)。需要说明的,图3所示的服务器数量、容器数量、硬件资源种类仅用于举例说明,本申请不作具体限定。
云手机管理节点310用于接收主播终端120发送的云手机创建信息,还用于接收服务器401上的云手机管理代理节点4013发送的服务器401的服务器信息,以及服务器402上的云手机管理代理节点4023实时发送的服务器402的服务器信息。云手机管理节点310可以结合云手机创建信息和当前各个服务器(服务器401和服务器402)的服务器信息,选择合适的服务器,并向该服务器上的云手机管理代理节点发送创建请求,该请求中包含了需要创建的云手机410和/或云手机420的规格信息,通过云手机管理代理节点进行对应云手机的创建。举例来说,如果云手机管理节点310结合各个服务器信息以及云手机创建信息,选择服务器401创建云手机410和云手机420,那么云手机管理节点310可以向服务器401的云手机管理代理节点4013发送创建请求,该请求中包含了需要创建的云手机410和云手机420的规格信息,使得云手机管理代理节点4013可以响应于该创建请求,在服务器401中创建云手机410和云手机420。其中,服务器信息可以包括该服务器上硬件资源的使用 情况、容器的占用情况等等,比如服务器的硬件处理能力、存储余量信息、当前可用的输入输出设备的信息等等,还可以包括服务器当前的温度信息、故障率、历史资源消耗信息等等,避免服务器响应于云手机创建信息进行云手机的创建之后,影响其他业务的运行。应理解,上述举例仅用于说明,并不能构成具体限定。
每一个服务器上的云手机管理代理节点可以用于监控和收集服务器的服务器信息,并将该服务器信息实时上报至云手机管理节点310。举例来说,服务器401上的云手机管理代理节点4013可以监控和收集服务器401的服务器信息,服务器402上的云手机管理代理节点4023可以监控和收集服务器402的服务器信息;云手机管理代理节点还用于接收云手机管理节点310发送的创建请求,该创建请求包含了需要创建的云手机410和/或云手机420的规格信息,云手机管理代理节点412可以根据该规格信息,创建对应的云手机,举例来说,云手机管理节点310根据云手机创建信息中云手机410的规格信息和各个云手机管理代理节点发送的服务器信息,确定由服务器401创建云手机410,服务器402创建云手机420,那么服务器401上的云手机管理代理节点4013可以接收云手机管理节点310发送的云手机410的规格信息,根据该规格信息完成云手机410的创建,服务器402上的云手机管理代理节点4023可以接收云手机管理节点310发送的云手机420的规格信息,根据该规格信息完成云手机420的创建。应理解,上述举例仅用于说明,并不能构成具体限定。
具体实现中,云手机管理代理节点可以根据接收到的云手机的规格信息,根据规格信息在服务器创建容器,并为容器设置上述云手机的规格信息所要求的硬件和软件,容器的操作***为云手机所需的操作***。举例来说,云手机管理代理节点4013接收到云手机管理节点310发送的云手机410的创建信息之后,云手机管理代理节点4013可以根据云手机410的规格信息,将在服务器401创建容器,该容器内包含该云手机410所需部署的第一直播应用412,以及第一直播应用412所需要的操作***核心库和***库,比如功能函数库、三维图形处理库(如Open GLES)、媒体库(Media Libraries)、输入管理器(Input Manager)等等。该云手机410可以与服务器401上其他的云手机(比如图3中的云手机420和云手机3)共享硬件资源和操作***,从而实现云手机410的创建,同理,可以完成云手机420的创建,这里不展开赘述。
硬件资源(比如硬件资源4012和硬件资源4022)可以包括服务器的各种可用硬件资源,比如处理器、存储器、网卡等等,还可以包括其他云手机可能需要的硬件资源,本申请不作具体限定。
操作***(比如操作***4014和操作***4024)可以是各种手机适用的操作***,比如安卓(Android)操作***,本申请不作具体限定。需要说明的是,操作***可以是官方完整的操作***,也可以是为了适应服务器的运行方式对官方完整的操作***的个别驱动模块进行修改后的操作***,本申请不做具体限定。
云手机以容器的形式与服务器上其他的云手机共享硬件资源和操作***,每个容器可以包括云手机所需的应用程序和每个应用程序所需的依赖资源,应用程序所需的依赖资源可以是前述内容中的核心库和***库。其中,每个云手机所处的容器使用硬件资源和操作***,但是不会对硬件资源进行独占,而是和其他云手机所处的容器共享硬件资源和操作***。换句话说,各个容器没有自己的内核,容器内的应用程序进程直接运行在服务器的 内核上,云手机管理代理节点根据接收到的所需创建的云手机的规格信息对云手机进行创建时,只需要将云手机所需的应用程序和应用程序的依赖资源进行打包,创建好的各个云手机可以相互独立地直接运行于未经虚拟化的宿主机硬件上,创造出应用程序的独立沙箱运行环境。
具体实现中,云手机管理节点和部署在每个服务器上的云手机管理代理节点可以基于Kubernetes、Docker等容器管理***实现,本申请不做具体限定。
简单来说,云手机管理节点310根据云手机创建信息创建云手机410和云手机420的步骤流程可以是:云手机管理节点310在接收到云手机创建信息之后,根据图3所示的云手机创建***,结合每个服务器上的云手机管理代理节点反馈的服务器信息,在云手机资源池中选择合适的服务器,向该服务器的云手机管理代理节点发送云手410的创建信息进行云手机410的创建,云手机管理代理节点可以根据云手机410的创建信息中需要部署的第一直播应用创建容器11,该容器11内包含云手机410所需部署的第一直播应用,以及第一直播应用所需要的操作***核心和库,并与服务器上其他的容器共享硬件资源和操作***,从而实现云手机410的创建。同理,可以完成云手机420的创建,创建好的云手机420将以容器12的形式与服务器401上的云手机410共享硬件资源4012和操作***4014。
虚拟机资源池500中的每一个服务器(比如服务器501和服务502)包括硬件资源(比如硬件资源5012和硬件资源5022)、操作***(比如操作***5013和操作***5023)以及至少一个虚拟机(比如虚拟机11~虚拟机1x,虚拟机21~虚拟机2y,其中x和y为自然数)。需要说明的,图3所示的服务器数量、虚拟机数量、硬件资源种类仅用于举例说明,本申请不作具体限定。其中,硬件资源的描述可以参考前述内容,这里不展开赘述。虚拟机是基于通用的物理服务器结合NFV技术实现的虚拟机,虚拟机指通过 软件模拟的具有完整 硬件***功能的、运行在一个完全 隔离环境中的完整 计算机***。操作***还包括虚拟机管理器,比如服务器501的操作***5013可以包括虚拟机管理器5014、服务器502的操作***5023可以包括虚拟机管理器5024。
虚拟机管理器用于接收云手机管理节点310发送的虚拟机创建请求,该请求包含了需要创建的虚拟机的规格信息。虚拟机管理器5024可以响应于上述虚拟机创建请求,在服务器中创建虚拟机。举例来说,服务器501的虚拟机管理器5014可以接收云手机管理节点310发送的创建内容分发服务节点320的创建请求,并响应于上述创建请求,创建虚拟机11作为内容分发服务节点320,并为其配置拉流地址和推流地址。应理解,上述举例仅用于说明,并不能构成具体限定。
具体实现中,上述虚拟机管理器可以通过虚拟监视器(Virtual Machine Monitor,VMM)、Hypervisor实现,也可以是由其他能够实现平台虚拟化的软件实现,本申请不作具体限定。
综上可知,图2所示的直播***200,可以在主播110开始直播后,内容分发服务节点320将接收到的主播终端120产生的直播内容分别发送至多个云手机,每个云手机上安装有一个直播应用,使得每个云手机上的直播应用可以将从虚拟摄像头处获取到的直播内容分别发送给对应的直播平台进行视频直播,主播只需要使用一个安装有云手机应用的主播终端120,即可实现多个平台同时直播的目的,进而解决了多平台直播***成本高、互动效 果差以及容易出现卡顿的情况。
本申请提供了一种基于云手机的直播方法和配置方法,应用于图2所示的直播***200中,直播***200包括内容分发服务节点320、云手机410以及云手机420,云手机410设置有第一直播应用和第一虚拟摄像头,云手机420设置有第二直播应用和第二虚拟摄像头,第一直播应用和第二直播应用服务于不同的直播平台。该方法可以使得主播110通过对主播终端上的云手机应用进行设置后,即可开始通过一个主播终端实现多个平台的视频直播,解决了多平台直播***成本高、互动效果差以及容易出现卡顿的情况。
下面首先结合图4,对本申请提供的基于云手机的直播配置方法进行解释说明。如图4所示,本申请提供的基于云手机的直播配置方法包括以下步骤:
S410:云手机管理节点310接收主播终端120发送的云手机创建信息,云手机创建信息包括至少两个云手机的规格信息。
举例来说,至少两个云手机可以是前述内容中的云手机410和云手机420,云手机创建信息可以包括云手机410的规格信息和云手机420的规格信息。云手机410的规格信息包括需设置于云手机410的第一直播应用的信息和第一虚拟摄像头的信息,云手机420的规格信息包括需设置于云手机420的第二直播应用的信息和第二虚拟摄像头的信息。其中,规格信息的具体描述可以参考图2实施例,这里不再展开赘述。
S420:云手机管理节点310根据云手机创建信息创建至少两个云手机,上述至少两个云手机与不同的直播平台连接。
仍以上述例子为例,云手机管理节点310根据云手机创建信息在云手机资源池创建云手机410和云手机420,其中,云手机410设置有第一直播应用和第一虚拟摄像头,云手机420设置有第二直播应用和第二虚拟摄像头,第一直播应用和第二直播应用服务于不同的直播平台。其中,云手机创建的具体流程可以参考图3实施例,这里不再展开赘述。
S430:云手机管理节点310将推流地址发送至主播终端120,推流地址为主播终端120产生的直播内容的目的地址。
可以理解的,推流地址为内容分发服务节点320的推流地址,云手机管理节点310将推流地址发送给主播终端120,使得主播开始直播后,主播终端120可以将产生的直播内容推流至内容分发服务节点320的推流地址中,使得内容分发服务节点320可以从推流地址中拉取直播内容,并将该直播内容关联至自己的拉流地址,以供上述至少两个云手机从该拉流地址拉取直播内容,使得每个云手机可以将直播内容再发送至与其连接的直播平台,从而实现一个主播终端在多个直播平台的视频直播,进而解决了多平台直播***成本高、互动效果差以及容易出现卡顿的情况。
S440:云手机管理节点310将拉流地址设置于至少两个云手机,拉流地址用于提供直播内容以供至少两个云手机拉取。其中,拉流地址为内容分发服务节点320的拉流地址。
具体实现中,云手机管理节点310将拉流地址直接配置于云手机410的第一虚拟摄像头、云手机420的第二虚拟摄像头,进而使得主播开始直播后,第一虚拟摄像头、第二虚拟摄像头可以该拉流地址拉取直播内容,每个云手机都可以获取到主播终端产生的直播内容,从而实现多个云手机共用主播终端120产生的直播内容进行直播的目的,进而解决了 多平台直播***成本高、互动效果差以及容易出现卡顿的情况。
在步骤S440之后,上述方法还包括以下步骤:云手机管理节点310接收主播终端120发送的直播启动命令,并根据该直播启动命令启动第一云手机中的第一直播应用和第二云手机中的第二直播应用,其中,第一直播应用启动时产生第一摄像头调用指令,第二直播应用启动时产生第二摄像头调用指令。可以理解的,当用户开始直播时,云手机管理节点可以启动各个云手机中的直播应用,使得直播应用向各自所处的云手机的虚拟摄像头发送摄像头调用指令,虚拟摄像头返回从拉流地址拉取的直播内容,使得各个直播应用都可以获取到主播终端产生的直播内容,从而实现一个主播终端在多个直播平台进行直播的目的。
在步骤S430之后,具体可以是在云手机管理节点310根据云手机创建信息在云手机资源池创建云手机410和云手机420之后,在接收上述直播启动命令之前,上述方法还包括以下步骤:云手机管理节点310为云手机410设置第一驱动,第一驱动用于控制第一虚拟摄像头在接收到第一直播应用产生的第一摄像头调用指令时向第一直播应用发送第一虚拟摄像头从拉流地址拉取的直播内容;云手机管理节点310为云手机420设置第二驱动,第二驱动用于控制第二虚拟摄像头在接收到第二直播应用产生的第二摄像头调用指令时向第二直播应用发送第二虚拟摄像头从拉流地址拉取的直播内容。
在步骤S420处,云手机管理节点310创建云手机的过程当中,可以为云手机410设置第一驱动,为云手机420设置第二驱动,使得云手机410上的第一直播应用向第一虚拟摄像头发送第一摄像头调用指令时,第一虚拟摄像头返回从拉流地址拉取的直播内容,从而达到“劫持”(Hook)应用程序接口(Application Programming Interface,API)的目的,进而实现在不修改直播应用的情况下,达到将主播终端120产生的直播内容返回给直播应用进行视频直播的目的。
具体实现中,第一驱动以及第二驱动可以按照云手机410以及云手机420的操作***接口标准进行编写,输入输出格式符合操作***接口标准即可,比如符合安卓操作***接口标准。这样,可以在不修改直播应用的情况下,达到将主播终端120产生的直播内容返回给直播应用进行视频直播的目的,使得本申请的基于云手机的直播方法普适性更高。
需要说明的,有的直播应用在向虚拟摄像头发送摄像头调用指令后,如果返回的数据不符合直播应用能够识别的格式,直播应用可能会出现报错问题。因此在本申请实施例中,云手机上的虚拟摄像头接收到直播平台发送的调用指令,在向直播平台返回由拉流地址拉取的直播内容之前,可以先将之前从拉流地址中拉取的直播内容进行格式转换,将其转换为直播应用能够识别的格式,比如主播终端摄像头采集的原格式音视频数据,然后再将其返回给直播平台,从而在不修改直播应用的情况下,达到将主播终端120产生的直播内容返回给直播应用进行视频直播的目的,使得本申请的基于云手机的直播方法普适性更高。
在步骤S440即云手机管理节点310将拉流地址设置于第一虚拟摄像头和第二虚拟摄像头之前,上述方法还包括以下步骤:云手机管理节点310根据一个用户输入的云手机创建信息在虚拟机资源池中创建内容分发服务节点320,并为内容分发服务节点320配置推流地址和拉流地址。可以理解的,云手机管理节点310是公有云中的资源管理服务器,可以在云手机资源池中创建云手机,也可以在虚拟机资源池中创建内容分发服务节点,使得一个用户账号和一个内容分发服务节点一一对应,多个用户之间的直播流量不会产生冲突, 避免直播卡顿情况的出现。并且,云手机和内容分发服务节点均为虚拟资源,成本较低。
在一实施例中,在步骤S440之后,即云手机管理节点310在创建好内容分发服务节点320、云手机410以及云手机420之后,可以生成一个绑定信息,该绑定信息包括创建好的内容分发服务节点320的推流地址、拉流地址、云手机410、云手机420的地址信息、主播终端120的地址信息等等,云手机管理节点310还以将上述绑定信息发送给创建好的内容分发服务节点320,使得内容分发服务节点320在步骤S310接收到主播终端120发送的直播内容时,可以根据该绑定信息确定从推流地址中拉取的直播内容是否来自绑定信息中的主播终端120,避免了将直播内容被其他主播用户的云手机拉流的可能性,提高数据传输的安全性。并且,内容分发服务节点310还可以根据绑定信息中的云手机地址,将控制流发送至各个云手机,还可以根据绑定信息中各个云手机的码率需求,对直播内容进行转码,使得本申请提供的基于云手机的视频直播方法可以适用于各种直播平台,普适性更好。
为便于理解本申请实施例所提方案的有益效果,示例性的,以主播通过主播终端120上的云手机应用(以云手机应用命名为“云直播”为例),创建云手机410和云手机420,并在云手机410上安装第一直播应用412,云手机420上安装第二直播应用422为例,介绍上述步骤S410-步骤S430过程中,用户操作主播终端120进行云手机创建的过程中,一些示例性的图形用户界面。
图5示例性示出了主播终端120上的用于展示主播终端120安装的应用程序的示例性用户界面10。
用户界面10可包括:状态栏201,日历指示符202,天气指示符203,具有常用应用程序图标的托盘204,导航栏205,以及其他应用程序图标。其中:
状态栏201可包括:移动通信信号(又可称为蜂窝信号)的一个或多个信号强度指示符201A、无线高保真(wireless fidelity,Wi-Fi)信号的一个或多个信号强度指示符201C,电池状态指示符201D、时间指示符201E。
日历指示符202可用于指示当前时间,例如日期、星期几、时分信息等。
天气指示符203可用于指示天气类型,例如多云转晴、小雨等,还可以用于指示气温等信息。
具有常用应用程序图标的托盘204可展示:电话图标204A、联系人图标204B、短信图标204C、相机图标204D。
导航栏205可包括:返回键205A、主屏幕键205B、多任务键205C等***导航键。当检测到用户点击返回键205A时,主播终端120可显示当前页面的上一个页面。当检测到用户点击主屏幕键205B时,主播终端120可显示主界面。当检测到用户点击多任务键205C时,主播终端120可显示用户最近打开的任务。各导航键的命名还可以为其他,本申请对此不做限制。不限于虚拟按键,导航栏205中的各导航键也可以实现为物理按键。
其他应用程序图标可例如:互传的图标206、图库的图标207、音乐的图标208、应用的图标209、邮箱的图标210、云直播的图标211、备忘录的图标212、设置的图标213。用户界面10还可包括页面指示符214。其他应用程序图标可分布在多个页面,页面指示符216可用于指示用户当前浏览的是哪一个页面中的应用程序。用户可以左右滑动其他应用程序图标的区域,来浏览其他页面中的应用程序图标。
在一些实施例中,图5示例性所示的用户界面10可以为主界面(Home screen)。可以理解的是,图5仅仅示例性示出了主播终端120上的用户界面,不应构成对本申请实施例的限定。
示例性的,如图6所示,用户可点击用户界面10上云直播的图标211,主播终端120检测到上述用户操作,响应于上述用户操作,主播终端120显示云直播的用户主界面11。
用户界面11可包括:应用程序标题栏301,控件302,搜索框303,常用控件的托盘304,以及多个直播显示框,其中:
应用程序标题栏301可用于指示当前页面用于展示主播终端120的云直播的界面。应用程序标题栏301的表现形式可以为文本信息、图标或其他形式。
控件302可接收用户操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可以显示登录或切换云直播账号的页面。
搜索框303可用于根据用户输入的字符,搜索与该字符匹配的设置项。
常用控件的托盘304可展示:首页控件图标304A,推荐控件图标304B,开始直播控件图标304C,聊天控件图标304D,我的控件图标304E。其中,上述控件图标均可接受用户操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可显示响应的页面,具体地,首页控件图标304A可用于显示云直播的首页,推荐控件图标304B可用于显示为用户推荐的页面,开始直播控件图标304C可用户显示用户开始直播的页面,聊天控件图标304D可用于显示用户的聊天页面,我的控件图标304E可用于显示账号中心页面。
多个直播显示框可例如:直播显示框305和直播显示框306,直播显示框用于显示该直播间正在直播的视频画面或者直播间的封面。
可以理解的是,图6仅仅示例性示出了主播终端120上的云直播应用的界面,不应构成对本申请实施例的限定。
示例性的,如图7所示,用户可点击常用控件的托盘304中,我的控件图标304E,主播终端120检测到该用户操作,响应于该用户操作,主播终端120可以显示如图7所示的云直播账号中心的用户界面12。应理解,图7显示的是用户已登录状态下的账号中心的用户界面。如果用户是未登录用户或者未注册用户,主播终端120将显示其他页面以供用户进行注册和登录,这里不展开赘述。
用户界面12可包括:返回控件801,会员中心802,账号803,头像804,退出控件811以及多个条目。其中,
返回控件801可接收用户操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可以退出该账号中心的用户界面12,显示用户界面12的上一用户界面,例如用户界面11。
会员中心802可接收用户操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可以显示会员中心的用户界面。
退出控件811可接收用户操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可以退出当前的云直播账号。
多个条目可例如:云手机创建条目805,账号与安全条目806,我的钱包条目807,我的收藏条目808,消息中心条目809以及设置条目810。其中,上述多个条目均可接收用户 操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可显示响应的页面,比如云手机创建条目805可显示用户界面13。
可以理解的是,图7仅仅示例性示出了主播终端120上的账号中心的用户界面,不应构成对本申请实施例的限定。
示例性的,如图8所示,用户可点击云手机创建条目,开始创建云手机,主播终端120检测到该用户操作,响应于该用户操作,主播终端120可以显示如图8所示的云手机创建的用户界面13。
用户界面13可包括:多个云手机规格配置子界面以及新建控件905,其中,
新建控件905用于接收用户操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可以在用户界面13上新增一个云手机规格配置子界面,比如云手机3规格配置子界面。
多个云手机规格配置子界面可例如:云手机410规格配置子界面901以及云手机420规格配置子界面903。其中,上述云手机规格配置子界面包括多个输入框和多个创建控件,该输入框用于接收用户输入的规格参数,例如处理器规格,内存规格,操作***,分辨率,部署应用和是否配置摄像头等等,还可以包括其他规格参数,本申请不做具体限定。创建控件用于接收用户的操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可以创建云手机规格配置子界面中所设定的规格的云手机。
具体地,用户可以点击云手机410规格配置子界面901中处理器规格对应的输入框,输入所需创建的云手机410的处理器规格,比如图8所示的2核处理器,用户可以点击操作***对应的输入框,输入所需创建的云手机410的操作***类型,比如图8的安卓操作***,用户可以点击部署应用对应的输入框,输入所需创建的云手机410上部署的应用为第一直播应用412,同理可以对其他规格对应的输入框进行输入,这里不展开赘述。输入完毕后,用户可以点击每个云手机规格配置子界面上的点击创建控件,进行云手机的创建。
可以理解的,用户根据创建需求对云手机410规格配置子界面901中各个输入框进行了输入,对云手机420规格配置子界面902中各个输入框进行了输入,并点击创建控件902和创建控件904后,该云手机应用(即云直播)将会生成前述内容中的用户的云手机创建信息,该云手机创建信息将由主播终端120发送到云手机管理节点310处(即图4实施例的步骤S410),云手机管理节点310可以根据云手机创建信息,在云手机资源池中创建云手机410和云手机420(即图4实施例的步骤S420),其中,云手机410设置有第一直播应用和第一虚拟摄像头,云手机420设置有第二直播应用和第二虚拟摄像头。接着,云手机管理节点310可以将推流地址发送至主播终端120,推流地址为主播终端120发送的直播内容的目的地址(即图4实施例的步骤S430)。最后,云手机管理节点310将拉流地址设置于第一虚拟摄像头和第二虚拟摄像头,该拉流地址用于提供直播内容以供第一虚拟摄像头和第二虚拟摄像头拉取(即图4实施例的步骤S440)。
具体实现中,云手机管理节点310根据云手机创建信息在云手机资源池创建云手机410和云手机420之后,还将云手机410设置第一驱动,云手机420设置第二驱动,当直播应用向云手机的虚拟摄像头发送摄像头调用直流时,每个云手机的虚拟摄像头可以将从上述拉流地址拉取到直播内容发送给直播应用,以供直播应用进将直播内容发送给对应的直播 平台,从而实现一个主播终端120在多个直播平台的直播。具体可以参考前述内容中图4实施例描述的云手机的直播配置方法,这里不展开赘述。
可以理解的是,图8仅仅示例性示出了主播终端120上的云手机创建的用户界面13,不应构成对本申请实施例的限定。
示例性的,如图9所示,用户点击创建控件后,主播终端120检测到该用户操作,响应于该用户操作,将用户的云手机创建信息发送给云手机管理节点310,云手机管理节点310执行图5实施例中描述的云手机的直播配置方法后,主播终端120可以显示如图9所示的云手机创建成功的用户界面14。应理解,如果该云手机服务是付费服务,用户点击创建控件后,主播终端120还可以先显示付款页面以供用户进行付款,在付款成功的情况下显示用户界面14,本申请不作具体限定。
用户界面14可包括:创建成功图标1001以及多个云手机显示子界面。其中,
创建成功图标1001用于提醒用户云手机创建成功。
多个云手机显示子界面用于显示用户当前已创建的云手机的部分信息,多个云手机显示子界面可例如:云手机410的显示子界面1002以及云手机420的显示子界面1003。每个云手机显示子界面可以包括配置控件、关机控件、连接控件以及重启控件,其中,
配置控件(例如配置控件1002A和配置控件1003A)用于对云手机进行重新规格配置。
关机控件(例如关机控件1002B和关机控件1003B)用于对云手机进行关闭。
连接控件(例如连接控件1002C和连接控件1003C)用于进入云手机的用户界面,进如第一直播应用412的用户界面进行设置,比如登录第一直播应用412的账号等,本申请不展开赘述。
重启控件(例如连接控件1002D和连接控件1003D)用于对云手机进行重启。
应理解,图8-图9仅仅示例性示出了主播终端120上的云手机创建用户界面13以及云手机创建成功的用户界面14,不应构成对本申请实施例的限定。
需要说明的,不限于上述图5-图9列出的创建云手机的用户操作,在具体实现中还可以有其他的用户操作可创建云手机,本申请实施例对此不作限定。
综上可知,通过上述图5-图9的用户操作,主播可以将直播的需求(比如创建几个云手机,部署什么直播应用等等)输入至主播终端120的云手机应用中,主播终端120将用户需求打包成云手机创建信息后,可以将云手机创建信息发送给云手机管理节点130,使得云手机管理节点310在主播直播前根据直播需求创建多个云手机,并在每一个云手机上部署相应的直播平台,并为每一个云手机设置内容分发服务节点320的拉流地址,当主播开始直播后,内容分发服务节点320将接收到的主播终端120产生的直播内容关联至自己的拉流地址,以供各个云手机从拉流地址中拉取直播内容,并将获取到的直播内容分别发送给对应的直播平台进行视频直播,使得主播只需要使用一个安装有云手机应用的主播终端120,即可实现多个平台同时直播,进而解决了多平台直播***成本高、互动效果差以及容易出现卡顿的情况。
下面结合图10对本申请提供的基于云手机的直播方法进行解释说明。如图5所示,本申请提供的基于云手机的直播方法包括以下步骤:
S310:内容分发服务节点320接收主播终端120向推流地址发送的直播内容,并将直播内容关联至拉流地址,其中,直播内容是由主播终端120产生的。
直播内容包括视频流和音频流,直播终端的摄像头采集关于主播的视频流,直播终端的麦克风采集关于主播的音频流,直播终端将视频流和音频流合成为直播内容,该方案尤其适用于主播现场表演的场景。
在其他实施例中,直播内容还可以包括另外一种音视频流,该音视频流结合了主播终端运行应用时产生的音视频流和麦克风采集的由主播旁述产生的音频流的音视频流,该方案尤其适用于在线游戏直播,在线课堂,设计软件教学等场景。
需要说明的,推流地址和拉流地址为内容分发服务节点320的地址,拉流地址用以供云手机410以及云手机420从该拉流地址拉取直播内容,推流地址用以供主播终端120向内容分发服务节点320发送直播内容。具体实现中,推流地址以及拉流地址可以包括公网IP地址、端口号以及URL,举例来说,推流地址可以是rtsp://10.0.10.1:554/live1,其中,10.0.10.1可以是内容分发服务节点320的公网IP地址,554可以是端口号,/live1为直播内容存放在服务器文件***中的目录URL;拉流地址可以是rtsp://10.0.10.1:554/live2,其中,10.0.10.1可以是内容分发服务节点320的公网IP地址,554可以是端口号,/live2为直播内容存放在服务器文件***中的目录URL。当然,推流地址和拉流地址还可以是能够用来在网络中寻址的其他形式的网络地址,本申请不作具体限定。
具体实现中,内容分发服务节点320将直播内容关联至内容分发服务节点320的拉流地址可以通过多种通信协议来实现,比如前述内容中的RTMP、HLS、WebRTC协议等等,还可以包括其他能够实现流媒体与服务器之间进行音视频和数据通信的协议,本申请不作具体限定。
S320:云手机410的第一虚拟摄像头从拉流地址拉取直播内容。其中,该拉流地址是在云手机创建阶段由云手机管理节点310设置于云手机410的第一虚拟摄像头,云手机创建阶段的步骤流程可以参考步骤S410-步骤S430以及图4-图9实施例的详细描述。并且,第一虚拟摄像头从拉流地址拉取直播内容的过程可以通过多种通信协议来实现,比如前述内容中的RTMP协议、HLS协议、WebRTC协议等等,还可以包括其他能够实现流媒体与服务器之间进行音视频和数据通信的协议,本申请不作具体限定。
S330:云手机410的第一直播应用从第一虚拟摄像头获取直播内容,并将直播内容发送至第一直播平台。
具体实现中,第一直播应用可以向第一虚拟摄像头发送第一摄像头调用申请,然后第一虚拟摄像头向第一直播应用返回从拉流地址拉取的直播内容,使得每一个云手机上的直播应用都可以拉取到主播的直播内容,从而实现了主播通过一个主播终端120进行多平台直播的目的。其中,第一直播应用向第一直播平台发送该直播内容的方式可以是:将直播内容推送到第一直播平台的推流地址,使得第一直播平台可以从该推流地址中获取该直播内容,具体可以参考图1实施例中步骤2的描述,这里不再展开赘述。
S340:第二虚拟摄像头从拉流地址拉取直播内容。具体可以参考上述步骤S320,这里不展开赘述。
S350:第二直播应用从第二虚拟摄像头获取直播内容,并将直播内容发送至第二直播平台。具体可以参考上述步骤S330,这里不展开赘述。
需要说明的,步骤S320-步骤S330以及步骤S340-步骤S350可以是同时进行的,也可以是不同时进行的,本申请不作具体限定。
在一实施例中,上述方法还包括以下步骤:内容分发服务节点接收该主播终端向推流地址发送的控制流,并将该控制流分别发送至第一云手机和第二云手机,其中,控制流可以是指令流,用于控制主播终端前后置摄像头的切换,摄像头调焦、对比度、亮度等。
在一些情况下,直播应用为第三方的直播平台提供,直播应用在运行时若不能接收到摄像头发送的控制流,有可能会认为摄像头发生故障,直播应用可能会向操作***报错或不能正常运行,但是云手机所能提供的摄像头由于是虚拟摄像头,虚拟摄像头无法向直播应用提供控制流,从而使得直播应用报错或不能正常运行,实施上述实现方式,主播终端可以将本机摄像头的控制流发送给内容分发服务节点,内容分发服务节点将控制流发送至每个云手机的虚拟摄像头,虚拟摄像头可以向直播应用返回主播终端的控制流,从而使得云手机的虚拟摄像头可以向直播应用发送针对摄像头的控制流,从而保证直播应用正常运行。由于直播应用一般为第三方的直播平台提供,而本申请的视频直播方法无需修改直播应用,因此针对第三方的直播平台具有普遍适用性。
具体实现中,主播终端120上的云手机应用可以对摄像头采集的视频数据以及麦克风采集的音频数据进行编码后封装成直播内容,将直播内容发送到拉流地址供云手机410和云手机420拉取,然后将控制指令进行编码后封装成控制流,根据云手机410和云手机420的网络地址,将控制流直接发送给云手机410和云手机420,从而避免了个别直播平台应用需要在获得摄像头控制权限的情况下才能进行视频直播情况的出现,使得本申请提供的基于云手机的直播方法能够有更好的普适性,适用于更多的直播平台。其中,直播内容和控制流的发送顺序可以是同时或先后进行的,本申请不做具体限定。并且,云手机410和云手机420的网络地址可以是在云手机管理节点310创建好云手机410和云手机420之后,创建内容分发服务节点320时存储于该内容分发服务节点320的绑定信息中,绑定信息的描述可以参考前述图4实施例中的内容,这里不重复赘述。
在一实施例中,内容分发服务节点320从拉流地址拉取到主播终端发送的直播内容和控制流之后,还可以根据各个云手机的码率需求对直播内容进行二次转码,比如云手机410上的第一直播应用需要码率A的直播内容,云手机420的第二直播应用需要码率B的直播内容,此时内容分发服务节点320还可以根据各个云手机的码率需求,对直播内容进行二次转码,获得码率A的直播内容和码率B的直播内容,并将两种码率的直播内容全部推流到拉流地址,以供云手机410的第一虚拟摄像头从该拉流地址拉取码率A的直播内容,云手机420的第二虚拟摄像头从该拉流地址拉取码率B的直播内容,使得本申请提供的基于云手机的直播方法能够适用于各种***率需求的直播平台,方案的普适性更强。其中,各个云手机的码率需求可以是云手机管理节点310创建云手机410和云手机420之后,创建内容分发服务节点320时存储于该内容分发服务节点320的的绑定信息中。
为了便于理解本申请实施例所提方案的有益效果,仍以图5-图9实施例描述的用户操作步骤为例,主播通过主播终端120上的云手机应用(以云手机应用命名为“云直播”为 例),创建云手机410和云手机420,并在云手机410上安装第一直播应用412,云手机420上安装第二直播应用422之后,开始多平台视频直播。下面介绍上述步骤S310-步骤S340的过程中,用户开始直播后一些示例性的图形用户界面。
用户可以返回用户界面11开始视频直播,具体可以通过如图6实施例描述方式,点击云直播的图标211,使得主播终端120显示用户界面11,也可以在图9所示的用户界面14处通过点击左上角的返回控件801返回当前用户界面的上一用户界面,直至返回用户界面11。用户点击用户界面11中的开始直播控件304C,开始多平台视频直播。主播终端120检测到该用户操作,响应于该用户操作,主播终端120可以显示如图11所示的正在直播的用户界面15。
用户界面15包括直播状态栏1101,云手机状态栏1102,缩小控件1103,直播窗口1104,聊天窗口1105以及常用控件托盘1106,其中,
直播状态栏1101用于显示用户的直播状态,包括各个平台的直播状态,比如图11所示的正在直播平台1直播,正在直播平台2直播,直播状态栏1101的表现形式可以为文本信息、图标或其他形式,本申请不作具体限定。
云手机状态栏1102用于显示用户的云手机运行状态,比如图11所示的云手机410正在运行,云手机420正在运行,直播状态栏1101的表现形式可以为文本信息、图标或其他形式,本申请不作具体限定。
缩小控件1103用于接收用户操作(例如触摸操作),响应于检测到的该用户操作,主播终端120可以将云直播的界面缩小,以供用户进行其他操作,比如打开邮箱查阅新邮件。
直播窗口1104用于显示直播内容。
聊天窗口1105用于显示多个平台用户的聊天记录。
常用控件托盘1106包括多个常用的控件,比如美颜控件1106A,结束直播控件1106B以及切换控件1106C。其中,美颜控件1106A用于美化直播画面,结束直播控件1106B用于结束当前直播,切换控件1106C用于切换前后置摄像头。
应理解,图11仅仅示例性示出了主播终端120上的正在直播的用户界面15,不应构成对本申请实施例的限定。
需要说明的,不限于上述图11列出的开始多平台直播的用户操作,在具体实现中还可以有其他的用户操作可开始多平台直播,本申请实施例对此不作限定。
可以理解的,参考前述内容可知,当用户点击用户界面11中的开始直播控件304C后,主播终端将会向云手机管理节点310发送由主播终端120产生的直播内容,具体地,主播终端可以根据之前云手机管理节点310发送的内容分发服务节点320的推流地址,将直播内容发送给内容分发服务节点320,使得内容分发服务节点320将直播内容发送到拉流地址,以供第一虚拟摄像头和第二虚拟摄像头从该拉流地址拉取直播内容。
当用户点击用户界面11中的开始直播控件304C后,主播终端还会将会向云手机管理节点310发送直播启动命令,使得云手机管理节点310根据该直播命令启动云手机410中的直播应用1和云手机420中的直播应用2,其中,直播应用1启动时产生第一摄像头调用指令,直播应用2启动时产生第二摄像头调用指令。接着,直播应用1向第一虚拟摄像头发送第一摄像头调用指令,第一虚拟摄像头中的第一驱动可以向直播应用1返回之前从 拉流地址拉取的直播内容,使得直播应用1可以获得主播终端120产生的直播内容,完成第一直播平台的视频直播,同理,可以完成第二直播平台的视频直播。
综上可知,本申请实施例通过的云手机的直播方法,使得用户只需要在直播前对所需的云手机进行创建,绑定直播平台之后,用户可以通过非常简单便捷的操作即可开始多平台直播,无需购买新的主播终端以服务不同的直播平台,取而代之以云手机实现,而云手机的租用价格比主播终端的购买价格低,可解决主播用户进行多平台直播时需购买多个主播终端而造成成本较高的问题,并且在直播过程中,仅需采用一台主播终端产生的直播内容并发送至内容分发服务节点320,通过内容分发服务节点320将直播内容分发到与不同的直播平台连接的至少两个云手机,使得不同的直播平台可从对应的云手机中获取到相同的直播内容进行视频直播,可提高主播与不同平台观众的互动效果,且直播过程中仅需上传一路直播内容,占用的网络带宽相对于多路直播内容而言较低,可有效解决直播卡顿问题。
上述详细阐述了本申请实施例的方法,为了便于更好的实施本申请实施例上述方案,相应地,下面还提供用于配合实施上述方案的相关设备。
图12是本申请提供的一种云手机管理节点600的结构示意图,该云手机管理节点600可以是前述内容中的云手机管理节点310。如图12所示,本申请提供的云手机管理节点600可以包括:
接收单元610,用于接收主播终端120发送的云手机创建信息,云手机创建信息包括至少两个云手机的规格信息;
创建单元620,用于根据云手机创建信息创建至少两个云手机,其中至少两个云手机与不同的直播平台连接;
发送单元630,用于将推流地址发送至主播终端120,推流地址为主播终端120产生的直播内容的目的地址;
设置单元640,用于将拉流地址设置于至少两个云手机,拉流地址用于提供直播内容以供至少两个云手机拉取。
在一实施例中,创建单元620还用于在接收单元610接收主播终端发送的云手机创建信息之后,创建内容分发服务节点320,并为内容分发服务节点320设置推流地址和拉流地址。
在一实施例中,云手机创建信息包括第一云手机的规格信息和第二云手机的规格信息,第一云手机的规格信息包括需设置在第一云手机的第一直播应用的信息和需设置在第一云手机中的第一虚拟摄像头的信息,第二云手机的规格信息包括需设置在第二云手机的第二直播应用的信息和需设置在第二云手机的第二虚拟摄像头的信息;创建单元620用于根据云手机创建信息在云手机资源池创建第一云手机和第二云手机,其中,第一云手机设置有第一直播应用和第一虚拟摄像头,第二云手机设置有第二直播应用和第二虚拟摄像头,第一直播应用和第二直播应用服务于不同的直播平台;设置单元640用于将拉流地址设置于第一云手机的第一虚拟摄像头和第二云手机的第二虚拟摄像头。
在一实施例中,设置单元640用于为第一云手机设置第一驱动,并为第二云手机设置 第二驱动,其中,第一驱动用于控制第一虚拟摄像头在接收到第一直播应用产生的第一摄像头调用指令时向第一直播应用发送第一虚拟摄像头从拉流地址拉取的直播内容,第二驱动用于控制第二虚拟摄像头在接收到第二直播应用产生的第二摄像头调用指令时向第二直播应用发送第二虚拟摄像头从拉流地址拉取的直播内容。
在一实施例中,节点还包括启动单元650,接收单元610还用于接收主播终端120发送的直播启动命令;启动单元650用于根据直播启动命令启动云手机410中的第一直播应用和云手机420中的第二直播应用,其中,第一直播应用启动后产生第一摄像头调用指令,第二直播应用启动时产生第二摄像头调用指令。
应理解,图12所示的云手机管理节点600的内部的单元模块也可以有多种划分,各个模块可以是软件模块,也可以是硬件模块,也可以是部分软件模块部分硬件模块,本申请不对其进行限制。图12是一种示例性的划分方式,本申请不作具体限定。
云手机管理节点600根据云手机创建信息创建第一云手机和第二云手机之后,将拉流地址设置于第一云手机的第一虚拟摄像头和第二云手机的第二虚拟摄像头,这样,当主播开始直播后,主播终端120将直播内容推流至内容分发服务节点320的推流地址,内容分发服务节点320将直播内容关联至拉流地址,此时第一虚拟摄像头、第二虚拟摄像头可以从该拉流地址拉取直播内容,使得第一云手机和第二云手机都可以获取到主播终端120发送的直播内容,从而实现多个云手机共用主播终端摄像头采集的直播内容进行直播的目的,进而解决了多平台直播***成本高、互动效果差以及容易出现卡顿的情况。
图13为本申请实施例提供的一种计算设备900的结构示意图。其中,所述计算设备900可以是图2-图11实施例中的云手机管理节点310和图12实施例中的云手机管理节点600。如图13所示,计算设备900包括:处理器910、通信接口920以及存储器930。其中,处理器910、通信接口920以及存储器930可以通过内部总线940相互连接,也可通过无线传输等其他手段实现通信。本申请实施例以通过总线940连接为例,总线940可以是外设部件互连标准(Peripheral Component Interconnect,PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture,EISA)总线等。所述总线940可以分为地址总线、数据总线、控制总线等。为便于表示,图13中仅用一条粗线表示,但并不表示仅有一根总线或一种类型的总线。
所述处理器910可以由至少一个通用处理器构成,例如中央处理器(Central Processing Unit,CPU),或者CPU和硬件芯片的组合。上述硬件芯片可以是专用集成电路(Application-Specific Integrated Circuit,ASIC)、可编程逻辑器件(Programmable Logic Device,PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(Complex Programmable Logic Device,CPLD)、现场可编程逻辑门阵列(Field-Programmable Gate Array,FPGA)、通用阵列逻辑(Generic Array Logic,GAL)或其任意组合。处理器910执行各种类型的数字存储指令,例如存储在存储器930中的软件或者固件程序,它能使计算设备900提供较宽的多种服务。
所述存储器930用于存储程序代码,并由处理器910来控制执行,以执行上述图2-图11中任一实施例中云手机管理节点310的处理步骤。所述程序代码中可以包括一个或多个 软件模块。这一个或多个软件模块可以为图12所示实施例中提供的软件模块,如接收单元,创建单元,发送单元以及设置单元,其中,接收单元可以用于接收主播终端120发送的云手机创建信息,创建单元可以用于根据该云手机创建信息创建至少两个云手机,发送单元可以用于将内容分发服务节点的推流地址发送至主播终端,设置单元可以用于将内容分发服务节点的拉流地址设置于至少两个云手机中,具体可用于执行前述方法的S410-步骤S440及其可选步骤,还可以用于执行图2-图12实施例描述的其他由云手机管理节点310执行的步骤,这里不再进行赘述。
需要说明的是,本实施例可以是通用的物理服务器实现的,例如,ARM服务器或者X86服务器,也可以是基于通用的物理服务器结合NFV技术实现的虚拟机实现的,所述虚拟机指通过 软件模拟的具有完整 硬件***功能的、运行在一个完全 隔离环境中的完整 计算机系 ,本申请不作具体限定。
所述存储器930可以包括易失性存储器(Volatile Memory),例如随机存取存储器(Random Access Memory,RAM);存储器1030也可以包括非易失性存储器(Non-Volatile Memory),例如只读存储器(Read-Only Memory,ROM)、快闪存储器(Flash Memory)、硬盘(Hard Disk Drive,HDD)或固态硬盘(Solid-State Drive,SSD);存储器930还可以包括上述种类的组合。存储器930可以存储有程序代码,具体可以包括用于执行图2-图11实施例描述的其他步骤的程序代码,这里不再进行赘述。
通信接口920可以为有线接口(例如以太网接口),可以为内部接口(例如高速串行计算机扩展总线(Peripheral Component Interconnect express,PCIe)总线接口)、有线接口(例如以太网接口)或无线接口(例如蜂窝网络接口或使用无线局域网接口),用于与与其他设备或模块进行通信。
需要说明的,图13仅仅是本申请实施例的一种可能的实现方式,实际应用中,所述计算设备还可以包括更多或更少的部件,这里不作限制。关于本申请实施例中未示出或未描述的内容,可参见前述图2-图11所述实施例中的相关阐述,这里不再赘述。
应理解,图13所示的计算设备还可以是至少一个服务器构成的计算机集群,本申请不作具体限定。
本申请实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,当其在处理器上运行时,图2-图11所示的方法流程得以实现。
本申请实施例还提供一种计算机程序产品,当所述计算机程序产品在处理器上运行时,图2-图11所示的方法流程得以实现。
上述实施例,可以全部或部分地通过软件、硬件、固件或其他任意组合来实现。当使用软件实现时,上述实施例可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括至少一个计算机指令。在计算机上加载或执行所述计算机程序指令时,全部或部分地产生按照本发明实施例所述的流程或功能。所述计算机可以为通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(Digital Subscriber Line,DSL))或无线(例如红外、无线、微波等) 方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含至少一个可用介质集合的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如,软盘、硬盘、磁带)、光介质(例如,高密度数字视频光盘(Digital Video Disc,DVD)、或者半导体介质。半导体介质可以是SSD。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到各种等效的修改或替换,这些修改或替换都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。

Claims (27)

  1. 一种基于云手机的直播方法,其特征在于,所述方法应用于直播***,所述直播***包括内容分发服务节点和至少两个云手机,所述至少两个云手机分别与不同的直播平台连接,所述内容分发服务节点设置有推流地址和拉流地址,所述方法包括:
    所述内容分发服务节点接收主播终端向所述推流地址发送的直播内容,并将所述直播内容关联至所述拉流地址,其中,所述直播内容是由所述主播终端产生;
    所述至少两个云手机分别从所述拉流地址拉取所述直播内容,并将所述直播内容发送至不同的直播平台。
  2. 根据权利要求1所述的方法,其特征在于,所述直播***还包括云手机管理节点,所述内容分发服务节点接收主播终端向所述推流地址发送的直播内容之前,所述方法包括:
    所述云手机管理节点接收所述主播终端发送的云手机创建信息,所述云手机创建信息包括所述至少两个云手机的规格信息;
    所述云手机管理节点根据所述云手机创建信息创建所述至少两个云手机;
    所述云手机管理节点将所述推流地址发送至所述主播终端;
    所述云手机管理节点将所述拉流地址设置于所述至少两个云手机。
  3. 根据权利要求1或2所述的方法,其特征在于,所述云手机管理节点接收所述主播终端发送的云手机创建信息之后,所述方法还包括:
    所述云手机管理节点创建所述内容分发服务节点,并为所述内容分发服务节点设置所述推流地址和所述拉流地址。
  4. 根据权利要求2或3所述的方法,其特征在于,所述云手机创建信息包括第一云手机的规格信息和第二云手机的规格信息,所述第一云手机的规格信息包括第一直播应用的信息和第一虚拟摄像头的信息,所述第二云手机的规格信息包括第二直播应用的信息和第二虚拟摄像头的信息;
    所述云手机管理节点根据所述云手机创建信息创建至少两个云手机,包括:
    所述云手机管理节点根据所述云手机创建信息在云手机资源池创建所述第一云手机和所述第二云手机,所述第一云手机设置有所述第一虚拟摄像头和所述第一直播应用,所述第二云手机设置有所述第二虚拟摄像头和所述第二直播应用,所述第一直播应用服务于第一直播平台,所述第二直播应用服务于第二直播平台,所述第一直播平台与所述第二直播平台是不同的直播平台;
    所述云手机管理节点将所述拉流地址设置于所述至少两个云手机,包括:
    所述云手机管理节点将所述拉流地址设置于所述第一虚拟摄像头和所述第二虚拟摄像头。
  5. 根据权利要求4所述的方法,其特征在于,所述云手机管理节点根据所述云手机创建信息在云手机资源池创建所述第一云手机和所述第二云手机之后,所述方法还包括:
    所述云手机管理节点为所述第一云手机设置第一驱动,其中,所述第一驱动用于控制所述第一虚拟摄像头在接收到所述第一直播应用产生的第一摄像头调用指令的情况下向所述第一直播应用发送所述第一虚拟摄像头从所述拉流地址拉取的所述直播内容;
    所述云手机管理节点为所述第二云手机设置第二驱动,其中,所述第二驱动用于控制 所述第二虚拟摄像头在接收到所述第二直播应用产生的第二摄像头调用指令的情况下向所述第二直播应用发送所述第二虚拟摄像头从所述拉流地址拉取的所述直播内容。
  6. 根据权利要求5所述的方法,其特征在于,所述方法还包括:
    所述云手机管理节点接收所述主播终端发送的直播启动命令;
    所述云手机管理节点根据所述直播启动命令启动所述第一直播应用和所述第二直播应用,其中,所述第一直播应用启动后产生所述第一摄像头调用指令,所述第二直播应用启动后产生所述第二摄像头调用指令。
  7. 根据权利要求4至6任一项所述的方法,其特征在于,所述至少两个云手机分别从所述拉流地址拉取所述直播内容,并将所述直播内容发送至不同的直播平台,包括:
    所述第一虚拟摄像头从所述拉流地址拉取所述直播内容,所述第一直播应用从所述第一虚拟摄像头获取所述直播内容并将所述直播内容发送至所述第一直播平台;
    所述第二虚拟摄像头从所述拉流地址拉取所述直播内容,所述第二直播应用从所述第二虚拟摄像头获取所述直播内容并将所述直播内容发送至所述第二直播平台。
  8. 一种基于云手机的直播配置方法,其特征在于,包括:
    云手机管理节点接收主播终端发送的云手机创建信息,所述云手机创建信息包括至少两个云手机的规格信息;
    所述云手机管理节点根据所述云手机创建信息创建所述至少两个云手机,其中所述至少两个云手机与不同的直播平台连接;
    所述云手机管理节点将推流地址发送至所述主播终端,所述推流地址为所述主播终端产生的直播内容的目的地址;
    所述云手机管理节点将拉流地址设置于所述至少两个云手机,所述拉流地址用于提供所述直播内容以供所述至少两个云手机拉取。
  9. 根据权利要求8所述的方法,其特征在于,所述云手机管理节点接收所述主播终端发送的云手机创建信息之后,所述方法还包括:
    所述云手机管理节点创建内容分发服务节点,并为所述内容分发服务节点设置所述推流地址和所述拉流地址。
  10. 根据权利要求8或9所述的方法,其特征在于,所述云手机创建信息包括第一云手机的规格信息和第二云手机的规格信息,所述第一云手机的规格信息包括需设置在所述第一云手机中的第一直播应用的信息和需设置在所述第一云手机中的第一虚拟摄像头的信息,所述第二云手机的规格信息包括需设置在所述第二云手机中的第二直播应用的信息和需设置在所述第二云手机中的第二虚拟摄像头的信息,
    所述云手机管理节点根据所述云手机创建信息创建所述至少两个云手机,包括:
    所述云手机管理节点根据所述云手机创建信息在云手机资源池创建所述第一云手机和所述第二云手机,其中,所述第一云手机设置有所述第一直播应用和所述第一虚拟摄像头,所述第二云手机设置有所述第二直播应用和所述第二虚拟摄像头,所述第一直播应用和所述第二直播应用服务于不同的直播平台;
    所述云手机管理节点将拉流地址设置于所述至少两个云手机,包括:
    所述云手机管理节点将所述拉流地址设置于所述第一虚拟摄像头和所述第二虚拟摄像 头。
  11. 根据权利要求10所述的方法,其特征在于,所述云手机管理节点根据所述云手机创建信息在云手机资源池创建所述第一云手机和所述第二云手机之后,所述方法还包括:
    所述云手机管理节点为所述第一云手机设置第一驱动,其中,所述第一驱动用于控制所述第一虚拟摄像头在接收到所述第一直播应用产生的第一摄像头调用指令时向所述第一直播应用发送所述第一虚拟摄像头从所述拉流地址拉取的所述直播内容;
    所述云手机管理节点为所述第二云手机设置第二驱动,其中,所述第二驱动用于控制所述第二虚拟摄像头在接收到所述第二直播应用产生的第二摄像头调用指令时向所述第二直播应用发送所述第二虚拟摄像头从所述拉流地址拉取的所述直播内容。
  12. 根据权利要求11所述的方法,其特征在于,所述方法还包括:
    所述云手机管理节点接收所述主播终端发送的直播启动命令;
    所述云手机管理节点根据所述直播启动命令启动所述第一直播应用和所述第二直播应用,其中,所述第一直播应用启动后产生所述第一摄像头调用指令,所述第二直播应用启动时产生所述第二摄像头调用指令。
  13. 一种直播***,其特征在于,所述直播***包括内容分发服务节点和至少两个云手机,所述至少两个云手机分别与不同的直播平台连接,所述内容分发服务节点设置有推流地址和拉流地址,
    所述内容分发服务节点,用于接收主播终端向所述推流地址发送的直播内容,并将所述直播内容关联至所述拉流地址,其中,所述直播内容是由所述主播终端产生;
    所述至少两个云手机,用于分别从所述拉流地址拉取所述直播内容,并将所述直播内容发送至不同的直播平台。
  14. 根据权利要求13所述的***,其特征在于,所述***还包括云手机管理节点,
    所述云手机管理节点,还用于在所述内容分发服务节点接收主播终端向所述推流地址发送的直播内容之前,接收所述主播终端发送的云手机创建信息,所述云手机创建信息包括所述至少两个云手机的规格信息;
    所述云手机管理节点,还用于根据所述云手机创建信息创建所述至少两个云手机;
    所述云手机管理节点,还用于将所述推流地址发送至所述主播终端;
    所述云手机管理节点,还用于将所述拉流地址设置于所述至少两个云手机。
  15. 根据权利要求13或14所述的***,其特征在于,
    所述云手机管理节点,还用于在接收所述主播终端发送的云手机创建信息之后,创建所述内容分发服务节点,并为所述内容分发服务节点设置所述推流地址和所述拉流地址。
  16. 根据权利要求14或15所述的***,其特征在于,所述云手机创建信息包括第一云手机的规格信息和第二云手机的规格信息,所述第一云手机的规格信息包括第一直播应用的信息和第一虚拟摄像头的信息,所述第二云手机的规格信息包括第二直播应用的信息和第二虚拟摄像头的信息;
    所述云手机管理节点,用于根据所述云手机创建信息在云手机资源池创建所述第一云手机和所述第二云手机,所述第一云手机设置有所述第一虚拟摄像头和所述第一直播应用,所述第二云手机设置有所述第二虚拟摄像头和所述第二直播应用,所述第一直播应用服务 于第一直播平台,所述第二直播应用服务于第二直播平台,所述第一直播平台与所述第二直播平台是不同的直播平台;
    所述云手机管理节点,用于将所述拉流地址设置于所述第一虚拟摄像头和所述第二虚拟摄像头。
  17. 根据权利要求16所述的***,其特征在于,
    所述云手机管理节点,用于在根据所述云手机创建信息在云手机资源池创建所述第一云手机和所述第二云手机之后,为所述第一云手机设置第一驱动,为所述第二云手机设置第二驱动,其中,所述第一驱动用于控制所述第一虚拟摄像头在接收到所述第一直播应用产生的第一摄像头调用指令的情况下向所述第一直播应用发送所述第一虚拟摄像头从所述拉流地址拉取的所述直播内容,所述第二驱动用于控制所述第二虚拟摄像头在接收到所述第二直播应用产生的第二摄像头调用指令的情况下向所述第二直播应用发送所述第二虚拟摄像头从所述拉流地址拉取的所述直播内容。
  18. 根据权利要求17所述的***,其特征在于,
    所述云手机管理节点,用于接收所述主播终端发送的直播启动命令;
    所述云手机管理节点,用于根据所述直播启动命令启动所述第一直播应用和所述第二直播应用,其中,所述第一直播应用启动后产生所述第一摄像头调用指令,所述第二直播应用启动后产生所述第二摄像头调用指令。
  19. 根据权利要求16至18任一项所述的***,其特征在于,
    所述第一云手机的所述第一虚拟摄像头,用于从所述拉流地址拉取所述直播内容,所述第一直播应用用于从所述第一虚拟摄像头获取所述直播内容并将所述直播内容发送至所述第一直播平台;
    所述第二云手机的所述第二虚拟摄像头,用于从所述拉流地址拉取所述直播内容,所述第二直播应用用于从所述第二虚拟摄像头获取所述直播内容并将所述直播内容发送至所述第二直播平台。
  20. 一种云手机管理节点,其特征在于,包括:
    接收单元,用于接收主播终端发送的云手机创建信息,所述云手机创建信息包括至少两个云手机的规格信息;
    创建单元,用于根据所述云手机创建信息创建所述至少两个云手机,其中,所述至少两个云手机与不同的直播平台连接;
    发送单元,用于将推流地址发送至所述主播终端,所述推流地址为所述主播终端产生的直播内容的目的地址;
    设置单元,用于将拉流地址设置于所述至少两个云手机,所述拉流地址用于提供所述直播内容以供所述至少两个云手机拉取。
  21. 根据权利要求20所述的云手机管理节点,其特征在于,
    所述创建单元,还用于创建内容分发服务节点,并为所述内容分发服务节点设置所述推流地址和所述拉流地址。
  22. 根据权利要求20或21所述的云手机管理节点,其特征在于,所述云手机创建信 息包括第一云手机的规格信息和第二云手机的规格信息,所述第一云手机的规格信息包括需设置在所述第一云手机中的第一直播应用的信息和需设置在所述第一云手机中的第一虚拟摄像头的信息,所述第二云手机的规格信息包括需设置在所述第二云手机中的第二直播应用的信息和需设置在所述第二云手机中的第二虚拟摄像头的信息;
    所述创建单元,用于根据所述云手机创建信息在云手机资源池创建所述第一云手机和所述第二云手机,其中,所述第一云手机设置有所述第一直播应用和所述第一虚拟摄像头,所述第二云手机设置有所述第二直播应用和所述第二虚拟摄像头,所述第一直播应用和所述第二直播应用服务于不同的直播平台;
    所述设置单元,用于将所述拉流地址设置于所述第一虚拟摄像头和所述第二虚拟摄像头。
  23. 根据权利要求22所述的云手机管理节点,其特征在于,
    所述设置单元,用于为所述第一云手机设置第一驱动,并为所述第二云手机设置第二驱动,其中,所述第一驱动用于控制所述第一虚拟摄像头在接收到所述第一直播应用产生的第一摄像头调用指令时向所述第一直播应用发送所述第一虚拟摄像头从所述拉流地址拉取的所述直播内容,所述第二驱动用于控制所述第二虚拟摄像头在接收到所述第二直播应用产生的第二摄像头调用指令时向所述第二直播应用发送所述第二虚拟摄像头从所述拉流地址拉取的所述拉取的所述直播内容。
  24. 根据权利要求23所述的云手机管理节点,其特征在于,所述云手机管理节点还包括启动单元,
    所述接收单元,还用于接收所述主播终端发送的直播启动命令;
    所述启动单元,用于根据所述直播启动命令启动所述第一直播应用和所述第二直播应用,其中,所述第一直播应用启动后产生所述第一摄像头调用指令,所述第二直播应用启动时产生所述第二摄像头调用指令。
  25. 一种计算机可读存储介质,其特征在于,包括指令,当所述指令在计算设备上运行时,使得所述计算设备执行如权利要求8至12任一权利要求所述的方法。
  26. 一种计算设备,其特征在于,包括处理器和存储器,所述处理器执行所述存储器中的代码执行如权利要求8至12任一权利要求所述的方法。
  27. 一种计算机程序产品,其特征在于,包括计算机程序,当所述计算机程序被计算设备读取并执行时,使得所述计算设备执行如权利要求8至12任一权利要求所述的方法。
PCT/CN2021/081451 2020-03-20 2021-03-18 基于云手机的直播和配置方法以及相关装置和*** WO2021185302A1 (zh)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202010200449 2020-03-20
CN202010200449.8 2020-03-20
CN202010387298.1A CN113497945B (zh) 2020-03-20 2020-05-09 基于云手机的直播和配置方法以及相关装置和***
CN202010387298.1 2020-05-09

Publications (1)

Publication Number Publication Date
WO2021185302A1 true WO2021185302A1 (zh) 2021-09-23

Family

ID=77770159

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/081451 WO2021185302A1 (zh) 2020-03-20 2021-03-18 基于云手机的直播和配置方法以及相关装置和***

Country Status (1)

Country Link
WO (1) WO2021185302A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114095744A (zh) * 2021-11-16 2022-02-25 北京字跳网络技术有限公司 视频直播方法、装置、电子设备及可读存储介质
CN114143572A (zh) * 2021-12-09 2022-03-04 杭州网易云音乐科技有限公司 直播交互方法、装置、存储介质、电子设备
CN114157584A (zh) * 2021-12-01 2022-03-08 北京百度网讯科技有限公司 云***控方法、装置、电子设备和存储介质
CN114222195A (zh) * 2022-01-27 2022-03-22 北京百度网讯科技有限公司 一种直播推流方法、装置、电子设备和存储介质
CN114363387A (zh) * 2021-12-31 2022-04-15 北京沃东天骏信息技术有限公司 应用拉活方法、装置、电子设备及存储介质
CN114793225A (zh) * 2022-03-30 2022-07-26 广东悦伍纪网络技术有限公司 一种云手机与真机的数据通信方法及***
CN115022669A (zh) * 2022-05-31 2022-09-06 厦门蝉羽网络科技有限公司 一种基于信息处理的直播***及直播方法
CN115514914A (zh) * 2022-09-28 2022-12-23 深圳市拓普智造科技有限公司 一种多媒体远程视频***、方法及存储介质
CN116156009A (zh) * 2023-01-12 2023-05-23 杭州龙境科技有限公司 一种安卓云手机容器间共享显示服务的方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107005721A (zh) * 2016-11-22 2017-08-01 广州市百果园信息技术有限公司 直播间视频流推送控制方法及相应的服务器与移动终端
CN107294785A (zh) * 2017-07-11 2017-10-24 上海帝联信息科技股份有限公司 Cdn节点服务的自动部署方法及装置、计算机可读存储介质
CN107483812A (zh) * 2017-08-02 2017-12-15 深圳依偎控股有限公司 一种多平台并行直播的方法及装置
US20180160158A1 (en) * 2016-12-06 2018-06-07 Bing Liu Method and system for live stream broadcast and content monetization
CN109005415A (zh) * 2018-07-26 2018-12-14 阿里巴巴集团控股有限公司 一种网络直播控制方法、装置及***
CN109068179A (zh) * 2018-09-17 2018-12-21 珠海市筑巢科技有限公司 一种多平台直播方法、计算机装置及计算机可读存储介质
CN110012115A (zh) * 2019-05-06 2019-07-12 广州华多网络科技有限公司 直播间推送信息的更新方法和***
US20190246146A1 (en) * 2018-02-06 2019-08-08 PhenixP2P Inc. Simulating a local experience by live streaming sharable viewpoints of a live event

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107005721A (zh) * 2016-11-22 2017-08-01 广州市百果园信息技术有限公司 直播间视频流推送控制方法及相应的服务器与移动终端
US20180160158A1 (en) * 2016-12-06 2018-06-07 Bing Liu Method and system for live stream broadcast and content monetization
CN107294785A (zh) * 2017-07-11 2017-10-24 上海帝联信息科技股份有限公司 Cdn节点服务的自动部署方法及装置、计算机可读存储介质
CN107483812A (zh) * 2017-08-02 2017-12-15 深圳依偎控股有限公司 一种多平台并行直播的方法及装置
US20190246146A1 (en) * 2018-02-06 2019-08-08 PhenixP2P Inc. Simulating a local experience by live streaming sharable viewpoints of a live event
CN109005415A (zh) * 2018-07-26 2018-12-14 阿里巴巴集团控股有限公司 一种网络直播控制方法、装置及***
CN109068179A (zh) * 2018-09-17 2018-12-21 珠海市筑巢科技有限公司 一种多平台直播方法、计算机装置及计算机可读存储介质
CN110012115A (zh) * 2019-05-06 2019-07-12 广州华多网络科技有限公司 直播间推送信息的更新方法和***

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114095744B (zh) * 2021-11-16 2024-01-02 北京字跳网络技术有限公司 视频直播方法、装置、电子设备及可读存储介质
CN114095744A (zh) * 2021-11-16 2022-02-25 北京字跳网络技术有限公司 视频直播方法、装置、电子设备及可读存储介质
CN114157584A (zh) * 2021-12-01 2022-03-08 北京百度网讯科技有限公司 云***控方法、装置、电子设备和存储介质
CN114143572A (zh) * 2021-12-09 2022-03-04 杭州网易云音乐科技有限公司 直播交互方法、装置、存储介质、电子设备
CN114143572B (zh) * 2021-12-09 2024-05-31 杭州网易云音乐科技有限公司 直播交互方法、装置、存储介质、电子设备
CN114363387A (zh) * 2021-12-31 2022-04-15 北京沃东天骏信息技术有限公司 应用拉活方法、装置、电子设备及存储介质
CN114222195A (zh) * 2022-01-27 2022-03-22 北京百度网讯科技有限公司 一种直播推流方法、装置、电子设备和存储介质
CN114793225A (zh) * 2022-03-30 2022-07-26 广东悦伍纪网络技术有限公司 一种云手机与真机的数据通信方法及***
CN114793225B (zh) * 2022-03-30 2023-04-28 广东悦伍纪网络技术有限公司 一种云手机与真机的数据通信方法及***
CN115022669A (zh) * 2022-05-31 2022-09-06 厦门蝉羽网络科技有限公司 一种基于信息处理的直播***及直播方法
CN115022669B (zh) * 2022-05-31 2024-03-12 厦门蝉羽网络科技有限公司 一种基于信息处理的直播***及直播方法
CN115514914A (zh) * 2022-09-28 2022-12-23 深圳市拓普智造科技有限公司 一种多媒体远程视频***、方法及存储介质
CN116156009B (zh) * 2023-01-12 2023-10-20 杭州龙境科技有限公司 一种安卓云手机容器间共享显示服务的方法
CN116156009A (zh) * 2023-01-12 2023-05-23 杭州龙境科技有限公司 一种安卓云手机容器间共享显示服务的方法

Similar Documents

Publication Publication Date Title
WO2021185302A1 (zh) 基于云手机的直播和配置方法以及相关装置和***
CN113497945B (zh) 基于云手机的直播和配置方法以及相关装置和***
US11164220B2 (en) Information processing method, server, and computer storage medium
CN109168021B (zh) 一种推流的方法及装置
CN112073758B (zh) 一种云桌面投屏方法、装置、计算机设备、计算机可读存储介质及云桌面投屏交互***
US20070078953A1 (en) User interface widget unit sharing for application user interface distribution
CN111901695B (zh) 视频内容截取方法、装置和设备及计算机存储介质
US10863246B2 (en) Network services platform systems, methods, and apparatus
WO2018157743A1 (zh) 媒体数据处理方法、装置、***及存储介质
EP3614679A1 (en) Method for configuring video thumbnail, and system
US11689749B1 (en) Centralized streaming video composition
JP2021534606A (ja) デジタルコンテンツ消費の同期
CN105025320B (zh) 一种混合构架的可运营桌面***及其实现方法
CN113569089A (zh) 信息处理方法、装置、服务器、设备、***及存储介质
CN112565877A (zh) 投屏方法、***、电子设备及存储介质
CN112714341B (zh) 信息获取方法、云化机顶盒***、实体机顶盒及存储介质
CN110996118A (zh) 一种封面合成方法、装置、服务器以及存储介质
RU2667374C1 (ru) Система и способ для отображения рекламных материалов
US20230362460A1 (en) Dynamically generated interactive video content
KR102612580B1 (ko) 미디어 제공 서버, 트리거 영역을 통해 다른 컨텐츠로 전환하는 방법 및 컴퓨터 프로그램
CN114445131A (zh) 一种开机广告投放方法、播放方法及显示设备、服务器
CN113727125A (zh) 直播间的截图方法、装置、***、介质以及计算机设备
CN114915810A (zh) 一种媒资推送方法及智能终端
CN115243064B (zh) 一种直播控制方法、装置、设备和存储介质
CN116708867B (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: 21770436

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

Country of ref document: EP

Kind code of ref document: A1