A web-based video monitoring distributed decoding method and system

Abstract

This invention discloses a distributed decoding method and system for web-based video surveillance, belonging to the field of network video playback technology. The method includes: the browser actively initiating a WebSocket connection via a local loopback address port (127.0.0.1:19022) to detect whether the user terminal has installed a distributed decoding program; the distributed decoding program calls the local FFmpeg library, utilizes the terminal CPU to perform real-time decoding of the video stream, and uses OpenCV to convert the decoded video keyframes frame by frame into an image format natively supported by the browser; the distributed decoding program encapsulates the binary data and address identifier of each frame into a WebSocket message and actively pushes it to the browser, which then refreshes and displays the image in real-time in a designated area of ​​the page based on the address identifier; this invention achieves zero-plugin, low-latency, cross-platform, and secure web-based video decoding, significantly reducing server load and network latency, and improving user experience and system compatibility.

Description

Technical Field

[0001] This invention relates to the field of network video playback technology, and in particular to a distributed decoding method and system for web-based video surveillance. Background Technology

[0002] With the rapid growth in demand for cloud-based and web-based video surveillance, traditional solutions have revealed the following shortcomings:

[0003] Centralized transcoding on servers: As concurrency increases, CPU and bandwidth costs increase exponentially, and secondary forwarding causes latency to be generally 5–15 seconds.

[0004] Browser plugin solution: Chrome, Edge, Firefox and other browsers have completely disabled NPAPI / ActiveX, so plugins cannot run and have poor system compatibility;

[0005] WebAssembly software decoding: Although there are no plugins, the browser version is limited, hardware acceleration cannot be called in the sandbox, and the terminal lag is severe when multiple concurrent connections are made.

[0006] Uncontrolled access after local decoding: Once the terminal obtains the raw bitstream, it can save it offline, posing a risk of leakage.

[0007] The process lifecycle is tightly coupled with the page state, and repeatedly pulling the stream and decoding after closing the tab wastes resources.

[0008] Therefore, how to complete multi-channel monitoring decoding on the web in a "zero-plugin, low-latency, cross-platform, secure and controllable" manner has become a pain point in the industry. Summary of the Invention

[0009] The purpose of this invention is to provide a distributed decoding method and system for web-based video surveillance, thereby solving the aforementioned problems existing in the prior art.

[0010] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0011] A distributed decoding method for web-based video surveillance, comprising:

[0012] a) The browser initiates a WebSocket connection via the local loopback address port to check whether the distributed decoding program has been installed on the user terminal;

[0013] b) If the distributed decoding program does not return the agreed handshake message "nvr wsopen" within the first preset time, it is determined that the program is not installed, and the browser will guide the user to download and install the distributed decoding program.

[0014] c) If a handshake message is received, the browser will send the Uniform Resource Locator (URL) of the video stream to be played to the distributed decoding program through the same WebSocket channel;

[0015] d) The distributed decoding program calls the local FFmpeg library, uses the terminal CPU to decode the video stream in real time, and uses OpenCV to convert the decoded video keyframes frame by frame into an image format natively supported by the browser.

[0016] e) The distributed decoding program encapsulates the binary data of each frame of image and its address identifier into a WebSocket message and actively pushes it to the browser. The browser then refreshes and displays the image in a specified area of ​​the page in real time based on the address identifier.

[0017] f) When the browser closes the monitoring page or the WebSocket is disconnected, the distributed decoding program maintains the decoding state of the video stream for a second preset time. If no pull request for the same video stream URL is received again within this time, the decoding will automatically terminate and the local computing resources will be released.

[0018] Preferably, the distributed decoding program and the browser communicate via a single WebSocket channel to transmit signaling, control, and image data, without the need to install browser plugins or ActiveX controls.

[0019] The image format is JPEG, and each frame is encapsulated in the WebSocket message body as a base64 string or ArrayBuffer, which is then rendered directly by the browser using an HTML5Canvas or Image object.

[0020] The first preset time is 3000ms; the second preset time is 60s.

[0021] After startup, the distributed decoding program listens to the local loopback address port and automatically creates a streaming thread upon receiving any video stream URL. The number of threads is dynamically correlated with the number of local CPU cores to prevent terminal lag.

[0022] Preferably, the browser sends the user's identity information and session token along with the video stream URL. The distributed decoding program performs a second verification of the token with the video management server before pulling the stream. Only after the verification is successful will the stream be pulled to ensure the consistency of video source permissions.

[0023] Preferably, when multiple browser tabs on the same terminal are playing different video streams simultaneously, the distributed decoding program only starts a single instance, decodes each video stream independently through internal multiplexing threads, and pushes image data to the corresponding tab according to different address identifiers, so as to reduce memory usage.

[0024] Preferably, the distributed decoding program is a cross-platform executable program that supports Windows, Linux, macOS and domestic operating systems. Its upgrade and uninstallation are triggered by the browser and completed by the terminal operating system-level daemon process, without the need for manual intervention by the user.

[0025] The distributed decoding program monitors the local CPU usage in real time during the decoding process. When the usage exceeds a set threshold, it automatically reduces the decoding frame rate or skips non-critical frames to ensure the smooth operation of the terminal system.

[0026] Preferably, the WebSocket messages between the browser and the distributed decoding program use a custom lightweight protocol. The protocol header includes a version number, message type, timestamp, and CRC32 checksum to protect against message tampering and replay attacks.

[0027] Based on the same concept, a web-based distributed video surveillance decoding system includes:

[0028] The browser module, deployed on the user terminal, is used to access the local loopback address port.

[0029] 127.0.0.1:19022 actively initiates a WebSocket connection and determines whether a distributed decoding module exists locally based on whether the agreed handshake message "nvrws open" is received; and if it exists, it sends the Uniform Resource Locator (URL) of the video stream to be played through the same WebSocket channel.

[0030] The distributed decoding module resides on the user terminal. After receiving the video stream's Uniform Resource Locator (URI), it calls the local FFmpeg library to decode the video stream in real time. It then uses OpenCV to convert the decoded keyframes frame by frame into an image format natively supported by the browser. Finally, it encapsulates the binary data and address identifier of each frame into a WebSocket message and actively pushes it to the browser module.

[0031] The video management server is used to provide raw video streams and permission verification services, but does not participate in video decoding or secondary transcoding.

[0032] When the WebSocket connection is disconnected, the distributed decoding module maintains the decoding state of the video stream for a preset keep-alive period. If no pull request for the same video stream Uniform Resource Locator is received again within this period, the decoding is automatically terminated and local computing resources are released.

[0033] Preferably, the browser module and the distributed decoding module complete signaling, control and image data transmission only through a single WebSocket channel, without the need to install browser plugins or ActiveX controls;

[0034] The distributed decoding module sets the image format to JPEG and encapsulates it in the WebSocket message body as a base64 string or ArrayBuffer; the browser module renders it directly using an HTML5Canvas or Image object.

