Method and device for managing acquisition equipment, equipment and medium

Abstract

The invention provides a method, a device, equipment and a medium for managing acquisition equipment. In one method, in response to detecting that a target object accesses a live broadcast room in a live broadcast application, the type of the target object is determined. A platform type of a client device for running a live application is obtained. And based on the type of the target object and the platform type, utilizing a live broadcast management tool to manage acquisition equipment of the client equipment. According to the embodiment of the invention, the live broadcast management tool can package the core logic of the collection equipment management operation of the live broadcast room, so that the collection equipment of each target object can be managed in the live broadcast application in a more convenient and effective manner.

Description

Technical Field

[0001] Exemplary implementations of the present disclosure generally relate to device management, and more particularly to methods, apparatuses, devices, and computer-readable storage media for managing acquisition devices in live broadcast applications. Background Art

[0002] With the development of computer technology, live broadcast applications can now be provided on various platform types of client devices. Users can install live broadcast applications on their own client devices to watch live broadcasts and participate in the interaction between live broadcast rooms. However, since client devices have various platform types, developers have to use specific development languages ​​of various platform types to develop corresponding live broadcast applications. Specifically, for the management of acquisition devices in live broadcast applications, it is necessary to use a specific development language to write code in order to implement the specific process of acquisition device management. This leads to various wastes of resources in the development process, and it is therefore expected that acquisition device management can be implemented in a more convenient and effective manner. Summary of the invention

[0003] In a first aspect of the present disclosure, a method for managing acquisition devices is provided. In the method, in response to detecting that a target object accesses a live broadcast room in a live broadcast application, the type of the target object is determined. The platform type of a client device used to run the live broadcast application is obtained. Based on the type of the target object and the platform type, a live broadcast management tool is used to manage the acquisition devices of the client device.

[0004] In a second aspect of the present disclosure, a device for managing acquisition devices is provided. The device includes: a determination module configured to determine the type of a target object in response to detecting that the target object accesses a live broadcast room in a live broadcast application; an acquisition module configured to acquire the platform type of a client device for running the live broadcast application; and a management module configured to manage the acquisition devices of the client device using a live broadcast management tool based on the type and platform type of the target object.

[0005] In a third aspect of the present disclosure, an electronic device is provided. The electronic device includes: at least one processing unit; and at least one memory, the at least one memory is coupled to the at least one processing unit and stores instructions for execution by the at least one processing unit, and when the instructions are executed by the at least one processing unit, the electronic device executes the method according to the first aspect of the present disclosure.

[0006] In a fourth aspect of the present disclosure, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the processor implements the method according to the first aspect of the present disclosure.

[0007] It should be understood that the content described in this content section is not intended to limit the key features or important features of the implementation of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easy to understand through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In the following, in conjunction with the accompanying drawings and with reference to the following detailed description, the above and other features, advantages and aspects of various implementations of the present disclosure will become more apparent. In the accompanying drawings, the same or similar figure labels represent the same or similar elements, wherein:

[0009] Figure 1 A block diagram showing an environment of a live broadcast application according to an exemplary implementation of the present disclosure is shown;

[0010] Figure 2 A block diagram for managing acquisition devices in a live broadcast application according to some implementations of the present disclosure is shown;

[0011] Figure 3 A block diagram showing the structure of a live broadcast management tool according to some implementations of the present disclosure;

[0012] Figure 4 A block diagram showing management of acquisition devices according to various types of permissions of users according to some implementations of the present disclosure;

[0013] Figure 5 A block diagram showing type conversion of a user according to some implementations of the present disclosure;

[0014] Figure 6 A block diagram showing an interface for presenting media information according to some implementations of the present disclosure is shown;

[0015] Figure 7 A block diagram showing state transitions in an invitation process according to some implementations of the present disclosure;

[0016] Figure 8 A flowchart of a method for managing acquisition devices in a live broadcast application according to some implementations of the present disclosure is shown;

[0017] Fig. 9 A block diagram showing an apparatus for managing acquisition devices in a live broadcast application according to some implementations of the present disclosure; and

[0018] Fig.10 A block diagram of a device capable of implementing multiple implementations of the present disclosure is shown. DETAILED DESCRIPTION

[0019] The implementation of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain implementations of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be interpreted as being limited to the implementations described herein. On the contrary, these implementations are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and implementations of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0020] In the description of the implementation methods of the present disclosure, the term "including" and similar terms should be understood as open inclusion, that is, "including but not limited to". The term "based on" should be understood as "based at least in part on". The term "an implementation" or "the implementation" should be understood as "at least one implementation". The term "some implementations" should be understood as "at least some implementations". The following may also include other explicit and implicit definitions. As used herein, the term "model" can represent the association relationship between various data. For example, the above-mentioned association relationship can be obtained based on a variety of technical solutions currently known and / or to be developed in the future.

[0021] It is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0022] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0023] For example, in response to receiving an active request from a user, a prompt message is sent to the user to clearly prompt the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, application, server, or storage medium that performs the operation of the technical solution of the present disclosure according to the prompt message.

[0024] As an optional but non-limiting implementation, in response to receiving an active request from the user, the prompt information is sent to the user in a manner such as a pop-up window, in which the prompt information can be presented in text form. In addition, the pop-up window can also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0025] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0026] The term "in response to" as used herein refers to a state in which a corresponding event occurs or a condition is satisfied. It will be understood that the timing of executing a subsequent action executed in response to the event or condition is not necessarily strongly related to the time when the event occurs or the condition is satisfied. For example, in some cases, the subsequent action may be executed immediately when the event occurs or the condition is satisfied; while in other cases, the subsequent action may be executed some time after the event occurs or the condition is satisfied.

[0027] Example Environment

[0028] Currently, live streaming applications are available on client devices with various platform types. Figure 1 Describe an application environment according to an example implementation of the present disclosure, Figure 1 A block diagram 100 of an environment for a live broadcast application according to an exemplary implementation of the present disclosure is shown. Figure 1 As shown, the server device 110 may be a server side corresponding to running a live broadcast application, and users (e.g., users 130, 132, ..., and 134) may respectively use their respective client devices (e.g., client devices 120, 122, ..., and 124) to log in to the live broadcast application and access the server device 110 via the network 112. Multiple users may have respective types (e.g., types 150, 152, ..., and 154), and perform corresponding operations in the live broadcast room 140 based on different types.

