A multi-path video decoding dynamic scheduling system and method

Abstract

The application discloses a kind of multi-channel video decoding dynamic scheduling system and method, the system includes integrated first decoding unit host, external second decoding unit, network camera equipment and display device, host and second decoding unit establish two-way communication link to transmit control instruction, second decoding unit is independently net mouth and takes video stream, realize control and data separation, and complete multi-channel video picture superposition output.The application adopts five-layer hierarchical scheduling strategy, relies on joint cost function to distribute video decoding task;Set double threshold hysteresis migration mechanism to suppress the frequent switching of task caused by load fluctuation;Periodic monitoring of video stream parameters realizes adaptive rescheduling, while multidimensional detection control communication link, decoding channel, front-end equipment and other faults and automatically migrate task self-healing.The application synchronously meets low-delay real-time decoding and complex image operation demand, balances hardware resources, improves system long-term running stability, and is suitable for remote control, security monitoring and other scenes.

Description

Technical Field

[0001] This invention relates to the field of video decoding technology, and in particular to a dynamic scheduling system and method for multi-channel video decoding, which is applicable to multi-channel video parallel processing scenarios (such as remote equipment operation, industrial monitoring, etc.) that require low latency in video decoding, complex information processing, and high system resource utilization. Background Technology

[0002] In applications such as remote device control, security monitoring, and visual command, it is often necessary to simultaneously access multiple network video streams and sequentially complete a series of operations, including video decoding, image processing, and multi-window simultaneous output. As video resolution, frame rate, and the number of concurrent video streams continue to increase, the decoding and processing capabilities of a single hardware device are gradually becoming insufficient to meet usage demands. Consequently, various decoding scheduling solutions for multiple video streams have emerged in the industry, such as hardware-software collaborative decoding scheduling solutions and multi-hardware parallel decoding solutions. Hardware-software collaborative decoding scheduling solutions combine the advantages of CPU software decoding and GPU hardware decoding to allocate tasks, thereby reducing the operational burden on a single decoding hardware device. For the high computational demands of parallel decoding of multiple high-definition videos, multi-hardware parallel decoding solutions distribute decoding tasks across multiple GPUs or external auxiliary decoding devices. By relying on the parallel operation of multiple hardware devices, overall load balancing is achieved, thus solving the problem of insufficient computing power of a single device to handle large-scale high-definition video decoding.

[0003] The aforementioned existing solutions provide basic processing functions for multi-channel video and can meet the video decoding and display needs in simple scenarios. However, in complex business scenarios, these solutions still have significant shortcomings and are difficult to adapt to differentiated business requirements, mainly facing the following core contradictions: 1. Resource conflicts exist between low-latency services and complex information processing services: Services such as remote control require extremely high end-to-end decoding and transmission latency, necessitating dedicated decoding hardware to ensure real-time performance; while complex information processing services such as target detection, 3D rendering, and data overlay require extensive complex computations, heavily relying on the computing power of general-purpose computing units. Existing scheduling schemes only perform simple traffic splitting for decoding tasks, without systematically designing an architecture for these two types of differentiated services. The low-latency requirements and complex computational requirements compete for hardware resources, often resulting in excessive latency for low-latency visuals and stuttering for complex computational services, failing to simultaneously meet the usage requirements of both types of services.

[0004] 2. Multi-channel parallel decoding is prone to system load imbalance and insufficient operational stability: When multiple high-resolution, high-frame-rate video streams are decoded simultaneously, they continuously consume a large amount of host CPU, GPU, and memory resources. Most existing solutions use static allocation or simple load balancing scheduling logic, lacking dynamic load control mechanisms. When the number of concurrent video streams increases, the parameters of a single video stream change dynamically, or the host runs other business programs simultaneously, it is easy to cause system resource overload, resulting in decoding stuttering, frame drops, and slow overall system response. At the same time, existing solutions are prone to repeated switching of decoding tasks due to small changes in load, causing system oscillations and further reducing the long-term stability of the equipment.

[0005] 3. Weak fault self-healing capability, business recovery relies on manual intervention: Existing multi-channel video decoding systems only have basic link status monitoring capabilities, with a single detection dimension. When problems such as decoding unit failure or network communication anomalies occur, the corresponding video stream will be directly interrupted. It is necessary for maintenance personnel to manually troubleshoot the fault location, manually adjust task allocation, or restart the equipment to restore the business. The duration of critical business interruption is uncontrollable and cannot meet the requirements of uninterrupted operation in scenarios such as security and remote control. Summary of the Invention

[0006] In summary, existing multi-channel video decoding technologies cannot simultaneously address the diverse service requirements of low latency and complex processing, exhibiting poor system load control capabilities and low fault recovery efficiency. To address these problems and technical requirements, the inventors propose a dynamic scheduling method and system for multi-channel video decoding, aiming to overcome the aforementioned deficiencies of existing technologies and improve the real-time performance, resource utilization, and operational reliability of multi-channel video decoding systems. The technical solution of this invention is as follows: In the first aspect, this application proposes a multi-channel video decoding dynamic scheduling system, including a host, an external second decoding unit, multiple network camera devices and a display device. The host integrates a first decoding unit for performing video decoding tasks for complex information processing business. Each network camera device is connected to the independent network interface of the host and the second decoding unit through a network switch for transmitting video streams of different service types; a bidirectional control communication link is established between the host and the second decoding unit for transmitting scheduling instructions and unit status data, thereby realizing the physical separation of control flow and video stream; The video signal output terminal of the host is connected to the video signal input terminal of the second decoding unit, and the video signal output terminal of the second decoding unit is connected to the display device. The second decoding unit is used to perform parallel video decoding tasks for low-latency and high-load video services, provide feedback on its own operating status, and overlay the multi-channel foreground video windows decoded by itself with the background video signal transmitted by the host, and output them to the display device for overall display. The host is used to complete the initial allocation of video decoding tasks for each channel based on a hierarchical scheduling strategy combined with video service type and preset configuration information. The host is also used to perform multi-dimensional real-time monitoring in parallel during system operation, and to trigger the rescheduling of corresponding video decoding tasks based on hierarchical scheduling strategies based on the monitoring results.

