Video stream remote transmission method, system and terminal based on locomotive 6A system

Abstract

The invention relates to a video stream remote transmission method, system and terminal based on a locomotive 6A system, and belongs to the technical field of video processing.The video stream remote transmission method takes a vehicle-mounted buffer pool as an execution main body and comprises the steps that real-time operation data of a locomotive and environment data of a locomotive driving area are collected; screening a risk type corresponding to the locomotive from a risk library according to the environment data; according to the real-time operation data and the environment data, generating a predicted risk score corresponding to the screened risk type; if the risk type of which the predicted risk score is greater than a risk score threshold exists, an encrypted video associated with the risk type is sent to a server, and the encrypted video comprises a real-time video and a historical video; the server is used for pushing the encrypted video to the client, and the client decrypts and plays the encrypted video. The method and the device have the beneficial effect of realizing early warning of risk events.

Description

Technical Field

[0001] The present 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 a locomotive 6A system. Background Art

[0002] With the continuous improvement of my country's railway transportation capacity and the continuous increase in train operating speeds, higher requirements are being placed on train safety and real-time monitoring of operating status. Especially in operating environments characterized by complex terrain, harsh climates, and frequent emergencies, achieving comprehensive perception of train operating status, intelligent identification of potential risks, and timely response have become key issues in ensuring railway transportation safety. The locomotive onboard safety protection system (6A system), a key technical means of ensuring locomotive safety, has been widely implemented across the railway system. The video subsystem, as a key component of the 6A system, bears the crucial responsibility of real-time monitoring of driver operations, equipment status, and the external environment.

[0003] Current railway industry applications typically use a video recording and remote transmission mechanism based on fixed time or event triggers. For example, in the event of an emergency brake, an abnormal door opening, or a driver's illegal operation, the system automatically triggers video recording and uploads it to the ground monitoring center.

[0004] Although existing technologies have achieved remote transmission of video data and event backtracking to a certain extent, the video retrieval strategy is still a passive response, resulting in delayed or redundant video resource retrieval and the inability to provide early warning of risk events. Summary of the Invention

[0005] In order to achieve early warning of risk events, the present application provides a video stream remote transmission method based on the locomotive 6A system.

[0006] In a first aspect, the present application provides a method for remotely transmitting a video stream based on a locomotive 6A system, which adopts the following technical solutions: A video stream remote transmission method based on a locomotive 6A system, with an onboard buffer pool as the execution body, includes: Collect real-time operation data of the locomotive and environmental data of the locomotive driving area; Filtering the risk type corresponding to the locomotive from the risk library according to the environmental data; generating a predicted risk score corresponding to the screened risk type based on the real-time operation data and the environmental data; If there is a risk type whose predicted risk score is greater than the risk score threshold, an encrypted video associated with the risk type is sent to the server, where 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.

[0007] By implementing this technical solution, the onboard buffer pool first collects real-time locomotive operating data and environmental data from the driving area, achieving comprehensive awareness of the locomotive's operating status, providing a detailed data foundation for subsequent risk assessment. Subsequently, based on this 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, enabling dynamic risk identification and classification. Based on this information, the onboard buffer pool further generates quantitative scores for each risk type, combining locomotive operating parameters with environmental factors. By setting appropriate risk thresholds, the onboard buffer pool determines whether there are currently significant safety hazards requiring attention. Once the risk score for a particular risk type exceeds the warning threshold, the onboard buffer pool immediately triggers a video transmission mechanism to extract encrypted video resources related to that risk type, including real-time camera footage and historical footage from before the incident, ensuring information integrity and traceability. The extracted video data is transmitted to the server via a secure channel, and then from the server to the remote client. After identity authentication and key decryption, the client enables real-time video playback and analysis, enabling the remote dispatch center or security personnel to immediately identify and intervene in potential risk events. This method not only realizes the linkage mechanism of risk identification and video retrieval, but also ensures the security and privacy of video transmission through data encryption and permission control.

[0008] Optionally, the step of generating a predicted risk score corresponding to the screened risk type based on the real-time operation data and the environmental data includes: Construct risk assessment models and risk factor mapping tables; Inputting the real-time operation data and the environmental data into the risk assessment model to output an initial prediction value; According to 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 modify the initial prediction value.

[0009] By implementing these technical solutions, data-driven model calculations and dynamic factor corrections can avoid the subjectivity of manual assessments and achieve a quantitative characterization of potential risks. Real-time data input and automated score generation processes can shorten risk assessment cycles, buy time for emergency response, and achieve a shift from passive response to proactive early warning.

[0010] Optionally, the step of sending the encrypted video associated with the risk type to the server includes: Retrieve the curvature radius of the locomotive running track; Calculate the video retrieval duration based on the video bit rate, the curvature radius, and the real-time running data; According to the video retrieval duration, historical videos associated with the risk type are retrieved and sent to the server.