[0029] For example, type 150 may be a host of the live broadcast room 140, and the host may manage the live broadcast room 140 as a host, for example, presenting his own media data (for example, including audio and / or video) to other users, inviting other users, and the like. Type 152 may be a guest of the live broadcast room 140, and the guest may present his own media data to other users; and type 154 may be an audience who can only watch the media data of the host and / or the guest. In the context of the present disclosure, the host may invite other users to join the live broadcast, for example, the host may invite one or more hosts of other live broadcast rooms to join the live broadcast room 140, and there may be multiple hosts in the live broadcast room 140 at this time; for another example, the host may invite the audience in the live broadcast room 140 to participate in the live broadcast, and the audience who accepts the invitation will be transformed into a guest, and the guest may broadcast his own media data.

[0030] For ease of description, the process of other users participating in the live broadcast room interaction can be referred to as "connecting the microphone" or "going on the microphone", and the process of other users exiting the connection and no longer participating in the live broadcast room interaction can be referred to as "leaving the microphone". The host can send an invitation to the audience, and the connection can be triggered if the audience accepts the invitation; the audience can send a request to the host, and the connection can be triggered if the host accepts the request. After connecting the microphone, the audience will be converted to a guest. Leaving the microphone can be triggered by the guest's exit operation or by the host's disconnection operation. After leaving the microphone, the guest will be converted to a viewer.

[0031] Although the above abbreviations only refer to the audio acquisition device "microphone", the "connected microphone", "upper microphone" and "lower microphone" herein may also refer to the image acquisition device (for example, camera). Here, the audio acquisition device and the image acquisition device may be set separately or in combination. For example, only the audio acquisition device may be turned on, only the video acquisition device may be turned on, or both the audio and video acquisition devices may be turned on at the same time.

[0032] It should be understood that since there are multiple platform types of client devices, developers have to use specific development languages ​​of various platform types to develop corresponding applications. Specifically, for the management of acquisition devices (e.g., audio acquisition devices and / or image acquisition devices) in live broadcast applications, multiple development teams need to use specific development languages ​​to write codes in order to implement the specific process of acquisition device management.

[0033] For example, taking the live broadcast and microphone connection function of the acquisition device management in the live broadcast application as an example, the current application development process is platform-specific, which means that dedicated code needs to be developed using the development language unique to each platform.

[0034] At this time, the codes of different platforms cannot be shared, which leads to a large waste of resources. For example, for all platforms that need to run the live broadcast and microphone connection function, they need to be redeveloped using the development language unique to the platform, which requires independent development and reduces development efficiency. Even for exactly the same functions, the implementation on different platforms will result in inconsistent development cycles, which will lead to delays in the overall development cycle. In addition, implementing the same functions on different platforms may cause inconsistencies in the final implemented functions, logic, or styles due to the different characteristics of different platforms. Furthermore, the inconsistency of functions or styles on different platforms may affect the user experience.

[0035] Furthermore, the existing technical solutions do not distinguish between the business functions and general basic capabilities for managing acquisition devices. Such an implementation method results in a low degree of code modularity, poor code encapsulation, and poor code maintainability. At this point, it is expected that acquisition device management can be implemented in a more convenient and effective way.

[0036] Overview of acquisition device management

[0037] In order to at least partially solve the deficiencies in the prior art, according to an exemplary implementation of the present disclosure, a method for managing acquisition devices in a live broadcast application is proposed. Figure 2 Describes an overview of an exemplary implementation according to the present disclosure, Figure 2 A block diagram 200 for managing acquisition devices in a live broadcast application according to some implementations of the present disclosure is shown. In summary, in an example implementation of the present disclosure, a live broadcast management tool 230 across multiple platform types is provided, and the live broadcast management tool 230 can support a unified acquisition device management process in live broadcast applications running on an iOS platform 232, an Android platform 234, and a PC platform 236.

[0038] like Figure 2 As shown, an access request of a user 130 of a live broadcast application 140 to access a live broadcast room in the live broadcast application can be detected. When an access request is detected, the type 150 of the user 130 in the live broadcast room can be determined. In the context of the present disclosure, the user can be referred to as a target object, which is used to represent an object that can use a collection device. The type of the target object here can include any one of an anchor, a guest, and an audience. Based on the different types, different operations can be performed when managing the collection device. Further, the platform type 210 of the client device 120 for running the live broadcast application can be obtained. Here, the platform type can include, for example, any one of an iOS platform 232, an Android platform 234, and a PC platform 236. Then, based on the type 150 and the platform type 210, the live broadcast management tool 230 can be used to manage the collection device of the client device.

[0039] By using the example implementation of the present disclosure, a unified management tool that supports cross-platform can be provided, thereby achieving high-performance live broadcast and microphone management. Specifically, the live broadcast management tool 230 can encapsulate the core microphone logic into a common module, and the internal logic of the tool is completely self-closed, and does not involve any specific business information, but only focuses on the general capabilities of microphone connection. In this way, the code abstraction and modularity are greatly improved, and maintainability is also greatly improved.

[0040] Here, the live broadcast management tool 230 is a unified cross-platform tool. You only need to call the tool and implement all subsequent microphone-connected functions in the tool. You do not need to develop separate microphone-connected management versions on different platforms. In this way, the human and material resources required to perform research and development and testing on multiple platforms can be released. While the development efficiency will be greatly improved, it can ensure that the microphone-connected logic, functions, and styles on multiple platforms will remain consistent, thereby improving the user experience of the application.

[0041] Detailed process of acquisition equipment management

[0042] Having described an overview of an example implementation of the present disclosure, see below. Figure 3 More details of the live broadcast management tool 230 are described. Figure 3 A block diagram 300 is shown showing the structure of the live broadcast management tool 230 according to some implementations of the present disclosure. Figure 3 As shown, the live broadcast management tool 230 may include multiple layers: a business layer 310, an access layer 320, a software development kit (SDK) layer 330, and a basic layer 340. Specifically, the business layer 310 may be the topmost business module, and may communicate with the business server of the live broadcast application. Here, the business server may provide specific business functions of the live broadcast room, and the specific business functions may be implemented by different development teams respectively. For example, business functions may include rich functions such as talent contests, interviews with live broadcasters, and taking turns to broadcast live, and the corresponding development team may define specific operating procedures by themselves, thereby providing richer live broadcast room functions.

