Fault detection and repair method and device, electronic equipment and video conference system

Abstract

The invention belongs to the field of data transmission, and particularly relates to a fault detection and repair method and device, electronic equipment and a video conference system. The fault detection and repair method is applied to a home terminal device in the video conference system, the video conference system further comprises an opposite terminal device, and the fault detection and repair method comprises the following steps: collecting monitoring parameters of the home terminal device in a video conference process between the home terminal device and the opposite terminal device, the monitoring parameters are used for representing the performance of streaming media or home terminal equipment in the video conference process; when the monitoring parameter meets a corresponding preset condition, determining that the video conference has a fault; and determining a repair strategy corresponding to the fault, and completing fault repair according to the repair strategy. According to the method and the device, the actual condition of the video conference can be timely and accurately acquired, and the fault in the video conference process is automatically repaired, so that the stability and the reliability of the video conference are effectively improved, and smooth proceeding of the video conference is guaranteed.

Description

Technical Field

[0001] This application belongs to the field of data transmission, specifically relating to a fault detection and repair method, apparatus, electronic device, and video conferencing system. Background Technology

[0002] With the development of internet communication technology, video conferencing applications have been widely used in daily office work.

[0003] Currently, there are various video conferencing applications available on the market for users to choose from. Different video conferencing applications may support the same communication protocols. However, even for different video conferencing applications supporting the same standard communication protocol, there may be differences in certain technical parameters. Therefore, when different users use these video conferencing applications for video conferencing, they may encounter abnormal phenomena such as black screens, discontinuous audio, and video stuttering.

[0004] In existing technologies, when encountering the aforementioned anomalies, technicians typically need to be on-site to determine the cause of the anomaly and perform repairs using techniques such as packet capture. However, this repair method is inefficient, costly, and impacts user experience. Summary of the Invention

[0005] This application provides a fault detection and repair method, device, electronic device, and video conferencing system, which can monitor, accurately judge, and repair faults in real time, improve the efficiency of fault detection and repair, reduce reliance on on-site operation by technicians, and lower maintenance costs.

[0006] In a first aspect, embodiments of this application provide a fault detection and repair method, applied to a local device in a video conferencing system, the video conferencing system also including a remote device, the fault detection and repair method comprising: during a video conference between the local device and the remote device, collecting monitoring parameters of the local device, the monitoring parameters being used to characterize the performance of the streaming media or the local device during the video conference; when the monitoring parameters meet corresponding preset conditions, determining that a fault exists in the video conference; determining a repair strategy corresponding to the fault, and completing fault repair according to the repair strategy.

[0007] In this embodiment, by collecting monitoring parameters of the local device in real time, the actual operating status of the device can be obtained more comprehensively and promptly. This eliminates the reliance on technicians reproducing the fault on-site and capturing logs after a significant malfunction occurs; instead, data is proactively collected during the meeting. Then, when the monitoring parameters meet preset conditions, a video conference malfunction is quickly identified, and a corresponding repair strategy is determined to fix the fault. This effectively improves the stability and reliability of the video conference, ensuring its smooth operation and enhancing the user experience. Simultaneously, this automated fault detection and repair method reduces the need for manual intervention and lowers maintenance costs.

[0008] In some embodiments, the monitoring parameters include the peer IP address and the local IP address; when the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference is faulty, including: when no media stream data is received within a first preset time period, detecting whether the peer IP address and the local IP address are in the same network segment; if the peer IP address and the local IP address are not in the same network segment, it is determined that the video conference is faulty; determining the corresponding repair strategy for the fault includes: determining that the repair strategy is to send the received media stream to the source address of the media stream.

[0009] This application embodiment monitors the local device's parameters in real time during video conferencing. Especially when no media stream data is received within a first preset time period, it quickly determines if there is a video conferencing fault by detecting whether the peer's IP address and the local IP address are on the same network segment. Once a fault is identified, a targeted repair strategy is immediately implemented—sending the received media stream to the source address of the media stream—effectively improving the stability and reliability of the video conferencing. This automated fault detection and repair mechanism eliminates the need for complex operations and specialized technical knowledge from users, greatly enhancing the user experience in video conferencing and reducing the maintenance costs of the video conferencing system.

[0010] In some embodiments, the monitoring parameters include an audio synchronization source identifier and a video synchronization source identifier; when the monitoring parameters meet the corresponding preset conditions, determining that the video conference has a fault includes: when the audio synchronization source identifier and the video synchronization source identifier are the same, determining that the video conference has a fault; determining the repair strategy corresponding to the fault includes: determining that the repair strategy is to replace the first identifier with the target identifier, wherein the first identifier is different from the target identifier, and the first identifier is either an audio synchronization source identifier or a video synchronization source identifier.

[0011] This application's embodiments can effectively detect and resolve faults caused by identical audio and video synchronization source identifiers in video conferencing. When these two identifiers are detected to be identical, the system can quickly determine that there is a problem with the video conferencing and take corresponding repair strategies, namely, replacing the first identifier with the target identifier, thereby making the audio and video synchronization source identifiers different, avoiding errors in media stream data processing, and ensuring the normal operation of the video conferencing.

[0012] In some embodiments, the monitoring parameters include total call bandwidth and video allocation bandwidth; determining that the video conference is faulty when the monitoring parameters meet the corresponding preset conditions includes: determining that the video conference is faulty when the total call bandwidth is greater than a first preset bandwidth and the video allocation bandwidth is less than a second preset bandwidth; determining the corresponding repair strategy for the fault includes: determining that the repair strategy is to reallocate bandwidth to adjust the video allocation bandwidth.

[0013] This application embodiment monitors the total call bandwidth and video allocation bandwidth to promptly detect faults in video conferencing caused by unreasonable bandwidth allocation. When the total call bandwidth exceeds a first preset bandwidth and the video allocation bandwidth is less than a second preset bandwidth, a problem in the video conferencing is accurately identified, and a repair strategy of reallocating bandwidth to adjust the video allocation bandwidth is implemented, effectively ensuring the quality and stability of the video conferencing. This method eliminates the need for complex operations and professional network knowledge from users, automatically completing fault detection and repair, improving the user experience of video conferencing, and reducing maintenance costs. Simultaneously, it provides strong support for the efficient operation of the video conferencing system.