[0011] By adopting the above technical solution, the high-risk spatial range is locked through the curvature radius, and the duration is dynamically calculated based on the bit rate and operating data, avoiding the redundancy caused by full video retrieval and focusing risk analysis on key segments.

[0012] Optionally, the video stream remote transmission method further includes: If there is no risk type with the 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; Generate a revised prediction value corresponding to the risk type based on the historical number of occurrences, the number of false alarms, and the resolution time; If there is a risk type whose corrected prediction value is greater than the correction threshold, the encrypted video associated with the risk type is sent to the server.

[0013] By adopting the above technical solution, when there is no risk type with a predicted risk score greater than the threshold, data such as the historical number of occurrences, number of false alarms, and resolution time of the corresponding risk type are retrieved from the risk library, and a revised prediction value is generated based on this historical data. This means that risk assessment no longer relies solely on a single prediction score, but instead comprehensively considers multiple factors such as the frequency of risk occurrence, false alarms, and difficulty of resolution. It can more accurately assess various risks, reduce misjudgments caused by a single assessment indicator, and thus discover potential high-risk types in advance. This helps to filter out situations that appear risky but actually have a low probability of occurrence or a small impact, making risk warnings more accurate and targeted, and avoiding the waste of resources and distraction caused by excessive warnings.

[0014] Optionally, after generating the revised predicted value corresponding to the risk type, the steps further include: If there is no risk type whose revised predicted value is greater than the revised threshold, then a risk curve graph corresponding to the risk type is constructed; According to the risk curve, obtaining the approach rate of the predicted risk value of the corresponding risk type to the risk score threshold; The monitoring frequency of the corresponding risk type is adjusted according to the approach rate.

[0015] By employing the above technical solution, a risk curve corresponding to each risk type is constructed, providing an intuitive graphical representation of risk trends over time or other factors. Compared to single numerical values, graphs are easier to understand and analyze, allowing stakeholders to quickly understand the evolving risk landscape, including whether the risk is rising, falling, or fluctuating, leading to a more comprehensive and in-depth understanding of the risk. Even if the current revised forecast value does not exceed the revised threshold, the curve's trend can be used to determine whether the risk is approaching the risk threshold. This helps identify potential risks in advance, providing sufficient time and preparation for subsequent risk responses. Dynamically adjusting the monitoring frequency based on the approach rate allows for the appropriate allocation of monitoring resources based on the actual risk situation. By avoiding a uniform, fixed-frequency monitoring schedule for all risk types, resources can be focused on those risk types that are more rapidly evolving and more likely to cause problems, improving resource utilization efficiency and reducing monitoring costs.

[0016] Optionally, the step of adjusting the monitoring frequency corresponding to the risk type according to the approach rate includes: Matching the approximation rate with a preset mapping rule to determine a frequency adjustment direction and an adjustment step size; If the approach rate exceeds a first threshold, increasing the monitoring frequency by a maximum step size; If the approach rate is lower than a second threshold, reducing the monitoring frequency by a minimum step size; If the approach rate is between the first threshold and the second threshold, the monitoring frequency is dynamically adjusted in a linear proportion.

[0017] By adopting the above technical solution, the abstract "approximation rate" is converted into a quantifiable monitoring frequency adjustment strategy, achieving dynamic allocation of risk monitoring resources. When the risk value rapidly approaches the threshold, the data collection density is automatically increased to ensure accurate capture of high-risk trends. When the risk trend stabilizes or decreases, the monitoring frequency is appropriately reduced to reduce data redundancy and computational load. This "on-demand allocation" mechanism not only avoids the "over-alerting" or "delayed warning" problems caused by fixed-frequency monitoring, but also balances real-time performance with resource consumption through a multi-threshold layered adjustment strategy, making risk monitoring more flexible and economical.

[0018] Optionally, the video stream remote transmission method further includes: After the video is sent to the server, the client's current playback status and network delay data are monitored in real time; When it is detected that the playback delay exceeds the preset threshold or the network bandwidth is lower than the set requirement, the video bit rate adaptive adjustment algorithm is automatically triggered to dynamically reduce the video resolution or frame rate, and generate a degradation report and push it to the client; Based on the degradation report, collecting user feedback information after decryption and playback on the client side; Based on the user feedback information, the video transmission strategy in the risk library is updated and subsequent video retrieval parameters are optimized.

