Vehicle-mounted video cloud storage method and system, electronic equipment and storage medium

Abstract

The invention provides a vehicle-mounted video cloud storage method and system, an electronic device and a storage medium, and the method comprises the steps: firstly obtaining vehicle state information and a lightering plan of an appointed date, and triggering an automatic uploading task when a vehicle is in an ignition state, a terminal is online, and the current time is not in a lightering time period or earlier than the earliest lightering plan starting time of the day; meanwhile, the historical date of the unfinished video is recorded through the cache of the date needing supplementary transmission, and automatic checking and supplementary transmission are carried out; then querying a local video list of the cloud server and the terminal, preferentially selecting channels which are never uploaded and are not being uploaded, if no idle channel exists, selecting a channel with the earliest last uploading time, then taking the last successful uploading time or the earliest lightering plan starting time of the channel as a starting point, generating suggested ending time in combination with a preset segmentation duration, and performing subdivision on the suggested ending time; and comparing the end time of the current first lightering plan working time period with the actual recording end time of the local video, and determining an uploading time window by taking the earliest value, so that the integrity of key video data can be improved.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of interdisciplinary technology of artificial intelligence and smart hardware, and in particular to a method, system, electronic device and storage medium for in-vehicle video cloud storage. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology, the storage and management of in-vehicle video data (such as videos collected by dashcams and in-vehicle monitoring hosts) has become a crucial link in ensuring vehicle operation safety, facilitating accident tracing, and obtaining evidence in cargo disputes. Currently, the in-vehicle video cloud storage field generally adopts a passive data upload mode. Its core process is as follows: after the in-vehicle terminal device completes registration and online access to the network platform via vehicle ignition and power-on, the system automatically initiates a preset data synchronization process, completely uploading the latest video data cached in the device's local storage medium (such as a TF card or internal hard drive) to a remote cloud server. Simultaneously, some solutions support users initiating on-demand requests via mobile apps or web clients. While responding to real-time audio and video transmission needs, the cloud platform simultaneously uploads the transmitted recording files to the cloud for backup. The core purpose of this mode is to achieve centralized management of distributed local video data, breaking the limitations of physical storage medium capacity and geographical location, and providing vehicle owners or fleet managers with a unified platform for post-event review and evidence collection.

[0003] Chinese invention patent CN115113808A discloses a method, apparatus, vehicle, and readable storage medium for in-vehicle video storage. It focuses on the optimized utilization of local storage space and proposes a hierarchical storage scheme based on video content characteristics and driving status. Specifically, the scheme cuts continuously recorded videos from in-vehicle devices into segments of preset duration. It extracts feature vectors from each segment using an algorithm to calculate "uniqueness" (i.e., similarity to already stored videos), and combines this with driving status information such as rapid acceleration and braking to classify the video content by value. Subsequently, high-value videos with strong uniqueness or those related to specific driving events are stored in a protected first storage space, while ordinary videos are stored in a reusable storage area. When the protected storage space is about to run out, the system proactively outputs a capacity reminder, thereby maximizing the retention of video data with long-term value within limited local storage resources.

[0004] The aforementioned CN115113808A patent solution is limited to local storage optimization and does not involve collaborative management of video data and the cloud. It lacks cloud interaction mechanisms such as network status monitoring, transmission queue management, and breakpoint resume, which means that when vehicles enter network blind spots such as underground garages and remote areas, even if high-value videos are identified, they cannot be started or uploaded. Critical data remains locally for a long time, facing the risk of loss due to equipment damage or repeated overwriting. On the other hand, existing passive upload modes (such as "upload upon login" and "upload with on-demand") do not dynamically adjust upload strategies based on vehicle operation plans and network costs. Upload behavior may occur in high-cost cellular network environments or due to signal interruption caused by vehicle movement, which increases user data costs and reduces upload success rate. In addition, the existing solutions have a single dimension for judging the value of videos, relying only on "uniqueness" or basic driving status, without incorporating custom rules for safety events (such as fatigue driving) and operational events. This can easily lead to repetitive but critical video data (such as frequently occurring violation segments) being classified as ordinary videos and lost, failing to meet the traceability needs in actual operation. Summary of the Invention

[0005] This invention provides a vehicle-mounted video cloud storage method, system, electronic device, and storage medium to solve the technical problems in the prior art, such as the lack of cloud collaboration mechanisms and network adaptability design leading to the easy retention and loss of key data, the waste of resources due to the lack of integration with vehicle operation plans, and the single dimension of video value judgment easily causing important data to be covered.