[0007] Secondly, this application also proposes a dynamic scheduling method for multi-channel video decoding, applied to the dynamic scheduling system for multi-channel video decoding as described in the first aspect, comprising the following steps: The host obtains the video stream parameter packets output by each network camera device, loads the preset configuration information, and determines the service type corresponding to each network camera device; the preset configuration information stores templates for different service types and the mapping relationship between network camera devices and services; Based on the hierarchical scheduling strategy combined with video service type and preset configuration information, the initial allocation of video decoding tasks is completed. The hierarchical scheduling strategy sets five decision levels with decreasing priority. Each video stream terminates the current round of scheduling judgment after hitting the corresponding level in sequence, and the video stream is obtained by the decoding unit assigned by that level. After all video streams have been allocated, the second decoding unit will overlay the multi-channel foreground video window it decodes with the background video signal transmitted by the host, and output the images to the display device for overall display. During system operation, multi-dimensional real-time monitoring is performed in parallel, including host load monitoring, video parameter monitoring, external operation monitoring, and system fault monitoring. Based on the monitoring results, the corresponding video decoding task is rescheduled according to the hierarchical scheduling strategy.

[0008] The beneficial technical effects of this invention are: This application adopts a heterogeneous hardware architecture with physical separation of control flow and data flow. The first decoding unit integrated on the host and the external second decoding unit form a functional division of labor: the second decoding unit is equipped with an independent network interface, and low-latency, high-load video streams are directly decoded by the front-end network camera device. The video data stream does not pass through the host for forwarding, reducing forwarding latency at the transmission link level and effectively ensuring the low-latency requirements of real-time control services. The first decoding unit on the host side completes complex information processing tasks such as target detection, 3D rendering, and data overlay after video decoding. The two types of services run on different hardware carriers. At the same time, the second decoding unit has a built-in hardware video overlay circuit, which combines the multiple foreground video windows decoded by itself with the background video signal output by the host before outputting it. Under the premise of realizing multi-screen display, it does not occupy additional host computing resources, and is suitable for composite application scenarios such as remote control and integrated monitoring that simultaneously have low-latency services and complex computing services.

[0009] The multi-channel video decoding dynamic scheduling method proposed in this application establishes a five-layer hierarchical scheduling strategy with decreasing priority. It orderly divides various scheduling conditions such as fault self-healing, forced binding, external operation, hardware inherent rules, and adaptive scheduling into priorities. Various scheduling instructions do not conflict with each other, ensuring that high-priority requirements such as forced rules, manual intervention, and fault handling are executed first, while reserving adaptive dynamic scheduling space for routine business. The scheduling logic is rigorous and the execution efficiency is high.

[0010] In the adaptive scheduling layer, the service requirements of each video stream are quantified by the service constraint vector, and the adaptability of different decoding hardware is represented by the decoding unit capability vector. Based on the joint cost function, the task is optimally allocated by comprehensively considering multiple factors such as service matching degree, video load, and hardware resource availability. This allows the decoding task to be accurately matched with the hardware capability and maximizes the utilization of the hardware resources of the dual decoding units.

[0011] This application introduces a dual-threshold hysteresis migration mechanism, distinguishing between load migration thresholds and load callback thresholds and setting corresponding judgment durations to form a hysteresis interval between the two thresholds. For situations where the host load fluctuates instantaneously or exceeds limits for a short period, the system will not trigger decoding task migration or callback, effectively avoiding repeated task switching caused by minor load fluctuations and eliminating system oscillations. When the load continuously deviates from the normal range, non-forced task migration to release resources or callback actions are automatically performed, dynamically balancing the overall load of the two decoding units. This prevents the host from experiencing decoding stuttering or slow overall response due to resource overload, ensuring long-term continuous and stable system operation. Attached Figure Description

[0012] Figure 1 This is a diagram of the multi-channel video decoding dynamic scheduling system architecture provided in this application; Figure 2 This is a schematic diagram of the built-in functional modules of the host provided in this application; Figure 3 This is a flowchart of the multi-channel video decoding dynamic scheduling method provided in this application; Figure 4 This is the layout diagram of the initial video display window provided in this application. Detailed Implementation

[0013] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0014] Example 1: Multi-channel video decoding dynamic scheduling system Please refer to Figure 1 As shown, one embodiment of this application provides a multi-channel video decoding dynamic scheduling system, which mainly includes a host (integrating a first decoding unit), an external second decoding unit, multiple network camera devices, and a display device. The functions of each core component are described below: 1) Host: Responsible for load sensing, dynamic scheduling, status monitoring, command issuance, and network video streaming. It is equipped with a PCIe (Peripheral Component Interconnect Express) interface, a Gigabit Ethernet port, and an HDMI (High Definition Multimedia Interface) output interface. It handles complex information processing tasks, synchronously renders the host desktop, and generates a local video signal as the global background layer, with the lowest display priority. The first decoding unit is integrated inside the host and consists of the host CPU and GPU. The CPU unit is responsible for software decoding of non-standard encoded video formats, offering format compatibility advantages. The GPU unit is responsible for hardware decoding of standard encoded video formats and subsequent complex information processing (such as object detection, 3D rendering, and data overlay). Non-standard encoded video formats refer to video streams that do not use mainstream encoding formats such as H.264 and H.265.

[0015] Optionally, the first decoding unit is not limited to the host built-in GPU, but can also be an NPU, FPGA or other computing unit with complex image processing capabilities.

[0016] 2) Second Decoding Unit: The hardware carrier is an external, independent dedicated decoding module. It establishes a bidirectional control communication link with the host CPU via a PCIe interface, receiving host scheduling commands to perform service migration and feeding back unit status data to the host. It is configured with an independent gigabit Ethernet port, directly pulling the corresponding video stream for parallel video decoding tasks according to host control commands. Decoding does not consume host CPU / GPU resources, and video is displayed according to the priority of the window position size specified in the host control commands. As the system's sole display output source, it is configured with at least one HDMI input interface and at least one HDMI output interface as video signal input / output terminals. The host's HDMI output interface (video signal output terminal) is connected to the HDMI input interface of this unit, and the HDMI output interface of this unit is connected to the display device.

[0017] In this embodiment, the second decoding unit has a built-in independent HDMI signal overlay hardware circuit, which can overlay the multi-channel windowed video signals (foreground layer) generated by its own decoding with the complete desktop video signal (background layer) output by the host. Window priority configuration is supported, with high-priority windows automatically covering the overlapping areas of low-priority windows. By default, the display priority of the foreground window is higher than that of the background layer; after signal overlay processing, the foreground window is displayed on top of the background layer.