[0014] In some embodiments, the monitoring parameters include audio stream data and video stream data; when the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference is faulty, including: if no audio stream data is received within a second preset time period, triggering a call disconnection and detecting whether video stream data is received; if video stream data is received, it is determined that the video conference is faulty; determining the corresponding repair strategy for the fault includes: determining that the repair strategy is to modify the media detection time to disable the disconnection check.

[0015] This embodiment of the application monitors audio and video stream data. If no audio stream data is received within a second preset time period, the call is disconnected and video stream data is checked. This allows for timely and accurate determination of video conferencing malfunctions. Upon confirmation of a malfunction, a repair strategy is implemented by modifying the media detection time to disable disconnection checks. This effectively prevents unexpected call disconnections due to brief audio stream interruptions, ensuring the continuity and stability of the video conferencing system. This automated fault detection and repair mechanism eliminates the need for complex user operations and specialized technical knowledge, significantly enhancing the user experience in video conferencing while also reducing the maintenance costs of the video conferencing system.

[0016] In some embodiments, the monitoring parameters include binary meeting room control protocol (BfCP) signaling; when the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference is faulty, including: when the BfCP signaling is not communicating normally, it is determined that the video conference is faulty; and the corresponding repair strategy is determined, including: determining that the repair strategy is to modify the transmission method of the BfCP protocol.

[0017] This application embodiment monitors BFCP signaling to promptly identify video conferencing faults when communication is abnormal. This method effectively captures key factors that may affect video conferencing, improving the accuracy and timeliness of fault detection. Once a fault is identified, a repair strategy that modifies the BFCP protocol transmission method is adopted, demonstrating strong targeting. Different transmission methods adapt to different network environments and fault conditions. By flexibly adjusting the transmission method, the success rate of BFCP signaling transmission can be improved, thereby quickly restoring normal video conferencing. This process requires no complex operations or professional technical knowledge from the user, achieving automated fault detection and repair, greatly enhancing the user experience in video conferencing, while also reducing the maintenance costs of the video conferencing system, providing strong support for efficient and stable video conferencing.

[0018] In some embodiments, the monitoring parameters include decoding status; when the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference has a fault, including: when the decoding status is decoding failure, it is determined that the video conference has a fault; and the corresponding repair strategy is determined, including: determining that the repair strategy is to modify the bitstream identifier of the received media stream or to modify the packet mode of the received media stream.

[0019] This application's embodiments effectively improve the stability and reliability of video conferencing by employing targeted repair strategies when decoding fails. Once a decoding failure confirms a video conferencing malfunction, modifying the bitstream identifier of the received media stream allows for the selection of a more suitable encoding configuration based on different device performance and application scenarios, thereby improving the decoding success rate. Alternatively, modifying the packetization mode of the received media stream can better adapt to different network environments and transmission requirements.

[0020] Secondly, embodiments of this application provide a fault detection and repair device, which is applied to a local device in a video conferencing system. The video conferencing system also includes a remote device. The fault detection and repair device includes:

[0021] The acquisition unit is used to collect monitoring parameters of the local device during video conferencing between the local device and the remote device. The monitoring parameters are used to characterize the performance of the streaming media or the local device during the video conferencing.

[0022] The determination unit is used to determine that there is a fault in the video conference when the monitoring parameters meet the corresponding preset conditions, and to determine the corresponding repair strategy for the fault.

[0023] The fault repair unit is used to complete fault repair according to the repair strategy.

[0024] Thirdly, embodiments of this application provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the fault detection and repair method as described above.

[0025] Fourthly, embodiments of this application provide a non-volatile computer storage medium storing computer-executable instructions, which are executed by one or more processors to perform the fault detection and repair method described above.

[0026] Fifthly, embodiments of this application provide a video conferencing system, including a local device and a remote device; the local device and the remote device are communicatively connected and transmit media stream data to each other; the local device is used to execute the fault detection and repair method described above. Attached Figure Description

[0027] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0028] Figure 1 This is a schematic diagram of the structure of a video conferencing system provided in an embodiment of this application;

[0029] Figure 2 This is a flowchart illustrating a fault detection and repair method provided in an embodiment of this application;

[0030] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0031] 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 thoroughly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0032] The technical features involved in the various embodiments of this application described below do not conflict with each other and can be combined with each other.

[0033] Although the functional modules are divided in the device schematic diagram and the logical sequence is shown in the flowchart, in some cases, the steps may be performed in a different order than those shown in the flowchart.

[0034] When an element is described as "connected" to another element, it can be directly connected to the other element, or there may be one or more intervening elements between them.

[0035] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more.

[0036] Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0037] In the current video conferencing field, although many manufacturers refer to unified standard documents when developing products, the actual situation is complex and varied.

[0038] Standard documents, as common industry guidelines, should theoretically ensure consistency and compatibility among manufacturers' products. However, in reality, due to differences in cognitive levels, technical capabilities, and business considerations, manufacturers interpret and understand standard documents significantly differently.

[0039] For example, regarding the video frame rate requirements in the standard, some manufacturers may believe that a slight reduction under certain conditions can meet basic needs, while others strictly adhere to the specified frame rate range and refuse to compromise. Similarly, regarding the audio encoding format specifications in the standard, some manufacturers may use custom fine-tuning in certain edge cases, while others consistently adhere to the format specified in the standard.

[0040] At the same time, the degree to which manufacturers adhere to standards varies. Some manufacturers may strictly follow the standards on key indicators but relax them on some non-core functions; while others may selectively ignore certain standard requirements in order to pursue a unique competitive advantage.

[0041] In addition, some manufacturers introduce their own proprietary features to meet the specific needs of certain customer groups or to highlight the differentiated characteristics of their products. These proprietary features may include unique user interface designs, customized meeting control functions, or even proprietary encryption algorithms or data transmission protocols.

[0042] All these factors intertwine, ultimately leading to frequent compatibility issues when video conferencing products from different manufacturers are interoperated. For example, when using a video conferencing terminal from manufacturer A to connect to a server from manufacturer B, problems such as blurry or stuttering video, intermittent audio, or shared documents failing to display correctly may occur.

