A method and system for concurrent distribution of multi-channel video streams and optimization in weak network conditions using unmanned aerial vehicles (UAVs).
By constructing a link fate graph and using the bat algorithm to optimize the transmission order of multiple video streams from drones, key content data is sent in advance, solving the problem of drones transmitting data in advance in high-risk areas, and achieving stable delivery of key content and efficient utilization of resources from multiple video streams.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHENZHEN TUOBIDA TECH CO LTD
- Filing Date
- 2026-04-24
- Publication Date
- 2026-06-30
AI Technical Summary
Existing drone multi-stream concurrent distribution systems struggle to complete the pre-transmission of critical content before entering high-risk areas when network conditions are unstable. This results in key footage being captured during the most unfavorable transmission periods, affecting video playback continuity and the delivery rate of critical content.
By reading multiple video streams, flight path data, and link status data, a video stream set is generated and a link fate graph is constructed. The bat algorithm is combined to optimize the segment boundaries and content transmission order, key content data is sent in advance, and maintenance transmission and differential backfilling are performed in high-risk segments to generate a corrected segmented transmission queue to achieve concurrent distribution to multiple terminals and weak network recovery.
It improved the delivery rate of key content, reduced the probability of playback interruption in high-risk sections, enhanced the resource utilization efficiency and system adaptability of concurrent distribution of multiple video streams, and ensured the stability and continuity of video transmission.
Smart Images