[0035] The preset keep-alive timeout is 60 seconds; if the browser module does not receive a handshake message within 3000 milliseconds, it determines that the distributed decoding module does not exist and guides the user to download and install it.

[0036] Preferably, the distributed decoding module listens to the local loopback address port after startup, and automatically establishes a streaming thread after receiving any video stream Uniform Resource Locator. The number of threads is dynamically related to the number of local CPU cores to prevent terminal lag.

[0037] The browser module is also used to distribute user identity information and session tokens along with the video stream's Uniform Resource Locator (URL); the distributed decoding module performs secondary token verification with the video management server before pulling the stream, and only pulls the stream after successful verification to ensure the consistency of video source permissions.

[0038] When multiple browser tabs on the same terminal are playing different video streams simultaneously, the distributed decoding module only starts a single instance, uses internal multiplexed threads to decode each video stream independently, and pushes image data to the corresponding tab according to different address identifiers to reduce memory usage.

[0039] Preferably, the distributed decoding module is a cross-platform executable program that supports Windows, Linux, macOS and domestic operating systems. Its upgrade and uninstallation are triggered by the browser module and completed by the terminal operating system-level daemon process, without the need for manual user intervention.

[0040] The WebSocket messages between the browser module and the distributed decoding module use a custom lightweight protocol. The protocol header includes a version number, message type, timestamp, and CRC32 checksum to protect against message tampering and replay attacks.

[0041] The distributed decoding module monitors the local CPU utilization in real time during the decoding process. When the utilization exceeds the set threshold, it automatically reduces the decoding frame rate or skips non-critical frames to ensure the smooth operation of the terminal system.

[0042] The beneficial effects of this invention are:

[0043] Zero plugins, high compatibility: Decoding calculations are completely offloaded to an independent process on the terminal. The browser and the decoding module interact only through a local loopback WebSocket single channel, requiring no plugins or ActiveX controls to be installed. It is compatible with all versions of browsers and operating systems (Windows / Linux / macOS / domestic OS).

[0044] Low latency and resource saving: Images are directly pushed after local decoding, with a measured latency of less than 2 seconds; single instance multiplexing threads, with the number of threads dynamically related to the CPU cores, keeping the stream alive within 60 seconds of interruption, avoiding repeated streaming, and saving more than 40% of memory and bandwidth.

[0045] Secure and controllable: The system introduces a triple mechanism of session token secondary verification, custom protocol header CRC32 verification, and local loopback isolation to prevent offline streaming after URL interception and to resolve the copyright / privacy leakage risks caused by local decoding.

[0046] Cross-platform and easy to deploy: The distributed decoding module is a green executable program. Upgrades and uninstalls are triggered by the browser and completed by a system-level daemon process, so users are unaware of it, making it suitable for large-scale promotion.

[0047] Adaptive Smoothness: Real-time monitoring of local CPU utilization; if the threshold is exceeded, the frame rate is automatically reduced or non-critical frames are skipped to ensure smooth operation of the terminal and improve user experience.

[0048] Reduce server costs: The server only needs to provide the original bitstream and authentication, without participating in decoding and transcoding. With zero CPU usage, it can save more than 50% of server resources and significantly reduce operating costs. Attached Figure Description

[0049] Figure 1 This is a system architecture diagram of the present invention;

[0050] Figure 2 This is a system architecture diagram of another embodiment of the present invention;

[0051] Figure 3 This is a timing diagram of the detection process of the present invention;

[0052] Figure 4 This is a flowchart of the decoding and push process of this invention;

[0053] Figure 5 This is a timing diagram of the interaction between the browser and the distributed decoding module of this invention;

[0054] Figure 6 This is a schematic diagram of the multiplexing thread scheduling of the present invention;

[0055] Figure 7 This is a flowchart of the secondary authentication process of this invention;

[0056] Figure 8 This is the CPU adaptive frame reduction logic diagram of the present invention;

[0057] Figure 9 This is a flowchart of the system method of the present invention.

[0058] In the attached diagram, 20 is the distributed decoding module; and 30 is the video management server. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0060] Reference Figure 1 , Figure 2 , Figure 3 , Figure 4 , Figure 5 , Figure 6 , Figure 7 , Figure 8 and Figure 9 The web-based distributed decoding method for video surveillance includes:

[0061] a) The browser initiates a WebSocket connection via the local loopback address port (127.0.0.1:19022) to check whether the user terminal has installed the distributed decoding program;

[0062] b) If the distributed decoding program does not return the agreed handshake message "nvr wsopen" within the first preset time, it is determined that the program is not installed, and the browser will guide the user to download and install the distributed decoding program.

[0063] c) If a handshake message is received, the browser will send the Uniform Resource Locator (URL) of the video stream to be played to the distributed decoding program through the same WebSocket channel;

[0064] d) The distributed decoding program calls the local FFmpeg library, uses the terminal CPU to decode the video stream in real time, and uses OpenCV to convert the decoded video keyframes frame by frame into an image format natively supported by the browser.

[0065] e) The distributed decoding program encapsulates the binary data of each frame of image and its address identifier into a WebSocket message and actively pushes it to the browser. The browser then refreshes and displays the image in a specified area of ​​the page in real time based on the address identifier.

[0066] f) When the browser closes the monitoring page or the WebSocket is disconnected, the distributed decoding program maintains the decoding state of the video stream for a second preset time. If no pull request for the same video stream URL is received again within this time, the decoding will automatically terminate and the local computing resources will be released.

[0067] The above steps are as follows: 1. Overall architecture

[0068] Figure 1 The system physical deployment is shown: the surveillance cameras are connected to the video management server 30 via an IP network; the user PC only establishes a signaling channel with the video management server 30, and the bitstream is completed in a closed loop through the PC's local port 127.0.0.1:19022. Figure 2 The logical modules are: a browser module, a distributed decoding module, and a video management server 30. Between these three, the browser and video management server 30 use HTTPS signaling, the browser and distributed decoding module use a local WebSocket data channel, and the distributed decoding module and camera use an RTSP streaming channel, forming a "signaling-data separation" architecture.

[0069] 2. Local capability detection and boot installation

[0070] Step a: During the page's onload phase, the browser module instantiates a WebSocket object. The target address is fixed at ws: / / 127.0.0.1:19022, the path is / nvr, and the protocol header carries Sec-WebSocket-Protocol:nvr-v1. If a frame of type TEXT is received within 3000ms and the payload is equal to the agreed handshake message "nvr ws open", the module is considered ready. Otherwise, a floating bar is rendered in the upper right corner of the page, providing a download link and SHA256 checksum. After clicking, the user obtains an executable installation package matching their operating system (Windows-msi, Linux-deb / rpm, macOS-dmg, and Tongxin UOS / deepin dedicated deb). The installation package embeds a daemon process that starts automatically with the system and automatically opens the TCP:19022 listening thread on the first run, requiring no additional configuration.