[0043] The business layer 310 can, for example, provide different modules: the anchor microphone module 312 can be used to manage the acquisition equipment of the anchor in the live broadcast room, for example, supporting the anchor to start his own audio acquisition device and / or image acquisition device, and play his own media data to other users. At this time, multiple anchors in different live broadcast rooms can be connected to each other, and these anchors are equal. The guest microphone module 314 can support guests to accept the invitation of the anchor and become guests, and then play their own media data to other users. At this time, the audiences between the anchors, guests and audiences in the same live broadcast room are not equal, and the anchor has management authority over the audience connected to the microphone. For another example, the game microphone module 316 can support invited users to present game data at their client devices to other users, and so on.

[0044] Using the example implementation of the present disclosure, the live broadcast management tool 230 can provide basic functions for acquisition device management, which are universal. Specifically, it can include connecting to microphones, operating audio and video status, managing microphone layout, and so on. As a result, the universal basic functions of acquisition device management can be provided in a cross-platform manner, thereby achieving code reuse. On top of this universal basic function, different development teams can develop their own business logic to provide richer live broadcast room functions.

[0045] According to an example implementation of the present disclosure, the access layer 320 can serve as a bridge to provide acquisition device management functions across multiple platforms, thereby realizing the connection management function that serves the iOS platform 232, the Android platform 234, and the PC platform 236 at the same time. Specifically, the respective development languages ​​need to be used on the iOS platform 232, the Android platform 234, and the PC platform 236. However, these development languages ​​cannot directly call the capabilities provided by the cross-platform SDK layer 330. At this time, it is necessary to generate a language function interface (Foreign Function Interface, abbreviated as FFI) that supports different languages, and then call the capabilities provided by the SDK layer 330 through FFI.

[0046] According to an example implementation of the present disclosure, in order to manage the acquisition device in a cross-platform manner using the live broadcast management tool 230, the development language of the live broadcast application running at the client device can be determined based on the platform type 210, and a language function interface associated with the development language can be generated. In other words, the access layer 320 can convert the execution file supporting the acquisition device management provided by the SDK layer 330 into an executable code that can run on different platforms. Figure 3 As shown, the access layer 320 can provide a connector 350 including multiple interfaces, so that the connector 350 can be used to connect the capabilities provided by the SDK layer 330 to the multiple microphone connection modules of the upper layer, which are then called by the specific business functions of the live broadcast room.

[0047] Specifically, in order to support client devices on the iOS platform, a Swift interface 352 corresponding to the iOS platform may be generated; in order to support client devices on the Android platform, a Kotlin interface 354 corresponding to the Android platform may be generated. Similarly, based on the predetermined platform type, a Dart interface 356 and a NodeJS interface 358 may also be generated, and so on. Further, the live broadcast management tool 230 may be called via the language function interface.

[0048] Using the example implementation of the present disclosure, the generated multiple interfaces can serve live broadcast applications running on different platforms based on the detected platform types. In this way, the live broadcast management tool 230 can provide the general basic functions of acquisition device management in a unified manner across different platform types, thereby supporting specific business logic written in different development languages. In this way, the specific business logic of acquisition device management can be separated from the general basic functions, reducing the code coupling and facilitating the development, management and later maintenance of the application.

[0049] According to an example implementation of the present disclosure, in order to call the live broadcast management tool 230 via the language function interface, the live broadcast management tool 230 may be used to generate an execution file for managing the acquisition device. Specifically, the execution file may be generated via the SDK layer 330, and then the execution file may be converted into a specific execution code. At this time, the specific execution code may have a development library format corresponding to the platform type, and in this way, the execution code may be called via the language function interface for managing the acquisition device.

[0050] In the context of the present disclosure, at the access layer 320, in addition to providing FFI supporting different languages, the executable files (eg, binary files) generated by the cross-platform SDK layer 330 may also be converted into formats that conform to third-party development libraries specified by different platforms.

[0051] According to an example implementation of the present disclosure, the SDK layer 330 can provide the core function of collection device management. Here, the SDK layer 330 can provide the function of the self-closed loop of the microphone connection logic. No business-related logic is processed inside the SDK layer 330, but only the general basic logic of collection device management is provided. For example, the SDK layer 330 can be responsible for the management of the microphone connection link, the callback of the microphone connection state machine, the user on the microphone and the user status, the microphone connection interface request, the consumption of the microphone connection related instant message (IM), etc., and only provide the necessary and general interfaces and callbacks to the business layer, etc.

[0052] like Figure 3 As shown, the SDK layer 330 may include two parts: the upper layer linker 336 may provide different specific functions for different types, and the lower layer manager 360 may provide basic management functions related to acquisition device management. Specifically, based on the type of user who calls acquisition device management, a host application development interface (Host API) 332 for supporting the host type and a guest application development interface (Guest API) 334 for supporting the guest type and the audience type may be provided. Since guests and audiences can be converted to each other, a unified Guest API 334 is used to serve guests and audiences together.

[0053] According to an example implementation of the present disclosure, multiple development languages ​​can be used to implement the SDK layer 330. In software development, Rust, as a modern development language, has the advantages of low overhead, cross-platform support, strong type morphology, memory safety, etc. Further, since Rust has a friendly technical community environment and a rapidly developing ecological environment, Rust can be used to implement the SDK layer 330.

[0054] According to an example implementation of the present disclosure, the identity of the user needs to be considered during the collection device management process. Specifically, in order to generate an execution file for managing the collection device, the user's call to the live broadcast management tool can be detected. When the call is detected, the user can be assigned permissions corresponding to the type, and the collection device can be managed based on the assigned permissions. That is, a specific microphone management process can be performed based on the specific types of anchors, guests, and audiences.

[0055] Here, the host is the room owner who created the live broadcast room, the guest is the audience who has connected to the microphone, and the audience is an ordinary user who has not connected to the microphone and can only watch the media data of the host and the guests. Figure 4 Describes more details about permission management. Figure 4 A block diagram 400 is shown for managing acquisition devices according to various types of permissions according to some implementations of the present disclosure. Figure 4 As shown, if it is determined that the type of user is a host 410, corresponding permissions 412 may be assigned to the user.