[0018] Optionally, the second decoding unit is not limited to an external dedicated decoding module, but can also be an independent hardware decoding board, an embedded decoding device, an FPGA decoding module, or a dedicated chip with multi-channel low-latency decoding capability.

[0019] Optionally, the display overlay method is not limited to HDMI overlay output; DP, SDI, network streaming, local rendering and compositing, or other video output methods can also be used.

[0020] 3) Network camera equipment: Each network camera equipment is connected to the host and the independent network interface of the second decoding unit through a network switch, and is used to transmit real-time streaming protocol (RTSP) network video streams of different service types.

[0021] 4) Display device: used to receive the superimposed video signal output by the second decoding unit.

[0022] The hardware connection relationships of the above core components are as follows: Figure 1 As shown, the host establishes a control connection with the second decoding unit via a PCIe interface; the host's HDMI output interface is connected to the second decoding unit's HDMI input interface; the second decoding unit's HDMI output interface is connected to the display device; all network cameras and the host are connected to the same Ethernet switch; the second decoding unit is connected to the switch via its own independent Gigabit Ethernet interface. The system's service data flow is as follows: for low-latency and high-load video services, the video stream is directly transmitted from the network camera to the independent network interface of the second decoding unit, where it is decoded and directly sent to the built-in overlay circuit as the foreground layer. This bypasses the host, reducing transmission latency and achieving physical separation of the control flow and video stream. For complex information processing services, the video stream is transmitted to the host's network interface, where the first decoding unit decodes and processes the complex information. After synchronous rendering with the host desktop, it is sent to the second decoding unit via the HDMI output interface as the background layer. The second decoding unit then hardware overlays the foreground and background layers and outputs them uniformly to the display device for overall display.

[0023] The host computer acts as the control center, using a hierarchical scheduling strategy combined with video service types and preset configuration information to initially allocate video decoding tasks for each channel. It then sends all control / scheduling commands to the second decoding unit via the PCIe interface. The second decoding unit provides real-time feedback on its operating status to the host via the PCIe interface, including the status of each decoding channel, resource load, and command execution results. The host computer also performs multi-dimensional real-time monitoring in parallel during system operation and triggers rescheduling of corresponding video decoding tasks based on the hierarchical scheduling strategy according to the monitoring results.

[0024] Combination Figure 2As shown, the host integrates multiple functional modules, including a configuration information module, a service identification and parsing module, a dynamic scheduling module, a load monitoring module, a video parameter monitoring module, a fault monitoring module, an external operation monitoring module, and a control command module. Each monitoring module performs real-time detection of host load, video stream parameters, system equipment and communication link faults, and external operation commands, and, based on the monitoring results, coordinates with the dynamic scheduling module to reschedule the corresponding video decoding tasks based on a hierarchical scheduling strategy. The functions of each module are described below: 1) Configuration information module, used to store all static configurations required for system operation. In this embodiment, it exists in the form of an XML configuration file, which can be modified before the system runs. The content defined in the XML includes: a. Templates for different business types: Define the business types supported by the system (such as low-latency demand business, high-load video demand business, complex information processing business, etc.), and the default base vector and default binding rules (such as forced binding / preferred binding) for each type. For example, the type "main" represents the main control perspective (belonging to low-latency demand business), and its default constraint vector is [0.9, 0.0, 0.1] (extremely high low-latency demand, insensitive to resource consumption, no complex information processing), and the default binding rule is forced binding to the second decoding unit.

[0025] b. Mapping relationship between network camera devices and services: Map each camera URL (Uniform Resource Locator) to a specified service type and declare binding rules (force / prefer).

[0026] c. Function weights: The weight coefficients of each dimension of the joint cost function in the hierarchical scheduling strategy.

[0027] d. System thresholds: Configure parameters such as load migration threshold, load callback threshold, video parameter change trigger threshold, and monitoring period.

[0028] Optionally, the configuration file is not limited to XML format; it can also be in JSON, database table, or other editable configuration formats.

[0029] 2) The service identification and parsing module is used to parse the video stream parameters output by each network camera device and, in conjunction with the configuration information storage module, generate a service constraint vector corresponding to each video stream for use by the dynamic scheduling module. The video stream parameters typically include the URL, resolution, frame rate, encoding format, and bitrate of each video stream.

[0030] The business constraint vector is defined as a three-dimensional quantized vector. The three dimensions correspond to the video's low-latency requirements, low-resource consumption requirements, and complex information processing requirements, respectively. Each dimension's value ranges from 0 to 1, and the values ​​of each dimension are normalized. In one possible implementation, for the i-th video stream, its business constraint vector is represented as: The meaning and value descriptions of each dimension are shown in Table 1: Table 1. Definition of Business Constraint Vector

[0031] Optionally, in addition to the three dimensions mentioned above, parameters such as encoding stream stability and security level can be added according to actual needs.

[0032] 3) The dynamic scheduling module is the system's sole decision-making center. It integrates a hierarchical scheduling strategy, is responsible for maintaining the decoding unit capability vector, performing hierarchical scheduling and adaptation degree (joint cost function) calculations, and managing the allocation status of all videos. It works in conjunction with the load monitoring module, video stream parameter monitoring module, fault monitoring module, and external operation monitoring module. When triggered by any of these monitoring modules, it uniformly calls its scheduling interface to obtain the new allocation result.

[0033] a. Decoding Unit Capability Vector: The capability vector A of each decoding unit pre-configured by the system. j This vector represents capability from three dimensions: low latency, low resource consumption, and complex information processing capability. In one possible implementation, the capability vector values ​​for the first / second decoding unit can be referenced as shown in Table 2 below: Table 2. Definition of Decoding Unit Capability Vector

[0034] b. Hierarchical Scheduling Engine: This engine sets up five decision levels with decreasing priorities. Each video stream, after sequentially matching its corresponding level, terminates the current round of scheduling, returns the allocation result, and the video stream is then acquired by the decoding unit assigned to that level. The specific details of the five priority levels are shown in Table 3. Table 3. Definition of Five-Level Priority Decision-Making Hierarchy

[0035] In one possible implementation, the joint cost function is expressed as: The default value for the weighting coefficients (which can be configured in XML) is... , , Each calculation factor is defined as follows: Business constraint matching degree B , is the business constraint vector c i With decoding unit capability vector A jThe dot product of the values. A larger value indicates that the decoding unit is more closely matched to the service requirements of that video stream.