[0071] 3. Session establishment and URL distribution

[0072] After step b completes the installation, the browser re-initiates the WebSocket handshake. Upon successful handshake, it immediately proceeds to step c: The Uniform Resource Locator (RTSP URL) of the video stream to be played and a one-time session token (JWT format, expiration time 15 minutes) are sent through the same WebSocket channel; the message structure is shown in the custom protocol header ( Figure 6): Fixed header 4 bytes (magic number 0x4E565202) + 2 bytes version + 1 byte message type (0x01=URL sent) + 4 bytes payload length + 4 bytes CRC32, payload is UTF-8 encoded JSON {"url":"rtsp: / / ...","token":"..."}.

[0073] 4. Secondary authentication

[0074] In step d, after receiving a message of type 0x01, the distributed decoding module does not immediately start streaming, but instead sends an HTTPS POST / verify request to the video management server 30, with the header including Authorization: Bearer. <token>

[0075] 5. Pulling, Decoding, and Pushback

[0076] After successful authentication, the module starts an independent thread (thread name format: NvrThread-). <cameraid>)

[0077] FFmpeg opens an RTSP connection, setting tcp transport, stimeout 5s, max_delay 0, and flagslow_delay;

[0078] After decoding to obtain YUV420P frames, OpenCV cvtColor is used to convert them to BGR, and then imencodes them into JPEG with a quality factor of q=80, controlling the single frame size to be <100KB.

[0079] The JPEG binary data and the prefix address identifier (cameraId+timestamp) are encapsulated into a data frame of type 0x02 and actively pushed to the browser via the established WebSocket;

[0080] After receiving the image, the browser draws the Image object onto the corresponding address based on the address identifier. <canvas>

[0081] 6. Multiplexing and Single Instance Keep-Alive

[0082] When multiple tabs are open on the same terminal, all pages connect to the same TCP port 19022, which is maintained by the internal multiplexing scheduler of the module.<fd,cameraId> Hash table, only one NvrThread is created. <cameraid>

[0083] 7. CPU adaptive frame rate reduction

[0084] After each frame is decoded, the module reads / proc / stat (Linux) or PDH (Windows) to calculate the average CPU usage over the past second. The upper limit threshold is TH_HIGH=85%, and the lower limit is TH_LOW=45%.

[0085] If the mean is greater than or equal to TH_HIGH and the current frame rate is greater than 50% of the original frame rate, then the frame rate is reduced by 1 or a non-critical frame is skipped.

[0086] If the mean is less than or equal to TH_LOW and the current frame rate is less than the original frame rate, then the frame rate is increased by 1.

[0087] Adjust the frame rate by 1fps increments, with a maximum reduction of no more than 50% of the original frame rate, to ensure usable visuals and smooth gameplay on the device.

[0088] 8. Chain interruption survival and resource release

[0089] When the page is closed or a network error causes the WebSocket connection to be disconnected, the module marks the thread corresponding to the URL as "keep-alive" and starts a 60-second timer. If the same URL is detected to be requested again within the timer, the original RTSP connection is reused to achieve a fast reconnection in less than 0.5 seconds; otherwise, a TEARDOWN message is sent to close the RTSP, release the decoding cache and thread resources, and the process automatically exits (if there are no other URLs).

[0090] 9. Information integrity protection

[0091] All WebSocket frames include a 4-byte CRC32 checksum. Upon receiving the frame, the browser recalculates the checksum and compares it with the checksum in the frame header. If they do not match, the frame is discarded and a retransmission is requested to prevent malicious injection of local loopback data.

[0092] 10. Cross-platform deployment and upgrade

[0093] The module provides a portable executable file and a system daemon. During the upgrade process, the browser downloads the new package and verifies the signature → the daemon compares the version number → the executable file is hot-swapped → a SIGTERM is sent to the old process → the old process exits smoothly, achieving a seamless upgrade for the user.

[0094] Through the above steps, the present invention achieves:

[0095] Zero plugins: No browser extensions or ActiveX controls need to be installed throughout the process;

[0096] Low latency: Local decoding + loopback push, actual end-to-end time <2s;

[0097] High compatibility: Supports Windows / Linux / macOS / domestic OS;

[0098] Secure and controllable: secondary authentication + CRC check + local loopback isolation;

[0099] Resource adaptation: CPU frame reduction + single instance reuse saves 40% of memory;

[0100] Video management server load reduction: no transcoding required, zero CPU usage.

[0101] Furthermore, the distributed decoding program and the browser communicate via the same WebSocket channel for signaling, control, and image data transmission, eliminating the need for browser plugins or ActiveX controls. Each frame is in JPEG format and encapsulated in the WebSocket message body as a base64 string or ArrayBuffer. The browser module renders the image directly using an HTML5Canvas or Image object, achieving zero-plugin, low-latency playback.

[0102] The first preset time is 3000ms, and the second preset time is 60s. After the distributed decoding program starts, it listens to the local loopback address port and automatically establishes a streaming thread after receiving any video stream Uniform Resource Locator. The number of threads is dynamically related to the number of local CPU cores. When the utilization rate exceeds the set threshold, the decoding frame rate is automatically reduced or non-critical frames are skipped to prevent terminal stuttering and ensure smooth playback.

[0103] Furthermore, the distributed decoding program and the browser communicate via a single WebSocket binary channel for signaling, control, and image data transmission, eliminating the need for browser plugins or ActiveX controls. Each frame is in JPEG format and encapsulated in a WebSocket message body as a base64 string or ArrayBuffer, which the browser module renders directly using an HTML5Canvas or Image object. Simultaneously, the distributed decoding program monitors local CPU usage in real time, automatically reducing the decoding frame rate or skipping non-critical frames when the usage exceeds a set threshold, achieving low latency and smooth playback in a plugin-free environment.

[0104] Furthermore, the browser sends the user's identity information and session token along with the video stream's Uniform Resource Locator (URL). The distributed decoding program performs a second token verification with the video management server 30 before pulling the stream. Only after successful verification will the stream be pulled to ensure consistency of video source permissions. When multiple browser tabs on the same terminal are playing different video streams simultaneously, the distributed decoding program only starts a single instance. It uses internal multiplexed threads to decode each video stream independently and pushes image data to the corresponding tabs according to different address identifiers to reduce memory usage and avoid duplicate streaming.

[0105] Preferably, the distributed decoding program and the browser communicate via a single WebSocket channel to transmit signaling, control, and image data, without the need to install browser plugins or ActiveX controls.

[0106] The image format is JPEG, and each frame is encapsulated in the WebSocket message body as a base64 string or ArrayBuffer, which is then rendered directly by the browser using an HTML5Canvas or Image object.

[0107] The first preset time is 3000ms; the second preset time is 60s.

[0108] After startup, the distributed decoding program listens to the local loopback address port and automatically creates a streaming thread upon receiving any video stream URL. The number of threads is dynamically correlated with the number of local CPU cores to prevent terminal lag.

