A locomotive 6A system-based video stream remote transmission method, system and terminal

Abstract

The application relates to a locomotive 6A system-based video stream remote transmission method, system and terminal, and belongs to the technical field of video processing. The video stream remote transmission method takes a vehicle-mounted buffer pool as an execution subject and comprises the following steps: collecting real-time running data of a locomotive and environmental data of a locomotive driving area; according to the environmental data, screening a risk type corresponding to the locomotive from a risk library; according to the real-time running data and the environmental data, generating a predicted risk score corresponding to the screened risk type; if there is a risk type with a predicted risk score greater than a risk score threshold, sending an encrypted video associated with the risk type to a server, wherein the encrypted video comprises real-time video and historical video; the server is used for pushing the encrypted video to a client, and the client plays the encrypted video after decryption. The application has the beneficial effect of realizing early warning of a risk event.

Description

Technical Field

[0001] This application relates to the technical field of video processing, and in particular to a method, system and terminal for remote transmission of video streams based on the Locomotive 6A system. Background Technology

[0002] With the continuous improvement of my country's railway transportation capacity and the sustained increase in train operating speed, higher requirements have been placed on the real-time monitoring of train operation safety and status. Especially in operating environments with complex terrain, severe weather, and frequent emergencies, achieving comprehensive perception of train operation status and intelligent identification and timely response to potential risks has become a key issue in ensuring railway transportation safety. The locomotive onboard safety protection system (6A system), as an important technical means to ensure locomotive operation safety, has been widely applied throughout the railway system. Among them, the video subsystem, as an important component of the 6A system, undertakes the crucial responsibility of real-time monitoring of driver operations, equipment status, and the external environment.

[0003] In current railway industry applications, video recording and remote transmission mechanisms based on fixed times or events are commonly used. For example, in the event of emergency braking, abnormal door opening, or driver misconduct, the system will automatically trigger video recording and upload it to the ground monitoring center.

[0004] Although existing technologies have enabled remote transmission of video data and event retrieval to some extent, video retrieval strategies are still passive responses, resulting in delayed or redundant video resource retrieval and failing to provide early warning of risk events. Summary of the Invention

[0005] To enable early warning of risk events, this application provides a method for remote transmission of video streams based on the locomotive 6A system.

[0006] Firstly, this application provides a method for remote transmission of video streams based on the locomotive 6A system, employing the following technical solution:

[0007] A method for remote transmission of video streams based on a locomotive 6A system, using an onboard buffer pool as the execution entity, includes:

[0008] Collect real-time operating data of the locomotive and environmental data of the locomotive's operating area;

[0009] Based on the environmental data, the risk type corresponding to the locomotive is selected from the risk database;

[0010] Based on the real-time operational data and the environmental data, a predicted risk score is generated corresponding to the selected risk type.

[0011] If there is a risk type whose predicted risk score is greater than the risk score threshold, then an encrypted video associated with that risk type is sent to the server. The encrypted video includes real-time video and historical video. The server is used to push the encrypted video to the client, and the client decrypts and plays the encrypted video.

[0012] By adopting the above technical solution, the onboard buffer pool first achieves comprehensive perception of the operating status by collecting real-time operating data of the locomotive and environmental data of the operating area, providing a detailed data foundation for subsequent risk assessment. Subsequently, based on the collected environmental information, the onboard buffer pool intelligently matches and filters risk types associated with the current operating scenario from a pre-set risk database, thereby achieving dynamic identification and classification of risk types. On this basis, combined with locomotive operating status parameters and environmental factors, the onboard buffer pool further generates quantitative scores for each type of risk. By setting reasonable risk thresholds, it determines whether there are any safety hazards requiring special attention. Once the score of a certain type of risk exceeds the warning threshold, the onboard buffer pool immediately triggers a video transmission mechanism, extracting encrypted video resources related to that risk type, including real-time camera footage and historical images before the event, ensuring the integrity and traceability of the information. The extracted video data is transmitted to the server through a secure channel, and then from the server to the remote client. After completing identity authentication and key decryption, the client enables real-time playback and analysis of the video, thereby allowing the remote dispatch center or safety management personnel to immediately grasp and intervene in potential risk events. This method not only realizes the linkage mechanism between risk identification and video retrieval, but also ensures the security and privacy of video transmission through data encryption and access control.

[0013] Optionally, the step of generating predicted risk scores corresponding to the selected risk types based on the real-time operational data and the environmental data includes:

[0014] Construct a risk assessment model and a risk factor mapping table;

[0015] The real-time operating data and the environmental data are input into the risk assessment model to output an initial predicted value;

[0016] Based on the current environmental data and the real-time status of the locomotive, the matching risk factors and their weights are extracted from the mapping table to correct the initial prediction value.

[0017] By adopting the above technical solutions, and through data-driven model calculations and dynamic factor corrections, the subjectivity of manual assessments is avoided, enabling a quantitative characterization of potential risks. Real-time data input and automated score generation processes shorten the risk assessment cycle, buying time for emergency response and achieving a shift from passive response to proactive early warning.