[0043] When such compatibility issues occur, the typical procedure is for technical personnel to first travel to the site. However, the site environment can be extremely complex, including different network architectures, hardware devices, and user operating habits, making accurate fault reproduction exceptionally difficult. Sometimes, technical personnel may need to try different scenarios and procedures multiple times to successfully reproduce the problem. After reproducing the fault, technical personnel then need to capture packets to obtain relevant log data. However, factors such as network instability, packet loss, and limitations of packet capture tools can all lead to incomplete or inaccurate log information. Finally, the technical personnel pass the obtained logs to the development team for analysis and repair. During this process, misunderstandings or omissions may occur during information transmission, and the development team may also face many challenges in interpreting the logs and locating the problem. Moreover, the development team needs to invest a significant amount of time and effort in code debugging and testing to ensure the effectiveness of the repair solution.

[0044] The entire troubleshooting process not only consumes significant manpower, resources, and time, but also involves numerous uncertainties, leading to high maintenance costs and making it difficult to accurately predict the time required to resolve the issue. This inefficient approach severely impacts the user experience, causing numerous problems when using video conferencing systems, such as meeting interruptions and communication breakdowns, and may even have serious negative impacts on users' work and business.

[0045] Based on this, this application provides a fault detection and repair method. By collecting monitoring parameters of the local device in real time during a video conference between the local and remote devices, the actual situation of the video conference can be obtained promptly and accurately. When the monitoring parameters meet preset conditions, a fault in the video conference is quickly identified, and a corresponding repair strategy is determined to repair the fault, thereby effectively improving the stability and reliability of the video conference, ensuring its smooth operation, and enhancing the user experience. At the same time, this automated fault detection and repair method reduces the need for manual intervention and lowers maintenance costs.

[0046] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of a video conferencing system provided in an embodiment of this application.

[0047] like Figure 1 As shown, the video conferencing system 100 includes a local device 10 and a remote device 20. The local device 10 and the remote device 20 are communicatively connected and transmit media stream data to each other. The local device 10 is used to execute the fault detection and repair method described below.

[0048] The local device 10 and the remote device 20 can be connected via a wired interface or a wireless network. It is understood that the local device 10 includes devices capable of transmitting media stream data, such as mobile phones, tablets, and computer terminals, and the remote device 100 includes devices capable of transmitting media stream data, such as mobile phones, tablets, and computer terminals. Wired interfaces include interfaces such as USB, HDMI, VGA, DVI, and DisplayPort, and wireless networks include wireless networks such as Bluetooth and Wi-Fi.

[0049] In a video conferencing system, media stream data includes audio stream data, video stream data, and possibly other media stream data.

[0050] Audio stream data consists of a series of consecutive audio samples, representing characteristics such as sound intensity and frequency. Audio stream data can exist independently; for example, in a purely audio call, only the audio stream data is transmitted. Audio stream data can contain different audio formats, such as MP3 and AAC, and has specific parameters, such as sample rate and number of channels. As part of media stream data, audio stream data provides the sonic dimension of the media stream data. During the transmission and processing of media stream data, audio stream data is usually synchronized with other media stream data, such as video stream data, to ensure a consistent and harmonious overall media experience.

[0051] Video stream data consists of a series of consecutive image frames, played at a certain frame rate to form dynamic video images. Video stream data can also exist independently; for example, in a video surveillance system, only the video stream data is transmitted. Video stream data uses different video encoding formats, such as H.264 and H.265, as well as different parameters such as resolution and frame rate. As an important component of media stream data, video stream data provides visual information. In media stream data, video stream data typically needs to work in conjunction with other media stream data, such as audio stream data.

[0052] Please see Figure 2 , Figure 2This is a flowchart illustrating a fault detection and repair method provided in an embodiment of this application.

[0053] This fault detection and repair method is applied to the local device 10 in the aforementioned video conferencing system 100.

[0054] like Figure 2 As shown, the fault detection and repair methods include:

[0055] Step S1: During the video conference between the local device and the remote device, the monitoring parameters of the local device are collected. The monitoring parameters are used to characterize the performance of the streaming media or the local device during the video conference.

[0056] Specifically, the methods for collecting monitoring parameters from this device include: using the device's built-in monitoring tools, using third-party monitoring software, and using hardware sensors.

[0057] For methods that utilize built-in monitoring tools, the local device typically comes equipped with some built-in monitoring tools or software modules that can collect various performance parameters in real time. For example, the operating system may provide system performance monitoring tools that can obtain information such as CPU usage and memory usage. The video conferencing software itself may also have built-in monitoring modules to collect parameters related to video conferencing, such as network bandwidth usage, video frame rate, and audio quality.

[0058] Among these methods, those using third-party monitoring software typically offer more powerful monitoring capabilities and more detailed data analysis. For example, network monitoring software can be used to monitor network connection stability, latency, packet loss rate, and other parameters in real time. For monitoring audio and video quality, specialized audio and video quality analysis software can be used.

[0059] For data acquisition using hardware sensors, some local devices may be equipped with hardware sensors that can provide specific monitoring parameters. For example, a laptop may be equipped with a temperature sensor to monitor the device's temperature; a mobile device may be equipped with an accelerometer to monitor the device's motion. Data from these hardware sensors can be collected and analyzed through the device's operating system or specific applications.

[0060] Specifically, monitoring parameters are used to characterize the performance of streaming media or local devices during video conferencing. Streaming media refers to the transmitted audio and video data. Local device performance includes hardware performance, software performance, and other performance metrics.

[0061] Step S2: If the monitoring parameters meet the corresponding preset conditions, it is determined that there is a fault in the video conference.

[0062] The preset conditions are specific standards or thresholds used to determine whether a video conference is malfunctioning. These preset conditions may include: network-related preset conditions, streaming media quality-related preset conditions, and device performance-related preset conditions, etc.

[0063] For example, network-related preset conditions include: insufficient network bandwidth, high network latency, and high packet loss rate. Insufficient network bandwidth refers to the situation where the upload or download bandwidth of the local device is detected to be below a certain value. For instance, if the upload bandwidth is consistently below 1Mbps and the video conferencing partner reports video stuttering, or if the download bandwidth is below 2Mbps and audio is intermittent, the preset condition is considered met. This is because low bandwidth may prevent timely transmission of streaming media data, affecting video and audio quality. For high network latency, a latency threshold can be set, such as a single-trip latency exceeding 200 milliseconds. If the detected network latency consistently exceeds this threshold, the preset condition is considered met. High latency leads to poor real-time interaction, choppy conversations, and affects the effectiveness of video conferencing. For a high packet loss rate, a packet loss rate exceeding a certain percentage is typically considered a fault, such as a packet loss rate consistently exceeding 5%. Packet loss can cause problems such as video flickering and audio distortion.

