Access management method and device for security and protection video and electronic equipment

Abstract

The invention provides a security and protection video access management method and device and electronic equipment, and the method comprises the steps: carrying out the coding processing of security and protection video data, determining key frame data and non-key frame data, respectively constructing a timestamp index table and an inter-frame dependency table, carrying out compression processing on the key frame data and the non-key frame data to obtain a key frame file and a non-key frame file; and based on the timestamp index table and the inter-frame dependency table, correspondingly decoding and reading the key frame file and the non-key frame file according to the demand information to obtain target security and protection video data, and playing the target security and protection video data at a playing client. Through the method, the access efficiency of the key frame in streaming playing of the real-time streaming protocol is improved, the delay of random jump in the video playing process is reduced, and the response speed of video playing is improved while the compression ratio of the stored video is ensured.

Description

Technical Field

[0001] This application relates to the field of video surveillance technology, and in particular to a method, apparatus and electronic device for accessing and managing security videos. Background Technology

[0002] Traditional security video storage solutions typically store keyframes and non-keyframes together in a single file. Specifically, during video encoding, a video stream containing keyframes and non-keyframes is generated according to certain encoding rules. The entire video stream is then written into a single file in a uniform format and in chronological order. When playing security videos, the entire video file needs to be parsed, the target frame is located by timestamp, and playback or navigation is achieved by relying on the complete file stream.

[0003] The mixed storage of keyframes and non-keyframes means that the entire video stream needs to be parsed when the file is read, which reduces the efficiency of reading security video data. In the playback scenario of Real-Time Streaming Protocol (RTSP), the latency of previewing keyframes is high and it consumes more resources. In addition, when randomly jumping to a specified time point during video playback, the entire video file needs to be traversed, resulting in a slow video playback response speed. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method, apparatus, and electronic device for accessing and managing security videos. By separating and storing keyframe data and non-keyframe data determined by encoding security video data into independent files, and constructing a timestamp index table and an inter-frame dependency table, users can read keyframe files and non-keyframe files according to the timestamp index table and the inter-frame dependency table when playing security videos, so as to play the target security video data according to user needs. This improves the access efficiency of keyframes in real-time streaming protocols, reduces the latency of random jumps during video playback, and improves the response speed of video playback while ensuring the compression rate of stored video.

[0005] This application provides a method for accessing and managing security videos, the method comprising: In response to receiving security video data, the security video data is encoded to determine the key frame data and non-key frame data corresponding to the security video data; Based on the keyframe data and the non-keyframe data, a timestamp index table and an inter-frame dependency table corresponding to the security video data are constructed respectively, and the keyframe data and non-keyframe data are compressed respectively to obtain keyframe files and non-keyframe files. In response to receiving a request to play the security video data, based on the timestamp index table and the inter-frame dependency table, the key frame file and the non-key frame file are decoded and read according to the request information to obtain the target security video data. The target security video data is sent to a playback client for playback on the playback client.

[0006] Furthermore, the encoding process of the security video data to determine the keyframe data and non-keyframe data corresponding to the security video data includes: For multiple video frames in the security video data, the video frame storing complete image data is determined as the key frame corresponding to the security video data, so as to determine the key frame data corresponding to the security video data; Video frames other than keyframe data in the security video data are identified as non-keyframe data; wherein, the non-keyframe data includes forward prediction frame data and bidirectional prediction frame data.

[0007] Furthermore, the security video data is encoded using the following steps to obtain the forward prediction frame data: For each forward prediction frame in the security video data, based on the first motion vector stored in the forward prediction frame and the key frame data located in the previous key frame of the forward prediction frame, the target matching block corresponding to the forward prediction frame and the first reference frame matching block corresponding to the previous key frame are located according to the offset of the first motion vector. Perform residual inverse processing on the first target matching block to obtain the first original residual pixel data corresponding to the forward prediction frame; The pixel value of the first reference frame matching block is added to the first original residual pixel data to obtain the pixel value of the first target matching block corresponding to the forward prediction frame; Based on the pixel values ​​of the first target matching block, the first target matching block corresponding to each forward prediction frame is concatenated to obtain the forward prediction frame data.

[0008] Furthermore, the security video data is encoded using the following steps to obtain the bidirectional prediction frame data: For multiple bidirectional prediction frames in the security video data, based on the second motion vector stored in the bidirectional prediction frame, the key frame data located in the previous key frame of the bidirectional prediction frame, and the key frame data located in the next key frame of the bidirectional prediction frame, the second target matching block corresponding to the previous key frame and the second reference frame matching block corresponding to the next key frame are located according to the second motion vector. Based on the pixel values ​​of the second target matching block, the pixel values ​​of the second reference frame matching block, and the preset weight coefficients, the target pixel value corresponding to the bidirectional prediction frame is determined. Perform residual inverse processing on the second target matching block to obtain the second original residual pixel data corresponding to the bidirectional prediction frame; The target pixel value is added to the second original residual pixel data to obtain the second target matching block pixel value corresponding to the bidirectional prediction frame; Based on the pixel values ​​of the second target matching block, the second target matching block corresponding to each bidirectional prediction frame is spliced ​​together to obtain the bidirectional prediction frame data.

[0009] Furthermore, the inter-frame dependency table corresponding to the security video data is constructed through the following steps: Based on the non-key frame data corresponding to each non-key frame, the reference key frame and non-key frame timestamps corresponding to each non-key frame are determined respectively. Based on the key frame data corresponding to each reference key frame, determine the key frame timestamp corresponding to that reference key frame. Based on the dependency relationship between each non-key frame and the reference key frame, the timestamp of the non-key frame and the timestamp of the key frame, an inter-frame dependency table corresponding to the security video data is constructed.