[0109] 1. WebSocket Single-Channel Configuration

[0110] Only one TCP connection is maintained between the browser module and the distributed decoding module, with the target address being 127.0.0.1:19022 and the path fixed at / nvr. The sub-protocol header Sec-WebSocket-Protocol is set to nvr-v1. After the connection is established, all uplink signaling (URL sending, pausing, resuming, closing) and downlink data (handshake response, JPEG frames, error codes) reuse this connection, without opening a new port, thus avoiding browser pop-up prompts or firewall blocking.

[0111] See single-channel message format Figure 6 Each message frame consists of a fixed 14-byte header and a payload. The fixed header includes, in order:

[0112] The magic number 0x4E565202 (4 bytes) is used to quickly identify legitimate frames;

[0113] Version number 0x0001 (2 bytes) ensures backward compatibility;

[0114] Message type 1 byte: 0x00 handshake response, 0x01 URL sending, 0x02 JPEG data, 0x03 pause, 0x04 resume, 0xFE error, 0xFF shutdown;

[0115] The payload length is 4 bytes (little endian), and the maximum supported single frame size is 4GB.

[0116] A 4-byte CRC32 checksum is used to cover the entire payload, preventing the injection of local loopback data.

[0117] The payload adopts an "address identifier + entity data" structure: the address identifier is a fixed 16-byte UUID (camera ID + timestamp hash), and the entity data uses UTF-8 text in handshake / control messages and binary in JPEG data messages. Upon receiving a message, the browser immediately calculates the CRC and compares it with the checksum in the header. If they do not match, the browser discards the message and sends back a 0xFE error frame. The distributed decoding module 20 retransmits the previous frame upon receiving the error frame, thus ensuring the integrity of single-channel data.

[0118] 2. JPEG encapsulation and rendering process

[0119] The distributed decoding module 20's internal decoding thread, upon acquiring a YUV420P image frame, calls the OpenCV function `cvtColor` to convert it to BGR, then uses `imencode` to compress the image into JPEG, with a quality factor of q=80, controlling the single frame size to ≤100KB. The compressed binary data is directly used as the payload entity, with the message type set to 0x02. Upon receiving frame 0x02:

[0120] If ArrayBuffer is supported, use WebSocket binaryType='arraybuffer' to get a Uint8Array, generate a Blob URL using new Blob([data],{type:'image / jpeg'}), assign it to HTMLImageElement.src, and then draw it. <canvas>

[0121] To ensure compatibility with older browsers, the JPEG binary is base64 encoded, with the header data:image / jpeg;base64 added, and then loaded and drawn using an Image object.

[0122] Since the address identifier is already given in the payload prefix, the browser writes the image to the corresponding address based on this UUID. <canvas>

[0123] 3. Definition and implementation of preset duration

[0124] First preset timeout (handshake timeout): The browser starts a single timer with a duration of 3000ms after the WebSocket constructor succeeds. If no frame of type 0x00 with a payload of "nvr ws open" is received within the timer callback, the connection is actively closed and a download prompt bar is triggered. This duration has been tested and can achieve 100% completion of local port opening and response on mainstream PCs (i5-8th generation + Win10) and domestic CPUs (Loongson 3A5000 + Tongxin UOS), balancing response speed and reliability.

[0125] The second preset time (keep-alive duration): After detecting that the WebSocket is closed or receiving a 0xFF type close frame, the module puts the corresponding camera thread into "keep-alive" state and starts a 60-second timer (allowing ±1 second error). During the keep-alive period, the thread does not actively send TEARDOWN, and the RTSP connection is maintained; if the same URL is requested again within 60 seconds, the original connection is reused and the timer is canceled, achieving a fast reconnection in less than 0.5 seconds; after the timeout, TEARDOWN is sent, the decoding buffer is released, the thread is closed, and the process automatically exits when there are no other camera tasks, thereby saving terminal power and memory.

[0126] 4. Dynamic thread association strategy

[0127] When the module starts, it calls std::thread::hardware_concurrency() in the main() function to get the number of CPU cores N:

[0128] If N≤4, the maximum number of streaming threads = N;

[0129] If N > 4, the upper limit = N - 2, reserving 2 cores for browser and system use;

[0130] For each new camera URL, the reuse scheduler first checks if the current number of threads has reached the limit. If not, it creates a new NvrThread. <cameraid>

[0131] With the above settings, this invention achieves single-channel low-latency transmission, JPEG-compatible rendering, fast handshake and keep-alive, and dynamically adjusts the number of decoding threads according to the CPU core in a zero-plugin environment, ensuring smooth terminal operation and saving system resources.

[0132] Preferably, the browser sends the user's identity information and session token along with the video stream URL. The distributed decoding program performs a second verification of the token with the video management server 30 before pulling the stream. Only after the verification is successful will the stream be pulled to ensure the consistency of video source permissions.

[0133] Preferably, when multiple browser tabs on the same terminal are playing different video streams simultaneously, the distributed decoding program only starts a single instance, decodes each video stream independently through internal multiplexing threads, and pushes image data to the corresponding tab according to different address identifiers, so as to reduce memory usage.

[0134] Preferably, the distributed decoding program is a cross-platform executable program that supports Windows, Linux, macOS and domestic operating systems. Its upgrade and uninstallation are triggered by the browser and completed by the terminal operating system-level daemon process, without the need for manual intervention by the user.

[0135] The distributed decoding program monitors the local CPU usage in real time during the decoding process. When the usage exceeds a set threshold, it automatically reduces the decoding frame rate or skips non-critical frames to ensure the smooth operation of the terminal system.

[0136] Preferably, the WebSocket messages between the browser and the distributed decoding program use a custom lightweight protocol. The protocol header includes a version number, message type, timestamp, and CRC32 checksum to protect against message tampering and replay attacks.

[0137] In this embodiment, 1. Token two-factor authentication

[0138] When the browser module sends the RTSP URL via a single WebSocket channel, it concatenates a one-time session token (JWT format, 15-minute expiration time, payload containing userId, cameraId, and expire) with the URL in the same JSON payload. Upon receiving a 0x01 message, the distributed decoding module immediately pauses streaming and sends a secondary verification request via HTTPS POST to the / verify endpoint of the video management server 30.

[0139] Header:Authorization: Bearer <token>

[0140] Body: {"url":"rtsp: / / ...","fingerprint":SHA256(url+userId)}.

[0141] After verifying the signature, validity period, and cameraId permissions, the video management server 30 returns a 200 OK response with the JSON field "allow" set to true; otherwise, it returns a 401 Unauthorized response. The module only continues streaming if it receives a 200 response with "allow" set to true; otherwise, it sends a 0xFE error frame and terminates the process. This secondary verification, together with the initial authentication between the browser and the video management server 30, forms a "two-factor" mechanism, ensuring that even if the RTSP URL is intercepted by a third party, offline streaming is impossible, thus guaranteeing the consistency of video source permissions.

