A video algorithm task scheduling and processing method and system based on Redis multi-queue cooperation

Abstract

A video algorithm task scheduling and processing method and system based on Redis multi-queue cooperation are disclosed, which comprises establishing a task scheduling queue, a real-time frame transmission queue and an event chain queue on a Redis server side; a task start-stop service listens to the task scheduling queue, parses task instructions and starts a corresponding first-level algorithm process; the first-level algorithm process decodes a target video stream and analyzes a first frame to generate a first analysis result; frame-by-frame pictures of the video stream are compressed, and the compressed frame data is pushed into the real-time frame transmission queue; a downstream algorithm process subscribes to the real-time frame transmission queue, directly acquires and decompresses the frame data for secondary analysis; the twice analysis results are written into the event chain queue through structured data containing a context identifier, and the context identifier is used to logically associate the analysis results of different algorithm processes for the same video target. The application can significantly improve the task scheduling flexibility and the data transmission efficiency in the video data analysis process.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, and in particular to a method and system for scheduling and processing video algorithm tasks based on Redis multi-queue collaboration. Background Technology

[0002] With the rapid development of fields such as smart security and industrial quality inspection, the demand for real-time intelligent analysis of massive video streams is increasing. Existing video analysis systems typically need to run multiple algorithm models simultaneously, such as object detection, behavior recognition, and trajectory tracking. How to efficiently schedule these algorithm tasks and realize the flow of data between different algorithm services is the main challenge currently facing the technology.

[0003] Existing technologies have the following main shortcomings when dealing with such problems: The limitations of traditional HTTP synchronous calls: Currently, many video analytics platforms use direct HTTP interface calls between services for synchronous communication. In high-concurrency scenarios, this tightly coupled architecture is prone to task backlog. If a certain algorithm service responds slowly, it can trigger a chain reaction, causing the overall system latency to spike, failing to meet the stringent real-time requirements of video surveillance.

[0004] While introducing message queues like Kafka or RabbitMQ can achieve asynchronous decoupling, these components typically rely on independent cluster operations (such as ZooKeeper), resulting in high deployment and maintenance costs. More importantly, these message queues are primarily designed for text or lightweight commands, while the single-frame data generated during video analytics is large (up to hundreds of KB). Directly using traditional message queues to transmit large numbers of video frames can easily lead to network congestion and disk storage pressure, resulting in a decrease in system throughput.

[0005] Inefficient cross-algorithm collaboration and context loss are common problems in complex video analysis scenarios, often requiring multiple algorithms to process data sequentially (e.g., detecting a "person" and then analyzing "behavior" based on that result). Existing technologies typically rely on databases as intermediaries to transfer intermediate results between different algorithms. This approach not only increases the I / O read / write pressure on the database but also easily leads to the loss of contextual information between upstream and downstream algorithms, causing processing chain breaks and making it difficult to form a logically tight chain of early warning events.

[0006] The wasted computing power caused by repeated video decoding: In traditional architectures where multiple algorithms analyze the same video stream, each algorithm process typically needs to independently pull the video stream and decode it. This means that the same frame will be decoded multiple times, consuming a large amount of CPU computing power and severely limiting the number of video streams that the server can analyze simultaneously. Summary of the Invention

[0007] To address the aforementioned technical problems in the existing technology, this invention proposes a video algorithm task scheduling and processing method and system based on Redis multi-queue collaboration, in order to solve the above-mentioned technical problems.

[0008] According to a first aspect of the present invention, a video algorithm task scheduling and processing method based on Redis multi-queue collaboration is proposed, comprising: S1: Establish a task scheduling queue, a real-time frame transmission queue, and an event chain queue on the Redis server; S2: The task start / stop service listens to the task scheduling queue, parses task instructions, and starts the corresponding first-level algorithm process; S3: The first-level algorithm process decodes the target video stream and analyzes the first frame to generate the first analysis result; at the same time, it compresses the frame-by-frame images of the video stream and pushes the compressed frame data to the real-time frame transmission queue through the Publish / Subscribe mode; S4: The downstream algorithm process subscribes to the real-time frame transmission queue, directly obtains and decompresses the frame data for secondary analysis; S5: Write the first analysis result and the second analysis result into the event chain queue through structured data containing context identifiers, and use the context identifiers to logically associate the analysis results of different algorithm processes for the same video target.

[0009] In some specific embodiments, in S1, the task scheduling queue adopts a List or Sorted Set structure to store task instructions in JSON format; the real-time frame transmission queue adopts a Pub / Sub mode or List structure to store high-throughput binary image data transmission; and the event chain queue adopts a Sorted Set structure, using timestamps or event priorities as scores, to store structured early warning event data.