[0006] In a first aspect, embodiments of the present invention provide a method for in-vehicle video cloud storage, comprising: S1. Obtain vehicle status information and transport plan. If the vehicle status information indicates that the vehicle is in ignition and the vehicle-mounted intelligent terminal is online, and the transport plan indicates that the current time is not within any transport plan time period or is earlier than the start time of the earliest transport plan of the day, then proceed to S2. S2. Query the cloud server to obtain the list of videos that have been successfully stored in each channel of the specified vehicle intelligent terminal, prioritize the idle channel as the target channel, and record the uploading task to the upload task list. The system queries the list of video clips stored locally on the vehicle-mounted intelligent terminal, and uses the last successful upload time of the selected channel or the start time of the earliest shuttle transport plan of the day as the starting point, combined with the preset segment duration to generate a suggested upload end time; the suggested upload end time is compared with the end time of the first shuttle transport plan working time period after the current time and the actual recording end time of the video clips on the vehicle-mounted intelligent terminal, and the earliest end time is taken as the actual end time to determine the upload time window; S3. Send the upload task containing the vehicle intelligent terminal ID, channel number and the upload time window to the vehicle intelligent terminal. The vehicle intelligent terminal extracts the local video file of the specified time window and uploads it to the cloud server. At the same time, the task status is recorded in the upload task list. The task status is removed after receiving the upload success callback.

[0007] Preferably, the vehicle status information includes the online status of the in-vehicle intelligent terminal, positioning information, vehicle CAN bus data, and network status information; The vehicle CAN bus data includes the adaptive cruise control (ACC) signal, which is used to determine the vehicle's ignition or shutdown status. The network status information includes network type and signal strength.

[0008] As a preferred option, it also includes: By checking the historical dates corresponding to the incomplete video data in the cached needUploaded records, the system automatically checks the records in needUploaded, examines each historical date to see if the local video still exists, and starts uploading according to priority, uploading the incomplete video data to the cloud server; after the upload is complete, the corresponding record is removed from the cached dataset.

[0009] As a preferred option, it also includes: When the vehicle is off but still within the scheduled transport period, it enters the proxy upload mode, compares the metadata of the local video in the vehicle's smart terminal with that of the cloud server video, identifies missing segments and uploads only the differences, performing incremental synchronization and breakpoint resume transmission.

[0010] Preferably, the metadata includes the video's start time, end time, channel number, unique checksum, file size, and encoding format. Missing segments are determined by comparing the consistency of the metadata.

[0011] Preferably, in step S2, prioritizing the selection of an idle channel as the target channel specifically includes: Filter channels that have never been uploaded and are not currently being uploaded. If multiple channels that have never been uploaded and are not currently being uploaded are calculated, select the channel with the smallest channel number as the target upload channel. If all channels have already uploaded, select the channel with the earliest last upload time as the target upload channel.

[0012] Preferably, step S2 further includes, at the last successful upload time of the selected channel: Query the size of the video data to be uploaded for each channel. If there are multiple channels with the same last upload time, prioritize the channel with the smaller amount of video data to be uploaded.

[0013] Secondly, an embodiment of the present invention provides an in-vehicle video cloud storage system, comprising: The status acquisition module acquires vehicle status information and transport plan. If the vehicle status information indicates that the vehicle is in ignition and the on-board intelligent terminal is online, the transport plan indicates that the current time is not within any transport plan time period or is earlier than the start time of the earliest transport plan of the day. The upload channel and time selection module queries the cloud server to obtain a list of videos that have been successfully stored in each channel of the specified vehicle intelligent terminal, prioritizes the selection of idle channels as target channels, and records the tasks that are being uploaded to the upload task list; The system queries the list of video clips stored locally on the vehicle-mounted intelligent terminal, and uses the last successful upload time of the selected channel or the start time of the earliest shuttle transport plan of the day as the starting point, combined with the preset segment duration to generate a suggested upload end time; the suggested upload end time is compared with the end time of the first shuttle transport plan working time period after the current time and the actual recording end time of the video clips on the vehicle-mounted intelligent terminal, and the earliest end time is taken as the actual end time to determine the upload time window; The task distribution and execution module distributes the upload task, which includes the vehicle intelligent terminal ID, channel number, and the upload time window, to the vehicle intelligent terminal. The vehicle intelligent terminal extracts the local video file of the specified time window and uploads it to the cloud server. At the same time, the task status is recorded in the upload task list. The task status is removed after receiving the upload success callback.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the vehicle-mounted video cloud storage method as described in the first aspect of the present invention.

[0015] Fourthly, embodiments of the present invention provide a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the vehicle-mounted video cloud storage method as described in the first aspect of the present invention.

