Automobile data record video storage control method, automobile data recorder, medium and product

Abstract

The invention discloses an automobile data record video storage control method, an automobile data recorder, a medium and a product, and relates to the field of data processing. The method comprises the following steps: acquiring a vehicle inertial sensor signal and a driving speed parameter in real time in a video shooting and storing process of the automobile data recorder; when the inertial sensor signal exceeds a collision threshold value, generating suspected collision event information including time and places, and extracting a target undetermined video from the cyclic video cache region according to the suspected collision event information; generating a temporary pre-protection mark for the video, and opening a state verification time window; if it is monitored in the window that the vehicle speed change rate conforms to a collision event deceleration model or a signal for confirming collision by a user is received, the temporary mark is changed into a permanent locking mark, and the video is transferred to an anti-coverage storage partition. By introducing a secondary judgment mechanism, non-collision vibration interference is effectively filtered, the storage space is prevented from being occupied by mistakenly locked videos, and it is ensured that real accident videos can be reliably stored.

Description

Technical Field

[0001] This invention relates to the field of data processing, and in particular to a method for controlling the storage of vehicle recording video, a vehicle recorder, a medium, and a product. Background Technology

[0002] Dashcams, as electronic devices that record images of a vehicle's driving process, are widely used in traffic accident evidence collection and driving assistance scenarios. To effectively utilize limited storage space, dashcams typically employ a loop recording mode, meaning that when the memory card is full, newly recorded videos automatically overwrite the earliest ones. Therefore, a core function of a dashcam is to identify and independently save video clips from before and after an accident in emergency situations, and to write-protect these clips to prevent them from being overwritten or deleted by the loop recording mechanism.

[0003] In existing technologies, dashcams typically incorporate a built-in G-sensor to automatically save emergency videos. This sensor works by monitoring vehicle vibration data in real time. When the detected acceleration (G-value) instantaneously exceeds a user-preset sensitivity threshold, the system immediately determines that a collision has occurred and triggers a lock command, marking the currently recording video file as locked (or moving it to a dedicated event folder) to ensure safe storage.

[0004] However, in complex real-world driving environments, vehicles experiencing significant instantaneous vibrations when passing speed bumps, running over manhole covers, traversing potholes, or braking suddenly can be easily misinterpreted by the system as collisions, triggering gear locking. These frequent false triggers can cause the generated false alarm videos to quickly fill the reserved anti-overwrite storage partition (Event partition) on the memory card. When a real traffic accident occurs, the protected space may be full, preventing the writing of new critical video footage and resulting in the loss of crucial evidence. Summary of the Invention

[0005] To address the aforementioned technical problems and deficiencies, the present invention aims to provide a method for controlling the storage of vehicle recording videos, a vehicle recorder, a medium, and a product, which can alleviate the problem that invalid vehicle recording videos caused by misjudged collision accidents fill up the storage space, making it impossible to write new key video evidence into the storage and resulting in its loss.

[0006] To achieve the above objectives, in a first aspect, the present invention provides a method for controlling the storage of vehicle recording video, applied to a vehicle dashcam. The method includes: acquiring vehicle inertial sensor signals and vehicle speed parameters during the process of recording and storing vehicle recording video in a loop recording buffer; generating suspected collision event information when the value of the dashcam inertial sensor signal exceeds a preset collision threshold, the suspected collision event information including the time and location of the suspected collision event; and extracting target pending video from the dashcam's loop recording buffer based on the suspected collision event information. The dashcam generates a temporary pre-protection flag for the target video and opens a state verification time window of a preset duration. If, during the duration of the dashcam state verification time window, the rate of change of the dashcam's vehicle speed parameters is found to match the preset collision event deceleration model, or a user confirmation signal is received from the dashcam's user confirming a collision event, the dashcam changes the temporary pre-protection flag of the target video to a permanent lock flag. Based on the permanent lock flag, the dashcam transfers the target video to a preset anti-overwrite storage partition.

[0007] This invention employs the aforementioned method, introducing a dual judgment mechanism of "suspected collision marker + status verification." Utilizing a status verification time window and a collision event deceleration model, it effectively alleviates the problem of frequent false alarms and invalid storage space occupation caused by single vibration threshold triggering in existing technologies, preventing the writing of new critical video evidence and resulting in its loss. When the inertial sensor signal exceeds the limit, this invention only temporarily pre-protects the video, then opens the verification window, combining the vehicle speed change rate (collision event deceleration model) or user subjective confirmation signals for secondary verification. Only when a sudden deceleration behavior matching collision characteristics is detected or a user confirmation command is received is the video permanently locked and transferred to the anti-overlay partition. This logic accurately filters out false triggers caused by non-accident vibrations such as vehicles passing through speed bumps and potholes at high speeds, fundamentally preventing the anti-overlay storage partition from being filled with useless false alarm videos. This ensures that in the event of a real and serious traffic accident, the dashcam has sufficient protected space to safely store critical on-site video evidence, improving the reliability of the dashcam in complex road conditions.

[0008] In some implementations, after the dashcam opens a preset duration status verification time window, the method further includes: if, during the duration of the dashcam status verification time window, no change rate of the dashcam vehicle speed parameter is detected that matches the dashcam collision event deceleration model, or no dashcam user confirmation signal is received, then the dashcam temporary pre-protection mark of the dashcam target pending video is deleted, and the occupancy lock of the dashcam target pending video is released.

[0009] By adopting the above technical solution, the resource release logic in the event of false triggering is clarified. When a suspected collision event fails the verification by the deceleration model or user confirmation within the verification window, the system automatically cancels the temporary marker and releases the occupancy lock, allowing the video segment to seamlessly return to the loop recording mechanism. This achieves automatic optimized management of storage space, eliminating the need for users to manually clean up false alarm files periodically, and ensuring the efficient recycling of storage resources.

[0010] In some implementations, the step of extracting a target pending video from the dashcam's loop recording buffer based on suspected collision event information includes: determining the start and end storage address pointers for the corresponding time period in the circular address list of the dashcam's loop recording buffer according to the time of the suspected collision event; constructing a virtual index linked list containing the dashcam's start and end storage address pointers; mapping the dashcam's virtual index linked list to the dashcam's target pending video, and locking the write permissions of the storage blocks in the dashcam's circular address list between the dashcam's start and end storage address pointers.

[0011] The above technical solution employs a virtual index linked list and address pointer locking to achieve video extraction and protection. By directly locking the write permissions of storage blocks in the circular address list, rather than copying or moving physical files, a "zero-copy" operation is achieved. This method significantly reduces system I / O overhead and write latency, ensuring that the target video can be locked instantly during high-speed recording, avoiding the risk of frame loss caused by large data transfers.

[0012] In some implementations, the step of opening a state verification time window of a preset duration for the dashcam specifically includes: determining the initial trigger speed based on the dashcam's vehicle speed parameters when the suspected collision event information is generated; calculating the theoretical braking time required for the dashcam's initial trigger speed to decay to zero using a preset vehicle braking distance physical model; determining the duration of the dashcam's state verification time window based on the dashcam's theoretical braking time and a preset basic buffer time, and starting countdown monitoring.

[0013] The above technical solution enables adaptive dynamic adjustment of the state verification time window. Based on the initial speed of the vehicle at the time of a suspected collision and the theoretical braking duration calculated using a physical braking model, the verification window length is scientifically set. This ensures sufficient time span to fully monitor the vehicle's deceleration process from collision to stop, avoiding missed detections due to excessively short verification times, while also preventing ineffective use of system resources due to excessively long windows.