[0010] Furthermore, the timestamp index table corresponding to the security video data is constructed through the following steps: Based on the keyframe data, determine the keyframe timestamp and first file offset corresponding to each keyframe in the security video data, and construct a keyframe timestamp index table based on the keyframe timestamp and the first file offset. Based on the non-critical frame data, determine the frame interval duration and second file offset corresponding to each non-critical frame in the security video data, and construct a non-critical frame timestamp index table based on the frame interval duration and the second file offset. The key frame timestamp index table and the non-key frame timestamp index table are integrated to construct the timestamp index table corresponding to the security video data.

[0011] Furthermore, the step of compressing the keyframe data and non-keyframe data separately to obtain keyframe files and non-keyframe files includes: The keyframe data is subjected to directional compression using a preset embedded zero-tree wavelet method to obtain a keyframe file; The non-keyframe data is differentially compressed using a preset context-adaptive binary arithmetic coding method to obtain a non-keyframe file.

[0012] Furthermore, in response to receiving a request to play the security video data, based on the timestamp index table and the inter-frame dependency table, the keyframe file and the non-keyframe file are decoded and read according to the request information to obtain the target security video data, including: In response to receiving a request to play the security video data, the playback method of the security video data is determined based on the request information; When the playback method is keyframe playback, the number of keyframe files to be preloaded and the preload frequency are determined based on the network bandwidth parameters and cache status of the playback client. Based on the timestamp index table, the keyframe file is decoded and read according to the preload quantity and the preload frequency to obtain the target security video data corresponding to the playback mode of the keyframe playback; When the playback mode is full playback, based on the timestamp index table and the inter-frame dependency table, the key frame file and the non-key frame file are decoded and read using a preset parallel dual-channel thread. The keyframe files and non-keyframe files are dynamically spliced ​​together to obtain the target security video data.

[0013] This application embodiment also provides a security video access management device, the access management device comprising: The encoding processing module is used to encode the security video data in response to receiving the security video data, and to determine the key frame data and non-key frame data corresponding to the security video data. The data storage module is used to construct a timestamp index table and an inter-frame dependency table corresponding to the security video data based on the key frame data and the non-key frame data, respectively, and to compress the key frame data and non-key frame data to obtain key frame files and non-key frame files. The file reading module is used to respond to the received request information for playing the security video data, and based on the timestamp index table and the inter-frame dependency table, decode and read the key frame file and the non-key frame file according to the request information to obtain the target security video data. The video playback module is used to send the target security video data to the playback client so that the target security video data can be played on the playback client.

[0014] Furthermore, when the encoding processing module encodes the security video data and determines the keyframe data and non-keyframe data corresponding to the security video data, the encoding processing module is used to: For multiple video frames in the security video data, the video frame storing complete image data is determined as the key frame corresponding to the security video data, so as to determine the key frame data corresponding to the security video data; Video frames other than keyframe data in the security video data are identified as non-keyframe data; wherein, the non-keyframe data includes forward prediction frame data and bidirectional prediction frame data.

[0015] Furthermore, when the encoding processing module encodes the security video data to obtain the forward prediction frame data, the encoding processing module is used to: For each forward prediction frame in the security video data, based on the first motion vector stored in the forward prediction frame and the key frame data located in the previous key frame of the forward prediction frame, the target matching block corresponding to the forward prediction frame and the first reference frame matching block corresponding to the previous key frame are located according to the offset of the first motion vector. Perform residual inverse processing on the first target matching block to obtain the first original residual pixel data corresponding to the forward prediction frame; The pixel value of the first reference frame matching block is added to the first original residual pixel data to obtain the pixel value of the first target matching block corresponding to the forward prediction frame; Based on the pixel values ​​of the first target matching block, the first target matching block corresponding to each forward prediction frame is concatenated to obtain the forward prediction frame data.

[0016] Furthermore, when the encoding processing module encodes the security video data to obtain the bidirectional prediction frame data, the encoding processing module is used to: For multiple bidirectional prediction frames in the security video data, based on the second motion vector stored in the bidirectional prediction frame, the key frame data located in the previous key frame of the bidirectional prediction frame, and the key frame data located in the next key frame of the bidirectional prediction frame, the second target matching block corresponding to the previous key frame and the second reference frame matching block corresponding to the next key frame are located according to the second motion vector. Based on the pixel values ​​of the second target matching block, the pixel values ​​of the second reference frame matching block, and the preset weight coefficients, the target pixel value corresponding to the bidirectional prediction frame is determined. Perform residual inverse processing on the second target matching block to obtain the second original residual pixel data corresponding to the bidirectional prediction frame; The target pixel value is added to the second original residual pixel data to obtain the second target matching block pixel value corresponding to the bidirectional prediction frame; Based on the pixel values ​​of the second target matching block, the second target matching block corresponding to each bidirectional prediction frame is spliced ​​together to obtain the bidirectional prediction frame data.

[0017] Furthermore, when constructing the inter-frame dependency table corresponding to the security video data, the data storage module is used to: Based on the non-key frame data corresponding to each non-key frame, the reference key frame and non-key frame timestamps corresponding to each non-key frame are determined respectively. Based on the key frame data corresponding to each reference key frame, determine the key frame timestamp corresponding to that reference key frame. Based on the dependency relationship between each non-key frame and the reference key frame, the timestamp of the non-key frame and the timestamp of the key frame, an inter-frame dependency table corresponding to the security video data is constructed.

[0018] Furthermore, when constructing the timestamp index table corresponding to the security video data, the data storage module is used for: Based on the keyframe data, determine the keyframe timestamp and first file offset corresponding to each keyframe in the security video data, and construct a keyframe timestamp index table based on the keyframe timestamp and the first file offset. Based on the non-critical frame data, determine the frame interval duration and second file offset corresponding to each non-critical frame in the security video data, and construct a non-critical frame timestamp index table based on the frame interval duration and the second file offset. The key frame timestamp index table and the non-key frame timestamp index table are integrated to construct the timestamp index table corresponding to the security video data.