[0142] 2. Multi-tab single instance reuse

[0143] When a user opens N tabs on the same terminal and plays live1...liveN respectively, all pages connect to the same local TCP port 19022. (Module internal maintenance)<cameraId, NvrThread, fdList> triplet hash table:

[0144] When the first tab requests live1, NvrThread-1 is created, and the corresponding WebSocket file descriptor fd1 is added to fdList;

[0145] When requesting live2...liveN from the second and subsequent tabs, if cameraId already exists, the new file descriptor is simply appended to fdList, and no new thread is created; if cameraId does not exist and the current number of threads has not reached the CPU core limit, then NvrThread is created. <cameraid>

[0146] When any WebSocket is closed, the corresponding fd is removed from fdList. NvrThread is destroyed only when fdList is empty, and RTSP TEARDOWN is sent.

[0147] This achieves "single instance - multiple push", reducing memory usage by more than 40% compared to the traditional independent process solution, and avoiding repeated streaming.

[0148] 3. Cross-platform protection upgrade

[0149] The module is released as a portable executable, containing both a daemon process and a worker process within the same binary:

[0150] Windows: Register as a Windows Service via nssm, service name NvrDecoder, startup type Auto; during upgrade, the browser downloads the new package and verifies the signature → call nssm restart to perform a hot replacement.

[0151] Linux / macOS: The systemd / user unit file is / usr / lib / systemd / user / nvr-decoder.service, and ExecStart points to / usr / bin / nvr-decoder; during upgrades, the rpm / deb package executes the postinst script systemctl --user restart nvr-decoder;

[0152] Domestic operating systems (Tongxin UOS, Kylin): also use systemd, and the rpm signing key is written to / etc / pki / rpm-gpg to ensure the source is trustworthy.

[0153] Uninstallation process: The browser page triggers the "Uninstall" button → JavaScript sends a 0xFF message → After receiving the message, the distributed decoding module 20 calls systemctl stop & disable and deletes the executable file. No manual intervention from the user is required throughout the process.

[0154] 4. CPU adaptive frame rate reduction

[0155] Each decoding thread retrieves its own CPU time after frame output using getrusage(RUSAGE_THREAD, …) (Linux) or GetThreadTimes() (Windows), and calculates the average CPU usage over the most recent second.

[0156] If the average is ≥85% and the current frame rate is >50% of the original frame rate, then the frame rate is reduced by 1 fps or a non-critical frame is skipped.

[0157] If the average is ≤45% and the current frame rate is < original frame rate, then the frame rate is increased by 1 fps;

[0158] Adjust the frame rate by 1fps increments, with a maximum reduction of no more than 50% of the original frame rate, ensuring usable visuals. Record frame rate usage every 5 seconds within each thread, creating a sliding window to prevent accidental triggering due to momentary jitter. This mechanism guarantees an overall interface stutter rate of <2%, even on low-end software terminals.

[0159] 5. Custom lightweight protocol

[0160] All WebSocket frames follow a 14-byte fixed header:

[0161] Magic number 0x4E565202 (4 bytes);

[0162] Version number 0x0001 (2 bytes);

[0163] Message type 1 byte (0x00~0xFF);

[0164] The timestamp is a Unix second (4 bytes) used to prevent replay attacks.

[0165] The payload length is 4 bytes (little endian).

[0166] The CRC32 checksum is 4 bytes, covering the payload, timestamp, and message type.

[0167] After receiving a frame, both the browser and the distributed decoding module 20 recalculate the CRC and compare it with the check value in the header. If they do not match, the frame is discarded and a 0xFE error frame is sent back, thereby preventing the local loopback data from being maliciously injected or tampered with. At the same time, frames with a timestamp difference > 30s are directly regarded as expired and discarded, further resisting replay attacks.

[0168] Through the above settings, this invention achieves consistent permissions, single-instance multiplexing, seamless cross-platform upgrades, smooth terminal adaptation, and message integrity protection in a zero-plugin environment, significantly improving the security, compatibility, and user experience of web-based video surveillance.

[0169] Based on the same concept, a web-based distributed video surveillance decoding system includes:

[0170] The browser module, deployed on the user terminal, is used to access the local loopback address port.

[0171] 127.0.0.1:19022 actively initiates a WebSocket connection and determines whether a distributed decoding module exists locally based on whether the agreed handshake message "nvrws open" is received; and if it exists, it sends the Uniform Resource Locator (URL) of the video stream to be played through the same WebSocket channel.

[0172] The distributed decoding module resides on the user terminal. After receiving the video stream's Uniform Resource Locator (URI), it calls the local FFmpeg library to decode the video stream in real time. It then uses OpenCV to convert the decoded keyframes frame by frame into an image format natively supported by the browser. Finally, it encapsulates the binary data and address identifier of each frame into a WebSocket message and actively pushes it to the browser module.

[0173] Video management server 30 is used to provide raw video streams and permission verification services, but does not participate in video decoding or secondary transcoding;

[0174] When the WebSocket connection is disconnected, the distributed decoding module maintains the decoding state of the video stream for a preset keep-alive period. If no pull request for the same video stream Uniform Resource Locator is received again within this period, the decoding is automatically terminated and local computing resources are released.

[0175] 1. Overall system deployment and physical connection

[0176] Video management server 30 is deployed in the server room, maintaining RTSP connections with several surveillance cameras via a standard IP network. It is responsible for stream aggregation, authentication, and session token issuance. User terminals are general-purpose PCs or domestically produced terminals, pre-installed with a browser module. The distributed decoding module resides on the terminal in a green executable form, listening on the local loopback address 127.0.0.1:19022 after startup, accepting only local connections to prevent external intrusion. The terminal and...

[0177] There is only an HTTPS signaling channel between the video management servers 30. The bitstream data is completed locally by the terminal in a closed loop. The video management server 30 does not participate in decoding or secondary transcoding at all, and the CPU usage is zero.

[0178] 2. Detailed Structure of the Browser Module

[0179] a. Connection detection unit: Instantiate WebSocket during the page onload phase, with the target URI fixed at ws: / / 127.0.0.1:19022 / nvr and the subprotocol header filled with nvr-v1; if a frame of type 0x00 with payload equal to "nvr ws open" is received within 3000ms, it is determined that the distributed decoding module 20 is ready; otherwise, a floating prompt bar is rendered to guide the user to download the installation package.

[0180] b. Signaling Unit: After the user selects a camera, the browser sends a 0x01 message via the same WebSocket. The payload is JSON{"url":"rtsp: / / ...","token":"JWT..."}, and the message header includes a 4-byte CRC32 checksum to prevent local injection.

[0181] c. Rendering Unit: Upon receiving a data frame of type 0x02, extracts the 16-byte address identifier and renders the JPEG data to the corresponding location based on the cameraId. <canvas>