[0036] Video load matching V The value is determined by the resolution and frame rate quantization in the current video stream parameter packet. For example, 4K@60fps=1.0, 1080P@30fps=0.7, 720P@15fps=0.4. The goal is to allocate more resources to the second decoding unit as the video load increases.

[0037] Resource surplus R The resource utilization rate is calculated based on the real-time resource utilization of each decoding unit. In this embodiment, it is defined as R = 1 - current resource utilization rate, where the resource utilization rate of the first decoding unit is the weighted value of the host CPU utilization rate and the GPU memory usage rate, and the resource utilization rate of the second decoding unit is the channel usage rate. The lower the resource utilization, the less suitable the decoding unit is for undertaking new tasks.

[0038] 4) The load monitoring module is responsible for monitoring the host load, that is, continuously collecting the host CPU utilization and GPU memory usage to calculate the host's overall resource pressure index in real time: 0.4 × CPU utilization + 0.6 × GPU memory usage. When the index exceeds the preset range, a hysteresis migration mechanism is used to dynamically migrate or call back the migrateable tasks marked in the fifth decision level. The hysteresis migration mechanism uses dual threshold control logic, with a pre-set load migration threshold and a load callback threshold, forming a hysteresis interval.

[0039] In one possible implementation, when the index continuously exceeds the load migration threshold (default 0.78) and reaches a preset duration (default 8 seconds), the system retrieves a list of all tasks marked as "migratable tasks" from the allocation status management of the dynamic scheduling module and calls the scheduling interface of the dynamic scheduling module to submit for rescheduling. The dynamic scheduling module initiates a hierarchical scheduling engine for these tasks one by one. Due to reduced host resource availability at the fifth layer, the recalculation of adaptability may lead to the task being assigned to the second decoding unit. If the new assignment result differs from the original unit, a switch is triggered via the control instruction module. If the assignment results for all migrateable tasks remain unchanged, a high load alarm is issued.

[0040] In one possible implementation, when the index remains below the load callback threshold (default 0.60) for a preset duration (default 20 seconds), the migrateable tasks previously vacated due to excessive load are retrieved from the allocation status management of the dynamic scheduling module, and the scheduling interface of the dynamic scheduling module is called to submit for rescheduling. The fifth layer, due to the recovery of host resource availability and recalculation of adaptability, may callback the task to the first decoding unit. If the new allocation result differs from the original unit, a callback switch is triggered via the control instruction module.

[0041] Load fluctuations within a hysteresis range of 0.18 between the migration threshold and the callback threshold do not trigger task migration or callback actions. This embodiment sets a hysteresis range in conjunction with a duration condition to effectively suppress frequent switching of decoding tasks and system oscillations caused by load fluctuations.

[0042] Optionally, the overall host resource stress index is not limited to CPU, memory, GPU and video memory parameters, but may also include PCIe bandwidth, network bandwidth, decoding queue length, frame drop rate, etc.

[0043] 5) The video parameter monitoring module sends an RTSP DESCRIBE media description request (less than 1KB each time) to all network cameras every 5 seconds to obtain the SDP file and parse the SPS / PPS parameters for monitoring changes in video resolution, frame rate, and encoding format. When a video's resolution or frame rate change exceeds a preset threshold (e.g., resolution change ≥ 25% or frame rate change ≥ 50%), the service identification and parsing module regenerates the service constraint vector for that video, and then calls the scheduling interface of the dynamic scheduling module to submit the video for rescheduling. The dynamic scheduling module starts the hierarchical scheduling engine to re-evaluate layers one through five and returns a new allocation result. If the new allocation result differs from the original decoding unit, a switch is triggered via the control command module. Other videos are unaffected.

[0044] If the changes in video parameters do not exceed the preset change threshold, continue to the next round of monitoring.

[0045] 6) The monitoring objects of the fault monitoring module include the bidirectional control communication link (PCIe communication link), each decoding channel of the second decoding unit, the video transmission channels of each network camera device, and the GPU of the first decoding unit. This embodiment sets corresponding judgment conditions for different fault types. After a fault is determined, the affected video decoding tasks are redistributed to normal decoding units according to the fault self-healing rules, and fault alarm information is output synchronously. Specific fault detection and handling methods are shown in Table 4 below: Table 4. Implementation of Fault Monitoring Module

[0046] 7) The external operation monitoring module is triggered by user interaction events and is non-periodic. It is used to listen for user manual switching of a video stream to a specified decoding unit.

[0047] 8) The control command module sends scheduling and video display window control commands to the second decoding unit through a bidirectional control communication link (PCIe interface). The control commands adopt a standard frame structure, including fields such as frame header, length, video stream URL, whether to display in a window, window coordinates, window size, window priority, checksum, and frame tail.

[0048] This embodiment employs a window management method based on direct coordinate mapping: the window coordinate parameters sent by the host directly correspond to the pixel positions of the HDMI signal, and the hardware circuit of the second decoding unit inserts the decoded video data into the corresponding positions according to the coordinate parameters. Window operations only require updating the coordinate parameters and do not require transmitting video data.

[0049] In one possible implementation, the hardware functional parameter requirements for the above-mentioned multi-channel video decoding dynamic scheduling system are as follows: 1. Main Unit: General-purpose computing processor, CPU cores ≥ 8, clock speed ≥ 2.0GHz, memory capacity ≥ 16GB, hard drive capacity ≥ 2TB, domestic Linux-like operating system, 2 PCIe 4.0×16 lanes, supports ≥ 2 HDMI output channels, maximum resolution not less than 3840×2160@60Hz. The HDMI output channels are directly connected to the HDMI input of the second decoding unit.

[0050] 2. First Decoding Unit: Core frequency ≥ 1.2GHz, supports OpenGL 4.0, video memory capacity ≥ 16GB, single-precision floating-point computing power ≥ 1.5 TFOPS. Supports decoding of AVC (H.264), HEVC (H.265), MPEG2, MPEG4, JPEG and other formats. Supports decoding up to 3840×2160@60fps. Supports decoding API frameworks such as ffmpeg, gstreamer, vaapi, vdpau and others.

[0051] 3. Second Decoding Unit: Supports multiple network video inputs and decoding. Supports scaling, combining, and overlaying of multiple decoded videos. Codec algorithms support H.264 and H.265. Supports simultaneous low-latency decoding of ≥16 channels of 1920×1080@30fps video. Supports simultaneous low-latency decoding of ≥2 channels of 3840×2160@60fps video. Supports PCIe bus communication. Supports ≥2 channels of HDMI video input and ≥2 channels of HDMI video output.