[0064] Preset conditions related to streaming media quality include: low video frame rate, low video resolution, and poor audio quality. Low video frame rate refers to a sustained video frame rate below a set value, such as 15 frames per second, which is considered a fault. A low frame rate makes the video choppy and affects the viewing experience. Low video resolution refers to a video resolution lower than a preset standard resolution, such as dropping from high definition (1920×1080) to standard definition (1280×720) or lower, which is considered to meet the preset condition. For poor audio quality, parameters such as signal-to-noise ratio (SNR) and distortion are used to determine audio quality. For example, a fault is considered to exist when the audio SNR is below a certain value (e.g., 40dB) or the distortion exceeds a certain percentage (e.g., 5%).

[0065] Preset conditions related to device performance include: high CPU utilization, high memory usage, and high device temperature. High CPU utilization refers to a sustained CPU usage exceeding a certain percentage, such as 80%, which may cause slow device response and affect video conferencing performance. High memory usage refers to memory usage exceeding a certain percentage of the device's total memory, such as 70%, which may cause system slowdown or lag. High device temperature refers to a temperature exceeding a certain value, such as 70°C, which may affect device stability and performance.

[0066] Step S3: Determine the repair strategy corresponding to the fault, and complete the fault repair according to the repair strategy.

[0067] First, determine the type of fault in the video conference based on the monitoring parameters: is it a network problem, a streaming media quality problem, or a device performance problem?

[0068] Then, select the appropriate repair strategy based on the type of fault.

[0069] If the problem is network-related, choose a network-related repair strategy; if the problem is streaming media quality-related, choose a streaming media quality-related repair strategy; if the problem is device performance-related, choose a device performance-related repair strategy.

[0070] Next, perform the specific operations according to the selected repair strategy. For example, if the problem is insufficient network bandwidth, reduce the video resolution or frame rate, close other applications that consume network bandwidth, etc. Finally, after implementing the repair strategy, re-collect monitoring parameters and observe whether the fault has been resolved. If the fault persists, it may be necessary to further adjust the repair strategy or try other methods.

[0071] As can be seen, the embodiments of this application provide a fault detection and repair method. By collecting monitoring parameters of the local device in real time, it can obtain a more comprehensive and timely understanding of the actual operating status of the device. It no longer relies on technicians reproducing the fault on-site and capturing packets to obtain logs after an obvious fault occurs; instead, it proactively collects data during the meeting. Then, when the monitoring parameters meet preset conditions, it quickly determines that a fault exists in the video conference and determines the corresponding repair strategy to repair the fault, thereby effectively improving the stability and reliability of the video conference, ensuring its smooth operation, and enhancing the user experience. At the same time, this automated fault detection and repair method also reduces the need for manual intervention and lowers maintenance costs.

[0072] In some embodiments, the monitoring parameters include the peer IP address and the local IP address. Step S2 above, determining a video conference malfunction when the monitoring parameters meet the corresponding preset conditions, includes: if no media stream data is received within a first preset time period, detecting whether the peer IP address and the local IP address are in the same network segment; if the peer IP address and the local IP address are not in the same network segment, then determining a video conference malfunction. Step S3 above, determining the corresponding repair strategy for the malfunction, includes: determining the repair strategy as sending the received media stream to the source address of the media stream.

[0073] The local IP address refers to the unique identifier of the device (local device) currently operating in the video conference within the network. The remote IP address refers to the unique identifier of the other device (remote device) communicating with the local device in the video conference within the network.

[0074] The first preset time period is a specific, pre-defined duration. If the local device does not receive media stream data within this time period, further detection will be triggered. This involves checking whether the remote IP address and the local IP address are on the same network segment to determine if there is a problem with the video conference. The setting of the first preset time period typically needs to consider factors such as the real-time requirements of the video conference, the stability of the network environment, and system resources and processing capabilities.

[0075] For example, if the first preset time period is set to 5 seconds, then during the video conference, if the local device does not receive media stream data for 5 consecutive seconds, it will start checking the network segment of the peer's IP address and the local IP address to determine if there is a fault in the video conference.

[0076] In a normal video conference, media stream data should be continuously transmitted between the local and remote devices. Therefore, if no media stream data is received within a first preset time period, the remote device may be able to see the image sent by the local device, but the local device may not be able to see the image from the remote device. If no media stream data is received for a period of time, checking whether the remote IP address and the local IP address are on the same network segment can determine if a fault exists.

[0077] IP addresses can be divided into different network segments, and communication between devices on the same network segment is usually more direct and efficient. If the local IP address and the remote IP address are on the same network segment, data transmission between them may involve fewer network devices and routers, making communication relatively easy to establish and maintain. Conversely, if they are not on the same network segment, data may need to pass through more network nodes and routers, which increases the likelihood of communication problems. For example, there may be issues such as firewalls or improperly configured routers between different network segments, causing media streaming data to fail to transmit properly.

[0078] In this embodiment, if no media stream data is received within a first preset time period, it is first determined whether the peer IP address and the local IP address are in the same network segment. If the peer IP address and the local IP address are not in the same network segment, it is determined that the video conference is malfunctioning.

[0079] If the video conferencing system is confirmed to have the aforementioned fault, the remediation strategy can be to send the received media stream to the source address of the media stream. If the peer IP address and the local IP address are not on the same network segment, it indicates that the local and peer devices may be located in an internal or external network environment. Network Address Translation (NAT) may cause a discrepancy between the media port negotiated by the two terminals and the port actually receiving the media stream data, resulting in the inability to receive the media stream data. In this case, the local device can send the received media stream to the source address of the media stream. The principle behind this approach is to send data directly to the source address, attempting to bypass potentially problematic intermediate network nodes and routes. This method can avoid data transmission interruptions caused by network device problems between different network segments.