[0010] In some specific embodiments, S2 also includes: introducing a priority field into the task scheduling queue, using the Score value of the Redis Sorted Set to mark the urgency of the task, where a high Score corresponds to an urgent task and a low Score corresponds to a normal task; the task start / stop service prioritizes the task instructions with high Scores for processing during polling.

[0011] In some specific embodiments, the compression processing of the video stream in the first-level algorithm process in S3 specifically includes: compressing the original decoded frame into JPEG format with a compression ratio of 70%-80%; determining whether the volume of the compressed frame data exceeds a preset threshold; if it exceeds the threshold, dividing the frame data into multiple fixed-size data blocks and pushing them in parallel to the real-time frame transmission queue, where downstream algorithm processes reassemble them upon acquisition.

[0012] In some specific embodiments, the downstream algorithm process that generates the second analysis result in S4 does not perform video stream fetching and decoding operations during the analysis process.

[0013] In some specific embodiments, the context identifier-based association analysis in S5 specifically includes: the first-level algorithm process acts as a target detection node, outputting metadata containing the target coordinate box, classification confidence, and the generated first context identifier; the second-level algorithm process acts as a behavior analysis node, obtains the first analysis result by subscribing to the event chain queue, extracts the coordinate information of the corresponding target using the same context identifier, and performs secondary behavior logic calculation by combining the current frame image obtained from the real-time frame transmission queue; after the calculation is completed, the behavior analysis result is written into the data structure corresponding to the original context identifier in an incremental update manner to form a complete event chain.

[0014] In some specific embodiments, memory optimization and breakpoint resumption mechanisms for the Redis server are also included: setting the Redis maxmemory parameter to 70% of the system's physical memory and enabling the volatile-lru memory eviction policy; assigning a globally unique Snowflake ID to each message pushed to the queue; storing the corresponding Snowflake ID in a Redis Set after the consumer successfully processes the message; and skipping processed messages by comparing the IDs in the Set when the service crashes and restarts, to prevent the task from being executed repeatedly.

[0015] According to a second aspect of the invention, a computer-readable storage medium is provided on which one or more computer programs are stored, which, when executed by a computer processor, implement the method described above.

[0016] According to a third aspect of the present invention, a video algorithm task scheduling and processing system based on Redis multi-queue collaboration is proposed, comprising: Redis server: Configure to establish task scheduling queue, real-time frame transmission queue and event chain queue; The task start / stop service module is configured to listen to the task scheduling queue, parse task instructions, and start the corresponding first-level algorithm process. The first-level algorithm processing module is configured to decode the target video stream and analyze the first frame to generate the first analysis result; at the same time, it compresses the video stream frame by frame and pushes the compressed frame data to the real-time frame transmission queue through the Publish / Subscribe mode. The downstream algorithm processing module is configured to subscribe to the real-time frame transmission queue, directly obtain and decompress frame data for secondary analysis. The event chain management module is configured to write the first and second analysis results into the event chain queue using structured data containing context identifiers, and to logically associate the analysis results of different algorithm processes for the same video target using context identifiers.

[0017] In some specific embodiments, when the first-level algorithm processing module pushes the compressed frame data to the real-time frame transmission queue, it adds a frame sequence number and timestamp information to each frame data. When the event chain management module writes the first analysis result and the second analysis result, it writes the corresponding frame sequence number and timestamp as a frame consistency identifier into the structured data containing the context identifier. When each downstream algorithm processing module subscribes to and processes the data in the real-time frame transmission queue and the event chain queue, it performs a matching and verification of the frame data and analysis results based on the frame consistency identifier. It only performs analysis and result updates when the frame sequence number and timestamp are consistent, thereby ensuring that the analysis of the same video target by multiple algorithm processing modules is based on the frame images at the same time.

[0018] Compared with the prior art, the present invention has the following main technical effects: This invention implements a "decode once, analyze multiple times" mechanism for video streams by constructing a frame transmission queue. Upstream tasks only need to decode once and push the compressed frame to Redis. Downstream, multiple different types of algorithm tasks (such as face recognition and behavior analysis) can directly consume the frame data in the queue for processing, without needing to repeatedly pull the stream and decode. Compared with traditional solutions, this mechanism can save 40% to 66% of CPU computing power, significantly reducing server load and allowing a single server to analyze more video streams simultaneously.

[0019] This invention introduces an event chain queue and a context identifier (ContextID), enabling the output of upstream algorithms (such as target coordinates) to be directly associated with the input of downstream algorithms (such as behavior determination). This design avoids the data processing link breakage and context information loss problems caused by relying on database transfers in traditional solutions, while reducing the performance loss caused by frequent database queries, and realizing lossless transmission and logical closed loop of early warning data.