[0019] Furthermore, when the data storage module compresses the keyframe data and non-keyframe data respectively to obtain keyframe files and non-keyframe files, the data storage module is used to: The keyframe data is subjected to directional compression using a preset embedded zero-tree wavelet method to obtain a keyframe file; The non-keyframe data is differentially compressed using a preset context-adaptive binary arithmetic coding method to obtain a non-keyframe file.

[0020] Furthermore, when the file reading module responds to receiving a request to play the security video data, and decodes and reads the keyframe file and the non-keyframe file according to the request information based on the timestamp index table and the inter-frame dependency table to obtain the target security video data, the file reading module is used to: In response to receiving a request to play the security video data, the playback method of the security video data is determined based on the request information; When the playback method is keyframe playback, the number of keyframe files to be preloaded and the preload frequency are determined based on the network bandwidth parameters and cache status of the playback client. Based on the timestamp index table, the keyframe file is decoded and read according to the preload quantity and the preload frequency to obtain the target security video data corresponding to the playback mode of the keyframe playback; When the playback mode is full playback, based on the timestamp index table and the inter-frame dependency table, the key frame file and the non-key frame file are decoded and read using a preset parallel dual-channel thread. The keyframe files and non-keyframe files are dynamically spliced ​​together to obtain the target security video data.

[0021] This application embodiment also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the security video access management method described above are performed.

[0022] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the security video access management method described above.

[0023] The security video access management method, apparatus, and electronic device provided in this application include: in response to receiving security video data, encoding the security video data to determine keyframe data and non-keyframe data corresponding to the security video data; based on the keyframe data and the non-keyframe data, constructing a timestamp index table and an inter-frame dependency table corresponding to the security video data, and compressing the keyframe data and non-keyframe data respectively to obtain keyframe files and non-keyframe files; in response to receiving a request to play the security video data, decoding and reading the keyframe files and non-keyframe files according to the request information based on the timestamp index table and the inter-frame dependency table to obtain target security video data; and sending the target security video data to a playback client for playback on the playback client.

[0024] Compared to existing technologies that generate a video stream containing keyframes and non-keyframes according to certain encoding rules during video encoding, and then write the entire video stream into a single file in a unified format and chronological order; and that require parsing the entire video file, locating the target frame by timestamp, and relying on the complete file stream for playback or navigation when playing security videos, this new method separates and stores the keyframe and non-keyframe data determined by encoding the security video data into independent files, and constructs a timestamp index table and an inter-frame dependency table. This allows users to read the keyframe and non-keyframe files based on the timestamp index table and inter-frame dependency table when playing security videos, thereby playing the target security video data according to user needs. This improves the access efficiency of keyframes in real-time streaming protocols, reduces the latency of random jumps during video playback, and improves the response speed of video playback while maintaining the compression rate of the stored video.

[0025] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0026] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0027] Figure 1 A flowchart illustrating a method for accessing and managing security videos provided in an embodiment of this application; Figure 2 A schematic diagram of the structure of a security video access management device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0029] Research has revealed that traditional security video storage solutions typically mix keyframes and non-keyframes in a single file. Specifically, during video encoding, a video stream containing keyframes and non-keyframes is generated according to certain encoding rules (e.g., H.264 or H.265). The entire video stream is then written to a single file in a uniform format and in chronological order, with the file header containing a global timestamp index. When playing security videos, the entire video file needs to be parsed, the target frame is located using the timestamp, and playback or navigation is achieved by relying on the complete file stream.

[0030] The mixed storage of keyframes and non-keyframes means that the entire video stream needs to be parsed when the file is read, which reduces the efficiency of reading security video data. In the playback scenario of Real-Time Streaming Protocol (RTSP), the latency of previewing keyframes is high and it consumes more resources. In addition, when randomly jumping to a specified time point during video playback, the entire video file needs to be traversed, resulting in a slow video playback response speed.

[0031] Here, Real-Time Streaming Protocol (RTSP) is a network protocol used to control the transmission of audio and video streams. It is commonly used in scenarios such as IP cameras, video surveillance, and live streaming systems. It does not transmit media data itself, but controls the streaming media server (e.g., start, pause, and stop playback). The actual audio and video data is usually transmitted via RTP or RTCP protocols.

[0032] Based on this, embodiments of this application provide a method for storing and managing security videos. By separating and storing keyframe data and non-keyframe data determined through encoding of security video data into independent files, and constructing a timestamp index table and an inter-frame dependency table, users can read keyframe files and non-keyframe files based on the timestamp index table and the inter-frame dependency table when playing security videos. This allows for the playback of target security video data according to user needs, improving the access efficiency of keyframes in real-time streaming protocols, reducing the latency of random jumps during video playback, and improving the response speed of video playback while ensuring the compression rate of stored video.

[0033] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for accessing and managing security videos provided in an embodiment of this application. Figure 1 As shown in the figure, the security video access management method provided in this application embodiment includes: S101. In response to receiving security video data, the security video data is encoded to determine the key frame data and non-key frame data corresponding to the security video data.

[0034] Here, security video data usually refers to video content collected, transmitted, stored and analyzed by video surveillance systems (such as IPC cameras, NVRs, DVRs, etc.). It is widely used in scenarios such as public safety, traffic management, building security, and industrial inspection. This type of data has the characteristics of high timeliness, long-term continuity, low bit rate compression, and strong structured requirements.

[0035] In this embodiment of the application, the keyframe data is the video data corresponding to the keyframe (Intra-coded frame, I-frame). The keyframe data is the data of the frame that stores the complete image data, including editable instance objects (such as graphics, elements, etc.), which are displayed as solid dots on the timeline and trigger changes in the animation state. For example, key content such as turning points in character actions and scene transitions are defined through keyframes.

[0036] Keyframes are independently encoded frames that do not rely on other frames for decoding, and they only use intra-frame prediction, which means they use the spatial redundancy information within the current frame for compression.