[0014] In some implementations, if the rate of change of the vehicle speed parameter of the dashcam is detected to conform to a preset collision event deceleration model during the duration of the dashcam status verification time window, the step of changing the temporary pre-protection mark of the dashcam target video to a permanent lock mark includes: within the dashcam status verification time window, when the dashcam vehicle speed parameter is detected to be missing or abnormally frozen, calling the video frame image of the dashcam target video at the current moment; calculating the pixel feature point displacement vector between the current video frame image and the previous video frame image to obtain the visual optical flow velocity value; if the rate of change of the dashcam visual optical flow velocity value conforms to the dashcam collision event deceleration model, then changing the dashcam temporary pre-protection mark to a permanent lock mark.

[0015] Using the above technical solution, a redundant speed measurement mechanism based on visual optical flow was established. In extreme conditions such as missing or abnormally frozen vehicle speed signals (e.g., OBD disconnection due to a collision, or no GPS signal in a tunnel), visual speed is calculated by analyzing the pixel displacement vectors of video frames. This ensures that even in complex scenarios where sensors fail, the system can still accurately determine vehicle deceleration behavior based on visual features, guaranteeing the high availability of the collision recognition function.

[0016] In some implementations, the step of calculating the pixel feature point displacement vector between the current video frame image and the previous video frame image to obtain the visual optical flow velocity value specifically includes: dividing the dashcam video frame image into a region of interest located in the center of the image and a background reference region located on the periphery of the image according to a preset geometric ratio; masking the pixel feature points in the dashcam's region of interest and using the pixel feature points in the dashcam's background reference region as valid calculation samples; calculating the weighted average of the horizontal divergence component or the vertical backward component of the dashcam's valid calculation samples along the image coordinate system between consecutive video frames, and determining the dashcam's weighted average as the dashcam's visual optical flow velocity value.

[0017] The above technical solution was adopted to optimize the visual speed measurement algorithm against interference. By segmenting the image region and shielding the central area of ​​interest, interference from vehicle hood vibration, windshield reflection, and relative motion of the vehicle in front on optical flow calculation was effectively eliminated. Divergence or backlash components were calculated using only effective samples from the background reference region, significantly improving the accuracy of visual optical flow velocity calculation and enhancing the algorithm's robustness in dynamic driving environments.

[0018] In some implementations, after the dashcam generates a temporary pre-protection marker for the dashcam target video, the method further includes: locating a video keyframe image in the dashcam target video that is closest to the time point of the suspected collision event; copying and writing the dashcam video keyframe image to a preset non-volatile storage unit as an emergency evidence snapshot independent of the dashcam's loop recording buffer.

[0019] The above technical solution provides independent snapshot backups of critical evidence. While locking the dynamic video, the key frame images closest to the moment of collision are extracted and independently written to non-volatile storage units. Even in catastrophic situations such as video file corruption, memory card sector failure, or power outages causing video loop closure, the static images of the moment of the accident can still be safely preserved, minimizing the risk of losing core evidence.

[0020] In a second aspect, the present invention provides a dashcam, comprising: one or more processors and a memory; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, wherein the one or more processors invoke the computer instructions to cause the dashcam to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, the present invention provides a computer-readable storage medium storing computer instructions that, when executed on a dashcam, cause the dashcam to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, the present invention provides a computer program product including computer instructions that, when executed on a dashcam, cause the dashcam to perform the method described in the first aspect and any possible implementation thereof.

[0023] Understandably, the dashcam provided in the second aspect, the storage medium provided in the third aspect, and the computer program product provided in the fourth aspect are all used to execute the method provided by this invention. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0024] Figure 1 This is a functional module framework diagram of a dashcam according to an embodiment of the present invention;

[0025] Figure 2 This is a flowchart illustrating a method for controlling the storage of vehicle recording video according to an embodiment of the present invention;

[0026] Figure 3 This is a schematic diagram of the hardware architecture of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0027] The terminology used in the following embodiments of the present invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the specification and appended claims of the present invention, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in the present invention refers to any or all possible combinations comprising one or more of the listed items.

[0028] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of the present invention, unless otherwise stated, "a plurality of" means two or more.

[0029] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below in conjunction with specific embodiments.

[0030] This invention provides a method for controlling the storage of dashcam video, applicable to dashcams. For example... Figure 1 As shown, the dashcam includes at least a processor, an image acquisition module, an inertial sensor, and a storage module. The processor, as the core control unit of the dashcam, is responsible for executing all steps of the dashcam video storage control method described in this embodiment. The image acquisition module is used to capture video footage during vehicle movement. The inertial sensor is used to detect changes in vehicle acceleration and vibration. The storage module includes at least two logical partitions: a loop recording buffer and an anti-overwrite storage partition. The processor is also connected to the vehicle's onboard system to acquire vehicle driving data.

[0031] like Figure 2 As shown, an embodiment of the present invention provides a method for controlling the storage of vehicle recording video, comprising the following steps:

[0032] S101 acquires vehicle inertial sensor signals and vehicle speed parameters while recording driving video and storing it in the loop recording buffer.

[0033] Specifically, the dashcam continuously records video footage of the vehicle in motion and stores the recorded video as video files in the loop recording buffer of the storage module. The loop recording buffer is a logical storage area within the storage module specifically designed for storing regular dashcam video. It employs a circular overwrite storage strategy; when the loop recording buffer is full, newly recorded video files automatically overwrite the oldest recorded video files in the buffer. Dashcams typically divide the recorded video into multiple independent video files according to a preset duration, with each video file lasting one minute, three minutes, or five minutes.

[0034] During the recording and storage of dashcam video in the loop recording buffer, the dashcam simultaneously acquires inertial sensor signals and vehicle speed parameters. Inertial sensor signals refer to the detection signals output by the dashcam's built-in inertial sensors. These inertial sensors can be accelerometers, gyroscopes, or a combination of both. Accelerometers detect changes in vehicle acceleration along three axes, and their output inertial sensor signals characterize the magnitude and direction of the impact force experienced by the vehicle. Gyroscopes detect changes in the vehicle's angular velocity, and their output inertial sensor signals characterize changes in the vehicle's attitude. The dashcam continuously reads the inertial sensor signals at a preset sampling frequency, which can be set to 100 to 500 times per second.

[0035] Vehicle speed parameters refer to data that characterizes the current speed of a vehicle. Dashcams acquire vehicle speed parameters in the following ways:

[0036] The first method is for the dashcam to connect to the vehicle's onboard system via an onboard diagnostic interface and read the vehicle's real-time speed data from the onboard system as the vehicle's speed parameter.

[0037] The second method is to have a built-in GPS module in the dashcam. The dashcam receives satellite positioning signals through the GPS module and calculates the vehicle's speed based on the satellite positioning signals as the vehicle's speed parameter.

[0038] The third method is for the dashcam to connect to the user's mobile terminal device via a wireless communication module, and obtain the vehicle's driving speed data from the user's mobile terminal device as the vehicle's driving speed parameter.

[0039] The dashcam stores the acquired inertial sensor signals and vehicle speed parameters in its running memory for analysis and processing in subsequent steps.

[0040] S102, when the value of the inertial sensor signal exceeds the preset collision threshold, generate suspected collision event information, which includes the time and location of the suspected collision event.

[0041] The inertial sensor signal value can refer to either the acceleration or angular velocity output by the inertial sensor. When the inertial sensor is an accelerometer, the signal value is the acceleration value detected by the accelerometer, which is usually expressed as a multiple of gravitational acceleration. When the inertial sensor is a gyroscope, the signal value is the angular velocity value detected by the gyroscope. When the inertial sensor is a combination of an accelerometer and a gyroscope, the signal value is a combined calculation of the acceleration and angular velocity values.

