High-compatibility intelligent fire-fighting video monitoring access deployment architecture

Abstract

The application provides a high-compatibility intelligent fire-fighting video monitoring access deployment architecture, which has the effect of strong protocol transcoding compatibility: a monitoring pull stream server pulls stream from a monitoring camera through an RTSP protocol; a video transcoding server performs FLV / HLS or WebRTC transcoding; mainly for web page end playing, historical review scene browser compatibility is strong, and delay tolerance is high (5-10s). Facing the command and dispatch, emergency scene watching scene, pursuing low delay (<500ms), and strong real-time performance. By introducing multi-local area network and 4G monitoring access capability, the system is expanded from the original single network structure to a cross-domain, cross-network segment and multi-terminal unified access intelligent video platform. The distributed and modular design greatly enhances the adaptability of the system to complex environments, and improves the dispatch response efficiency and data control of the intelligent fire-fighting and other emergency systems in the emergency scene.

Description

Technical Field

[0001] This utility model relates to the field of smart fire protection technology, and in particular to a highly compatible smart fire protection video surveillance access and deployment architecture. Background Technology

[0002] Currently, in smart fire protection systems, front-end monitoring equipment (such as fire cameras) generally support outputting video streams via the RTSP protocol for scenarios such as fire monitoring, on-site inspection, and remote dispatch. Traditional video viewing methods mostly rely on client-side or dedicated software, which suffers from problems such as cumbersome deployment, poor compatibility, and weak platform adaptability, making it difficult to meet the requirements of modern fire protection systems for "multi-terminal, real-time, and flexible" capabilities.

[0003] Especially in the event of a fire, command centers and mobile personnel urgently need to be able to view on-site video at any time via web or mobile devices, rather than relying solely on local platforms or closed software environments.

[0004] Therefore, this paper proposes a video access deployment solution that can quickly access and transcode RTSP video streams into playable formats (such as HLS, FLV, and WebRTC) for web pages, apps, and mini-programs. This solution supports flexible deployment on local servers, private clouds, or public cloud platforms, and features lightweight, cross-platform compatibility, and high compatibility, making it widely applicable to real-time video viewing needs in smart fire protection scenarios. Utility Model Content

[0005] In order to solve the technical problems existing in the prior art, the present invention provides the following technical solution:

[0006] A highly compatible smart fire protection video surveillance access deployment architecture, the architecture comprising:

[0007] The monitoring layer is used for fire monitoring and to collect fire monitoring videos.

[0008] The decoding layer is used to retrieve the fire monitoring video from the monitoring layer, decode it, and upload it.

[0009] The transcoding layer is used to transcode the uploaded fire monitoring video.

[0010] The video forwarding layer is used to send the transcoded fire monitoring video to the client.

[0011] The client is used to play the fire monitoring video.

[0012] Preferably, the monitoring layer adopts local area network monitoring or 4G monitoring.

[0013] Preferably, the decoding layer includes:

[0014] A monitoring streaming server is used to pull the fire monitoring video collected by the monitoring layer and send it to the decoding layer;

[0015] A video stream forwarding server is used to provide forwarding services, forwarding the collected fire monitoring video to the monitoring streaming server.

[0016] Preferably, the decoding layer includes:

[0017] A video decoding server is used to decode the fire monitoring video sent by the monitoring streaming server and upload it to the transcoding layer.

[0018] Preferably, the transcoding layer includes:

[0019] The video transcoding server (FLV / HLS) is used to transcode the fire monitoring video uploaded by the video decoding server into FLV / HLS format, and forward the transcoded video stream to the video forwarding layer, while pre-storing it in the video storage server; when the client webpage / APP requests to play the video stream, the video storage server forwards the FLV / HLS format video stream to the client webpage / APP.

[0020] Preferably, the video forwarding layer includes:

[0021] A video playback forwarding server is used to forward the FLV / HLS format video stream to the client webpage / APP when the client webpage / APP requests to play the video stream.

[0022] Preferably, the transcoding layer includes:

[0023] The video transcoding server (WebRTC) is used to transcode the fire monitoring video uploaded by the video decoding server into WebRTC format, and send the transcoded WebRTC format video stream to the client webpage / mobile phone.

[0024] Preferably, the client includes a client webpage / APP or a client webpage / mobile phone, used to receive and play video streams of different formats, and simultaneously upload the video streams to the smart fire protection backend server.