[0056] Permission 412 can allow the user to perform at least one of the following actions: open a live broadcast room, which allows the user to create a new live broadcast room in the live broadcast application, and the user will be the host of the new live broadcast room; close a live broadcast room, which allows the anchor to close the live broadcast room of which he is the host, but does not allow closing the live broadcast rooms of other anchors; invite guests, which allows the anchor 410 to send an invitation to the audience of the live broadcast room. If the audience accepts the invitation, the type of audience will be changed to guest; remove guests, which allows the anchor 410 to remove one or more current guests, for example, when the guest's microphone connection ends The guest can be removed afterwards, or the host 410 can remove the guest if he / she thinks the live broadcast needs to be ended (the removed guest can, for example, continue to watch the live broadcast as an ordinary viewer of the live broadcast room, or can directly leave the live broadcast room); receive application, this action allows the host 410 to receive an application submitted by the audience to turn on the acquisition device (that is, the live broadcast application); and adjust the action, this action allows the host 410 to adjust the status of his / her own, other hosts connected to the microphone, or the guests connected to the microphone. For example, the microphone switch, volume, camera switch, color settings, filter settings, resolution, etc. can be adjusted individually or separately.

[0057] According to an example implementation of the present disclosure, if it is determined that the type of the user is a guest 420, the corresponding permission 422 may be assigned to the user. Permission 422 may allow the user to perform at least one of the following actions: apply to open the collection device, which may allow the viewer to send a microphone connection application to the host, and after the host accepts the microphone connection application, the viewer's type may be changed to a guest; accept the host's invitation, which may allow the viewer to accept the microphone connection invitation from the host, and if the viewer ends the invitation, the viewer's type will be changed to a guest; and adjust the action, which may allow the guest 420 to adjust the status of his or her own collection device.

[0058] According to an example implementation of the present disclosure, if the type of the user is determined to be a viewer 430, the user may be assigned corresponding permissions 432. Permissions 432 may allow the user to receive media data from guests and / or hosts, that is, the viewer can only watch the live media data but cannot provide his or her own media data to other users.

[0059] Using the example implementation of the present disclosure, the SDK layer 330 can use the permission management mechanism to provide different control capabilities to different types. Specifically, the SDK layer 330 can perform a type verification process each time a call to each function is detected. If it is found that a function that exceeds the current type permission is called, the SDK layer 330 can reject the call and throw an exception to the business server to inform the illegal call.

[0060] According to an example implementation of the present disclosure, the manager 360 in the SDK layer 330 may provide specific functions related to the management of the microphone connection. For example, the manager 360 may include multiple managers for performing different functions: a network manager 361, a user manager 362, a state manager 363, a communication manager 364, an enhancement manager 365, a log manager 366, a report manager 367, a location manager 368, and a message manager 369, etc.

[0061] Specifically, in the process of managing the acquisition device by using the live broadcast management tool 230, the network manager 361 in the live broadcast management tool 230 can be used to parse the received network data. For example, the network manager 361 can issue a request to call an interface in an asynchronous thread, and after receiving a callback for the interface, parse the original binary data (e.g., Protobuf data and / or JSON data) returned by the interface.

[0062] Further, the network manager 361 can store the received network data in an instance of the live broadcast management tool 230, for example, storing the parsing result in a class structure instance of Rust. The network manager 361 can transmit the instance to the linker in the live broadcast management tool 230 so as to communicate with the live broadcast application via the linker. For example, the instance can be passed back to the upper-level linker in the main thread. In the event of an exception in the request, the network manager 361 can throw the exception to the upper-level linker, thereby completing the entire interface request process.

[0063] According to an example implementation of the present disclosure, in the process of managing the acquisition device by using the live broadcast management tool 230, the user manager 362 in the live broadcast management tool 230 can be used to manage the user list of the live broadcast room. It should be understood that during the operation of the live broadcast room, there may be a large number of users with different statuses, so the user manager 362 can be used to manage the user list with different statuses, thereby realizing the business logic of the live broadcast room.

[0064] Here, the user list includes at least any one of the following: a list of users who have been connected, indicating one or more users who have entered the live broadcast room; a list of users who have applied for connection, indicating one or more users who have applied to the anchor for connection; a list of users who have been invited to connect, indicating one or more users to whom the anchor has sent a connection invitation; a list of users waiting to be connected, indicating one or more users who have been connected to the live broadcast room but have not yet received the first frame of content in the live broadcast room; a list of successfully connected users, indicating one or more users who have been connected to the live broadcast room and have received the first frame of content in the live broadcast room; a list of muted users, indicating one or more users who have turned off the audio; a list of video-turned users, indicating one or more users who have turned off the video.

[0065] According to an example implementation of the present disclosure, the user manager 362 can perform some simple processing and filtering on the user data, and provide a response to the upper-level linker through a callback when the user list changes. Using the example implementation of the present disclosure, the user manager 362 can cooperate with other parts in the live broadcast management tool 230 to provide rich and independent user management capabilities.

[0066] According to an exemplary implementation of the present disclosure, during the operation of the live studio, the status of the user may change continuously, and when the status change of the user in the live studio is detected, the user manager 362 may be used to update the user lists described above. Figure 5 Describes more details about the user's status change. Figure 5 A block diagram 500 of user type conversion according to some implementations of the present disclosure is shown. Figure 5 As shown, after the user successfully performs the microphone connection 510 action, the user type will be changed from audience 430 to guest 420. The microphone connection 510 can be performed in response to a request from the audience, for example; alternatively and / or additionally, the microphone connection 510 can also be performed in response to an invitation from the host. At this time, the relevant user list described above will be updated.

[0067] See also Figure 5 After the user successfully performs the microphone-off 520 action, the type of the user will be converted from guest 420 to audience 430. For example, microphone-off 520 can be performed in response to a leave request from an audience; alternatively and / or additionally, microphone-off 520 can also be performed in response to a disconnection operation from the anchor. At this time, the relevant user list described above will be updated. Using the example implementation of the present disclosure, the user manager 362 can continuously update each user list based on the latest user status received, thereby ensuring that users of different types and statuses in the live broadcast room can coordinate and participate in the various business logics of the live broadcast room.

[0068] According to an example implementation of the present disclosure, in the process of managing the acquisition device using the live broadcast management tool 230, the state manager 363 in the live broadcast management tool 230 can be used to detect the state change of the user. In response to detecting the change of state, the state manager 363 can transmit the state change to the server of the live broadcast application so that the server distributes the state change to at least one other client device for accessing the live broadcast room.