[0080] For example, under normal circumstances, media stream data is forwarded through some intermediate servers. However, if a problem is found in a different network segment, sending the data directly to the source address of the peer device may bypass the problematic intermediate links, re-establish the communication connection, and restore the normal operation of the video conference.

[0081] This application embodiment monitors the local device's parameters in real time during video conferencing. Especially when no media stream data is received within a first preset time period, it quickly determines if there is a video conferencing fault by detecting whether the peer's IP address and the local IP address are on the same network segment. Once a fault is identified, a targeted repair strategy is immediately implemented—sending the received media stream to the source address of the media stream—effectively improving the stability and reliability of the video conferencing. This automated fault detection and repair mechanism eliminates the need for complex operations and specialized technical knowledge from users, greatly enhancing the user experience in video conferencing and reducing the maintenance costs of the video conferencing system.

[0082] In some embodiments, the monitoring parameters include an audio synchronization source identifier and a video synchronization source identifier. Step S2 above, determining that the video conference is faulty when the monitoring parameters meet the corresponding preset conditions, includes: determining that the video conference is faulty when the audio synchronization source identifier and the video synchronization source identifier are the same. Step S3 above, determining the corresponding repair strategy for the fault, includes: determining that the repair strategy is to replace the first identifier with a target identifier, wherein the first identifier is different from the target identifier, and the first identifier is either an audio synchronization source identifier or a video synchronization source identifier.

[0083] The audio synchronization source identifier is a specific code or number used to identify the synchronization source of an audio stream, such as ssrc (Synchronization Source Identifier). The video synchronization source identifier is a specific code or number used to identify the synchronization source of a video stream, such as ssrc.

[0084] If the audio stream data received by the local device uses the same audio synchronization source identifier as the video stream data, it may cause confusion when processing the media stream data. This can lead to incorrect synchronization and playback of audio and video, resulting in malfunctions in media stream data processing and a black screen on the local device. Therefore, if the audio and video synchronization source identifiers are the same, it indicates a problem with the video conferencing.

[0085] If the video conferencing system is confirmed to have the aforementioned fault, the remediation strategy can be determined as follows: replace the first identifier with the target identifier. The first identifier is different from the target identifier; the first identifier is either the audio synchronization source identifier or the video synchronization source identifier. The target identifier is an independent identifier generated or stored internally by the local device.

[0086] This ensures that the audio synchronization source identifier and the video synchronization source identifier are different. When the audio synchronization source identifier and the video synchronization source identifier are different, the local device can clearly distinguish the source of the audio stream data and the video stream data, thereby processing them accurately.

[0087] This application's embodiments can effectively detect and resolve faults caused by identical audio and video synchronization source identifiers in video conferencing. When these two identifiers are detected to be identical, the system can quickly determine that there is a problem with the video conferencing and take corresponding repair strategies, namely, replacing the first identifier with the target identifier, thereby making the audio and video synchronization source identifiers different, avoiding errors in media stream data processing, and ensuring the normal operation of the video conferencing.

[0088] In some embodiments, the monitoring parameters include total call bandwidth and video allocation bandwidth. Step S2 above, determining that the video conference is faulty when the monitoring parameters meet the corresponding preset conditions, includes: determining that the video conference is faulty when the total call bandwidth is greater than a first preset bandwidth and the video allocation bandwidth is less than a second preset bandwidth. Step S3 above, determining the corresponding repair strategy for the fault, includes: determining the repair strategy as reallocating bandwidth to adjust the video allocation bandwidth.

[0089] The total bandwidth of the call refers to the total network bandwidth used to transmit all data (including audio, video, control signals, etc.) between the local device and the remote device during a video conference.

[0090] Video allocated bandwidth refers to the network bandwidth allocated from the total call bandwidth to the transmission of video stream data.

[0091] The first preset bandwidth is a total call bandwidth threshold preset based on the normal operation requirements of the video conferencing system and factors such as the network environment. For example, 8Mbps.

[0092] The second preset bandwidth is a threshold set for the bandwidth allocated to video. For example, 3 Mbps.

[0093] Specifically, if the total call bandwidth is high and the video allocation bandwidth is low (i.e., the total call bandwidth is greater than the first preset bandwidth and the video allocation bandwidth is less than the second preset bandwidth), then a video conference malfunction is confirmed. This malfunction may result in a low screen resolution during the video conference.

[0094] If the video conferencing system is confirmed to have the aforementioned fault, the remediation strategy can be to reallocate bandwidth to adjust the video allocation bandwidth. Specifically, increase the video allocation bandwidth of the local device, thereby enabling it to generate high-resolution video and ignoring the impact of the lower video allocation bandwidth of the remote device on the resolution.

[0095] This application embodiment monitors the total call bandwidth and video allocation bandwidth to promptly detect faults in video conferencing caused by unreasonable bandwidth allocation. When the total call bandwidth exceeds a first preset bandwidth and the video allocation bandwidth is less than a second preset bandwidth, a problem in the video conferencing is accurately identified, and a repair strategy of reallocating bandwidth to adjust the video allocation bandwidth is implemented, effectively ensuring the quality and stability of the video conferencing. This method eliminates the need for complex operations and professional network knowledge from users, automatically completing fault detection and repair, improving the user experience of video conferencing, and reducing maintenance costs. Simultaneously, it provides strong support for the efficient operation of the video conferencing system.

[0096] In some embodiments, the monitoring parameters include audio stream data and video stream data. Step S2 above, determining a video conference malfunction when the monitoring parameters meet corresponding preset conditions, includes: if no audio stream data is received within a second preset time period, triggering a call disconnection and detecting whether video stream data is received; if video stream data is received, then determining a video conference malfunction. Step S3 above, determining the corresponding repair strategy for the malfunction, includes: determining the repair strategy as modifying the media detection time to disable disconnection checks.

[0097] The audio stream data consists of a series of consecutive audio samples, which represent characteristics such as sound intensity and frequency. The video stream data consists of a series of consecutive image frames, which are played at a certain frame rate to form dynamic video images.

[0098] The second preset time period is a specific, pre-defined duration. Its main function is to serve as a time standard for determining whether a video conference has malfunctioned. If the local device does not receive audio stream data within this time period, the system will trigger a series of fault detection operations. The setting of the second preset time period typically needs to consider factors such as real-time communication requirements, tolerance for audio interruptions, network fluctuations, data transmission latency, system resources, and processing capabilities.