[0182] 3. Detailed Composition of the Distributed Decoding Module

[0183] a. Local Listening Submodule: At startup, a TCP listening socket is created in the main thread, bound to 127.0.0.1:19022, and the port reuse option SO_REUSEADDR is set to 1; it adopts the epoll (Linux) or IOCP (Windows) model, and a single thread can handle thousands of concurrent connections.

[0184] b. Secondary Authentication Submodule: After receiving a 0x01 message, it first pauses the streaming and sends a message to the video management server 30.

[0185] Initiate HTTPS POST / verify, with the header attached.

[0186] Authorization: Bearer <token> <cameraid>

[0187] 4. Functional Boundaries of Video Management Server 30

[0188] Video management server 30 only provides:

[0189] 1) Forwarding the original RTSP stream; 2) User login and JWT token issuance; 3) / verify secondary authentication interface.

[0190] Its CPU does not participate in decoding, transcoding, or image processing, so even with tens of thousands of concurrent connections, the computing load remains at an extremely low level, significantly reducing data center energy consumption and bandwidth costs.

[0191] 5. System Collaboration Workflow

[0192] Step 1: Browser module detects the presence of the local module → Step 2: Issues URL + Token → Step 3: Module secondary authentication → Step 4: Pull-stream decoding → Step 5: JPEG pushback rendering → Step 6: Keep alive for 60 seconds after connection failure → Step 7: Release resources if no reconnection occurs. Throughout the entire process, the bitstream remains confined to the local terminal. A custom lightweight protocol (version number, timestamp, CRC32) is used between the browser and the module to resist injection and replay attacks, achieving a "zero-plugin, low-latency, secure and controllable" web-based video surveillance experience.

[0193] In summary, this system, through the collaboration of the browser module, the distributed decoding module, and the video management server 30, relieves the video management server 30 of the decoding burden, enabling the terminal to achieve single-instance multiplexing, secondary permission verification, CPU adaptive frame reduction, and seamless cross-platform upgrades.

[0194] Preferably, the browser module and the distributed decoding module complete signaling, control and image data transmission only through a single WebSocket channel, without the need to install browser plugins or ActiveX controls;

[0195] The distributed decoding module sets the image format to JPEG and encapsulates it in the WebSocket message body as a base64 string or ArrayBuffer; the browser module renders it directly using an HTML5Canvas or Image object.

[0196] The preset keep-alive timeout is 60 seconds; if the browser module does not receive a handshake message within 3000 milliseconds, it determines that the distributed decoding module does not exist and guides the user to download and install it.

[0197] Preferably, the distributed decoding module listens to the local loopback address port after startup, and automatically establishes a streaming thread after receiving any video stream Uniform Resource Locator. The number of threads is dynamically related to the number of local CPU cores to prevent terminal lag.

[0198] The browser module is also used to distribute user identity information and session tokens along with the video stream's Uniform Resource Locator (URL); the distributed decoding module performs a second verification of the token with the video management server 30 before pulling the stream, and only pulls the stream after the verification is successful, so as to ensure the consistency of video source permissions.

[0199] When multiple browser tabs on the same terminal are playing different video streams simultaneously, the distributed decoding module only starts a single instance, uses internal multiplexed threads to decode each video stream independently, and pushes image data to the corresponding tab according to different address identifiers to reduce memory usage.

[0200] Preferably, the distributed decoding module is a cross-platform executable program that supports Windows, Linux, macOS and domestic operating systems. Its upgrade and uninstallation are triggered by the browser module and completed by the terminal operating system-level daemon process, without the need for manual user intervention.

[0201] The WebSocket messages between the browser module and the distributed decoding module use a custom lightweight protocol. The protocol header includes a version number, message type, timestamp, and CRC32 checksum to protect against message tampering and replay attacks.

[0202] The distributed decoding module monitors the local CPU utilization in real time during the decoding process. When the utilization exceeds the set threshold, it automatically reduces the decoding frame rate or skips non-critical frames to ensure the smooth operation of the terminal system.

[0203] 1. Single-channel WebSocket full-duplex transmission

[0204] Only one TCP connection is maintained between the browser module and the distributed decoding module. The target address is fixed at ws: / / 127.0.0.1:19022 / nvr, and the subprotocol header is filled with nvr-v1. After the connection is established, uplink signaling (URL sending, pausing, resuming, closing) and downlink data (handshake response, JPEG frames, error codes) all reuse this channel, without opening a new port, thus avoiding browser pop-up prompts or firewall blocking. The channel uses binary frame type, and the browser side sets binaryType='arraybuffer' to ensure that there is no transcoding overhead.

[0205] 2. JPEG encapsulation and rendering

[0206] Internally, the decoding thread of the module, after acquiring each frame of YUV420P image, calls OpenCV cvtColor to convert it to BGR, and then compresses it into JPEG using imencode, with a quality factor of q=80, controlling the single frame size to ≤100KB. The compressed binary data is concatenated with a 16-byte address identifier (cameraId + timestamp) to form the payload. Upon receiving this, the browser:

[0207] If ArrayBuffer is supported, directly generate a BlobURL using `new Blob([data],{type:'image / jpeg'})`, assign it to the Image object, and draw it to the image. <canvas>;

[0208] To ensure compatibility with older browsers, the JPEG binary is base64 encoded, and the header is modified to include data:image / jpeg;base64, before being loaded via Image.

[0209] Since the address identifier is already given in the payload prefix, the browser writes the image to the corresponding address based on this UUID. <canvas>;

[0210] 3. Keep-alive and handshake timeout

[0211] Handshake Timeout: After the WebSocket constructor succeeds, the browser starts a single timer with a duration of 3000ms. If no frame of type 0x00 with a payload equal to "nvr ws open" is received within the timer callback, the connection is actively closed and a download prompt bar is triggered. This duration has been tested and can achieve 100% completion of local port opening and response on mainstream PCs (i5-8th generation + Win10) and domestic CPUs (Loongson 3A5000 + Tongxin UOS), balancing response speed and reliability.

[0212] Keep-alive duration: Upon detecting a WebSocket closure or receiving a 0xFF type close frame, the module sets the corresponding cameraId thread to "keep-alive" state and starts a 60-second timer (allowing ±1 second error). During the keep-alive period, the thread does not actively send TEARDOWN, and the RTSP connection remains open. If the same URL is requested again within 60 seconds, the original RTSP connection is reused and the timer is canceled, achieving a fast reconnection in less than 0.5 seconds. After the timeout, an RTSP TEARDOWN is sent, the decoding buffer is released, the thread is closed, and the process automatically exits when there are no other camera tasks, thereby saving terminal power and memory.

[0213] 4. Dynamic thread association

[0214] When the module starts, it calls std::thread::hardware_concurrency() in the main() function to get the number of CPU cores N:

[0215] If N≤4, the maximum number of streaming threads = N;

[0216] If N > 4, the upper limit = N - 2, reserving 2 cores for browser and system use;