[0042] The collision threshold is a reference value preset and stored in the dashcam's storage module. It's used to determine whether a collision has occurred. The collision threshold can be set by the user based on their actual needs, or it can be preset by the dashcam manufacturer as a default value. Setting the collision threshold requires consideration of factors such as vehicle type, road conditions, and the user's driving habits. For small passenger vehicles, the collision threshold can be set to a value between 1.5 and 3 times the acceleration due to gravity.

[0043] The dashcam compares the values ​​of inertial sensor signals with a collision threshold. When the inertial sensor signal value exceeds the collision threshold, the dashcam determines that a collision event may have occurred and generates suspected collision event information. Suspected collision event information is a set of data records describing a possible collision event. This information includes the time and location of the suspected collision event. The time of the suspected collision event refers to the moment when the inertial sensor signal value exceeds the collision threshold; the dashcam reads the timestamp of this moment from its real-time clock module. The location of the suspected collision event refers to the vehicle's geographical location when the inertial sensor signal value exceeds the collision threshold; the dashcam obtains the latitude and longitude coordinates of this moment from its Global Positioning System (GPS) module. The dashcam stores the generated suspected collision event information in its running memory for subsequent processing.

[0044] S103, extract the target pending video from the loop recording buffer based on suspected collision event information.

[0045] Among them, the target pending video refers to video files or video clips that contain driving footage during the time period before and after the suspected collision event. The target pending video is used to record the complete process of the suspected collision event.

[0046] In this step, the dashcam searches for the video file corresponding to the time of the suspected collision event in the loop recording buffer, based on the time of the suspected collision event in the suspected collision event information. Because the dashcam divides the recorded video into multiple independent video files according to a preset time length, and each video file has a clear start and end time, the dashcam can quickly locate the video file containing the time of the suspected collision event.

[0047] The methods for a dashcam to extract video of a target to be determined can include the following:

[0048] The first method is to use a single video file containing the moment of the suspected collision as the target video.

[0049] The second approach is to use the video file containing the moment of the suspected collision, along with one or more video files preceding and one or more video files following the suspected collision, as the target pending video to ensure that the target pending video fully records the driving conditions before the suspected collision and the scene after the suspected collision.

[0050] The third method involves taking the time of the suspected collision as the center, extracting video clips of a preset duration forward and backward, and then merging these clips to create a new video file as the target video. The preset duration for both forward and backward clipping can be between ten and sixty seconds.

[0051] The dashcam temporarily stores the extracted target video in the loop recording buffer, awaiting further processing in subsequent steps.

[0052] S104, generate a temporary pre-protection marker for the target pending video and open a state verification time window with a preset duration.

[0053] In this step, the dashcam marks the target pending video extracted in step S103 and starts a time window to verify the authenticity of the suspected collision event.

[0054] A temporary pre-protection tag is a status indicator attached to a target video pending verification. It indicates that the video is in a pending verification state. The purpose of the temporary pre-protection tag is to prevent the video from being overwritten or deleted by the loop recording buffer's overwrite mechanism during the verification time window. The dashcam can generate temporary pre-protection tags for target videos in several ways:

[0055] The first method is to add a flag indicating a temporary protection status to the file attributes of the target video;

[0056] The second method is to record the file information of the target video to be determined into a special temporary protection list. Before performing the loop overwrite operation, the dashcam will check the temporary protection list and skip the video files recorded in the temporary protection list.

[0057] The third method is to modify the file name of the target video to be protected by adding specific characters or prefixes to the file name to indicate a temporary protection status.

[0058] The status verification time window is a pre-defined time period used to collect and analyze vehicle driving status data to verify whether a suspected collision event is a real collision event. The preset duration refers to the length of time the status verification time window lasts from opening to closing. The preset duration can be set according to the actual application scenario, and can be set to a value between thirty seconds and three minutes. The setting of the preset duration needs to consider the following factors: the preset duration needs to be long enough to collect sufficient vehicle driving status data to determine the authenticity of a suspected collision event, but the preset duration should not be too long to avoid delaying timely protection in the event of a real collision.

[0059] After the dashcam opens the status verification time window, it starts timing the duration of the status verification time window and continuously monitors the vehicle's driving status data during the duration of the status verification time window.

[0060] S105, if during the duration of the state verification time window, the rate of change of the vehicle speed parameter is found to conform to the preset collision event deceleration model, or a user confirmation signal is received from the vehicle user confirming that a collision event has occurred, then the temporary pre-protection mark of the target pending video is changed to a permanent lock mark.

[0061] During the duration of the status verification time window opened in step S104, the dashcam continuously monitors the vehicle's driving status and determines whether a suspected collision event is a real collision event. The dashcam verifies the authenticity of a suspected collision event through two methods: the first method is to analyze whether the rate of change of the vehicle's speed parameters conforms to a preset collision event deceleration model; the second method is to detect whether a user confirmation signal has been received.

[0062] The rate of change of vehicle speed parameters refers to the rate at which vehicle speed parameters change over time, reflecting the degree of acceleration or deceleration of the vehicle. A dashcam obtains the rate of change of vehicle speed parameters by calculating the difference between the vehicle speed parameters at two adjacent moments and dividing by the time interval between the two moments.

[0063] A collision event deceleration model is a set of parameters or rules pre-built and stored in the dashcam's storage module. It describes the typical deceleration characteristics of a vehicle during a real collision event. The model is built upon statistical analysis of a large amount of real collision event data. The collision event deceleration model includes the following characteristic parameters:

[0064] The first feature parameter is the deceleration magnitude threshold, which represents the minimum speed reduction of the vehicle within a preset time period after a collision. The second feature parameter is the deceleration duration threshold, which represents the shortest duration of continuous deceleration after a collision. The third feature parameter is the final speed threshold, which represents the maximum speed of the vehicle at the end of the state verification time window after a collision.

[0065] When a real collision occurs, the vehicle typically decelerates significantly or even comes to a complete stop after the collision. The dashcam compares the rate of change of the vehicle's speed parameters with the characteristic parameters in a collision event deceleration model. If the rate of change of the vehicle's speed parameters matches the collision event deceleration model—that is, if the vehicle exhibits deceleration characteristics described by the model after the inertial sensor signal exceeds the collision threshold—then the dashcam determines the suspected collision event to be a real collision event. For example, if the vehicle's speed decreases from 60 km / h to 0 km / h within ten seconds after the inertial sensor signal exceeds the collision threshold and remains stationary for more than 20 seconds, then the rate of change of the vehicle's speed parameters matches the collision event deceleration model. Conversely, if the vehicle only experiences vibrations from passing over speed bumps or potholes, the vehicle will typically continue at normal speed after a brief period of vibration, and the rate of change of the vehicle's speed parameters will not match the collision event deceleration model.

[0066] A user confirmation signal is a signal actively sent by the driver or passenger of a vehicle to acknowledge that a collision has occurred. Dashcams can receive user confirmation signals in the following ways:

[0067] The first method is for the user to press the physical confirmation button on the dashcam. The dashcam generates a user confirmation signal after detecting that the physical confirmation button has been pressed.

[0068] The second method is for the user to click the confirmation option on the dashcam's touch screen. The dashcam will then generate a user confirmation signal after detecting that the confirmation option has been clicked.

[0069] The third method is for the user to send a confirmation command through a companion application running on a mobile terminal device paired with the dashcam. After receiving the confirmation command through the wireless communication module, the dashcam generates a user confirmation signal.