[0019] By adopting the above technical solution, through real-time monitoring of the client playback status and network conditions, and introducing an adaptive bitrate adjustment mechanism, the problem of video transmission freezes or interruptions in complex network environments is solved, ensuring the continuity and reliability of remote monitoring. Dynamic bitrate adjustment avoids video loss caused by bandwidth bottlenecks, especially in locomotive driving areas with unstable mobile networks, and can maintain smooth playback of key images. The subsequent user feedback closed-loop design feeds actual playback experience data back to the risk library, forming a continuous optimization cycle: for example, when feedback shows that degraded video affects risk analysis, the system can automatically increase future transmission priority or increase buffer redundancy, thereby improving the availability and decision-making 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 optimization, making the entire system more intelligent and user-oriented.

[0020] In the second aspect, the present application provides a video stream remote transmission system based on the locomotive 6A system, which adopts the following technical solutions: A video stream remote transmission system based on a locomotive 6A system, comprising: An onboard buffer pool interacts with the locomotive's 6A system data to collect the locomotive's real-time operating data and environmental data of the locomotive's driving area, as well as to store and encrypt locomotive videos. The onboard buffer pool is further configured to filter risk types corresponding to the locomotive from a risk library based on the environmental data, and generate predicted risk scores corresponding to the filtered risk types based on the real-time operating data and the environmental data. If a risk type exists for which the predicted risk score is greater than a risk score threshold, the encrypted video associated with the risk type is transmitted. The server communicates with the vehicle-mounted buffer pool via a VPN 5G network, is configured to receive and push the encrypted video, and distribute keys to the vehicle-mounted buffer pool and the client; The client is used to receive the encrypted video and decrypt and play the encrypted video.

[0021] In a third aspect, the present application provides a terminal that adopts the following technical solution: A terminal, comprising: a memory storing a video stream remote transmission program based on the locomotive 6A system; The processor is configured to execute the program stored in the memory to implement the steps of the above-mentioned method for remotely transmitting video streams based on the locomotive 6A system.

[0022] In summary, this application has at least the following beneficial effects: First, the onboard buffer pool collects real-time locomotive operating data and environmental data from the driving area, achieving comprehensive awareness of the locomotive's operating status and providing a detailed data foundation for subsequent risk assessment. Subsequently, based on this collected environmental information, the onboard buffer pool intelligently matches and filters risk types associated with the current operating scenario from a pre-defined risk database, enabling dynamic risk identification and classification. Based on this information, the onboard buffer pool further generates quantitative scores for each risk category, combining locomotive operating parameters with environmental factors. By setting appropriate risk thresholds, the onboard buffer pool determines whether any safety hazards require attention. Once the risk score for a particular category exceeds the warning threshold, the onboard buffer pool immediately triggers a video transmission mechanism to extract encrypted video resources related to that risk category, including real-time camera footage and historical footage from before the incident, ensuring information integrity and traceability. The extracted video data is transmitted to the server via a secure channel, and then from the server to the remote client. After identity authentication and key decryption, the client enables real-time video playback and analysis, enabling the remote dispatch center or safety management personnel to immediately identify and intervene in potential risk events. This method not only realizes the linkage mechanism of risk identification and video retrieval, but also ensures the security and privacy of video transmission through data encryption and permission control. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a first flow chart of an embodiment of the method of the present application; Figure 2 This is a second flow chart of the method embodiment of the present application; Figure 3 This is a third flow chart of the method embodiment of the present application; Figure 4 This is a fourth flow chart of the method embodiment of the present application; Figure 5 It is a structural block diagram of an embodiment of the system of the present application. DETAILED DESCRIPTION

[0024] To make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the following will be combined with the appended drawings of the embodiments of the present invention. Figure 1 -Attached Figure 5 The technical solutions in the embodiments of the present invention are clearly and completely described. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0025] The first embodiment of the present application discloses a method for remote transmission of video stream based on a locomotive 6A system, with a vehicle-mounted buffer pool as the execution body. Figure 1 The video stream remote transmission method may include S110-S200: S110, collecting real-time operation data of the locomotive and environmental data of the locomotive driving area; S120, based on the environmental data, screening the risk type corresponding to the locomotive from the risk library; S130, generating a predicted risk score corresponding to the screened risk type based on the real-time operation data and environmental data; S140: If there is a risk type with a predicted risk score greater than the risk score threshold, an encrypted video associated with the risk type is sent to the server, where the encrypted video includes real-time video and historical video. The server pushes the encrypted video to the client, which decrypts and plays the encrypted video. 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; S160, generating a revised prediction value corresponding to the risk type based on the historical number of occurrences, number of false alarms, and resolution time; S170, if there is a risk type whose corrected prediction value is greater than the corrected threshold, sending the encrypted video associated with the risk type to the server; S180, if there is no risk type whose corrected predicted value is greater than the corrected threshold, construct a risk curve graph corresponding to the risk type; S190, obtaining, based on the risk curve, an approach rate of the predicted risk value of the corresponding risk type to the risk score threshold; S200: Adjust the monitoring frequency of the corresponding risk type according to the approach rate.

