A video storage and accurate positioning playing method and device

Abstract

The application provides a video storage and accurate positioning playing method, which can solve the problems of high storage space occupation caused by high video storage code rate and high fixed-point playing delay after increasing I frame interval, and comprises the following steps: performing GOP encoding on video data, and setting I frame interval to be greater than 1 second; extracting I frame information from the encoded video stream to generate an independent I frame index file; performing associated storage; an RTSP server receives a playing request of a client and extracts a target timestamp; querying the I frame index file to locate the nearest target I frame; for a video frame with a display timestamp less than the target timestamp, the display timestamp and the decoding timestamp of the corresponding video frame are remapped to a value less than and close to the target timestamp, and the frame display duration of the corresponding video frame is set to 0; the processed video data is transmitted to the client, and the client skips the video frame with the frame display duration of 0 and starts playing from the video frame corresponding to the target timestamp.

Description

Technical Field

[0001] This invention relates to the field of video surveillance and streaming media transmission technology, specifically to a video storage and precise positioning playback method and device, which is particularly suitable for video storage and playback based on H.264 / H.265 encoding standards and RTSP / RTP in urban rail transit vehicle-mounted video surveillance scenarios. Background Technology

[0002] In the urban rail transit sector, onboard video surveillance systems are core supporting facilities for ensuring driving safety, tracing operational events, and standardizing work processes. The storage, playback, and remote retrieval of surveillance footage have become essential technical means for daily maintenance and accident evidence collection. Currently, the industry commonly uses H.264 and H.265 video coding standards for audio and video compression and storage. Both H.264 and H.265 are video coding standards based on a Group of Pictures (GOP) structure. I-frames are intra-coded frames, which can be independently decoded and completely saved without relying on other frames; P-frames are forward predictive coded frames, relying on the previous I-frame or P-frame as a reference frame for decoding.

[0003] Onboard monitoring equipment requires 24 / 7 uninterrupted acquisition of multiple high-definition video streams. A single train typically deploys 20-40 onboard cameras. When using the traditional fixed image group encoding scheme of one frame per second for encoding and storage, the overall video bitrate remains consistently high. A single train can generate 50-80GB of monitoring video data daily. For a line with 20 operating trains, the total daily increase in video data can exceed 1TB. With the continuous rise in storage hard drive hardware prices, the massive amount of video data directly leads to a year-on-year increase in hardware procurement costs, significantly increasing the operating costs of rail transit operators.

[0004] To reduce storage pressure, some manufacturers have lowered the bitrate and reduced storage size by adjusting the image group structure and increasing the I-frame interval. However, increasing the I-frame interval introduces new problems. Video storage servers need to provide streaming media forwarding functionality to support remote playback of recorded files by clients. During playback, when the user drags the progress bar to a specific position, due to the characteristics of video encoding and decoding, the player must wait for the I-frame to appear before it can begin decoding and playback. An I-frame can be decoded independently and the image is completely preserved, while P-frames depend on a reference frame. For example, if the user drags the progress bar to the 10th second, and there is no I-frame at that 10-second mark, the player must wait for the I-frame at the 15th second to begin decoding and playback, resulting in video playback delay and impacting user experience. With large I-frame intervals, this waiting process can last up to approximately 20 seconds, severely affecting the real-time performance of video playback. Summary of the Invention

[0005] To address the aforementioned problems, this invention provides a video storage and precise positioning playback method that can solve the problems of high video storage bitrate leading to large storage space occupation and high fixed-point playback delay after increasing the I-frame interval in the prior art, and has good terminal compatibility.

[0006] The technical solution is as follows: a video storage and precise positioning playback method, comprising the following steps: Step 1: Use H.264 or H.265 encoding standards to perform GOP encoding on the video data captured by the camera, set the I-frame interval to be greater than 1 second, and obtain the video file; Step 2: Extract I-frame information from the encoded video stream and generate an I-frame index file independent of the video file. The I-frame index file records at least the display timestamp, decoding timestamp, byte offset in the video file, and frame data size of each I-frame. Step 3: Associate and store the video file with the corresponding I-frame index file; Step 4: The RTSP server receives the client's playback request and extracts the target timestamp from the playback request; Step 5: Query the I-frame index file, locate the nearest target I-frame before the target timestamp, and obtain the byte offset of the target I-frame; Step 6: Starting from the located target I-frame, read video frame data. For video frames whose display timestamp is less than the target timestamp, remap the display timestamp and decoding timestamp of the corresponding video frame to values ​​that are less than and close to the target timestamp, and set the frame display duration of the corresponding video frame to 0. For video frames whose display timestamp is greater than or equal to the target timestamp, keep the original timestamp unchanged. Step 7: Encapsulate the processed video frames into RTP data packets and transmit them to the client, so that the client skips video frames with a duration of 0 and starts playing from the video frame corresponding to the target timestamp.