[0016] This invention provides a method, system, electronic device, and storage medium for in-vehicle video cloud storage. First, it acquires vehicle status information (including the online status of the in-vehicle intelligent terminal, location information, vehicle CAN bus data, etc., wherein the CAN bus data includes an ACC signal used to determine ignition / shutdown) and a transport plan for a specified date. An automatic upload task is triggered when the vehicle is ignited, the terminal is online, and the current time is outside the transport period or earlier than the earliest start time of the day's transport plan. Simultaneously, it records the historical dates of incomplete videos through a cache of dates requiring re-upload (needUploaded) and automatically checks for re-upload. Next, it queries the cloud server and the terminal's local video list. Prioritize channels that have never uploaded and are not currently uploading. If no channels are available, select the channel with the earliest last upload time. Then, using the last successful upload time or the earliest start time of the transport plan as the starting point, and combining this with preset segment durations, generate a suggested end time. Compare the end time of the first and second transport plan's working time slot with the actual end time of local video recording, and take the earliest value to determine the upload time window. When the vehicle is off but in the transport period, initiate proxy upload. Compare local and cloud video metadata (including start time, verification code, etc.) and only upload the differences. Record the task status through an upload task list (uploading). Remove the record after successful upload; if interrupted, move it to the re-upload cache. This method improves the integrity of critical video data, reduces traffic and storage resource waste, achieves highly automated operation and maintenance, and adapts to the needs of vehicle networking applications. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of an in-vehicle video cloud storage method according to an embodiment of the present invention; Figure 2 This is a detailed flowchart of the in-vehicle video cloud storage method according to an embodiment of the present invention; Figure 3 This is a block diagram of an in-vehicle video cloud storage system according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the physical structure according to an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a system, product, or device that includes a series of components or units is not limited to the listed components or units, but may optionally include unlisted components or units, or may optionally include other components or units inherent to such products or devices. In the description of this application, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] This invention provides a method for in-vehicle video cloud storage, such as... Figure 1 , Figure 2 As shown, it includes: S1. Obtain vehicle status information and transport plan. If the vehicle status information indicates that the vehicle is in ignition and the vehicle-mounted intelligent terminal is online, and the transport plan indicates that the current time is not within any transport plan time period or is earlier than the start time of the earliest transport plan of the day, then proceed to S2. S2. Query the cloud server to obtain the list of videos that have been successfully stored in each channel of the specified vehicle intelligent terminal, prioritize the idle channel as the target channel, and record the uploading task to the upload task list. The system queries the list of video clips stored locally on the vehicle-mounted intelligent terminal, and uses the last successful upload time of the selected channel or the start time of the earliest shuttle transport plan of the day as the starting point, combined with the preset segment duration to generate a suggested upload end time; the suggested upload end time is compared with the end time of the first shuttle transport plan working time period after the current time and the actual recording end time of the video clips on the vehicle-mounted intelligent terminal, and the earliest end time is taken as the actual end time to determine the upload time window; S3. Send the upload task containing the vehicle intelligent terminal ID, channel number and the upload time window to the vehicle intelligent terminal. The vehicle intelligent terminal extracts the local video file of the specified time window and uploads it to the cloud server. At the same time, the task status is recorded in the upload task list. The task status is removed after receiving the upload success callback.

[0024] Specifically, vehicle status information refers to the real-time vehicle operation and equipment-related data that the onboard system needs to collect. The transshipment plan specifies the vehicle's pre-set operational schedule for a designated date, including one or more working time periods. For example, a freight fleet might set a transshipment plan for a vehicle on October 25th as "8:00-12:00 transporting goods from warehouse A to port B, 14:00-18:00 returning from port B," where "8:00-12:00" and "14:00-18:00" are the working time periods. Regular automatic uploads are disabled during these working time periods. Onboard intelligent terminals are devices installed in vehicles for collecting and locally storing onboard video, such as dashcams and onboard monitoring hosts. They are the source carriers of video data and need to interact with the cloud server to upload data. The cloud server is a remote, centralized storage and management platform used to receive and store video data uploaded by various onboard intelligent terminals, and can query the list of stored videos and manage upload tasks. A channel is a logical port on an in-vehicle intelligent terminal used to distinguish different video acquisition sources. For example, if the terminal is connected to 4 cameras, there are 4 channels. Channel 1 captures video from the front of the vehicle, channel 2 captures video from the passenger compartment, and each channel's video is stored and uploaded independently.

[0025] Furthermore, idle channels are those that have never uploaded videos to the cloud server or have been uploaded but are not currently in an uploading state. They are defined as the union of the set of all channel numbers on the device, C_all, minus the set of channels that have completed uploading, C_uploaded, and the set of channels that are currently uploading, C_uploading.

[0026] The upload task list is a dynamic list maintained by the cloud server to record channel information for currently executing upload tasks, such as device ID: 001, channel 2, upload time period: 10:00-10:15. Its core function is to avoid repeatedly issuing upload commands to the same channel for the same device.

[0027] The local video clip list is a list of video files stored locally on the vehicle's intelligent terminal, recording key information for each video clip (such as start time, end time, corresponding channel, and file size) so that the system can query which local videos have not yet been uploaded.

[0028] The preset segment duration is the length of a single video upload (e.g., 15 minutes) set in advance by the system to avoid interruptions caused by uploading excessively large videos at once, thereby improving the upload success rate.

[0029] The upload time window is the effective time range of a single upload task (including the start point and the actual end point). It is necessary to ensure that the upload behavior does not occupy vehicle operating time and does not exceed the actual recording range of local video.