[0020] This invention leverages Redis's in-memory storage capabilities and Pub / Sub mode to reduce task scheduling latency from the traditional 200-500ms of HTTP synchronous blocking to less than 10ms. Compared to message queues like Kafka that rely on disk I / O, this invention's in-memory broadcast mechanism reduces average latency by 92% (to only 1.2ms) and increases throughput by 167%. Combined with WebSocket technology, it achieves millisecond-level visualization of the analysis process, resolving the issue of high latency in the front-end display.

[0021] This invention directly reuses Redis as the data transmission platform, eliminating the need to deploy and maintain a separate ZooKeeper cluster like Kafka, thus reducing system deployment complexity. Compared to the Kafka solution, this invention optimizes memory usage by 75% (to only 50MB) and reduces bandwidth usage by 40%, making it more suitable for resource-sensitive industrial quality inspection or edge computing scenarios.

[0022] This invention employs a three-tiered queue architecture (task scheduling, event chain, and frame transmission) to achieve on-demand task distribution and decoupling. The task start / stop service supports concurrent management of hundreds of task instances, and can control the start or termination of task processes in real time by listening to topics, exhibiting extremely high scheduling flexibility and system stability. Attached Figure Description

[0023] The accompanying drawings are included to provide a further understanding of the embodiments and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments and, together with the description, serve to explain the principles of the invention. Other embodiments and many anticipated advantages of the embodiments will be readily recognized as they become better understood through reference to the following detailed description. Other features, objects, and advantages of this application will become more apparent from reading the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart of a video algorithm task scheduling and processing method based on Redis multi-queue collaboration, according to an embodiment of this application; Figure 2 This is a flowchart illustrating the cross-algorithm event ContextID transfer process according to a specific embodiment of this application; Figure 3 This is a diagram of three parallel queue architectures based on a specific embodiment of this application; Figure 4 This is a task data flow diagram of a specific embodiment of this application; Figure 5 This is a framework diagram of a video algorithm task scheduling and processing system based on Redis multi-queue collaboration, according to one embodiment of this application. Figure 6 This is a schematic diagram of the structure of a computer system used to implement the electronic device of the present application. Detailed Implementation

[0024] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0025] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0026] Figure 1 A flowchart illustrating a video algorithm task scheduling and processing method based on Redis multi-queue collaboration, according to an embodiment of this application, is shown. Figure 1 As shown, the method includes the following steps: S1: Establish a task scheduling queue, a real-time frame transmission queue, and an event chain queue on the Redis server.

[0027] In specific embodiments, the task scheduling queue adopts a List or Sorted Set structure to store task instructions in JSON format. Using a List or Sorted Set ensures that task instructions are ordered first-in, first-out or sorted on demand, guaranteeing the orderliness of scheduling. The real-time frame transmission queue adopts a Pub / Sub mode or a List structure for high-throughput binary image data transmission. For frame data transmission, the Pub / Sub mode implements a "publish once, subscribe to multiple devices" broadcast mechanism, significantly improving data distribution throughput compared to the point-to-point transmission of traditional queues. The event chain queue adopts a Sorted Set structure, using timestamps or event priorities as scores, to store structured early warning event data. For event chains, the Sorted Set leverages its sorting properties to efficiently manage the timeline and priority of events, facilitating rapid retrieval and association by downstream services.

[0028] S2: The task start / stop service listens to the task scheduling queue, parses task instructions, and starts the corresponding first-level algorithm process.

[0029] In a specific implementation, a priority field is introduced into the task scheduling queue, using Redis Sorted Set scores to mark the urgency of tasks. High scores correspond to urgent tasks, while low scores correspond to ordinary tasks. The task start / stop service prioritizes processing tasks with high scores during polling. With limited computing resources, by introducing a priority field and using Redis Sorted Set scores, the system can distinguish between "urgent tasks" and "ordinary tasks." This ensures that high-priority security alert tasks are processed first, preventing missed or delayed reporting of critical security events due to a backlog of ordinary tasks, and significantly improving the system's response speed to sudden security incidents.

[0030] S3: The first-level algorithm process decodes the target video stream and analyzes the first frame to generate the first analysis result; at the same time, it compresses the video stream frame by frame and pushes the compressed frame data to the real-time frame transmission queue through the Publish / Subscribe mode.