[0018] Optionally, the step of sending the encrypted video associated with this risk type to the server includes:

[0019] Determine the radius of curvature of the locomotive's running track;

[0020] The video retrieval duration is calculated based on the video bitrate, the radius of curvature, and the real-time running data.

[0021] Based on the video retrieval duration, retrieve historical videos associated with this risk type and send them to the server.

[0022] By adopting the above technical solution, the high-risk spatial range is locked by the radius of curvature, and the duration is dynamically calculated by combining the bit rate and running data, avoiding redundancy caused by full video retrieval, and enabling risk analysis to focus on key segments.

[0023] Optionally, the video stream remote transmission method further includes:

[0024] If there is no risk type whose predicted risk score is greater than the risk score threshold, then retrieve the historical occurrence count, false alarm count, and resolution time of the corresponding risk type from the risk database;

[0025] Based on the historical occurrence count, the false alarm count, and the resolution time, a corrected prediction value corresponding to the risk type is generated;

[0026] If there is a risk type whose corrected predicted value is greater than the corrected threshold, then send the encrypted video associated with that risk type to the server.

[0027] By adopting the above technical solution, when no risk type with a predicted risk score greater than the threshold exists, historical data such as the frequency of occurrence, false alarms, and resolution time for the corresponding risk type are retrieved from the risk database. Based on this historical data, a revised predicted value is generated. This allows risk assessment to move beyond relying solely on a single predicted score, comprehensively considering factors such as the frequency of risk occurrence, false alarms, and resolution difficulty. This enables more accurate assessment of various risks, reduces misjudgments caused by single assessment indicators, and thus helps identify potential high-risk types in advance. It also helps filter out situations that appear risky but have a low probability of occurrence or minimal impact, making risk warnings more precise and targeted, and avoiding resource waste and distraction caused by over-warning.

[0028] Optionally, the steps following the generation of the revised forecast value corresponding to the risk type also include:

[0029] If there is no risk type whose revised predicted value is greater than the revised threshold, then construct the risk curve corresponding to the risk type.

[0030] Based on the risk curve, obtain the approximation rate of the predicted risk value for the corresponding risk type to the risk score threshold;

[0031] Based on the approximation rate, adjust the monitoring frequency for the corresponding risk type.

[0032] By employing the aforementioned technical solutions, risk curves corresponding to different risk types can be constructed, providing an intuitive graphical representation of risk trends over time or due to other factors. Compared to single numerical values, graphs are easier to understand and analyze, allowing relevant personnel to quickly grasp the development trend of risks, including increases, decreases, or fluctuations, thus gaining a more comprehensive and in-depth understanding of the risks. Even if the current revised forecast value does not exceed the revision threshold, the curve's trend can indicate whether the risk is gradually approaching the risk threshold, helping to identify potential risks in advance and providing sufficient time and preparation for subsequent risk response. The dynamic adjustment of monitoring frequency based on the approach rate allows for the rational allocation of monitoring resources according to the actual situation of the risks. This avoids uniform, fixed-frequency monitoring of all risk types, enabling resources to be concentrated on risk types that change rapidly and are more likely to cause problems, improving resource utilization efficiency and reducing monitoring costs.

[0033] Optionally, the step of adjusting the monitoring frequency for the corresponding risk type based on the approximation rate includes:

[0034] The approximation rate is matched with a preset mapping rule to determine the frequency adjustment direction and adjustment step size;

[0035] If the approximation rate exceeds the first threshold, the monitoring frequency is increased by the maximum step size;

[0036] If the approximation rate is lower than the second threshold, the monitoring frequency is reduced by the minimum step size;

[0037] If the approximation rate is between the first threshold and the second threshold, the monitoring frequency is dynamically adjusted in a linear proportion.

[0038] By adopting the above technical solution, the abstract "approach rate" is transformed into a quantifiable monitoring frequency adjustment strategy, enabling dynamic allocation of risk monitoring resources. When the risk value rapidly approaches the threshold, the data collection density is automatically increased to ensure precise capture of high-risk trends; conversely, when the risk trend stabilizes or declines, the monitoring frequency is appropriately reduced to decrease data redundancy and computational load. This "on-demand allocation" mechanism avoids the problems of "over-warning" or "warning lag" caused by fixed-frequency monitoring, and balances real-time performance with resource consumption through a multi-threshold hierarchical adjustment strategy, making risk monitoring more flexible and economical.

[0039] Optionally, the video stream remote transmission method further includes:

[0040] After the video is sent to the server, the client's current playback status and network latency data are monitored in real time.

[0041] When playback delay exceeds a preset threshold or network bandwidth is lower than the set requirements, the video bitrate adaptive adjustment algorithm is automatically triggered to dynamically reduce the video resolution or frame rate and generate a degradation report to be pushed to the client.

[0042] Based on the aforementioned quality degradation report, user feedback information is collected after decryption and playback on the client side.

[0043] Based on the user feedback, the video transmission strategy in the risk database is updated, and the parameters for subsequent video retrieval are optimized.