[0026] Specifically, in step S110, high-definition network cameras can be deployed at key parts of the locomotive (such as the engine compartment, cab, coupler connection, etc.) to collect real-time video data during the locomotive's travel, and the on-board sensor array (including speed sensors, acceleration sensors, temperature sensors, humidity sensors, Beidou positioning modules, gyroscopes, and indoor and outdoor ambient light sensors, etc.) can be used to synchronously collect the locomotive's real-time operating data (such as real-time speed, engine speed, bearing temperatures, brake pressure, etc.) and environmental data of the locomotive's travel area (such as the current location's latitude and longitude, altitude, real-time weather conditions, visibility, road slope and curvature, etc.). All collected data are aggregated into the locomotive's 6A system through the on-board CAN bus or Ethernet for preliminary preprocessing and storage. In step S120, after the environmental data is analyzed by the locomotive 6A system, key feature parameters such as extreme weather (heavy rain, heavy snow, heavy fog), complex terrain (mountainous curves, long downhill slopes, tunnel entrances and exits), and special road sections (construction sections, unmanned crossings) are extracted and sent to the on-board buffer pool. The on-board buffer pool inputs these feature parameters into a pre-trained risk type matching model (the model is based on a database of historical accident cases and risk events and is constructed using machine learning algorithms such as decision trees or naive Bayes). Based on the input environmental feature parameters, the model will screen out risk types that are highly relevant to the current locomotive driving environment from a preset risk library (including derailment risk, brake failure risk, component overheating risk, signal failure risk, collision risk, and other risk types and their feature descriptions). For example, when the environmental data shows that the current locomotive is traveling on a mountainous road section with a continuous downhill slope and a slippery road surface, "brake overheating failure risk" and "derailment risk" will be preferentially screened out.

[0027] In step S140, the on-board buffer pool compares the generated predicted risk scores for each risk type with the preset risk score threshold (the threshold is set according to the severity of the risk type and safety regulations, such as the "collision risk" threshold is set to 80 points and the "component overheating risk" threshold is set to 70 points) in real time. If the predicted risk score of any risk type is greater than its corresponding risk score threshold, the system immediately triggers the video encryption transmission process and retrieves the real-time video stream associated with the risk type (collected in real time by the camera in the corresponding monitoring area) and historical video clips (ensuring that the key processes before the risk event occur are included) from the video storage unit of the on-board buffer pool. The encryption algorithm adopts the national secret algorithm, that is, the SM2 national secret algorithm is used to encrypt the key application process, and the SM4 national secret algorithm is used to encrypt the video stream data, and metadata such as timestamp, locomotive ID, risk type label, etc. are added. The encrypted video is then pushed to the server through the VPN 5G network with a private protocol. After receiving the encrypted video, the server identifies the client identity through the 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 and the maintenance personnel mobile terminal). After the client receives the encrypted video and decryption key, it uses the local decryption plug-in to decrypt the video data, and plays and stores it in real time through a player that supports H.265 / H.264 encoding.

[0028] If no risk type with a predicted risk score greater than the risk score threshold is detected in step S140, step S150 is entered. The on-board buffer pool accesses the server-side risk database through a private protocol and retrieves the corresponding historical statistical data based on the currently screened risk type, including the historical number of occurrences of the risk type on similar locomotives, the same type of lines, and similar environmental conditions (the number of actual risk events that occurred in the past three months), the number of false alarms (the number of times the system alerts and manual review confirm that they are not real risks), and the average resolution time of historical risk events (the time consumed from the discovery of the risk event to its complete resolution, which can be accurate to minutes). These data are extracted from the database using structured query language (SQL) and returned to the on-board buffer pool.

[0029] In step S160, based on the retrieved historical data, the following formula is used to generate a revised prediction value: Revised prediction value = [(historical number of occurrences - number of false alarms) / historical number of occurrences] × baseline risk coefficient + resolution time × time impact factor, where the baseline risk coefficient is set according to the inherent danger of the risk type (such as the collision risk coefficient is higher than the risk of slight overheating of the component), and the time impact factor reflects the impact of the resolution time on the spread of risk (the longer the resolution time, the larger the factor value). The revised prediction value calculated by this formula can more objectively reflect the actual threat level of the risk.

[0030] 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 provide early warning of potential risks. For example, when 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 for a longer period of time) is sent to the server so that the monitoring center can intervene in the analysis in advance.