[0037] In this embodiment, the non-keyframe data includes forward prediction frame data and bidirectional prediction frame data. Non-keyframes are displayed as gray squares on the timeline. They are essentially static continuations of keyframes and their content cannot be directly edited.

[0038] Among them, the forward prediction frame data is the video data corresponding to the forward prediction frame (Predictive-coded frame, P frame), which is the difference data between the frame and the previous key frame, and the content of the current frame is predicted through motion compensation.

[0039] Bidirectional predictive frame data is the video data corresponding to a bidirectional predictive-coded frame (B-frame). The bidirectional predictive frame data is the difference data between this frame and the keyframes before and after it. The content of the current frame is predicted through bidirectional motion compensation.

[0040] In one possible implementation of this application, in specific implementation, the step S101 of encoding the security video data and determining the keyframe data and non-keyframe data corresponding to the security video data may include: S1011. For multiple video frames in the security video data, determine the video frame storing complete image data in the video frame as the key frame corresponding to the security video data, so as to determine the key frame data corresponding to the security video data.

[0041] S1012. Determine the video frames in the security video data other than key frame data as non-key frame data.

[0042] Here, the frame type is distinguished by the frame type marking in the video encoding process. During video encoding, key frames are marked as I-frames, forward prediction frames in non-key frames are marked as P-frames, and bidirectional prediction frames in non-key frames are marked as B-frames.

[0043] In one possible implementation of this application, in specific implementation, the step of encoding the security video data in step S1012 to obtain the forward prediction frame data may include: S10121. For each forward prediction frame in the security video data, based on the first motion vector stored in the forward prediction frame and the key frame data located in the previous key frame of the forward prediction frame, locate the first target matching block corresponding to the forward prediction frame and the first reference frame matching block corresponding to the previous key frame according to the offset of the first motion vector.

[0044] Here, the first target matching block is the best matching block corresponding to the forward prediction frame.

[0045] S10122. Perform residual inverse processing on the first target matching block to obtain the first original residual pixel data corresponding to the forward prediction frame.

[0046] Here, the residual inverse processing includes entropy decoding, inverse quantization, and inverse discrete cosine transform, etc.; the first original residual pixel data is the pixel data of the original residual recovered from the first target matching block.

[0047] S10123. Add the pixel value of the first reference frame matching block to the first original residual pixel data to obtain the pixel value of the first target matching block corresponding to the forward prediction frame.

[0048] In this embodiment of the application, the pixel value of the first target matching block corresponding to the forward prediction frame is the sum of the pixel value of the first reference frame matching block and the first original residual pixel data.

[0049] S10124. Based on the pixel value of the first target matching block, the first target matching block corresponding to each forward prediction frame is spliced ​​together to obtain the forward prediction frame data.

[0050] Here, all the first target matching blocks of the forward prediction frame are stitched together to form a complete current image, so as to achieve the same predictive visual effect as the original image.

[0051] In one possible implementation of this application, in specific implementation, the step of encoding the security video data in step S1012 to obtain the bidirectional prediction frame data may include: S10125. For multiple bidirectional prediction frames in the security video data, based on the second motion vector stored in the bidirectional prediction frame, the key frame data located in the previous key frame of the bidirectional prediction frame, and the key frame data located in the next key frame of the bidirectional prediction frame, the second target matching block corresponding to the previous key frame and the second reference frame matching block corresponding to the next key frame are located according to the second motion vector.

[0052] Here, the second target matching block is the best matching block corresponding to the previous keyframe; the second reference frame matching block is the best matching block corresponding to the next keyframe.

[0053] S10126. Based on the pixel value of the second target matching block, the pixel value of the second reference frame matching block, and the preset weight coefficient, determine the target pixel value corresponding to the bidirectional prediction frame.

[0054] In this embodiment of the application, the weighting coefficient is set by the following formula.

[0055] .

[0056] in, Indicates the weighting coefficient; This indicates the timestamp corresponding to the bidirectional prediction frame; Indicates the timestamp corresponding to the previous keyframe; This indicates the timestamp corresponding to the next keyframe.

[0057] In this embodiment of the application, the target pixel value corresponding to the bidirectional prediction frame is determined by the following formula.

[0058] .

[0059] in, This indicates the target pixel value corresponding to the bidirectional prediction frame; This represents the pixel value of the second target matching block; This represents the pixel value of the matching block in the second reference frame; This represents the weighting coefficient.

[0060] S10127. Perform residual inverse processing on the second target matching block to obtain the second original residual pixel data corresponding to the bidirectional prediction frame.

[0061] Here, the residual inverse processing includes entropy decoding, inverse quantization, and inverse discrete cosine transform, etc.; the second original residual pixel data is the pixel data of the original residual recovered from the second target matching block.

[0062] S10128. Add the target pixel value to the second original residual pixel data to obtain the second target matching block pixel value corresponding to the bidirectional prediction frame.

[0063] In this embodiment, the second target matching block pixel value corresponding to the bidirectional prediction frame is the sum of the target pixel value corresponding to the bidirectional prediction frame and the second original residual pixel data.

[0064] S10129. Based on the pixel value of the second target matching block, the second target matching block corresponding to each bidirectional prediction frame is spliced ​​together to obtain the bidirectional prediction frame data.

[0065] Here, all the second target matching blocks of the bidirectional prediction frame are stitched together to form a complete current image, so as to achieve the same predictive visual effect as the original image.

[0066] S102. Based on the key frame data and the non-key frame data, construct the timestamp index table and the inter-frame dependency table corresponding to the security video data, and compress the key frame data and the non-key frame data respectively to obtain key frame files and non-key frame files.

[0067] In this embodiment, the timestamp index table is used to record the position of each video frame on the timeline and its byte offset in the file or video stream, so as to realize time-based video stream switching; the inter-frame dependency table is used to describe the decoding dependency of each video frame, that is, the reference frame that needs to be decoded first when decoding a certain video frame, i.e., the reference relationship between key frames, forward prediction frames and bidirectional prediction frames.