[0007] Furthermore, the I-frame index file also records the image group number to which each I-frame belongs; the I-frame index file is arranged in ascending order of display timestamps and stored using a structure that supports binary search; in step 5, the nearest target I-frame before the target timestamp is located by binary search.

[0008] Furthermore, in step 6, video frames with display timestamps smaller than the target timestamp are remapped using the following formula: PTS 调整后 =T target -ε×N; Among them, PTS 调整后 T is the remapped display timestamp. targetThe target timestamp is ε, where ε is a small time offset and N is the number of remaining frames between the current frame and the target frame; the decoding timestamp after remapping the corresponding video frame is the same as the display timestamp after remapping.

[0009] Furthermore, the minute time offset ε is set to 1 millisecond; the product of ε and N is less than the difference between the target timestamp and the display timestamp of the located I-frame, so that the display timestamps of each video frame after remapping increase sequentially, and the display timestamps of each video frame after remapping are all greater than the display timestamp of the located I-frame and all less than the target timestamp.

[0010] Furthermore, audio frames are processed simultaneously while reading video frame data: when the display timestamp of the corresponding video frame is less than the target timestamp, the corresponding audio frame is skipped and not transmitted; when the display timestamp of the corresponding video frame is greater than or equal to the target timestamp, the corresponding audio frame is read and transmitted to the client.

[0011] Furthermore, the timestamp remapping in step 6 only changes the display timestamp, decoding timestamp, and frame display duration of the video frame, while keeping the original encoded data and image group structure unchanged; the client includes a player that supports the standard RTSP and RTP protocols, and no adaptation or modification is required.

[0012] Furthermore, in step 1, the I-frame interval is set to be greater than or equal to 5 seconds.

[0013] Furthermore, the I-frame index file is stored in JSON or binary format; the I-frame index file is associated with the corresponding video file using a unified naming rule and storage path; the I-frame index file is generated synchronously during the recording file writing process; after confirming that the data of an I-frame has been written to the recording file, the corresponding index entry is written to the I-frame index file.

[0014] Furthermore, the video stream contains only two types of video frames: I-frames and P-frames, where P-frames rely on the previous I-frame or P-frame as a reference frame for decoding.

[0015] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the video storage and precise positioning playback method described above.

[0016] A computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the video storage and precise positioning playback method described above.

[0017] A computer program product includes a computer program / instructions, characterized in that the computer program / instructions, when executed by a processor, implement the steps of the above-described method.

[0018] Compared with the prior art, the advantages of the present invention are as follows: This invention reduces video bitrate by increasing the I-frame interval. By increasing the I-frame interval from the traditional 1 second to 5 seconds, 10 seconds, or even 20 seconds, the bitrate and storage volume can be significantly reduced while meeting the image quality standards for rail transit monitoring and evidence collection. The reduction in storage costs is particularly significant for scenarios where urban rail transit generates terabytes of video data daily. This invention, by utilizing an independent I-frame index file and a binary search algorithm, can locate the nearest I-frame before the target timestamp within milliseconds, avoiding the time-consuming operation of directly traversing the entire video file for frame searching. Furthermore, by combining timestamp remapping with setting the display duration of video frames before the target frame to 0, the client can instantly skip these frames, completely solving the problem of high latency in fixed-point playback after increasing the I-frame interval, enabling millisecond-level jump playback. Timestamp remapping only adjusts the frame's timestamp metadata at the RTSP transmission layer, without modifying the original encoded data in the video file or changing the GOP structure, thus ensuring the integrity and original availability of the stored data. This invention enables any player conforming to the standard RTSP protocol to achieve precise positioning and playback by remapping frame timestamps, without requiring special customization or adaptation of the client. This significantly reduces system deployment and maintenance costs. This invention is suitable for multi-camera, all-weather vehicle monitoring scenarios in rail transit and can be smoothly integrated into existing vehicle video monitoring systems. Attached Figure Description