[0070] The fourth method is for the user to issue a confirmation voice command to the dashcam. The dashcam uses its built-in microphone to collect the voice and perform voice recognition. Once the confirmation voice command is recognized, it generates a user confirmation signal.

[0071] When the dashcam detects that the rate of change of the vehicle's speed parameters matches the deceleration model of a collision event during the status verification time window, or when it receives a user confirmation signal, the dashcam changes the temporary pre-protection flag of the target pending video to a permanent lock flag. The permanent lock flag is another status indicator attached to the target pending video. It indicates that the target pending video has been confirmed as important video recording a real collision event and requires permanent protection. The difference between a permanent lock flag and a temporary pre-protection flag is that a video file with a temporary pre-protection flag is still in a pending verification state and the temporary pre-protection flag may be revoked, while the protection status of a video file with a permanent lock flag is fixed and will not be automatically revoked.

[0072] The way the dashcam changes the temporary pre-protection mark to a permanent lock mark corresponds to the way the temporary pre-protection mark is generated in step S104. It can be by modifying the flag bit in the file attributes, updating the recording status in the protection list, or modifying specific characters in the file name.

[0073] If, during the duration of the status verification time window, the dashcam neither detects a rate of change in the vehicle speed parameters that matches the collision event deceleration model nor receives a user confirmation signal, then when the duration of the status verification time window reaches the preset duration, the dashcam will remove the temporary pre-protection mark on the target pending video. After removing the temporary pre-protection mark, the target pending video will revert to normal dashcam video, and can be normally overwritten by the loop recording buffer's loop overwrite mechanism.

[0074] In some embodiments, the collision event deceleration model is constructed by collecting dashcam data from a large number of real-world collision accident cases:

[0075] First, we collected a large amount of raw data from dashcams of real collision accidents and extracted the vehicle speed change curves from ten seconds before the collision to sixty seconds after the collision in each accident.

[0076] Then, feature extraction is performed on the velocity change curve to calculate feature parameters such as the velocity decrease rate in the first second after the collision, the average deceleration in the five seconds after the collision, the duration from the collision to complete stop, and the duration of stillness after the vehicle stops.

[0077] Next, statistical analysis was performed on all sample data. Clustering algorithms were used to classify collision accidents into three levels according to collision intensity: minor collision, moderate collision, and severe collision. The mean and standard deviation range of the characteristic parameters were calculated for each level.

[0078] Finally, a judgment rule is established: when the monitored rate of change of speed meets the characteristic parameter range of any level, it is judged to conform to the collision event deceleration model.

[0079] The collision event deceleration model also sets exclusion rules, treating speed change features from non-collision scenarios such as emergency braking and passing over speed bumps as negative samples, to ensure that the collision event deceleration model can effectively distinguish between real collisions and false triggering situations.

[0080] S106, based on the permanent lock mark, transfer the target pending video to the preset anti-overwrite storage partition.

[0081] In step S106, the dashcam, based on the permanent lock mark added to the target video in step S105, transfers the target video from the loop recording buffer to the anti-overwrite storage partition for permanent storage.

[0082] The anti-overwrite storage partition is a logical storage area within the storage module specifically designed to store confirmed collision event videos. It can also be called the event storage partition or the locked video storage partition. The anti-overwrite storage partition is independent of the loop recording buffer and is not affected by the loop recording buffer's overwrite mechanism. Video files stored in the anti-overwrite storage partition will not be automatically overwritten or deleted; they can only be manually deleted by the user or managed by the system with user authorization. The storage capacity of the anti-overwrite storage partition is preset and can account for 10% to 30% of the total storage module capacity.

[0083] The process of a dashcam transferring a target video to an overwrite-proof storage partition includes the following steps: First, the dashcam checks if the remaining storage space in the overwrite-proof storage partition is sufficient to hold the target video. If the remaining storage space is sufficient, the dashcam copies or moves the target video from the loop recording buffer to the overwrite-proof storage partition, and deletes the original file of the target video from the loop recording buffer after copying or moving. If the remaining storage space in the overwrite-proof storage partition is insufficient, the dashcam can send a message to the user indicating insufficient storage space, reminding the user to clear historical video files in the overwrite-proof storage partition, or the dashcam can automatically delete the oldest video file stored in the overwrite-proof storage partition according to a preset storage management policy to free up storage space.

[0084] After the target-pending video is transferred to the anti-overwrite storage partition, the dashcam retains a permanent lock mark on the target-pending video, as well as metadata information such as the time and location of the suspected collision event from the suspected collision event information. Users can view and manage the collision event videos stored in the anti-overwrite storage partition through the dashcam's display interface or the accompanying mobile application.

[0085] Through steps S101 to S106 above, the vehicle recording video storage control method provided by this embodiment of the invention achieves intelligent identification and reliable storage of collision event videos. Compared with the prior art, which directly triggers gear locking based solely on inertial sensor signals exceeding a threshold, this embodiment of the invention, by introducing a state verification time window and a collision event deceleration model, can effectively distinguish between real collision events and false triggering caused by passing speed bumps, potholes, etc., significantly reducing the probability of false gear locking, avoiding the problem of the anti-overwrite storage partition being filled with false alarm videos, and ensuring that critical accident video evidence can be reliably stored when a real traffic accident occurs.

[0086] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the technical solutions of this invention will be clearly and completely described below in conjunction with more specific embodiments. The method provided by the embodiments of this invention may further include the following steps:

[0087] S201 acquires vehicle inertial sensor signals and vehicle speed parameters during the process of recording driving video and storing it in the loop recording buffer.

[0088] This step can be referred to the description in the previous embodiments, and will not be repeated here.

[0089] S202, when the value of the inertial sensor signal exceeds the preset collision threshold, a suspected collision event information is generated.

[0090] This step can be referred to the description in the previous embodiments, and will not be repeated here.

[0091] S203, based on the time of the suspected collision event, determine the start and end storage address pointers for the corresponding time period from the circular address list of the loop recording buffer.

[0092] The circular address list is an index structure used by the circular recording buffer to manage the location of video data storage. It organizes the address information of each storage block in the circular recording buffer in a circular queue. Each entry in the circular address list records the physical storage address of a storage block, the timestamp information corresponding to the video data stored in that block, and the usage status of that storage block.

[0093] The starting memory address pointer is a reference to a memory block in the circular address list. The starting memory address pointer indicates the location of the memory block where the beginning part of the target video to be determined is located.

[0094] The end-of-storage address pointer is a reference to another storage block in the circular address list. The end-of-storage address pointer identifies the storage block location where the end of the target pending video is located.

[0095] The dashcam searches for a storage block in a circular address list whose timestamp matches the time of the suspected collision event based on the time of the suspected collision event. It sets the address of that storage block as the end storage address pointer, and then traces back a preset number of storage blocks from that storage block, setting the address of the traced storage block as the start storage address pointer. This determines the range of storage addresses containing video data before and after the suspected collision event.

[0096] S204, construct a virtual index linked list containing a starting memory address pointer and an ending memory address pointer.

[0097] In step S204, the dashcam creates a logical index structure to represent the target video. A virtual index list is a lightweight index structure that does not actually store video data but only stores the location information of the video data. The virtual index list indirectly represents the video content by recording the storage address of the video data in the loop recording buffer.

[0098] When constructing a virtual index linked list, the dashcam uses the starting storage address pointer as the head node and the ending storage address pointer as the tail node. The addresses of all storage blocks between the starting and ending storage address pointers are then connected in chronological order to form the linked list structure. Each node in the virtual index linked list stores the address of a storage block and a pointer to the next node.