[0217] For each new camera URL, the reuse scheduler first checks if the current number of threads has reached the limit. If not, it creates a new NvrThread. <cameraid>

[0218] 5. Secondary authentication

[0219] After receiving a 0x01 message, the module first pauses the streaming and then sends a secondary verification request via HTTPS POST to the / verify endpoint of the video management server 30.

[0220] Header: Authorization: Bearer <token>

[0221] Body: {"url":"rtsp: / / ...","fingerprint":SHA256(url+userId)}.

[0222] After verifying the signature, validity period, and cameraId permissions, the video management server 30 returns a 200 OK response with the JSON field "allow" set to true; otherwise, it returns a 401 Unauthorized response. The module only continues streaming if it receives a 200 response with "allow" set to true; otherwise, it sends a 0xFE error frame and logs it in the audit log. This secondary verification, together with the initial authentication between the browser and the video management server 30, forms a "two-factor" mechanism, ensuring that even if the RTSP URL is intercepted by a third party, offline streaming is impossible, thus guaranteeing the consistency of video source permissions.

[0223] 6. Single-instance multiplexing

[0224] When a user opens N tabs on the same terminal and plays live1...liveN respectively, all pages connect to the same TCP port 19022. (Module internal maintenance)<cameraId, NvrThread, fdList> triplet hash table:

[0225] When the first tab requests live1, NvrThread-1 is created, and the corresponding WebSocket file descriptor fd1 is added to fdList;

[0226] When requesting live2...liveN from the second and subsequent tabs, if cameraId already exists, the new file descriptor is simply appended to fdList, and no new thread is created; if cameraId does not exist and the current number of threads has not reached the CPU core limit, then NvrThread is created. <cameraid>

[0227] When any WebSocket is closed, the corresponding fd is removed from fdList. NvrThread is destroyed only when fdList is empty, and RTSP TEARDOWN is sent.

[0228] This achieves "single instance - multiple push", reducing memory usage by more than 40% compared to the traditional independent process solution, and avoiding repeated streaming.

[0229] 7. Cross-platform protection upgrade

[0230] The module is released as a portable executable, containing both a daemon process and a worker process within the same binary:

[0231] Windows: Register as a Windows Service via nssm, service name NvrDecoder, startup type Auto; during upgrade, the browser downloads the new package and verifies the signature → call nssm restart to perform a hot replacement.

[0232] Linux / macOS: The systemd / user unit file is / usr / lib / systemd / user / nvr-decoder.service, and ExecStart points to / usr / bin / nvr-decoder; during upgrades, the rpm / deb package executes the postinst script systemctl --user restart nvr-decoder;

[0233] Domestic operating systems (Tongxin UOS, Kylin): also use systemd, and the rpm signing key is written to / etc / pki / rpm-gpg to ensure the source is trustworthy.

[0234] Uninstallation process: The browser page triggers the "Uninstall" button → JavaScript sends a 0xFF message → After receiving the message, the module calls systemctl stop & disable and deletes the executable file. No manual intervention from the user is required throughout the process.

[0235] 8. Custom lightweight protocol

[0236] All WebSocket frames follow a 14-byte fixed header:

[0237] The magic number 0x4E565202 (4 bytes) is used to quickly identify legitimate frames;

[0238] Version number 0x0001 (2 bytes) ensures backward compatibility;

[0239] Message type 1 byte (0x00~0xFF);

[0240] The timestamp is a Unix second (4 bytes) used to prevent replay attacks.

[0241] The payload length is 4 bytes (little endian), and the maximum supported single frame size is 4GB.

[0242] The CRC32 checksum is 4 bytes, covering the payload, timestamp, and message type.

[0243] After receiving a frame, both the browser and the distributed decoding module recalculate the CRC and compare it with the checksum in the header. If they do not match, the frame is discarded and a 0xFE error frame is sent back, thus preventing the local loopback data from being injected or tampered with. At the same time, frames with a timestamp difference > 30 seconds are directly regarded as expired and discarded, further resisting replay attacks.

[0244] 9. CPU adaptive frame rate reduction

[0245] Each decoding thread retrieves its CPU time after frame output using getrusage(RUSAGE_THREAD, …) (Linux) or GetThreadTimes() (Windows), and calculates the average CPU usage over the most recent second.

[0246] If the average is ≥85% and the current frame rate is >50% of the original frame rate, then the frame rate is reduced by 1fps or a non-critical frame is skipped.

[0247] If the average is ≤45% and the current frame rate is < original frame rate, then the frame rate is increased by 1fps;

[0248] Adjust the frame rate by 1fps increments, with a maximum reduction of no more than 50% of the original frame rate, ensuring usable visuals. Record frame rate usage every 5 seconds within each thread, creating a sliding window to prevent accidental triggering due to momentary jitter. This mechanism guarantees an overall interface stutter rate of <2%, even on low-end software terminals.

[0249] With the above settings, this system achieves single-channel full-duplex transmission, JPEG-compatible rendering, 60s keep-alive and 3000ms handshake, dynamic thread association, secondary permission verification, single-instance multiplexing, seamless cross-platform upgrades, message integrity protection, and CPU adaptive frame reduction in a zero-plugin environment.

[0250] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are obtained:

[0251] Zero plugins and high compatibility: The browser and the distributed decoding module communicate via a single local WebSocket for signaling, control, and image transmission. No browser plugins, ActiveX, or Wasm need to be installed. It is compatible with all browser versions and operating systems (Windows, Linux, macOS, UnionTech UOS, Kylin, etc.), and deployment is plug-and-play, significantly reducing user-side modification costs.

[0252] Low latency and resource saving: The video stream is pulled, decoded, converted to JPEG and pushed back locally on the terminal. The actual end-to-end latency is less than 2 seconds. The single instance multiplexed thread is dynamically associated with the CPU core to avoid repeated pulling. The terminal memory usage is reduced by more than 40% compared with the traditional multi-process solution. The video management server has zero decoding load on 30 sides, saving more than 50% of the data center's CPU and bandwidth costs.

[0253] Secure and controllable: A dual mechanism of one-time JWT session token + HTTPS secondary authentication is introduced, and the video management server must verify the authentication before decoding; local loopback address monitoring + custom protocol header (version number, timestamp, CRC32) prevent injection, tampering and replay attacks, ensuring that even if the RTSP URL is intercepted, offline streaming cannot be pulled, meeting the stringent requirements of government and enterprise scenarios for video source permissions.

[0254] Cross-platform seamless maintenance: The distributed decoding module is released in a green executable form with a built-in system-level daemon process; upgrades / uninstalls are triggered by a single click in the browser, hot-replacing old versions without any user awareness; the same binary supports Windows services, Linux / macOS systemd and domestic operating systems, significantly reducing the complexity of operation and maintenance.