[0052] 4. Network Camera Equipment: Supports RTSP / ONVIF standard protocols. Supports H.264, H.265 and other encoding formats. Supports multi-stream output at different resolutions (4K / 1080P / 720P, etc.). Supports adjustable frame rate and bitrate.

[0053] 5. Display Device: One monitor supporting multiple resolutions including 4K (3840×2160) and 1080P (1920×1080). Includes at least one HDMI 2.0 port. The resolution is set to 1080P, and it connects directly to the HDMI output of the second decoding unit without any additional adapters.

[0054] The configuration information file uses XML format and supports manual editing of rules. The business type module in the preset initial table structure is represented as follows: <businesstemplates> <!-- Main control perspective template --> <Template name="main" <!-- Template name, referenced for camera mapping --> c1="0.9" <!-- Default value of low-latency requirement weight, range 0~1 --> c2="0.0" <!-- Default value of low-resource occupation requirement weight --> c3="0.1" <!-- Default value of complex processing requirement weight --> default_mode="force" <!-- Default binding rule: force=forced locking, prefer=initial priority and migratable --> default_unit="second_decoder" <!-- Default binding target: first_decoder=host, second_decoder=external decoding unit --> / > In the complex information processing template "analysis", c1="0.1", c2="0.2", c3="0.7"; default_mode="force"; default_unit="first_decoder".

[0055] In the ordinary monitoring template "monitor", c1="0.2", c2="0.6", c3="0.2"; default_mode="prefer" <!-- Preferred but not mandatory, can be migrated when load is high -->; default_unit="second_decoder" <!-- Prefer to use the external decoding unit -->.

[0056] The mapping between camera devices and service types in the preset initial table structure is shown as follows: <businesstemplates> <!-- Bind the RTSP URL of each camera to the service type --> <cameramappings> <Mapping URL="rtsp: / / 192.168.1.10 / main" <!-- RTSP address of the camera, unique identifier --> template="main" <!-- Name of the referenced service template, corresponding to the name of Template --> mode="force" <!-- Binding mode: force=forced locking and non-migratable, prefer=initial priority and migratable --> / > For the joint cost function weights and system thresholds in the preset initial table structure, reference can be made to the relevant content above, and details are not repeated herein.

[0057] In the control instruction module, the host sends a standard data frame structure to the second decoding unit, and the parameter fields are shown in Table 5; after receiving the standard data frame sent by the host, the second decoding unit feeds back its own status, and the parameter fields are shown in Table 6.

[0058] Table 5. Control Instruction Parameter Table

[0059] Table 6. Status Feedback Parameter Table

[0060] Example 2: Dynamic Scheduling Method for Multi-channel Video Decoding Please refer to Figure 3 , in one embodiment of the present application, a dynamic scheduling method for multi-channel video decoding is disclosed, which is applied to the dynamic scheduling system for multi-channel video decoding provided in Example 1, and includes the following steps: Step 1: System initialization. Start the host, the second decoding unit, the display device, and the external network camera device, establish control and data connections for each module, and complete hardware self-check. Initialize window layout display. As shown in Figure 4 , the number and layout of windows support manual modification.

[0061] Step 2: Read configuration information. The software integrated in the host starts, loads the preset configuration information XML file, and reads core rules. The preset configuration information stores templates of different service types and mapping relationships between network camera devices and services.

[0062] Step 3: Parse video parameters. The host obtains the video stream parameter packets output by each network camera device and determines the service type and video stream parameters corresponding to each network camera device based on the preset configuration information. Specifically, the software integrated into the host reads the URLs corresponding to all devices, reads the service type corresponding to the camera URL in the XML, and sends RTSP DESCRIBE requests to all network camera devices to parse the video stream parameters (resolution, frame rate, encoding format, etc.).

[0063] Step 4: Generate the service constraint vector for each video stream. The service constraint vector is defined as a three-dimensional quantized vector. The three dimensions correspond to the low latency requirement, low resource consumption requirement, and complex information processing requirement of the video, respectively. The value of each dimension ranges from 0 to 1, and the values ​​of each dimension of the vector are normalized. Specific definitions can be found in Table 1, and will not be repeated here.

[0064] When generating the service constraint vector for each video stream, the base vector is determined based on the service type template corresponding to the video stream. The vector values ​​are then dynamically adjusted by combining the real-time resolution, frame rate, and the on / off status of the complex processing functions acquired by the host for that video stream from the retrieved video stream parameter package. The sum of all weights is 1. When a weight is adjusted due to changes in real-time parameters, the other weights are compressed proportionally to maintain normalization.

[0065] Step 5: Initial allocation of decoding units. Based on the hierarchical scheduling strategy combined with video service type and preset configuration information, the initial allocation of video decoding tasks for each channel is completed. The hierarchical scheduling strategy sets five decision levels with decreasing priority. Each video stream terminates the current round of scheduling judgment after hitting the corresponding level in sequence, and the decoding unit assigned by that level obtains the video stream.

[0066] In this embodiment, the five priority decision levels of the hierarchical scheduling strategy are as follows: The first level is the fault alarm level, which forcibly allocates decoding tasks according to preset fault self-healing rules when a fault is detected in the system equipment or communication link. The second level is the preset binding level, which directly allocates video streams configured with forced binding rules (marked as mode="force" in XML) to designated decoding units and locks the tasks (which are not transferable throughout the process). The binding rules for each video stream are defined in the service type template of the preset configuration information. The third level is the external operation level, which allocates video streams to designated decoding units and locks the tasks according to external operation instructions (such as user-manually specifying decoding units or enabling a complex function) (without violating the first level). The fourth level is the system hard logic level, which forcibly allocates decoding tasks according to the inherent rules set by the video encoding format and resolution upper limit. For example, non-standard encoding formats are forcibly allocated to the first decoding unit; 4K@60fps and above are forcibly allocated to the second decoding unit. The fifth level is the adaptive scheduling level, which completes the decoding task allocation by calculating the compatibility between different decoding units and video streams for video streams that do not hit the first four levels. The tasks allocated at this level are marked as transferable tasks.