[0099] For example, if the second preset time period is set to 20 seconds, then during the video conference, if the local device does not receive audio stream data for 20 consecutive seconds, it will trigger the call to be disconnected and check whether video stream data has been received in order to determine whether there is a fault in the video conference.

[0100] The media detection time is the time interval or duration used to check whether audio stream data is being transmitted normally. During a video conference, the local device checks whether it has received audio stream data at specific time intervals; this time interval is part of the media detection time. If no audio stream data is received within one or several consecutive such time intervals, a fault diagnosis mechanism may be triggered. For example, if the media detection time is set to check the audio stream reception every 5 seconds, it will check every 5 seconds to see if any audio stream data has arrived at the local device. If the media detection time is set to check every 0 seconds, it will not check whether any audio stream data has arrived at the local device.

[0101] Specifically, if no audio stream data is received within the second preset time period, the local device will typically consider the call abnormal and trigger a call termination. At this point, it's possible to check if video stream data is being received. If video stream data is still being received, it indicates that the video transmission channel is normal. The lack of audio stream data may be normal or a special behavior of certain devices, and there's no need to terminate the video conference call, thus confirming a video conference malfunction.

[0102] If the video conferencing system is confirmed to have the aforementioned issues, the remediation strategy can be to modify the media detection time to disable hang-up checks. Specifically, setting the media detection time to 0 will prevent the call from being disconnected before audio stream data is received.

[0103] This embodiment of the application monitors audio and video stream data. If no audio stream data is received within a second preset time period, the call is disconnected and video stream data is checked. This allows for timely and accurate determination of video conferencing malfunctions. Upon confirmation of a malfunction, a repair strategy is implemented by modifying the media detection time to disable disconnection checks. This effectively prevents unexpected call disconnections due to brief audio stream interruptions, ensuring the continuity and stability of the video conferencing system. This automated fault detection and repair mechanism eliminates the need for complex user operations and specialized technical knowledge, significantly enhancing the user experience in video conferencing while also reducing the maintenance costs of the video conferencing system.

[0104] In some embodiments, the monitoring parameters include Bfcp (Binary Floor Control Protocol) signaling. Step S2 above, determining that the video conference is faulty when the monitoring parameters meet the corresponding preset conditions, includes: determining that the video conference is faulty when Bfcp signaling is not communicating normally. Step S3 above, determining the corresponding repair strategy for the fault, includes: determining that the repair strategy is to modify the transmission method of the Bfcp protocol.

[0105] In video conferencing, BfCP signaling plays a crucial control role. It manages various resources within the meeting, such as speaking rights control, video source switching, and shared document operations. If BfCP signaling fails to communicate properly, these control functions cannot be implemented correctly, thus affecting the video conference. For example, if a user requests speaking rights but BfCP signaling malfunctions, the user's request cannot be correctly transmitted to the conference server, and other participants will not be aware of the user's request, leading to communication barriers. BfCP signaling is typically transmitted within the control channel of a multimedia conferencing system, separate from audio and video media streams. This ensures that signaling transmission is not interfered with by media streams, improving signaling reliability and real-time performance. For instance, in a SIP (Session Initiation Protocol)-based video conference, BfCP signaling can be transmitted through the SIP signaling channel, separate from the RTP (Real-time Transport Protocol) media stream.

[0106] Specifically, if BFCP signaling fails to communicate normally, it indicates a video conferencing malfunction. In this case, the remediation strategy is to modify the BFCP protocol's transmission method. Modifying the BFCP protocol's transmission method can attempt to resolve signaling communication failures caused by transmission issues. Different transmission methods may have varying adaptability to network environments; therefore, choosing an appropriate transmission method can improve the success rate of signaling transmission. For example, if the original transmission method was UDP (User Datagram Protocol), it can be changed to TCP (Transmission Control Protocol). Conversely, if the original transmission method was TCP, it can be changed to UDP. It's also possible to detect whether the local device's network restricts TCP or UDP, causing BFCP signaling communication failures. Modifying the BFCP protocol's transmission method can restore normal communication.

[0107] This application embodiment monitors BFCP signaling to promptly identify video conferencing faults when communication is abnormal. This method effectively captures key factors that may affect video conferencing, improving the accuracy and timeliness of fault detection. Once a fault is identified, a repair strategy that modifies the BFCP protocol transmission method is adopted, demonstrating strong targeting. Different transmission methods adapt to different network environments and fault conditions. By flexibly adjusting the transmission method, the success rate of BFCP signaling transmission can be improved, thereby quickly restoring normal video conferencing. This process requires no complex operations or professional technical knowledge from the user, achieving automated fault detection and repair, greatly enhancing the user experience in video conferencing, while also reducing the maintenance costs of the video conferencing system, providing strong support for efficient and stable video conferencing.

[0108] In some embodiments, the monitoring parameters include the decoding status. Step S2 above, determining that the video conference is faulty when the monitoring parameters meet the corresponding preset conditions, includes: determining that the video conference is faulty when the decoding status is decoding failure. Step S3 above, determining the corresponding repair strategy for the fault, includes: determining that the repair strategy is to modify the bitstream identifier of the received media stream, or to modify the packetization mode of the received media stream.

[0109] The decoding status refers to the feedback from the local device regarding the decoding of the received media stream. Decoding status includes successful decoding and decoding failure.

[0110] In this context, a decoding status is considered successful when the local device can correctly decode the media stream. This means that the media stream's data format is compatible with the receiving end's decoder, and that no damage or loss occurred during transmission. For example, in a high-definition video conference, if the receiving device can successfully decode the high-definition video stream from the sending end and play back clear picture and smooth audio, then the decoding status is considered successful.

[0111] In this context, the decoding status is "decoding failure" when the receiving end cannot correctly decode the media stream. For example, in a video conference, if the receiving device cannot decode the video stream from the sending end, it may result in a black screen, a distorted screen, or audio playback failure; in this case, the decoding status is "decoding failure."

[0112] The bitstream identifier of the media stream indicates the specific profile used for video encoding. Different profiles support different encoding functions, thus affecting the compression efficiency and quality of the video.