[0031] In a specific embodiment, the first-level algorithm process for compressing the video stream includes: compressing the original decoded frame into JPEG format with a compression ratio of 70%-80%; determining whether the compressed frame data volume exceeds a preset threshold; if it exceeds the threshold, dividing the frame data into multiple fixed-size data blocks and pushing them in parallel to the real-time frame transmission queue, where downstream algorithm processes reassemble them upon retrieval. Redis is a single-threaded model, and large-volume value reads and writes can block the entire service. This invention avoids long-term Redis blocking caused by "BigKey" by dividing video frames into fixed-size (e.g., 64KB) data blocks, ensuring system response speed under high concurrency. Combined with JPEG / HEVC compression technology, the amount of data transmitted over the network is significantly reduced. Compared to directly transmitting the original frame or using Kafka, bandwidth usage is reduced by approximately 40%, making it possible to transmit high-definition video frames in limited network environments.

[0032] S4: The downstream algorithm process subscribes to the real-time frame transmission queue, directly obtains and decompresses the frame data for secondary analysis.

[0033] In a specific embodiment, the downstream algorithm process generating the second analysis result does not perform video stream fetching and decoding operations during the analysis process. This is the core energy-saving effect of the present invention. By directly reusing the upstream already decoded and compressed frame data, the downstream algorithm process (such as behavior analysis) does not need to perform the energy-intensive "stream fetching" and "decoding" operations again. Experimental data shows that this mechanism can save approximately 40%-66% of CPU computing resources, which means that under the same hardware configuration, this system can support real-time analysis tasks from more cameras.

[0034] S5: Write the first analysis result and the second analysis result into the event chain queue through structured data containing context identifiers, and use the context identifiers to logically associate the analysis results of different algorithm processes for the same video target.

[0035] In a specific embodiment, the context identifier-based association analysis includes: a first-level algorithm process, acting as a target detection node, outputs metadata containing the target bounding box, classification confidence score, and the generated first context identifier; a second-level algorithm process, acting as a behavior analysis node, obtains the first analysis result by subscribing to an event chain queue, extracts the coordinate information of the corresponding target using the same context identifier, and performs secondary behavior logic calculations by combining the current frame obtained from the real-time frame transmission queue; after the calculation is completed, the behavior analysis result is written to the data structure corresponding to the original context identifier in an incremental update manner, forming a complete event chain. By using ContextID to connect the independently running target detection process and behavior analysis process, downstream algorithms can directly inherit the metadata (such as bounding boxes) generated by the upstream algorithm, achieving "zero-loss" context transfer across processes. This avoids the huge IO pressure and latency caused by the traditional "upstream writes to the database - downstream polls the database" approach, achieving pure memory-level pipelined processing and greatly improving the real-time performance of complex event analysis. The incremental update method for writing results ensures that the entire process data from event discovery to final confirmation is completely recorded in the same structured object, facilitating subsequent evidence preservation and backtracking.

[0036] In specific embodiments, the system also includes memory optimization and breakpoint resumption mechanisms for the Redis server: The Redis `maxmemory` parameter is set to 70% of the system's physical memory, and a volatile-lru memory eviction policy is enabled. By setting `maxmemory` (70%) and enabling the volatile-lru eviction policy, a "safety airbag" for memory usage is established to prevent service crashes caused by Redis memory overflow (OOM) due to video data backlog. Each message pushed to the queue is assigned a globally unique Snowflake ID. After successfully processing a message, the consumer stores the corresponding Snowflake ID in a Redis Set. When the service crashes and restarts, processed messages are skipped by comparing the IDs in the Set to prevent duplicate task execution. The introduction of globally unique Snowflake IDs and deduplication Sets solves the common message loss or duplicate consumption problems in distributed environments. Even if the service crashes and restarts, processed messages can be skipped or unfinished messages can be reprocessed by comparing IDs, achieving accuracy and reliability in task processing.

[0037] Figure 2 This is a flowchart illustrating the cross-algorithm event ContextID passing process according to a specific embodiment of this application, as follows: Figure 2 As shown, the specific process includes: An external system issues a "start" command, and the "receive task" service (i.e., the HTTP interface script) receives a task request in JSON format (containing task ID, video address, algorithm type, etc.). After parsing the request, the receiving service writes the "JSON task data" unidirectionally into the Redis task scheduling queue, completing the command distribution. "Process service 1" (task start / stop service) listens for task commands in Redis and starts the corresponding "algorithm service 1" (e.g., object detection algorithm). Algorithm service 1 retrieves task details from Redis. After decoding the stream, algorithm service 1 compresses the video footage (JPEG) to form "real-time frame data" and pushes it back to the Redis frame transmission queue. Algorithm service 1 detects video frames (e.g., detects a "face") and generates metadata containing target coordinates, classification confidence, and a unique context identifier (ContextID). This data is written to the Redis event queue as "multi-level warning data" (i.e., event chain data). Algorithm service N (e.g., behavior analysis), as a downstream task, subscribes to the event chain queue in Redis. After reading the warning data generated by service 1, service N uses the ContextID to identify the context information of the same target. Meanwhile, service N directly reads "real-time frame data" (compressed frames) from Redis and performs secondary analysis (such as behavior judgment) using the coordinate information provided by the ContextID, without needing to re-pull and decode the stream. After completing the analysis, service N writes the new analysis results to Redis in an incremental update manner, completing the event chain under that ContextID. The "WebSocket" service subscribes to the "real-time frame data" in Redis and pushes the algorithm-processed and labeled images directly to the "web playback" end, achieving millisecond-level visual monitoring. Finally, the "persistence service" consumes the final "warning image data" and the complete event chain results, saving them to disk or object storage, completing the task loop.