[0069] Specifically, the state manager 363 can receive and / or send the audio and video status of each user connected to the microphone, the status of exiting to the background, the audio occupancy status, etc. The server device of the live broadcast application can be informed through the uplink path. When the server device senses that the status of a connected user has changed, it can notify other users of the live broadcast room through the downlink path. In this way, each user in the live broadcast room can perceive the changes in the status of other users in a timely manner, and adjust the interface presented at their respective local client devices accordingly.

[0070] According to an example implementation of the present disclosure, in the process of managing the acquisition device using the live broadcast management tool 230, the communication manager 364 in the live broadcast management tool 230 can be used to manage the user's control parameters. Here, the control parameters may include at least any one of the following: startup parameters associated with data transmission in the live broadcast room, startup parameters associated with the acquisition device, entry parameters for entering the live broadcast room, and exit parameters for exiting the live broadcast room.

[0071] Specifically, based on the Real Time Communication (RTC) technology, the communication manager 364 can continuously collect the parameters injected by each client device running the live broadcast application. Using the example implementation of the present disclosure, the communication manager 364 can manage various control parameters involved in the live broadcast process in an independent and effective manner. In this way, the normal operation of the live broadcast room can be ensured in real time based on the latest control parameters.

[0072] According to an example implementation of the present disclosure, in the process of managing the acquisition device using the live broadcast management tool 230, the enhancement manager 365 in the live broadcast management tool 230 can be used to transmit the media data collected by the acquisition device to the server device of the live broadcast application, so that the server distributes the media data to at least one other client device for accessing the live broadcast room. Here, for example, the enhancement manager 365 can be implemented based on supplemental enhancement information (SEI), and the enhancement manager 365 can continuously follow the media data of the anchor and / or the guest according to a predetermined period, and transmit these data to each audience.

[0073] Specifically, the enhancement manager 365 can be used to transmit at least any of the following parameters: screen parameters of the client device, state parameters of the acquisition device (e.g., the switch state of the microphone, volume, etc.), and presentation position of the acquisition device (e.g., at which position of the screen the acquired media data is presented, etc.). For example, the above parameters can be transmitted to other client devices via a server device. Using the example implementation of the present disclosure, the enhancement manager 365 can manage more detailed information involved during the operation of the live broadcast room, thereby facilitating the coordinated operation of multiple modules to achieve the overall function of the live broadcast room.

[0074] According to an example implementation of the present disclosure, in the process of managing the acquisition device using the live broadcast management tool 230, the report manager 367 in the live broadcast management tool 230 can be used to report predetermined information to the server device of the live broadcast application, for example, the running time of each live broadcast room, the number of online participants, etc. can be counted and reported. In this way, it is convenient for the server device to understand the status of each live broadcast room as a whole, so as to adjust various resource configurations at the server device accordingly, thereby ensuring the operation of the live broadcast application.

[0075] According to an exemplary implementation of the present disclosure, in the process of managing the acquisition device by using the live broadcast management tool 230, the location manager 368 in the live broadcast management tool 230 can be used to manage the presentation location of the media data of at least one user associated with the live broadcast room. Figure 6Describes more details about location management. Figure 6 A block diagram 600 of an interface for presenting media information according to some implementations of the present disclosure is shown. Figure 6 As shown, in the interface 630 of the live broadcast application, media data of at least one user may be presented at the client device based on the presentation position of the media data of at least one user.

[0076] Assume that the presentation positions of the host and the guest are 612 and 622 respectively, the presentation position 612 represents the first position in the interface 630, and the presentation position 622 represents the second position in the interface 630. Figure 6 As shown, the host's media data 610 can be presented at the left position of the interface 630, and the guest's media data 620 can be presented at the right position. It should be understood that Figure 6 The example of presenting the media data of each user at different locations is merely schematically shown; when there are more or fewer hosts and guests, the corresponding media data may be presented in a similar manner.

[0077] For example, when there is only one anchor, the anchor's media data can be presented in the middle of the interface 630. For another example, when there is one anchor and three guests, the media data of each anchor and guest can be presented in two rows and two columns. It should be understood that the presentation of media data can be adjusted in real time. For example, when the number of anchors and / or guests changes, the layout of the interface 630 can be adjusted in real time. In this way, the corresponding media data can be presented according to different layouts, so as to manage the interface display of the live broadcast application in a more convenient way for the audience to watch.

[0078] According to an example implementation of the present disclosure, in the process of managing the acquisition device using the live broadcast management tool 230, the message manager 369 in the live broadcast management tool 230 can be used to obtain message data from the server of the live broadcast application. Further, the parsed result of the message data can be stored in an instance of the live broadcast management tool, and the instance can be transmitted to the linker in the live broadcast management tool so as to communicate with the live broadcast application via the linker.

[0079] Specifically, the message manager 369 can call back all received message data to the upper-level linker. The data obtained by the message manager 369 here can be original binary data (for example, Protobuf and / or JSON format). At this time, the message manager 369 can parse the original binary data and store the parsed results in the Rust class structure instance. At this time, the linker can perform the corresponding communication via the corresponding interface. In this way, the message manager 369 can manage the communication with the server in a simple and effective way, thereby completing the expected functions of the live broadcast application.

[0080] return Figure 3 The base layer 340 may include a variety of modules for receiving data injection from the bottom layer: network module 342, log module 344, audio / video module 346, etc. Here, the SDK layer 330 does not have a corresponding runtime, nor does it have other dependent libraries, so it needs to rely on the host (for example, the live broadcast application running at each client device) to request capabilities from the SDK layer 330 through injection.

[0081] According to an example implementation of the present disclosure, the method described above can be performed at a client device. For example, a live broadcast management tool 230 can be used to develop a live broadcast application. Specifically, when developing a live broadcast application running on different platforms, the business logic can be separated from the underlying general logic for the management of the microphone connection. The various functions encapsulated in the live broadcast management tool 230 can be directly called to complete the underlying logic of the microphone connection, and the upper-level business logic can perform the corresponding call via the various interfaces in the linker 350.

[0082] Here, the platform type of the client device may include an operating system based on a mobile device (such as an iOS operating system and an Android operating system) and an operating system based on a desktop device (such as a PC operating system). In this way, it is possible to implement microphone co-hosting management in a simpler and more effective manner across multiple development languages ​​and platform types.