[0019] Figure 1 This is a schematic diagram illustrating the steps of the video storage and precise positioning playback method according to an embodiment of the present invention; Figure 2 This is a comparative diagram of frame timestamp adjustment before and after in an embodiment of the present invention; Figure 3 This is a schematic diagram of the data structure of the I-frame index file in an embodiment of the present invention; Figure 4 This is a schematic diagram of system deployment according to an embodiment of the present invention; Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0020] This embodiment applies to scenarios where the video stream does not contain B-frames, i.e., the video stream consists only of I-frames and P-frames. In real-time recording scenarios for vehicle monitoring, B-frames are usually disabled to reduce encoding latency, so the example is given for a scenario without B-frames.

[0021] See Figure 1 The present invention provides a video storage and precise positioning playback method, which includes at least the following steps: Step 1: Use H.264 or H.265 encoding standards to perform GOP encoding on the video data captured by the camera, set the I-frame interval to be greater than 1 second, and obtain the video file; Step 2: Extract I-frame information from the encoded video stream and generate an I-frame index file independent of the video file. The I-frame index file records at least the display timestamp, decoding timestamp, byte offset in the video file, and frame data size of each I-frame. Step 3: Associate and store the video file with the corresponding I-frame index file; Step 4: The RTSP server receives the client's playback request and extracts the target timestamp from the playback request; Step 5: Query the I-frame index file, locate the nearest target I-frame before the target timestamp, and obtain the byte offset of the target I-frame; Step 6: Starting from the located target I-frame, read video frame data. For video frames whose display timestamp is less than the target timestamp, remap the display timestamp and decoding timestamp of the corresponding video frame to values ​​that are less than and close to the target timestamp, and set the frame display duration of the corresponding video frame to 0. For video frames whose display timestamp is greater than or equal to the target timestamp, keep the original timestamp unchanged. Step 7: Encapsulate the processed video frames into RTP data packets and transmit them to the client, so that the client skips video frames with a duration of 0 and starts playing from the video frame corresponding to the target timestamp.

[0022] Specifically, in one embodiment of the present invention, the method of this embodiment is implemented in a system, including multiple vehicle-mounted cameras for collecting video data inside the vehicle compartment, supporting high-definition resolution recording such as 1080P; using H.264 or H.265 encoding standards to perform GOP encoding on the collected video data; extracting I-frame information from the encoded video stream and generating an I-frame index file; associating and storing the video file with the I-frame index file; the RTSP server receiving the client's playback request, querying the index to locate the target I-frame, performing timestamp remapping on intermediate video frames and encapsulating RTP data packets; and the client player receiving the RTP data packets and decoding and playing them according to the standard protocol.

[0023] The following is combined with Figure 1 The overall process is described, with each step of the method explained in detail.

[0024] In step 1, the vehicle-mounted camera acquires video data from inside the vehicle compartment, performs GOP encoding on the video data using the H.264 or H.265 encoding standard, and sets the I-frame interval to be greater than 1 second. In this embodiment, the I-frame interval is set to 5 seconds. Compared to the traditional scheme of generating one I-frame per second, increasing the I-frame interval reduces the number of I-frames per unit time, increases the proportion of P-frames, and consequently reduces the overall bitrate and storage size of the video stream, resulting in a smaller video file. It should be noted that the larger the I-frame interval, the more significant the decrease in bitrate, but the greater the time span between adjacent independently decodeable points; this embodiment selects 5 seconds, balancing storage benefits with the overhead of subsequent positioning processing under the image quality requirements of in-vehicle high-definition monitoring.

[0025] In step 2 of this embodiment, the frame type is identified frame by frame from the encoded video stream, and key information of all I-frames is extracted, including the display timestamp, decoding timestamp, byte offset in the video file, frame data size, and the image group number to which each I-frame belongs. The display timestamp is used for time positioning during playback, the byte offset is used to directly locate the starting position of the I-frame data in the video file, the frame data size is used to determine the reading range, and the image group number is used to identify the image group led by the I-frame.