[0038] Figure 3 This is a diagram of three parallel queue architectures based on a specific embodiment of this application, such as... Figure 3 As shown, this architecture achieves decoupled transmission of signaling, event data, and video stream data through three independent horizontal channels, specifically including: The first layer: Redis task scheduling layer (top layer). Responsible for receiving, distributing, and consuming task instructions, thus decoupling business logic. Its processing flow is as follows: HTTP Task Receiving Layer: The "Receive External Tasks" module on the left receives JSON-formatted task requests from third parties via an HTTP interface.

[0039] Enqueue operation (LPUSH): The receiving layer pushes the parsed task instructions to the intermediate Redis task scheduling layer using the Redis LPUSH command. Here, a Redis List data structure is used, as shown in the diagram as task_queue.

[0040] Dequeue Consumption (RPOP): The "Algorithm Execution Unit Set" on the right (which includes processes such as face detection and behavior analysis) acts as a consumer, obtaining task instructions from the task_queue through the RPOP command, thereby starting the corresponding analysis process.

[0041] The second layer: Redis event coordination layer (middle layer). Responsible for storing structured alert data, transmitting it across algorithms, and persisting it, implementing contextual relationships. Its processing flow is as follows: Cross-algorithm event propagation: After the analysis is completed, the "Algorithm Execution Unit Set" on the right generates a structured result containing a context identifier (ContextID).

[0042] Data coordination: These results are written to the intermediate Redis event coordination layer, namely the alert_queue shown in the diagram. This queue typically uses a SortedSet structure to manage the chained event data generated by multi-level algorithms in an ordered manner.

[0043] Persistence: The "Alert Event Persistence" module (storage service) on the left reads the final analysis results from alert_queue and saves them to the database or file system, completing the data persistence.

[0044] The third layer: Redis real-time frame transmission layer (bottom layer). Responsible for compressing and real-time broadcasting of high-bandwidth video stream data, enabling decoding-free multiplexing and visualization. Its processing flow is as follows: Frame Compression and Publishing: After the "Algorithm Execution Unit Set" on the right performs pull decoding on the video stream, it compresses each frame into JPEG or HEVC format. Subsequently, through Redis's Pub / Sub mode, the compressed frame is "published" to the middle Redis real-time frame transmission channel, i.e., frame_channel marked in the figure.

[0045] Subscription Push: The "WebSocket Service" on the left subscribes to this frame_channel, and as soon as a new compressed frame is published, it is immediately pushed to the front-end page. This layer realizes "decoding once, multiplexing across multiple devices" of video data, significantly reducing transmission latency and bandwidth consumption.

[0046] Figure 4 This is a task data flow diagram of a specific embodiment of this application, such as... Figure 4As shown, this data flow includes the following stages: 410. Data Input. The process begins with a call to an external system. The system receives data input through a pre-defined Python script interface, namely a JSON-formatted task request sent by a third party (containing task ID, camera address, algorithm type, etc.).

[0047] 420. HTTP Receive Task Information. Parse the task request and write the standardized task instructions into the Redis task scheduling queue using the LPUSH command.

[0048] 430. Task Start / Stop Service Consumes Tasks. The background Node.js task start / stop service listens to specific topics and consumes instructions from the Redis queue. This step is responsible for parsing task parameters and calling system commands to start or stop the corresponding algorithm process based on the instructions.

[0049] 440. Algorithm obtains task information. The launched Python algorithm process (as the first-level task, such as face detection) establishes a connection with Redis, obtains the specific video stream address and detection parameters, and begins pulling the stream and decoding the video.

[0050] 450. Data Push Analysis. After decoding and analyzing the first frame of the video stream, the algorithm divides the generated data into two categories and pushes them to different queues in Redis to prepare for subsequent parallel processing.

[0051] 461. Analyze the results data. The algorithm extracts structured information (such as target bounding box, classification confidence, and ContextID) as metadata and writes it into the Redis event chain queue (SortedSet).

[0052] 462. Frame Data Push. The algorithm compresses the decoded video footage into JPEG format and pushes it to Redis's real-time frame transmission queue via Pub / Sub mode. This step ensures that downstream tasks do not need to consume CPU resources for video decoding again.