[0083] The specific functions of each module of the live broadcast management tool 230 have been described. Figure 7 The operation process of the live broadcast room implemented by the live broadcast management tool 230 is described. Figure 7 A block diagram 700 is shown of state transitions in an invitation process according to some implementations of the present disclosure. Specifically, Figure 7 The process of the host 410 inviting the guest 420 is shown, that is, the overall process of a microphone connection. Figure 7 The left side shows the state change of the host 410, and the right side shows the state change of the guest 420. In the initial stage, the host 410 and the guest 420 are respectively in the "Idle" state 710 and 720. The host 410 can send out an invitation 730, at which time the host 410 will enter the "Waiting For Invite Reply" state 711 to wait for the guest 420 to respond to the invitation.

[0084] After sending an invitation to the guest 420, the host 410 may start 732 entering the live broadcast room (e.g., RTC room). At this time, the state of the host 410 changes to WaitingForInviteReply and "starting to enter the live broadcast room (JoiningChannel)". Entering the live broadcast room may be an asynchronous process. On the guest 420 side, the guest 420 may receive 731 a microphone connection invitation from the host 410, and then enter the "Receive Invitation" state 721. When the guest 420 starts 740 to enter the live broadcast room, the state 722 of the guest 420 changes to ReceiveInvitation and JoiningChannel. After the guest 420 accepts 741 the microphone connection invitation, the state 723 of the guest 420 may change to JoiningChannel.

[0085] At this time, the host 410 successfully enters the live broadcast room 733, and the host 410 can receive a callback of successful entry, and then the state 713 of the host 410 changes to WaitingForInviteReply and "successfully entered the live broadcast room (JoinedChannel)". At this time, the host 410 can also start to push his own media data. If the host 410 receives a response 742 from the guest 420 agreeing to the invitation, the state 714 of the host 410 changes to JoinedChannel. At this time, the guest 420 successfully enters the live broadcast room 743, and the state 724 of the guest 420 changes to JoinedChannel. At the same time, the guest 420 can start to push his own media data.

[0086] After receiving 744 the first frame data from the host 410, the status 725 of the guest 420 changes to "Linked", at which point the guest 420 is truly connected to the microphone successfully. Subsequently, after receiving 734 the first frame data from the guest 420, the status 715 of the host 410 changes to Linked, which means that the host 410 is also connected to the microphone successfully. After a period of time, the guest 420 can leave 745 (for example, actively end the connection to the microphone through the leave interface), and the guest 420 can clear all temporary data related to the connection to the microphone, at which point the status 726 of the guest 420 changes to "Finish". After the host 410 receives 746 the leaving message of the guest 420, the host 410 can determine whether there are other users connected to the microphone. If there are no other users connected to the microphone, the host 410 can clear all temporary data related to the connection to the microphone, at which point the status 716 of the host 410 changes to "Finish", and the entire connection to the microphone process ends.

[0087] It should be understood that although the above only schematically shows the process of the host 410 inviting the guest 420 to connect with the host, alternatively and / or additionally, the host 410 can invite another host to connect with the host, and the process of connecting with the host is similar to Figure 7 According to an example implementation of the present disclosure, the Figure 7 In the manner shown, one or more hosts and / or guests can be invited to realize multi-person live broadcast in the live broadcast room. According to an exemplary implementation of the present disclosure, the audience can actively send a connection request to the host, and the audience can be converted to a guest if the host allows it. The active request process is similar to Figure 7 As shown, the difference is that at this time, the audience on the right actively sends a connection request to the anchor 410.

[0088] By using the exemplary implementation of the present disclosure, the live broadcast management tool 230 can encapsulate the core logic of the live broadcast room microphone connection operation, and thus manage the acquisition equipment of each user in the live broadcast application in a more convenient and effective manner.

[0089] Example Process

[0090] Figure 8 A flow chart of a method 800 for managing acquisition devices according to some implementations of the present disclosure is shown. At block 810, in response to detecting that a target object accesses a live broadcast room in a live broadcast application, the type of the target object is determined. At block 820, the platform type of the client device used to run the live broadcast application is obtained. At block 830, based on the type of the target object and the platform type, the acquisition device of the client device is managed using a live broadcast management tool.

[0091] According to an example implementation of the present disclosure, a live broadcast management tool is used to manage acquisition devices, including: determining the development language of a live broadcast application running on a client device based on a platform type; generating a language function interface associated with the development language; and calling the live broadcast management tool via the language function interface.

[0092] According to an example implementation of the present disclosure, calling a live broadcast management tool via a language function interface includes: using the live broadcast management tool to generate an execution file for managing an acquisition device; converting the execution file into an execution code, the execution code having a development library format corresponding to a platform type; and calling the execution code via a language function interface for managing the acquisition device.

[0093] According to an example implementation of the present disclosure, using a live broadcast management tool to manage a capture device includes: using a network manager in the live broadcast management tool to parse received network data; storing the network data in an instance of the live broadcast management tool; and transmitting the instance to a linker in the live broadcast management tool so as to communicate with a live broadcast application via the linker.

[0094] According to an example implementation of the present disclosure, using a live broadcast management tool to manage a capture device includes: using a state manager in the live broadcast management tool to detect a state change of a target object; in response to detecting a state change, transmitting the state change to a server of a live broadcast application so that the server distributes the state change to at least one other client device used to access the live broadcast room.

[0095] According to an example implementation of the present disclosure, using a live broadcast management tool to manage a collection device includes: using a communication manager in the live broadcast management tool to manage control parameters of a target object, the control parameters including at least any one of the following: startup parameters associated with data transmission in the live broadcast room, startup parameters associated with the collection device, entry parameters for entering the live broadcast room, and exit parameters for exiting the live broadcast room.

[0096] According to an example implementation of the present disclosure, using a live broadcast management tool to manage a capture device includes: using an enhanced manager in the live broadcast management tool to transmit media data captured by the capture device to a server device of a live broadcast application, so that the server distributes the media data to at least one other client device for accessing the live broadcast room.

[0097] According to an example implementation of the present disclosure, the method further includes: using the enhancement manager to transmit at least any of the following parameters to the server device: screen parameters of the client device, state parameters of the acquisition device, and presentation position of the acquisition device.