[0026] In step 2 of this embodiment, the extracted I-frame information is organized into a structured I-frame index file, which is stored separately from the video file; see also Figure 3 The I-frame index file is saved with the extension .idx and consists of two parts: a header area and an entry area. The header area records the frame rate and total number of frames N of the video stream. The entry area arranges the index entries of each I-frame in ascending order of display timestamp. Each entry records the display timestamp, decoding timestamp, file offset, frame data size, and image group number of an I-frame. Figure 3For example, the first I-frame entry has a display timestamp of 0 milliseconds, a decoding timestamp of 0 milliseconds, a file offset of 1024 bytes, a frame data size of 102400 bytes, and an image group number of 0; the second I-frame entry has a display timestamp of 5000 milliseconds, a decoding timestamp of 5000 milliseconds, a file offset of 524288 bytes, a frame data size of 102400 bytes, and an image group number of 1. Given the 5000 millisecond difference in display timestamps between the two adjacent I-frame entries, the I-frame interval in this embodiment is 5 seconds. Since the entry area is arranged in ascending order of display timestamps, the I-frame index file supports binary search, enabling keyframe retrieval to be completed within milliseconds. The frame rate and total number of frames recorded in the header area play an auxiliary role in playback positioning: the frame rate can be used to convert the target timestamp in milliseconds into a frame number and estimate the number of frames to be traversed, providing parameter references for subsequent timestamp remapping; it can also be used to perform integrity verification on the I-frame index file based on the total number of frames. When the frame distribution recorded in the entry area is inconsistent with the total number of frames declared in the header area, it is determined that the index file may be corrupted and reconstruction is triggered to avoid positioning failure due to missing or misaligned indexes; the header metadata enables the index file to have self-description and verification capabilities, which can improve the reliability in large-scale video recording management scenarios.

[0027] In this embodiment, the index generation and video recording writing in step 2 are performed simultaneously. During the process of writing data to the video file, the frame type of the currently written data is determined in real time. Whenever it is confirmed that the data of an I-frame has been written to the video file, the index entry corresponding to that I-frame is appended to the I-frame index file. The method of building the index while recording in this embodiment does not require a second traversal of the video file after recording is completed. The index file is generated and updated synchronously with the video file, which can ensure the timeliness of the index and avoid additional full file scanning overhead.

[0028] In step 3 of this embodiment, the video file and the corresponding I-frame index file are associated and stored together. They adopt a unified naming rule and storage path. For example, the video file and the .idx index file are saved with the same main file name but different extensions. This allows the system to directly deduce the index file path from the video file path when retrieving a certain recording, which is convenient for association management and retrieval. The I-frame index file can be stored in JSON format or binary format: JSON format is easy to read and cross-platform parsing, while binary format is more compact and faster to parse. One can be chosen according to the deployment environment.

[0029] In step 4 of this embodiment, the RTSP server receives a playback request initiated by the client, such as an RTSP PLAY command, and parses and extracts the target timestamp T from the playback request, indicating the user's desired start time for playback. target The target timestamp is the point in time that the user is pointing to when dragging the progress bar.

[0030] In step 5 of this embodiment, the RTSP server queries the I-frame index file and uses a binary search to locate the target timestamp T in the entry area arranged in ascending order of display timestamps. target The most recent target I-frame is recorded as its display timestamp T2, and the byte offset of the target I-frame is read. Using the target I-frame as the starting point for decoding and playback, it can be ensured that subsequent P-frames have a usable reference frame, thus ensuring the correctness of decoding. With the help of binary search, even if the number of index entries is large, the positioning process can still be completed in milliseconds, which can avoid the delay caused by scanning the video file frame by frame.

[0031] In step 6 of this embodiment, the RTSP server, based on the byte offset obtained in step 5, reads video frame data frame by frame from the located I-frame in the video file, and performs judgment and processing on each video frame: if the display timestamp of the current video frame is less than the target timestamp T... target Then, perform timestamp remapping on the frame and adjust its display timestamp using the following formula: PTS 调整后 =T target -ε×N In the formula, PTS 调整后 T is the remapped display timestamp. target The target timestamp is ε, a small time offset of 1 millisecond, and N is the number of remaining frames between the current frame and the target frame. Simultaneously, the decoded timestamp after remapping this frame is equal to the remapping display timestamp, and the frame display duration is set to 0. If the display timestamp of the current video frame is greater than or equal to the target timestamp T... target If the original display timestamp and decoding timestamp of the frame are unchanged, then the original display timestamp and decoding timestamp of the frame will remain unchanged. Since the video stream is arranged in ascending order of display timestamp, the first frame whose display timestamp is greater than or equal to T will be considered. target Starting with the first video frame, all subsequent video frames are continuously read, encapsulated, and transmitted using the original timestamp until the video file is fully read or the playback process terminates.