[0113] For example, in H.264 video, profile_idc (profile indicator code) is a bitstream identifier for a media stream, which has ALL (all functions), BP (Baseline Profile), and HP (High Profile) states.

[0114] The ALL state of profile_idc represents the set of all possible H.264 encoding features. This means it supports various advanced coding tools and features defined in the H.264 standard to achieve the highest coding efficiency and video quality. For example, the ALL state may include advanced features such as complex prediction modes, multiple reference frames, and adaptive quantization. These features can be flexibly adjusted according to the characteristics of the video content to achieve the best compression effect.

[0115] The BP state in profile_idc is a basic configuration in the H.264 standard. It provides a relatively simple set of encoding tools and functions to ensure reliable video playback across various devices and network environments. The BP state typically supports I-frame (keyframe) and P-frame (predictive frame) encoding, but not B-frame (bidirectional predictive frame) encoding. Its encoding complexity is low, making it suitable for devices with limited processing power and low-bandwidth network environments.

[0116] Among them, the HP state of profile_idc is an advanced configuration in the H.264 standard, which significantly improves encoding efficiency and video quality compared to the BP state. The HP state supports more advanced encoding tools, such as B-frames, weighted prediction, and adaptive quantization. For example, the HP state can achieve a higher compression ratio while maintaining good video quality by using B-frames. It can also automatically adjust encoding parameters according to the characteristics of the video content to obtain the best visual effect.

[0117] The media stream packetization mode refers to the method by which audio and video stream data are packaged into data packets for network transmission. Different packetization modes affect the transmission efficiency, latency, and quality of the media stream. For example, in video conferencing, using an inappropriate packetization mode may result in excessively large data packets, increasing network transmission latency; or excessively small data packets, increasing network transmission overhead. Therefore, choosing the appropriate packetization mode is crucial for ensuring the quality of video conferencing.

[0118] For example, H.264 video needs to use the following packet modes during transmission and storage: ALL mode, NALU (Network Abstraction Layer Unit) mode, NON_INTERLEAVE mode, etc.

[0119] Among them, ALL mode is a more general or comprehensive packetization mode that may combine the features of multiple packetization methods in an attempt to provide good performance under different conditions. For example, ALL mode may dynamically adjust the packetization strategy based on network conditions and the capabilities of the receiving end to balance video quality and transmission efficiency.

[0120] NALU mode packages H.264 video data according to the NALU structure. Each NALU contains a complete coding unit, such as a slice or a parameter set. The advantage of this mode is its clear structure, which facilitates network transmission and error recovery. Local devices can decode and reassemble video frames based on the type and sequence number of the NALU. For example, in network transmission, if a NALU is lost or damaged, the receiving end can perform a certain degree of error recovery based on information from other NALUs, or request the sending end to retransmit the lost NALU.

[0121] NON_INTERLEAVE mode, or non-interleaved mode, means that video data is not interleaved during packaging. In this mode, different parts of the video (such as frames and segments) are packaged sequentially, rather than being interleaved. The advantage of this mode is its simplicity and intuitiveness, facilitating fast decoding and processing at the receiving end. The local device does not need to process interleaved data and can directly read and process each video unit sequentially. For example, on devices with limited processing power, NON_INTERLEAVE mode can reduce decoding complexity and improve video playback smoothness.

[0122] In this embodiment, a video conference malfunction is determined when the decoding status is "decoding failed." At this time, the repair strategy is determined to be either modifying the bitstream identifier of the received media stream or modifying the packetization mode of the received media stream. For example, modifying the bitstream identifier of the received media stream includes changing the profile_idc supported by H264 video from the ALL state to the BP state or HP state. Modifying the packetization mode of the received media stream includes changing the packetization mode supported by H264 video from the ALL mode to the NALU mode or the NON_INTERLEAVE mode.

[0123] This application's embodiments effectively improve the stability and reliability of video conferencing by employing targeted repair strategies when decoding fails. Once a decoding failure confirms a video conferencing malfunction, modifying the bitstream identifier of the received media stream allows for the selection of a more suitable encoding configuration based on different device performance and application scenarios, thereby improving the decoding success rate. Alternatively, modifying the packetization mode of the received media stream can better adapt to different network environments and transmission requirements.

[0124] In summary, the fault detection and repair method provided in this application, by collecting monitoring parameters of the local device in real time, can obtain a more comprehensive and timely understanding of the actual operating status of the device. It no longer relies on technicians reproducing the fault on-site and capturing packets to obtain logs after an obvious fault occurs; instead, it proactively collects data during the meeting. Then, when the monitoring parameters meet preset conditions, it quickly determines that a fault exists in the video conference and determines the corresponding repair strategy to fix the fault, thereby effectively improving the stability and reliability of the video conference, ensuring its smooth operation, and enhancing the user experience. At the same time, this automated fault detection and repair method also reduces the need for manual intervention and lowers maintenance costs.

[0125] This application also provides a fault detection and repair device, which is applied to the local device in the aforementioned video conferencing system. The fault detection and repair device includes:

[0126] The acquisition unit is used to collect monitoring parameters of the local device during video conferencing between the local device and the remote device. These monitoring parameters are used to characterize the performance of the streaming media or the local device during the video conferencing process.

[0127] The determination unit is used to determine that there is a fault in the video conference when the monitoring parameters meet the corresponding preset conditions, and to determine the corresponding repair strategy for the fault.

[0128] The fault repair unit is used to complete fault repair according to the repair strategy.

[0129] The fault detection and repair device is also used to perform other functions mentioned in the above fault detection and repair methods, which will not be described in detail here.

[0130] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0131] This application also provides an electronic device 30, including: at least one processor 31; and at least one memory 32. The memory 32 stores instructions executable by at least one processor 31, which, when executed by at least one processor 31, enable at least one processor 31 to perform the fault detection and repair method described above.

[0132] Processor 31 and memory 32 can be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0133] The processor 31 is used to provide computing and control capabilities to control the electronic device 30 to perform corresponding tasks, such as controlling the electronic device 30 to perform the fault detection and repair method in any of the above method embodiments, including: during a video conference between the local device and the peer device, collecting monitoring parameters of the local device, the monitoring parameters being used to characterize the performance of the streaming media or the local device during the video conference; when the monitoring parameters meet the corresponding preset conditions, determining that there is a fault in the video conference; determining the repair strategy corresponding to the fault, and completing the fault repair according to the repair strategy.