[0068] In one possible implementation of this application, the step of constructing the inter-frame dependency table corresponding to the security video data in step S102 may include: S1021. Based on the non-key frame data corresponding to each non-key frame, determine the reference key frame and non-key frame timestamps corresponding to each non-key frame.

[0069] S1022. Based on the key frame data corresponding to each reference key frame, determine the key frame timestamp corresponding to the reference key frame.

[0070] S1023. Based on the dependency relationship between each non-key frame and the reference key frame, the timestamp of the non-key frame and the timestamp of the key frame, construct the inter-frame dependency table corresponding to the security video data.

[0071] In this embodiment of the application, the inter-frame dependency table may include a metadata file (dep) that records the timestamps of the key frames referenced by each non-key frame generated by the encoder based on security video data, and writes the dependency relationship into the metadata file.

[0072] In one possible implementation of this application, the step of constructing the timestamp index table corresponding to the security video data in step S102 may include: S1024. Based on the key frame data, determine the key frame timestamp and first file offset corresponding to each key frame in the security video data, and construct a key frame timestamp index table based on the key frame timestamp and the first file offset.

[0073] In this embodiment of the application, the keyframe timestamp index table may include a data structure hash table (keyframe timestamp; file offset), the keyframe timestamp index table records the offset of each keyframe in the file, and the keyframe index table is written into the index file.

[0074] S1025. Based on the non-critical frame data, determine the frame interval duration and second file offset corresponding to each non-critical frame in the security video data, and construct a non-critical frame timestamp index table based on the frame interval duration and the second file offset.

[0075] In this embodiment of the application, the non-critical frame timestamp index table may include a data structure interval tree, which records the frame interval duration and file offset corresponding to the non-critical frame. When reading, the non-critical frame timestamp is calculated by the critical frame timestamp and the frame interval duration. That is, the non-critical frame timestamp is equal to the sum of the previous critical frame timestamp and the frame interval duration.

[0076] S1026. Integrate the key frame timestamp index table and the non-key frame timestamp index table to construct the timestamp index table corresponding to the security video data.

[0077] Here, the timestamp index table may include a timestamp index (idx) file.

[0078] In one possible implementation of this application, in specific implementation, the step S102 of compressing the keyframe data and non-keyframe data respectively to obtain keyframe files and non-keyframe files may include: S1027. The keyframe data is subjected to directional compression processing using a preset embedded zero-tree wavelet method to obtain a keyframe file.

[0079] In this step, in practice, firstly, the keyframe data is decomposed into low-frequency and high-frequency subbands through multi-level wavelet decomposition. Then, lossless compression (e.g., using Huffman coding) is applied to the low-frequency subbands to preserve the main structure of the image. Afterward, lossy compression (quantization and arithmetic coding) is applied to the high-frequency subbands to remove visual redundancy. Finally, the compressed subband data are merged to generate a keyframe file with a high compression ratio range (e.g., 10:1 to 20:1).

[0080] S1028. The non-keyframe data is differentially compressed using a preset context-adaptive binary arithmetic coding method to obtain a non-keyframe file.

[0081] In this step, in specific implementation, firstly, the non-keyframe data is divided into blocks, and the best matching block with the reference keyframe is found through motion estimation; then, the residual data between the current block and the reference block (i.e., motion compensation differential) is calculated; then, the residual data is subjected to DCT transformation to remove spatial redundancy; finally, the DCT coefficients are quantized and entropy encoded to generate a differential compressed file, i.e., a non-keyframe file. For example, the compression ratio of the non-keyframe file ranges from 50:1 to 100:1.

[0082] The residual data between the current block and the reference block is calculated through the following steps: First, the image of non-keyframe data is divided into fixed blocks, for example, 8x8 pixels; then, motion estimation and matching are performed to determine the best matching block, that is, by calculating the absolute error and SAD, the smaller the value, the higher the matching degree, and the position of the reference block is recorded as a motion vector. The SAD is calculated by summing the difference between the pixel value of the current block and the pixel value of the reference block; then, the residual value is calculated pixel by pixel for the best matching block between the current block and the reference frame, and the calculation method is: the residual pixel value is equal to the difference between the pixel value of the current block and the pixel value of the matching block.

[0083] S103. In response to receiving the request information for playing the security video data, based on the timestamp index table and the inter-frame dependency table, decode and read the key frame file and the non-key frame file according to the request information to obtain the target security video data.

[0084] In this embodiment of the application, the requirement information includes the playback method of security video data; wherein, the playback method includes, but is not limited to, keyframe playback and full playback.

[0085] At the real-time streaming protocol level, when the playback client needs to quickly browse video content (i.e., when the playback mode is keyframe playback), it only requests keyframe files from the server. The server only sends keyframe data, and the client generates a brief video preview based on the keyframe data. When the playback client needs to view the complete video details (i.e., when the playback mode is full playback), it requests both keyframe files and non-keyframe files. The server reads and merges the two types of file data using a dual-channel parallel reading mechanism, splices them together to form a complete video stream, and then sends it to the playback client for playback.

[0086] In one possible implementation of this application, step S103 may include: S1031. In response to receiving a request for playing the security video data, determine the playback method of the security video data based on the request information.

[0087] The playback methods include, but are not limited to, keyframe playback and full playback.

[0088] S1032. When the playback mode is keyframe playback, the number of preloaded frames and the preload frequency of the keyframe file are determined based on the network bandwidth parameters and cache status of the playback client.

[0089] Here, an adaptive caching algorithm is used to dynamically adjust the number and frequency of keyframes to be preloaded based on network bandwidth and the caching status of the playback client.

