Method, apparatus, device, medium and product for managing remote media device

Abstract

This application relates to the field of device management technology, and discloses a method, apparatus, device, medium, and product for managing remote media devices. The method includes: acquiring real-time status information of the remote media device; when the real-time status information indicates the addition of a first remote media device, registering and enabling a first virtual media device corresponding to the first remote media device in the local operating system; when the real-time status information indicates that a second remote media device is unavailable, disabling and deregistering a second virtual media device corresponding to the second remote media device in the local operating system; and controlling the target media data link corresponding to the target remote media device based on the consumption status of each enabled target virtual media device. The target remote media device corresponds to the target virtual media device. This application can dynamically mount and unmount virtual media devices corresponding to remote media devices, preventing local applications from selecting currently unavailable virtual media devices.

Description

Technical Field

[0001] This application relates to the field of equipment management technology, specifically to methods, devices, equipment, media, and products for managing remote media devices. Background Technology

[0002] In meeting scenarios, users typically use their own laptops or tablets to join meetings, log in, share documents, and control the meeting flow, while the large screen in the meeting room is often connected to cameras, array microphones, and speakers that are more suitable for multi-person meetings. This Bring Your Own Meeting (BYOM) scenario aims to allow local meeting applications to continue running on the user's own device, while turning the existing audio and video equipment in the meeting room on the large screen into selectable cameras, microphones, and speakers in the local system.

[0003] To enable local devices to access the conference room's audio and video equipment, some solutions fix virtual audio and video devices locally and associate them with remote physical audio and video devices for use by third-party applications. However, this solution struggles to dynamically update the local list of available devices as remote devices appear or are removed, affecting the normal use of remote devices. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, device, medium and product for managing remote media devices to solve the problem that local terminal devices cannot dynamically use remote devices.

[0005] In a first aspect, this application provides a method for managing a remote media device, applied to a terminal device, the method comprising: Obtain real-time status information of remote media devices; When the real-time status information indicates the addition of a first remote media device, the first virtual media device corresponding to the first remote media device is registered and enabled in the local operating system; If the real-time status information indicates that the second remote media device is unavailable, the second virtual media device corresponding to the second remote media device is disabled and deregistered in the local operating system. Monitor the consumption status of each enabled target virtual media device, and control the target media data link corresponding to the target remote media device based on the consumption status of the target virtual media device; the target remote media device corresponds to the target virtual media device, and the consumption status is used to indicate whether the target virtual media device is being used.

[0006] Secondly, this application provides a management device for a remote media device, applied to a terminal device, the device comprising: The acquisition module is used to acquire real-time status information of remote media devices; The mounting module is used to register and enable the first virtual media device corresponding to the first remote media device in the local operating system when the real-time status information indicates that a new first remote media device has been added. The uninstallation module is used to disable and deregister the second virtual media device corresponding to the second remote media device in the local operating system when the real-time status information indicates that the second remote media device is unavailable. The processing module is used to monitor the consumption status of each enabled target virtual media device, and control the target media data link corresponding to the target remote media device based on the consumption status of the target virtual media device; the target remote media device corresponds to the target virtual media device, and the consumption status is used to indicate whether the target virtual media device is being used.

[0007] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the remote media device management method of the first aspect or any corresponding embodiment described above.

[0008] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to execute the remote media device management method of the first aspect or any corresponding embodiment described above.

[0009] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to execute the remote media device management method of the first aspect or any corresponding embodiment described above.

[0010] The remote media device management method provided in this application embodiment allows the local terminal device to obtain real-time status information of the remote media device. The terminal device dynamically mounts a local virtual media device when the remote media device appears or resumes operation, and dynamically unmounts the local virtual media device when the remote media device is removed or disconnected. This enables the local operating system to register, enable, disable, and deregister the corresponding virtual media device in real time based on changes in the remote media device's status, achieving dynamic management of the local virtual media device's lifecycle. It can dynamically update the list of available local virtual media devices in real time with the appearance or removal of the remote media device, preventing local applications from selecting currently unavailable virtual media devices. Furthermore, local applications can select enabled virtual media devices from the system's standard device list without integrating a dedicated SDK for user-detected virtual devices, making it suitable for various applications. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the specific embodiments of this application or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0012] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application; Figure 2 This is a schematic diagram of a first method for managing remote media devices according to an embodiment of this application; Figure 3 This is a schematic diagram of an overall architecture for remote device management according to an embodiment of this application; Figure 4 This is a timing diagram illustrating the mounting and unmounting of a local virtual media device according to an embodiment of this application; Figure 5 This is a second flowchart illustrating a method for managing remote media devices according to an embodiment of this application; Figure 6 This is a schematic diagram of the state machine of a virtual media device according to an embodiment of this application; Figure 7 This is a schematic diagram of a process for dynamically mounting and unmounting virtual media devices according to an embodiment of this application; Figure 8 This is a structural block diagram of a management device for a remote media device according to an embodiment of this application; Figure 9 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] It is understood that before using the technical solutions disclosed in the various embodiments of this application, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this application in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0015] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0016] Before providing a detailed description of the embodiments of this application, some of the terms and concepts involved in the embodiments of this application will be explained. These explanations are intended to make the embodiments of this application easier to understand and should not be considered as limiting the scope of protection claimed in this application.

[0017] (1) BYOM (Bring Your Own Meeting): refers to a local device such as a laptop or tablet that carries the meeting application and can connect to the existing camera, microphone and speaker on the conference room's large screen.

[0018] (2) Meeting application carrier: Local laptop, tablet or other personal device running meeting applications, responsible for running third-party meeting applications and selecting system audio and video devices.

[0019] (3) Capability provider: The conference room large screen or a set of cameras, microphones and speakers bound to the large screen can provide remote audio and video capabilities.

[0020] (4) Remote real capability: The actual and working camera acquisition capability, microphone acquisition capability, or speaker playback capability of the capability provider.

[0021] (5) Local virtual media devices: Virtual cameras, virtual microphones or virtual speakers that are registered and enabled in the operating system of the conferencing application and can be selected by third-party conferencing applications.

[0022] Third-party conferencing applications typically only recognize standard audio and video devices that the operating system has already enumerated. If a remote camera, microphone, or speaker exists only in a private bridging link and does not form a corresponding virtual device in the local system, the third-party conferencing application cannot select these remote capabilities as if using native devices.