[0099] By constructing a virtual index linked list, the dashcam does not need to copy video data from the loop recording buffer to other locations. Instead, it can quickly locate and access the data of the target video by indexing, saving storage space and data copying time.

[0100] S205, map the virtual index linked list to the target pending video, and lock the write permission of the storage block between the start storage address pointer and the end storage address pointer in the circular address list.

[0101] In step S205, the dashcam establishes a mapping relationship between the virtual index list and the target video to be recorded, and protects the storage block occupied by the target video. The dashcam creates a virtual file object representing the target video in the file system, and associates the virtual index list with the virtual file object, so that file access operations of the virtual file object can locate the corresponding video data in the loop recording buffer through the virtual index list.

[0102] The dashcam locks write permissions for storage blocks located between the start and end storage address pointers in the circular address list, marking these blocks as read-only or write-protected. This write permission locking is achieved by setting a protection flag in the corresponding entry of the circular address list or registering a protected region in the storage management module. When the circular overwrite mechanism of the loop recording buffer attempts to write new video data to a locked storage block, the storage management module detects the locked write permission and skips that block, selecting another available block for writing, thus preventing the data of the target video from being overwritten.

[0103] S206, Generate a temporary pre-protection marker for the target video.

[0104] This step can be referred to the description of the foregoing embodiments, and will not be repeated here.

[0105] S207, in the target pending video, locate the video key frame image that is closest to the time point of the suspected collision event; and copy and write the video key frame image to a preset non-volatile storage unit as an emergency evidence snapshot independent of the loop recording buffer.

[0106] In step S207, the dashcam extracts key frames from the target video and backs them up independently to ensure the security of critical evidence in extreme circumstances. A video keyframe image is an independent image frame in the video stream that contains complete image information; video keyframe images can be decoded and displayed independently without relying on other image frames.

[0107] In the video encoding process, the video stream typically includes two types of image frames: keyframes and non-keyframes. Keyframes are also called I-frames or internally encoded frames, while non-keyframes are also called P-frames or B-frames.

[0108] The dashcam searches the video stream of the target video for keyframes whose timestamps are closest to the suspected collision event's time. It then analyzes the video encoding data of the target video, identifies keyframe markers, compares the time difference between the timestamps of each keyframe and the suspected collision event's time, and selects the keyframe with the smallest time difference as the video keyframe image.

[0109] Non-volatile storage units refer to storage media whose data is not lost after a power outage. Non-volatile storage units can be flash memory chips, solid-state drives, or dedicated data protection storage devices. Emergency evidence snapshots refer to still image data saved as an emergency backup. Emergency evidence snapshots are used to provide visual evidence of the moment a collision event occurred, even if the target video is damaged due to storage media failure or other abnormal conditions.

[0110] The dashcam decodes the image data of the key frame images in the video into bitmap format, JPEG format or other image formats, and writes the image data to a non-volatile storage unit for independent storage, forming a backup copy that is separate from the video data.

[0111] S208 determines the initial trigger speed based on the vehicle speed parameters at the time the suspected collision event information is generated.

[0112] In this step, the dashcam simultaneously records the vehicle speed parameters at the moment it generates suspected collision event information. The moment the suspected collision event information is generated is the instant when the inertial sensor signal value exceeds the collision threshold. After detecting that the inertial sensor signal value exceeds the collision threshold, the dashcam immediately reads the latest collected vehicle speed parameter value from its running memory at that moment.

[0113] Since vehicle speed parameters are typically collected once per second to ten times per second, the vehicle speed parameters acquired by the dashcam may have a slight time deviation from the precise moment when the inertial sensor signal exceeds the collision threshold. To improve the accuracy of the initial trigger speed, the dashcam uses a linear interpolation method for correction. The dashcam reads vehicle speed parameter samples once before and once after the moment the inertial sensor signal exceeds the collision threshold. Based on the time interval and numerical difference between the two samples, it calculates the vehicle speed interpolation corresponding to the precise moment the inertial sensor signal exceeds the collision threshold according to a linear relationship. The calculated interpolation value is then used as the initial trigger speed.

[0114] The dashcam stores the determined initial trigger speed value in the data structure of the suspected collision event information for subsequent calculation of the theoretical braking time.

[0115] S209 uses a preset vehicle braking distance physical model to calculate the theoretical braking time required for the initial trigger speed to decay to zero.

[0116] In this step, the dashcam reads the preset parameter configuration of the vehicle braking distance physical model from the storage module. The vehicle braking distance physical model includes braking reaction time parameters, braking deceleration parameters, and road friction coefficient parameters. The braking reaction time parameter represents the delay time from when the driver perceives a hazard to when they press the brake pedal; a typical value for the braking reaction time parameter is 0.5 s to 1.5 s. The braking deceleration parameter represents the average deceleration of the vehicle during braking. The braking deceleration parameter is determined based on the vehicle type and braking system performance. For small passenger vehicles equipped with anti-lock braking systems, the braking deceleration parameter can be taken as 0.6g (g is the acceleration due to gravity) to 0.8g. The road friction coefficient parameter represents the magnitude of the friction force between the tires and the road surface. The road friction coefficient parameter is determined based on the road conditions; the road friction coefficient parameter for dry asphalt roads is taken as 0.7 to 0.9, and for wet and slippery roads, it is taken as 0.4 to 0.6.

[0117] The dashcam uses the uniform deceleration calculation formula of the vehicle braking distance physical model to divide the initial trigger speed by the product of the braking deceleration parameter and the road friction coefficient parameter, thus obtaining the pure braking time required for the vehicle to decelerate from the initial trigger speed to zero. The dashcam then adds the pure braking time to the braking reaction time parameter to obtain the theoretical braking time.

[0118] For example, when the initial trigger speed is 54 km / h (15 m / s), the braking deceleration parameter is taken as 0.7 times the gravitational acceleration, which is 6.68 m / s². 2 When the road surface friction coefficient parameter is taken as 0.8 and the braking reaction time parameter is taken as 1 second, the pure braking time is calculated as 15 m / s divided by 6.86 m / s² multiplied by 0.8, which is approximately equal to 2.73 s. The theoretical braking time is calculated as 2.73 s plus 1 s, which equals 3.73 s.

[0119] In some embodiments, the physical model of vehicle braking distance can be established based on vehicle dynamics theory and experimental data:

[0120] First, establish the equation of motion for the vehicle braking process based on Newton's second law of motion. The braking force is equal to the vehicle's mass multiplied by the braking deceleration, and the braking force is also equal to the road friction force, which is the vehicle's weight multiplied by the road friction coefficient.

[0121] Braking distance and braking time data were obtained through real vehicle braking tests under different initial speeds and road conditions. The test samples covered a speed range of 20 km / h to 120 km / h and various road conditions such as dry road, wet and slippery road, and icy and snowy road.

[0122] Regression analysis was performed on the test data to fit the functional relationship between braking distance and initial speed and road friction coefficient, resulting in the formula that braking distance equals the square of initial speed divided by twice the braking deceleration multiplied by the road friction coefficient, and the formula that braking time equals the initial speed divided by the braking deceleration multiplied by the road friction coefficient.

[0123] The physical model of vehicle braking distance also incorporates a safety factor correction, multiplying the theoretical calculation results by a safety factor of 1.1 to 1.3 to account for the effects of actual factors such as brake system wear and differences in driver operation.

[0124] S210 determines the duration of the state verification time window based on the theoretical braking duration and the preset basic buffer duration, and starts countdown monitoring.