[0030] Furthermore, in step S1, by determining the dual status of vehicle ignition and terminal online status, it can be ensured that the vehicle-mounted intelligent terminal is powered on during upload (able to read local video data, avoiding the inability to retrieve data when the terminal is powered off) and maintains a network connection with the cloud server (able to transmit data to the cloud, avoiding upload interruption when offline). This avoids invalid operations caused by substandard device status leading to upload failure from the source, improves the initial success rate of upload tasks, and solves the resource waste problem of triggering uploads even when there is no network in the existing technology. By determining that the current time is not within any barge transport plan time period or is earlier than the earliest barge transport plan start time of the day, the upload task can be limited to vehicle operation gaps (such as between two operation periods) or before the start of operation, avoiding the occupation of network resources and terminal computing power during operation periods (such as freight vehicle transportation and delivery periods). One of the shortcomings of the existing technology is that uploading during non-work plan periods can easily lead to interference with real-time monitoring and dispatch command transmission during operation. This step precisely solves this problem, achieving the collaborative effect of uploading without affecting operation.

[0031] Furthermore, in step S2, on the one hand, by querying the cloud-stored video list to locate idle channels (channels that have never been uploaded or are not currently being uploaded), channels that have already been uploaded can be directly avoided, preventing duplicate upload operations on the same channel (e.g., if a channel has already uploaded a video of the train's cab, the upload command for that channel will not be issued again), reducing unnecessary traffic consumption and cloud storage redundancy; on the other hand, the upload task list records the channels that are currently uploading in real time, which can prevent multiple upload tasks from being issued to the same channel at the same time (e.g., if channel 2 is uploading a video of the train's cab, the upload command for the driver's cab will not be issued to it), avoiding conflicts between channel computing power and network resources. At the same time, by prioritizing idle channels, the upload frequency of each channel can be balanced (e.g., there will be no situation where channel 1 uploads frequently while channel 4 is idle for a long time), ensuring that the video data of all channels is updated synchronously in the cloud, solving the problem of data synchronization lag caused by disordered channel scheduling in existing technologies.

[0032] Query the list of video clips stored locally on the device (videoRecord1).

[0033] The starting point is the last successful upload time of the selected channel (or the start time of the transshipment plan).

[0034] Based on the preset segmentation duration (e.g., 15 minutes), a suggested upload end time (startTime + segmentation) is generated.

[0035] Compare the suggested time window with the following time boundaries, and take the earliest end time as the actual end time to ensure that it does not exceed the boundaries: a) The end time of the current barge transport schedule.

[0036] b) The natural end time of the video segment on the device.

[0037] Ultimately, a precise upload time window (startTime, endTime) that does not exceed the limits was determined.

[0038]

[0039] Objective: To determine the start and end times of video uploads to ensure alignment with planned times and device recording times.

[0040] Parameter description: • T_plan: The set of time periods for the barge transport plan (e.g., [10:00-12:00, 13:00-14:00]).

[0041] • T_device: The set of video time periods actually recorded by the device (e.g., [10:05-12:10, 13:05-14:15]).

[0042] • s: Segment duration (e.g., 15 minutes).

[0043] Logical decomposition: Start time T_start: Take the larger of the earliest plan start time in T_plan and the earliest device start time in T_device (e.g., max(10:00, 10:05) = 10:05).

[0044] End time T_end: The upload time cannot exceed the minimum of the following three: T_start + s (segment duration, e.g., 12:05 + 15 minutes = 12:20).

[0045] The latest planned end time in T_plan (e.g., 12:10).

[0046] The latest device end time in T_device (e.g., 12:00).

[0047] The result is min(12:20, 12:10, 12:00) = 12:00.

[0048] Example: If the planned time is 10:00-12:00, the device recording time is 10:05-12:10, and the segment duration is s=15, then the upload time is 10:05-10:20.

[0049] From the perspective of the starting point, taking the last successful upload time as the starting point can ensure that the upload task inherits the previously unuploaded data (e.g., if the last upload to channel 3 was at 10:00, this time it will start from 10:00, avoiding missing videos in the middle period); taking the earliest start time of the day's transport plan as the starting point can cover the initial video data before the start of operations, preventing data gaps; From the perspective of the endpoint, by comparing the three times and taking the earliest, the upload time can be strictly limited to not exceeding the vehicle operation boundary (e.g., if the end time of the first and last shuttle transport plan is 12:00, even if the suggested upload end time is 12:15, 12:00 will be the endpoint), avoiding the upload task occupying network and terminal resources during the operation period (e.g., when freight vehicles are transporting goods, real-time monitoring and dispatch instruction transmission will not be affected by video upload); at the same time, it will not exceed the actual recording range of the local video (e.g., if the local recording only goes up to 11:50, then 11:50 will be the endpoint), avoiding empty periods of upload without data, and improving upload efficiency.

[0050] By combining the design of generating suggested upload end times based on preset segment durations and the determination of precise time windows, the risk of upload interruption can be indirectly reduced. The preset segment duration (e.g., 15 minutes) is set based on the fluctuating nature of vehicle-to-everything (V2X) network signals, limiting the duration of a single upload task to a reasonable range (avoiding the complete failure of uploading a 1-hour video due to signal interruption). Even in the event of a brief network interruption, only the current segment (e.g., the last 5 minutes of the 15 minutes) needs to be re-uploaded, rather than the entire long video, significantly improving the upload success rate in weak network environments. Simultaneously, the clearly defined upload time window allows the in-vehicle intelligent terminal to prepare local video files for the corresponding time period in advance (without temporarily retrieving large amounts of historical data), reducing terminal computing power consumption and further ensuring the stability of the upload process. This addresses the shortcomings of existing technologies where large single upload volumes and undefined time boundaries lead to high interruption rates.