[0023] Furthermore, in a meeting scenario, the presence of remote, real-world capabilities or the mounting of local virtual devices does not equate to the user actually beginning to use media capabilities. Immediately activating the large-screen camera capture, microphone capture, or speaker playback link after mounting can easily lead to privacy concerns, accidental triggering of playback during the event, and unnecessary consumption of computing power and network resources. Therefore, a clear boundary needs to be established between "remote, real-world capabilities driving locally visible devices" and "media activation only after the local meeting application has actually used the device."

[0024] A common approach is to connect the conference room's cameras, microphones, or speakers directly to the local laptop via wired connections such as HDMI (High Definition Multimedia Interface), USB (Universal Serial Bus), or Type-C. Once connected, the local conferencing application selects these wired peripherals from the system's list of cameras, microphones, and speakers, thus utilizing the conference room's hardware capabilities.

[0025] The above-mentioned wired direct connection solution has at least the following problems: (1) On-site wiring and plugging and unplugging are required. The use of the conference room desktop, interface type, cable length and compatibility will all affect the use. (2) Local devices can only see the peripherals physically connected to the local device. It is difficult to dynamically present the existing devices on the large screen as the devices that can be selected by the local device according to the actual changes in the remote device's capabilities. (3) Once the device is recognized by the local device, the peripheral is usually in a state that can be opened by the conference application. The boundary of the remote media is not activated only when the local conference application actually consumes the data. (4) When switching between multiple users or multiple conferences, cable occupation and device occupation can easily cause the on-site management of the conference room to become complicated.

[0026] Another option is to deploy a hardware box in the meeting room. One end of the hardware box connects to the meeting room's camera, microphone, and speakers, while the other end transmits the simulated camera, microphone, and speakers to a local laptop via USB, wireless projection, or a dedicated protocol. The local meeting application sees the audio and video equipment simulated by the hardware box, while the actual media comes from the external equipment outside the meeting room.

[0027] The hardware box-based device emulation solution reduces some wiring complexity compared to the wired direct connection solution, but it still has the following problems: (1) Hardware boxes are usually based on fixed device simulation, focusing on making the local computer see the device. They may not be able to dynamically mount / unmount the local virtual device as the remote real camera, microphone, and speaker appear, are removed, or are switched. (2) If the hardware box starts the conference room camera acquisition, microphone acquisition, or speaker playback link after the connection or device simulation is completed, it will cause idle acquisition, premature occupation, or misplay. If the local meeting application only enumerates the device list or the user only completes the device selection, the remote real camera and microphone should not start acquisition. (3) Hardware box solutions usually rely on dedicated hardware. The system expansion and the ability to update the local device list according to changes in the remote real capabilities are limited by the hardware implementation.

[0028] Another approach is to pre-install fixed virtual cameras, microphones, or speakers on the local system. Third-party conferencing applications can then select these virtual devices, which are then populated with remote media by a bridging program.

[0029] While static virtual device solutions allow third-party conferencing applications to treat remote devices as local devices, they are not driven by the actual capabilities of the remote device for mounting / unmounting, which presents the following problems: (1) When the remote screen does not have a camera, microphone or speaker, the local system may still display the corresponding virtual device, and the third-party conferencing application will select the device that is not actually available; (2) After the real device at the remote end changes, the local virtual device list cannot be updated in time, and it is difficult for users to judge the current available capabilities from the conferencing application device list; (3) Fixed virtual devices may exist for a long time when there are no remote capabilities, which can easily cause misselection, black screen, no sound or misplay; (4) If the media is pulled immediately after the static virtual device is enumerated, it still cannot solve the problem that the device is visible but the application is not actually in use.

[0030] As one optional application scenario in the embodiments of this application, such as Figure 1 As shown, application 101 is installed in terminal device 110, and user 130 can interact with application 101 through terminal device 110 and / or access device of terminal device 110.

[0031] For example, application 101 can be any application. For instance, application 101 could be a third-party conferencing application, video calling application, music player, etc. Figure 1 In the application scenario shown, if application 101 is active, the terminal device 110 can display the interface 102 of application 101. The interface 102 may include various pages that application 101 can provide, such as interactive pages, settings pages, query pages, etc.

[0032] In some embodiments, terminal device 110 is communicatively connected to remote device 120 to provide services to application 101. Terminal device 110 may be a mobile terminal, fixed terminal, or portable terminal, including but not limited to mobile phones, desktop computers, laptop computers, multimedia tablets, e-book devices, gaming devices, or any combination thereof, including accessories and peripherals of these devices or any combination thereof. In some embodiments, terminal device 110 may also support any type of interface, and remote device 120 has a physical media device 121, which can provide accessible media device 110; remote device 120 may be, for example, a conference room screen, a classroom screen device, etc., and media device 121 may include one or more of a camera, microphone, and speaker.

[0033] It should be noted that, Figure 1 This is merely an example of an application scenario and does not limit the scope of protection of this application.

[0034] This application provides a method for managing remote media devices. A local terminal device can obtain real-time status information of the remote media device. When the remote media device appears or recovers, the terminal device dynamically mounts a local virtual media device. When the remote media device is removed or disconnected, the local virtual media device is dynamically unmounted. This allows the local operating system to register, enable, disable, and deregister the virtual media device corresponding to the remote media device in real time according to the changes in the remote media device's status. This enables dynamic management of the lifecycle of the local virtual media device and allows for real-time updates of the list of available local virtual media devices as the remote media device appears or is removed, preventing local applications from selecting currently unavailable virtual media devices.

[0035] According to an embodiment of this application, a method for managing a remote media device is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] This embodiment provides a method for managing remote media devices, which can be used with the aforementioned terminal devices, such as mobile terminals like mobile phones and tablets. Figure 2 This is a flowchart of a remote media device management method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps.

[0037] Step S201: Obtain the real-time status information of the remote media device.

[0038] In this embodiment, when the local terminal device needs to use the audio, video, or other media capabilities of the remote device, it can obtain the relevant status information of the remote media device in real time, i.e., real-time status information. The remote media device is a media device located at a remote location that can provide the required media capabilities to the local terminal device; for example, the remote media device can be a video capture device (such as a camera), an audio capture device (such as a microphone), or an audio playback device (such as a speaker) of the remote device (e.g., a conference room large screen).