[0032] In this embodiment, the product of the minute time offset ε and the remaining number of frames N is less than the target timestamp T. target The difference between the timestamp T2 of the located I-frame and the timestamp T2 is ε×N<T. target -T2 ensures that the display timestamps of each video frame after remapping increase sequentially and all fall within T2 and T... target Between these frames, the display timestamp must be greater than the starting I-frame's timestamp and less than the target timestamp. It will not overlap with the starting I-frame's timestamp, nor will it cross the target time point. Since ε is 1 millisecond and the remapping timestamps of adjacent crossed frames differ by only 1 millisecond, these frames are compressed into an extremely short interval immediately before the target timestamp on the time axis. Combined with a frame display duration of 0, this allows the client to continuously cross frames at a near-instantaneous speed.

[0033] The following is combined with Figure 2 For an explanation of timestamp remapping, see [link / reference]. Figure 2 Assume the display timestamps of each frame in the original video stream are 0, 40, 80, 120, 160, 200, 240, 280, 320, 360, 400, 440, 480, 520, 560...1000 milliseconds, where the first frame (0 milliseconds) and the last frame (1000 milliseconds) are I-frames, and the rest are P-frames, with a frame interval of 40 milliseconds; the target time for the user to drag the progress bar is 520 milliseconds, i.e., T... target =520 milliseconds, the nearest I-frame before the target time has a display timestamp of 0 milliseconds. For each frame with a display timestamp less than 520 milliseconds, i.e., 0, 40, 80, ..., 480 milliseconds, a total of 13 frames, according to PTS. 调整后 =T target -ε×N remapping: For a frame with a display timestamp of 0 milliseconds, the remaining number of frames N=13 between it and the target frame. After remapping, the display timestamp is 520-1×13=507 milliseconds. For a frame with a display timestamp of 40 milliseconds, N=12, and after remapping, it is 520-1×12=508 milliseconds. Similarly, for a frame with a display timestamp of 480 milliseconds, N=1, and after remapping, it is 520-1×1=519 milliseconds. The display timestamps of the 13 frames are remapped sequentially to 507, 508, 509, ..., 519 milliseconds, increasing by milliseconds and all less than 520 milliseconds. The corresponding decoding timestamps are taken as the same value, and the frame display duration is set to 0. For the target frame with a display timestamp of 520 milliseconds and subsequent frames at times of 560, 600, 640...1000 milliseconds, the original timestamps remain unchanged. After remapping, the 13 P-frames between the I-frame and the target frame are compressed into a close interval of 507-519 milliseconds. The client decodes these zero-duration frames and immediately crosses them, finally starting normal playback from the target frame at 520 milliseconds, achieving millisecond-level positioning accuracy.

[0034] Timestamp remapping only changes three types of time information of the video frame: display timestamp, decoding timestamp, and frame display duration. It does not touch the original encoded data of the frame or destroy the image group structure. The compressed bitstream of the remapped P-frame remains unchanged and can still be correctly decoded by the starting I-frame and the preceding P-frame. It is just that after decoding, it is quickly skipped by zero-duration rendering. The bitstream output by the server is still a legal standard bitstream.

[0035] While reading video frame data byte-by-byte, the RTSP server also processes the interspersed audio frames, based on the display timestamp of the corresponding video frame: if the display timestamp of the corresponding video frame is less than the target timestamp T... targetWhen the audio frame is not transmitted to the client, skip it; when the display timestamp of the corresponding video frame is greater than or equal to the target timestamp T. target At that time, the audio frame is read and transmitted normally to the client. Since the video frames skipped during the positioning process are only rendered for zero duration and do not actually present a continuous picture, playing the corresponding audio as usual would produce noise. By skipping the audio frame at this stage and resuming audio transmission after reaching the target time point, the audio and video synchronization logic in the fast frame skipping stage is simplified, and noise during the frame skipping process can be avoided, ensuring that the audio and video are synchronized and start playing naturally after the target time point.