[0134] By collecting monitoring parameters of the local device in real time during video conferences with the remote device, the actual situation of the video conference can be obtained promptly and accurately. When the monitoring parameters meet preset conditions, a fault in the video conference can be quickly identified, and a corresponding repair strategy can be determined to fix the fault. This effectively improves the stability and reliability of the video conference, ensures its smooth operation, and enhances the user experience. At the same time, this automated fault detection and repair method reduces the need for manual intervention and lowers maintenance costs.

[0135] Processor 31 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0136] The memory 32, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the fault detection and repair method in the embodiments of the present invention. The processor 31 executes various functional applications and data processing of the electronic device by running the non-volatile software programs, instructions, and modules stored in the memory 32, thereby implementing the fault detection and repair method of the above-described method embodiments.

[0137] The memory 32 may include volatile memory (VM), such as random access memory (RAM); the memory 32 may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), solid-state drive (SSD), or other non-transitory solid-state storage devices; the memory 32 may also include combinations of the above types of memory.

[0138] Memory 32 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 32 may optionally include memory remotely located relative to processor 31. Examples of the above-described networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0139] One or more modules are stored in memory 32. When executed by one or more processors 31, they perform the fault detection and repair methods in any of the above method embodiments, for example, performing... Figure 2 The steps shown.

[0140] In this embodiment, the electronic device 30 also includes a display for showing the video conference video feed and an audio player for playing the video conference audio. The electronic device 30 may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The electronic device 30 may also include other components for implementing device functions, which will not be elaborated here.

[0141] This application also provides a non-volatile computer storage medium storing computer-executable instructions, which are executed by one or more processors to perform the fault detection and repair method described above. For example, the non-volatile computer storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CDROM), magnetic tape, floppy disk, or optical data storage device, etc.

[0142] It should be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0143] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0144] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; under the concept of the present invention, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the present invention as described above, which are not provided in detail for the sake of brevity; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A fault detection repair method characterized by, The method comprises the following steps: In the process of video conference between the local device and the opposite device, the monitoring parameters of the local device are collected, which are used to represent the performance of the stream media or the local device in the process of video conference; When the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference has a fault; The corresponding repair strategy of the fault is determined, and the fault is repaired according to the repair strategy.

2. The fault detection repair method of claim 1, wherein, The monitoring parameters include opposite ip address and local ip address; When the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference has a fault, which comprises the following steps: whether the opposite ip address and the local ip address are in the same network segment is detected when no media stream data is received within a first preset time period; if the opposite ip address and the local ip address are not in the same network segment, it is determined that the video conference has a fault; The corresponding repair strategy of the fault is determined, which comprises the following steps: the repair strategy is determined to be sending the received media stream to the source address of the media stream.

3. The fault detection repair method according to claim 1 or 2, characterized in that, The monitoring parameters include audio synchronization source identifier and video synchronization source identifier; When the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference has a fault, which comprises the following steps: when the audio synchronization source identifier and the video synchronization source identifier are the same, it is determined that the video conference has a fault; The corresponding repair strategy of the fault is determined, which comprises the following steps: the repair strategy is determined to be replacing the first identifier with the target identifier, the first identifier and the target identifier are different, and the first identifier is the audio synchronization source identifier or the video synchronization source identifier.

4. The fault detection repair method of claim 3, wherein, The monitoring parameters include total bandwidth and video distribution bandwidth; When the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference has a fault, which comprises the following steps: when the total bandwidth is greater than a first preset bandwidth, and the video distribution bandwidth is less than a second preset bandwidth, it is determined that the video conference has a fault; The corresponding repair strategy of the fault is determined, which comprises the following steps: the repair strategy is determined to be reallocating bandwidth to adjust the video distribution bandwidth.

5. The fault detection repair method of claim 3, wherein, The monitoring parameters include audio stream data and video stream data; When the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference has a fault, which comprises the following steps: when no audio stream data is received within a second preset time period, the call is hung up and it is detected whether the video stream data is received; if the video stream data is received, it is determined that the video conference has a fault; The corresponding repair strategy of the fault is determined, which comprises the following steps: the repair strategy is determined to be modifying the media detection time to close the hang-up check.

6. The fault detection repair method of claim 3, wherein, The monitoring parameters include binary conference control protocol (Bfcp) signaling; When the monitoring parameters meet the corresponding preset conditions, it is determined that the video conference has a fault, which comprises the following steps: when the Bfcp signaling does not communicate normally, it is determined that the video conference has a fault; The determining the repair strategy corresponding to the fault comprises determining the repair strategy as modifying a transmission mode of the Bfcp protocol.

7. The fault detection repair method of claim 3, wherein, The monitoring parameter comprises a decoding state; The determining the video conference as having a fault when the monitoring parameter satisfies a corresponding preset condition comprises determining the video conference as having a fault when the decoding state is decoding failure; The determining the repair strategy corresponding to the fault comprises determining the repair strategy as modifying a stream identifier of a received media stream or modifying a packaging mode of the received media stream.

8. A fault detection repair apparatus, characterized by, The fault detection and repair apparatus is applied to a local device in a video conference system, the video conference system further comprising a remote device, and the fault detection and repair apparatus comprises: a collecting unit configured to collect a monitoring parameter of the local device during a video conference process of the local device and the remote device, the monitoring parameter being used to represent a performance of a stream media or the local device during the video conference process; a determining unit configured to determine the video conference as having a fault when the monitoring parameter satisfies a corresponding preset condition, and determine a repair strategy corresponding to the fault; a fault repair unit configured to complete fault repair according to the repair strategy.

9. An electronic device, comprising: comprise: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the fault detection and repair method according to any one of claims 1-7.

10. A non-transitory computer storage medium, comprising, The computer storage medium stores computer executable instructions, and the computer executable instructions are executed by one or more processors to complete the fault detection and repair method according to any one of claims 1-7.

11. A video conferencing system, characterized by comprise a local device and a remote device; the local device and the remote device are connected in communication and transmit media stream data to each other; the local device is configured to execute the fault detection and repair method according to any one of claims 1-7.

Images