Method for safely accessing plug stream of video stream
By adopting long connection channels, custom device unique identification code encryption and Redis cache management in the video streaming system, the problems of cumbersome authentication process and insufficient security in large-scale device management are solved, and efficient and secure video streaming access is achieved.
Patent Information
- Application Number
- CN202510687603.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-27
- Publication Date
- 2025-10-03
AI Technical Summary
Existing video streaming technology has problems with cumbersome authentication processes and high resource usage in large-scale device management. It is also unable to effectively prevent illegal devices from forging return data, resulting in insufficient security and response speed.
It adopts a long connection channel, a Sage encoding encryption strategy for a custom device unique identification code, a Redis cache-based authentication timeliness management, a video viewing status monitoring and resource release mechanism, combined with SSL/TLS encrypted transmission and a heartbeat mechanism to achieve security and efficiency in device identity authentication and authorization.
It improves the system response speed, enhances the security of data transmission and the uniqueness and timeliness of authentication parameters, and ensures the security and controllability of video streaming.
Smart Images
Figure CN120751186A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of video streaming, and in particular to a method for secure access to video streaming. Background Art
[0002] With the acceleration of urban digitalization, demand for advertising on large outdoor screens (such as commercial complex curtain wall screens and transportation hub guide screens) and indoor advertising screens (such as shopping mall shopping guide screens and building elevator screens) has exploded. According to industry reports, the domestic outdoor advertising screen market will exceed 80 billion yuan in 2024, with an average annual growth rate of 12.3%. The annual growth rate of indoor screens in chain stores and public service venues is even higher, exceeding 20%. At the same time, playback accidents caused by content violations and device hijacking are frequent. For example, an outdoor screen in a certain city was once implanted with illegal advertisements. This has prompted regulatory authorities to tighten the security control requirements for broadcast content. Documents such as the "Outdoor Electronic Display Screen Installation Management Specifications" clearly stipulate that "real-time monitoring and second-level response to violations" must be implemented for broadcast content.
[0003] In this context, traditional video streaming technology faces multiple challenges. First, the sheer number of devices scattered across cities (up to tens of thousands in a single city) necessitates an efficient centralized management solution. Second, criminals can tamper with content by forging device identities or hijacking streaming channels. Early authentication methods based on fixed IP addresses or simple password verification no longer meet security requirements. A weak streaming authentication mechanism at a commercial complex resulted in malicious links being implanted on advertising screens on multiple floors, causing both brand reputation and financial losses.
[0004] To solve the above problems, the industry urgently needs a full-link security solution covering device identity authentication, streaming channel encryption, and authentication time management. In particular, in the video image return link, it is necessary to ensure that the monitoring stream returned by the front-end device only comes from legitimate terminals to prevent illegal devices from forging return data to evade supervision. Some solutions currently on the market have the defects of cumbersome authentication processes and high resource usage. For example, a certain information transmission platform uses a single authentication mechanism, which results in a 23% authentication delay when devices are concurrently streaming, causing real-time monitoring images to freeze. Therefore, designing a safe and efficient video streaming access method has become a key technical path to meet the needs of large-scale device management and ensure the security of content broadcasting. Summary of the Invention
[0005] In response to the needs and shortcomings of current technological development, the present invention provides a method for secure access to video stream push, which can meet the needs of large-scale device management and ensure the security of content broadcasting.
[0006] The present invention provides a method for secure access to video stream push, which solves the above technical problems using the following technical solutions:
[0007] A method for secure access to video streaming, applied to an intelligent information publishing and security management service platform, comprises the following steps:
[0008] a) Establish a long connection channel between the client and server of the service platform for real-time communication;
[0009] b) Customize the Sage encoding encryption strategy of the device's unique identification code to generate a 32-bit pure digital encrypted string as the device's unique identification;
[0010] c) Authenticate the data and video channels based on the custom authentication code;
[0011] d) Authentication timeliness management based on Redis cache;
[0012] e) Actively trigger shutdown and authentication failure;
[0013] f) Video viewing status monitoring and resource release.
[0014] Optionally, perform step a). The client and server of the service platform establish a persistent connection based on the Netty non-blocking I / O model, use a custom TCP protocol, and encrypt transmission through SSL / TLS to prevent man-in-the-middle attacks.
[0015] When the client establishes a connection, it sends an authentication message containing the device's unique identifier to the server. After the server verifies the identifier's validity, it binds the identifier to the Netty Channel object and caches it for subsequent instruction issuance.
[0016] When the server receives a video streaming request, it searches for the target device's channel and sends the / stream / start command to the client. After receiving the command, the client starts streaming using the specified URL and authentication parameters.
[0017] Optionally, perform step a) and define a private heartbeat message type / heartbeat as a keep-alive mechanism. The client and server send heartbeat packets to each other at a set interval. If there is no response after three consecutive timeouts, the connection is automatically disconnected to release resources.
[0018] If the client fails to connect n times in a row, an exponential backoff algorithm is triggered: the initial retry interval is x seconds, and the retry interval doubles each time to avoid resource exhaustion.
[0019] Optionally, b) specifically includes:
[0020] Get the MAC address from the device network card and remove the colon in the MAC address;
[0021] Convert each hexadecimal character to its corresponding two-digit decimal number, doubling the length of the string;
[0022] Swap the expanded strings in groups of two to increase confusion;
[0023] Swap the first and last two digits of the processed string to form the final 32-bit encrypted identifier, which serves as the unique identifier of the device.
[0024] The encrypted identification code is stored in the device firmware and platform database, and the CRC32 checksum is calculated and stored for verifying data integrity during each authentication.
[0025] Optionally, c) specifically includes:
[0026] Parameter generation: When the server sends a streaming instruction to the client, it generates dynamic authentication parameters and carries the streaming channel address, and caches the address in Redis.
[0027] Parameter verification: When the platform receives a streaming request, it intercepts each request through a callback method and extracts authentication parameters from the request information; it separates the device identification code from the extracted parameters, compares it with the data in the database, and verifies whether the device is a legally registered device. If the device is illegal, access is denied and error code 40101 is returned; the device identification code and timestamp are combined into a key to query the streaming address in the Redis cache. If the cached value cannot be obtained, it means that the authentication parameter has expired, access is denied, and error code 40103 is returned; the difference between the current time and the timestamp in the request is calculated. If it exceeds the allowed range of ±300 seconds, access is denied and error code 40103 is returned; the device identification code and timestamp are signed using the preset key, and the calculation result is compared with the signature in the request to see if it is consistent. If not, access is denied and error code 40102 is returned;
[0028] Permission control: Dynamically assign streaming permissions based on device type and preset policies.
[0029] Optionally, the d) mentioned specifically includes:
[0030] Set the key-value structure of the Redis cache and specify the validity period. Use Redis Cluster deployment and enable the least frequently used elimination policy to ensure that frequently used authentication data is not cleared.
[0031] During each streaming heartbeat, if the remaining validity period of the authentication parameters is less than the set duration, the client automatically requests a refresh token from the server. After the server verifies the validity of the old token, it generates new authentication parameters and returns them to ensure uninterrupted streaming.
[0032] Optionally, the involved e) specifically includes:
[0033] The user clicks the "Stop Streaming" button on the service platform management interface, and the system automatically triggers shutdown when it detects device abnormalities;
[0034] The server sends a shutdown command to the client. After receiving the command, the client immediately stops pushing the stream and deletes the locally stored authentication parameters. The server atomically executes the "delete Redis cache and update database status" operations through Lua scripts to ensure the atomicity of authentication failure under high concurrency.
[0035] If the client does not respond to the shutdown command, the server automatically clears the authentication cache after the cache item expires and marks the device status as "offline".
[0036] Optionally, f) specifically includes:
[0037] The embedded player SDK reports the viewing status at set intervals;
[0038] The server parses video packets based on the RTSP / RTP protocol, calculates key frame intervals and packet loss rates, and uses FFmpeg to analyze video stream metadata to detect black screens or static frames.
[0039] When the preset conditions are met at the same time, the following operations are triggered: the corresponding authentication parameter cache in Redis is deleted, making the streaming address invalid immediately; a stream offline notification is sent to the CDN node, the edge node cache is stopped, and bandwidth resources are released; and an audit log is recorded for tracing.
[0040] The method for secure access to video stream push of the present invention has the following beneficial effects compared with the prior art:
[0041] 1. This invention utilizes the real-time characteristics of long connections and actively issues instructions through the service platform, thereby improving the system's response speed. It also encrypts the device MAC address through the Sage encoding encryption strategy to generate a unique identifier for the device, thereby improving the security of data transmission. At the same time, it utilizes this unique identifier and the cache invalidation feature of Redis to ensure the uniqueness and timeliness of the authentication parameters.
[0042] 2. The present invention is applicable to various scenarios where large-screen information release is required, such as large-screen information display in government agencies, enterprises, schools, shopping malls, transportation hubs and other places, and can meet the requirements of these places for the security, accuracy, timeliness and controllability of information release. BRIEF DESCRIPTION OF THE DRAWINGS
[0043] Attachment Figure 1 It is a flow chart of the method of the present invention. DETAILED DESCRIPTION
[0044] In order to make the technical solution, the technical problems solved and the technical effects of the present invention more clear, the technical solution of the present invention is clearly and completely described below in conjunction with specific embodiments.
[0045] Example:
[0046] Reference Attachment Figure 1 This embodiment proposes a method for secure access to video streaming, which is applied to intelligent information publishing and security management service platforms. Specifically, the method is applied to the Inspur Intelligent Information Distribution Security Service Platform (a cloud platform focusing on large-screen information publishing security) as an example. The method includes the following steps:
[0047] a) A long connection channel is established between the client and server of the service platform for real-time communication.
[0048] The client and server of the service platform build a persistent connection based on the Netty non-blocking I / O model, adopt a custom TCP protocol (such as a binary protocol based on Protobuf), and use SSL / TLS encrypted transmission to prevent man-in-the-middle attacks;
[0049] When the client establishes a connection (e.g. after the TCP handshake is completed), it sends an authentication message containing the device's unique identifier (e.g. an identifier generated by Sage encoding) to the server. After the server verifies the validity of the identifier, it binds the identifier to the Netty Channel object and caches it (e.g., storing it in a ConcurrentHashMap).<DeviceId,Channel> ), used for issuing subsequent instructions;
[0050] When the server receives a video streaming request (such as one triggered by the management platform), it searches for the target device's channel and sends the / stream / start command to the client. After receiving the command, the client starts streaming using the specified URL and authentication parameters.
[0051] It should be added that, after executing step a), a private heartbeat message type / heartbeat is defined as a keep-alive mechanism, and the message format is JSON:
[0052] {"type":" / heartbeat","timestamp":1695534210,"device_id":"DEV-20250524A1"}; The client and server send heartbeat packets to each other at a set interval (e.g., 30 seconds). If there is no response after three consecutive timeouts, the connection is automatically disconnected to release resources.
[0053] If the client fails to connect five times in a row (e.g., the server port is unreachable), an exponential backoff algorithm is triggered: the initial retry interval is 1 second, and the retry interval doubles each time (1→2→4→8→16 seconds) to avoid resource exhaustion.
[0054] b) Customize the Sage encoding encryption strategy for the device's unique identification code to generate a 32-bit pure digital encrypted string as the device's unique identification, specifically including:
[0055] Get the MAC address from the device network card and remove the colon in the MAC address (for example, convert 00:11:22:33:44:55 to 001122334455);
[0056] Convert each hexadecimal character to its corresponding two-digit decimal number (e.g. A to 10, F to 15) to double the length of the string.
[0057] Swap the positions of the expanded string in groups of two (e.g. 1234 becomes 2143) to increase obfuscation;
[0058] Swap the first and last two digits of the processed string (e.g., the first two digits 12 and the last two digits 34 are swapped to form 34...12) to form the final 32-bit encrypted identifier, which serves as the unique identifier of the device.
[0059] The encrypted identification code is stored in the device firmware and platform database, and the CRC32 check value (such as 0x5D4B2C1F) is calculated and stored for verifying data integrity during each authentication.
[0060] c) Authenticate the data and video channels based on the custom authentication code, including:
[0061] Parameter generation: When the server sends a streaming instruction to the client, it generates dynamic authentication parameters and carries the streaming channel address. The format of the streaming channel address is: RTMP: / / IP address: port number / live / device identification code_timestamp (for example:
[0062] RTMP: / / 192.168.1.1:1935 / live / U2FnZV8xQ0Y5RkY3RTQwOEQ4QkY3Nzk1RjBEMjM2QTQz RjZDRg==_1695534210); and cache the address to Redis. The cache key format is: stream_url: device identifier: timestamp → {full RTMP address, permission range, expiration time};
[0063] Parameter verification: When the platform receives a streaming request, it intercepts each request through a callback method and extracts the authentication parameters (i.e., the device identification code_timestamp part in the URL) from the request information; separates the device identification code from the extracted parameters, compares it with the data in the database, and verifies whether the device is a legally registered device. If the device is illegal, access is denied and error code 40101 is returned; uses the device identification code and timestamp as a key to query the streaming address in the Redis cache. If the cached value cannot be obtained, it means that the authentication parameter has expired, access is denied, and error code 40103 is returned; calculates the difference between the current time and the timestamp in the request. If it exceeds the allowed range of ±300 seconds, access is denied and error code 40103 is returned; (If the parameter contains an HMAC-SHA256 signature) uses the preset key to calculate the signature of the device identification code and timestamp, and compares the calculation result with the signature in the request to see if it is consistent. If not, access is denied and error code 40102 is returned;
[0064] Permission control: Dynamically allocate streaming permissions based on device type (such as "surveillance camera", "IPTV set-top box") and preset policies, including but not limited to resolution restrictions, streaming duration thresholds, bandwidth quotas, etc.
[0065] This authentication mechanism achieves secure control of video streaming requests by embedding device identification codes and timestamps into streaming addresses and combining them with Redis cache management and multi-layer verification. It can effectively resist risks such as URL theft and replay attacks, and ensure that only streaming requests from legitimate devices within the validity period can access the system.
[0066] d) Authentication timeliness management based on Redis cache, specifically including:
[0067] Set the key-value structure of the Redis cache (e.g., auth:{device identification code}:{random number}→{authentication parameters, creation time, permission range}) and specify the validity period (e.g., 30 minutes). Use Redis Cluster deployment (at least three masters and three slaves) and enable the LFU (least frequently used) eviction policy to ensure that frequently used authentication data is not cleared.
[0068] During each streaming heartbeat, if the remaining validity period of the authentication parameters is less than the set duration (e.g., 60 seconds), the client automatically requests a refresh token (e.g., {"action":"refresh_token","old_token":"xxx","timestamp":1695534210}) from the server. After verifying the validity of the old token, the server generates new authentication parameters and returns them to ensure uninterrupted streaming.
[0069] e) Actively trigger shutdown and authentication failure, including:
[0070] When the user clicks the "Stop Streaming" button on the service platform management interface, the system will automatically trigger shutdown if it detects device abnormalities (such as CPU usage > 90% for 30 seconds or network packet loss rate > 20%).
[0071] The server sends a close command to the client (WebSocket message: {"action":"close","reason":"manual","timestamp":1695534210}). After receiving the command, the client immediately stops streaming and deletes the locally stored authentication parameters. The server atomically executes the "delete Redis cache and update database status" operations through Lua scripts to ensure the atomicity of authentication failure under high concurrency.
[0072] If the client does not respond to the shutdown command, the server automatically clears the authentication cache after the cache item expires and marks the device status as "offline".
[0073] f) Video viewing status monitoring and resource release, specifically including:
[0074] The embedded player SDK reports the viewing status at set intervals (specifically in JSON format: {"status":"playing","viewer_count":23,"buffer_time":0.5,"fps":25.0});
[0075] The server parses video packets based on the RTSP / RTP protocol, calculates the key frame interval (a value exceeding 2 seconds is considered abnormal) and the packet loss rate (a packet loss rate of >5% for 10 consecutive frames), and uses FFmpeg to analyze the video stream metadata to detect the presence of a black screen (brightness value <10 for more than 5 seconds) or a static frame (image similarity of >95% for 20 consecutive frames).
[0076] When the preset conditions are met simultaneously (such as the number of viewers = 0 for 60 seconds, the packet loss rate > 10% for 30 seconds, or a black screen or static frame is detected), the following operations are triggered: the corresponding authentication parameter cache in Redis is deleted, making the streaming address invalid immediately; a stream offline notification is sent to the CDN node, the edge node cache is stopped, and bandwidth resources are released; an audit log is recorded (such as 2025-05-24 10:30:45 | Channel ID: CH-2025052410 | Automatic shutdown reason: no one watching + stream abnormality) for traceability.
[0077] In summary, the method for secure access to video streaming of the present invention utilizes the real-time characteristics of long connections and actively issues instructions through the service platform, thereby improving the response speed of the system; encrypts the device MAC data through the Sage coding encryption strategy to generate a unique identifier for the device, thereby improving the security of data transmission; and at the same time utilizes the unique identifier and the cache invalidation feature of Redis to ensure the uniqueness and timeliness of the authentication parameters.
[0078] The above specific examples are used to illustrate the principles and implementation methods of the present invention in detail. These examples are only used to help understand the core technical content of the present invention. Based on the above specific embodiments of the present invention, any improvements and modifications made by those skilled in the art without departing from the principles of the present invention should fall within the scope of patent protection of the present invention.
Claims
1. A method for secure access to video streaming, applied to intelligent information publishing and security management service platforms, characterized in that: The steps include: a) Establish a long connection channel between the client and server of the service platform for real-time communication; b) Customize the Sage encoding encryption strategy of the device's unique identification code to generate a 32-bit pure digital encrypted string as the device's unique identification; c) Authenticate the data and video channels based on the custom authentication code; d) Authentication timeliness management based on Redis cache; e) Actively trigger shutdown and authentication failure; f) Video viewing status monitoring and resource release.
2. A method for secure access to video streaming according to claim 1, characterized in that: In step a), the client and server of the service platform establish a persistent connection based on the Netty non-blocking I / O model, adopt a custom TCP protocol, and use SSL / TLS encrypted transmission to prevent man-in-the-middle attacks. When the client establishes a connection, it sends an authentication message containing the device's unique identifier to the server. After the server verifies the identifier's validity, it binds the identifier to the Netty Channel object and caches it for subsequent instruction issuance. When the server receives the video streaming request, it searches for the channel of the target device. Send the / stream / start command to the client. After receiving the command, the client starts streaming using the specified URL and authentication parameters.
3. A method for secure access to video streaming according to claim 2, characterized in that: Execute step a) and define a private heartbeat message type / heartbeat as a keep-alive mechanism. The client and server send heartbeat packets to each other at a set interval. If there is no response after three consecutive timeouts, the connection is automatically disconnected to release resources. If the client fails to connect n times in a row, an exponential backoff algorithm is triggered: the initial retry interval is x seconds, and the retry interval doubles each time to avoid resource exhaustion.
4. The method for secure access to video streaming according to claim 1, wherein: Said b) specifically includes: Get the MAC address from the device network card and remove the colon in the MAC address; Convert each hexadecimal character to its corresponding two-digit decimal number, doubling the length of the string; Swap the expanded strings in groups of two to increase confusion; Swap the first and last two digits of the processed string to form the final 32-bit encrypted identifier, which serves as the unique identifier of the device. The encrypted identification code is stored in the device firmware and platform database, and the CRC32 checksum is calculated and stored for verifying data integrity during each authentication.
5. The method for secure access to video streaming according to claim 1, wherein: Said c) specifically includes: Parameter generation: When the server sends a streaming instruction to the client, it generates dynamic authentication parameters and carries the streaming channel address, and caches the address in Redis. Parameter verification: When the platform receives a streaming request, it intercepts each request through a callback method and extracts authentication parameters from the request information; it separates the device identification code from the extracted parameters, compares it with the data in the database, and verifies whether the device is a legally registered device. If the device is illegal, access is denied and error code 40101 is returned; the device identification code and timestamp are combined into a key to query the streaming address in the Redis cache. If the cached value cannot be obtained, it means that the authentication parameter has expired, access is denied, and error code 40103 is returned; the difference between the current time and the timestamp in the request is calculated. If it exceeds the allowed range of ±300 seconds, access is denied and error code 40103 is returned; the device identification code and timestamp are signed using the preset key, and the calculation result is compared with the signature in the request to see if it is consistent. If not, access is denied and error code 40102 is returned; Permission control: Dynamically assign streaming permissions based on device type and preset policies.
6. The method for secure access to video streaming according to claim 1, wherein: Said d) specifically includes: Set the key-value structure of the Redis cache and specify the validity period. Use Redis Cluster deployment and enable the least frequently used elimination policy to ensure that frequently used authentication data is not cleared. During each streaming heartbeat, if the remaining validity period of the authentication parameters is less than the set duration, the client automatically requests a refresh token from the server. After the server verifies the validity of the old token, it generates new authentication parameters and returns them to ensure uninterrupted streaming.
7. The method for secure access to video streaming according to claim 1, characterized in that: Said e) specifically includes: The user clicks the "Stop Streaming" button on the service platform management interface, and the system automatically triggers shutdown when it detects device abnormalities. The server sends a shutdown command to the client. Upon receiving the command, the client immediately stops streaming and deletes the locally stored authentication parameters. The server atomically executes the "delete Redis cache and update database status" operations through Lua scripts to ensure the atomicity of authentication failure under high concurrency. If the client does not respond to the shutdown command, the server will automatically clear the authentication cache after the cache item expires and mark the device status as "offline".
8. The method for secure access to video streaming according to claim 1, wherein: Said f) specifically includes: The embedded player SDK reports the viewing status at set intervals; The server parses video packets based on the RTSP / RTP protocol, calculates key frame intervals and packet loss rates, and uses FFmpeg to analyze video stream metadata to detect black screens or static frames. When the preset conditions are met at the same time, the following operations are triggered: the corresponding authentication parameter cache in Redis is deleted, making the streaming address invalid immediately; a stream offline notification is sent to the CDN node, the edge node cache is stopped, and bandwidth resources are released; and an audit log is recorded for tracing.