[0255] Adaptive Smoothness: Real-time monitoring of local CPU utilization. If it exceeds 85%, it automatically reduces the frame rate or skips non-critical frames. If it is below 45%, it gradually restores the original frame rate with a maximum reduction of no more than 50%, ensuring that the interface stuttering rate is less than 2% on low-end software terminals, thus improving the user experience.

[0256] Fast reconnection and resource release: The RTSP connection and decoding context are maintained for 60 seconds after the WebSocket is disconnected, and the screen can be restored in less than 0.5 seconds if the same URL is requested again; the TEARDOWN is automatically sent and the thread is released after the timeout, and the process exits when there is no task, which significantly reduces the terminal's power consumption and memory usage.

[0257] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / cameraid> < / token> < / cameraid> < / canvas> < / canvas> < / cameraid> < / token> < / canvas> < / cameraid> < / token> < / cameraid> < / canvas> < / canvas> < / cameraid> < / canvas> < / cameraid> < / token>

Claims

1. A distributed decoding method for web-based video surveillance, characterized in that, include: a) The browser initiates a WebSocket connection via the local loopback address port to check whether the distributed decoding program has been installed on the user terminal; b) If the distributed decoding program does not return the agreed handshake message "nvr wsopen" within the first preset time, it is determined that the program is not installed, and the browser guides the user to download and install the distributed decoding program. c) If the handshake message is received, the browser will send the Uniform Resource Locator (URL) of the video stream to be played to the distributed decoding program via the same WebSocket channel; The browser sends the user's identity information and session token along with the video stream URL. The distributed decoding program performs a second verification of the token with the video management server before pulling the stream. Only after the verification is successful will the stream be pulled to ensure the consistency of video source permissions. d) The distributed decoding program calls the local FFmpeg library, uses the terminal CPU to decode the video stream in real time, and uses OpenCV to convert the decoded video keyframes frame by frame into an image format natively supported by the browser. e) The distributed decoding program encapsulates the binary data and address identifier of each frame of image into a WebSocket message and actively pushes it to the browser. The browser refreshes and displays the image in a specified area of ​​the page in real time based on the address identifier. f) When the browser closes the monitoring page or the WebSocket is disconnected, the distributed decoding program maintains the decoding state of the video stream for a second preset time. If no pull request for the same video stream URL is received again within this time, the decoding is automatically terminated and local computing resources are released.

2. The method according to claim 1, characterized in that: The distributed decoding program communicates with the browser via a single WebSocket channel for signaling, control, and image data transmission, without requiring browser plugins or ActiveX controls. The image format is JPEG, and each frame of the image is encapsulated in the WebSocket message body as a base64 string or ArrayBuffer, and the browser renders it directly through HTML5Canvas or Image object; The first preset time is 3000ms; the second preset time is 60s; After startup, the distributed decoding program listens to the local loopback address port and automatically establishes a streaming thread upon receiving any video stream URL. The number of threads is dynamically correlated with the number of local CPU cores to prevent terminal lag.

3. The method according to claim 2, characterized in that: When multiple browser tabs on the same terminal are playing different video streams simultaneously, the distributed decoding program only starts a single instance, uses internal multiplexed threads to decode each video stream independently, and pushes image data to the corresponding tabs according to different address identifiers to reduce memory usage.

4. The method according to claim 3, characterized in that: The distributed decoding program is a cross-platform executable program that supports Windows, Linux, and macOS. Its upgrade and uninstallation are triggered by the browser and completed by the terminal operating system-level daemon process, without the need for manual user intervention. The distributed decoding program monitors the local CPU usage in real time during the decoding process. When the usage exceeds a set threshold, it automatically reduces the decoding frame rate or skips non-critical frames to ensure the smooth operation of the terminal system.

5. The method according to claim 4, characterized in that: The WebSocket messages between the browser and the distributed decoding program use a custom lightweight protocol. The protocol header includes a version number, message type, timestamp, and CRC32 checksum to protect against message tampering and replay attacks.

6. A web-based distributed decoding system for video surveillance, characterized in that, include: The browser module, deployed on the user terminal, is used to access the local loopback address port. 127.0.0.1:19022 actively initiates a WebSocket connection and determines whether a distributed decoding module exists locally based on whether the agreed handshake message "nvr wsopen" is received; and if it exists, it sends the Uniform Resource Locator (URL) of the video stream to be played through the same WebSocket channel. The distributed decoding module resides in the user terminal and is used to call the local FFmpeg library to decode the video stream in real time after receiving the video stream Uniform Resource Locator. It then uses OpenCV to convert the decoded keyframes frame by frame into an image format natively supported by the browser. Finally, it encapsulates the binary data and address identifier of each frame into a WebSocket message and actively pushes it to the browser module. The video management server is used to provide raw video streams and permission verification services, but does not participate in video decoding or secondary transcoding. When the WebSocket connection is disconnected, the distributed decoding module maintains the decoding state of the video stream for a preset keep-alive time. If no pull request for the same video stream Uniform Resource Locator is received again within this time, the decoding is automatically terminated and local computing resources are released. After startup, the distributed decoding module listens to the local loopback address port and automatically establishes a streaming thread upon receiving a Uniform Resource Locator (URI) for any video stream. The number of threads is dynamically correlated with the number of local CPU cores to prevent terminal lag. The browser module is also used to send the user's identity information and session token along with the video stream's Uniform Resource Locator; the distributed decoding module performs a second verification of the token with the video management server before pulling the stream, and only pulls the stream after the verification is successful, so as to ensure the consistency of video source permissions. When multiple browser tabs on the same terminal are playing different video streams simultaneously, the distributed decoding module only starts a single instance, and decodes each video stream independently through internal multiplexed threads, and pushes image data to the corresponding tab according to different address identifiers to reduce memory usage.

7. The system according to claim 6, characterized in that, The browser module and the distributed decoding module communicate via a single WebSocket channel for signaling, control, and image data transmission, without the need for browser plugins or ActiveX controls. The distributed decoding module sets the image format to JPEG and encapsulates it in the WebSocket message body as a base64 string or ArrayBuffer. The browser module renders directly using an HTML5Canvas or Image object; The preset keep-alive duration is 60 seconds; if the browser module does not receive a handshake message within 3000 milliseconds, it determines that the distributed decoding module does not exist and guides the user to download and install it.

8. The system according to claim 7, characterized in that, The distributed decoding module is a cross-platform executable program that supports Windows, Linux, and macOS. Its upgrade and uninstallation are triggered by the browser module and completed by the terminal operating system-level daemon process, without the need for manual user intervention. The WebSocket messages between the browser module and the distributed decoding module use a custom lightweight protocol. The protocol header includes a version number, message type, timestamp, and CRC32 checksum to protect against message tampering and replay attacks. The distributed decoding module monitors the local CPU utilization in real time during the decoding process. When the utilization exceeds a set threshold, it automatically reduces the decoding frame rate or skips non-critical frames to ensure the smooth operation of the terminal system.

Images