[0044] By adopting the above technical solution, and through real-time monitoring of client playback status and network conditions, an adaptive bitrate adjustment mechanism is introduced to solve the problem of video transmission stuttering or interruption in complex network environments, ensuring the continuity and reliability of remote monitoring. Dynamic bitrate adjustment avoids video loss caused by bandwidth bottlenecks, especially in areas where mobile networks are unstable and trains are traveling, maintaining smooth playback of critical scenes. The subsequent closed-loop design of user feedback feeds actual playback experience data back to the risk database, forming a continuous optimization cycle: for example, when feedback indicates that degraded video affects risk analysis, the system can automatically increase future transmission priority or add buffer redundancy, thereby improving the availability and decision support value of video content without increasing bandwidth burden. This method not only strengthens the resilience of the transmission link but also optimizes the risk response process through data-driven approaches, making the entire system more intelligent and user-oriented.

[0045] Secondly, this application provides a video stream remote transmission system based on the locomotive 6A system, which adopts the following technical solution:

[0046] A video stream remote transmission system based on the locomotive 6A system includes:

[0047] The onboard buffer pool interacts with the locomotive's 6A system to collect real-time operating data of the locomotive and environmental data of the locomotive's operating area, as well as store locomotive videos and encrypt the locomotive videos. The onboard buffer pool is also used to filter the risk type corresponding to the locomotive from the risk database based on the environmental data, and generate a predicted risk score corresponding to the filtered risk type based on the real-time operating data and the environmental data. If there is a risk type with a predicted risk score greater than the risk score threshold, the encrypted video associated with that risk type is sent.

[0048] The server communicates with the vehicle-mounted buffer pool via a VPN 5G network to receive and push the encrypted video, and to allocate keys to the vehicle-mounted buffer pool and the client.

[0049] A client is used to receive the encrypted video and decrypt and play it.

[0050] Thirdly, this application provides a terminal that adopts the following technical solution:

[0051] A terminal, comprising:

[0052] The memory contains a video stream remote transmission program based on the Locomotive 6A system;

[0053] A processor is used to execute a program stored in the memory to implement the steps of the video stream remote transmission method based on the locomotive 6A system described above.

[0054] In summary, this application has at least the following beneficial effects:

[0055] First, the onboard buffer pool achieves comprehensive perception of the operational status by collecting real-time operating data of the locomotive and environmental data of the operating area, providing a detailed data foundation for subsequent risk assessment. Then, based on the collected environmental information, the onboard buffer pool intelligently matches and filters risk types associated with the current operating scenario from a pre-set risk database, thereby achieving dynamic identification and classification of risk types. On this basis, combined with locomotive operating status parameters and environmental factors, the onboard buffer pool further generates quantitative scores for each type of risk. By setting reasonable risk thresholds, it determines whether there are any safety hazards requiring close attention. Once the score of a certain type of risk exceeds the warning threshold, the onboard buffer pool immediately triggers a video transmission mechanism, extracting encrypted video resources related to that risk type, including real-time camera footage and historical images before the event, ensuring information integrity and traceability. The extracted video data is transmitted to the server through a secure channel, and then from the server to the remote client. After completing identity authentication and key decryption, the client enables real-time playback and analysis of the video, thereby allowing the remote dispatch center or safety management personnel to immediately grasp and intervene in potential risk events. This method not only realizes the linkage mechanism between risk identification and video retrieval, but also ensures the security and privacy of video transmission through data encryption and access control. Attached Figure Description

[0056] Figure 1 This is a first flowchart of an embodiment of the method of this application;

[0057] Figure 2 This is a second flowchart of an embodiment of the method of this application;

[0058] Figure 3 This is a third flowchart of an embodiment of the method of this application;

[0059] Figure 4 This is the fourth flowchart of an embodiment of the method of this application;

[0060] Figure 5 This is a structural block diagram of an embodiment of the system in this application. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the appendices in the embodiments of the present invention will be described below. Figure 1 -Appendix Figure 5 The technical solutions in the embodiments of the present invention are clearly and completely described herein. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. 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.

[0062] The first embodiment of this application discloses a method for remote transmission of video streams based on a locomotive 6A system, using an onboard buffer pool as the execution entity. (See also...) Figure 1 The video stream remote transmission method may include S110-S200:

[0063] S110 collects real-time operating data of the locomotive and environmental data of the locomotive's operating area;

[0064] S120, based on environmental data, selects the corresponding risk type for the locomotive from the risk database;

[0065] S130, based on real-time operational data and environmental data, generates predicted risk scores corresponding to the selected risk types;

[0066] S140, if there is a risk type whose predicted risk score is greater than the risk score threshold, then send the encrypted video associated with that risk type to the server. The encrypted video includes real-time video and historical video. The server is used to push the encrypted video to the client, and the client decrypts and plays the encrypted video.

[0067] S150, if there is no risk type with a predicted risk score greater than the risk score threshold, retrieve the historical occurrence count, false alarm count, and resolution time of the corresponding risk type from the risk database;

[0068] S160, based on the historical occurrence frequency, false alarm frequency, and resolution time, generates the corrected prediction value corresponding to the risk type;