[0067] In this hierarchical scheduling strategy, the adaptive scheduling levels use a joint cost function to calculate the overall fit between different decoding units and the video stream, and select the decoding unit with the higher fit value to assign video decoding tasks. In one possible implementation, the joint cost function S uses the service constraint matching degree... B Video load matching degree V Resource surplus R The calculation factor is set, and a preset weighting coefficient is configured for weighted calculation. The expression is: S = 0.50 × B +0.30× V +0.20× R Among them, business constraint matching degree B Let c be the business constraint vector. i With the pre-configured capability vector A of each decoding unit j The vector dot product, A j For specific definitions, please refer to Table 2; Video load matching degree V The value is determined by the resolution and frame rate quantization in the current video stream parameter packet; for example, 4K@60fps=1.0, 1080P@30fps=0.7, 720P@15fps=0.4; resource availability. R Based on the real-time resource utilization of each decoding unit, it can be defined as R = 1 - current resource utilization, where the resource utilization of the first decoding unit is the weighted value of the host CPU utilization and the GPU memory usage, and the resource utilization of the second decoding unit is the channel usage.

[0068] Step 6: After all video streams have been allocated, the second decoding unit overlays the multi-channel foreground video windows it decodes with the background video signal transmitted by the host, and outputs them to the display device for overall display.

[0069] Step 7: During system operation, multi-dimensional real-time monitoring is performed in parallel, including host load monitoring, video parameter monitoring, external operation monitoring, and system fault monitoring. Based on the monitoring results, the corresponding video decoding tasks are rescheduled using a hierarchical scheduling strategy. Each dimension runs in parallel and is triggered independently on a periodic basis. A: In host load monitoring, the real-time host comprehensive resource pressure index is calculated as 0.4 × CPU utilization + 0.6 × GPU memory usage. When the index exceeds the preset range, a hysteresis migration mechanism is used to dynamically migrate or call back the migrateable tasks marked in the fifth decision level. The hysteresis migration mechanism employs dual-threshold control logic, with a pre-set load migration threshold and a load callback threshold, forming a hysteresis interval.

[0070] In one possible implementation, when the index continuously exceeds the load migration threshold (default 0.78) and reaches a preset duration (default 8 seconds), return to step 5, scan all currently marked as fifth-layer migrateable tasks, and select the migrateable task with the best fit to migrate to the second decoding unit. When multiple migrateable tasks exist, for each migrateable task, calculate the fit difference between different decoding units and the video stream, and select the migrateable task with the smallest difference to migrate to the second decoding unit. If no migrateable task is found, issue a high-load alarm and continue monitoring.

[0071] In one possible implementation, when the index remains below the load callback threshold (default 0.60) and reaches a preset duration (default 20 seconds), the tasks previously migrated out due to excessive load are callbacked back to the original decoding unit. If no such task exists, monitoring continues.

[0072] Load fluctuations within the hysteresis interval (0.18) do not trigger task migration or callback actions. This embodiment sets a hysteresis interval in conjunction with a duration condition, which can effectively suppress frequent switching of decoding tasks and system oscillations caused by load fluctuations.

[0073] B: In video parameter monitoring, the host sends RTSP DESCRIBE media description requests (less than 1KB each time) to each network camera device at a fixed period (e.g., every 5 seconds) to parse and obtain the resolution, frame rate, and encoding format parameters from the video stream parameter packets. When the resolution or frame rate change ratio of a certain video stream is detected to exceed the corresponding preset change threshold (e.g., resolution change ratio ≥ 25% or frame rate change ratio ≥ 50%), the system returns to step 4 to regenerate the service constraint vector of that video stream and triggers a rescheduling of the video decoding task based on the hierarchical scheduling strategy, i.e., re-executes the first to fifth layer judgments in step 5. If the allocation result changes, a switch is performed. Other videos are unaffected.

[0074] C: The monitoring objects, detection methods, judgment conditions, and self-healing actions for system fault monitoring can be found in Table 4, and will not be repeated here. During fault monitoring, the PCIe communication heartbeat, the status of each decoding channel, the RTSP DESCRIBE response of the network camera device, and the GPU driver status are independently inspected. When any fault is determined, the system jumps back to the hierarchical scheduling entry point in step 5. After the first layer captures the fault, it reallocates the affected video decoding tasks to normal decoding units according to the corresponding fault self-healing rules, and outputs fault alarm information synchronously, recording the new allocation results.

[0075] D: In external operation monitoring, listen for user interaction events, including manually dragging and dropping a specific video decoding unit, and enabling or disabling global complex processing functions. When a user operation event occurs, the affected video jumps back to the hierarchical scheduling entry point in step 5 and re-executes the judgments from the first to the fifth layer. After capturing the user operation, the third layer assigns decoding tasks according to the user's specifications and locks them. If the assignment result changes, a switch is performed. After the user manually locks the task, it suspends participation in the dynamic migration of "A", but the fault self-healing of "C" can still cover it.

[0076] The main loop continues to run, with each of the four monitoring dimensions triggering independently until the system shuts down.

[0077] In one possible implementation, this method takes the remote control of an underwater robot as an example. The robot is equipped with six network cameras, one of which is the main viewpoint related to operation. To achieve real-time control response, the main viewpoint network video must be transmitted and displayed with extremely low latency. The remaining five network videos are auxiliary views from other directions. The host software is required to periodically refresh and display the acquired position, attitude, speed, and other information, and to have target recognition and detection functions. The initial configuration of the scenario is shown in Table 7. Table 7. Control Command Parameter Table

[0078] The system thresholds are as follows: load migration threshold 0.78, migration duration 8 seconds, load callback threshold 0.60, callback duration 20 seconds.

[0079] Decoding unit capability vector: First decoding unit [0.3, 0.3, 0.9], Second decoding unit [0.9, 0.9, 0.0].

[0080] Joint cost function: S = 0.50 × B + 0.30× V + 0.20× R .in B This is the business constraint matching degree (the dot product of the business constraint vector and the capability vector). V Video load matching score (1080P@30fps=0.7, 4K@60fps=1.0). R Resource surplus (1 - current utilization rate).

[0081] The auxiliary perspective 5 service constraint vector C = [0.2, 0.6, 0.2]. Initially, the resource surplus of the first decoding unit is 0.90, and the resource surplus of the second decoding unit is 0.10. Calculations show S1 = 0.50×0.42 + 0.30×0.7 + 0.20×0.90 = 0.600, and S2 = 0.50×0.72 + 0.30×0.7 + 0.20×0.10 = 0.590. Since S1 > S2, auxiliary perspective 5 is initially assigned to the first decoding unit and marked as a layer 5 portable task. The initial allocation results of each decoding unit, host resource utilization, and overall resource pressure index are shown in Table 8. Table 8. Initial Allocation of Decoding Tasks and Host Resources