[0051] Furthermore, in step S3, the generated upload task (including device ID, channel number, and precise time window) is sent to the vehicle-mounted device.

[0052] After receiving the instruction, the device extracts the video file for the specified time window from the local storage and uploads it to the cloud server.

[0053] The task status is recorded in the upload task list uploading until a successful upload callback is received, at which point it is removed.

[0054] The task status is maintained in the list during execution, allowing for real-time tracking of incomplete tasks. (For example, if the system periodically checks the list and finds that the task on terminal 002-channel 2 is in the upload process for an extended period, it can be determined that the upload has been interrupted.) The task status is only removed after the cloud server confirms that the video upload was successful (by receiving a callback notification). If no callback is received (e.g., due to network interruption causing upload failure), the task status will remain in the list, and subsequent re-upload logic can be triggered to retrieve the video from the terminal's local storage and upload it again. This avoids the loss of critical data due to upload interruption and solves the shortcomings of existing technologies where upload status is not tracked and cannot be traced after interruption.

[0055] Based on the above embodiments, as a preferred implementation, the vehicle status information includes the online status of the in-vehicle intelligent terminal, positioning information, vehicle CAN bus data, and network status information; The vehicle CAN bus data includes the adaptive cruise control (ACC) signal, which is used to determine the vehicle's ignition or shutdown status. The network status information includes network type and signal strength.

[0056] Specifically, being online is a fundamental prerequisite for uploading. If the terminal is offline (e.g., not connected to the network or the network is interrupted), even if the vehicle is started and there is video data, the data cannot be transmitted to the cloud server. Therefore, determining that the in-vehicle intelligent terminal is online is one of the necessary conditions for triggering an upload. For example, when a freight vehicle enters an underground tunnel, the network connection between the terminal and the cloud server is interrupted, and the terminal status becomes offline. At this time, the system will pause the upload task. When the vehicle leaves the tunnel and the terminal re-establishes a connection with the cloud server (the status returns to online), if the vehicle is started and it is not during the operating period, the upload will be triggered.

[0057] Location information can help optimize upload strategies. For example, the system can use location information to determine whether a vehicle is in the operating area of ​​the transshipment plan (such as the route from warehouse A to port B). If the vehicle deviates from the operating area (such as temporarily stopping in a remote service area without signal), a retransmission task can be triggered first (using the stop time to upload historical data); if it is in the operating area and during non-operating hours, it will be uploaded according to the normal logic.

[0058] When the vehicle is ignited, the onboard intelligent terminal can receive a stable power supply and read locally stored video data normally (after the engine is turned off, the terminal may enter a low-power mode or lose power, making data retrieval impossible). Simultaneously, ignition status usually indicates that the vehicle is in an operational or temporarily parked state, possessing the hardware foundation for uploading data. When the driver inserts the key to start the ignition, the ACC signal goes high, and the system determines that the vehicle is ignited. If the terminal is online at this time and the current time is earlier than the earliest scheduled start time of the day (e.g., 7:30, scheduled to start operation at 8:00), then condition S1 is met, and the system enters condition S2. If the driver turns off the engine and stops the vehicle (ACC signal goes low), even if the terminal is still online, the system will pause uploading to prevent data transmission interruption due to power failure.

[0059] Network status information indirectly affects the execution of upload tasks. If the network type is Wi-Fi (low cost) and the signal strength is strong (e.g., -60dBm), the upload task will be executed first. If the network type is 5G (high data cost) and the signal strength is weak (e.g., -110dBm), even if the S1 condition is met, the system may postpone the upload until the network status is optimized to avoid wasting data and interrupting the upload.

[0060] Based on the above embodiments, as a preferred implementation, step S2 further includes: By checking the historical dates corresponding to the incomplete video data in the cached needUploaded records, the system automatically checks the records in needUploaded, examines each historical date to see if the local video still exists, and starts uploading according to priority, uploading the incomplete video data to the cloud server; after the upload is complete, the corresponding record is removed from the cached dataset.

[0061] Specifically, needUploaded needs to record the historical dates corresponding to incomplete video data. However, the upload task needs to include the vehicle intelligent terminal ID, channel number, and upload time window. Simply recording the historical date is insufficient for accurate re-upload. Therefore, it is necessary to supplement and record multi-dimensional correlation information to ensure that the unuploaded data can be located in a specific device, channel, and time period in the future. Basic identifiers: Vehicle intelligent terminal ID (to distinguish terminals in different vehicles and avoid data confusion across devices), and video corresponding channel number; Time information: The historical date of the incomplete upload + the specific time period (not a single date, such as October 25th 10:15-10:30. If the video upload during this time period fails due to network interruption at 10:22, then the complete record is October 25th 10:15-10:30). Interruption flag: Records the reason for the interruption (such as network interruption, terminal offline) to provide a basis for subsequent priority scheduling.