[0036] In step 7 of this embodiment, the RTSP server encapsulates the remapped zero-duration frames, video frames that retain their original timestamps after the target time point, and audio frames that have resumed transmission into RTP data packets, and transmits them to the client player over the network according to the standard RTP protocol.

[0037] On the client side, the player receives RTP data packets sent by the RTSP server, decodes and renders them according to the standard RTP protocol without any customization. Since each video frame between the starting I-frame and the target frame has a display duration of 0 seconds, and its timestamp increases milliseconds without crossing the target timestamp, the player renders and jumps to the next frame immediately after decoding these frames, allowing it to skip between intermediate frames at extremely high speeds. When the player receives a display timestamp greater than or equal to the target timestamp T... target When the frame is reached, the normal playback rhythm is restored, achieving the transition from the target time point T. target Precise positioning playback begins. This allows for millisecond-level precise point-to-point playback, even with large I-frame intervals, without requiring the user to wait for the entire GOP to be decoded. Throughout the process, all positioning and frame-hopping logic is handled by the server via timestamp remapping; the client only decodes and plays according to the standard protocol, making it compatible with various players supporting standard RTSP / RTP protocols.

[0038] The method in this embodiment can be deployed in a video surveillance system inside an urban rail transit vehicle. The system mainly includes onboard cameras, network switching equipment, a recording server, and a video player. Multiple onboard cameras are distributed across each carriage of the train and connected to the nearest network switching equipment. These network switching devices are interconnected via the vehicle's internal network and connected to the recording server. The recording server performs the aforementioned encoding processing, index generation, storage management, and RTSP service functions. After the video player connects to the network, it can remotely retrieve and accurately play back recordings at any point in time via the RTSP / RTP protocol. The deployment method in this embodiment is suitable for a single train with 20-40 cameras and multiple servers working together, and can operate stably in a 24 / 7 onboard environment. By increasing the I-frame interval from the traditional 1 second to 5 seconds, 10 seconds, or even 20 seconds, the bitrate and storage size can be significantly reduced while meeting the image quality standards for rail transit monitoring and evidence collection. Actual measurements show that when the I-frame interval is increased to 5 seconds, the bit rate and storage volume decrease by about 20%; when the I-frame interval is increased to 10 seconds, the decrease is about 23%; and when the I-frame interval is increased to 20 seconds, the decrease is about 25%. For vehicle monitoring scenarios with 20 to 40 cameras per train operating continuously 24 / 7, the reduction in storage costs is particularly significant.

[0039] The method of this invention reduces bitrate and storage usage by increasing the I-frame interval. The index file, which can be binary searched, enables millisecond-level retrieval of keyframes. Combined with timestamp remapping, it achieves fast frame switching while keeping the encoded data and image group structure unchanged. Centralized processing on the server side eliminates the need for client modification. Thus, the method in this embodiment achieves low bitrate storage, millisecond-level accurate playback, and full terminal compatibility in the same link, which is superior to the existing solutions that require trade-offs between storage cost, playback latency, and terminal compatibility.

[0040] In an embodiment of the present invention, a computer device is also provided, including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the video storage and precise positioning playback method described above.

[0041] The computer device can be a terminal, and its internal structure diagram can be as follows: Figure 5As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a video storage and precise positioning playback method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device casing, or an external keyboard, touchpad, or mouse.

[0042] Memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), and Electrically Erasable Programmable Read-Only Memory (EEPROM). Memory stores programs, and the processor executes these programs after receiving execution instructions.

[0043] A processor can be an integrated circuit chip with signal processing capabilities. The aforementioned processor can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc. The processor can also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. A general-purpose processor can be a microprocessor or any conventional processor.

[0044] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. A specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0045] In an embodiment of the present invention, a computer-readable storage medium is also provided, on which a program is stored, and when the program is executed by a processor, it implements the video storage and precise positioning playback method described above.

[0046] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, computer devices, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0047] The embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, computer apparatuses, or computer program products according to embodiments of the invention. These computer program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, create means for implementing the functions specified in the flowchart illustrations and / or block diagrams.

[0048] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in the flowchart.

[0049] In an embodiment of the present invention, a computer program product is also provided, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0050] In practical applications, the aforementioned computer program products include, but are not limited to: network video recorders, drones, smartphones, desktop computers, laptops, tablets, host computers, and server platforms, etc., without specific limitations.