[0082] (a) Load-triggered dynamic migration Verification objective: To demonstrate that when the host load exceeds the migration threshold, Layer 5 migrated tasks are automatically and smoothly migrated to low-load units.

[0083] Operation: The 3D rendering software was launched, and the host load steadily increased over 15 seconds. The host load change data is shown in Table 9. Table 9. Host Load Variation over Time

[0084] The specific migration decision-making steps are as follows: Step 1: Scan for transferable tasks. Auxiliary view 5 shows the transferable tasks marked at layer 5.

[0085] Step 2: Calculate the adaptation difference. During migration, the resource remaining quantity of the first decoding unit is 0.136, and the resource remaining quantity of the second decoding unit is 0.90. Therefore, the updated adaptation values ​​are expressed as follows: S1'= 0.50×0.42 + 0.30×0.7 + 0.20×0.136 = 0.447 S2' = 0.50×0.72 + 0.30×0.7 + 0.20×0.90 = 0.750 Since there is only one transferable task, auxiliary viewpoint 5 is selected for scheduling.

[0086] The specific migration process is as follows: The host sends a command to the second decoding unit, which then decodes and displays the network video from auxiliary viewpoint 5. Table 10 shows a comparison of the host load before and after the migration. Table 10. Comparison of Host Load Migration Before and After

[0087] Expected results: When the load exceeds the threshold, automatic migration is triggered. The auxiliary viewpoint 5 migrates from the first decoding unit to the second decoding unit. The host stress index drops by 48.6%, the 3D rendering software resumes response, and the auxiliary viewpoint 5 screen switches normally.

[0088] (ii) Load callback Verification objective: To demonstrate that after the host load drops below the callback threshold and remains below it for a sufficient period of time, the migrated task automatically migrates back to its original unit.

[0089] Operation: The 3D rendering software was shut down, and the host load continued to decrease. The host load change data and the status of the decoding unit after the callback are shown in Tables 11 and 12, respectively. Table 11. Host load variation over time

[0090] Table 12. Decoding Unit Status After Callback

[0091] Expected result: After the load remains below the callback threshold for 20 seconds, auxiliary viewpoint 5 will automatically switch back to the first decoding unit and restore the initial scheme.

[0092] (iii) Hysteresis interval suppresses oscillations Verification objective: To demonstrate that the dual-threshold hysteresis interval can filter instantaneous load fluctuations and avoid frequent migrations. The changes in the comprehensive resource pressure index over time and the system behavior are shown in Table 13. Table 13. Changes in the Resource Pressure Index

[0093] Analysis of the data in Table 13 shows that the pressure index exceeded the threshold at T0+7s but only for 5 seconds, without triggering migration. From T0+30s to T0+50s, the load fluctuated between 0.55 and 0.72 three times, all within the hysteresis zone, without any action.

[0094] Expected result: The hysteresis mechanism avoids multiple invalid migrations or callbacks, ensuring system stability.

[0095] (iv) Parameter changes lead to loss of task transferability Verification objective: To demonstrate that after a transferable task is captured by the fourth-layer hard logic, it is released from dynamic migration management and protected by a lock.

[0096] Operation: Auxiliary view 5 is currently in the second decoding unit (after migration), and the remote platform switches it from 1080P@30fps to 4K@60fps.

[0097] Rescheduling Triggered: The parameter monitoring module detected a resolution change from 1920×1080 to 3840×2160 at the 5th second, with a change ratio of 1.0 exceeding the threshold of 0.25. The hierarchical judgment logic is shown in Table 14. Table 14. Hierarchical Judgment Logic

[0098] As shown in the table above, auxiliary viewpoint 5 has changed to the fourth layer of locking and is currently in the second decoding unit without switching. To verify the locking status, the 3D rendering software was restarted, and the host stress index remained at 0.85 for 12 seconds. System scan for transferable tasks: auxiliary viewpoint 5 is in the fourth layer of locking, and auxiliary views 1-4 are in the first layer of locking. There are no transferable tasks, and no migration occurs except for an alarm. The task allocation method, transferability, and system actions under overload before and after the resolution change are shown in Table 15. Table 15. Comparison of resolution before and after change

[0099] When the auxiliary view 5 drops back to 1080P@30fps, a rescheduling will be triggered again. If the fourth layer is not hit, the fifth layer judgment will be entered, and the task will be restored to a transferable task.

[0100] Expected results: High-load video is locked at the fourth layer to prevent the host from being overwhelmed by load balancing, thus ensuring 4K display quality; after the parameters are restored, dynamic scheduling will resume.

[0101] The above descriptions are merely preferred embodiments of this application, and the present invention is not limited to the above embodiments. It is understood that other improvements and variations directly derived or conceived by those skilled in the art without departing from the spirit and concept of the present invention should be considered to be included within the protection scope of the present invention.< / cameramappings> < / businesstemplates> < / businesstemplates>

Claims

1. A multi-channel video decoding dynamic scheduling system, characterized in that, It includes a host, an external second decoding unit, multiple network camera devices and a display device. The host integrates a first decoding unit for performing video decoding tasks for complex information processing. Each network camera device is connected to the independent network interface of the host and the second decoding unit through a network switch for transmitting video streams of different service types; a bidirectional control communication link is established between the host and the second decoding unit for transmitting scheduling instructions and unit status data, thereby realizing the physical separation of control flow and video stream; The video signal output terminal of the host is connected to the video signal input terminal of the second decoding unit, and the video signal output terminal of the second decoding unit is connected to the display device. The second decoding unit is used to perform parallel video decoding tasks for low-latency demand services and high-load video demand services, provide feedback on its own operating status, and overlay the multi-channel foreground video windows decoded by itself with the background video signal transmitted by the host, and output them to the display device for overall display. The host is used to complete the initial allocation of video decoding tasks for each channel based on a hierarchical scheduling strategy combined with video service type and preset configuration information. The host is also used to perform multi-dimensional real-time monitoring in parallel during system operation, and to trigger the rescheduling of the corresponding video decoding task based on the hierarchical scheduling strategy based on the monitoring results.