[0053] 470. Next-level algorithm task analysis. After the downstream algorithm process (such as behavior analysis) starts, it simultaneously obtains input from the two sources above: context information (ContextID) from 461 to know which target to analyze; and compressed real-time frames from 462 for direct image computation. This step realizes pipelined operation with cross-algorithm context association and no-repetition decoding.

[0054] 481. Storage Services. The task analysis result persistence service subscribes to the final event queue and saves the complete analysis record (JSON) and snapshot images to object storage (such as MinIO) or a database to achieve evidence retention.

[0055] 482. Video Playback Service. The front-end WebSocket service subscribes to the Redis frame transmission channel, obtains the processed real-time video, and performs low-latency rendering on the web page to achieve visual monitoring.

[0056] In a specific embodiment, the data processing method of this application is as follows: Step 01: Deploy Redis service in the server cluster as the data transmission framework. This includes installing Redis version 6.0, configuring a master-slave replication architecture for high availability, and enabling RDB snapshots and AOF log persistence mechanisms to ensure data recovery in case of task interruption. Simultaneously, set the maxmemory parameter to 70% of system memory and adopt a volatile-lru strategy to optimize memory management to meet the demands of high-concurrency video data processing.

[0057] Step 02: Write the algorithm task data receiving interface script using Python and the redis-py library to implement a RESTful API interface for receiving third-party JSON format task requests. After parsing the task information, the script pushes the data to different Redis queues (e.g., "task_schedule_queue") based on the task category (e.g., object detection or behavior analysis), thus achieving dynamic distribution of task instructions.

[0058] Example: Algorithm task JSON data structure {"task_id": "T001", "camera_id": "C01", "algorithms": ["face_detect", "behavior_analysis"]}.

[0059] Step 03: The task start / stop service is developed based on Node.js and listens for task commands by subscribing to the "task_control" topic. This service maintains a process mapping table, parses task IDs, video stream addresses, and target classification parameters in real time, and calls system commands to start or terminate the corresponding Python algorithm process, supporting the concurrent management of hundreds of task instances.

[0060] Step 04: After the algorithm task process starts, the video stream address is pulled in real time using the FFmpeg tool. After decoding the first frame, the object detection algorithm (such as the YOLOv5 model) is triggered. The detection results include object coordinates and classification information. At the same time, the video stream metadata is written to a Redis queue to ensure low-latency processing.

[0061] Step 05: The running algorithm task performs JPEG compression on the video frames (compression ratio set to 70%) and pushes the frame data to the "frame_transfer_queue" via the LPUSH command. Downstream algorithm tasks directly consume this queue, avoiding repeated decoding, saving up to 40% of CPU computing power, and improving the throughput of multi-channel video analysis.

[0062] Step 06: The target snapshot (such as captured image) generated by the algorithm task is stored on the local SSD disk. At the same time, the detection results in JSON format (including timestamp, target ID and confidence level) are integrated with the task metadata and broadcast to "event_chain_queue" via PUBLISH command to realize the context transmission of the early warning event.

[0063] Step 07: Downstream algorithm tasks subscribe to "event_chain_queue", consume upstream results, and perform secondary calculations (such as behavior recognition or trajectory tracking). The calculation results are incrementally updated to update the original task's JSON data and written to a new queue via the RPUSH command, forming a pipeline-like processing chain to ensure data continuity.

[0064] Step 08: The task result persistence service consumes "final_result_topic" to obtain the integrated task data. This service calls the MinIO object storage interface to save the image and pushes the JSON result to the third-party detection platform via HTTP callback, completing the task loop.

[0065] Step 09: The video playback service subscribes to the last-level queue based on the task ID, obtains the compressed frame stream, and then transmits it to the front-end webpage in real time via WebSocket. The libwebsocket library is used to achieve millisecond-level latency rendering, supporting user-visualized monitoring and analysis of the process, thus improving task management efficiency.

[0066] In one specific embodiment, Table 1 shows a macro-level comparison of the proposed Redis multi-queue scheme and the traditional HTTP+Kafka scheme at the system architecture level.

[0067] ; As shown in Table 1, this invention achieves significant optimization in task scheduling latency, reducing the traditional 200-500 milliseconds to less than 10 milliseconds; in terms of cross-algorithm transmission, it uses ContextID chain association to replace database transfer, achieving zero context loss; at the same time, it replaces Kafka's disk I / O mode with a memory broadcast mechanism, reducing the cost of transmitting tens of thousands of frames and reducing bandwidth usage by 40%, and in terms of system scalability, it does not require independent deployment of MQ clusters, directly reusing Redis infrastructure, reducing operational complexity.