[0098] According to an example implementation of the present disclosure, using a live broadcast management tool to manage a capture device includes: using a location manager in the live broadcast management tool to manage a presentation location of media data of at least one target object associated with a live broadcast room; and based on the presentation location of the media data of the at least one target object, presenting the media data of the at least one target object at a client device.

[0099] According to an example implementation of the present disclosure, using a live broadcast management tool to manage a capture device includes: using a message manager in the live broadcast management tool to obtain message data from a server of a live broadcast application; storing the parsed results of the message data in an instance of the live broadcast management tool; and transmitting the instance to a linker in the live broadcast management tool so as to communicate with the live broadcast application via the linker.

[0100] According to an example implementation of the present disclosure, the method is executed at a client device, and the development language of the live broadcast application depends on the platform type, which includes at least any one of the following: an operating system based on a mobile device and an operating system based on a desktop device.

[0101] Example devices and equipment

[0102] Fig. 9 A block diagram of an apparatus 900 for managing a collection device according to some implementations of the present disclosure is shown. The apparatus 900 includes: a determination module 910 configured to determine the type of a target object in response to detecting that the target object accesses a live broadcast room in a live broadcast application; an acquisition module 920 configured to acquire the platform type of a client device for running the live broadcast application; and a management module 930 configured to manage the collection device of the client device using a live broadcast management tool based on the type and platform type of the target object.

[0103] According to an example implementation of the present disclosure, the management module includes: a language determination module, configured to determine the development language of a live broadcast application running at a client device based on a platform type; a generation module, configured to generate a language function interface associated with the development language; and a calling module, configured to call a live broadcast management tool via the language function interface.

[0104] According to an example implementation of the present disclosure, a calling module includes: an execution file generation module configured to generate an execution file for managing an acquisition device using a live broadcast management tool; a conversion module configured to convert the execution file into an execution code, the execution code having a development library format corresponding to a platform type; and an interface calling module configured to call the execution code via a language function interface for managing the acquisition device.

[0105] According to an example implementation of the present disclosure, the management module includes: a parsing module configured to parse received network data using a network manager in a live broadcast management tool; a storage module configured to store the network data in an instance of the live broadcast management tool; and a transmission module configured to transmit the instance to a linker in the live broadcast management tool so as to communicate with the live broadcast application via the linker.

[0106] According to an example implementation of the present disclosure, the management module includes: a detection module, configured to utilize a state manager in a live broadcast management tool to detect a state change of a target object; and a state transmission module, configured to transmit the state change to a server of a live broadcast application in response to detecting a state change, so that the server distributes the state change to at least one other client device for accessing the live broadcast room.

[0107] According to an example implementation of the present disclosure, the management module includes: a control module configured to manage control parameters of a target object using a communication manager in a live broadcast management tool, the control parameters including at least any one of the following: startup parameters associated with data transmission in the live broadcast room, startup parameters associated with a capture device, entry parameters for entering the live broadcast room, and exit parameters for exiting the live broadcast room.

[0108] According to an example implementation of the present disclosure, the management module includes: an enhancement module, configured to utilize an enhancement manager in a live broadcast management tool to transmit media data collected by a collection device to a server device of a live broadcast application, so that the server distributes the media data to at least one other client device for accessing the live broadcast room.

[0109] According to an example implementation of the present disclosure, the apparatus further includes: a parameter transmission module configured to utilize the enhancement manager to transmit at least any of the following parameters to the server device: screen parameters of the client device, state parameters of the acquisition device, and presentation position of the acquisition device.

[0110] According to an example implementation of the present disclosure, the management module includes: a location management module configured to manage the presentation location of media data of at least one target object associated with a live broadcast room by utilizing a location manager in a live broadcast management tool; and a presentation module configured to present the media data of at least one target object at a client device based on the presentation location of the media data of the at least one target object.

[0111] According to an example implementation of the present disclosure, the management module includes: a message acquisition module, configured to utilize a message manager in a live broadcast management tool to acquire message data from a server of a live broadcast application; a result storage module, configured to store the parsed result of the message data in an instance of the live broadcast management tool; and an instance transmission module, configured to transmit the instance to a linker in the live broadcast management tool so as to communicate with the live broadcast application via the linker.

[0112] According to an example implementation of the present disclosure, the apparatus is executed at a client device, and the development language of the live broadcast application depends on the platform type, which includes at least any one of the following: an operating system based on a mobile device and an operating system based on a desktop device.

[0113] Fig.10 1 shows a block diagram of a device 1000 capable of implementing multiple implementations of the present disclosure. It should be understood that Fig.10 The computing device 1000 shown is merely exemplary and should not constitute any limitation on the functionality and scope of the implementations described herein. Fig.10The computing device 1000 shown may be used to implement the methods described above.

[0114] like Fig.10 As shown, computing device 1000 is in the form of a general-purpose computing device. Components of computing device 1000 may include, but are not limited to, one or more processors or processing units 1010, memory 1020, storage device 1030, one or more communication units 1040, one or more input devices 1050, and one or more output devices 1060. Processing unit 1010 may be an actual or virtual processor and is capable of performing various processes according to a program stored in memory 1020. In a multi-processor system, multiple processing units execute computer executable instructions in parallel to increase the parallel processing capabilities of computing device 1000.

[0115] The computing device 1000 typically includes a plurality of computer storage media. Such media may be any available media accessible to the computing device 1000, including but not limited to volatile and non-volatile media, removable and non-removable media. The memory 1020 may be a volatile memory (e.g., registers, caches, random access memory (RAM)), a non-volatile memory (e.g., a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. The storage device 1030 may be a removable or non-removable medium, and may include a machine-readable medium, such as a flash drive, a disk, or any other medium, which may be capable of being used to store information and / or data (e.g., training data for training) and may be accessed within the computing device 1000.

[0116] The computing device 1000 may further include additional removable / non-removable, volatile / non-volatile storage media. Fig.10 As shown in , a disk drive for reading or writing from a removable, non-volatile disk (e.g., a "floppy disk") and an optical drive for reading or writing from a removable, non-volatile optical disk may be provided. In these cases, each drive may be connected to the bus (not shown) by one or more data media interfaces. Memory 1020 may include a computer program product 1025 having one or more program modules that are configured to perform various methods or actions of various implementations of the present disclosure.

[0117] The communication unit 1040 enables communication with other computing devices via a communication medium. Additionally, the functions of the components of the computing device 1000 can be implemented in a single computing cluster or multiple computing machines that can communicate via a communication connection. Therefore, the computing device 1000 can operate in a networked environment using a logical connection with one or more other servers, a network personal computer (PC), or another network node.

[0118] Input device 1050 may be one or more input devices, such as a mouse, keyboard, tracking ball, etc. Output device 1060 may be one or more output devices, such as a display, a speaker, a printer, etc. Computing device 1000 may also communicate with one or more external devices (not shown) through communication unit 1040 as needed, such as storage devices, display devices, etc., communicate with one or more devices that allow a user to interact with computing device 1000, or communicate with any device that allows computing device 1000 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.). Such communication may be performed via an input / output (I / O) interface (not shown).