[0039] Terminal devices can proactively acquire real-time status information of remote media devices; alternatively, remote devices themselves have real-time status sensing capabilities and send the sensed real-time status information to the terminal devices.

[0040] In this embodiment, the local terminal device mainly focuses on the status changes of the remote media device. Therefore, if the remote device actively provides real-time status information to the local terminal device, the remote device can send the real-time status information to the local terminal device only when the status of the remote media device changes.

[0041] Step S202: If the real-time status information indicates the addition of a first remote media device, register and enable the first virtual media device corresponding to the first remote media device in the local operating system.

[0042] In this embodiment, the terminal device can create corresponding virtual media devices for each remote media device locally, and dynamically manage the lifecycle of the virtual media devices corresponding to the remote media devices based on the real-time status information of each remote media device, so as to create, register, enable, disable or remove local virtual media devices according to changes in the actual capabilities of the remote devices.

[0043] Specifically, when a first remote media device is added remotely, the terminal device can obtain the corresponding real-time status information. At this time, the terminal device can register and enable the first virtual media device corresponding to the first remote media device in the local operating system, that is, to complete the dynamic mounting of the first virtual media device, so that the first virtual media device enters the enumerable and selectable state of the local application (such as a third-party conferencing application).

[0044] Specifically, when a terminal device first connects to a remote device, all media devices of the remote device are considered newly added first remote media devices for that terminal device; or, if a new media device is added to the remote device after the terminal device has connected to it, the newly added media device is also considered the first remote media device.

[0045] After the first virtual media device is mounted to the local operating system, for applications installed on the terminal device, this first virtual media device is the same as the local physical media device and can be recognized by the application; that is, the application can enumerate the first virtual media device. For example, the application can be a third-party conferencing application, recording application, or other application that can select to use a media device.

[0046] Step S203: If the real-time status information indicates that the second remote media device is unavailable, disable and deregister the second virtual media device corresponding to the second remote media device in the local operating system.

[0047] As shown above, remote media devices have multiple states. Similar to step S202, when a second remote media device is added, the local terminal device will also register and enable the corresponding second virtual media device in its local operating system. It can be understood that the second remote media device and the first remote media device can be the same remote media device or different remote media devices; this embodiment does not limit this.

[0048] Furthermore, if the real-time status information of the second remote media device indicates that the second remote media device is unavailable—for example, if the second remote media device has been deleted (e.g., the user has unplugged the second remote media device physically connected to the remote large screen), or if the session between the second remote media device and the local terminal device has ended—then it can be determined that the second remote media device is unavailable. In this case, the terminal device will promptly disable and deregister the second virtual media device corresponding to the second remote media device in its local operating system to dynamically unload the second virtual media device, effectively removing it.

[0049] After that, local applications such as third-party conferencing applications will no longer be able to use the second virtual media device; that is, local applications cannot discover the second virtual media device through enumeration.

[0050] Through the above steps S202 and S203, the lifecycle of the virtual media devices corresponding to each remote media device can be dynamically managed, such as creating, registering, enabling, disabling or removing the corresponding virtual media devices.

[0051] Step S204: Monitor the consumption status of each enabled target virtual media device, and control the target media data link corresponding to the target remote media device based on the consumption status of the target virtual media device; the target remote media device corresponds to the target virtual media device, and the consumption status is used to indicate whether the target virtual media device is being used.

[0052] In this embodiment, the terminal device supports the creation of one or more virtual media devices. For any virtual media device, if it has been enabled, the terminal device will monitor the consumption status of the virtual media device in real time. The consumption status can indicate whether the virtual media device is being used. For ease of description, the currently enabled virtual media device is referred to as the "target virtual media device".

[0053] For example, if a terminal device obtains real-time status information indicating the addition of a remote media device, it can register and start the remote media device, and then use that remote media device as a target remote media device to monitor its consumption status. It can be understood that both the first and second remote media devices mentioned above can be monitored as a target remote media device.

[0054] For each enabled target virtual media device, the terminal device can adaptively control the target media data link corresponding to the target remote media device based on whether the target virtual media device is used by a local application (such as a third-party conferencing application). For example, when the local application starts using the target virtual media device, the target media data link is created; when the local application stops using the target virtual media device, the target media data link is disabled or deleted.

[0055] It is understood that the above steps S202 to S204 may be executed in parallel or sequentially, depending on the actual state of the remote media device. This embodiment does not limit the execution order of each step.

[0056] Figure 3 This diagram illustrates an overall architecture for remote device management. (For example...) Figure 3 As shown, a remote agent component is provided for capability awareness and media control, namely the remote agent; the remote agent runs on the large screen side.

[0057] In step S31, the remote agent can perceive the status of the real remote media devices such as cameras, microphones, and speakers on the remote side in real time, and form real-time status information. This real-time status information can indicate whether the corresponding remote media device has appeared, been removed, or has been restored.

[0058] In step S32, the remote agent sends real-time status information to the local terminal device.

[0059] like Figure 3 As shown, the local terminal device mainly consists of a local bridging layer and a device management layer. These two layers cooperate based on real-time status information to achieve dynamic management of the virtual media device. These two layers will be explained in detail later. Specifically, the local bridging layer obtains real-time status information sent by the remote agent.

[0060] In addition, the remote agent can also obtain device parameters of the remote media device. These parameters may include: device type, device identifier, display name, supported formats, sampling rate or resolution, number of channels, etc. The remote agent can then send these device parameters to the local terminal device for its use.

[0061] In step S33, the local bridging layer sends a device management request to the device management layer based on real-time status information. Specifically, this device management request may instruct the device management layer to mount or unmount the corresponding local virtual media device.

[0062] In step S34, the device management layer, as the specific management executor, can manage the local virtual media devices according to the device management request. This includes tasks such as registering, enabling, disabling, and removing the corresponding virtual media devices.

[0063] If the remote agent also provides the device parameters of the remote media device, the device management layer can configure the corresponding virtual media device parameters according to the device parameters of the remote media device when creating the virtual media device. For example, the device parameters of the virtual media device can be set to match the actual capabilities of the remote device. For example, the device parameters of the two can be set to be completely consistent, or configured to be compatible formats.