2. The multi-channel video decoding dynamic scheduling system according to claim 1, characterized in that, The integrated functional modules within the host include a configuration information module, a service identification and parsing module, a dynamic scheduling module, a load monitoring module, a video parameter monitoring module, a fault monitoring module, an external operation monitoring module, and a control command module. The configuration information module is used to store templates for different service types, the mapping relationship between the network camera device and the service, function weights and system thresholds. The templates define the service types, binding rules and basic vectors corresponding to different video streams. The service identification and parsing module is used to parse the video stream parameters output by each network camera device, and combine them with the configuration information storage module to generate a service constraint vector corresponding to each video stream; The dynamic scheduling module integrates the hierarchical scheduling strategy, which is used to perform hierarchical scheduling and adaptation calculation. The hierarchical scheduling strategy sets five decision levels with decreasing priorities. Each video stream terminates the current round of scheduling judgment after hitting the corresponding level in sequence, and the video stream is obtained by the decoding unit assigned by that level. Each monitoring module performs real-time detection of host load, video stream parameters, system equipment and communication link faults, and external operation commands. Based on the monitoring results, it links with the dynamic scheduling module to reschedule the corresponding video decoding task based on the hierarchical scheduling strategy. The control command module sends scheduling and video display window control commands to the second decoding unit through the bidirectional control communication link.

3. A dynamic scheduling method for multi-channel video decoding, characterized in that, The system applied to the multi-channel video decoding dynamic scheduling system as described in claim 1 or 2 includes the following steps: The host obtains the video stream parameter packets output by each network camera device, loads preset configuration information, and determines the service type corresponding to each network camera device; wherein, the preset configuration information stores different service type templates and the mapping relationship between the network camera devices and services; Based on the hierarchical scheduling strategy combined with video service type and preset configuration information, the initial allocation of video decoding tasks is completed. The hierarchical scheduling strategy sets five decision levels with progressively decreasing priority. Each video stream terminates the current round of scheduling judgment after hitting the corresponding level in sequence, and the video stream is obtained by the decoding unit assigned by that level. After all video streams are allocated, the second decoding unit overlays the multi-channel foreground video window it decodes with the background video signal transmitted by the host, and outputs the unified image to the display device for overall display. During system operation, multi-dimensional real-time monitoring is performed in parallel, including host load monitoring, video parameter monitoring, external operation monitoring, and system fault monitoring. Based on the monitoring results, the corresponding video decoding task is rescheduled according to the hierarchical scheduling strategy.

4. The multi-channel video decoding dynamic scheduling method according to claim 3, characterized in that, The five priority decision levels of the hierarchical scheduling strategy are as follows: The first layer is the fault alarm level. When a fault is detected in the system equipment or communication link, a decoding task is forcibly assigned according to the preset fault self-healing rules. The second layer is the preset binding layer, which directly assigns video streams with configured forced binding rules to the specified decoding unit and locks the task. The binding rules for each video stream are defined in the service type template of the preset configuration information. The third layer is the external operation layer, which allocates the video stream to the designated decoding unit and locks the task according to the external operation instructions; The fourth layer is the system's hard logic layer, which forcibly assigns decoding tasks based on the inherent rules set by the video encoding format and resolution limit. The fifth layer is the adaptive scheduling layer. For video streams that have not hit the first four layers, the decoding task is assigned by calculating the compatibility between different decoding units and the video stream. The tasks assigned at this layer are marked as transferable tasks.

5. The multi-channel video decoding dynamic scheduling method according to claim 4, characterized in that, The adaptive scheduling level of the hierarchical scheduling strategy uses a joint cost function to calculate the comprehensive fit between different decoding units and video streams, and selects the decoding unit with the higher fit value to assign video decoding tasks to it. The joint cost function uses business constraint matching degree, video load matching degree, and resource surplus as calculation factors, and performs weighted calculations with preset weight coefficients. Wherein, the business constraint matching degree is the vector dot product of the business constraint vector and the capability vector of each pre-configured decoding unit; The video load matching degree is determined based on the resolution and frame rate quantization in the current video stream parameter packet; The resource availability is calculated based on the real-time resource utilization rate of each decoding unit.

6. The multi-channel video decoding dynamic scheduling method according to claim 3, characterized in that, The method further includes generating a service constraint vector corresponding to each video stream, including: The business constraint vector is defined as a three-dimensional quantized vector. The three dimensions correspond to the low latency requirement, low resource consumption requirement, and complex information processing requirement of the video, respectively. The value range of each dimension is 0~1 and the values ​​of each dimension of the vector are normalized. When generating the service constraint vector for each video stream, the base vector is determined based on the service type template corresponding to the video stream, and the vector value is dynamically corrected by combining the real-time resolution, frame rate and the on / off status of the complex processing function of the host for acquiring the video stream in the video stream parameter package.

7. The multi-channel video decoding dynamic scheduling method according to claim 3, characterized in that, In the host load monitoring, the host comprehensive resource pressure index is calculated in real time, and when the index exceeds the preset range, a hysteresis migration mechanism is used to perform dynamic migration or callback of the migrateable tasks marked in the fifth decision level. The hysteresis migration mechanism employs dual-threshold control logic, pre-setting a load migration threshold and a load callback threshold, with the two thresholds forming a hysteresis interval. When the index continuously exceeds the load migration threshold and reaches a preset duration, the migration task with the best adaptability is selected and migrated to the second decoding unit. When the index remains below the load callback threshold for an extended period of time, the previously migrated tasks will be returned to the original decoding unit. Load fluctuations within the hysteresis range do not trigger task migration or callback actions.

8. The multi-channel video decoding dynamic scheduling method according to claim 7, characterized in that, When there are multiple transferable tasks, for each transferable task, the fit difference between different decoding units and the video stream is calculated, and the transferable task with the smallest difference is selected to migrate to the second decoding unit.

9. The multi-channel video decoding dynamic scheduling method according to claim 3, characterized in that, In the video parameter monitoring, the host sends media description requests to each network camera device at a fixed period to parse and obtain the resolution, frame rate, and encoding format parameters in the video stream parameter packet; When the resolution or frame rate change ratio of a certain video stream is detected to exceed the corresponding preset change threshold, the service constraint vector of that video stream is regenerated, and the video decoding task of that stream is rescheduled based on the hierarchical scheduling strategy.

10. The multi-channel video decoding dynamic scheduling method according to claim 3, characterized in that, The monitoring objects of the system fault monitoring include the bidirectional control communication link, each decoding channel of the second decoding unit, the video transmission channel of each network camera device, and the first decoding unit; For different fault types, corresponding judgment conditions are set. After the fault is judged, the affected video decoding tasks are redistributed to normal decoding units according to the fault self-healing rules, and fault alarm information is output synchronously.

Images