[0125] The dashcam takes into account both the vehicle braking process and the time required for post-accident handling to determine a reasonable length of the status verification time window and begin monitoring. The basic buffer time is a pre-set extra waiting time used to cover the time needed for the driver to check the vehicle's condition or negotiate with other vehicles after the vehicle has come to a complete stop.

[0126] The base buffer duration is set based on practical application experience and can range from 20 to 60 seconds. The dashcam adds the theoretical braking duration to the base buffer duration to obtain the duration of the status verification time window. For example, when the theoretical braking duration is 2.4 seconds and the base buffer duration is 30 seconds, the duration of the status verification time window is 32.4 seconds.

[0127] Countdown monitoring refers to a timing process that decreases towards zero starting from the duration of the status verification time window. Countdown monitoring is used to track the remaining time within the status verification time window. After the dashcam starts countdown monitoring, it creates a software timer and sets the initial value of the timer to the duration of the status verification time window. The timer decreases at fixed time intervals until the count reaches zero.

[0128] During the countdown monitoring process, the dashcam continuously checks whether the conditions for confirming a collision event are met. The status verification time window ends when the countdown monitoring count reaches zero.

[0129] S211, within the state verification time window, when the vehicle speed parameter is detected to be missing or its value is abnormally frozen, the video frame image located at the current moment in the target pending video is called to calculate the current video frame image.

[0130] During the duration of the status verification time window, the dashcam reads the input interface status of the vehicle speed parameters at a preset monitoring frequency (e.g., ten times per second).

[0131] The logic of a dashcam in determining missing vehicle speed parameters is as follows: if a valid data packet is not received from the vehicle diagnostic interface or the GPS module within three consecutive monitoring cycles, or if the data checksum of the received data packet is incorrect, then the vehicle speed parameters are determined to be missing.

[0132] The logic of a dashcam in determining if a vehicle speed parameter value is abnormally frozen is as follows: if the vehicle speed parameter value remains completely consistent for two consecutive seconds (accurate to one decimal place), and at the same time, the dashcam's inertial sensor signal shows that the vehicle is not stationary and is experiencing vibration or acceleration changes, then the dashcam determines that the vehicle speed parameter value is abnormally frozen.

[0133] Once the system determines that the vehicle speed parameter is missing or abnormally frozen, the dashcam immediately switches to visual speed measurement mode. The dashcam accesses the frame buffer of the video encoder and retrieves the corresponding video image data from the frame buffer based on the current system clock timestamp.

[0134] The dashcam reads the video data frame corresponding to the timestamp, decodes it into uncompressed bitmap data, and uses it as the video frame image for the current moment. At the same time, the dashcam reads the previous frame of video data (e.g., the frame 33ms ago) from the buffer queue and uses it as the video frame image for the previous moment to construct a continuous image pair for optical flow calculation.

[0135] In some embodiments, during this step, when video frame images need to be called for auxiliary verification, but the average brightness of the video image is detected to be lower than the preset dark light threshold, resulting in the inability to extract a sufficient number of background reference area feature points, the dashcam automatically switches from optical flow speed measurement mode to rolling shutter vibration analysis mode.

[0136] The specific implementation steps for the rolling shutter vibration analysis mode are as follows:

[0137] (1) Highlight feature extraction: In the current video frame image, a high-pass filter or adaptive threshold segmentation algorithm is applied to extract point or line bright connected components with brightness values ​​significantly higher than the background (e.g., street light spots, taillight spots of the vehicle in front, road surface reflective strips).

[0138] (2) Horizontal Scan Distortion Detection: Based on the horizontal scanning characteristics of the CMOS sensor, the edge trajectory of the above-mentioned bright connected regions in the vertical direction is analyzed. Under static or low-frequency vibration (such as passing over a speed bump), the spot trajectory remains a straight line or a smooth curve; however, under the action of a high-frequency shock wave of a real collision (usually in the range of 50Hz-200Hz), due to the time difference of horizontal exposure, the spot trajectory will exhibit a high-frequency sawtooth or sinusoidal micro-distortion (i.e., jelly effect) in a single frame image.

[0139] (3) Visual vibration energy calculation: Calculate the frequency and amplitude of the micro-twist to generate a visual vibration fingerprint. A visual vibration fingerprint is a unique visual feature that uses the rolling shutter effect of a CMOS sensor to convert the high-frequency mechanical vibration caused by a real collision into a specific wave-like micro-distortion of a bright feature point in an image, thereby effectively verifying the authenticity of a physical impact when optical flow velocity measurement cannot be performed in low light.

[0140] (4) Multimodal correlation verification: The processor performs cross-correlation analysis between the temporal characteristics of the visual vibration fingerprint and the high-frequency acceleration vibration waveform collected by the inertial sensor. If the peak vibration frequencies of the two are highly coincident on the time axis (the correlation coefficient exceeds the preset threshold), it is determined that a physical contact collision has occurred.

[0141] (5) Result output: The judgment result is directly used as the basis for determining the collision event, replacing the verification of the rate of change of visual optical flow velocity value in subsequent steps, and directly triggering the generation of permanent lock mark.

[0142] The above scheme cleverly utilizes the inherent limitations of rolling shutter imaging in CMOS sensors, transforming the difficult problem of low-light vision into a feature detection advantage. It overcomes the technical bottleneck of optical flow velocity measurement failure due to the lack of background texture in low-light environments such as nighttime or tunnels. By extracting the microscopic wave-like distortion (visual vibration fingerprint) of high-brightness spots within a single frame image and cross-correlating it with acceleration frequency domain features, the system can verify the authenticity of accidents under extreme conditions of extremely limited visual information by identifying the high-frequency mechanical resonance characteristics unique to real physical collisions. This significantly enhances the system's robustness and irreplaceability under complex lighting conditions.

[0143] S212, calculate the pixel feature point displacement vector between the current video frame image and the previous video frame image to obtain the visual optical flow velocity value.

[0144] The dashcam first converts the current video frame and the previous video frame into grayscale images to reduce computation. The dashcam then uses a corner detection algorithm (such as the FAST or Harris corner detection algorithm) to select several pixels with significant texture features in the central region of the previous video frame (usually the area of ​​the road surface being filmed) as feature tracking points.

[0145] Next, the dashcam uses a sparse optical flow algorithm (such as the Lucas-Kanade optical flow method) to search for corresponding points in the current video frame that match the feature tracking points in the previous video frame. The dashcam calculates the coordinate difference between the two frames for each feature tracking point, obtaining the pixel feature point displacement vector for each feature tracking point. The dashcam performs statistical filtering on the pixel feature point displacement vectors of all feature tracking points, removing outliers with large directional deviations or abnormal displacement lengths (such as interference points caused by oncoming vehicles or windshield reflections), and retaining the effective vectors that reflect the backward movement of ground texture. The dashcam calculates the average displacement length (in pixels) of the effective vectors.

[0146] Finally, based on pre-calibrated camera intrinsic parameters (focal length, sensor size) and extrinsic parameters (camera mounting height, pitch angle), the dashcam uses a perspective projection transformation formula to convert the average displacement length into the vehicle's actual distance traveled in the physical world. The dashcam then divides this actual distance traveled by the time interval between two frames (i.e., the reciprocal of the video frame rate) to calculate the vehicle's real-time speed, which is output as the visual optical flow velocity value.

[0147] In some embodiments, this step may specifically include the following sub-steps:

[0148] S2121, the video frame image is divided into a region of interest located in the center of the image and a background reference region located on the periphery of the image according to a preset geometric ratio.