[0068] Table 2 shows the performance comparison data of Redis and Kafka as algorithm message bus components.

[0069] ; Experimental results show that Redis achieves a 92% reduction in average latency (1.2ms) and a 167% increase in throughput (120,000 messages / second) compared to Kafka, making it more suitable for high-frequency message processing. Furthermore, Redis demonstrates superior resource consumption, reducing CPU and memory usage by 66% and 75% respectively, while also exhibiting lower deployment complexity and a message loss rate of only 0.01%, proving its significant advantages in lightweight design, high reliability, and low cost.

[0070] This application proposes a video algorithm task scheduling and processing method and system based on Redis multi-queue collaboration, constructing a three-level queue mechanism including task scheduling, event chain collaboration, and real-time frame transmission. The system successfully achieves a pipelined operation of "one-time decoding, multi-level reuse" by broadcasting compressed video frames using Redis Pub / Sub mode and introducing ContextID for cross-algorithm logical association. This solution effectively solves the technical pain points of high latency in traditional HTTP synchronous calls and context loss caused by database transfers. While significantly reducing CPU computing power consumption (approximately 40%-66%), it achieves millisecond-level real-time visualization monitoring and high-throughput distributed collaborative processing.

[0071] Figure 5 This application illustrates a framework diagram of a Redis multi-queue collaborative video algorithm task scheduling and processing system according to an embodiment of this application, as shown below. Figure 5As shown, the system mainly includes a Redis server 501, a task start / stop service module 502, a first-level algorithm processing module 503, a downstream algorithm processing module 504, and an event chain management module 505. The Redis server 501 is configured to establish a task scheduling queue, a real-time frame transmission queue, and an event chain queue. The task start / stop service module 502 is configured to listen to the task scheduling queue, parse task instructions, and start the corresponding first-level algorithm process. The first-level algorithm processing module 503 is configured to decode the target video stream and perform first-frame analysis, generating a first analysis result. Simultaneously, it compresses each frame of the video stream and pushes the compressed frame data to the real-time frame transmission queue using a Publish / Subscribe mode. The downstream algorithm processing module 504 is configured to subscribe to the real-time frame transmission queue, directly obtain and decompress the frame data for secondary analysis. The event chain management module 505 is configured to write the first and second analysis results into the event chain queue using structured data containing context identifiers, and logically associate the analysis results of different algorithm processes for the same video target using these context identifiers.

[0072] The following is for reference. Figure 6 It shows a schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application. Figure 6 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0073] like Figure 6 As shown, the computer system includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 602 or programs loaded from storage section 608 into random access memory (RAM) 603. The RAM 603 also stores various programs and data required for the operation of the system 600. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0074] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a liquid crystal display (LCD) and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card and a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0075] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable storage medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined in the methods of this application. It should be noted that the computer-readable storage medium of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. The computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium may also be any computer-readable storage medium other than a computer-readable storage medium that can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0076] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages—such as Java, Smalltalk, and C++—as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0077] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0078] The modules described in the embodiments of this application can be implemented in software or in hardware.

[0079] In another aspect, this application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the electronic device, the electronic device causes the following: a task scheduling queue, a real-time frame transmission queue, and an event chain queue are established on the Redis server; the task start / stop service listens to the task scheduling queue, parses task instructions, and starts the corresponding first-level algorithm process; the first-level algorithm process decodes the target video stream and performs first-frame analysis, generating a first analysis result; simultaneously, it compresses each frame of the video stream and pushes the compressed frame data to the real-time frame transmission queue using a Publish / Subscribe mode; downstream algorithm processes subscribe to the real-time frame transmission queue, directly obtain and decompress the frame data for secondary analysis; and the first analysis result and the second analysis result are written to the event chain queue using structured data containing context identifiers, using the context identifiers to logically associate the analysis results of different algorithm processes for the same video target.

[0080] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A video algorithm task scheduling and processing method based on Redis multi-queue collaboration, characterized in that, include: S1: Establish a task scheduling queue, a real-time frame transmission queue, and an event chain queue on the Redis server; S2: The task start / stop service listens to the task scheduling queue, parses task instructions, and starts the corresponding first-level algorithm process; S3: The first-level algorithm process decodes the target video stream and analyzes the first frame to generate the first analysis result; at the same time, it compresses the frame-by-frame images of the video stream and pushes the compressed frame data to the real-time frame transmission queue through the Publish / Subscribe mode; S4: The downstream algorithm process subscribes to the real-time frame transmission queue, directly obtains and decompresses the frame data for secondary analysis; S5: Write the first analysis result and the second analysis result into the event chain queue through structured data containing context identifiers, and use the context identifiers to logically associate the analysis results of different algorithm processes for the same video target.