[0069] S170, If there is a risk type whose corrected predicted value is greater than the corrected threshold, send the encrypted video associated with that risk type to the server.

[0070] S180, If there is no risk type whose corrected predicted value is greater than the corrected threshold, then construct the risk curve corresponding to the risk type.

[0071] S190, Based on the risk curve, obtain the approximation rate of the predicted risk value of the corresponding risk type to the risk score threshold;

[0072] S200 adjusts the monitoring frequency for the corresponding risk type based on the approximation rate.

[0073] Specifically, in step S110, high-definition network cameras can be deployed in key parts of the locomotive (such as the engine compartment, cab, coupler connection, etc.) to collect real-time video data during the locomotive's operation. On-board sensor arrays (including speed sensors, acceleration sensors, temperature sensors, humidity sensors, Beidou positioning modules, gyroscopes, and ambient light sensors inside and outside the vehicle) are used to simultaneously collect real-time operating data of the locomotive (such as real-time speed, engine speed, temperature of each bearing, braking pressure, etc.) and environmental data of the locomotive's operating area (such as the latitude and longitude of the current location, altitude, real-time weather conditions, visibility, road slope and curvature, etc.). All collected data are aggregated into the locomotive's 6A system via the on-board CAN bus or Ethernet for preliminary preprocessing and storage. In step S120, after the environmental data is analyzed by the locomotive's 6A system, key feature parameters such as extreme weather (heavy rain, heavy snow, heavy fog), complex terrain (mountain curves, long downhill slopes, tunnel entrances and exits), and special road sections (construction sections, unmanned level crossings) are extracted and sent to the onboard buffer pool. The onboard buffer pool inputs these feature parameters into a pre-trained risk type matching model (this model is based on historical accident cases and risk event databases, constructed using machine learning algorithms such as decision trees or Naive Bayes). The model will select risk types that are highly relevant to the current locomotive's operating environment from a preset risk library (containing various risk types and their feature descriptions, such as derailment risk, brake failure risk, component overheating risk, signal failure risk, collision risk, etc.) based on the input environmental feature parameters. For example, when the environmental data shows that the locomotive is currently traveling on a mountain road section with continuous downhill slopes and slippery surfaces, "brake overheating failure risk" and "derailment risk" will be selected first.

[0074] In step S140, the vehicle-mounted buffer pool compares the predicted risk scores for each risk type with preset risk score thresholds (the thresholds are set according to the severity of the risk type and safety procedures, such as 80 points for "collision risk" and 70 points for "component overheating risk"). If the predicted risk score for any risk type is greater than its corresponding risk score threshold, the system immediately triggers the video encryption transmission process, retrieving the real-time video stream associated with that risk type (collected in real time by the camera in the corresponding monitoring area) and historical video clips (ensuring that key processes before the risk event occur) from the video storage unit of the vehicle-mounted buffer pool. The encryption algorithm adopts national cryptographic algorithms, specifically using the SM2 national cryptographic algorithm to encrypt the key application process and the SM4 national cryptographic algorithm to encrypt the video stream data, adding metadata such as timestamps, locomotive IDs, and risk type tags. Subsequently, the encrypted video is pushed to the server via a VPN 5G network using a private protocol. After receiving the encrypted video, the server identifies the client's identity through a preset permission management mechanism and pushes the encrypted video and the corresponding decryption key (sent through an independent secure channel) to the authorized client (such as the dispatch center monitoring terminal or maintenance personnel's mobile terminal). After receiving the encrypted video and decryption key, the client decrypts the video data using a local decryption plugin and plays and stores it in real time through a player that supports H.265 / H.264 encoding.

[0075] When no risk type with a predicted risk score greater than the risk score threshold is detected in step S140, the process proceeds to step S150. The onboard buffer pool accesses the server-side risk database through a private protocol and retrieves the corresponding historical statistical data based on the currently selected risk type. This includes the number of times the risk type has occurred in the same type of locomotive, the same type of line, and similar environmental conditions (the number of actual risk events that have occurred in the past 3 months), the number of false alarms (the number of times the system issued a warning and was confirmed by manual review to be a non-real risk), and the average resolution time of historical risk events (the time consumed from the discovery of a risk event to its complete resolution, which can be accurate to the minute). This data is extracted from the database using Structured Query Language (SQL) and returned to the onboard buffer pool.

[0076] In step S160, based on the retrieved historical data, the revised prediction value is generated using the following formula: Revised prediction value = [(Number of historical occurrences - Number of false alarms) / Number of historical occurrences] × Baseline risk coefficient + Resolution duration × Time-sensitive impact factor. The baseline risk coefficient is set according to the inherent hazard of the risk type (e.g., the collision risk coefficient is higher than the component slight overheating risk), and the time-sensitive impact factor reflects the impact of resolution duration on risk diffusion (the longer the resolution duration, the larger the factor value). The revised prediction value calculated by this formula can more objectively reflect the actual threat level of the risk.