[0149] The dashcam first acquires the resolution parameters of the current video frame image, including the image width and height in pixels. A preset geometric ratio, a set of values ​​stored in the dashcam's system parameters, defines the range of the central region of the image. For example, the preset geometric ratio can be set to 50% of both the image width and height in pixels. Based on the image width, height, and preset geometric ratio, the dashcam calculates the boundary coordinates of the region of interest. The region of interest is a rectangular area centered on the geometric center point of the video frame image. This rectangular area typically covers the hood, dashboard reflections, and the vanishing point of the road in the dashcam's view. The background reference region refers to the remaining portion of the video frame image excluding the region of interest. The background reference region typically covers road surface textures, stationary objects (such as guardrails and trees), and road markings. By setting coordinate thresholds, the dashcam logically divides the pixel matrix of the video frame image into the region of interest and the background reference region, allowing for different processing strategies to be applied to different areas.

[0150] S2122, mask the pixel feature points within the region of interest, and use the pixel feature points within the background reference region as valid calculation samples.

[0151] When a dashcam performs feature point detection on a video frame, it first obtains the coordinates of all candidate feature points in the entire image. To eliminate interference from vehicle vibration, windshield reflections, and following vehicles, the dashcam needs to perform a shielding operation. The dashcam then iterates through the coordinates of each candidate feature point and compares them with the boundary coordinates of the region of interest determined in the previous steps.

[0152] If the coordinates of a candidate feature point are within the boundary of the region of interest, the dashcam will mark the candidate feature point as invalid and discard it, and will not include it in the subsequent optical flow calculation process.

[0153] If the coordinates of a candidate feature point are located within the background reference area, the dashcam marks the candidate feature point as a valid calculation sample.

[0154] In this way, the dashcam filters out feature points located on the periphery of the image that primarily reflect road surface texture and stationary roadside references. These effective computational samples, located within the background reference area, can more accurately reflect the vehicle's motion trend relative to the ground, thereby improving the accuracy of visual optical flow velocity calculations.

[0155] S2123, calculate the weighted average of the horizontal divergence component or the vertical backward component of the effective computational sample along the image coordinate system between consecutive video frames, and determine the weighted average as the visual optical flow velocity value.

[0156] The dashcam uses an optical flow tracing algorithm to calculate the displacement vector of each valid sample between the current video frame and the previous video frame. The dashcam decomposes the displacement vector into a horizontal component along the x-axis and a vertical component along the y-axis of the image coordinate system. Because objects on both sides of the image tend to spread outwards as the vehicle moves forward, and road textures at the bottom of the image tend to move downwards, the dashcam extracts the horizontal divergence component (i.e., the amount of left-side sample moving to the left and right-side sample moving to the right) and the vertical backward component (i.e., the amount of downward movement).

[0157] The dashcam assigns a weight value to each valid computational sample. The weight value is proportional to the distance of the valid computational sample from the center of the image. That is, the farther the valid computational sample is from the center of the image, the more significant its optical flow motion is, and the larger the weight value assigned to it.

[0158] The dashcam calculates the average optical flow velocity, which reflects the overall motion trend of the image, by weighting and summing the horizontal divergence components or vertical backward components of all valid calculation samples according to the weight values.

[0159] Finally, the dashcam multiplies the average optical flow velocity by a preset scaling factor (which is determined by the camera's focal length and installation height) to convert it into a visual optical flow velocity value with physical units (such as kilometers per hour).

[0160] S213, if during the duration of the state verification time window, the rate of change of the vehicle speed parameter is found to conform to the preset collision event deceleration model, or the rate of change of the visual optical flow velocity value is found to conform to the collision event deceleration model, or a user confirmation signal is received from the vehicle confirming a collision event, then the temporary pre-protection mark of the target pending video is changed to a permanent lock mark.

[0161] In this step, the dashcam integrates multiple information sources to determine the authenticity of a suspected collision event. During the status verification time window, the dashcam simultaneously monitors three types of information: the rate of change of vehicle speed parameters, the rate of change of visual optical flow velocity values, and user confirmation signals.

[0162] The rate of change of visual optical flow velocity refers to the rate at which the visual optical flow velocity changes over time. The calculation method for the rate of change of visual optical flow velocity is the same as that for the rate of change of vehicle speed parameters. When vehicle speed parameters are reliable, the dashcam prioritizes comparing the rate of change of vehicle speed parameters with the collision event deceleration model.

[0163] When vehicle speed parameters are missing or abnormally frozen, the dashcam compares the rate of change of visual optical flow velocity with the collision event deceleration model.

[0164] If the rate of change of the vehicle speed parameter matches the collision event deceleration model, or the rate of change of the visual optical flow velocity value matches the collision event deceleration model, or the dashcam receives a user confirmation signal, the dashcam will determine the suspected collision event as a real collision event and change the temporary pre-protection mark of the target pending video to a permanent lock mark.

[0165] S214, Based on the permanent lock mark, transfer the target pending video to the preset anti-overwrite storage partition.

[0166] This step can be referred to the description in the foregoing embodiments, and will not be repeated here.

[0167] S215, if during the duration of the state verification time window, no change rate of vehicle speed parameters conforming to the collision event deceleration model and no change rate of visual optical flow velocity values ​​conforming to the collision event deceleration model are detected, or no user confirmation signal is received, then the temporary pre-protection mark of the target pending video is deleted and the occupation lock of the target pending video is released.

[0168] In this step, the dashcam handles false triggering situations and releases storage resources occupied by the pending target video. When the countdown monitoring count value of the status verification time window reaches zero, if the dashcam neither detects a rate of change of the vehicle speed parameter that matches the collision event deceleration model, nor detects a rate of change of the visual optical flow velocity value that matches the collision event deceleration model, and also does not receive a user confirmation signal, then the dashcam determines the suspected collision event as a false triggering event.

[0169] The dashcam deletes the temporary pre-protection marker of the target pending video and removes the protection status of the target pending video. Occupancy locking refers to the write permission restriction imposed on the storage block of the loop recording buffer occupied by the target pending video. Occupancy locking is achieved in step S205 by locking the write permission of the storage block.

[0170] The dashcam unlocks the occupancy of the target pending video by clearing the protection flag bit of the corresponding storage block in the ring address list or deregistering the protection area in the storage management module, thus restoring these storage blocks to a writable state.

[0171] After the lock is released, the loop recording buffer's loop overwrite mechanism can normally overwrite the video data in these storage blocks. The target video will participate in the loop overwrite process as a regular dashcam video. The dashcam will also delete the virtual index list and virtual file object created for the target video, releasing related system resources.

[0172] Through steps S201 to S215 above, the vehicle recording video storage control method provided by the present invention realizes intelligent identification and reliable storage of collision event videos, effectively reduces the probability of accidental locking, and ensures that key accident video evidence can be reliably stored when a traffic accident actually occurs.

[0173] In some application scenarios, when a vehicle is stationary (speed 0) and violently rear-ended, the inertial sensor triggers a threshold (generating suspected collision information). However, because the initial speed is 0, the calculated theoretical braking time may be 0 or an invalid value. More importantly, at the moment of impact, the vehicle's speed abruptly changes from 0 to a forward instantaneous velocity, subsequently stopping due to the driver applying the brakes or the exhaustion of collision energy. This "stationary-acceleration-stop" speed change characteristic may deviate from the preset collision event deceleration model (i.e., monotonic deceleration characteristic). Therefore, the aforementioned severe passive rear-end collision accidents are easily misjudged as false triggers because the rate of speed change does not conform to the collision event deceleration model, leading to automatic unlocking and the loss of crucial evidence.

[0174] Therefore, after determining the initial trigger speed, the dashcam in this embodiment can also perform a traffic splitting judgment: if the initial trigger speed is less than the preset stationary judgment threshold (e.g., three kilometers per hour), the calculation based on the braking distance physical model will not be performed, but the passive displacement verification mode will be directly entered.

[0175] For example, when the inertial sensor signal exceeds the collision threshold, but the acquired vehicle speed parameters show an initial speed lower than a preset "stationary judgment threshold" (e.g., 3 km / h), the collision event deceleration model verification logic is automatically bypassed, and a passive displacement verification mode is activated instead. In this mode, the processor performs double integration in the time domain on the high-frequency acceleration data from the inertial sensor to calculate the vehicle's physical displacement vector over a short period. Simultaneously, it considers the vehicle's gear information (P / N / D) and brake pedal status. If the calculated physical displacement exceeds the non-autonomous movement threshold (e.g., a displacement of more than 0.5 meters occurs even when the brake pedal is depressed or the vehicle is in P gear), it is determined to be a passive collision, and the passive displacement verification mode is immediately activated.

[0176] In passive displacement verification mode, the dashcam performs the following operations:

[0177] (1) High-frequency inertial integration: The processor extracts the raw triaxial acceleration data of the inertial sensor within two seconds before and after the suspected collision time point at the highest sampling rate (e.g., 1000Hz). First, the gravitational acceleration component is removed using the quaternion algorithm. Then, the net acceleration data is integrated in the time domain for the first time to obtain the instantaneous velocity change. Finally, a second integration is performed to obtain the displacement vector in three-dimensional space.

[0178] (2) Constraint fusion: At the same time, the processor reads the vehicle's gear position signal and brake pedal signal.

[0179] (3) Abnormal displacement judgment: If the brake pedal is detected to be depressed or the gear is in parking gear (P gear), but the magnitude of the displacement vector calculated by the above-mentioned second integral exceeds the preset non-autonomous movement threshold (e.g., 0.3 meters), or the calculated instantaneous velocity change shows the pulse characteristics of "rapidly increasing in the positive direction and then rapidly falling back" (consistent with the passive force model), then a "passive collision confirmation signal" is directly generated.

[0180] (4) Logical merging: The “passive collision confirmation signal” has the same effect as the “user confirmation signal” in step S211 and can directly trigger the operation of changing the temporary pre-protection mark to a permanent lock mark.

[0181] This embodiment effectively fills the logical gap in existing deceleration models for scenarios where vehicles are passively impacted while stationary (such as being rear-ended while waiting at a red light). Through dual integration of high-frequency acceleration data, it can accurately quantify the non-autonomous physical displacement of the vehicle caused by a severe external impact under contradictory conditions where the initial vehicle speed is zero and the brake pedal is depressed. This allows for accurate identification of passive collision accidents that do not conform to conventional deceleration characteristics, completely avoiding the risk of such serious accidents being misjudged as false triggers and evidence being deleted due to logical defects. This greatly improves the completeness of evidence collection by dashcams in all scenarios.

[0182] The following describes an exemplary dashcam provided by an embodiment of the present invention. Figure 3 This is a schematic diagram of an exemplary hardware architecture of a dashcam provided in an embodiment of the present invention.

[0183] In some embodiments, the dashcam can be an electronic device, or the dashcam may include an electronic device. The electronic device includes a processor, memory, and a network interface connected via a system 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 an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data. The network interface communicates with other external terminals or servers via a network connection. In some embodiments, the network interface can be a wired network interface; in some embodiments, it can also be a wireless network interface. When the computer program is executed by the processor, it implements the methods described in the embodiments of the present invention.

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

[0185] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

[0186] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0187] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on an electronic device, all or part of the processes or functions described in the embodiments of the present invention are generated. The electronic device may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0188] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for controlling the storage of dashcam video, characterized in that, Applications in dashcams include: During the process of recording driving video and storing it in the loop recording buffer, the vehicle's inertial sensor signals and vehicle speed parameters are acquired. When the value of the inertial sensor signal exceeds a preset collision threshold, suspected collision event information is generated, including the time and location of the suspected collision event. Based on the suspected collision event information, extract the target video from the loop recording buffer. A temporary pre-protection marker is generated for the target video to be determined, and a status verification time window of a preset duration is opened; If, during the duration of the state verification time window, the rate of change of the vehicle's driving speed parameter is found to conform to the preset collision event deceleration model, or if a user confirmation signal is received from the vehicle confirming a collision event, then the temporary pre-protection mark of the target pending video is changed to a permanent lock mark. The target video to be determined is transferred to a preset anti-overwrite storage partition based on the permanent lock mark.