[0119] According to an exemplary implementation of the present disclosure, a computer-readable storage medium is provided, on which computer-executable instructions are stored, wherein the computer-executable instructions are executed by a processor to implement the method described above. According to an exemplary implementation of the present disclosure, a computer program product is also provided, the computer program product is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, and the computer-executable instructions are executed by a processor to implement the method described above. According to an exemplary implementation of the present disclosure, a computer program product is provided, on which a computer program is stored, and when the program is executed by a processor, the method described above is implemented.

[0120] Various aspects of the present disclosure are described herein with reference to the flowcharts and / or block diagrams of the methods, devices, equipment, and computer program products implemented according to the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer-readable program instructions.

[0121] These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processing unit of the computer or other programmable data processing device, a device that implements the functions / actions specified in one or more boxes in the flowchart and / or block diagram is generated. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0122] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operational steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable data processing apparatus, or other device implement the functions / actions specified in one or more boxes in the flowchart and / or block diagram.

[0123] The flow chart and block diagram in the accompanying drawings show the possible architecture, function and operation of the system, method and computer program product according to multiple implementations of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and a part of a module, program segment or instruction includes one or more executable instructions for realizing the logical function of the specification. In some implementations as replacements, the function marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be realized by a special hardware-based system that performs the function or action of the specification, or can be realized by a combination of special hardware and computer instructions.

[0124] The above descriptions of various implementations of the present disclosure are exemplary, non-exhaustive, and not limited to the disclosed implementations. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described implementations. The selection of terms used herein is intended to best explain the principles of the implementations, practical applications, or improvements to the technology in the market, or to enable other persons of ordinary skill in the art to understand the various implementations disclosed herein.

Claims

1. A method for managing a collection device, comprising: In response to detecting that a target object accesses a live broadcast room in a live broadcast application, determining a type of the target object; Obtaining a platform type of a client device used to run the live broadcast application; as well as Based on the type of the target object and the platform type, a live broadcast management tool is used to manage the acquisition device of the client device.

2. The method according to claim 1, wherein using the live broadcast management tool to manage the acquisition device comprises: Determining a development language of the live broadcast application running at the client device based on the platform type; generating a language function interface associated with the development language; as well as The live broadcast management tool is called via the language function interface.

3. The method according to claim 1, wherein calling the live broadcast management tool via the language function interface comprises: Using the live broadcast management tool to generate an execution file for managing the acquisition device; Converting the execution file into an execution code, wherein the execution code has a development library format corresponding to the platform type; as well as The execution code is called via the language function interface to manage the acquisition device.

4. The method according to claim 1, wherein using the live broadcast management tool to manage the acquisition device comprises: Utilizing the network manager in the live broadcast management tool to parse the received network data; Storing the network data in an instance of the live broadcast management tool; as well as The instance is transmitted to a linker in a live broadcast management tool so as to communicate with the live broadcast application via the linker.

5. The method according to claim 1, wherein using the live broadcast management tool to manage the acquisition device comprises: Using the state manager in the live broadcast management tool to detect the state change of the target object; In response to detecting the change in state, the change in state is transmitted to a server of the live broadcast application so that the server distributes the change in state to at least one other client device for accessing the live broadcast room.

6. The method according to claim 1, wherein using the live broadcast management tool to manage the acquisition device comprises: The communication manager in the live broadcast management tool is used to manage the control parameters of the target object, and the control parameters include at least any one of the following: startup parameters associated with the data transmission of the live broadcast room, startup parameters associated with the acquisition device, entry parameters for entering the live broadcast room, and exit parameters for exiting the live broadcast room.

7. The method according to claim 1, wherein using the live broadcast management tool to manage the acquisition device comprises: The enhanced manager in the live broadcast management tool is used to transmit the media data collected by the collection device to the server device of the live broadcast application, so that the server distributes the media data to at least one other client device for accessing the live broadcast room.

8. The method according to claim 11, further comprising: The enhancement manager is used to transmit at least any one of the following parameters to the server device: screen parameters of the client device, state parameters of the acquisition device, and presentation position of the acquisition device.

9. The method according to claim 1, wherein using the live broadcast management tool to manage the acquisition device comprises: Using a location manager in the live broadcast management tool to manage a presentation location of media data of at least one target object associated with the live broadcast room; as well as Based on the presentation position of the media data of the at least one target object, the media data of the at least one target object is presented at the client device.

10. The method according to claim 1, wherein using the live broadcast management tool to manage the acquisition device comprises: Using the message manager in the live broadcast management tool to obtain message data from the server corresponding to the live broadcast application; Storing the parsed result of the message data in the instance of the live broadcast management tool; as well as The instance is transmitted to a linker in a live broadcast management tool so as to communicate with the live broadcast application via the linker.

11. The method according to claim 1, wherein the method is executed at the client device, and the development language of the live broadcast application depends on the platform type, and the platform type includes at least any one of the following: an operating system based on a mobile device and an operating system based on a desktop device.

12. A device for managing acquisition equipment in a live broadcast application, comprising: A determination module, configured to determine the type of the target object in response to detecting that the target object accesses the live broadcast room in the live broadcast application; An acquisition module, configured to acquire a platform type of a client device used to run the live broadcast application; as well as The management module is configured to manage the acquisition device of the client device using a live broadcast management tool based on the type of the target object and the platform type.

13. An electronic device, comprising: at least one processing unit; as well as At least one memory, the at least one memory being coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit, the instructions causing the electronic device to perform the method according to any one of claims 1 to 11 when executed by the at least one processing unit.

14. A computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the processor is caused to implement the method according to any one of claims 1 to 11.

Images