[0025] The beneficial effects of the technical solution provided by this utility model embodiment include at least the following:

[0026] This solution expands the system from a single network structure to a unified intelligent video platform that supports cross-domain, cross-network segment, and multi-terminal access by introducing multi-LAN and 4G monitoring access capabilities. This distributed and modular design greatly enhances the system's adaptability to complex environments and improves the dispatch response efficiency and data control capabilities of emergency systems such as smart fire protection in sudden scenarios.

[0027] This solution architecture boasts strong protocol transcoding compatibility:

[0028] The monitoring streaming server pulls streams from the monitoring cameras via the RTSP protocol (RTSP + TCP / UDP).

[0029] Video transcoding server (FLV / HLS): Converts to .flv and .m3u8;

[0030] Features: Primarily designed for web-based playback and history replay scenarios; strong browser compatibility; high latency tolerance (5~10s).

[0031] Video transcoding server (WebRTC): Converts to SRTP-encoded WebRTC streams. Features: Designed for command and dispatch, emergency site viewing scenarios, prioritizing low latency (< 500ms) and strong real-time performance. Attached Figure Description

[0032] To more clearly illustrate the technical solutions in the embodiments of this utility model, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this utility model. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0033] Figure 1 This is a schematic diagram of the topology of a highly compatible smart fire protection video surveillance access deployment architecture provided by an embodiment of this utility model;

[0034] Figure 2 This is a schematic diagram of the business flow of an architecture provided in an embodiment of this utility model;

[0035] Figure 3 This is a schematic diagram of a lightweight architecture deployment provided by an embodiment of the present invention. Detailed Implementation

[0036] The technical solution of this utility model will now be described with reference to the accompanying drawings.

[0037] In the embodiments of this utility model, words such as "exemplarily" and "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in this utility model should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in the embodiments of this utility model, the meaning expressed by "and / or" can be both, or it can be either one or the other.

[0038] In this embodiment of the utility model, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that when the distinction between them is not emphasized, their intended meanings are consistent. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that when the distinction between them is not emphasized, their intended meanings are consistent.

[0039] In this embodiment of the invention, subscripts such as W1 may sometimes be mistakenly written as non-subscript forms such as W1. When the difference is not emphasized, the meaning remains the same. In this embodiment, case sensitivity is not required; for example, RTC / Rtc.

[0040] To make the technical problems, technical solutions and advantages of this utility model clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0041] The communication protocol types used between the various servers deployed in this solution, or between the servers and clients / backends, can be found in the appendix. Figure 1 The example illustrates one type of communication protocol, therefore this embodiment is not limited to any particular type.

[0042] This utility model embodiment provides a highly compatible smart fire protection video surveillance access deployment architecture, such as... Figure 1 The diagram shows the topology of a highly compatible smart fire protection video surveillance access deployment architecture, which includes:

[0043] (1) Monitoring layer, used for fire monitoring and collecting fire monitoring videos;

[0044] The monitoring layer employs either local area network (LAN) monitoring or 4G monitoring. For example, LAN 1 and LAN 2 are deployed, enabling fire monitoring through these two LANs. Simultaneously, 4G monitoring equipment (such as 4G cameras) can be used to acquire video streams. The video stream is forwarded via TCP to a TCP stream forwarding server (i.e., the video stream forwarding server), and then transmitted back to the monitoring streaming server.

[0045] Advantages of supporting multiple LANs and 4G monitoring access:

[0046] It supports acquiring RTSP video streams from cameras in multiple subnets, cross-regional LANs, or public network environments via the TCP protocol;

[0047] It can be integrated with various monitoring application scenarios such as government agencies, enterprise factories, residential communities, and remote field monitoring.

[0048] (2) Decoding layer, used to retrieve the fire monitoring video from the monitoring layer and decode and upload it;

[0049] After decoding, the video streams need to be split and transcoded into different formats. Specifically, there are two routes:

[0050] 1) Decoding layer to video transcoding servers (FLV / HLS), including:

[0051] A monitoring streaming server is used to pull the fire monitoring video collected by the monitoring layer and send it to the decoding layer;

[0052] A video stream forwarding server is used to provide forwarding services, forwarding the collected fire monitoring video to the monitoring streaming server.

[0053] 2) The decoding layer for the video transcoding server (WebRTC), including:

[0054] A video decoding server is used to decode the fire monitoring video sent by the monitoring streaming server and upload it to the transcoding layer.