2. The video algorithm task scheduling and processing method based on Redis multi-queue collaboration according to claim 1, characterized in that, In step S1, the task scheduling queue adopts a List or SortedSet structure to store task instructions in JSON format; the real-time frame transmission queue adopts a Pub / Sub mode or a List structure to transmit high-throughput binary image data; and the event chain queue adopts a SortedSet structure, using timestamps or event priorities as scores, to store structured early warning event data.

3. The video algorithm task scheduling and processing method based on Redis multi-queue collaboration according to claim 1, characterized in that, S2 further includes: introducing a priority field into the task scheduling queue, using the Score value of RedisSortedSet to mark the urgency of tasks, where a high Score corresponds to an urgent task and a low Score corresponds to a normal task; the task start / stop service prioritizes the task instructions with the high Score for processing during polling.

4. The video algorithm task scheduling and processing method based on Redis multi-queue collaboration according to claim 1, characterized in that, The compression processing of the video stream in the first-level algorithm process in S3 specifically includes: compressing the original decoded frame into JPEG format with a compression ratio of 70%-80%; determining whether the volume of the compressed frame data exceeds a preset threshold; if it exceeds the threshold, dividing the frame data into multiple fixed-size data blocks and pushing them in parallel to the real-time frame transmission queue, where downstream algorithm processes reassemble them upon acquisition.

5. The video algorithm task scheduling and processing method based on Redis multi-queue collaboration according to claim 1, characterized in that, In S4, the downstream algorithm process that generates the second analysis result does not perform video stream fetching and decoding operations during the analysis process.

6. The video algorithm task scheduling and processing method based on Redis multi-queue collaboration according to claim 1, characterized in that, The context identifier-based association analysis in S5 specifically includes: the first-level algorithm process acts as a target detection node, outputting metadata including the target coordinate box, classification confidence, and the generated first context identifier; the second-level algorithm process acts as a behavior analysis node, obtains the first analysis result by subscribing to the event chain queue, extracts the coordinate information of the corresponding target using the same context identifier, and performs secondary behavior logic calculation by combining the current frame obtained from the real-time frame transmission queue; after the calculation is completed, the behavior analysis result is written into the data structure corresponding to the original context identifier in an incremental update manner to form a complete event chain.

7. The video algorithm task scheduling and processing method based on Redis multi-queue collaboration according to claim 1, characterized in that, It also includes memory optimization and breakpoint resume mechanism for Redis server: set Redis maxmemory parameter to 70% of system physical memory and enable volatile-lru memory eviction policy; Each message pushed to the queue is assigned a globally unique SnowflakeID; after successfully processing the message, the consumer stores the corresponding SnowflakeID in a RedisSet collection. When the service crashes and restarts, processed messages are skipped by comparing the IDs in the Set collection to prevent tasks from being executed repeatedly.

8. A computer-readable storage medium having one or more computer programs stored thereon, characterized in that, When the one or more computer programs are executed by a computer processor, they perform the method according to any one of claims 1-7.

9. A video algorithm task scheduling and processing system based on Redis multi-queue collaboration, characterized in that, include: Redis server: Configure to establish task scheduling queue, real-time frame transmission queue and event chain queue; The task start / stop service module is configured to listen to the task scheduling queue, parse task instructions, and start the corresponding first-level algorithm process. The first-level algorithm processing module is configured to decode the target video stream and analyze the first frame to generate the first analysis result; at the same time, it compresses the frame-by-frame images of the video stream and pushes the compressed frame data to the real-time frame transmission queue through the Publish / Subscribe mode. The downstream algorithm processing module is configured to subscribe to the real-time frame transmission queue, directly acquire and decompress frame data for secondary analysis. The event chain management module is configured to write the first analysis result and the second analysis result into the event chain queue through structured data containing context identifiers, and to logically associate the analysis results of different algorithm processes for the same video target using context identifiers.

10. A video algorithm task scheduling and processing system based on Redis multi-queue collaboration according to claim 9, characterized in that, When the first-level algorithm processing module pushes the compressed frame data to the real-time frame transmission queue, it adds a frame sequence number and timestamp information to each frame data; when the event chain management module writes the first analysis result and the second analysis result, it writes the corresponding frame sequence number and timestamp as a frame consistency identifier into the structured data containing the context identifier. When each downstream algorithm processing module subscribes to and processes the data in the real-time frame transmission queue and event chain queue, it performs matching and verification between the frame data and the analysis results based on the frame consistency identifier. It only performs analysis and result updates when the frame sequence number and timestamp are consistent, thereby ensuring that the analysis of the same video target by multiple algorithm processing modules is based on the frame images at the same time.

Images