[0064] It is understood that the device management request and the specific actions of the device management layer are related to the specific content of the implementation status information. For details, please refer to the relevant descriptions of steps S202 and S203, which will not be repeated here.

[0065] In step S35, the local application can enumerate the various media devices in the local terminal device through the system standard device list, which includes the terminal device's own physical media devices and enabled virtual media devices.

[0066] In step S36, the local bridging layer can monitor the consumption status of the local virtual media device in real time. If the local application chooses to use or stop using a certain virtual media device, the consumption status of the virtual media device will change and be detected by the local bridging layer, so that the local bridging layer can adaptively control the start and stop of the corresponding media data link.

[0067] For example, the local bridging layer can monitor whether the virtual media device has been opened by the user, whether there are frame read requests, and whether media data has arrived, thus determining the consumption status of the virtual media device.

[0068] In step S37, after the local bridging layer detects a change in the consumption status of the virtual media device, it can adaptively start or stop the corresponding media data links between remote agents.

[0069] In step S38, the remote agent can acquire media data collected by the remote media device (such as a camera, microphone, etc.) as needed, or provide the media data to be played to the remote media device (such as a speaker), depending on the actual situation.

[0070] Figure 4 A timing diagram illustrating the mounting and unmounting of a local virtual media device is shown. Figure 4As shown, when a new real remote media device is added on the remote side, the remote agent can detect the new remote capability and report the corresponding capability description. This description can include the real-time status information and device parameters of the remote media device. The local bridging layer determines that a corresponding local virtual media device needs to be created based on this capability description and initiates a mounting request to the device management layer. The device management layer generates a local virtual device identifier and display name for this remote capability and registers and enables the corresponding virtual media device in the local operating system, such as a camera, virtual microphone, or virtual speaker. Afterward, local applications (such as third-party conferencing applications) can enumerate the newly added virtual media device through the system's standard device list; that is, the local operating system returns a list of available devices containing the virtual media device. The local application can then use the virtual media device as needed.

[0071] When a remote media device is removed—for example, when the remote real capability is disconnected, no longer used as a target capability, or when the session ends—the remote agent can detect the removal of the remote real capability and report the disappearance of the remote real capability to the local terminal device. The local bridging layer responds to the capability disappearance message and initiates a request to the device management layer to uninstall the virtual media device. The device management layer then disables and deregisters the virtual media device to uninstall it. If the local application subsequently performs enumeration again, the list of available devices returned to the local application will no longer contain the aforementioned virtual media device; if the local application has already opened the virtual media device at this time, it will terminate the data stream corresponding to the virtual media device or enter a system-perceptible disconnected state.

[0072] It's understandable that local virtual media devices are not fixed in existence, nor are they solely determined by local installation actions. Instead, their dynamic mounting and unmounting are driven by the presence and status of remote real media devices such as cameras, microphones, and speakers. The local application enumerates standard local devices within the operating system, which can include all currently running virtual media devices, but excludes unregistered ones. This allows the local application to select remote media devices just as it would select the capabilities of the terminal device itself; when a remote real capability is no longer available, the corresponding local virtual media device ceases to be an available device.

[0073] The remote media device management method provided in this embodiment allows the local terminal device to obtain real-time status information of the remote media device. The terminal device dynamically mounts a local virtual media device when the remote media device appears or resumes operation, and dynamically unmounts the local virtual media device when the remote media device is removed or disconnected. This enables the local operating system to register, enable, disable, and deregister the corresponding virtual media device in real time based on changes in the remote media device's status, achieving dynamic management of the local virtual media device's lifecycle. It can dynamically update the list of available local virtual media devices in real time with the appearance or removal of the remote media device, preventing local applications from selecting currently unavailable virtual media devices. Furthermore, local applications can select enabled virtual media devices from the system's standard device list without integrating a dedicated SDK (Software Development Kit) for user-detected virtual devices, making it suitable for various applications.

[0074] This embodiment provides a method for managing remote media devices, which can be used with the aforementioned terminal devices, such as mobile terminals like mobile phones and tablets. Figure 5 This is a flowchart of a remote media device management method according to an embodiment of this application, such as... Figure 5 As shown, the process includes the following steps.

[0075] Step S501: Obtain the real-time status information of the remote media device.

[0076] Please see details Figure 2 Step S201 of the illustrated embodiment will not be described again here.

[0077] Step S502: If the real-time status information indicates the addition of a first remote media device, register and enable the first virtual media device corresponding to the first remote media device in the local operating system.

[0078] Please see details Figure 2 Step S202 of the illustrated embodiment will not be described again here.

[0079] Step S503: Perform a control plane warm-up operation on the first virtual media device. The control plane warm-up operation includes at least one of link connection maintenance, clock calibration, media device capability negotiation, and data format negotiation.

[0080] In this embodiment, after the first virtual media device is enabled in step S502, that is, after the first virtual media device is mounted, even if the first virtual media device is not used for the time being, the first virtual media device can be preheated first.

[0081] Specifically, after mounting the first virtual media device, a control plane warm-up operation is performed on the first virtual media device, meaning that this warm-up operation does not involve the data plane. A control plane channel and a data plane channel can be established between the local terminal device and the remote terminal. The control plane channel is used for remote capability reporting, device mounting / unmounting notifications, capability negotiation, consumer status notifications, start commands, and stop commands, etc.; the data plane channel is used for transmitting video frames, microphone audio frames, or speaker playback data after the corresponding media device is triggered by a consumer.

[0082] In this embodiment, the warm-up operation specifically includes link connection maintenance, that is, establishing a corresponding media data link with the first remote media device and keeping the media data link in a connected state. When the local application actually uses the first virtual media device later, it can immediately transmit data with the maintained media data link, thereby reducing the waiting time for the first use (e.g., the first video frame or audio frame).

[0083] In addition, the warm-up process may also include clock calibration, media device capability negotiation, data format negotiation, etc., depending on the actual situation.

[0084] It is understood that this warm-up operation only involves the control plane and does not perform any operations on the data plane. That is, the acquisition or playback of the real remote media device will not be started after the warm-up is completed. Afterwards, if the local bridging layer detects that the virtual media device meets the startup conditions (e.g., the virtual media device is being used), the corresponding real remote media device will then be started.