Figure CN122093534B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of UAV video transmission and edge network collaborative processing technology, and in particular to a method and system for concurrent distribution of multiple UAV video streams and optimization of weak network conditions. Background Technology
[0002] Drone video stream distribution technology has been widely applied to various scenarios involving real-time acquisition and transmission of aerial video data. Existing systems can typically handle drone video access, single-channel streaming, multi-terminal distribution, and protocol conversion. By detecting bandwidth usage, round-trip latency, packet loss rate, and jitter, they perform frame reduction, bitrate reduction, forward error correction, critical content caching, and base station pre-handover on the current link to maintain video playback continuity as much as possible. For scenarios with relatively stable network conditions and small flight ranges, the above methods can meet basic usage requirements.
[0003] However, drones continuously traverse different areas during flight, and their subsequent paths may enter obstructed areas, base station boundary areas, or high-interference areas, resulting in significant variations in network conditions across different segments. While existing technologies can adjust based on the current link status, their focus remains on remediation after link degradation. They typically still transmit video content according to its natural chronological order, failing to further consider network risks along the subsequent flight path and proactively arrange the transmission order of critical and non-critical content.
[0004] The above problems are even more pronounced in scenarios involving the concurrent distribution of multiple video streams from drones. Since multiple video streams simultaneously occupy edge network resources, if the system cannot prioritize sending critical content before entering high-risk areas, the crucial footage that truly affects command and control decisions is likely to fall into the most unfavorable transmission period. By the time compensation is attempted after the link quality deteriorates, the optimal time to send critical content has often been missed.
[0005] Therefore, this invention proposes a method and system for concurrent distribution of multiple video streams from unmanned aerial vehicles (UAVs) and optimization in weak network conditions. The information disclosed in the background section is only for enhancing understanding of the background of this disclosure and may therefore contain prior art information that is not common knowledge to those skilled in the art. Summary of the Invention
[0006] The purpose of this invention is to address the shortcomings of existing technologies by providing a method and system for concurrent distribution of multiple video streams from unmanned aerial vehicles (UAVs) and optimization in weak network conditions, thereby solving the technical problems mentioned in the background section.
[0007] To achieve the above objectives, the present invention provides the following technical solution:
[0008] The first part of this invention provides a method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions, comprising the following steps:
[0009] S1. Read multiple video streams, flight path data, and link status data; perform time correction, path splicing, and index merging on the multiple video streams, flight path data, and link status data to generate a video stream set.
[0010] S2. Divide candidate segments according to the video stream set, and combine the bat algorithm to jointly optimize the boundary of the flight path segment, the pre-sending window of key content and the weight of concurrent sending of multiple video streams to generate a link fate graph.
[0011] S3. Based on the video stream set and link fate graph, perform content classification and segmentation of each video stream to generate segmented transmission queues;
[0012] S4. Based on the link fate map and segmented transmission queue, perform pre-concurrent distribution of critical content data and generate a recovery index set in low-risk segments, and perform hold-through transmission and generate a segment transmission result table in high-risk segments.
[0013] S5. Generate a queue correction request based on the video stream set, link fate graph, segmented transmission queue, recovery index set and segmented transmission result table, obtain the corrected segmented transmission queue, and complete multi-terminal concurrent distribution and weak network recovery based on the corrected segmented transmission queue.
[0014] S1 specifically includes: reading multiple video streams, flight path data, and link status data from the UAV equipment side, flight control scheduling side, and edge network respectively; performing nearest-neighbor interpolation or deletion on records with missing stream identifiers, task identifiers, timestamps, or link fields; uniformly parsing the task identifiers, timestamps, and stream identifiers in the multiple video streams; performing time correction, path attachment, and link status attachment with a unified time base; generating a unified stream registration table and stream path association records; and performing index merging and consistency verification based on the unified stream registration table and stream path association records to generate a video stream set containing task identifiers, a unified timeline, corresponding flight segment sequences, and corresponding link status sequences.
[0015] S2 specifically includes: based on the flight segment sequence and corresponding link state sequence in the video stream set, using the path interval between adjacent waypoints as the initial segment, dividing candidate segments by combining bandwidth usage, round-trip latency, packet loss rate, jitter value, and edge network node switching times, and generating a candidate segment risk table; calling the Bat Algorithm to jointly optimize the flight path segment boundaries, key content pre-sending window, and concurrent transmission weights of multiple video streams, generating an optimized segment parameter set; re-executing segment determination based on the optimized segment parameter set and the candidate segment risk table, determining high-risk and low-risk segments, and generating a link fate graph containing segment identifiers, segment start and end times, risk levels, corresponding edge network nodes, key content pre-sending windows, and concurrent transmission weights of multiple video streams.
[0016] S3 specifically includes: based on the video stream set and link fate graph, and according to task priority, content type, and time sensitivity, performing content classification on video segments in each video stream to obtain key content data and non-key content data, and generating content classification records; based on the content classification records and link fate graph, moving key content data located in high-risk segments forward and delaying non-key content data that meets the conditions forward, generating segmented arrangement records; and based on the segmented arrangement records, link fate graph, and optimized segment parameter set, generating segmented transmission queues including a key content queue for low-risk segments, a maintenance queue for high-risk segments, and a delayed queue for non-key content.
[0017] S4 specifically includes: based on the link fate map and segmented transmission queue, extracting key content data of the current low-risk segment and the key content data required for subsequent high-risk segments in the low-risk segment, performing pre-concurrent distribution, and generating a recovery index set and pre-distribution record; when entering a high-risk segment, sending time synchronization data, retransmission indication data, and differential correction data according to the high-risk segment maintenance queue and recovery index set in the segmented transmission queue, and generating a high-risk maintenance record; and performing a unified check on the segment transmission results based on the pre-distribution record, recovery index set, and high-risk maintenance record, determining the segments that have been transmitted, the segments to be retransmitted, and the segments that need to be retransmitted, and generating a segment transmission result table.
[0018] S5 specifically includes: generating a queue correction request based on the video stream set, link fate graph, segmented transmission queue, recovery index set, and segmented transmission result table, combined with link feedback data in the edge network; performing real-time correction on key content data, segments to be retransmitted, segments to be retransmitted, and edge network node load in the segmented transmission queue based on the queue correction request, generating a corrected segmented transmission queue; and performing differential backfilling, fixed-point retransmission, and delayed transmission based on the corrected segmented transmission queue, recovery index set, high-risk retention record, and segmented transmission result table to complete multi-terminal concurrent distribution and weak network recovery.
[0019] The second part of this invention provides a system for concurrent distribution of multiple video streams from a drone and optimization of weak network conditions, comprising:
[0020] The data reading and video stream set generation module is used to read multiple video streams, flight path data, and link status data respectively.
[0021] The link fate graph construction module is used to divide candidate segments based on the video stream set and generate a candidate segment risk table.
[0022] The content classification and segmented sending queue generation module is used to perform content classification and segmented arrangement of each video stream based on the video stream set and link fate graph;
[0023] The pre-distribution and high-risk retention module is used to perform pre-concurrent distribution of critical content data in low-risk segments and generate a recovery index set based on the link fate graph and segmented transmission queue;
[0024] The real-time correction and weak network recovery module is used to analyze the video stream set, link fate graph, segmented transmission queue, recovery index set, and segmented transmission result table.
[0025] The beneficial effects of this invention are as follows:
[0026] This invention reads multiple video streams, flight path data, and link status data to first generate a set of video streams, and then constructs a link fate graph. This allows the video transmission process to no longer rely solely on the current link status for passive adjustments, but can instead formulate transmission strategies in advance based on the network risks of the UAV's subsequent flight segments, thereby improving the scheduling targeting in weak network scenarios from the source.
[0027] This invention optimizes the boundaries of flight path segments, the pre-sending window for key content, and the weights for concurrent transmission of multiple video streams. This enables the early transmission of key content data required for subsequent high-risk segments in low-risk segments, avoiding passive remediation after key content falls into high packet loss and high latency segments, thereby improving the delivery rate of key images and business continuity.
[0028] This invention classifies and segments video clips, moves key content data forward and postpones non-key content data, and generates segmented transmission queues. This ensures that limited bandwidth is prioritized for the transmission of key content data, reduces the crowding out of high-value footage by non-key content, and improves resource utilization efficiency when multiple video streams are distributed concurrently.
[0029] This invention forms a complete weak network recovery closed loop by performing pre-concurrent distribution in low-risk segments, maintaining transmission in high-risk segments, and combining a recovery index set, a segment transmission result table, and a corrected segment transmission queue to perform differential backfilling, fixed-point retransmission, and delayed transmission, thereby reducing the probability of terminal playback interruption caused by the loss of critical content in high-risk segments.
[0030] This invention generates queue correction requests by combining real-time link feedback data in the edge network and performs real-time correction on the segmented transmission queue. When the link status deviates from the prediction result, the transmission order and allocation method of key content data, segments to be retransmitted, segments to be retransmitted, and edge network node load can be adjusted in a timely manner, thereby improving the system's adaptability to dynamic weak network environments and multi-terminal concurrent scenarios.
[0031] This invention establishes a correspondence between network risks in the subsequent flight path and the transmission order of different content in multiple video streams, solving the problem that existing technologies can only passively adjust parameters based on the current link status and are unable to complete the pre-transmission of critical content before entering high-risk sections. Therefore, it can simultaneously improve the critical content protection capability, concurrent distribution stability, and weak network recovery effect. Attached Figure Description
[0032] Figure 1 This is a schematic diagram of a method for concurrent distribution of multiple video streams from a drone and optimization in weak network conditions, according to the present invention.
[0033] Figure 2 This is a schematic diagram of the framework of a UAV multi-channel video stream concurrent distribution and weak network optimization system according to the present invention. Detailed Implementation
[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0035] Example 1: As Figure 1 As shown, this embodiment provides a method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions, including the following steps:
[0036] S1. Read multiple video streams, flight path data, and link status data; perform time correction, path splicing, and index merging on the multiple video streams, flight path data, and link status data to generate a video stream set.
[0037] S2. Divide candidate segments according to the video stream set, and combine the bat algorithm to jointly optimize the boundary of the flight path segment, the pre-sending window of key content and the weight of concurrent sending of multiple video streams to generate a link fate graph.
[0038] S3. Based on the video stream set and link fate graph, perform content classification and segmentation of each video stream to generate segmented transmission queues;
[0039] S4. Based on the link fate map and segmented transmission queue, perform pre-concurrent distribution of critical content data and generate a recovery index set in low-risk segments, and perform hold-through transmission and generate a segment transmission result table in high-risk segments.
[0040] S5. Generate a queue correction request based on the video stream set, link fate graph, segmented transmission queue, recovery index set and segmented transmission result table, obtain the corrected segmented transmission queue, and complete multi-terminal concurrent distribution and weak network recovery based on the corrected segmented transmission queue.
[0041] S1 specifically includes the following sub-steps:
[0042] S110. At the start of a concurrent distribution of multiple video streams from a UAV and weak network optimization processing, multiple video streams are read from the UAV equipment side, flight path data is read from the flight control scheduling side, and link status data is read from the edge access node, edge forwarding node and edge computing node in the edge network.
[0043] Multiple video streams are registered using raw video stream records. Each raw video stream record includes at least the stream identifier, task identifier, acquisition timestamp, encoding type, frame sequence number, and source device identifier. Flight path data is registered using raw path records. Each raw path record includes at least the UAV identifier, takeoff time, waypoint sequence, waypoint timestamp, waypoint coordinates, and estimated arrival time. Link status data is registered using raw link status records. Each raw link status record includes at least the segment identifier, acquisition time, bandwidth usage, round-trip time, packet loss rate, jitter value, and node load.
[0044] To avoid invalid input during subsequent connection, field integrity checks are first performed on three types of records: original video stream records missing stream identifiers, task identifiers, or acquisition timestamps are directly deleted; original path records missing drone identifiers, waypoint sequences, or waypoint timestamps are directly deleted; and original link status records missing any of the following fields—segment identifier, acquisition time, bandwidth usage, round-trip latency, packet loss rate, jitter value, or node load—are first subjected to proximity interpolation by calling the complete records of the previous and next acquisition times for the same segment. If the interpolation is still incomplete, the records are directly deleted.
[0045] To ensure subsequent time alignment is executable, the retained original video stream records, original path records, and original link status records are then sorted by time and written to the original video stream record table, original path record table, and original link status record table, respectively. The original video stream records, original path records, and original link status records are then output for use by S120.
[0046] S120: Read the original video stream records, original path records, and original link status records. Perform unified parsing of the task identifier, timestamp, and stream identifier in each video stream. Using the standard clock on the flight control scheduling side as a unified time reference, perform time correction on the original video stream records and original path records to obtain the video timestamp and path timestamp under a unified timeline. Time correction is performed using a time difference determination method, with the determination formula as follows:
[0047] ;
[0048] In the formula, This represents the time difference between the current video frame timestamp and the current waypoint timestamp. This indicates the video timestamp corresponding to the current video frame. This represents the path timestamp corresponding to the current waypoint.
[0049] The preset time tolerance is set to 200 milliseconds. When the time tolerance is less than or equal to the preset time tolerance, it is determined that the current video frame and the current waypoint can be linked; when If the time difference exceeds the preset time tolerance, the current video frame is written into the record to be corrected, and comparison with adjacent waypoints continues. If the time difference with both the preceding and following waypoints exceeds the preset time tolerance, the record to be corrected is deleted.
[0050] After time correction, the original video stream records are path-attached according to waypoint sequence, waypoint timestamps, and estimated arrival times, establishing a unique correspondence between each video stream and its corresponding flight segment. If the same video frame corresponds to multiple candidate flight segments within the same time window, the flight segment with the smallest time difference and whose segment boundary covers the current video timestamp is selected first. If the time differences are the same, the flight segment with higher link status record completeness is selected. Subsequently, the original link status records are attached to the corresponding flight segments according to segment identifiers and acquisition times, forming a link status sequence synchronized with the video timeline.
[0051] Based on the above processing, a unified flow registration table and a flow path association record are generated; wherein, the unified flow registration table includes at least a flow identifier, a task identifier, a unified timeline and a source device identifier, and the flow path association record includes at least a flow identifier, a flight segment sequence, a segment corresponding time range and a link status sequence.
[0052] Output a unified flow registration table and flow path association records for S130 to call, and for subsequent segment optimization processing based on the bat algorithm.
[0053] S130. Read the unified stream registration table and stream path association records, perform index merging on the unified timeline, flight segment sequence and link status sequence under the same stream identifier, and generate a video stream set.
[0054] The video stream collection is stored by creating index entries based on stream identifiers. Each index entry contains a fixed task identifier, a unified timeline, a corresponding flight segment sequence, and a corresponding link status sequence to ensure that the objects read in subsequent steps are unique and that the source of the fields is clear.
[0055] To prevent the generation of invalid set items, consistency verification is performed during the merging process: if there are two different task identifiers under the same stream identifier, the record corresponding to the task identifier with continuous time and complete frame sequence is retained, and the other record is deleted; if the flight segment sequence is inconsistent with the length of the unified time axis, the excess part of the flight segment sequence is deleted based on the unified time axis; if the link status sequence is missing more than two consecutive acquisition cycles in a certain flight segment, the flight segment is marked as a segment to be completed, but the corresponding video stream index item is not deleted, thereby ensuring that S210 can continue to perform risk statistics on candidate segments based on the index item.
[0056] To facilitate direct use in subsequent steps, the purpose of each field in the video stream set is fixed: the task identifier is used to determine task priority when identifying key content later; the unified timeline is used for subsequent segment boundary verification and real-time queue correction; the corresponding flight segment sequence is used for subsequent link fate map construction; and the corresponding link status sequence is used for subsequent segment risk assessment and weak network recovery.
[0057] To enhance executability, a small number of data constraints can be adopted. For example, for a certain video stream, if its unified timeline contains 1200 time points, and the corresponding flight segment sequence only contains 1198 valid attachment points, then the two unattached time points are deleted before being written into the video stream set. If the link status record acquisition period corresponding to a certain flight segment is set to 500 milliseconds, then one missing interpolation is allowed in a single acquisition period, and two consecutive missing periods are marked as segments to be filled.
[0058] The final output video stream set is used by S210 to read candidate segment information, by S310 to read task identifiers and unified timelines, and by S510 to read the entire index to perform real-time correction.
[0059] S2 specifically includes the following sub-steps:
[0060] S210. Read the video stream set, divide the subsequent flight path of the UAV into candidate segments according to the flight segment sequence and corresponding link status sequence of each video stream, and generate a candidate segment risk table.
[0061] Specifically, the path interval between adjacent waypoints is first used as the initial segment. Then, based on the bandwidth usage, round-trip delay, packet loss rate, jitter value, and edge network node identifier changes in the corresponding link state sequence, the initial segment is further subdivided or merged. When any of the changes in packet loss rate, round-trip delay, or jitter value in two consecutive sampling periods within the same interval exceeds a preset fluctuation threshold, the interval is split into two candidate segments at the corresponding sampling time to avoid merging path parts with significantly different link states into the same candidate segment. When a candidate segment contains fewer than 3 link state sampling points, the candidate segment is merged with the candidate segment that is temporally adjacent and has the smallest difference in link state to ensure that there is a sufficient sample size for subsequent risk statistics.
[0062] After dividing the candidate segments, the average bandwidth usage, average round-trip time, average packet loss rate, average jitter value, and edge network node handover count are calculated for each candidate segment. The edge network node handover count is defined as a valid handover where the edge network node identifier changes continuously for at least two sampling periods, preventing instantaneous jitter from being mistakenly recorded as a node handover. To ensure consistent comparison across different candidate segments, the above statistical results are normalized, and the risk value of the candidate segment is calculated using the following formula:
[0063] ;
[0064] In the formula, Indicates the risk value of the candidate segment; This represents the normalized bandwidth usage metric. This represents the normalized round-trip time delay indicator. This represents the normalized packet loss rate. This represents the jitter value after normalization. This represents the normalized edge network node switching count. This indicates the risk weight of the corresponding indicator, and .
[0065] In a preferred embodiment, it can be The values were set to 0.20, 0.20, 0.25, 0.20, and 0.15 respectively, so that the packet loss rate had a slightly higher impact on the candidate segment risk value than other indicators.
[0066] In addition, the system supports the aforementioned risk weights. Dynamic adaptive adjustment: Before the UAV enters a specific flight area, the system retrieves the fluctuation variance of the historical link status data of that area. If the historical fluctuation variance of a certain indicator (such as round-trip delay) is higher than the preset variance baseline, its corresponding risk weight is increased proportionally, so that the risk assessment is more in line with the actual network characteristics of the current area.
[0067] Subsequently, the segment identifier, start and end times, corresponding waypoint range, average bandwidth usage, average round-trip time, average packet loss rate, average jitter, edge network node switching count, and candidate segment risk value of each candidate segment are written into the candidate segment risk table. The candidate segment risk table is then output for S220 to use.
[0068] S220. Read the candidate segment risk table, call the bat algorithm to jointly optimize the flight path segment boundary, the key content pre-sending window and the weight of concurrent transmission of multiple video streams, and generate the optimized segment parameter set.
[0069] Each bat in the bat algorithm corresponds to a set of parameters to be solved. These parameters include at least the boundary positions of each candidate segment, the length of the pre-sending window for key content corresponding to each high-risk candidate segment, and the concurrent sending weights of multiple video streams within each candidate segment. The segment boundary positions are constrained by the waypoint order and cannot be crossed or reversed. The pre-sending window length for key content is limited to 1 to 5 seconds. The concurrent sending weights are limited to real numbers from 0 to 1, and the sum of the concurrent sending weights of each video stream within the same segment is 1.
[0070] The initial bat population is generated based on the start and end times of the segments in the candidate segment risk table and the risk values of the candidate segments. That is, the boundary of the segment with the larger risk value is first retained as the priority boundary, and then an adjustable boundary is randomly inserted between adjacent candidate segments to form multiple sets of comparable initial schemes.
[0071] For each individual bat, based on its corresponding segment boundary position, critical content pre-sending window length, and concurrent sending weight, the expected successful delivery rate of critical content, segment risk assessment consistency, terminal average latency, and edge network node load imbalance are calculated. Furthermore, the fitness value is calculated using the following formula:
[0072] ;
[0073] In the formula, Indicates the fitness value; This indicates the expected success rate of delivery of key content; This indicates consistency in risk assessment across different sections; Indicates the average latency of the terminal; This indicates the degree of load imbalance among edge network nodes; This represents the fitness weight of the corresponding evaluation item, and .
[0074] Among them, the expected successful delivery rate of key content is used to evaluate the likelihood that key content will be pre-sent before entering the high-risk segment under this set of parameters; the segment risk judgment consistency is used to evaluate whether the segment boundary matches the risk change trend of the candidate segment; the terminal average latency is used to limit the impact of the pre-sent process on the terminal playback timeliness; and the edge network node load imbalance is used to limit the excessive concentration of concurrent sending weight on a single edge network node.
[0075] In a preferred embodiment, it can be The values were set to 0.35, 0.25, 0.20, and 0.20 respectively. Subsequently, each bat individual was iteratively corrected according to the frequency, speed, and position update rules of the bat algorithm. When the change in the optimal fitness value over five consecutive iterations was less than a preset convergence threshold, the iteration stopped, and the segment boundary position corresponding to the optimal bat individual, the length of the key content pre-sending window, and the concurrent sending weights of multiple video streams were written into the optimized segment parameter set. The optimized segment parameter set was output for use by S230 and S330.
[0076] After each location update, a legality mapping process is performed on each individual bat: for multiple video streams sending weights concurrently, if the sum of weights in the same segment after the update is not 1 or is negative, then forced normalization is performed according to the ratio of the absolute value of each weight to the total.
[0077] For flight path segment boundaries, if the updated boundary position crosses adjacent waypoint constraints or time inversion occurs, the inverted boundary is forcibly backtracked and corrected to the time corresponding to the nearest legal waypoint. Through the above mapping, it is ensured that all iteratively corrected solutions satisfy the UAV operational constraints.
[0078] S230: Read the optimized segment parameter set and candidate segment risk table, and re-execute segment determination based on the optimized segment boundary position to form a link fate map characterizing the network transmission risk of the UAV's subsequent flight segment.
[0079] Specifically, the flight path is first re-segmented according to the segment boundary positions in the optimized segment parameter set to generate optimized segments; then, the number of link status sampling points covered by each optimized segment is verified. When an optimized segment covers less than 3 link status sampling points, the optimized segment is merged with the optimized segment that is temporally adjacent and has the smallest difference in risk value among candidate segments to ensure the stability of subsequent risk assessment.
[0080] For each optimized segment after verification, its corresponding candidate segment risk value, key content pre-sending window length, and multi-channel video stream concurrent sending weight are read, and risk level determination is performed according to the preset risk threshold. When the candidate segment risk value is greater than or equal to the preset risk threshold, the optimized segment is marked as a high-risk segment; when the candidate segment risk value is less than the preset risk threshold, the optimized segment is marked as a low-risk segment.
[0081] In a preferred embodiment, the preset risk threshold can be set to 0.60. Simultaneously, the edge network node corresponding to each optimization segment is determined: if multiple edge network nodes exist within an optimization segment, the edge network node with the longest occupancy time and the highest link state record completeness is selected as the corresponding edge network node for that optimization segment.
[0082] Finally, the segment identifier, segment start and end times, risk level, corresponding edge network node, key content pre-sending window, and concurrent video stream sending weights are written into the link fate graph. The risk level is used by S320 to determine the segment position of key and non-key content data when performing content arrangement; the key content pre-sending window is used by S320 when moving key content data forward; and the concurrent video stream sending weights are used by S330 when writing to the segment sending queue. The link fate graph is output for use by S310, S320, S410, and S510.
[0083] S3 specifically includes the following sub-steps:
[0084] S310: Read the video stream set and link fate graph, perform content classification on each video stream, and generate content classification records.
[0085] Specifically, the task identifier, unified timeline, corresponding flight segment sequence, and corresponding link status sequence are read item by item using the stream identifier in the video stream set as an index. Then, based on the risk level of each segment in the link fate map, the start and end times of the segment, and the pre-sending window of key content, the video segments on the unified timeline are located, so that each video segment obtains a unique flight segment.
[0086] Subsequently, task priority is determined based on task identifier, content type is determined based on frame structure corresponding to video segment, and time sensitivity is determined based on time interval between the start time of video segment and the start time of its high-risk section.
[0087] In determining the content type based on the frame structure corresponding to a video segment, the system directly reads and parses the NALU (Network Abstraction Unit) type identifier bit in the header of the video bitstream (such as H.264 or H.265 format), thereby quickly distinguishing keyframes (I-frames) from ordinary predicted frames (P-frames or B-frames). This process does not require full decoding of the video image data, ensuring the real-time nature of content classification at edge nodes.
[0088] Task priorities are determined using a pre-defined mapping table, with high-priority, medium-priority, and low-priority tasks corresponding to different priority scores. Content types are categorized into keyframe segments, ordinary predicted frame segments, and reconstruction reference segments, with keyframe segments and reconstruction reference segments receiving higher content scores than ordinary predicted frame segments. Time sensitivity characterizes the temporal proximity of the current video segment to high-risk sections; the smaller the time interval, the higher the time sensitivity score. To avoid relying solely on experience in determining key content, a content importance score is calculated for each video segment using the following formula:
[0089] ;
[0090] In the formula, This indicates the score for content importance; This indicates the priority score corresponding to the task priority; This indicates the content rating corresponding to the content type; This indicates the timeliness score corresponding to time sensitivity; This indicates the weight of the corresponding score, and .
[0091] In a preferred embodiment, The values can be set to 0.40, 0.35, and 0.25 respectively. After calculating the content importance score, if the content importance score is greater than or equal to the preset importance threshold, the corresponding video segment will be marked as key content data; if the content importance score is less than the preset importance threshold, the corresponding video segment will be marked as non-key content data.
[0092] For recovery reference segments located in high-risk segments and subsequently used in weak network recovery, even if their content importance score is below a preset importance threshold, they are forcibly marked as critical content data to ensure the integrity of the subsequent recovery chain. Finally, the flow identifier, segment identifier, segment start and end times, flight segment to which it belongs, content importance score, content classification tag, and corresponding link status segment are written into the content classification record. The content classification record is output for use by the S320.
[0093] S320: Read the content classification records and link destiny diagram, perform segmented arrangement of key content data and non-key content data, and generate segmented arrangement records.
[0094] Specifically, first, the preceding low-risk segment corresponding to each high-risk segment is identified according to the segment order in the link fate graph. Then, key content data belonging to the flight segment of that high-risk segment is extracted from the content classification record. For key content data, not all is directly moved forward; instead, it is further determined whether the start time of its segment falls within the key content pre-transmission coverage of the corresponding high-risk segment. Only when a key content data is located within a high-risk segment and its segment start time is later than the start time of the high-risk segment minus the key content pre-transmission window length, is that key content data identified as a forward-moving object. The forward-moving position is determined according to the pre-transmission start time, calculated using the following formula:
[0095] ;
[0096] In the formula, Indicates the start time of sending critical content data after the execution of the forward shift; Indicates the start time of the corresponding high-risk section; This indicates the length of the pre-send window for the key content corresponding to the high-risk segment in the link fate graph.
[0097] If the calculated start time of the forward transmission is earlier than the start time of the previous low-risk segment, then the start time of the forward transmission will be limited to the start time of the previous low-risk segment to avoid the forward position exceeding the transmittable segment. For non-critical content data, it is only allowed to be postponed to the next low-risk segment if its flight segment is a high-risk segment, the corresponding content is classified as non-critical content data, and it does not belong to the recovery reference segment; if a non-critical content data has a content importance score lower than the preset importance threshold, but its corresponding link status segment has been written into the subsequent recovery index generation range, then no postponement will be performed, and it will remain in the original segment.
[0098] After completing the forward shift and postponement, the adjusted segment position and adjusted transmission order are rewritten for each video segment. This ensures that critical content data shifted forward is located within the preceding low-risk segment, non-critical content data postponed is located within the following low-risk segment, and unadjusted video segments retain their original segment positions. Finally, the stream identifier, segment identifier, original segment position, adjusted segment position, transmission sequence number, forward shift flag, and postponement flag are written to the segment arrangement record. The segment arrangement record is output for use by the S330.
[0099] S330 reads the segment arrangement record, link fate map and optimized segment parameter set to generate segmented transmission queues for multiple video streams.
[0100] Specifically, the segmented arrangement records are first split according to the flow identifier, then the video segments under the same flow identifier are segmented according to the adjusted segment position, and sorted within the segment according to the sending sequence number. On this basis, according to the risk level in the link fate graph, the sorted video segments are written into the low-risk segment critical content queue, the high-risk segment maintenance queue, and the non-critical content delay queue, respectively.
[0101] Among them, video clips marked as forward objects and whose adjusted segment positions belong to low-risk segments are written into the low-risk segment critical content queue; video clips whose segments belong to high-risk segments and whose content classification is marked as critical content data are written into the high-risk segment maintenance queue; and video clips marked as follow-up objects and whose adjusted segment positions belong to low-risk segments are written into the non-critical content delay queue.
[0102] To enable subsequent S410, S420, and S510 to directly invoke the data, the concurrent transmission weights of the multi-channel video streams in the optimized segment parameter set are synchronously written to the corresponding queue entries when writing to each queue. The segment identifier, fragment identifier, transmission sequence number, concurrent transmission weight, and the edge network node corresponding to the segment are also written to the queue entries. For high-risk segment hold queues, time synchronization data write bits, retransmission indication data write bits, and differential correction data write bits are reserved, allowing subsequent S420 to directly write the control data required for hold transmission without modifying the queue structure. For low-risk segment critical content queues, the transmission start time corresponding to the critical content pre-transmission window is retained for subsequent S410 to directly execute pre-concurrent distribution.
[0103] The final segmented transmission queue includes at least a queue identifier, stream identifier, segment identifier, fragment identifier, transmission sequence number, concurrent transmission weight, and edge network node identifier. The low-risk segment critical content queue is used by S410, the high-risk segment maintenance queue is used by S420, and the entire segmented transmission queue is used by S510 for real-time correction. The segmented transmission queue is then output.
[0104] S4 specifically includes the following sub-steps:
[0105] S410 reads the link fate map and segmented transmission queue, and initiates pre-concurrent distribution processing when the segment corresponding to the drone's current playback timestamp is identified as a low-risk segment.
[0106] Specifically, the key content data of the current low-risk segment is first read from the key content queue of the low-risk segment in the segmented transmission queue. Then, according to the subsequent high-risk segments adjacent to the current low-risk segment in the link fate graph and their key content pre-transmission windows, the key content data belonging to the subsequent high-risk segments and whose segment start time falls within the coverage of the corresponding key content pre-transmission window is extracted. The key content data of the current low-risk segment and the key content data required by the subsequent high-risk segments are combined to form the pre-transmission set.
[0107] Subsequently, merging is performed according to the stream identifier in the pre-send set, and concurrent distribution is performed to multiple terminals based on the sending sequence number and concurrent sending weight of each queue item in the segmented sending queue. When multiple key content data segments compete for sending resources at the same sending time, the key content data with higher task priority and whose segment start time is closer to the start time of the subsequent high-risk segment is sent first, so as to ensure that the key content data that is called first in the subsequent high-risk segment is sent first.
[0108] Upon completion of the pre-transmission of each key content data segment, a recovery index is generated. The recovery index uses the stream identifier, segment identifier, and fragment identifier as unique primary keys, and records at least the frame sequence range, target terminal identifier, transmission status bits, and differential backfill entry. The transmission status bits distinguish between segments that have been successfully transmitted and those awaiting retransmission, while the differential backfill entry directly locates the segment position requiring correction during subsequent weak network recovery. To determine whether the pre-transmission of the current low-risk segment meets the entry conditions for subsequent high-risk segments, the pre-distribution completion rate is calculated for the pre-transmission set using the following formula:
[0109] ;
[0110] in, Indicates the completion rate of the pre-distribution process; This indicates the number of key content data segments that have been successfully pre-sent; This indicates the total number of key content data fragments to be sent before the plan is executed.
[0111] If the pre-distribution completion rate is greater than or equal to the preset completion threshold, the current low-risk segment is recorded as the pre-distribution completed segment; if the pre-distribution completion rate is less than the preset completion threshold, the key content data segments that have not yet been successfully sent are written into the list to be resent, and the sending status bit of the corresponding recovery index is marked as to be resent.
[0112] Finally, the stream identifier, segment identifier, fragment identifier, transmission sequence number, target terminal identifier, transmission status bit, and pre-distribution completion degree are written into the pre-distribution record, and the recovery index set is output synchronously for S420, S430, S510, and S530 to call.
[0113] S420: When the drone's current playback timestamp enters a high-risk segment marked on the link fate graph, read the high-risk segment hold queue and recovery index set from the segment transmission queue, perform high-risk segment hold transmission, and generate a high-risk hold record.
[0114] Specifically, when the current segment identifier matches the high-risk segment identifier in the link fate map, and the current segment identifier has a corresponding queue entry in the high-risk segment hold queue, high-risk segment hold transmission is triggered. After triggering, data transmission in the non-critical content delay queue is suspended, and only the critical content data transmission bit, time synchronization data write bit, retransmission indication data write bit, and differential correction data write bit in the high-risk segment hold queue are kept in an active state.
[0115] Time synchronization data includes at least stream identifier, segment identifier, fragment identifier, target playback timestamp, and local transmission timestamp, used to ensure that multiple terminals maintain a unified playback timeline within high-risk segments; retransmission indication data is generated based on the reception confirmation results returned by the terminal. When a critical content data fragment does not arrive completely on the terminal side, the corresponding fragment is located according to the unique index key in the recovery index set, and retransmission indication data is generated; differential correction data is used to perform local correction on critical content data that has been pre-transmitted but requires local correction. When the terminal has received the corresponding fragment but there are missing frames or timing offsets, the corresponding fragment is also located according to the unique index key in the recovery index set, and differential correction data is generated.
[0116] For critical content data located in high-risk sections, priority is given to maintaining the transmission of time synchronization data and differential correction data. Then, retransmission indication data is sent based on the reception confirmation results returned by the terminal, in order to avoid repeatedly sending complete segments in high-risk sections and thus occupying the transmission resources.
[0117] In a preferred embodiment, when a high-risk segment lasts for 2 seconds and the terminal returns that one of the key content data segments has not arrived completely, only retransmission indication data is generated for that segment, and retransmission is not repeatedly initiated for other segments in the same segment that have arrived completely.
[0118] Before the high-risk segment ends, continuously record the time synchronization status, retransmission trigger status, differential correction status and terminal reception confirmation status corresponding to each segment, and write the above content into the high-risk retention record for S430, S510 and S530 to call.
[0119] S430. After the drone exits the high-risk segment at the current playback timestamp, read the previous distribution record, the recovery index set, and the high-risk retention record, perform a unified verification on the previous concurrent distribution result and the high-risk segment retention transmission result, and generate a segment transmission result table.
[0120] Specifically, firstly, based on the flow identifier, segment identifier, and fragment identifier, a one-to-one correspondence verification is performed between the fragment items in the pre-distribution record and the fragment items in the recovery index set. Then, based on the pre-distribution completion status in the pre-distribution record, it is determined whether the pre-transmission of the current segment has reached the verification baseline. Next, based on the same unique index primary key, a consistency verification is performed between the actual transmitted fragments in the high-risk maintenance record and the target fragments in the recovery index set. Finally, based on the reception confirmation result returned by the terminal, it is determined whether each fragment belongs to a completed transmission fragment, a fragment to be retransmitted, or a fragment that needs to be retransmitted.
[0121] Among them, "completely sent segments" refer to segments that have completed pre-sending or maintained transmission in high-risk segments, and whose content is confirmed to be complete and whose playback timeline is not offset by the terminal; "segments to be resent" refer to segments that have not yet been sent but can be directly located for resentment through the recovery index set; and "segments requiring retransmission" refer to segments that have been sent but whose content is confirmed to be incomplete or misaligned by the terminal and need to be sent again. To evaluate the overall delivery status of the current segment, the segment delivery rate is calculated for this segment using the following formula:
[0122] ;
[0123] in, Indicates the segment delivery rate; This indicates the number of segments within this section that have been confirmed to have been fully delivered; This indicates the total number of segments planned to be sent within this segment.
[0124] If the segment delivery rate is greater than or equal to the preset delivery threshold, and the playback timestamp deviation, number of missing key content segments, and number of continuous playback interruptions returned by the terminal do not exceed the corresponding preset upper limit, then the terminal playback continuity status of the current segment is marked as continuous; otherwise, the terminal playback continuity status is marked as pending recovery, and the corresponding segments are written into the pending retransmission segment item or the segment item that needs to be retransmitted.
[0125] Finally, the segment identifier, completed segments, segments to be retransmitted, segments to be retransmitted, segment delivery rate, and terminal playback continuity status are written into the segment transmission result table, which is called by S510 to perform real-time correction, and by S530 to perform fixed-point retransmission, differential backfilling, and weak network recovery.
[0126] S5 specifically includes the following sub-steps:
[0127] S510: When the drone enters a subsequent segment at the current playback timestamp, it reads the video stream set, link fate graph, segmented transmission queue, recovery index set, high-risk hold records, and segment transmission result table, and collects the link feedback data of the current segment from the edge network in real time to generate a queue correction request.
[0128] Specifically, the segment identifier corresponding to the current playback timestamp is used as the current segment identifier. When the current segment identifier matches the identifier of the next segment to be sent in the segmented transmission queue, but is different from the segment identifier corresponding to the previous sampling period, it is determined that the drone has entered the subsequent segment, and the current round of queue correction processing is triggered. The link feedback data includes at least the current bandwidth usage, current round-trip time, current packet loss rate, current jitter value, current edge network node load, and terminal reception confirmation result.
[0129] To prevent abnormal feedback from directly entering the correction process, the link feedback data is first checked for field integrity. If any field is missing, the same field data from the previous sampling period of the current segment is retrieved and supplemented. If the field is still missing after supplementation, it is not included in the current round of deviation calculation. Subsequently, the verified link feedback data is compared item by item with the segment reference bandwidth occupancy, segment reference round-trip time, segment reference packet loss rate, segment reference jitter value, and segment reference edge network node load corresponding to the current segment in the link fate graph to calculate the queue correction deviation value. The calculation formula is as follows:
[0130] ;
[0131] In the formula, This indicates the queue correction deviation value; This represents the difference between the current bandwidth usage and the segment's reference bandwidth usage. This represents the difference between the current round-trip delay and the reference round-trip delay for the segment; This represents the difference between the current packet loss rate and the reference packet loss rate for the segment. This represents the difference between the current jitter value and the reference jitter value for the segment. This represents the difference between the current edge network node load and the segment reference edge network node load; This represents the correction weight for the corresponding deviation term, and .
[0132] In a preferred embodiment, it can be They were set to 0.20, 0.20, 0.25, 0.15, and 0.20 respectively.
[0133] After calculating the queue correction deviation value, the categories of content to be adjusted and suggested adjustment actions are determined by combining the segments to be retransmitted, segments to be retransmitted, and terminal playback continuity status in the segment transmission result table; when the queue correction deviation value exceeds the preset correction threshold, or the terminal playback continuity status is to be restored, a queue correction request is generated.
[0134] The queue correction request includes at least the segment identifier, deviation item identifier, deviation direction, category of content to be adjusted, range of segments to be adjusted, and suggested adjustment actions. The suggested adjustment actions include at least the following: advancing critical content, inserting segments to be retransmitted earlier, prioritizing the insertion of segments requiring retransmission, continuing to postpone non-critical content, and redistributing load across edge network nodes. The queue correction request is output for S520 to use.
[0135] S520: Read the queue correction request and the segmented transmission queue, perform real-time correction on the segmented transmission queue, and generate the corrected segmented transmission queue.
[0136] Specifically, the primary cause of this round of correction is first determined based on the deviation item identifier in the queue correction request. When the primary cause of this round of correction is packet loss rate deviation or round-trip delay deviation, priority is given to advancing key content and inserting segments to be retransmitted in advance. When the primary cause of this round of correction corresponds to edge network node load deviation, priority is given to redistributing edge network node load and updating the terminal concurrent transmission order. When the current segment has been marked as a high-risk segment in the link fate graph and the terminal playback continuity status in the segment transmission result table is pending recovery, priority is given to inserting segments that need to be retransmitted.
[0137] When handling the insertion of retransmission segments and segments that need to be retransmitted, an arbitrary insertion method is not adopted. Instead, the segments are written into the queue position corresponding to the current segment in the following order: segment identifier first, segment start and end time second, and sending sequence number third. If the insertion will occupy the established sending window of the current critical content data, the position and concurrent sending weight of the critical content data remain unchanged, and only the non-critical content data is postponed.
[0138] For edge network node load redistribution, the corresponding queue item will be migrated to the candidate edge network node only if there is a reachable mapping relationship between the candidate edge network node and the current segment identifier, and the current node load of the candidate edge network node is lower than the preset load limit. If the above conditions are not met, only the terminal concurrent transmission order will be updated, and node migration will not be performed.
[0139] For the enhanced processing of critical content forwarding, the range of critical content data that needs to be prioritized is re-determined based on the recovery index set and the segment sending result table, and its sending sequence number is moved forward to before the segments to be resent and non-critical content data.
[0140] After the correction is completed, the adjusted transmission sequence number, adjusted concurrent transmission weight, adjusted edge network node identifier, and adjustment action flag are rewritten into each queue item in the segmented transmission queue to form the corrected segmented transmission queue.
[0141] The corrected segmented transmission queue includes at least the queue identifier, stream identifier, segment identifier, fragment identifier, adjusted transmission sequence number, adjusted concurrent transmission weight, adjusted edge network node identifier, and adjustment action flag. The corrected segmented transmission queue is output for use by the S530.
[0142] S530: Read the corrected segmented transmission queue, recovery index set, high-risk retention record and segmented transmission result table, perform multi-terminal concurrent distribution and weak network recovery, and generate concurrent distribution completion record and weak network recovery result record.
[0143] Specifically, firstly, based on the time synchronization status and differential correction status in the high-risk record, differential backfilling is performed on key content data that has been pre-sent but still requires local correction, according to the differential backfill entry in the recovery index set; then, based on the retransmission fragment items in the segment transmission result table and the unique index primary key in the recovery index set, the retransmission fragments are resent at specific points; finally, based on the resent fragment items in the segment transmission result table and the adjusted transmission sequence number in the corrected segment transmission queue, the resent fragments are resent in a delayed manner.
[0144] The reason for adopting the above order is that differential backfilling directly corresponds to the key content data that the terminal is currently playing, and should be given priority; fixed-point resending corresponds to segments that have been sent but whose content is incomplete, and should be processed with the second priority; delayed sending corresponds to segments that have not been sent but have little impact on the continuity of the current playback, and can be performed after the first two types of processing are completed.
[0145] After completing one round of differential backfilling, fixed-point retransmission, and delayed transmission, based on the reception confirmation result returned by the terminal and the terminal playback continuity status in the segment transmission result table, it is determined whether the current segment has met the conditions for weak network recovery completion. To make this determination executable, the weak network recovery completion rate for the current segment is calculated using the following formula:
[0146] ;
[0147] In the formula, Indicates the completion rate of weak network recovery; This indicates the number of segments that have been successfully recovered after differential backfilling, fixed-point retransmission, and delayed transmission. This indicates the total number of segments marked as pending retransmission and needing retransmission in the segment transmission result table.
[0148] If the weak network recovery completion rate is greater than or equal to the preset recovery threshold, and the number of segments to be retransmitted and the number of segments to be retransmitted corresponding to the current segment are 0, and the terminal playback continuity status changes from pending recovery to continuous, then the current segment is determined to have completed weak network recovery, and the segment is written into the recovery completed segment in the weak network recovery result record; if the above conditions are not met, the recovery index of the incomplete recovery is retained, and the current segment is written into the recovery incomplete segment in the weak network recovery result record for subsequent segments to continue to call.
[0149] Simultaneously, the segment transmission status, adjustment action execution status, and transmission completion confirmation results completed by each terminal within the current segment are written into the concurrent distribution completion record. Finally, the concurrent distribution completion record and weak network recovery result record are output as the final outputs of this UAV multi-channel video stream concurrent distribution and weak network optimization processing.
[0150] Example 2: Figure 2 As shown, this embodiment provides a multi-channel video stream concurrent distribution and weak network optimization system for unmanned aerial vehicles (UAVs), including:
[0151] The data reading and video stream set generation module is used to read multiple video streams, flight path data and link status data respectively, and perform field verification, time correction, path splicing and index merging on the multiple video streams, flight path data and link status data to generate a video stream set;
[0152] The link fate graph construction module is used to divide candidate segments according to the video stream set, generate a candidate segment risk table, and call the Bat algorithm to jointly optimize the flight path segment boundaries, the key content pre-sending window, and the concurrent sending weight of multiple video streams to generate the link fate graph.
[0153] The content classification and segmented sending queue generation module is used to perform content classification and segmented arrangement of each video stream based on the video stream set and link fate graph, to obtain key content data and non-key content data, and to generate segmented sending queues.
[0154] The pre-distribution and high-risk hold module is used to perform pre-concurrent distribution of key content data in low-risk segments and generate a recovery index set based on the link fate graph and segmented transmission queues, and to perform hold transmission in high-risk segments and generate a segment transmission result table.
[0155] The real-time correction and weak network recovery module is used to generate a queue correction request based on the video stream set, link fate graph, segmented transmission queue, recovery index set and segmented transmission result table, combined with the link feedback data in the edge network, to obtain the corrected segmented transmission queue, and to complete multi-terminal concurrent distribution and weak network recovery based on the corrected segmented transmission queue.
[0156] In terms of physical deployment architecture, the aforementioned data reading and video stream generation modules serve as distributed data probes, deployed on both the UAV device side and the flight control scheduling side. The link fate graph construction module, content classification and segmented transmission queue generation module, pre-distribution and high-risk retention module, and real-time correction and weak network recovery module, as the main scheduling logic of this system, are preferably centrally deployed on edge computing nodes in the edge network or on the cloud central server. Edge computing nodes interact with the UAV and various playback terminals via control signaling, performing unified network coordination and concurrent scheduling.
[0157] All the above formulas are performed using dimensionless numerical calculations; the relevant formulas are based on empirical models that approximate the real situation, obtained through extensive data collection and software simulation fitting. The preset parameters and thresholds involved in the formulas can be conventionally set and adjusted by those skilled in the art according to the physical constraints of the actual application scenario.
[0158] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0159] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0160] In conclusion, the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions, characterized in that, Includes the following steps: S1. Read multiple video streams, flight path data, and link status data; perform time correction, path splicing, and index merging on the multiple video streams, flight path data, and link status data to generate a video stream set. S2. Divide candidate segments according to the video stream set, and combine the bat algorithm to jointly optimize the boundary of the flight path segment, the pre-sending window of key content and the weight of concurrent sending of multiple video streams to generate a link fate graph. S3. Based on the video stream set and link fate graph, perform content classification and segmentation of each video stream to generate segmented transmission queues; S4. Based on the link fate map and segmented transmission queue, perform pre-concurrent distribution of critical content data and generate a recovery index set in low-risk segments, and perform hold-through transmission and generate a segment transmission result table in high-risk segments. S5. Generate a queue correction request based on the video stream set, link fate graph, segmented transmission queue, recovery index set and segmented transmission result table, obtain the corrected segmented transmission queue, and complete multi-terminal concurrent distribution and weak network recovery based on the corrected segmented transmission queue.
2. The method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions according to claim 1, characterized in that, S1 specifically includes: Multiple video streams, flight path data, and link status data are read from the UAV equipment side, flight control and scheduling side, and edge network respectively. For records with missing stream identifiers, task identifiers, timestamps, or link fields, nearest neighbor interpolation or deletion is performed. The task identifier, timestamp, and stream identifier in multiple video streams are uniformly parsed, and time correction, path attachment, and link status attachment are performed with a unified time base to generate a unified stream registration table and stream path association record; Based on the unified flow registration form and flow path association records, index merging and consistency verification are performed to generate a video stream set containing task identifiers, unified timelines, corresponding flight segment sequences, and corresponding link status sequences.
3. The method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions according to claim 1, characterized in that, S2 specifically includes: Based on the flight segment sequence and corresponding link status sequence in the video stream set, the path interval between adjacent waypoints is used as the initial segment. Candidate segments are divided by combining bandwidth usage, round-trip latency, packet loss rate, jitter value and edge network node switching times, and a candidate segment risk table is generated. The Bat Algorithm is invoked to jointly optimize the boundaries of flight path segments, the pre-send window for key content, and the weights for concurrent transmission of multiple video streams, generating an optimized segment parameter set. Based on the optimized segment parameter set and the candidate segment risk table, the segment determination is re-executed to identify high-risk and low-risk segments.
4. The method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions according to claim 3, characterized in that, Also includes: Generate a link fate graph that includes segment identifiers, segment start and end times, risk levels, corresponding edge network nodes, key content pre-sending windows, and weights for concurrent transmission of multiple video streams.
5. The method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions according to claim 1, characterized in that, S3 specifically includes: Based on the video stream set and link fate graph, and according to task priority, content type and time sensitivity, the video segments in each video stream are classified to obtain key content data and non-key content data, and content classification records are generated. Based on the content classification records and the link fate map, key content data located in high-risk sections are moved forward, and non-key content data that meets the conditions are postponed, generating segmented arrangement records; Based on the segmented arrangement records, link fate map, and optimized segment parameter set, a segmented transmission queue is generated, which includes a low-risk segment critical content queue, a high-risk segment hold queue, and a non-critical content delay queue.
6. The method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions according to claim 1, characterized in that, S4 specifically includes: Based on the link fate graph and segmented transmission queue, extract the key content data of the current low-risk segment and the key content data required for the subsequent high-risk segment in the low-risk segment, perform pre-concurrent distribution, and generate a recovery index set and pre-distribution records; Upon entering a high-risk segment, time synchronization data, retransmission indication data, and differential correction data are sent according to the high-risk segment hold queue and recovery index set in the segmented transmission queue, and a high-risk hold record is generated.
7. The method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions according to claim 6, characterized in that, Also includes: Based on the pre-distribution records, recovery index set, and high-risk retention records, a unified check is performed on the segment transmission results to determine the segments that have been transmitted, the segments to be retransmitted, and the segments that need to be retransmitted, and a segment transmission result table is generated.
8. The method for concurrent distribution of multiple video streams from a UAV and optimization in weak network conditions according to claim 1, characterized in that, S5 specifically includes: Based on the video stream set, link fate graph, segmented transmission queue, recovery index set, and segment transmission result table, and combined with link feedback data in the edge network, a queue correction request is generated. Based on the queue correction request, real-time correction is performed on the key content data, segments to be resent, segments to be retransmitted, and the load of edge network nodes in the segmented transmission queue, and a corrected segmented transmission queue is generated. Based on the corrected segmented transmission queue, recovery index set, high-risk retention record, and segment transmission result table, differential backfilling, fixed-point retransmission, and delayed transmission are performed to complete multi-terminal concurrent distribution and weak network recovery.
9. A UAV multi-channel video stream concurrent distribution and weak network optimization system, employing the UAV multi-channel video stream concurrent distribution and weak network optimization method according to any one of claims 1 to 8, characterized in that, include: The data reading and video stream generation module is used to read multiple video streams, flight path data, and link status data respectively; The link fate graph construction module is used to divide candidate segments based on the video stream set and generate a candidate segment risk table. The content classification and segmented sending queue generation module is used to perform content classification and segmented arrangement of each video stream based on the video stream set and link fate graph; The pre-distribution and high-risk retention module is used to perform pre-concurrent distribution of critical content data in low-risk segments and generate a recovery index set based on the link fate graph and segmented transmission queue; The real-time correction and weak network recovery module is used to analyze the video stream set, link fate graph, segmented transmission queue, recovery index set, and segmented transmission result table.