[0077] In step S170, the calculated corrected prediction value is compared with the preset correction threshold (this threshold is lower than the risk score threshold and is used to warn of potential risks in advance; for example, if the risk score threshold is 80 points, the correction threshold can be set to 65 points). If there is a risk type whose corrected prediction value is greater than the correction threshold, the video encryption transmission process is also triggered, and the encrypted video associated with the risk type (including real-time video and historical video over a longer period of time) is sent to the server so that the monitoring center can intervene and analyze it in advance.

[0078] If the triggering condition is not met in step S170, the system executes step S180. For each risk type, the on-board buffer retrieves the time-series data of the predicted risk score for that risk type over the past 72 hours. Using time as the horizontal axis and the predicted risk score as the vertical axis, the data is smoothed using a sliding window averaging method to eliminate short-term fluctuation noise. Then, a risk curve is constructed for that risk type using polynomial fitting (e.g., cubic spline curve fitting) or a deep learning-based time-series prediction model (e.g., TCN temporal convolutional network). This visually displays the trend, peaks, troughs, and fluctuation frequency of the risk score over time. In step S190, based on the constructed risk curve, the average time required for the predicted risk value to rise from its current value to the risk score threshold per unit time (e.g., per hour) is calculated. Combined with the distribution of the risk value's rate of increase in historical data, a differential algorithm is used to calculate the slope of each point on the curve. This yields the approximation rate of the predicted risk value for the corresponding risk type towards the risk score threshold (i.e., the percentage by which the risk value approaches the risk score threshold per unit time, such as "approaching the risk score threshold by 5% every 10 minutes").

[0079] In S200, the steps for adjusting the monitoring frequency for the corresponding risk type based on the approximation rate include:

[0080] The approximation rate is matched with the preset mapping rules to determine the frequency adjustment direction and adjustment step size. If the approximation rate exceeds the first threshold, the monitoring frequency is increased by the maximum step size. If the approximation rate is lower than the second threshold, the monitoring frequency is decreased by the minimum step size. If the approximation rate is between the first and second thresholds, the monitoring frequency is dynamically adjusted by a linear ratio.

[0081] Specifically, during the system initialization phase, a mapping rule base between risk types and approximation rates is pre-defined, clearly defining a first threshold (upper limit) and a second threshold (lower limit) corresponding to different risk levels. When the real-time calculated approximation rate exceeds the first threshold, the system automatically triggers the highest-level monitoring response mechanism, directly increasing the monitoring frequency significantly by a preset maximum step size (e.g., shortening the monitoring interval from 1 hour to 15 minutes) to ensure full coverage tracking under high-risk conditions. Conversely, if the approximation rate remains below the second threshold, the monitoring load is gradually reduced by a minimum step size (e.g., extending the interval from 24 hours to 48 hours) to avoid resource waste. For intermediate values ​​between the two thresholds, the system initiates a dynamic calibration algorithm: first, it calculates the relative position ratio of the current approximation rate within the threshold range, using it as a linear coefficient; then, it multiplies this coefficient by the difference between the maximum and minimum step sizes; finally, it adds the minimum step size to obtain the specific adjustment amount (formula: adjustment amount = minimum step size + [(approximation rate - second threshold) / (first threshold - second threshold)] × (maximum step size - minimum step size)).

[0082] Reference Figure 2 The steps for generating predicted risk scores corresponding to the selected risk types based on real-time operational data and environmental data include S210-S230:

[0083] S210, Construct a risk assessment model and risk factor mapping table;

[0084] S220 inputs real-time operational data and environmental data into the risk assessment model to output initial predicted values;

[0085] S230 extracts matching risk factors and their weights from the mapping table based on current environmental data and the real-time status of the locomotive to correct the initial prediction value.