[0085] In some alternative implementations, after enabling the first virtual media device in step S502 above, the method further includes steps a1 to a2.

[0086] Step a1: Set the media data link corresponding to the first virtual media device to an invalid state; wherein, the media data link in the invalid state is prohibited from transmitting data.

[0087] Step a2: When the consumption state of the first virtual media device indicates that the first virtual media device has switched from an idle state to a used state, the media data link corresponding to the first virtual media device is switched to an effective state that allows data transmission.

[0088] In this embodiment, after mounting the first virtual media device, the media data link corresponding to the first virtual media device needs to be set to an invalid state to prevent data transmission through the media data link. Specifically, after mounting the first virtual media device, the creation of the media data link corresponding to the first virtual media device can be prohibited; that is, the media data link does not exist at this time and is therefore in an invalid state where data transmission is prohibited. Alternatively, if a media data link was established and maintained based on the warm-up operation in step S503 above, then it is necessary to prevent data transmission through this media data link. This can be achieved by configuring the driver of the virtual media device.

[0089] Furthermore, the local bridging layer can monitor the consumption status of the first virtual media device in real time. Initially, its consumption status is idle, meaning there are no consumers for the first virtual media device; for example, no local application is currently using the enumerated first virtual media device. If the first consumer appears later, i.e., a local application starts using the first virtual media device, the consumption status of the first virtual media device will switch from idle to active. At this time, the local bridging layer can switch the media data link corresponding to the first virtual media device to active status to allow data transmission, enabling data (such as video data, audio data, etc.) to be transmitted between the local application and the corresponding remote media device. In other words, the local application can use the remote media device normally.

[0090] In this embodiment, by controlling the link of the virtual media device that has been started, the remote media devices such as cameras and microphones are only started to collect data when the local application is actually using them. That is, the real camera and microphone are not started to collect data before the virtual media device is actually used, thus avoiding the premature collection of images and sounds during the mounting or enumeration phase of the virtual media device and effectively preventing privacy leaks.

[0091] Step S504: If the real-time status information indicates that the second remote media device is unavailable, disable and deregister the second virtual media device corresponding to the second remote media device in the local operating system.

[0092] Please see details Figure 2 Step S203 of the illustrated embodiment will not be described again here.

[0093] In some optional implementations, the method further includes: recording the mapping relationship between the first remote media device and the first virtual media device when the real-time status information indicates that a first remote media device has been added; and deleting the mapping relationship between the second remote media device and the second virtual media device when the real-time status information indicates that a second remote media device is unavailable.

[0094] In this embodiment, in addition to providing bridging capabilities, controlling the mounting and unmounting of local virtual media devices, and detecting consumption status, the local bridging layer also performs remote real capability mapping, that is, it maintains the mapping relationship between remote media devices and local virtual media devices.

[0095] Specifically, after determining the addition of a first remote media device in step S502, the local bridging layer can record the mapping relationship between the first remote media device and the first virtual media device; subsequently, if the first remote media device becomes unavailable, the local bridging layer deletes the mapping relationship between the first remote media device and the first virtual media device. Similarly, for a second remote media device, after adding a second remote media device, the local bridging layer can record the mapping relationship between the second remote media device and the second virtual media device; subsequently, if the second remote media device becomes unavailable in step S504, the local bridging layer deletes the mapping relationship between the second remote media device and the second virtual media device. Through this method, the mapping of remote real capabilities can be dynamically maintained.

[0096] In some alternative implementations, the method further includes step b1.

[0097] Step b1: If the real-time status information indicates that the second remote media device is unavailable, and the second virtual media device is in use, then disconnect the media data link corresponding to the second remote media device, and discard the temporary media data if there is any unconsumed temporary media data on the second virtual media device.

[0098] In this embodiment, for a second remote media device that is no longer usable, such as when the second remote media device is removed or the connection with the remote side is broken, the collection, injection, transmission or playback of data related to the second remote media device will be stopped.

[0099] Specifically, when the second remote media device is unavailable, if the second virtual media device is not in use (i.e., it is in an idle state), then the local second virtual media device can be unloaded directly. If the second virtual media device is currently in use (i.e., at least one local application device is using the second virtual media device), then the media data link corresponding to the second remote media device needs to be disconnected, and it needs to be determined whether there is any unconsumed temporary media data on the second virtual media device. If so, the temporary media data should be discarded directly, and then the second virtual media device should be disabled and deregistered in the local operating system.

[0100] Step S505: Monitor the consumption status of each enabled target virtual media device, and control the target media data link corresponding to the target remote media device based on the consumption status of the target virtual media device; the target remote media device corresponds to the target virtual media device, and the consumption status is used to indicate whether the target virtual media device is being used.

[0101] Please see details Figure 2 Step S204 of the illustrated embodiment will not be described again here.

[0102] In some optional implementations, the consumption status can directly indicate whether the corresponding virtual media device is being used, such as the consumption status being "device is used" or "device is not used"; or, the consumption status can indicate whether the virtual media device has switched from never being used to being used, or from being used to not being used. Status switching can also indicate whether the virtual media device is being used. Specifically, step S505, "controlling the target media data link corresponding to the target remote media device according to the consumption status of the target virtual media device," can include steps c1 to c2.

[0103] Step c1: When the consumption state of the target virtual media device indicates that the target virtual media device has switched from an idle state to a used state, start the target media data link corresponding to the target remote media device and assign a corresponding session identifier to the target media data link.

[0104] Step c2: When the consumption state of the target virtual media device indicates that the target virtual media device has switched from the usage state to the idle state, stop the target media data link corresponding to the target remote media device and delete the session identifier assigned to the target media data link.

[0105] In this embodiment, the local bridging layer monitors the consumption status of each activated target virtual media device in real time. For any target virtual media device, if its consumption status changes from idle to active, the media data link corresponding to that target remote media device, i.e., the target media data link, is then activated. It can be understood that only after activating the target media data link can corresponding media data be transmitted based on it. For example, video and audio streams captured by target remote media devices such as cameras and microphones can be transmitted to the local terminal device, or audio streams captured by the local terminal device can be transmitted to target remote media devices such as speakers for playback.