[0062] Triggering timing: When the vehicle status meets the standard: When the vehicle is started and the in-vehicle smart terminal is online, the system will simultaneously start the needUploaded check (if the vehicle is turned off and then restarted, and the terminal is back online, historical unuploaded data will be processed first to avoid conflict with the current automatic upload task). When optimizing network status: When the terminal network recovers from weak signal / offline to strong signal / online (such as when a vehicle leaves an underground garage or enters a service area to access Wi-Fi), needUploaded should also be checked. Scheduled periodic checks: The system checks at fixed intervals (e.g., every 24 hours) to avoid data backlog caused by the failure to trigger the above scenarios for a long time.

[0063] needUploaded tracks all incomplete uploads through precise recording, automatic checking, and breakpoint resumption. Even with multiple interruptions, it can continuously re-upload data by updating the interrupted nodes, ensuring that critical videos such as operational data and accident footage in the transshipment plan are ultimately uploaded to the cloud, thus avoiding the loss of critical data.

[0064] Based on the above embodiments, as a preferred implementation, it further includes: When the vehicle is off but still within the scheduled transport period, it enters the proxy upload mode, compares the metadata of the local video in the vehicle's smart terminal with that of the cloud server video, identifies missing segments and uploads only the differences, performing incremental synchronization and breakpoint resume transmission.

[0065] Not all scenarios where the vehicle is off during the scheduled transport period will trigger proxy uploads. Two core prerequisites must be met to ensure the reasonableness of the mode activation: The in-vehicle intelligent terminal remains online and has data reading capabilities. The in-vehicle intelligent terminal is the carrier for local video storage and uploading. After the vehicle is turned off (ACC signal is low level), the terminal needs to be in a low-power online state (such as some in-vehicle terminals that support maintaining network connection and local storage access for a short time after the engine is turned off). If the terminal is offline with the vehicle turned off and power is cut off, it cannot read local video and naturally cannot trigger proxy uploading. Within the effective working period of the barge transport plan, which includes one or more specific working periods (e.g., 8:00-12:00 and 14:00-18:00 on October 25), the agent upload will only be triggered within this time period (e.g., if the vehicle is turned off at 8:30 due to temporary unloading, it is still within the 8:00-12:00 working period). If it exceeds this time period (e.g., if the vehicle is turned off at 12:30, it has already passed the morning working period), this mode will not be activated to avoid occupying the terminal standby resources during non-operational periods.

[0066] Based on metadata comparison results, missing segments that exist locally but not in the cloud are identified. The specific judgment rules perfectly align with the design goal of uploading only the differing parts of the file. If there is no metadata record for the corresponding channel number and time range in the cloud (e.g., there is video metadata for channel 1, 8:10-8:15, but no record in the cloud), it is determined to be a completely missing segment, and the complete video segment must be uploaded. If the cloud has corresponding metadata, but the unique check code does not match (e.g., the local video has changed due to abnormal recording, or the cloud record is incomplete due to the previous upload interruption), it is judged as "content missing / abnormal segment", and the video for that period of time needs to be re-uploaded; If the cloud metadata is completely consistent with the local metadata (start / end time, channel number, and verification code all match), it is determined that the segment has been completely uploaded, and this part is skipped to avoid duplicate transmission.

[0067] The time period for the transshipment plan is the core period of vehicle operation (such as loading and unloading of freight vehicles and passenger carrying time for passenger vehicles). The videos generated during this period (such as cargo loading and unloading monitoring and passenger safety monitoring) are key traceability data. In existing technologies, real-time monitoring must be prioritized when the vehicle is in operation (ignition state), and uploading cannot be initiated, which can easily lead to data backlog. The proxy upload mode utilizes the gaps when the vehicle is temporarily parked after being turned off (such as unloading and passenger boarding and alighting) to supplement and upload the data for this period without affecting operations. This avoids data remaining locally for a long time (which may be lost due to storage overwriting or equipment failure) and ensures that the key videos in the transshipment plan are eventually synchronized to the cloud.

[0068] The proxy upload mode is strictly limited to the period when the vehicle is off but still within the scheduled transport time. This utilizes the temporary idle window during operating hours while avoiding interference with the core operation of the vehicle. When the vehicle is in operation (such as while driving or loading / unloading), the terminal prioritizes real-time video acquisition and operation-related functions (such as receiving dispatch instructions) and does not initiate uploading. The agent upload is only initiated when the vehicle is temporarily parked with the engine off (non-operational operation) and within the time limit of the transfer plan. The intelligent scheduling logic of the upload task is driven by the transfer plan to achieve the synergistic effect of operation priority and idle supplementary upload.

[0069] Based on the above embodiments, as a preferred implementation, the metadata includes the video's start time, end time, channel number, unique checksum, file size, and encoding format. Missing segments are determined by comparing the consistency of the metadata.