[0055] Streaming, decoding, and transcoding are standard video processing methods and will not be elaborated upon further.

[0056] This architecture boasts strong protocol transcoding compatibility.

[0057] The monitoring streaming server pulls streams from the monitoring cameras via the RTSP protocol (RTSP + TCP / UDP).

[0058] Video transcoding server (FLV / HLS): Converts to .flv and .m3u8;

[0059] Features: Primarily designed for web-based playback and history replay scenarios; strong browser compatibility; high latency tolerance (5~10s).

[0060] Video transcoding server (WebRTC): Converts to SRTP-encoded WebRTC streams. Features: Designed for command and dispatch, emergency site viewing scenarios, prioritizing low latency (< 500ms) and strong real-time performance.

[0061] The business flow of this architecture is as follows: Figure 2As shown. Both types of transcoding streams can be shared with the "Smart Firefighting Backend Server" for scheduling, management, and front-end distribution. Table 1 below compares the two transcoding methods; users can select the appropriate transcoding format based on their needs:

[0062]

[0063] Table 1

[0064] (3) Transcoding layer, used to transcode the uploaded fire monitoring video;

[0065] Transcoding layer, including:

[0066] The video transcoding server (FLV / HLS) is used to transcode the fire monitoring video uploaded by the video decoding server into FLV / HLS format, and forward the transcoded video stream to the video forwarding layer, while pre-storing it in the video storage server; when the client webpage / APP requests to play the video stream, the video storage server forwards the FLV / HLS format video stream to the client webpage / APP.

[0067] The transcoding layer may also include transcoding servers for the following formats:

[0068] The video transcoding server (WebRTC) is used to transcode the fire monitoring video uploaded by the video decoding server into WebRTC format, and send the transcoded WebRTC format video stream to the client webpage / mobile phone.

[0069] This solution also supports WebRTC low-latency direct playback.

[0070] RTSP → Decode → WebRTC transcoding (H.264 + SRTP);

[0071] The video transcoding server (WebRTC) exchanges SDP / ICE with the client via the WebSocket protocol;

[0072] Browser clients connect directly to the server (UDP preferred) for low-latency media communication.

[0073] (4) A video forwarding layer, used to send the transcoded fire monitoring video to the client; the video forwarding layer includes:

[0074] A video playback forwarding server is used to forward the FLV / HLS format video stream to the client webpage / APP when the client webpage / APP requests to play the video stream.

[0075] (5) Client, used to play the fire monitoring video.

[0076] The client, including a client webpage / APP or a client webpage / mobile phone, is used to receive and play video streams of different formats, and simultaneously upload the video streams to the smart fire protection backend server.

[0077] This architecture supports multi-device access:

[0078] Client-side web pages / apps, mini-programs, and WebViews obtain playback streams from video playback forwarding servers via HTTP / HTTPS.

[0079] The web player uses flv.js / hls.js / WebRTC for decoding and display;

[0080] The playback forwarding server is compatible with multiple protocols: HTTP / HTTPS / WS(S) output.

[0081] This solution allows for flexible architecture deployment:

[0082] The system components are loosely coupled: the modules are connected through protocols and are not bound to a single process or server, which facilitates split deployment and fault isolation.

[0083] Communication is via standard protocols: RTSP, TCP, HTTP, and WebSocket. This means all transmissions use universal protocols and do not rely on specific vendors or proprietary protocols. Specific deployment instructions are shown in Table 2 below:

[0084]

[0085] Table 2

[0086] This solution can be deployed in three scenarios:

[0087] Scenario 1: Local area network (LAN) deployment (e.g., fire station): low latency, no public network required, suitable for the main control center;

[0088] Scenario 2, Edge Gateway (e.g., in villages and towns): Deployed on an edge server close to the front-end camera to handle basic decoding / forwarding, saving bandwidth;

[0089] Scenario 3, Cloud Server (Headquarters / Dispatch Center): Unified management of multiple front-ends, providing user access points, forwarding video streams, and storage management.

[0090] This solution also allows for lightweight component assembly:

[0091] Built using lightweight components such as FFmpeg, ZLMediaKit, and SRS, deployment is not dependent on large platforms, making it suitable for rapid expansion. An architecture example is shown below. Figure 3 As shown. The implementation method is as follows:

[0092] The front-end camera continuously outputs a real-time video stream via the RTSP protocol;