[0031] If the trigger conditions are still not met in step S170, the system proceeds to step S180. For each risk type, the onboard buffer pool retrieves the predicted risk score time series data for that risk type from the past 72 hours. Using time as the horizontal axis and the predicted risk score as the vertical axis, the system smooths the data using a sliding window averaging method to eliminate short-term fluctuation noise. Then, using polynomial fitting (such as cubic spline fitting) or a deep learning-based time series prediction model (such as a temporal convolutional network), it constructs a risk curve for that risk type, visually displaying the risk score's temporal trend, peaks, valleys, and fluctuation frequency. In step S190, based on the constructed risk curve, the system calculates the average time required for the predicted risk value to rise from the current value to the risk score threshold per unit time (e.g., per hour). Combined with the distribution of risk value increase rates in historical data, the system uses a differential algorithm to determine the slope of each point on the curve. This results in the approximation rate of the predicted risk value for that risk type toward the risk score threshold (i.e., the percentage of the risk value approaching the risk score threshold per unit time, e.g., "5% approaching the risk score threshold every 10 minutes").

[0032] In S200, the step of adjusting the monitoring frequency of the corresponding risk type according to the approach rate includes: The approach rate is matched with the preset mapping rule to determine the frequency adjustment direction and adjustment step size. If the approach rate exceeds the first threshold, the monitoring frequency is increased according to the maximum step size. If the approach rate is lower than the second threshold, the monitoring frequency is reduced according to the minimum step size. If the approach rate is between the first threshold and the second threshold, the monitoring frequency is dynamically adjusted in a linear proportion.

[0033] Specifically, during the system initialization phase, a pre-defined rule base maps risk types to approach rates, clearly defining first (upper) and second (lower) thresholds corresponding to different risk levels. When the real-time approach rate exceeds the first threshold, the system automatically triggers the highest-level monitoring response mechanism, significantly increasing monitoring frequency with a preset maximum step size (for example, shortening the monitoring interval from one hour to 15 minutes) to ensure full coverage tracking in high-risk situations. Conversely, if the approach rate consistently falls below the second threshold, the minimum step size (for example, extending the interval from 24 hours to 48 hours) is adopted to gradually reduce the monitoring load and avoid resource waste. For values ​​between the two thresholds, the system initiates a dynamic calibration algorithm: First, the relative position of the current approach rate within the threshold range is calculated and used as a linear coefficient. This coefficient is then multiplied by the difference between the maximum and minimum step sizes. Finally, the minimum step size is added to determine the specific adjustment amount (formula: adjustment amount = minimum step size + [(approach rate - second threshold) / (first threshold - second threshold)] × (maximum step size - minimum step size)).

[0034] Reference Figure 2 The steps of generating a predicted risk score corresponding to the screened risk type based on the real-time operation data and the environmental data include S210-S230: S210, constructing a risk assessment model and a risk factor mapping table; S220, inputting the real-time operation data and environmental data into the risk assessment model to output an initial prediction value; S230 , extracting matching risk factors and their weights from a mapping table based on current environmental data and the real-time status of the locomotive, so as to revise the initial prediction value.