[0090] Specifically, when network bandwidth is sufficient, the number of keyframes preloaded is increased to cache more keyframe data in advance, thereby improving the efficiency of previewing and random access; when network bandwidth is limited, the number of keyframes preloaded is reduced to avoid network congestion caused by excessive data transmission.

[0091] In this step, firstly, parameters such as network bandwidth, cache hit rate, and playback progress metrics of the playback client are collected in real time; then, in scenarios with high bandwidth greater than or equal to 500Mbps, the next 4 keyframes are preloaded to reduce playback stuttering; in scenarios with low bandwidth less than or equal to 100Mbps, only the current keyframe is preloaded to prioritize smoothness; finally, the cache replacement rules of the LFU-Age hybrid strategy are used to eliminate keyframes with low access frequency and older age, so as to dynamically adjust the number and frequency of keyframes preloaded.

[0092] S1033. Based on the timestamp index table, decode and read the keyframe file according to the preload quantity and the preload frequency to obtain the target security video data corresponding to the playback mode of the keyframe playback.

[0093] In this step, a preset keyframe thread is used to read keyframe data from the keyframe file in timestamp order and load the corresponding timestamp index table into memory to obtain the target security video data corresponding to the keyframe playback mode.

[0094] S1034. When the playback mode is full playback, based on the timestamp index table and the inter-frame dependency table, the key frame file and the non-key frame file are decoded and read using a preset parallel dual-channel thread.

[0095] In this step, two threads are started during the reading phase: a pre-defined keyframe thread and a non-keyframe thread. First, the keyframe thread is responsible for reading keyframe data from the keyframe file in timestamp order and loading the corresponding timestamp index table into memory. Then, the non-keyframe thread is responsible for finding the non-keyframe data timestamp and file position corresponding to the keyframe timestamp from the timestamp index table of the non-keyframe file according to the timestamp range provided by the keyframe thread, and reading the corresponding forward prediction frame data and bidirectional prediction frame data from the non-keyframe file. Finally, the keyframe thread and the non-keyframe thread use condition variables synchronously. That is, after reading a keyframe, the keyframe thread notifies the non-keyframe thread to start reading non-keyframes through condition variables, and uses semaphores to control the access of the two threads to the shared buffer (i.e., the frame splicing queue).

[0096] Here, the inter-frame dependency table is used to solve playback abnormalities caused by the loss of non-key frames. Specifically, the inter-frame dependency table (IDT) is a data structure used to record the encoding dependencies between video frames, clarifying which key frames or other non-key frames each non-key frame needs to refer to during decoding.

[0097] The inter-frame dependency table is loaded into memory during the reading phase; the decoding order constraint of the inter-frame dependency table is to ensure that the dependent frame is decoded before the dependent frame; when a key frame is lost, interpolation between the previous and next key frames is used; when a forward prediction frame is lost, the previous frame is used as a substitute; and when a bidirectional prediction frame is lost, it is skipped directly.

[0098] S1035. Dynamically stitch the keyframe file and the non-keyframe file together to obtain the target security video data.

[0099] In this step, the key frame timestamp index table file is first loaded into memory; then, the non-key frame timestamp index table is loaded into memory; finally, a preset video frame merging thread is used to dynamically stitch together key frames and non-key frames with the same timestamp in the shared buffer according to the key frame timestamp index table to restore the complete video frame group and obtain the target security video data.

[0100] Here, if file corruption is detected, the file read error handling adopts an exponential backoff retry mechanism. For example, the first error will wait for 100ms, and the waiting time will double for each subsequent error (100ms, 200ms, 400ms). The maximum number of retries is 3. If there are 3 errors, the current file reading will be stopped and notified by the log or alarm.

[0101] S104. The target security video data is sent to the playback client so that the target security video data can be played on the playback client.

[0102] In this embodiment, by physically isolating key data and incremental data, the access efficiency of key frames in the streaming playback of the real-time streaming protocol is improved, and the random jump latency is reduced, thereby improving the access efficiency of video data; the compression rate is maintained in accordance with traditional storage solutions, while reducing the amount of data parsing during reading, thus reducing CPU and bandwidth usage; and a low-latency keyframe preview mode and fast random access are supported, making it particularly suitable for scenarios such as fast event retrieval and multi-channel parallel preview in security monitoring, significantly improving the efficiency of video data analysis.

[0103] The security video access management method provided in this application separates and stores key frame data and non-key frame data determined by encoding security video data into independent files, and constructs a timestamp index table and an inter-frame dependency table. This allows users to read key frame files and non-key frame files based on the timestamp index table and the inter-frame dependency table when playing security videos, so as to play the target security video data according to user needs. This improves the access efficiency of key frames in real-time streaming protocol streaming playback, reduces the latency of random jumps during video playback, and improves the response speed of video playback while ensuring the compression rate of stored video.

[0104] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of a security video access management device provided in an embodiment of this application. Figure 2 As shown, the access management device 200 includes: Encoding processing module 210 is used to encode security video data in response to receiving security video data, and to determine key frame data and non-key frame data corresponding to the security video data; Data storage module 220 is used to construct a timestamp index table and an inter-frame dependency table corresponding to the security video data based on the key frame data and the non-key frame data, respectively, and to compress the key frame data and non-key frame data to obtain key frame files and non-key frame files; The file reading module 230 is used to respond to receiving a request to play the security video data, and based on the timestamp index table and the inter-frame dependency table, decode and read the key frame file and the non-key frame file according to the request information to obtain the target security video data. The video playback module 240 is used to send the target security video data to the playback client so as to play the target security video data on the playback client.

[0105] Furthermore, when the encoding processing module 210 performs encoding processing on the security video data and determines the keyframe data and non-keyframe data corresponding to the security video data, the encoding processing module 210 is used to: For multiple video frames in the security video data, the video frame storing complete image data is determined as the key frame corresponding to the security video data, so as to determine the key frame data corresponding to the security video data; Video frames other than keyframe data in the security video data are identified as non-keyframe data; wherein, the non-keyframe data includes forward prediction frame data and bidirectional prediction frame data.