[0086] Specifically, an ensemble learning-based risk assessment model framework is deployed on the vehicle-mounted edge server: First, the XGBoost algorithm is used to establish the basic prediction architecture, and feature importance weights are trained using a historical accident dataset (containing over 100,000 locomotive sensor records and environmental parameters); simultaneously, a risk factor mapping table is constructed—the key influencing factors of 12 core risks, such as "brake overheating failure" (e.g., slope angle, wheel-rail adhesion coefficient, brake pad temperature change rate), are quantified and encoded, and the weight coefficients of each factor are determined based on SHAP value analysis (e.g., the weight increases by 0.15 for every 1° increase in slope on a continuous downhill section). When the locomotive transmits real-time data packets (containing 32-dimensional parameters such as acceleration / GPS coordinates / temperature and humidity with 0.1-second accuracy) through the 5G+BeiDou fusion network, the preprocessing engine performs three stages of processing: ① spatiotemporal alignment (matching environmental meteorological data with the locomotive position); ② outlier cleaning (using... (1) Filter fault sensor data according to rules; 2) Feature vectorization (e.g., convert the current slope of 7° and air humidity of 85% into a normalized array of [0.7, 0.85]. After this vector is input into the XGBoost model, it outputs an initial risk value Pt based on probability (e.g., an initial derailment risk value of 0.38), and the model simultaneously generates an interpretable report to mark the key decision paths.

[0087] The key correction factors for the current scenario are indexed through a mapping table: for example, in the scenario of "heavy rain + curve radius 300m", the "sideslip risk" correction group (including wheel-rail water film thickness weight 0.3, centrifugal acceleration weight 0.4, etc.) is activated. The correction engine performs three steps: ① Extracting real-time locomotive status parameters (such as detecting that the sand spreading device is not activated); ② Calculating the environmental superposition coefficient (1.5 times environmental multiplier is triggered when a red rainstorm warning is issued); ③ Applying the weight formula: the corrected predicted risk value. (Where wi is the factor weight and vi is the real-time normalized value).

[0088] Reference Figure 3 The steps for sending the encrypted video associated with this risk type to the server include S310-S330:

[0089] S310, retrieves the radius of curvature of the locomotive's running track;

[0090] S320 calculates the video retrieval duration based on video bitrate, radius of curvature, and real-time running data;

[0091] S330 retrieves historical videos associated with the risk type based on the video retrieval duration and sends them to the server.

[0092] Specifically, the locomotive collects track geometry data in real time through onboard sensors (such as gyroscopes or GPS trajectory analysis modules), and dynamically calculates the radius of curvature of the current operating section by combining it with pre-stored line information from a high-precision digital map. This data is read through the CAN bus or Ethernet interface of the onboard control system and transmitted to the onboard buffer pool for temporary storage via tunneling protocol. Based on the radius of curvature, the locomotive's real-time speed / acceleration data, and a preset video bitrate (such as 4Mbps under H.264 encoding), the onboard buffer pool dynamically determines the duration of historical video to be retrieved using a safety threshold model. The specific formula can be designed as: Retrieval Duration = (Safety Factor × Radius of Curvature) / (Real-time Speed ​​× Video Bitrate Weight). The smaller the radius of curvature (the sharper the curve) or the higher the speed, the longer the required video duration needs to be retrieved. The model parameters need to be continuously optimized through machine learning in actual operating scenarios to ensure coverage of critical operational scenes before the risk occurs. Based on the calculated retrieval duration, the onboard buffer pool retrieves video segments (usually in HLS slice format) for the corresponding time period from the local solid-state drive.

[0093] Reference Figure 4 Furthermore, the video stream remote transmission method also includes S410-S440:

[0094] S410 monitors the client's current playback status and network latency data in real time after the video is sent to the server;

[0095] When the S420 detects that the playback delay exceeds the preset threshold or the network bandwidth is lower than the set requirements, it automatically triggers the video bitrate adaptive adjustment algorithm, dynamically reduces the video resolution or frame rate, and generates a degradation report and pushes it to the client.

[0096] S430 collects user feedback information after decrypting and playing the video on the client side, based on the degradation report.

[0097] S440 updates the video transmission strategy in the risk database based on user feedback and optimizes subsequent video retrieval parameters.

[0098] Specifically, in step S410, after the video data is successfully sent to the server, the system needs to monitor the client's playback status and network latency data in real time. This can be achieved by integrating a lightweight status acquisition module into the client. This module sends a status message to the server every second, containing the current playback progress, buffering time, and number of stutters (determined by comparing the expected playback time with the actual playback time). Simultaneously, the server periodically sends probe packets to the client using the ICMP protocol, calculates the round-trip time (RTT) as network latency data, and stores this information in real time in a distributed time-series database (such as InfluxDB). The fluctuations of key metrics are then displayed in real time through a visual monitoring panel (such as Grafana).

[0099] When the server detects an anomaly through a preset threshold judgment mechanism (such as network latency exceeding 300ms for 3 consecutive seconds or real-time network bandwidth being less than 1.2 times the current video bitrate), it automatically triggers a video bitrate adaptive adjustment algorithm. Specifically, it employs layered encoding technology based on the H.265 / HEVC standard, pre-storing multiple resolution versions of the same video (e.g., 4K, 2K, 1080P, 720P) on the server. The algorithm analyzes the current network bandwidth, latency, and historical bitrate adjustment records, dynamically switching to a matching resolution using FFmpeg (e.g., reducing from 1080P to 720P), while proportionally reducing the frame rate (e.g., reducing from 60fps to 30fps). It also generates a degradation report by extending the field using the RTP protocol to carry the reason for the degradation (e.g., "Insufficient network bandwidth, adjusted to 720P / 30fps"). This report, encrypted with AES-128, is pushed to the client via WebSocket. Upon receiving the report, the client displays a semi-transparent prompt bar at the bottom of the playback interface, informing the user of the current video quality adjustment status and restoration suggestions (e.g., "Suggest switching to Wi-Fi to improve image quality").

[0100] Based on the degradation report received by the client, the system collects user feedback information in two ways after the video decryption and playback are completed. On the one hand, after the degradation status is lifted (e.g., 5 minutes after the network returns to normal), the client pops up a lightweight feedback window, providing three options: "Acceptable picture quality," "Noticeable stuttering," and "Blurry affects viewing," as well as a text input box. After the user submits the data, it is transmitted to the server via HTTPS encryption. On the other hand, the system automatically collects user operation behavior data during the degradation period (such as the number of fast-forwards, pause duration, and whether the resolution was actively switched), combines it with the user's explicit feedback to construct a feedback dataset, performs sentiment analysis on the text feedback using natural language processing (NLP) technology (e.g., identifying "too blurry" as negative feedback), and associates the structured feedback information (such as feedback type, degradation duration, and user level) with the corresponding video ID and transmission session ID.

[0101] Finally, the server updates the video transmission strategy in the risk database based on the collected user feedback. Specifically, a machine learning-based strategy optimization model can be built, using user feedback (e.g., 80% of users consider the degradation of 720P / 30fps "acceptable"), network environment characteristics (e.g., the optimal initial bitrate under 4G networks), and video content attributes (e.g., action movies are more sensitive to frame rate than documentaries) as training features. A dynamic decision tree is generated using a random forest algorithm to optimize subsequent video retrieval parameters. For example, when a new user visits for the first time, the strategy database will initially allocate a lower bitrate version based on historical data from the network operator of the user's IP address and gradually increase it. For users who frequently report buffering issues, a pre-loading buffering mechanism is automatically enabled (pre-caching 30 seconds of video content). Simultaneously, the optimized strategy is synchronized to the edge computing servers of the CDN nodes, enabling real-time policy implementation at the nearest node. Finally, A / B testing is used to verify the strategy optimization effect (e.g., using an increase in the average user completion rate as a core KPI).

[0102] Based on the above method embodiments, the second embodiment of this application discloses a video stream remote transmission system based on a locomotive 6A system. The video stream remote transmission system based on a locomotive 6A system of this application embodiment can implement any of the above-described methods for video stream remote transmission based on a locomotive 6A system, and the specific working process of each module in the video stream remote transmission system based on a locomotive 6A system can be referred to the corresponding process in the above method embodiments.

[0103] For ease of understanding, please refer to Figure 5 An example is as follows: A video stream remote transmission system based on the locomotive 6A system includes:

[0104] The onboard buffer pool interacts with the locomotive's 6A system to collect real-time operating data of the locomotive and environmental data of the locomotive's operating area, as well as store locomotive videos and encrypt the locomotive videos. The onboard buffer pool is also used to filter the risk type corresponding to the locomotive from the risk database based on the environmental data, and generate a predicted risk score corresponding to the filtered risk type based on the real-time operating data and the environmental data. If there is a risk type with a predicted risk score greater than the risk score threshold, the encrypted video associated with that risk type is sent.

[0105] The server communicates with the vehicle-mounted buffer pool via a VPN 5G network to receive and push the encrypted video, and to allocate keys to the vehicle-mounted buffer pool and the client.

[0106] A client is used to receive the encrypted video and decrypt and play it.

[0107] Specifically, for real-time video, the onboard buffer pool device implements this function using embedded Linux C++. It interacts with the server through a private protocol to obtain attributes such as the channel number and bitrate required for real-time preview, and uses the ffmpeg API to pull H.264 format video data from the corresponding channel camera. After multi-threaded processing, the H.264 video data is encapsulated using a private protocol, then encrypted using the SM4 algorithm. Finally, through socket programming, the encrypted data is pushed to the server. The server parses the data and pushes the encrypted data file to the client, which then decrypts and plays it.

[0108] For historical videos, the vehicle-mounted buffer pool device uses FTP to capture the historical video calendar from the video cards in the 6A system and saves it to a JSON file. It iterates through the captured calendar, using ffmpeg's FTP streaming function to retrieve the historical video files for each day, obtaining attributes such as start time, duration, and size for each video file, and saving these to a newly created JSON file. When a client requests the historical video calendar or the duration of historical videos for a specific date, the vehicle-mounted buffer pool pushes the data content from the JSON file to the server in a fixed format via a private protocol. The server then sends the data to the client. When a user clicks on a time point in the retrieved historical video timeline, the server sends the requested time, channel, and other relevant attributes to the vehicle-mounted buffer pool device via a private protocol. The buffer pool then uses ffmpeg's FTP to retrieve the historical video data from the video cards starting at the corresponding time, processes it through multi-threading, encrypts it with SM4, and pushes it to the server. The server parses the data and pushes the encrypted data file to the client, which then decrypts and plays it.

[0109] In addition, the vehicle-mounted buffer pool device will use ffmpeg to pull h.264 data, encapsulate it with PS stream video, and store it in the buffer pool's hard drive with a fixed duration and format for backup purposes, preventing the loss of important video due to damage to the video board in the 6A system.

[0110] Additionally, when historical video files need to be cached, the in-vehicle buffer pool device obtains the required historical video time period, retrieves the corresponding video file using ffmpeg, and caches it on the hard drive. The buffer pool then pushes the video file to the corresponding directory on the server via FTP. During this process, the buffer pool first checks if the file exists on the server; if it doesn't exist, it starts uploading from the beginning; if it exists, it obtains the size of the existing file and skips that size during upload, thus enabling resumeable video file transfer.

[0111] Finally, it's worth noting that 5G network transmission using a VPN can support video data volumes that were previously impossible to transmit, while ensuring video data security. The use of a combination of SM4 and SM2 encryption ensures the integrity and security of encrypted data. Real-time video is directly retrieved from the camera, bypassing other devices, ensuring data accuracy and real-time performance. Historical video data can be directly retrieved from the 6A system video card, maximizing device utilization. FTP-based resume functionality pushes historical video cache to the server, reducing duplicate video file uploads and ensuring data integrity.

[0112] A third embodiment of this application provides a terminal. As one implementation of this terminal, the terminal may include: a memory and a processor; wherein...

[0113] The memory is used to store the video stream remote transmission program based on the Locomotive 6A system;

[0114] The processor is used to execute the program stored in the memory to implement the steps of the video stream remote transmission method based on the locomotive 6A system described above.

[0115] The memory can communicate with the processor via a communication bus, which can be an address bus, a data bus, a control bus, etc.

[0116] Additionally, the memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0117] Furthermore, the processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0118] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A method for remote transmission of video streams based on a locomotive 6A system, characterized in that, The implementation of the vehicle-mounted buffer pool includes: Collect real-time operating data of the locomotive and environmental data of the locomotive's operating area; Based on the environmental data, the risk type corresponding to the locomotive is selected from the risk database; Construct a risk assessment model and a risk factor mapping table; The real-time operating data and the environmental data are input into the risk assessment model to output an initial predicted value; Based on the current environmental data and the real-time status of the locomotive, the matching risk factors and their weights are extracted from the mapping table to correct the initial prediction value and obtain the predicted risk score. If there is a risk type whose predicted risk score is greater than the risk score threshold, then an encrypted video associated with that risk type is sent to the server. The encrypted video includes real-time video and historical video. The server is used to push the encrypted video to the client, and the client decrypts and plays the encrypted video. If there is no risk type whose predicted risk score is greater than the risk score threshold, then retrieve the historical occurrence count, false alarm count, and resolution time of the corresponding risk type from the risk database; Based on the historical occurrence count, the false alarm count, and the resolution time, a corrected prediction value corresponding to the risk type is generated; If there is a risk type whose corrected predicted value is greater than the corrected threshold, then send the encrypted video associated with that risk type to the server. If there is no risk type whose revised predicted value is greater than the revised threshold, then construct the risk curve corresponding to the risk type. Based on the risk curve, obtain the approximation rate of the predicted risk value for the corresponding risk type to the risk score threshold; Based on the approximation rate, adjust the monitoring frequency for the corresponding risk type.