[0106] Correspondingly, if the consumption status of the target virtual media device changes from the used state to the idle state, that is, the local application no longer uses the target virtual media device, the target media data link corresponding to the target remote media device can be stopped to avoid transmitting data based on the target media data link, thereby avoiding privacy leaks and other issues.

[0107] Furthermore, the local bridging layer also maintains the session identifier of the target media data link. Based on the session identifier of each link, session isolation can be achieved to prevent old session media data from entering the new session.

[0108] In some alternative implementations, each local virtual media device is configured with the following states: Found but not mounted, Mounted and idle, Warm-up complete, Starting, Running, Stopped, Unmounting, and Unmounted. It may also include no remote capabilities discovered. The meanings of each state are as follows: No remote capabilities detected: The remote agent did not detect remote media devices, such as the remote large screen not reporting remote capabilities such as real cameras, microphones or speakers.

[0109] Unmounted detected: The local bridging layer has received the remote real capability reported by the remote agent, that is, there is a newly added remote media device, but the local virtual media device corresponding to the remote media device has not yet been registered or enabled.

[0110] Mounted but Idle: A local virtual media device is mounted and appears in the system device list, but no local application is actually using it, so it is in an idle state. In this case, the local bridging layer can establish and maintain the corresponding mapping relationship.

[0111] Warm-up complete: Control plane prediction operations are completed in advance without starting actual media acquisition or playback. For example, connection holding, capability negotiation, format negotiation, or clock calibration have been completed, but actual acquisition or playback has not yet started.

[0112] In the process of starting up: The local bridging layer has detected the first consumer, i.e., the virtual media device, which has switched from an idle state to a used state. At this time, it is notifying the remote end to start the corresponding remote media device.

[0113] Running: The corresponding remote media device is being used by a local application, such as a remote camera capture, microphone capture, or speaker playback link is in operation.

[0114] Stopped: The last consumer has disappeared, meaning the virtual media device has switched from being in use to being idle. The remote media device is currently being stopped.

[0115] Unloading in progress: When the remote physical capability disappears (e.g., the remote media device is removed) or the session with the remote physical capability ends, the corresponding virtual media device is being unloaded, including deactivating, deregistering, or removing the local virtual media device.

[0116] Uninstalled: The local virtual media device has been removed from the local operating system, and the corresponding mapping relationship can be deleted from the local bridging layer.

[0117] Figure 6 A schematic diagram of the state machine of a virtual media device is shown, including the changes between various states, the specific conditions and actions for switching from the source state to the target state, as shown in Table 1 below.

[0118] Table 1

[0119] In this embodiment, dynamic mounting and unmounting, as well as consumption triggering, can be achieved for various media devices such as cameras, microphones, and speakers. Furthermore, different types of media devices can adaptively collect corresponding consumer data; for example, a local virtual camera reports open counts and consumer negotiation formats; a virtual microphone reports input stream open status, frame read requests, and injection consumption status; and a virtual speaker reports output stream open status, arrival and stop status of valid playback data, etc.

[0120] For cameras: When the remote agent detects the presence of a real remote camera, the device management layer mounts a virtual camera in the local operating system. Third-party conferencing applications can then select this virtual camera from the system's camera list. At this point, only the virtual camera is mounted or the conferencing application enumerates the device; the real camera does not initiate data capture.

[0121] The local bridging layer monitors the consumption status of virtual cameras, such as their open status, the number of active consumers, and frame request status. When at least one local conferencing application opens a virtual camera and requests to preview or record frames, it can detect that the virtual camera is in use (virtual camera is open, number of active consumers is greater than 0, frame requests exist, etc.). The local bridging layer then sends a real camera start command to the remote agent. Upon receiving the command, the remote agent starts the real camera to capture, encode, and transmit video. The local bridging layer receives the video data and writes it to the local virtual camera for use by local conferencing applications.

[0122] When all consumers of local virtual cameras are turned off or abnormally exited, the local bridging layer notifies the remote agent to stop real camera capture and video transmission, while the local virtual cameras remain mounted and idle. If a remote real camera is removed, disconnected, or the session ends, the device management layer stops the corresponding video link and unmounts the local virtual camera, and third-party conferencing applications will no longer enumerate the virtual device corresponding to that remote camera.

[0123] For microphones: When the remote agent detects the presence of a real remote microphone, the device management layer mounts a virtual microphone in the local operating system. Third-party conferencing applications can then select this virtual microphone from the system's microphone list. At this point, only the virtual microphone is mounted or the conferencing application enumerates the device; the real microphone capture is not initiated.

[0124] The local bridging layer monitors the consumption status of the virtual microphone, such as whether the virtual microphone input stream is opened by the local conferencing application and whether the local conferencing application is requesting audio frames. When at least one local conferencing application opens the virtual microphone and requests audio data, the local bridging layer sends a real microphone acquisition start command to the remote agent. Upon receiving the command, the remote agent starts remote real microphone acquisition and transmits audio frames to the local bridging layer via the media channel. The local bridging layer then injects the audio frames into the local virtual microphone for use by the local conferencing application.

[0125] Once all local virtual microphone consumers are turned off or input streams are released, the local bridging layer notifies the remote agent to stop real microphone acquisition. If the remote real microphone is removed, disconnected, or the session ends, the device management layer stops audio injection and unloads the local virtual microphone, and third-party conferencing applications will no longer enumerate the virtual device corresponding to that remote microphone.

[0126] For speakers: When the remote agent detects the presence of a real remote speaker, the device management layer mounts a virtual speaker in the local operating system. Third-party conferencing applications can then select this virtual speaker from the system's speaker list. At this point, only the virtual speaker is mounted or the conferencing application enumerates the device; the remote speaker is not occupied or played.

[0127] The local bridging layer monitors the consumption status of virtual speakers, such as whether the local conferencing application selects a virtual speaker and whether it generates a valid output stream or playback data. When the local conferencing application outputs valid audio data to the virtual speaker, the local bridging layer initiates a playback link to the remote real speaker, sending the locally output audio data to the remote agent, which then controls the playback on the remote real speaker.