[0106] Furthermore, when the encoding processing module 210 encodes the security video data to obtain the forward prediction frame data, the encoding processing module 210 is used to: For each forward prediction frame in the security video data, based on the first motion vector stored in the forward prediction frame and the key frame data located in the previous key frame of the forward prediction frame, the target matching block corresponding to the forward prediction frame and the first reference frame matching block corresponding to the previous key frame are located according to the offset of the first motion vector. Perform residual inverse processing on the first target matching block to obtain the first original residual pixel data corresponding to the forward prediction frame; The pixel value of the first reference frame matching block is added to the first original residual pixel data to obtain the pixel value of the first target matching block corresponding to the forward prediction frame; Based on the pixel values ​​of the first target matching block, the first target matching block corresponding to each forward prediction frame is concatenated to obtain the forward prediction frame data.

[0107] Furthermore, when the encoding processing module 210 encodes the security video data to obtain the bidirectional prediction frame data, the encoding processing module 210 is used to: For multiple bidirectional prediction frames in the security video data, based on the second motion vector stored in the bidirectional prediction frame, the key frame data located in the previous key frame of the bidirectional prediction frame, and the key frame data located in the next key frame of the bidirectional prediction frame, the second target matching block corresponding to the previous key frame and the second reference frame matching block corresponding to the next key frame are located according to the second motion vector. Based on the pixel values ​​of the second target matching block, the pixel values ​​of the second reference frame matching block, and the preset weight coefficients, the target pixel value corresponding to the bidirectional prediction frame is determined. Perform residual inverse processing on the second target matching block to obtain the second original residual pixel data corresponding to the bidirectional prediction frame; The target pixel value is added to the second original residual pixel data to obtain the second target matching block pixel value corresponding to the bidirectional prediction frame; Based on the pixel values ​​of the second target matching block, the second target matching block corresponding to each bidirectional prediction frame is spliced ​​together to obtain the bidirectional prediction frame data.

[0108] Furthermore, when constructing the inter-frame dependency table corresponding to the security video data, the data storage module 220 is used to: Based on the non-key frame data corresponding to each non-key frame, the reference key frame and non-key frame timestamps corresponding to each non-key frame are determined respectively. Based on the key frame data corresponding to each reference key frame, determine the key frame timestamp corresponding to that reference key frame. Based on the dependency relationship between each non-key frame and the reference key frame, the timestamp of the non-key frame and the timestamp of the key frame, an inter-frame dependency table corresponding to the security video data is constructed.

[0109] Furthermore, when constructing the timestamp index table corresponding to the security video data, the data storage module 220 is used to: Based on the keyframe data, determine the keyframe timestamp and first file offset corresponding to each keyframe in the security video data, and construct a keyframe timestamp index table based on the keyframe timestamp and the first file offset. Based on the non-critical frame data, determine the frame interval duration and second file offset corresponding to each non-critical frame in the security video data, and construct a non-critical frame timestamp index table based on the frame interval duration and the second file offset. The key frame timestamp index table and the non-key frame timestamp index table are integrated to construct the timestamp index table corresponding to the security video data.

[0110] Furthermore, when the data storage module 220 compresses the keyframe data and non-keyframe data respectively to obtain keyframe files and non-keyframe files, the data storage module 220 is used to: The keyframe data is subjected to directional compression using a preset embedded zero-tree wavelet method to obtain a keyframe file; The non-keyframe data is differentially compressed using a preset context-adaptive binary arithmetic coding method to obtain a non-keyframe file.

[0111] Furthermore, when the file reading module 230, in response to receiving a request to play the security video data, decodes and reads the keyframe file and the non-keyframe file according to the request information based on the timestamp index table and the inter-frame dependency table to obtain the target security video data, the file reading module 230 is used to: In response to receiving a request to play the security video data, the playback method of the security video data is determined based on the request information; When the playback method is keyframe playback, the number of keyframe files to be preloaded and the preload frequency are determined based on the network bandwidth parameters and cache status of the playback client. Based on the timestamp index table, the keyframe file is decoded and read according to the preload quantity and the preload frequency to obtain the target security video data corresponding to the playback mode of the keyframe playback; When the playback mode is full playback, based on the timestamp index table and the inter-frame dependency table, the key frame file and the non-key frame file are decoded and read using a preset parallel dual-channel thread. The keyframe files and non-keyframe files are dynamically spliced ​​together to obtain the target security video data.

[0112] The security video storage and management device provided in this application separates and stores key frame data and non-key frame data determined by encoding security video data into independent files, and constructs a timestamp index table and an inter-frame dependency table. This allows users to read key frame files and non-key frame files based on the timestamp index table and the inter-frame dependency table when playing security videos, so as to play the target security video data according to user needs. This improves the access efficiency of key frames in real-time streaming protocol streaming playback, reduces the latency of random jumps during video playback, and improves the response speed of video playback while ensuring the compression rate of stored video.

[0113] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 300 includes a processor 310, a memory 320, and a bus 330.

[0114] The memory 320 stores machine-readable instructions executable by the processor 310. When the electronic device 300 is running, the processor 310 and the memory 320 communicate via the bus 330. When the machine-readable instructions are executed by the processor 310, they can perform the operations described above. Figure 1 The steps of the security video access management method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

[0115] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The steps of the security video access management method in the method embodiment shown are described in detail in the method embodiment, and will not be repeated here.

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

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

[0118] 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.

[0119] In addition, the functional units in the various embodiments of this application 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.

[0120] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, 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 application. 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.