2. The method for remote transmission of video streams based on a locomotive 6A system according to claim 1, characterized in that, The steps for sending the encrypted video associated with this risk type to the server include: Determine the radius of curvature of the locomotive's running track; The video retrieval duration is calculated based on the video bitrate, the radius of curvature, and the real-time running data. Based on the video retrieval duration, retrieve historical videos associated with this risk type and send them to the server.

3. The method for remote transmission of video streams based on a locomotive 6A system according to claim 1, characterized in that, The steps for adjusting the monitoring frequency for the corresponding risk type based on the approximation rate include: The approximation rate is matched with a preset mapping rule to determine the frequency adjustment direction and adjustment step size; If the approximation rate exceeds the first threshold, the monitoring frequency is increased by the maximum step size; If the approximation rate is lower than the second threshold, the monitoring frequency is reduced by the minimum step size; If the approximation rate is between the first threshold and the second threshold, the monitoring frequency is dynamically adjusted in a linear proportion.

4. The method for remote transmission of video streams based on a locomotive 6A system according to claim 1, characterized in that, The video stream remote transmission method further includes: After the video is sent to the server, the client's current playback status and network latency data are monitored in real time. When playback delay exceeds a preset threshold or network bandwidth is lower than the set requirements, the video bitrate adaptive adjustment algorithm is automatically triggered to dynamically reduce the video resolution or frame rate and generate a degradation report to be pushed to the client. Based on the aforementioned quality degradation report, user feedback information is collected after decryption and playback on the client side. Based on the user feedback, the video transmission strategy in the risk database is updated, and the parameters for subsequent video retrieval are optimized.

5. A video stream remote transmission system based on the locomotive 6A system, characterized in that, The method for remote transmission of video streams based on the locomotive 6A system as described in any one of claims 1-4 includes: The onboard buffer pool interacts with the locomotive's 6A system to collect real-time operating data of the locomotive and environmental data of the locomotive's operating area, as well as store locomotive videos and encrypt the locomotive videos. The onboard buffer pool is also used to filter the risk type corresponding to the locomotive from the risk database based on the environmental data, and generate a predicted risk score corresponding to the filtered risk type based on the real-time operating data and the environmental data. If there is a risk type with a predicted risk score greater than the risk score threshold, the encrypted video associated with that risk type is sent. The server communicates with the vehicle-mounted buffer pool via a VPN 5G network to receive and push the encrypted video, and to allocate keys to the vehicle-mounted buffer pool and the client. A client is used to receive the encrypted video and decrypt and play it.

6. A terminal, characterized in that, include: The memory contains a video stream remote transmission program based on the Locomotive 6A system; A processor is configured to execute a program stored in the memory to implement the steps of the video stream remote transmission method based on the locomotive 6A system as described in any one of claims 1-4.

Images