[0128] When the local conferencing application stops output, the virtual speaker stream is closed, or the consumer is released, the local bridging layer stops the remote speaker playback link. If the remote real speaker is removed, disconnected, or the session ends, the device management layer stops the playback link and unloads the local virtual speaker, and third-party conferencing applications will no longer enumerate the virtual device corresponding to that remote speaker.

[0129] The mounting, triggering, and unmounting conditions for the above three types of media devices are shown in Table 2 below.

[0130] Table 2

[0131] Optionally, the method further includes steps c1 to c3, and / or steps c4 to c6.

[0132] Step c1: If the real-time status information indicates the addition of a first remote media device, determine whether the first virtual media device corresponding to the first remote media device has been registered.

[0133] Step c2: If the first virtual media device has been registered, discard the real-time status information.

[0134] Step c3: If the first virtual media device is not registered, perform the step of registering and enabling the first virtual media device corresponding to the first remote media device in the local operating system.

[0135] Step c4: If the real-time status information indicates that the second remote media device is unavailable, determine whether the second virtual media device corresponding to the second remote media device has been deregistered.

[0136] Step c5: If the second virtual media device has been deregistered, discard the real-time status information.

[0137] Step c6: Without deregistering the second virtual media device, perform the steps to disable and deregister the second virtual media device corresponding to the second remote media device in the local operating system.

[0138] In this embodiment, when the same remote real capability is repeatedly reported, the local virtual media device is not created again; when the same remote real capability is repeatedly reported and disappears, the local virtual media device is not unloaded again, thus achieving idempotent mounting and unloading.

[0139] Figure 7 This illustrates a flowchart of dynamically mounting and unmounting virtual media devices, such as... Figure 7 As shown, after detecting a change in the actual capabilities of a remote media device, the local bridging layer can determine whether the change involves the presence or removal of the remote actual capabilities.

[0140] If the remote real capability is available, the system continues to determine whether the corresponding virtual media device has been mounted. If not mounted, the virtual media device is mounted to the local operating system and enters a mounted idle state. If mounted, it remains in the mounted idle state, waiting for the consumer to use it. The local bridging layer can monitor in real time whether each virtual media device is being used. If it is not being used, it remains in the mounted idle state, and the real remote media device is not started. If the virtual media device is being used, the corresponding remote media device is started.

[0141] If the remote real capability is removed, determine whether the corresponding virtual media device has been uninstalled; if not, uninstall the local virtual media device; if it has been uninstalled, do not uninstall it again and end the process directly.

[0142] In this embodiment, remote media devices can also be idempotently started and stopped, that is: if the same remote media device receives a start condition again while running, it will not start again; if it receives a stop condition again while stopped or already stopped, it will not stop again.

[0143] Furthermore, once the last consumer releases the device, the virtual media device can be immediately discontinued, or a short de-jitter window can be set to avoid frequent restarts and shutdowns caused by the conferencing application switching devices in a short period of time. Similarly, once the remote real capability disappears, the local virtual media device can be removed immediately, or the device can be disabled first and then removed after a short time window to adapt to the device refresh behavior of the conferencing application.

[0144] The remote media device management method provided in this embodiment dynamically mounts the local virtual media device when the remote real capability appears and dynamically unmounts it when the remote real capability disappears. This ensures that the virtual devices in the local device list are consistent with the remote real capabilities, reducing the possibility of local applications mistakenly selecting unavailable devices, and is suitable for BYOM scenarios. The remote real media device is dynamically mapped to the local system's standard virtual media device, eliminating the need for local applications to integrate a dedicated SDK, making it suitable for most applications. The remote real camera and microphone are only activated and collect data when the local application is actually using them, avoiding premature acquisition of images and sound during the virtual device mounting or enumeration phase, thus improving privacy protection. The remote real speaker is only activated for remote playback when the local application generates valid output, enhancing on-site playback control and preventing accidental occupation or playback. By preheating the control plane, the waiting time for the first video frame or the first audio frame can be reduced without collecting real media data. By not activating real media acquisition, encoding, transmission, or playback in the idle state, the remote computing power, network bandwidth, and power consumption can be reduced, saving system resources.

[0145] This embodiment also provides a management device for a remote media device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0146] This embodiment provides a management device for remote media devices, such as... Figure 8 As shown, the device includes: The acquisition module 801 is used to acquire real-time status information of remote media devices; Mounting module 802 is used to register and enable the first virtual media device corresponding to the first remote media device in the local operating system when the real-time status information indicates that a new first remote media device has been added. The unloading module 803 is used to disable and deregister the second virtual media device corresponding to the second remote media device in the local operating system when the real-time status information indicates that the second remote media device is unavailable. The processing module 804 is used to monitor the consumption status of each enabled target virtual media device, and control the target media data link corresponding to the target remote media device according to the consumption status of the target virtual media device; the target remote media device corresponds to the target virtual media device, and the consumption status is used to indicate whether the target virtual media device is being used.

[0147] In some optional implementations, the mounting module 802 is further configured to: record the mapping relationship between the first remote media device and the first virtual media device when the real-time status information indicates the addition of a first remote media device; The unloading module 803 is further configured to: delete the mapping relationship between the second remote media device and the second virtual media device when the real-time status information indicates that the second remote media device is unavailable.

[0148] In some optional implementations, after enabling the first virtual media device, the processing module 804 is further configured to: perform a control plane warm-up operation on the first virtual media device, the control plane warm-up operation including at least one of link connection maintenance, clock calibration, media device capability negotiation, and data format negotiation.

[0149] In some alternative implementations, after enabling the first virtual media device, the processing module 804 is further configured to: Set the media data link corresponding to the first virtual media device to an invalid state; wherein, the media data link in the invalid state is prohibited from transmitting data; When the consumption state of the first virtual media device indicates that the first virtual media device has switched from an idle state to a used state, the media data link corresponding to the first virtual media device is switched to an effective state that allows data transmission.

[0150] In some optional implementations, the processing module 804 is further configured to: If the real-time status information indicates that the second remote media device is unavailable, and the second virtual media device is in use, then the media data link corresponding to the second remote media device is disconnected, and if there is any unconsumed temporary media data on the second virtual media device, then the temporary media data is discarded.

