Method and apparatus for managing acquisition device, device, and medium

Abstract

Embodiments of the present disclosure provide a method and an apparatus for managing an acquisition device, a device, and a medium. The method comprises: in response to detecting a target object accessing a live broadcast room in a live broadcast application, determining the type of the target object; obtaining a platform type of a client device for running the live broadcast application; and on the basis of the type of the target object and the platform type, managing an acquisition device of the client device by using a live broadcast management tool. By using an exemplary implementation of the present disclosure, the live broadcast management tool can package the core logic of the acquisition device management operation related to the live broadcast room, so that acquisition devices of various target objects are managed in the live broadcast application in a convenient and effective manner.

Description

[0001]This application claims priority to Chinese invention patent application number 202311460295.6, filed on November 3, 2023, entitled "Method, Apparatus, Device, and Medium for Managing Collection Devices," the entire contents of which are incorporated herein by reference. Technical Field: 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 collection devices in live streaming applications. With the advancement of computer technology, live streaming applications are now available on various platform types for client devices. Users can install live streaming applications on their client devices to watch live broadcasts and participate in live streaming room interactions. However, since client devices are available on various platform types, developers are forced to develop corresponding live streaming applications using development languages ​​specific to each platform type. Specifically, managing collection devices in live streaming applications requires code written in specific development languages ​​to implement the specific processes of collection device management. This leads to various resource wastes during the development process, and it is therefore desirable to implement acquisition device management in a more convenient and efficient manner. SUMMARY OF THE INVENTION In a first aspect of the present disclosure, a method for managing acquisition devices is provided. In this method, in response to detecting a target object accessing a live broadcast room in a live broadcast application, the type of the target object is determined. The platform type of the client device used to run the live broadcast application is obtained. Based on the type and platform type of the target object, the acquisition device of the client device is managed using a live broadcast management tool. In a second aspect of the present disclosure, an apparatus for managing acquisition devices is provided. The apparatus includes: a determination module configured to determine the type of the target object in response to detecting a target object accessing a live broadcast room in a live broadcast application; an acquisition module configured to obtain the platform type of the client device used to run the live broadcast application; and a management module configured to manage the acquisition device of the client device using the live broadcast management tool based on the type and platform type of the target object. 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 being coupled to the at least one processing unit and storing instructions for execution by the at least one processing unit. When executed by the at least one processing unit, the instructions cause the electronic device to perform the method according to the first aspect of the present disclosure. In a fourth aspect of the present disclosure, a computer-readable storage medium is provided, having a computer program stored thereon. When executed by a processor, the computer program causes the processor to perform the method according to the first aspect of the present disclosure.It should be understood that the content described in this summary is not intended to define the key features or important features of the implementations of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily apparent through the following description. BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other features, advantages, and aspects of various implementations of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, identical or similar reference numerals represent identical or similar elements, wherein: FIG1 is a block diagram illustrating an environment of a live broadcast application according to an exemplary implementation of the present disclosure; FIG2 is a block diagram illustrating a method for managing acquisition devices in a live broadcast application according to some implementations of the present disclosure; FIG3 is a block diagram illustrating the structure of a live broadcast management tool according to some implementations of the present disclosure; FIG4 is a block diagram illustrating management of acquisition devices according to various user types of permissions according to some implementations of the present disclosure; FIG5 is a block diagram illustrating user type conversion according to some implementations of the present disclosure; FIG6 is a block diagram illustrating an interface for presenting media information according to some implementations of the present disclosure; FIG7 is a block diagram illustrating state conversion during an invitation process according to some implementations of the present disclosure; FIG8 is a flow chart illustrating a method for managing acquisition devices in a live broadcast application according to some implementations of the present disclosure; FIG9 is a block diagram illustrating an apparatus for managing acquisition devices in a live broadcast application according to some implementations of the present disclosure; and FIG10 is a block diagram illustrating a device capable of implementing various implementations of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS Implementations 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 may be implemented in various forms and should not be construed as limited to the implementations described herein. Rather, these implementations are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the accompanying drawings and implementations of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure. The term "present manner" or "this implementation manner" should be understood as "at least one implementation manner." The term "some implementation manners" should be understood as "at least some implementation manners." 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 association relationship can be obtained based on various technical solutions currently known and / or to be developed in the future. It is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) must comply with the requirements of relevant laws, regulations and relevant provisions. It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, the type, scope of use, and usage scenarios of the personal information involved in this disclosure should be informed to the user in accordance with relevant laws and regulations through appropriate means and the user's authorization should be obtained. For example, in response to receiving a user's active request, a prompt message is sent to the user to clearly inform the user that the operation requested will require the acquisition and use of the user's personal information. Therefore, the user can independently choose whether to provide personal information to the electronic device, application, server, storage medium, or other software or hardware that performs the operation of the technical solution of this disclosure based on the prompt message. As an optional but non-limiting implementation, in response to receiving a user's active request, a prompt message may be sent to the user, for example, in the form of a pop-up window, in which the prompt message may be presented in text form. Furthermore, the pop-up window may also contain a selection control for the user to select "Agree" or "Disagree" to provide personal information to the electronic device. It should be understood that the above notification and user authorization process are merely illustrative and do not limit the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure. The term "in response to" as used herein refers to the 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 an event or condition is not necessarily strongly correlated with the time when the event occurs or the condition is satisfied. For example, in some cases, the subsequent action may be executed immediately upon the occurrence of the event or the satisfaction of the condition; in other cases, the subsequent action may be executed some time after the occurrence of the event or the satisfaction of the condition. The example environment currently provides live streaming applications on client devices with various platform types.FIG1 illustrates an application environment according to an exemplary implementation of the present disclosure. FIG1 shows a block diagram 100 of an environment for a live broadcast application according to an exemplary implementation of the present disclosure. As shown in FIG1 , server device 110 may be a server running a live broadcast application. Users (e.g., users 130, 132, ..., and 134) may use their respective client devices (e.g., client devices 120, 122, ..., and 124) to log in to the live broadcast application and access server device 110 via network 112. Multiple users may have different types (e.g., types 150, 152, ..., and 154) and perform corresponding operations in live broadcast room 140 based on their different types. For example, type 150 may be the host of live broadcast room 140. This host may manage live broadcast room 140 as a host, for example, presenting their own media data (e.g., including audio and / or video) to other users, inviting other users, and so on. Type 152 may be a guest in live studio 140, who can present their own media data to other users; and type 154 may be an audience member who can only view the media data of the host and / or guests. In the context of this disclosure, a host can invite other users to join a live broadcast. For example, a host can invite one or more hosts from other live studios to join live studio 140, where multiple hosts may exist. Another example is a host can invite a viewer in live studio 140 to participate in the live broadcast. Upon accepting the invitation, the viewer becomes a guest and can broadcast their own media data. For ease of description, the process of other users participating in live studio interaction may be referred to as "connecting the microphone" or "coming up on the microphone," while the process of other users exiting the microphone connection and no longer participating in the live studio interaction may be referred to as "going off the microphone." The host can send an invitation to a viewer, and a connection to the microphone can be triggered if the viewer accepts the invitation. A viewer can also initiate a request to the host, and a connection to the microphone can be triggered if the host accepts the request. After connecting to the microphone, the viewer becomes a guest. The guest's exit can trigger the microphone to go offline, or the host's disconnection. After leaving the microphone, the guest becomes an audience member. Although the above abbreviations refer only to the audio capture device "microphone," "connecting to the microphone," and "going offline" can also refer to image capture devices (e.g., cameras). Audio and image capture devices can be provided separately or in combination.For example, it's possible to enable only the audio capture device, only the video capture device, or both. It's important to understand that, due to the diverse platform types available for client devices, developers must develop applications using platform-specific development languages. Specifically, managing capture devices (e.g., audio and / or image capture devices) in live streaming applications requires multiple development teams to write code using specific development languages ​​to implement the specific processes involved. For example, taking the live broadcast and microphone connection feature within live streaming applications as an example, the current application development process is platform-specific, requiring dedicated code to be developed using platform-specific development languages. This prevents code sharing between platforms, resulting in significant resource waste. For example, all platforms requiring the live broadcast and microphone connection feature must be redeveloped using their platform-specific development languages, requiring independent development and reducing development efficiency. Even for the exact same functionality, implementation on different platforms can lead to inconsistent development cycles, further delaying the overall development cycle. Furthermore, implementing the same functionality on different platforms may lead to inconsistencies in the final implemented functionality, logic, or style due to the varying characteristics of the platforms. Furthermore, inconsistent functionality or style across different platforms may impact the user experience. Furthermore, existing technical solutions do not distinguish between business functions and general infrastructure capabilities for managing acquisition devices. This implementation results in low code modularity, poor code encapsulation, and poor code maintainability. Therefore, it is desirable to implement acquisition device management in a more convenient and efficient manner. Overview of Acquisition Device Management: To at least partially address the deficiencies of the existing technology, according to an exemplary implementation of the present disclosure, a method for managing acquisition devices in a live broadcast application is proposed. An overview of an exemplary implementation of the present disclosure is described with reference to FIG2 , which shows a block diagram 200 for managing acquisition devices in a live broadcast application according to some implementations of the present disclosure. In summary, in one exemplary implementation of the present disclosure, a live streaming management tool 230 is provided across multiple platforms. This live streaming management tool 230 can support unified acquisition device management in live streaming applications running on iOS 232, Android 234, and PC 236 platforms. As shown in FIG2 , an access request from a user 130 of a live streaming application 140 to access a live streaming room within the application can be detected. Upon detecting the access request, the user 130's type 150 within the live streaming room can be determined.In the context of this disclosure, a user can be referred to as a target object, representing an object that can use a capture device. The target object type can include any of: host, guest, and audience. Different operations can be performed when managing capture devices based on the target object type. Furthermore, the platform type 210 of the client device 120 running the live broadcast application can be obtained. For example, the platform type can include any of: iOS platform 232, Android platform 234, and PC platform 236. Based on the type 150 and platform type 210, the client device's capture devices can be managed using the live broadcast management tool 230. Using the example implementations of this disclosure, a unified management tool with cross-platform support can be provided, enabling high-performance live broadcast and live-streaming management. Specifically, the live broadcast management tool 230 can encapsulate the core live-streaming logic into a common module. The internal logic of the tool is completely self-contained and does not involve any specific business information, focusing solely on the general capabilities of live-streaming. This significantly improves code abstraction and modularity, significantly enhancing maintainability. Here, the live broadcast management tool 230 is a unified cross-platform tool. Simply call it and implement all subsequent live broadcast-related functions within it, eliminating the need to develop separate live broadcast management versions for different platforms. This approach frees up the human and material resources required for development and testing on multiple platforms. This significantly improves development efficiency while ensuring consistency in live broadcast logic, functionality, and style across multiple platforms, thereby enhancing the user experience. The detailed process of acquisition device management has already outlined an example implementation of this disclosure. Below, see Figure 3 for more details on the live broadcast management tool 230. FIG3 illustrates a block diagram 300 of the structure of a live broadcast management tool 230 according to some implementations of the present disclosure. As shown in FIG3 , 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 base layer 340. Specifically, the business layer 310 may be the top-level business module and may communicate with the business server of the live broadcast application. The business server may provide specific business functions for the live broadcast room, and these specific business functions may be implemented by different development teams. For example, business functions may include talent shows, live interviews, and rotating microphones, among other rich functions. The corresponding development teams may define their own specific operating procedures to provide even richer live broadcast room functions.For example, the business layer 310 can provide different modules: The host microphone connection module 312 can be used to manage the host's capture devices in the live broadcast room. For example, it allows the host to activate their own audio and / or image capture devices and broadcast their media data to other users. In this case, multiple hosts in different live broadcast rooms can connect to each other, and these hosts are equal. The guest microphone connection module 314 allows guests to accept the host's invitation and become guests, and then broadcast their media data to other users. In this case, the host, guests, and audience in the same live broadcast room are not equal, and the host has management authority over the connected audience. For another example, the game microphone connection module 316 can allow invited users to present their game data from their client devices to other users, and so on. Using the example implementation of the present disclosure, the live broadcast management tool 230 can provide basic functions for collecting device management. These basic functions are universal. Specifically, they can include connecting to microphones, controlling audio and video status, and managing microphone position layouts. This allows for cross-platform provision of common basic functions for acquisition device management, enabling code reuse. Building upon this common foundation, different development teams can develop their own business logic, providing richer live studio functionality. According to one exemplary implementation of the present disclosure, the access layer 320 can serve as a bridge to provide acquisition device management functionality across multiple platforms, thereby enabling simultaneous live broadcast management functionality for iOS 232, Android 234, and PC 236 platforms. Specifically, the iOS, Android, and PC platforms 232, 234, and 236 require the use of their respective development languages. However, these languages ​​cannot directly access the capabilities provided by the cross-platform SDK layer 330. Therefore, it is necessary to generate a foreign function interface (FFI) supporting different languages, allowing the SDK layer 330 capabilities to be accessed through the FFI. According to an example implementation of the present disclosure, to utilize live broadcast management tool 230 to manage capture devices in a cross-platform manner, the development language of the live broadcast application running on the client device can be determined based on platform type 210, and a language function interface associated with the development language can be generated. In other words, access layer 320 can convert the execution file supporting capture device management provided by SDK layer 330 into executable code that can run on different platforms.As shown in Figure 3, the access layer 320 can provide a connector 350 comprising multiple interfaces. This connector 350 can be used to link the capabilities provided by the SDK layer 330 to the various microphone-connecting modules in the upper layer, which can then be called by specific business functions within the live studio. Specifically, to support iOS client devices, a Swift interface 352 corresponding to the iOS platform can be generated; to support Android client devices, a Kotlin interface 354 corresponding to the Android platform can be generated. Similarly, based on the predetermined platform type, a Dart interface 356 and a NodeJS interface 358 can be generated, and so on. Furthermore, the live broadcast management tool 230 can be called via language function interfaces. Using the example implementation of the present disclosure, the various generated interfaces can serve live broadcast applications running on different platforms based on the detected platform type. In this way, the live broadcast management tool 230 can provide common basic functions for acquisition device management in a unified manner across different platform types, thereby supporting specific business logic written in different development languages. This allows the specific business logic for acquisition device management to be separated from general infrastructure functions, reducing code coupling and facilitating application development, management, and subsequent maintenance. According to one exemplary implementation of the present disclosure, to invoke the live broadcast management tool 230 via a language function interface, the live broadcast management tool 230 can first be used to generate an executable file for managing acquisition devices. Specifically, the SDK layer 330 can generate this executable file, which is then converted into specific executable code. The specific executable code can be formatted as a development library corresponding to the platform type. In this way, the executable code can be invoked via the language function interface to manage acquisition devices. In the context of the present disclosure, in addition to providing FFI support for different languages, the access layer 320 can also convert the executable file (e.g., binary file) generated by the cross-platform SDK layer 330 into a format compatible with third-party development libraries specific to each platform. According to one exemplary implementation of the present disclosure, the SDK layer 330 can provide the core functionality for acquisition device management. The SDK layer 330 provides a self-contained logic loop for connecting to the microphone. The SDK layer 330 does not handle any business-related logic internally, but only provides general basic logic for data acquisition device management. For example, the SDK layer 330 is responsible for managing the microphone connection link, microphone state machine callbacks, users on the microphone and their status, microphone connection interface requests, and consumption of instant messages (IMs) related to microphone connection. It only provides the business layer with necessary and general interfaces and callbacks.As shown in Figure 3, the SDK layer 330 consists of two parts: an upper-layer linker 336 that provides specific functions for different types, and a lower-layer manager 360 that provides basic management functions related to acquisition device management. Specifically, based on the type of user invoking acquisition device management, a host application development interface (Host API) 332 for the host type and a guest application development interface (Guest API) 334 for guests and audience types can be provided. Because guests and audiences can convert between each other, a unified Guest API 334 is used to serve both. According to an example implementation of the present disclosure, the SDK layer 330 can be implemented using multiple development languages. In software development, Rust, as a modern development language, offers advantages such as low overhead, cross-platform support, strong typing, and memory safety. Furthermore, Rust can be used to implement the SDK layer 330 due to its friendly technical community and rapidly developing ecosystem. According to an example implementation of the present disclosure, user identity needs to be considered during acquisition device management. Specifically, to generate an executable file for managing capture devices, the system can detect user calls to live broadcast management tools. Upon detecting such calls, permissions corresponding to the user's type can be assigned, allowing capture devices to be managed based on these permissions. Specifically, the link-in management process can be tailored to the specific types of hosts, guests, and viewers. A host can be the host who created the live broadcast room, a guest is an audience member who has connected to a microphone, and a viewer is an ordinary user who has not yet connected to a microphone and can only view the host and guest's media data.4 for more details on permission management. FIG4 illustrates a block diagram 400 for managing acquisition devices according to various types of permissions according to some implementations of the present disclosure. As shown in FIG4 , if the user type is determined to be a live streamer 410, corresponding permissions 412 may be assigned to the user. Permission 412 may allow the user to perform at least one of the following actions: Open a live stream room, which allows the user to create a new live stream room in the live streaming application, and the user will become the host of the new live stream room; Close a live stream room, which allows the host to close the live stream room of which they are the host, but does not allow the host to close the live stream rooms of other hosts; Invite a guest, which allows the host 410 to send an invitation to a viewer of the live stream room. If the viewer accepts the invitation, the viewer type will be changed to a guest; Remove a guest, which allows the host 410 to remove one or more current guests. For example, a guest can be removed after the guest's live broadcast ends, or when the host 410 determines that the live broadcast connection needs to be ended (the removed guest can, for example, continue to watch the live broadcast as an ordinary viewer of the live stream room, or can directly leave the live stream room); Receive requests, which allows the host 410 to receive requests submitted by viewers to activate their capture devices (i.e., connect to a live stream); and Adjust actions, which allow the host 410 to adjust the capture device status of their own, other connected hosts, or connected guests. For example, they can individually or separately adjust the microphone on / off, volume, camera on / off, color settings, filter settings, resolution, and so on. According to an example implementation of the present disclosure, if the user type is determined to be a guest 420, the user can be assigned corresponding permissions 422. Permissions 422 can allow the user to perform at least one of the following actions: Request to activate capture devices, which allows the viewer to submit a connect to a live stream request to the host. If the host accepts the connect to a live stream request, the viewer's type can be changed to guest; Accept a host's invitation, which allows the viewer to accept the host's connect to a live stream invitation. If the viewer cancels the invitation, the viewer's type will be changed to guest; and Adjust actions, which allow the guest 420 to adjust the status of their own capture device. According to an example implementation of the present disclosure, if a user type is determined to be a viewer 430, corresponding permissions 432 may be assigned to the user. Permissions 432 may allow the user to receive media data from guests and / or hosts. Specifically, a viewer can only view live media data but cannot provide their own media data to other users. Using this example implementation, the SDK layer 330 can utilize a permissions management mechanism to provide different control capabilities to different user types.Specifically, the SDK layer 330 can perform a type verification process each time it detects a call to a function. If a call to a function exceeds the current type permissions, the SDK layer 330 can reject the call and throw an exception to the service server to notify it of the illegal call. According to an example implementation of the present disclosure, the manager 360 in the SDK layer 330 can provide specific functions related to co-hosting management. For example, the manager 360 can include multiple managers, each performing different functions: a network manager 361, a list manager 362, a status 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, among others. Specifically, when using the live broadcast management tool 230 to manage acquisition devices, the network manager 361 in the live broadcast management tool 230 can be used to parse received network data. For example, the network manager 361 can issue an interface call request in an asynchronous thread and, after receiving a callback for the interface, parse the raw binary data (e.g., Protobuf data and / or JSON data) returned by the interface. Furthermore, the network manager 361 can store the received network data in an instance of the live broadcast management tool 230, for example, storing the parsed results in an instance of a Rust class structure. The network manager 361 can transmit the instance to the linker in the live broadcast management tool 230, so that the linker can communicate with the live broadcast application. For example, the instance can be passed back to the upper-level linker in the main thread. If an exception occurs in the request, the network manager 361 can throw the exception to the upper-level linker, thus completing the entire interface request process. According to an example implementation of the present disclosure, while the live broadcast management tool 230 is used to manage the capture device, the list 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 list manager 362 can be used to manage user lists with different statuses, thereby realizing the business logic of the live broadcast room.Here, the user list includes at least one of the following: a list of connected users, indicating one or more users who have entered the live studio; a list of users who have requested a connection, indicating one or more users who have requested a microphone connection from the host; a list of users who have been invited to connect, indicating one or more users to whom the host has sent a microphone connection invitation; a list of users waiting to connect, indicating one or more users who have connected to the live studio but have not yet received the first frame of content; a list of successfully connected users, indicating one or more users who have connected to the live studio and have received the first frame of content; a list of muted users, indicating one or more users who have muted their audio; and a list of users who have muted their video. According to an example implementation of the present disclosure, the list manager 362 can respond to changes in the user list through callbacks to the upper-level linker. Using this example implementation, the list manager 362 can collaborate with other components of the live studio management tool 230 to provide rich and independent list management capabilities. According to an example implementation of the present disclosure, during a live broadcast studio session, a user's status can constantly change. Upon detecting a change in a user's status, the list manager 362 can be used to update the user lists described above. See FIG5 for more details on user status changes, which shows a block diagram 500 of user type conversion according to some implementations of the present disclosure. As shown in FIG5 , after a user successfully performs the "join microphone" action 510, the user's type changes from audience 430 to guest 420. Join microphone 510 can, for example, be performed in response to a request from an audience member; alternatively and / or additionally, joining microphone 510 can also be performed in response to an invitation from a host. In this case, the relevant user lists described above will be updated. Further referring to FIG5 , after a user successfully performs the "leave microphone" action 520, the user's type changes from guest 420 to audience 430. For example, leaving the microphone 520 can be executed in response to a viewer's request to leave; alternatively and / or additionally, leaving the microphone 520 can also be executed in response to a disconnection request from the host. At this point, the relevant user lists described above will be updated. Using the example implementation of the present disclosure, the list manager 362 can continuously update each user list based on the latest received user status, ensuring that users of different types and statuses in the live studio can coordinate and participate in the various business logic of the live studio.According to an example implementation of the present disclosure, when managing capture devices using the live broadcast management tool 230, the state manager 363 within the live broadcast management tool 230 can detect user status changes. Upon detecting a status change, the state manager 363 can transmit the status change to the live broadcast application server, so that the server can distribute the status change to at least one other client device accessing the live broadcast room. Specifically, the state manager 363 can receive and / or transmit information about the audio and video status, backend status, and audio usage status of each connected user. This information can be communicated to the live broadcast application server via an upstream path. When the server device detects a status change for a connected user, it can notify other users in the live broadcast room via a downstream path. In this way, each user in the live broadcast room can promptly perceive other users' status changes and adjust the interface presented on their local client device accordingly. According to an example implementation of the present disclosure, when managing capture devices using the live broadcast management tool 230, the communication manager 364 within the live broadcast management tool 230 can manage user control parameters. Here, the control parameters may include at least one of the following: startup parameters associated with data transmission in the live broadcast room, startup parameters associated with the capture device, entry parameters for entering the live broadcast room, and exit parameters for exiting the live broadcast room. Specifically, based on real-time communication (RTC) technology, the communication manager 364 can continuously collect parameters injected by various client devices running the live broadcast application. Using an example implementation of the present disclosure, the communication manager 364 can independently and effectively manage the various control parameters involved in the live broadcast process. In this way, the normal operation of the live broadcast room can be ensured in real time based on the latest control parameters. According to an example implementation of the present disclosure, when the live broadcast management tool 230 manages the capture device, the enhancement manager 365 in the live broadcast management tool 230 can be used to transmit media data collected by the capture device to the server device of the live broadcast application, so that the server device can distribute the media data to at least one other client device accessing the live broadcast room. Here, for example, the enhancement manager 365 may be implemented based on supplemental enhancement information (SEI), and the enhancement manager 365 may continuously follow the media data of the host and / or guest according to a predetermined period and deliver the data to each viewer.Specifically, the enhancement manager 365 can be used to transmit at least any of the following parameters: client device screen parameters, capture device status parameters (e.g., microphone on / off status, volume, etc.), and capture device presentation location (e.g., where on the screen the captured media data is presented). For example, these parameters can be transmitted to other client devices via a server device. Using an example implementation of the present disclosure, the enhancement manager 365 can manage more detailed information involved in the operation of a live broadcast room, thereby facilitating coordinated operations among multiple modules to achieve the overall functionality of the live broadcast room. According to an example implementation of the present disclosure, while managing the capture devices using the live broadcast management tool 230, the report manager 367 within the live broadcast management tool 230 can be used to report predetermined information to the live broadcast application server. For example, the runtime of each live broadcast room, the number of online participants, and so on can be counted and reported. This allows the server device to gain a comprehensive understanding of the status of each live broadcast room, thereby adjusting various resource configurations on the server device accordingly, thereby ensuring the operation of the live broadcast application. According to an example implementation of the present disclosure, when managing capture devices using the live broadcast management tool 230, the location manager 368 within the live broadcast management tool 230 can be used to manage the presentation location of media data of at least one user associated with the live broadcast room. For more details regarding location management, see FIG6 , which shows a block diagram 600 of an interface for presenting media information according to some implementations of the present disclosure. As shown in FIG6 , in the live broadcast application interface 630, media data of at least one user can be presented on the client device based on the presentation location of the at least one user's media data. Assuming that the presentation locations of the host and guest are 612 and 622, respectively, presentation location 612 represents the first location in interface 630, and presentation location 622 represents the second location in interface 630. As shown in FIG6 , the host's media data 610 can be presented on the left side of interface 630, while the guest's media data 620 can be presented on the right side. It should be understood that FIG6 merely schematically illustrates an example of presenting media data of various users in different locations. When there are more or fewer hosts and guests, the corresponding media data can be presented in a similar manner. For example, when there is only one host, the host's media data can be presented in the center of interface 630. For another example, when there is one host and three guests, the media data of each host 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 hosts and / or guests changes, the layout of interface 630 can be adjusted in real time. In this way, corresponding media data can be presented in different layouts, thereby managing the interface display of the live broadcast application in a more convenient manner for viewers. According to an exemplary implementation of the present disclosure, when using the live broadcast management tool 230 to manage acquisition devices, the message manager 369 in the live broadcast management tool 230 can be used to obtain message data from the live broadcast application server. Furthermore, the parsed results 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 to communicate with the live broadcast application via the linker. 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 can be raw binary data (for example, in Protobuf and / or JSON format). In this case, the message manager 369 can parse the raw binary data and store the parsed results in an instance of the Rust class structure. At this point, the linker can perform the corresponding communication via the corresponding interface. In this way, the message manager 369 can manage communication with the server in a simple and effective manner, thereby fulfilling the intended functionality of the live broadcast application. Returning to Figure 3, the base layer 340 may include multiple modules for receiving data injection from the underlying layers: a network module 342, a logging module 344, an audio / video module 346, and so on. The SDK layer 330 does not have a corresponding runtime or other dependencies, and therefore relies on the host (e.g., the live broadcast application running on each client device) to request capabilities from the SDK layer 330 through injection. According to an example implementation of the present disclosure, the method described above can be executed on the client device. For example, the live broadcast management tool 230 can be used to develop a live broadcast application. Specifically, when developing a live broadcast application that runs on different platforms, the business logic can be separated from the underlying general logic for microphone connection management. The underlying logic for live broadcast management can be implemented by directly calling various functions encapsulated in the live broadcast management tool 230. The upper-layer business logic then executes the corresponding calls via various interfaces in the connector 350. Client device platforms can include mobile device operating systems (e.g., iOS and Android) and desktop operating systems (e.g., PC operating systems). This allows for simpler and more efficient management of live broadcasts across multiple development languages ​​and platforms.Having described the specific functions of the various modules of the live broadcast management tool 230, the following describes the operation of a live broadcast room implemented using the live broadcast management tool 230, with reference to FIG7 . FIG7 illustrates a block diagram 700 of state transitions during an invitation process according to some implementations of the present disclosure. Specifically, FIG7 illustrates the process of a host 410 inviting a guest 420, i.e., the overall process of a live broadcast session. The left side of FIG7 illustrates the state changes of the host 410, while the right side illustrates the state changes of the guest 420. Initially, the host 410 and the guest 420 are in the "Idle" state 710 and 720, respectively. The host 410 can issue an invitation 730, at which point the host 410 will enter the "Waiting For Invite Reply" state 711, awaiting a response from the guest 420. After sending the invitation to the guest 420, the host 410 can begin 732 entering the live broadcast room (e.g., an RTC room). At this time, the host 410's status changes to WaitingForInviteReply and "starting to enter the live broadcast room (JoiningChannel)". Entering the live broadcast room can be an asynchronous process. On the guest 420 side, the guest 420 can receive 731 the invitation to connect with the host 410, and then enter the "Receive invitation" state 721. When the guest 420 starts 740 to enter the live broadcast room, the guest 420's status 722 changes to Receive invitation and JoiningChannel. After the guest 420 accepts 741 the invitation to connect with the host, the guest 420's status 723 can change to JoiningChannel. At this time, the host 410 successfully enters 733 the live broadcast room, and the host 410 can receive a callback of successful entry, and then the host 410's status 713 changes to WaitingForInviteReply and "successfully entered the live broadcast room (JoinedChannel)". At this point, host 410 can begin pushing their own media data. If host 410 receives a response 742 from guest 420 agreeing to the invitation, host 410's status 714 changes to JoinedChannel. Guest 420 has successfully entered the live broadcast room 743, and guest 420's status 724 changes to JoinedChannel. Guest 420 can then begin pushing their own media data.After receiving the first frame of data from host 410 at 744 , guest 420's status 725 changes to "Linked," indicating that guest 420 has successfully connected to the microphone. Subsequently, after receiving the first frame of data from guest 420 at 734 , host 410's status 715 changes to "Linked," indicating that host 410 has also successfully connected to the microphone. After a period of time, guest 420 can leave 745 (for example, by actively ending the connection via the leave interface). Guest 420 can clear all temporary data related to the connection, at which point guest 420's status 726 changes to "Finished." After host 410 receives 746 a message indicating guest 420's departure, host 410 can determine whether there are other users connected to the microphone. If no other users are connected to the live broadcast, host 410 can clear all temporary data related to the live broadcast. At this point, host 410's status 716 changes to "Finish," and the entire live broadcast process ends. It should be understood that while the above only schematically illustrates the live broadcast process in which host 410 invites guest 420, host 410 can alternatively and / or additionally invite another host to join the live broadcast, and the process can be similar to that shown in FIG7 . According to an example implementation of the present disclosure, one or more hosts and / or guests can be invited in the manner shown in FIG7 to achieve a multi-person live broadcast within the live broadcast room. According to an example implementation of the present disclosure, a viewer can proactively send a live broadcast request to the host, and with the host's permission, the viewer can be converted to a guest. The proactive request process is similar to that shown in FIG7 , except that the viewer on the right now proactively sends a live broadcast request to host 410. Using exemplary implementations of the present disclosure, the live broadcast management tool 230 can encapsulate the core logic related to live broadcast room co-hosting operations, thereby managing each user's capture devices in a more convenient and efficient manner within the live broadcast application. Example Process Figure 8 shows a flowchart of a method 800 for managing capture devices according to some implementations of the present disclosure. At block 810, in response to detecting a target object accessing a live broadcast room within a live broadcast application, the target object's type is determined. At block 820, the platform type of the client device running the live broadcast application is obtained. At block 830, based on the target object's type and platform type, the live broadcast management tool is used to manage the client device's capture devices. According to an exemplary implementation of the present disclosure, managing the capture devices by the live broadcast management tool includes: determining the development language of the live broadcast application running on the client device based on the platform type; generating a language function interface associated with the development language; and invoking the live broadcast management tool via the language function interface.According to an example implementation of the present disclosure, invoking a live broadcast management tool via a language function interface includes: generating an executable file for managing acquisition devices using the live broadcast management tool; converting the executable file into executable code in a development library format corresponding to the platform type; and invoking the executable code via the language function interface to manage the acquisition devices. According to an example implementation of the present disclosure, managing the acquisition devices using the live broadcast management tool includes: parsing received network data using a network manager within the live broadcast management tool; storing the network data in an instance of the live broadcast management tool; and transmitting the instance to a linker within the live broadcast management tool for communication with a live broadcast application via the linker. According to an example implementation of the present disclosure, managing the acquisition devices using the live broadcast management tool includes: detecting a state change of a target object using a state manager within the live broadcast management tool; and, in response to detecting a state change, transmitting the state change to a server of the live broadcast application, so that the server distributes the state change to at least one other client device accessing the live broadcast room. According to an example implementation of the present disclosure, managing a capture device using a live broadcast management tool includes: utilizing a communication manager within the live broadcast management tool to manage control parameters of a target object, where the control parameters include at least one of the following: startup parameters associated with data transmission within the live broadcast room, startup parameters associated with the capture device, entry parameters for entering the live broadcast room, and exit parameters for exiting the live broadcast room. According to an example implementation of the present disclosure, managing a capture device using the live broadcast management tool includes: utilizing an enhancement manager within 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 accessing the live broadcast room. According to an example implementation of the present disclosure, the method further includes: utilizing the enhancement manager to transmit at least one of the following parameters to the server device: screen parameters of the client device, status parameters of the capture device, and presentation position of the capture device. According to an example implementation of the present disclosure, managing acquisition devices using a live broadcast management tool includes: utilizing a location manager within the live broadcast management tool to manage the presentation location of media data of at least one target object associated with a live broadcast room; and presenting the media data of the at least one target object on a client device based on the presentation location of the media data of the at least one target object. According to an example implementation of the present disclosure, managing acquisition devices using the live broadcast management tool includes: utilizing a message manager within the live broadcast management tool to obtain message data from a server of a live broadcast application; storing parsed results of the message data in an instance of the live broadcast management tool; and transmitting the instance to a linker within the live broadcast management tool for communication with the live broadcast application via the linker.According to an example implementation of the present disclosure, the method is executed on a client device. The development language of the live streaming application depends on the platform type, which includes at least one of the following: a mobile device-based operating system and a desktop device-based operating system. Example Apparatus and Devices FIG9 shows a block diagram of an apparatus 900 for managing acquisition devices according to some implementations of the present disclosure. 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 has accessed a live streaming room in a live streaming application; an acquisition module 920 configured to acquire the platform type of the client device running the live streaming application; and a management module 930 configured to manage the acquisition devices of the client device using a live streaming management tool based on the target object type and the platform type. According to an example implementation of the present disclosure, the management module includes: a language determination module configured to determine the development language of the live streaming application running on the client device based on the platform type; a generation module configured to generate a language function interface associated with the development language; and a calling module configured to call the live streaming management tool via the language function interface. According to an example implementation of the present disclosure, the calling module includes: an executable file generation module configured to generate an executable file for managing acquisition devices using a live broadcast management tool; a conversion module configured to convert the executable file into executable code in a development library format corresponding to the platform type; and an interface calling module configured to call the executable code via a language function interface to manage the acquisition devices. 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 within the 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 within the live broadcast management tool for communication with the live broadcast application via the linker. According to an example implementation of the present disclosure, the management module includes: a detection module configured to use 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 the state change, so that the server distributes the state change to at least one other client device used to access the live broadcast room.According to an example implementation of the present disclosure, a management module includes a control module configured to manage control parameters of a target object using a communication manager within a live broadcast management tool. The control parameters include at least one of the following: startup parameters associated with data transmission within 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. According to an example implementation of the present disclosure, the management module includes an enhancement module configured to utilize the enhancement manager within 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 can distribute the media data to at least one other client device accessing the live broadcast room. 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 one of the following parameters to the server device: screen parameters of the client device, status parameters of the capture device, and presentation position of the capture device. According to an example implementation of the present disclosure, a 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 using a location manager in a live broadcast management tool; and a presentation module configured to present the media data of the at least one target object on a client device based on the presentation location of the media data of the at least one target object. According to an example implementation of the present disclosure, the management module includes: a message acquisition module configured to acquire message data from a live broadcast application server using a message manager in the live broadcast management tool; a result storage module configured to store the parsed results 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 for communication with the live broadcast application via the linker. According to an example implementation of the present disclosure, the apparatus is executed on a client device, and the development language of the live broadcast application depends on the platform type, which includes at least one of the following: a mobile device-based operating system and a desktop device-based operating system. Figure 10 shows a block diagram of a device 1000 capable of implementing various implementations of the present disclosure. It should be understood that the computing device 1000 shown in FIG. 10 is merely exemplary and should not be construed to limit the functionality and scope of the implementations described herein. The computing device 1000 shown in FIG. 10 can be used to implement the methods described above. As shown in FIG. 10 , the computing device 1000 is in the form of a general-purpose computing device.The 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 a real 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. Computing device 1000 typically includes multiple computer storage media. Such media can be any available media accessible to computing device 1000, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 1020 may be volatile memory (e.g., register, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 1030 may be removable or non-removable media and may include machine-readable media such as a flash drive, a magnetic disk, or any other media that can be used to store information and / or data (e.g., training data for training) and accessed within computing device 1000. Computing device 1000 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not shown in FIG. 10 , a magnetic disk drive for reading from or writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, non-volatile optical disk may be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 1020 can include a computer program product 1025 having one or more program modules configured to perform various methods or actions of various implementations of the present disclosure. Communication unit 1040 enables communication with other computing devices via a communication medium. Additionally, the functionality of the components of computing device 1000 can be implemented in a single computing cluster or multiple computing machines capable of communicating via a communication connection. Thus, computing device 1000 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or other network nodes. Input device 1050 can be one or more input devices, such as a mouse, keyboard, trackball, etc.Output device 1060 may be one or more output devices, such as a display, a speaker, a printer, and the like. Computing device 1000 may also communicate with one or more external devices (not shown) via communication unit 1040 as needed. External devices such as storage devices, display devices, and the like may communicate with one or more devices that enable a user to interact with computing device 1000, or with any device that enables 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). According to an exemplary implementation of the present disclosure, a computer-readable storage medium is provided, having computer-executable instructions stored thereon. 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. 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, which stores a computer program that, when executed by a processor, implements the method described above. Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of the methods, apparatuses, devices, and computer program products implemented according to the present disclosure. It should be understood that each block in the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions. 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 such that, when executed by the processing unit of the computer or other programmable data processing device, these instructions generate a device that implements the functions / actions specified in one or more blocks in the flowcharts and / or block diagrams. Alternatively, these computer-readable program instructions can be stored in a computer-readable storage medium. These instructions cause the computer, programmable data processing device, and / or other device to operate in a specific manner. Thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing various aspects of the functions / actions specified in one or more blocks in the flowcharts and / or block diagrams.Computer-readable program instructions can be loaded onto a computer, other programmable data processing device, or other device, causing the computer, other programmable data processing device, or other device to execute a series of operational steps to produce a computer-implemented process. Consequently, the instructions executed on the computer, other programmable data processing device, or other device implement the functions / actions specified in one or more blocks in the flowcharts and / or block diagrams. The flowcharts and block diagrams in the accompanying drawings illustrate possible architectures, functions, and operations of systems, methods, and computer program products according to various implementations of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a module, program segment, or portion of an instruction, each of which contains one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions noted in the blocks may occur in an order different from that noted in the accompanying drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flow charts, as well as combinations of blocks in the block diagrams and / or flow charts, can be implemented using a dedicated hardware-based system that performs the specified functions or actions, or can be implemented using a combination of dedicated hardware and computer instructions. Various implementations of the present disclosure have been described above. The above descriptions are illustrative, not exhaustive, and are not limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is selected to best explain the principles, practical applications, or improvements to existing technologies of each implementation, or to enable others skilled in the art to understand the various implementations disclosed herein.

Claims

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; And 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; And calling the live broadcast management tool 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; and calling the execution code 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; And transmitting the instance 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, transmitting the change in state 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, wherein the control parameters include at least one of the following: a startup parameter associated with the data transmission of the live broadcast room, a startup parameter associated with the acquisition The device-associated startup parameters, the entry parameters for entering the live broadcast room, and the 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; And based on the presentation position of the media data of the at least one target object, presenting the media data of the at least one target object 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; And transmitting the instance to a linker in a live broadcast management tool so as to communicate with the live broadcast application via the linker. 1 1. The method according to claim 1, wherein the method is executed at the client device, 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 a collection device 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; and a management module 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; and at least one memory 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 execute 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 enabled to implement the method according to any one of claims 1 to 11.

Images