[0070] Based on the above embodiments, as a preferred implementation, step S2, which prioritizes selecting an idle channel as the target channel, specifically includes: Filter channels that have never been uploaded and are not currently being uploaded. If multiple channels that have never been uploaded and are not currently being uploaded are calculated, select the channel with the smallest channel number as the target upload channel. If all channels have already uploaded, select the channel with the earliest last upload time as the target upload channel.

[0071] Specifically, query the cloud server to obtain the list of videos (videoRecord2) that have been successfully stored on each channel of the specified device.

[0072] First priority: Channels that have never uploaded videos.

[0073] Second priority: If all channels have already uploaded videos, then the channel with the earliest last upload time will be selected. This ensures that the video data for each channel is updated synchronously in the cloud as much as possible.

[0074] A static list (uploading) records the tasks that are currently being uploaded, avoiding the repeated issuance of upload commands to the same channel on the same device.

[0075]

[0076] Objective: Select a channel from all available channels that is neither currently uploading nor has an upload function. If no channel is available, select the channel that completed its upload earliest.

[0077] Parameter description: • C_all: The set of all channel numbers configured for the device (e.g., [1, 2, 3, 4]).

[0078] • C_uploaded: The set of channels that have been uploaded (e.g., [1, 2]).

[0079] • C_uploading: The set of channels currently uploading (e.g., [3]).

[0080] • t_end(c): The timestamp of the last upload ended for channel c.

[0081] Logical decomposition: Prioritize using idle channels: Calculate C_all - (C_uploaded ∪ C_uploading), which represents channels that have never been uploaded or are not currently being uploaded.

[0082] If the result is not empty, select the smallest channel number (e.g., [4], select channel 4).

[0083] When all channels are occupied: Find the channel with the smallest t_end(c) among all channels (i.e. the channel that completed the upload earliest) and start a new task.

[0084] Example: If C_all = [1,2,3,4], C_uploaded = [1,2], and C_uploading = [3], then the available channel is [4], and channel 4 is selected.

[0085] If all channels are uploading or have already uploaded, compare the t_end(c) of each channel and select the channel that finished earliest (e.g., if channel 2 finishes at 10:00 and channel 3 finishes at 10:05, select channel 2). Based on the above embodiments, as a preferred implementation, step S2 further includes, when the last successful upload time of the selected channel is reached: Query the size of the video data to be uploaded for each channel. If there are multiple channels with the same last upload time, prioritize the channel with the smaller amount of video data to be uploaded.

[0086] By prioritizing channels with smaller amounts of data to be uploaded, the size of data packets for a single upload task can be controlled within a more reasonable range. Small data transmissions take less time (e.g., a 100MB video takes about 1-2 minutes to complete on a 4G network, while a 1GB video takes 10-20 minutes). This is better suited to the short network stability window in vehicle scenarios (e.g., a vehicle temporarily stops for 5 minutes and the signal is briefly restored), significantly reducing the probability of network interruptions due to excessive transmission time and indirectly reducing the need for subsequent retransmission tasks.

[0087] Secondly, an embodiment of the present invention provides an in-vehicle video cloud storage system, based on the in-vehicle video cloud storage method in the above-mentioned format example, such as... Figure 3 As shown, it includes: The status acquisition module 310 acquires vehicle status information and a transport plan. If the vehicle status information indicates that the vehicle is in ignition and the vehicle-mounted intelligent terminal is online, the transport plan indicates that the current time is not within any transport plan time period or is earlier than the start time of the earliest transport plan of the day. The upload channel and time selection module 320 queries the cloud server to obtain the list of videos that have been successfully stored in each channel of the specified vehicle intelligent terminal, prioritizes the selection of idle channels as target channels, and records the tasks that are being uploaded to the upload task list. The system queries the list of video clips stored locally on the vehicle-mounted intelligent terminal, and uses the last successful upload time of the selected channel or the start time of the earliest shuttle transport plan of the day as the starting point, combined with the preset segment duration to generate a suggested upload end time; the suggested upload end time is compared with the end time of the first shuttle transport plan working time period after the current time and the actual recording end time of the video clips on the vehicle-mounted intelligent terminal, and the earliest end time is taken as the actual end time to determine the upload time window; The task distribution and execution module 330 distributes the upload task, which includes the vehicle intelligent terminal ID, channel number and the upload time window, to the vehicle intelligent terminal. The vehicle intelligent terminal extracts the local video file of the specified time window and uploads it to the cloud server. At the same time, the task status is recorded in the upload task list. The task status is removed after receiving the upload success callback.

[0088] Based on the same concept, this invention also provides a schematic diagram of a physical structure, such as... Figure 4 As shown, the server may include a processor 410, a communications interface 420, a memory 430, and a communication bus 440. The processor 410, communications interface 420, and memory 430 communicate with each other via the communication bus 440. The processor 410 can call logical instructions stored in the memory 430 to execute the steps of the in-vehicle video cloud storage method as described in the above embodiments.

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

[0090] Based on the same concept, embodiments of the present invention also provide a non-transitory computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a master control device to control the master control device to implement the steps of the vehicle-mounted video cloud storage method as described in the above embodiments.

[0091] Based on the same technical concept, this application also provides a computer program, which, when executed by a main control device, is used to implement the above-described method embodiments.