[0051] The above provides a detailed description of the video storage and precise positioning playback method, computer device, computer-readable storage medium, and computer program product provided by this invention. Specific examples have been used to illustrate the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A method for video storage and precise positioning playback, characterized in that, Includes the following steps: Step 1: Use H.264 or H.265 encoding standards to perform GOP encoding on the video data captured by the camera, set the I-frame interval to be greater than 1 second, and obtain the video file; Step 2: Extract I-frame information from the encoded video stream and generate an I-frame index file independent of the video file. The I-frame index file records at least the display timestamp, decoding timestamp, byte offset in the video file, and frame data size of each I-frame. Step 3: Associate and store the video file with the corresponding I-frame index file; Step 4: The RTSP server receives the client's playback request and extracts the target timestamp from the playback request; Step 5: Query the I-frame index file, locate the nearest target I-frame before the target timestamp, and obtain the byte offset of the target I-frame; Step 6: Starting from the located target I-frame, read video frame data. For video frames whose display timestamp is less than the target timestamp, remap the display timestamp and decoding timestamp of the corresponding video frame to values ​​that are less than and close to the target timestamp, and set the frame display duration of the corresponding video frame to 0. For video frames whose display timestamp is greater than or equal to the target timestamp, keep the original timestamp unchanged. Step 7: Encapsulate the processed video frames into RTP data packets and transmit them to the client, so that the client skips video frames with a duration of 0 and starts playing from the video frame corresponding to the target timestamp.

2. The video storage and precise positioning playback method according to claim 1, characterized in that: The I-frame index file also records the image group number to which each I-frame belongs; the I-frame index file is arranged in ascending order of display timestamps and stored in a structure that supports binary search; in step 5, the nearest target I-frame before the target timestamp is located by binary search.

3. The video storage and precise positioning playback method according to claim 1, characterized in that: In step 6, video frames with display timestamps less than the target timestamp are remapped using the following formula: PTS 调整后 =T target -ε×N; Among them, PTS 调整后 T is the remapped display timestamp. target The target timestamp is ε, where ε is a small time offset and N is the number of remaining frames between the current frame and the target frame; the decoding timestamp after remapping the corresponding video frame is the same as the display timestamp after remapping.

4. The video storage and precise positioning playback method according to claim 3, characterized in that: The minute time offset ε is set to 1 millisecond; the product of ε and N is less than the difference between the target timestamp and the display timestamp of the located I-frame, so that the display timestamps of each video frame after remapping increase sequentially, and the display timestamps of each video frame after remapping are all greater than the display timestamp of the located I-frame and all less than the target timestamp.

5. The video storage and precise positioning playback method according to claim 1, characterized in that: While reading video frame data, audio frames are processed simultaneously: when the display timestamp of the corresponding video frame is less than the target timestamp, the corresponding audio frame is skipped and not transmitted; when the display timestamp of the corresponding video frame is greater than or equal to the target timestamp, the corresponding audio frame is read and transmitted to the client.

6. The video storage and precise positioning playback method according to claim 1, characterized in that: The timestamp remapping in step 6 only changes the display timestamp, decoding timestamp, and frame display duration of the video frame, while keeping the original encoded data and image group structure unchanged; the client includes a player that supports the standard RTSP and RTP protocols, and no adaptation or modification is required.

7. The video storage and precise positioning playback method according to claim 1, characterized in that: In step 1, the I-frame interval is set to be greater than or equal to 5 seconds.

8. The video storage and precise positioning playback method according to claim 1, characterized in that: The I-frame index file is stored in JSON or binary format; the I-frame index file and the corresponding video file are associated with a unified naming rule and storage path; The I-frame index file is generated synchronously during the recording file writing process; after confirming that the data of an I-frame has been written to the recording file, the corresponding index entry is written to the I-frame index file.

9. The video storage and precise positioning playback method according to claim 1, characterized in that: The video stream contains only two types of video frames: I-frames and P-frames. P-frames rely on the previous I-frame or P-frame as a reference frame for decoding.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the video storage and precise positioning playback method as described in any one of claims 1 to 9.

11. A computer-readable storage medium having a program stored thereon, characterized in that: When the program is executed by the processor, it implements the video storage and precise positioning playback method as described in any one of claims 1 to 9.

12. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method as described in any one of claims 1 to 9.

Images