[0035] Specifically, a risk assessment model framework based on ensemble learning is deployed on the onboard edge server: first, the XGBoost algorithm is used to establish a basic prediction architecture, and the feature importance weights are trained through the historical accident data set (including more than 100,000 locomotive sensor records and environmental parameters); at the same time, a risk factor mapping table is constructed - the key influencing factors of 12 core risks such as "brake overheating failure" (such as slope angle, wheel-rail adhesion coefficient, brake pad temperature change rate) are quantified and encoded, and the weight coefficient of each factor is determined based on SHAP value analysis (such as the weight increases by 0.15 for every 1° increase in the slope of a continuous downhill section). When the locomotive transmits real-time data packets (including 32-dimensional parameters such as acceleration / GPS coordinates / temperature and humidity with 0.1-second accuracy) through the 5G+Beidou integrated network, the preprocessing engine will perform three-stage processing: ① Spatiotemporal alignment (matching environmental meteorological data with the locomotive position); ② Outlier cleaning (using ③ Feature vectorization (for example, converting the current slope of 7° and air humidity of 85% into a normalized array of [0.7, 0.85]). This vector is input into the XGBoost model, which outputs an initial probability-based risk value Pt (for example, an initial derailment risk value of 0.38). The model also generates an explainable report that identifies key decision paths.

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

[0037] Reference Figure 3 The step of sending the encrypted video associated with the risk type to the server includes S310-S330: S310, retrieve the curvature radius of the locomotive running track; S320, calculating the video retrieval duration based on the video bit rate, curvature radius, and real-time operation data; S330: retrieve historical videos associated with the risk type based on the video retrieval duration and send them to the server.

[0038] Specifically, the locomotive collects track geometry data in real time through onboard sensors (such as gyroscopes or GPS trajectory analysis modules). Combined with route information stored in high-precision digital maps, the curvature radius of the current operating section is dynamically calculated. This data is read via the onboard control system's CAN bus or Ethernet interface and transmitted via a tunneling protocol to an onboard buffer pool for temporary storage. Based on the curvature radius, the locomotive's real-time speed / acceleration data, and a preset video bitrate (e.g., 4 Mbps in H.264 encoding), the onboard buffer pool dynamically determines the length of historical video to be retrieved using a safety threshold model. The specific formula can be: Retrieval duration = (safety factor × curvature radius) / (real-time speed × video bitrate weight). The smaller the curvature radius (sharper curves) or the higher the speed, the longer the required video replay duration. The model parameters are continuously optimized through machine learning based on actual operating scenarios to ensure coverage of critical operational scenes before a risk occurs. Based on the calculated retrieval duration, the onboard buffer pool retrieves video clips (typically in HLS slice format) from the local solid-state drive for the corresponding time period.

[0039] Reference Figure 4 Furthermore, the video stream remote transmission method further includes S410-S440: S410, after the video is sent to the server, the current playback status and network delay data of the client are monitored in real time; S420, when it is detected that the playback delay exceeds a preset threshold or the network bandwidth is lower than the set requirement, the video bit rate adaptive adjustment algorithm is automatically triggered to dynamically reduce the video resolution or frame rate, and a degradation report is generated and pushed to the client; S430, collecting user feedback information after decryption and playback on the client based on the degradation report; S440: Update the video transmission strategy in the risk library based on user feedback information and optimize subsequent video retrieval parameters.

[0040] 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 delay data in real time. This can be achieved by integrating a lightweight status acquisition module on the client. This module sends a status message containing the current playback progress, buffering time, and number of freezes (determined by comparing the expected playback time with the actual playback time) to the server once per second. At the same time, the server uses the ICMP protocol to periodically send probe packets to the client, calculate the round-trip time (RTT) as network delay data, and store this information in a distributed time series database (such as InfluxDB) in real time. The fluctuations of key indicators are displayed in real time through a visual monitoring panel (such as Grafana).

[0041] When the server detects an anomaly based on a preset threshold (e.g., network latency exceeding 300ms for three consecutive seconds or real-time network bandwidth falling below 1.2 times the current video bitrate), the adaptive video bitrate adjustment algorithm is automatically triggered. Specifically, this algorithm utilizes layered coding technology based on the H.265 / HEVC standard, pre-storing multiple resolution versions of the same video (e.g., 4K, 2K, 1080P, and 720P) on the server. The algorithm analyzes current network bandwidth, latency, and historical bitrate adjustment history, then uses FFmpeg to dynamically switch to a matching resolution (e.g., from 1080P to 720P). It also proportionally reduces the frame rate (e.g., from 60fps to 30fps). The algorithm then generates a degradation report using an RTP protocol extension field containing the degradation reason (e.g., "Insufficient network bandwidth, adjusted to 720P / 30fps"). This report is encrypted with AES-128 and pushed to the client via WebSocket. Upon receiving the report, the client displays a semi-transparent notification bar at the bottom of the playback interface, informing the user of the current video quality adjustment and providing recovery suggestions (e.g., "Switching to Wi-Fi for improved quality").

[0042] Based on the degradation report received by the client, after the video is decrypted and played, the system collects user feedback in two ways. First, after the degradation state is lifted (e.g., five minutes after the network returns to normal), a lightweight feedback window pops up on the client, providing three options: "Acceptable quality," "Noticeable lag," and "Blurring video quality," along with a text input box. After the user submits the feedback, the data is transmitted to the server via HTTPS encryption. Second, the system automatically collects user behavior data during the degradation period (e.g., number of fast-forwards, pause duration, and whether the video resolution is actively switched). This data is combined with explicit user feedback to construct a feedback dataset. Natural language processing (NLP) techniques are used to perform sentiment analysis on the text feedback (e.g., identifying "too blurry" as negative feedback). The system then associates structured feedback information (e.g., feedback type, degradation duration, and user rating) with the corresponding video ID and transmission session ID.

[0043] Finally, the server updates the video transmission policy in the risk library based on collected user feedback. Specifically, a machine learning-based policy optimization model is constructed, using user feedback (e.g., 80% of users rate 720P / 30fps degradation as "acceptable"), network environment characteristics (e.g., the optimal initial bitrate on 4G networks), and video content attributes (e.g., action films 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 accesses the service for the first time, the policy library will initially assign a lower bitrate version based on historical data from the network operator in their IP location, and then gradually increase it. For users who frequently report lag, a pre-load buffering mechanism is automatically enabled (caching 30 seconds of video content in advance). The optimized policy is then synchronized to the edge computing servers of CDN nodes, ensuring real-time policy implementation at the nearest node. Finally, the effectiveness of the policy optimization is verified through A / B testing (e.g., increasing the average viewing completion rate as a core KPI).

[0044] Based on the above method embodiments, the second embodiment of the present application discloses a video stream remote transmission system based on a locomotive 6A system. The video stream remote transmission system based on the locomotive 6A system of the present embodiment can implement any of the above methods for remote transmission of video streams based on the locomotive 6A system, and the specific operating processes of each module in the video stream remote transmission system based on the locomotive 6A system can refer to the corresponding processes in the above method embodiments.

[0045] For ease of understanding, refer to Figure 5 , an example is as follows: A video stream remote transmission system based on the locomotive 6A system, comprising: An onboard buffer pool interacts with the locomotive's 6A system data to collect the locomotive's real-time operating data and environmental data of the locomotive's driving area, as well as to store and encrypt locomotive videos. The onboard buffer pool is further configured to filter risk types corresponding to the locomotive from a risk library based on the environmental data, and generate predicted risk scores corresponding to the filtered risk types based on the real-time operating data and the environmental data. If a risk type exists for which the predicted risk score is greater than a risk score threshold, the encrypted video associated with the risk type is transmitted. The server communicates with the vehicle-mounted buffer pool via a VPN 5G network, is configured to receive and push the encrypted video, and distribute keys to the vehicle-mounted buffer pool and the client; The client is used to receive the encrypted video and decrypt and play the encrypted video.

[0046] Specifically, for real-time video, the on-board buffer pool device implements this functionality using embedded Linux C++. It interacts with the server via a proprietary protocol to obtain attributes such as the channel number and bitrate for real-time preview. It then uses the FFmpeg API to pull H.264-formatted video data from the corresponding channel camera. Through multi-threaded processing, the H.264 video data is encapsulated using a proprietary protocol and encrypted using the SM4 algorithm. Finally, through socket programming, the encrypted data is pushed to the server. The server then parses the data and pushes it to the client, which decrypts and plays it.

[0047] For historical videos, the onboard buffer pool device uses FTP to capture the historical video calendar of the video board in the 6A system and save it to a JSON file. It then traverses the captured calendar and uses FFmpeg's FTP streaming function to pull the daily historical video files, obtaining the start time, duration, size, and other attributes of each video file, and saves them to a newly created JSON file. When a client requests the historical video calendar and the duration of historical videos for a specific date, the onboard buffer pool pushes the data contents of the JSON file to the server using a proprietary protocol in a fixed format. The server then sends it to the client. When a user clicks a time point in the acquired historical video timeline, the server sends the requested time, channel, and other related attributes to the onboard buffer pool device using a proprietary protocol. The buffer pool uses FFmpeg's FTP to pull historical video data from the video board starting at the corresponding time. Through multi-threaded processing, it performs SM4 encryption and pushes it to the server. The server then parses the data and pushes the encrypted data file to the client, which decrypts and plays it.

[0048] In addition, the on-board buffer pool device will encapsulate the h.264 data pulled by ffmpeg through PS stream video and store it in the buffer pool's hard disk with a fixed length and format for backup purposes to prevent the loss of important videos due to damage to the video board in the 6A system.

[0049] Furthermore, when caching historical video files, the vehicle's onboard buffer pool device retrieves the required time period, uses FFmpeg to pull the video files for that time period, and caches them on the hard drive. The buffer pool then pushes the video files to the corresponding directory on the server via FTP. During this process, the buffer pool first checks the server for the existence of the file. If not, it starts uploading from the beginning. If it exists, it retrieves the size of the existing file and skips the upload to the next file, enabling resumable downloads.

[0050] Finally, it's important to note that 5G network transmission using VPN can support previously unattainable video data volumes and ensure data security. Data encryption using a combination of SM4 and SM2 ensures the integrity and security of encrypted data. Real-time video directly pulls video data from the camera without forwarding it through other devices, ensuring data accuracy and real-time performance. Historical video data can be directly pulled from the 6A system video card to maximize device utilization. Resuming historical video data via FTP reduces duplicate uploads and ensures data integrity.

[0051] The third embodiment of the present application provides a terminal. As an implementation of the terminal, the terminal may include: a memory and a processor; wherein, The memory is used to store a video stream remote transmission program based on the locomotive 6A system; The processor is used to execute the program stored in the memory to implement the steps of the above-mentioned video stream remote transmission method based on the locomotive 6A system.

[0052] The memory may be communicatively connected to the processor via a communication bus, and the communication bus may be an address bus, a data bus, a control bus, or the like.

[0053] In addition, the memory may include a random access memory (RAM) and may also include a non-volatile memory (NVM), such as at least one disk storage.

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

[0055] The above are all preferred embodiments of the present application and are not intended to limit the scope of protection of the present application. Unless otherwise specified, any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features. In other words, unless otherwise specified, each feature is merely an example of a series of equivalent or similar features.

Claims

1. A video stream remote transmission method based on a locomotive 6A system, characterized in that: The execution body of the vehicle buffer pool includes: Collect real-time operation data of the locomotive and environmental data of the locomotive driving area; Filtering the risk type corresponding to the locomotive from the risk library according to the environmental data; generating a predicted risk score corresponding to the screened risk type based on the real-time operation data and the environmental data; If there is a risk type whose predicted risk score is greater than the risk score threshold, an encrypted video associated with the risk type is sent to the server, where 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.

2. A video stream remote transmission method based on a locomotive 6A system according to claim 1, characterized in that: The step of generating a predicted risk score corresponding to the screened risk type according to the real-time operation data and the environmental data includes: Construct risk assessment models and risk factor mapping tables; Inputting the real-time operation data and the environmental data into the risk assessment model to output an initial prediction value; According to 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 modify the initial prediction value.

3. The method for remotely transmitting video streams based on a locomotive 6A system according to claim 1, characterized in that: The steps of sending the encrypted video associated with the risk type to the server include: Retrieve the curvature radius of the locomotive running track; Calculate the video retrieval duration based on the video bit rate, the curvature radius, and the real-time running data; According to the video retrieval duration, historical videos associated with the risk type are retrieved and sent to the server.

4. The method for remotely transmitting video streams based on a locomotive 6A system according to claim 1, characterized in that: The video stream remote transmission method further includes: If there is no risk type with the 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; Generate a revised prediction value corresponding to the risk type based on the historical number of occurrences, the number of false alarms, and the resolution time; If there is a risk type whose corrected prediction value is greater than the correction threshold, the encrypted video associated with the risk type is sent to the server.

5. The method for remotely transmitting video streams based on the locomotive 6A system according to claim 4, characterized in that: The steps after generating the revised predicted value corresponding to the risk type also include: If there is no risk type with a revised predicted value greater than the revised threshold, then a risk curve graph corresponding to the risk type is constructed; According to the risk curve, obtaining the approach rate of the predicted risk value of the corresponding risk type to the risk score threshold; The monitoring frequency of the corresponding risk type is adjusted according to the approach rate.

6. A method for remotely transmitting video streams based on a locomotive 6A system according to claim 5, characterized in that: The step of adjusting the monitoring frequency of the corresponding risk type according to the approach rate includes: Matching the approximation rate with a preset mapping rule to determine a frequency adjustment direction and an adjustment step size; If the approach rate exceeds a first threshold, increasing the monitoring frequency by a maximum step size; If the approach rate is lower than a second threshold, reducing the monitoring frequency by a minimum step size; If the approach rate is between the first threshold and the second threshold, the monitoring frequency is dynamically adjusted in a linear proportion.

7. The method for remotely transmitting 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 delay data are monitored in real time; When it is detected that the playback delay exceeds the preset threshold or the network bandwidth is lower than the set requirement, the video bit rate adaptive adjustment algorithm is automatically triggered to dynamically reduce the video resolution or frame rate, and generate a degradation report and push it to the client; Based on the degradation report, collecting user feedback information after decryption and playback on the client side; Based on the user feedback information, the video transmission strategy in the risk library is updated and subsequent video retrieval parameters are optimized.

8. A video stream remote transmission system based on the locomotive 6A system, characterized in that: Executing the video stream remote transmission method based on the locomotive 6A system according to any one of claims 1 to 7 comprises: An onboard buffer pool interacts with the locomotive's 6A system data to collect the locomotive's real-time operating data and environmental data of the locomotive's driving area, as well as to store and encrypt locomotive videos. The onboard buffer pool is further configured to filter risk types corresponding to the locomotive from a risk library based on the environmental data, and generate predicted risk scores corresponding to the filtered risk types based on the real-time operating data and the environmental data. If a risk type exists for which the predicted risk score is greater than a risk score threshold, the encrypted video associated with the risk type is transmitted. The server communicates with the vehicle-mounted buffer pool via a VPN 5G network, is configured to receive and push the encrypted video, and distribute keys to the vehicle-mounted buffer pool and the client; The client is used to receive the encrypted video and decrypt and play the encrypted video.

9. A terminal, characterized in that: include: a memory storing a video stream remote transmission program based on the locomotive 6A system; The processor is configured to execute the program stored in the memory to implement the steps of the method for remotely transmitting video streams based on the locomotive 6A system as described in any one of claims 1 to 7.

Images