[0151] In some optional implementations, controlling the target media data link corresponding to the target remote media device based on the consumption status of the target virtual media device includes: When the consumption state of the target virtual media device indicates that the target virtual media device has switched from an idle state to a used state, the target media data link corresponding to the target remote media device is started, and a corresponding session identifier is assigned to the target media data link. When the consumption status of the target virtual media device indicates that the target virtual media device has switched from a used state to an idle state, the target media data link corresponding to the target remote media device is stopped, and the session identifier assigned to the target media data link is deleted.

[0152] In some optional implementations, the mounting module 802 is further configured to: when the real-time status information indicates the addition of a first remote media device, determine whether the first virtual media device corresponding to the first remote media device has been registered; if the first virtual media device has been registered, discard the real-time status information; if the first virtual media device has not been registered, perform the step of registering and enabling the first virtual media device corresponding to the first remote media device in the local operating system; And / or, The unloading module 803 is further configured to: determine whether the second virtual media device corresponding to the second remote media device has been deregistered when the real-time status information indicates that the second remote media device is unavailable; discard the real-time status information if the second virtual media device has been deregistered; and execute the step of disabling and deregistering the second virtual media device corresponding to the second remote media device in the local operating system if the second virtual media device has not been deregistered.

[0153] The remote media device management apparatus provided in this disclosure can execute the remote media device management method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0154] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0155] The following is a detailed reference. Figure 9 This diagram illustrates a suitable structural schematic for implementing the electronic device described in the embodiments of this application. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 901, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 902 or a program loaded from memory 908 into random access memory (RAM) 903. The RAM 903 also stores various programs and data required for the operation of the electronic device. The processor 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0156] Typically, the following devices can be connected to I / O interface 905: input devices 906 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 907 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 908 including, for example, magnetic tapes, hard disks, etc.; and communication devices 909. Communication device 909 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 9 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0157] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 909, or installed from a memory 908, or installed from a ROM 902. When the computer program is executed by the processor 901, it performs the functions defined in the remote media device management method of embodiments of this application.

[0158] Figure 9 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0159] This application also provides a computer-readable storage medium. The methods described in this application can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the remote media device management method shown in the above embodiments is implemented.

[0160] A portion of this application can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to this application through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0161] Although embodiments of this application have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of this application, and all such modifications and variations fall within the scope defined by the appended claims.

Claims

1. A method for managing remote media devices, characterized in that, Applied to a terminal device, the method includes: Obtain real-time status information of remote media devices; When the real-time status information indicates the addition of a first remote media device, the first virtual media device corresponding to the first remote media device is registered and enabled in the local operating system; If the real-time status information indicates that the second remote media device is unavailable, the second virtual media device corresponding to the second remote media device is disabled and deregistered in the local operating system. Monitor the consumption status of each enabled target virtual media device, and control the target media data link corresponding to the target remote media device based on the consumption status of the target virtual media device; the target remote media device corresponds to the target virtual media device, and the consumption status is used to indicate whether the target virtual media device is being used.

2. The method according to claim 1, characterized in that, The method further includes: When the real-time status information indicates the addition of a first remote media device, the mapping relationship between the first remote media device and the first virtual media device is recorded; If the real-time status information indicates that the second remote media device is unavailable, delete the mapping relationship between the second remote media device and the second virtual media device.

3. The method according to claim 1, characterized in that, After enabling the first virtual media device, the method further includes: A control plane warm-up operation is performed on the first virtual media device. The control plane warm-up operation includes at least one of link connection maintenance, clock calibration, media device capability negotiation, and data format negotiation.

4. The method according to claim 1 or 3, characterized in that, After enabling the first virtual media device, the method further includes: Set the media data link corresponding to the first virtual media device to an invalid state; wherein, the media data link in the invalid state is prohibited from transmitting data; When the consumption state of the first virtual media device indicates that the first virtual media device has switched from an idle state to a used state, the media data link corresponding to the first virtual media device is switched to an effective state that allows data transmission.

5. The method according to claim 1, characterized in that, The method further includes: If the real-time status information indicates that the second remote media device is unavailable, and the second virtual media device is in use, then the media data link corresponding to the second remote media device is disconnected, and if there is any unconsumed temporary media data on the second virtual media device, then the temporary media data is discarded.

6. The method according to claim 1, characterized in that, The step of controlling the target media data link corresponding to the target remote media device based on the consumption status of the target virtual media device includes: When the consumption state of the target virtual media device indicates that the target virtual media device has switched from an idle state to a used state, the target media data link corresponding to the target remote media device is started, and a corresponding session identifier is assigned to the target media data link. When the consumption status of the target virtual media device indicates that the target virtual media device has switched from a used state to an idle state, the target media data link corresponding to the target remote media device is stopped, and the session identifier assigned to the target media data link is deleted.

7. The method according to claim 1, characterized in that, The method further includes: If the real-time status information indicates the addition of a first remote media device, determine whether the first virtual media device corresponding to the first remote media device has been registered; if the first virtual media device has been registered, discard the real-time status information; if the first virtual media device has not been registered, execute the step of registering and enabling the first virtual media device corresponding to the first remote media device in the local operating system. And / or, If the real-time status information indicates that the second remote media device is unavailable, determine whether the second virtual media device corresponding to the second remote media device has been deregistered; if the second virtual media device has been deregistered, discard the real-time status information; if the second virtual media device has not been deregistered, execute the step of disabling and deregistering the second virtual media device corresponding to the second remote media device in the local operating system.

8. A management device for remote media equipment, characterized in that, Applied to a terminal device, the device includes: The acquisition module is used to acquire real-time status information of remote media devices; The mounting module is used to register and enable the first virtual media device corresponding to the first remote media device in the local operating system when the real-time status information indicates that a new first remote media device has been added. The uninstallation module is used to disable and deregister the second virtual media device corresponding to the second remote media device in the local operating system when the real-time status information indicates that the second remote media device is unavailable. The processing module is used to monitor the consumption status of each enabled target virtual media device, and control the target media data link corresponding to the target remote media device based on the consumption status of the target virtual media device; the target remote media device corresponds to the target virtual media device, and the consumption status is used to indicate whether the target virtual media device is being used.

9. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the management method of any one of claims 1 to 7 for a remote media device.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the management method for the remote media device according to any one of claims 1 to 7.

11. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the management method for a remote media device as described in any one of claims 1 to 7.

Images