[0093] The access server transcodes the RTSP stream into HLS, FLV, and WebRTC video streams in real time through the video conversion server;

[0094] Publish the transcoded video stream to the web frontend (via Nginx, Node.js, or a self-developed streaming media service).

[0095] Users can access the playback page through a browser or mobile device to view the video content in real time;

[0096] The system can be deployed in the cloud (suitable for unified management across multiple locations) or locally (suitable for closed network environments), and the deployment mode can be dynamically switched;

[0097] It supports backend operations such as lifecycle management, disconnection reconnection, and stream status monitoring for each video stream.

[0098] Therefore, by introducing multi-LAN and 4G monitoring access capabilities, this solution expands the system from its original single network structure into an intelligent video platform with unified access across domains, network segments, and multiple terminals. Specifically, it is compatible with the following integration solutions:

[0099] The video dispatch platform of the fire emergency command center;

[0100] Fire trucks and mobile terminals can view real-time footage from the front lines;

[0101] A local video viewing platform for key areas such as industrial parks, hazardous chemical storage areas, mining areas, and customs;

[0102] A closed-loop internal emergency platform deployed on a local small server;

[0103] It integrates with the existing smart fire protection platform system as a video module subsystem.

[0104] Therefore, this distributed and modular design greatly enhances the system's adaptability to complex environments and improves the dispatch response efficiency and data control of emergency systems such as smart fire protection in emergency scenarios.

[0105] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0106] It should be understood that in the various embodiments of this utility model, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this utility model.

[0107] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0108] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0109] In the several embodiments provided by this utility model, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0110] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0111] In addition, in the various embodiments of this utility model, each functional unit can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0112] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this utility model, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this utility model. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0113] The above description is merely a specific embodiment of this utility model, but the protection scope of this utility model is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this utility model should be included within the protection scope of this utility model. Therefore, the protection scope of this utility model should be determined by the protection scope of the claims.

Claims

1. A highly compatible smart fire protection video surveillance access and deployment architecture, characterized in that, The architecture includes: The monitoring layer is used for fire monitoring and to collect fire monitoring videos. The decoding layer is used to retrieve the fire monitoring video from the monitoring layer, decode it, and upload it. The transcoding layer is used to transcode the uploaded fire monitoring video. The video forwarding layer is used to send the transcoded fire monitoring video to the client. The client is used to play the fire monitoring video.

2. The highly compatible smart fire protection video surveillance access deployment architecture according to claim 1, characterized in that, The monitoring layer adopts local area network monitoring or 4G monitoring.

3. The highly compatible intelligent fire protection video surveillance access deployment architecture according to claim 1, characterized in that, The decoding layer includes: A monitoring streaming server is used to pull the fire monitoring video collected by the monitoring layer and send it to the decoding layer; A video stream forwarding server is used to provide forwarding services, forwarding the collected fire monitoring video to the monitoring streaming server.

4. The highly compatible intelligent fire protection video surveillance access deployment architecture according to claim 3, characterized in that, The decoding layer includes: A video decoding server is used to decode the fire monitoring video sent by the monitoring streaming server and upload it to the transcoding layer.

5. The highly compatible intelligent fire protection video surveillance access deployment architecture according to claim 4, characterized in that, The transcoding layer includes: The video transcoding server is used to transcode the fire monitoring video uploaded by the video decoding server into FLV / HLS format, and forward the transcoded video stream to the video forwarding layer, while pre-storing it in the video storage server; when the client webpage / APP requests to play the video stream, the video storage server forwards the FLV / HLS format video stream to the client webpage / APP.

6. The highly compatible intelligent fire protection video surveillance access deployment architecture according to claim 5, characterized in that, The video forwarding layer includes: A video playback forwarding server is used to forward the FLV / HLS format video stream to the client webpage / APP when the client webpage / APP requests to play the video stream.

7. The highly compatible smart fire protection video surveillance access deployment architecture according to claim 4, characterized in that, The transcoding layer includes: The video transcoding server is used to transcode the fire monitoring video uploaded by the video decoding server into WebRTC format, and send the transcoded WebRTC format video stream to the client webpage / mobile phone.

8. The highly compatible intelligent fire protection video surveillance access deployment architecture according to claim 1, characterized in that, The client is used to receive and play video streams of different formats, and simultaneously upload the video streams to the smart fire protection backend server.

Images