2. The method according to claim 1, characterized in that, After opening the preset duration state verification time window, the following is also included: If, during the duration of the state verification time window, the rate of change of the vehicle speed parameter is not detected to conform to the collision event deceleration model, or if the user confirmation signal is not received, then the temporary pre-protection mark of the target pending video is deleted, and the occupancy lock of the target pending video is released.

3. The method according to claim 1 or 2, characterized in that, The step of extracting the target video in the loop recording buffer based on the suspected collision event information includes: Based on the time of the suspected collision event, determine the start and end storage address pointers for the corresponding time period from the circular address list of the loop recording buffer. Construct a virtual index linked list containing the starting storage address pointer and the ending storage address pointer; The virtual index list is mapped to the target pending video, and the write permissions of the storage blocks between the start storage address pointer and the end storage address pointer in the circular address list are locked.

4. The method according to claim 3, characterized in that, The step of opening a state verification time window of a preset duration specifically includes: The initial trigger speed is determined based on the vehicle speed parameters at the time the suspected collision event information was generated. Using a preset vehicle braking distance physical model, the theoretical braking time required for the initial trigger speed to decay to zero is calculated; Based on the theoretical braking duration and the preset basic buffer duration, the duration of the state verification time window is determined, and countdown monitoring is started.

5. The method according to claim 4, characterized in that, If, during the duration of the state verification time window, the rate of change of the vehicle speed parameter is found to conform to a preset collision event deceleration model, the step of changing the temporary pre-protection marker of the target pending video to a permanent lock marker includes: Within the state verification time window, when the vehicle speed parameter is detected to be missing or its value is abnormally frozen, the video frame image at the current moment in the target pending video is called. Calculate the pixel feature point displacement vector between the current video frame and the previous video frame to obtain the visual optical flow velocity value; If the rate of change of the visual optical flow velocity value is found to match the collision event deceleration model, the temporary pre-protection marker is changed to a permanent lock marker.

6. The method according to claim 5, characterized in that, The step of calculating the pixel feature point displacement vector between the current video frame image and the previous video frame image to obtain the visual optical flow velocity value specifically includes: The video frame image is divided into a region of interest located in the center of the image and a background reference region located on the periphery of the image according to a preset geometric ratio; Pixel feature points within the region of interest are masked, and pixel feature points within the background reference region are used as valid calculation samples. Calculate the weighted average of the horizontal divergence component or the vertical backward component of the effective calculation sample along the image coordinate system between consecutive video frames, and determine the weighted average as the visual optical flow velocity value.

7. The method according to claim 1, characterized in that, After generating a temporary pre-protection marker for the target video, the method further includes: In the target video to be determined, locate the video keyframe image that is closest to the time point of the suspected collision event; The keyframe images of the video are copied and written to a preset non-volatile storage unit as an emergency evidence snapshot independent of the loop recording buffer.

8. A dashcam, characterized in that, Includes one or more processors and memory; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the dashcam to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed on the dashcam, the dashcam performs the method as described in any one of claims 1-7.

10. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed on the dashcam, the dashcam performs the method as described in any one of claims 1-7.

Images