[0092] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

[0093] Based on the same technical concept, this application also provides a processor for implementing the above-described method embodiments. The processor can be a chip.

[0094] The various embodiments of the present invention can be combined arbitrarily to achieve different technical effects.

[0095] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can 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 can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can 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).

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

[0097] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; 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; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for in-vehicle video cloud storage, characterized in that, include: S1. Obtain vehicle status information and transport plan. If the vehicle status information indicates that the vehicle is in ignition and the vehicle-mounted intelligent terminal is online, and the transport plan indicates that the current time is not within any transport plan time period or is earlier than the start time of the earliest transport plan of the day, then proceed to S2. S2. Query the cloud server to obtain the list of videos that have been successfully stored in each channel of the specified vehicle intelligent terminal, prioritize the idle channel as the target channel, and record the uploading task to the upload task list. The system queries the list of video clips stored locally on the vehicle's intelligent terminal, and generates a suggested upload end time based on the last successful upload time of the selected channel or the start time of the earliest transport plan of the day, combined with the preset segment duration. The suggested upload end time is compared with the end time of the first barge transport plan working period after the current time and the actual recording end time of the local video segment of the vehicle-mounted smart terminal. The earliest end time is taken as the actual end time to determine the upload time window. S3. Send the upload task containing the vehicle intelligent terminal ID, channel number and the upload time window to the vehicle intelligent terminal. The vehicle intelligent terminal extracts the local video file of the specified time window and uploads it to the cloud server. At the same time, the task status is recorded in the upload task list. The task status is removed after receiving the upload success callback.

2. The vehicle-mounted video cloud storage method according to claim 1, characterized in that, The vehicle status information includes the online status of the in-vehicle intelligent terminal, positioning information, vehicle CAN bus data, and network status information; The vehicle CAN bus data includes the adaptive cruise control (ACC) signal, which is used to determine the vehicle's ignition or shutdown status. The network status information includes network type and signal strength.

3. The vehicle-mounted video cloud storage method according to claim 1, characterized in that, Also includes: By recording the historical dates of incomplete video data in the cached needUploaded records, the system automatically checks the records in needUploaded, checks each historical date to see if the local video still exists, and starts uploading according to priority, supplementing the incomplete video data and uploading it to the cloud server. After the upload is complete, remove the corresponding record from the cached dataset.

4. The vehicle-mounted video cloud storage method according to claim 1, characterized in that, Also includes: When the vehicle is off but still within the scheduled transport period, it enters the proxy upload mode, compares the metadata of the local video in the vehicle's smart terminal with that of the cloud server video, identifies missing segments and uploads only the differences, performing incremental synchronization and breakpoint resume transmission.

5. The vehicle-mounted video cloud storage method according to claim 4, characterized in that, The metadata includes the video's start time, end time, channel number, unique checksum, file size, and encoding format. Missing segments are determined by comparing the consistency of the metadata.

6. The vehicle-mounted video cloud storage method according to claim 1, characterized in that, In step S2, prioritizing the selection of an idle channel as the target channel specifically includes: Filter channels that have never been uploaded and are not currently being uploaded. If multiple channels that have never been uploaded and are not currently being uploaded are calculated, select the channel with the smallest channel number as the target upload channel. If all channels have already uploaded, select the channel with the earliest last upload time as the target upload channel.

7. The vehicle-mounted video cloud storage method according to claim 1, characterized in that, In step S2, when the last successful upload time of the selected channel is reached, the following is also included: Query the size of the video data to be uploaded for each channel. If there are multiple channels with the same last upload time, prioritize the channel with the smaller amount of video data to be uploaded.

8. A vehicle-mounted video cloud storage system, characterized in that, include: The status acquisition module acquires vehicle status information and transport plan. If the vehicle status information indicates that the vehicle is in ignition and the on-board intelligent terminal is online, the transport plan indicates that the current time is not within any transport plan time period or is earlier than the start time of the earliest transport plan of the day. The upload channel and time selection module queries the cloud server to obtain a list of videos that have been successfully stored in each channel of the specified vehicle intelligent terminal, prioritizes the selection of idle channels as target channels, and records the tasks that are being uploaded to the upload task list; The system queries the list of video clips stored locally on the vehicle's intelligent terminal, and generates a suggested upload end time based on the last successful upload time of the selected channel or the start time of the earliest transport plan of the day, combined with the preset segment duration. The suggested upload end time is compared with the end time of the first barge transport plan working period after the current time and the actual recording end time of the local video segment of the vehicle-mounted smart terminal. The earliest end time is taken as the actual end time to determine the upload time window. The task distribution and execution module distributes the upload task, which includes the vehicle intelligent terminal ID, channel number, and the upload time window, to the vehicle intelligent terminal. The vehicle intelligent terminal extracts the local video file of the specified time window and uploads it to the cloud server. At the same time, the task status is recorded in the upload task list. The task status is removed after receiving the upload success callback.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the vehicle-mounted video cloud storage method as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the in-vehicle video cloud storage method as described in any one of claims 1 to 7.

Images