[0121] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for storing and managing security videos, characterized in that, The access management method includes: In response to receiving security video data, the security video data is encoded to determine the key frame data and non-key frame data corresponding to the security video data; Based on the keyframe data and the non-keyframe data, a timestamp index table and an inter-frame dependency table corresponding to the security video data are constructed respectively, and the keyframe data and non-keyframe data are compressed respectively to obtain keyframe files and non-keyframe files. In response to receiving a request to play the security video data, based on the timestamp index table and the inter-frame dependency table, the key frame file and the non-key frame file are decoded and read according to the request information to obtain the target security video data. The target security video data is sent to a playback client for playback on the playback client.

2. The method according to claim 1, characterized in that, The process of encoding the security video data to determine the keyframe data and non-keyframe data corresponding to the security video data includes: For multiple video frames in the security video data, the video frame storing complete image data is determined as the key frame corresponding to the security video data, so as to determine the key frame data corresponding to the security video data; Video frames other than keyframe data in the security video data are identified as non-keyframe data; wherein, the non-keyframe data includes forward prediction frame data and bidirectional prediction frame data.

3. The method according to claim 2, characterized in that, The security video data is encoded using the following steps to obtain the forward prediction frame data: For each forward prediction frame in the security video data, based on the first motion vector stored in the forward prediction frame and the key frame data located in the previous key frame of the forward prediction frame, the target matching block corresponding to the forward prediction frame and the first reference frame matching block corresponding to the previous key frame are located according to the offset of the first motion vector. Perform residual inverse processing on the first target matching block to obtain the first original residual pixel data corresponding to the forward prediction frame; The pixel value of the first reference frame matching block is added to the first original residual pixel data to obtain the pixel value of the first target matching block corresponding to the forward prediction frame; Based on the pixel values ​​of the first target matching block, the first target matching block corresponding to each forward prediction frame is concatenated to obtain the forward prediction frame data.

4. The method according to claim 2, characterized in that, The security video data is encoded using the following steps to obtain the bidirectional prediction frame data: For multiple bidirectional prediction frames in the security video data, based on the second motion vector stored in the bidirectional prediction frame, the key frame data located in the previous key frame of the bidirectional prediction frame, and the key frame data located in the next key frame of the bidirectional prediction frame, the second target matching block corresponding to the previous key frame and the second reference frame matching block corresponding to the next key frame are located according to the second motion vector. Based on the pixel values ​​of the second target matching block, the pixel values ​​of the second reference frame matching block, and the preset weight coefficients, the target pixel value corresponding to the bidirectional prediction frame is determined. Perform residual inverse processing on the second target matching block to obtain the second original residual pixel data corresponding to the bidirectional prediction frame; The target pixel value is added to the second original residual pixel data to obtain the second target matching block pixel value corresponding to the bidirectional prediction frame; Based on the pixel values ​​of the second target matching block, the second target matching block corresponding to each bidirectional prediction frame is spliced ​​together to obtain the bidirectional prediction frame data.

5. The method according to claim 1, characterized in that, The inter-frame dependency table corresponding to the security video data is constructed through the following steps: Based on the non-key frame data corresponding to each non-key frame, the reference key frame and non-key frame timestamps corresponding to each non-key frame are determined respectively. Based on the key frame data corresponding to each reference key frame, determine the key frame timestamp corresponding to that reference key frame. Based on the dependency relationship between each non-key frame and the reference key frame, the timestamp of the non-key frame and the timestamp of the key frame, an inter-frame dependency table corresponding to the security video data is constructed.

6. The method according to claim 1, characterized in that, The timestamp index table corresponding to the security video data is constructed through the following steps: Based on the keyframe data, determine the keyframe timestamp and first file offset corresponding to each keyframe in the security video data, and construct a keyframe timestamp index table based on the keyframe timestamp and the first file offset. Based on the non-critical frame data, determine the frame interval duration and second file offset corresponding to each non-critical frame in the security video data, and construct a non-critical frame timestamp index table based on the frame interval duration and the second file offset. The key frame timestamp index table and the non-key frame timestamp index table are integrated to construct the timestamp index table corresponding to the security video data.

7. The method according to claim 1, characterized in that, The step of compressing the keyframe data and non-keyframe data separately to obtain keyframe files and non-keyframe files includes: The keyframe data is subjected to directional compression using a preset embedded zero-tree wavelet method to obtain a keyframe file; The non-keyframe data is differentially compressed using a preset context-adaptive binary arithmetic coding method to obtain a non-keyframe file.

8. The method according to claim 1, characterized in that, In response to receiving a request to play the security video data, the system decodes and reads the keyframe file and the non-keyframe file according to the request information based on the timestamp index table and the inter-frame dependency table to obtain the target security video data, including: In response to receiving a request to play the security video data, the playback method of the security video data is determined based on the request information; When the playback method is keyframe playback, the number of keyframe files to be preloaded and the preload frequency are determined based on the network bandwidth parameters and cache status of the playback client. Based on the timestamp index table, the keyframe file is decoded and read according to the preload quantity and the preload frequency to obtain the target security video data corresponding to the playback mode of the keyframe playback; When the playback mode is full playback, based on the timestamp index table and the inter-frame dependency table, the key frame file and the non-key frame file are decoded and read using a preset parallel dual-channel thread. The keyframe files and non-keyframe files are dynamically spliced ​​together to obtain the target security video data.

9. A security video storage and management device, characterized in that, The access management device includes: The encoding processing module is used to encode the security video data in response to receiving the security video data, and to determine the key frame data and non-key frame data corresponding to the security video data. The data storage module is used to construct a timestamp index table and an inter-frame dependency table corresponding to the security video data based on the key frame data and the non-key frame data, respectively, and to compress the key frame data and non-key frame data to obtain key frame files and non-key frame files. The file reading module is used to respond to the received request information for playing the security video data, and based on the timestamp index table and the inter-frame dependency table, decode and read the key frame file and the non-key frame file according to the request information to obtain the target security video data. The video playback module is used to send the target security video data to the playback client so that the target security video data can be played on the playback client.

10. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the security video access management method as described in any one of claims 1 to 8.

Images