GoP-level video semantic-aware multi-path real-time video transmission method based on linucb

Abstract

The present application relates to the technical field of computer network transmission control, and particularly relates to a GoP level video semantic perception multi-path real-time video transmission method based on LinUCB, which comprises the following steps: a plurality of sub-streams are established by using a multi-path fast UDP Internet connection protocol at a sending end and a receiving end, and session handshake is completed; a GoP is taken as a scheduling period, a data packet set of an I frame and a P frame is identified, and a context feature vector is constructed; pre-allocation is performed to generate a data volume pre-allocation result; an action space is defined, an upper confidence limit of each action is determined, and a transmission action is selected; the data volume pre-allocation result and the transmission action are combined, and a current data packet set is sent; a punctual arrival rate of an I frame data packet and a corresponding reward value are obtained respectively, and LinUCB model parameters are updated; a continuous failure count and a continuous success count of the I frame are monitored, and a protection and a global soft restart mechanism are set; after current GoP transmission, steps S2-S7 are repeated until original video stream transmission is completed.

Description

Technical Field

[0001] This invention relates to the field of computer network transmission control technology, specifically to a multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness. Background Technology

[0002] With the rapid development of mobile communication and wireless network technologies, real-time video services are becoming increasingly popular in scenarios such as mobile terminals, vehicle networks, drone inspections, and remote interaction. Real-time video transmission not only requires high throughput but also has stringent requirements for end-to-end latency, packet loss recovery, playback continuity, and keyframe reliability. In mobile wireless environments, terminals typically connect simultaneously to heterogeneous networks such as WiFi (Wireless Fidelity) and LTE (Long Term Evolution), with significant differences in bandwidth, latency, packet loss rate, and stability across these links, which change rapidly with user movement and wireless channel fluctuations. Achieving stable and efficient video transmission in dynamic multipath environments is challenging.

[0003] The Quick UDP Internet Connections (QUIC) protocol offers advantages such as low-latency connection establishment, stream-level control, and connection migration, making it well-suited for changes in mobile network addresses. In contrast, the Multipath Quick UDP Internet Connections (MPQUIC) protocol extends the multipath capabilities of QUIC, allowing terminals to utilize multiple paths simultaneously, improving bandwidth aggregation and transmission reliability. However, multipath transmission introduces new scheduling challenges. Due to the heterogeneous performance of each path, data packets from the same video stream may be severely out of order at the receiving end, leading to increased buffering, head-of-line congestion, and delivery later than the playback deadline, directly impacting user experience.

[0004] Among existing multipath scheduling methods, traditional rule-based scheduling methods mainly make decisions based on transport layer metrics, lacking awareness of video frame structure and importance differences. Lightweight online learning scheduling methods can dynamically adjust strategies, but their actions and rewards are mostly designed around throughput or average latency, without explicitly modeling the criticality of video I-frames and GoP (Group of Pictures) level playback constraints. I-frames typically play a role in independent decoding and as a reference basis; if an I-frame fails to arrive before the playback deadline, the playback continuity of the current GoP will be significantly affected. Deep reinforcement learning methods have strong expressive power, but they have high training and deployment costs, insufficient real-time performance and interpretability, limiting their application on mobile terminals. Summary of the Invention

[0005] To address the technical problems of existing methods, such as frame semantic blind spots, reward target mismatch, and insufficient adaptation to motion mutations, the present invention aims to provide a GoP-level video semantic awareness multipath real-time video transmission method based on LinUCB. The specific technical solution adopted is as follows:

[0006] Step S1: Establish multiple sub-streams at the sending and receiving ends using the Multipath Fast UDP Internet Connection Protocol and complete the session handshake;

[0007] Step S2: Obtain the original video stream, use GoP as the scheduling period, identify the data packet sets of I-frames and P-frames in the current GoP, and construct a context feature vector based on the round-trip delay, window transmission rate, packet loss rate and congestion window of each sub-stream at any transmission time obtained from the sender.

[0008] Step S3: Obtain the number of bytes in transit for each sub-stream at the current transmission time, and pre-allocate the set of data packets to be sent by combining the round-trip delay, window transmission rate and congestion window, determine the length of the continuous data segment carried by each sub-stream, and generate the data volume pre-allocation result;

[0009] Step S4: Define the action space based on I-frames and P-frames, determine the upper confidence bound of each action based on the context feature vector, and select the transmission action of the current GOP.

[0010] Step S5: Combine the data volume pre-allocation results and transmission actions, and send the current data packet set using a sub-stream;

[0011] Step S6: Obtain the on-time delivery rate of the I-frame data packet through the receiving end and send it to the sending end. Obtain the corresponding reward value based on whether the on-time delivery rate reaches the preset threshold, and use the reward value to update the LinUCB model parameters corresponding to the transmission action.

[0012] Step S7: Preset the first threshold and the second threshold respectively, and monitor the consecutive failure count and consecutive success count of I-frames. When the consecutive failure count is greater than or equal to the first threshold, enter the protection mode; when the consecutive success count is greater than or equal to the second threshold, trigger a global soft reboot.

[0013] Step S8: After each GoP is completed and the model parameters are updated, move on to the next GoP and repeat steps S2 to S7 until the original video stream transmission is finished.

[0014] Preferably, step S1 includes:

[0015] Step S11: The sending end calls the MPQUIC handshake module to send a probe message to the receiving end through the UDP port. The message contains the Fast UDP Internet Connection Protocol version supported by the client, the new connection ID, and the encryption key parameters.

[0016] Step S12: The receiving end receives the probe message, and returns a response after successful verification. The sending end and the receiving end establish an MPQUIC session.

[0017] Step S13: After the session is established, the sending end and the receiving end poll for available local network card addresses respectively. The sending end announces multiple local addresses to the receiving end by exchanging the ADDADDRESS frame of the MPQUIC protocol. After receiving it, the receiving end initiates a new path connection and establishes multiple available sub-streams between the sending end and the receiving end.

[0018] Preferably, step S2 includes:

[0019] Step S21: Obtain the original video stream, divide it into consecutive GoPs according to the encoding structure, use GoPs as the scheduling period, identify the I frames and P frames in it, and integrate them to establish a data packet set;

[0020] Step S22: At any transmission moment of the current video image group, collect the round-trip delay, window transmission rate, packet loss rate and congestion window of each sub-stream, and integrate them to form a context feature vector.

[0021] Preferably, step S3 includes:

[0022] Step S31: Collect the number of bytes in transit for each sub-stream at the current transmission time, sort each sub-stream according to the round-trip delay, and determine the upper limit of the amount of data that should be reserved for each sub-stream based on the sorted sub-streams, combined with the number of bytes in transit, window transmission rate and congestion window.

[0023] Step S32: Preset the total number of bytes of the data packets to be allocated, allocate them sequentially to the sorted sub-streams, and allocate all remaining sendable data to the last sorted sub-stream, determine the length of the continuous data segment carried by each sub-stream, and generate the data volume pre-allocation result.

[0024] Preferably, in step S31, the upper limit of the data volume to be reserved for each sub-stream is determined, and the corresponding calculation formula is:

[0025]

[0026] in, Indicates the first The maximum amount of data that should be reserved for a strip stream; This indicates the operation of finding the maximum value. , They represent the first Strip flow and adjacent sorting after the first The window transmission rate of the strip stream; , They represent the first Strip flow and adjacent sorting after the first One-way delay of the stripe stream; Indicates the first Round-trip delay of the strip stream; , They represent the first Strip flow and adjacent sorting after the first The number of bytes in transit in the data stream.

[0027] Preferably, step S4 includes:

[0028] Step S41: Define the action space by combining two dimensions: whether forward error correction is enabled in I-frames and whether packet loss retransmission is enabled in P-frames. Each action corresponds to a set of action vectors. , Indicates the forward error correction selection for I-frames; Indicates the retransmission option for lost P-frames;

[0029] Step S42: Define a matrix and vector for each action, initialize the LinUCB model parameters, determine the ridge regression parameter estimates, and combine the maintained matrix and context feature vectors to obtain the upper confidence bound of the corresponding action.

[0030] Step S43: Traverse the upper confidence bound of each action and select the action with the largest upper confidence bound as the current GoP's transmission action.

[0031] Preferably, step S5 specifically includes:

[0032] Arrange the current data packet set in I-frame priority, followed by P-frame, and prepare data segments of corresponding lengths for each sub-stream based on the data volume pre-allocation result. If transmission is in progress... Forward error correction coding is performed on all data packets belonging to I-frames in the current data packet set to generate redundant data packets, which are then sent together with the I-frame data packets; if the transmission operation is in progress... It directly sends all data packets belonging to the I-frame in the current data packet set; if the transmission action is in progress... In the current data packet set, packets belonging to P-frames follow the standard MPQUIC retransmission mechanism. The sender retains a buffer for P-frame packets. If no ACK is received from the receiver before the timeout retransmission timer expires, a retransmission is triggered. If the transmission is in progress... The P-frame data packet is marked as unreliable transmission. The sender does not maintain a retransmission buffer for unreliable P-frame data packets, and the receiver discards them directly without triggering a retransmission request.

[0033] Preferably, step S6 includes:

[0034] Step S61: Preset the I-frame reliability threshold and deadline. Count the number of I-frame data packets and P-frame data packets in the current data packet set. Combine the end-to-end delay, number, and deadline of the I-frame data packets to obtain the on-time delivery rate of the I-frame data packets and send it to the sending end.

[0035] Step S62: Combine the sending status of P-frame data packets and obtain the corresponding reward value based on whether the on-time delivery rate reaches the I-frame reliability threshold;

[0036] Step S63: Based on the reward value and combined with the context feature vector, update the LinUCB model parameters corresponding to the transmission action.

[0037] Preferably, step S7 includes...

[0038] Step S71: Determine the maintenance selection count of each action in the action space based on the current data packet set, define the cold start flag, and update the LinUCB model parameters normally when in the cold start phase, but do not trigger the protection mode and soft restart;

[0039] Step S72: Based on the current GoP monitoring of the consecutive failure count and consecutive success count of I-frames, after the cold start phase ends, if the consecutive failure count is greater than or equal to the first threshold, enter the protection mode until the consecutive failure count is greater than or equal to the minimum number of successful I-frame transmissions, and then exit the protection mode.

[0040] Step S73: When in protection mode, if the consecutive success count is greater than or equal to the second threshold, trigger a global soft restart, perform a soft reset of the LinUCB model parameters for each action in the action space, until exiting protection mode.

[0041] To address the aforementioned technical problems, this invention also provides: a multi-path real-time video transmission system based on the Multipath Fast UDP Internet Connection Protocol (MWCP). The system includes a transmitter and a receiver. The transmitter is sequentially configured with a video frame parsing module, a path status acquisition module, a data pre-allocation module, a LinUCB decision module, a forward error correction module, a packet loss retransmission control module, and a multi-path scheduling and transmission module. The receiver is sequentially configured with a data reception and reassembly module, a timeliness statistics module, and a feedback module, to execute the aforementioned LinUCB-based GoP-level video semantic awareness multi-path real-time video transmission method.

[0042] The present invention has the following beneficial effects:

[0043] 1. First, multiple sub-streams are established for both the sending and receiving ends. Using video GoP as the basic scheduling cycle, video frame semantics are introduced into the MPQUIC multipath scheduling process, enabling the differentiation between the importance of I-frames and P-frames and avoiding the traditional scheduling method's equal treatment of all data packets. Next, the set of data packets to be sent is pre-allocated, i.e., pre-allocation based on out-of-order awareness, which alleviates out-of-order arrival and head-of-line congestion problems caused by concurrent transmission along heterogeneous paths. Then, action spaces are defined for I-frames and P-frames, and differentiated actions are adopted. A corresponding reward value is obtained based on whether the on-time delivery rate reaches a preset threshold. When the on-time delivery rate of I-frames is insufficient, the transmission reward for P-frames is reduced, allowing the learning model to prioritize actions that benefit the reliable transmission of critical I-frames. This ensures reliable transmission of critical I-frames when network resources are limited, reducing video interruption rates. Finally, a protection mode and a global soft restart mechanism are designed to increase exploration and accelerate the forgetting of expired experiences when mobile network path quality changes abruptly, improving performance in dynamic network environments. It takes into account path status, video frame semantics, out-of-order control, and dynamic network environment adaptability to achieve lightweight and efficient multi-path video transmission optimization, which is suitable for high-quality video live streaming, remote monitoring, vehicle video and other real-time services in mobile heterogeneous network environments.

[0044] 2. The multi-path real-time video transmission system based on the multi-path fast UDP Internet connection protocol provided by this invention has the same beneficial effects as the multi-path real-time video transmission method based on LinUCB GoP-level video semantic awareness provided by this invention, and will not be elaborated here. Attached Figure Description

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

[0046] Figure 1 This is a flowchart illustrating the implementation of a GoP-level video semantic awareness multipath real-time video transmission method based on LinUCB, as provided in one embodiment of the present invention.

[0047] Figure 2 The logical structure diagram of a multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness provided in an embodiment of the present invention is shown below.

[0048] Figure 3A comparison chart of the effective aggregated throughput of real-time video stream transmission between the GoP-level video semantic awareness multipath real-time video transmission method based on LinUCB provided in an embodiment of the present invention and existing multipath transmission schemes.

[0049] Figure 4 A comparison of the end-to-end latency CDF curves of video data packets between the GoP-level video semantic awareness multipath real-time video transmission method based on LinUCB provided in an embodiment of the present invention and existing multipath transmission schemes.

[0050] Figure 5 This is a comparison chart of the real-time video stream transmission interruption rate between the GoP-level video semantic awareness multipath real-time video transmission method based on LinUCB provided in an embodiment of the present invention and existing multipath transmission schemes. Detailed Implementation

[0051] To further illustrate the technical means and effects adopted by the present invention to achieve its intended purpose, the following, in conjunction with the accompanying drawings and preferred embodiments, details the specific implementation, structure, features, and effects of a multi-path real-time video transmission method based on LinUCB and GoP-level video semantic awareness proposed according to the present invention. In the following description, different "one embodiment" or "another embodiment" do not necessarily refer to the same embodiment. Furthermore, specific features, structures, or characteristics in one or more embodiments can be combined in any suitable form.

[0052] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0053] The following description, in conjunction with the accompanying drawings, details a specific scheme for a multi-path real-time video transmission method based on LinUCB and GoP-level video semantic awareness provided by this invention.

[0054] To better illustrate, the MPQUIC protocol, or Multipath Fast UDP Internet Connection Protocol, extends the multipath capabilities of the QUIC protocol. Specifically, it's an IETF multipath extension of standard QUIC, allowing multiple network paths to transmit data in parallel over the same QUIC logical connection, achieving bandwidth aggregation, improved transmission reliability, and seamless link switching. It includes an MPQUIC handshake module for establishing connections and verifying the legitimacy of subpaths, activating multiple paths; a path management module for maintaining the lifecycle and state of multiple paths; an MPQUIC scheduling module for allocating packets to appropriate paths for transmission, achieving bandwidth aggregation and link fault tolerance; and a congestion control module for independently managing the transmission rate of each path to avoid network congestion.

[0055] Please combine Figure 1 and Figure 2 The first embodiment of the present invention provides a multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness, the method comprising:

[0056] Step S1: Establish multiple sub-streams at the sending and receiving ends using the Multipath Fast UDP Internet Connection Protocol and complete the session handshake;

[0057] Step S2: Obtain the original video stream, use GoP as the scheduling period, identify the data packet sets of I-frames and P-frames in the current GoP, and construct a context feature vector based on the round-trip delay, window transmission rate, packet loss rate and congestion window of each sub-stream at any transmission time obtained from the sender.

[0058] Step S3: Obtain the number of bytes in transit for each sub-stream at the current transmission time, and pre-allocate the set of data packets to be sent by combining the round-trip delay, window transmission rate and congestion window, determine the length of the continuous data segment carried by each sub-stream, and generate the data volume pre-allocation result;

[0059] Step S4: Define the action space based on I-frames and P-frames, determine the upper confidence bound of each action based on the context feature vector, and select the transmission action of the current GOP.

[0060] Step S5: Combine the data volume pre-allocation results and transmission actions, and send the current data packet set using a sub-stream;

[0061] Step S6: Obtain the on-time delivery rate of the I-frame data packet through the receiving end and send it to the sending end. Obtain the corresponding reward value based on whether the on-time delivery rate reaches the preset threshold, and use the reward value to update the LinUCB model parameters corresponding to the transmission action.

[0062] Step S7: Preset the first threshold and the second threshold respectively, and monitor the consecutive failure count and consecutive success count of I-frames. When the consecutive failure count is greater than or equal to the first threshold, enter the protection mode; when the consecutive success count is greater than or equal to the second threshold, trigger a global soft reboot.

[0063] Step S8: After each GoP is completed and the model parameters are updated, move on to the next GoP and repeat steps S2 to S7 until the original video stream transmission is finished.

[0064] To clarify, LinUCB, or Linear Upper Confidence Bound, is typically used to receive real-time contextual features, calculate reward values ​​for candidate actions, add confidence exploration terms, select the optimal action, and incrementally update model parameters after observing the actual reward, balancing the exploration of unknown options with the utilization of existing experience; GoP, or Group of Pictures, is used as the basic scheduling cycle, which can significantly reduce the original video bitstream size.

[0065] Further, step S1 includes:

[0066] Step S11: The sending end calls the MPQUIC handshake module to send a probe message to the receiving end through the UDP port. The message contains the Fast UDP Internet Connection Protocol version supported by the client, the new connection ID, and the encryption key parameters.

[0067] Step S12: The receiving end receives the probe message, and returns a response after successful verification. The sending end and the receiving end establish an MPQUIC session.

[0068] Step S13: After the session is established, the sending end and the receiving end poll for available local network card addresses respectively. The sending end announces multiple local addresses to the receiving end by exchanging the ADDADDRESS frame of the MPQUIC protocol. After receiving it, the receiving end initiates a new path connection and establishes multiple available sub-streams between the sending end and the receiving end.

[0069] Specifically, the sending end establishes a handshake mechanism based on the existing connection in the underlying MPQUIC protocol stack. It sends a probe message carrying the protocol version, new connection ID, and encryption key parameters to the receiving end through a UDP port to initiate the MPQUIC session establishment process between the two ends. The protocol version is used to determine the compatibility of the protocols of both parties; the connection ID is used to identify and associate this MPQUIC session, and the receiving end creates or matches the corresponding connection context based on the connection ID; the encryption key parameters are used to complete the security verification during the handshake phase.

[0070] Next, after receiving the probe message, the receiving end parses and verifies the legality of the parameters. The verification process fully follows the standard QUIC connection establishment specification, which is executed by the MPQUIC protocol stack according to the QUIC connection establishment process, including protocol version compatibility verification, connection identifier validity check, and handshake key and authentication parameter verification. If any verification fails, the session is refused to be established. If the verification passes, the corresponding connection context is established and a handshake response is returned. At this point, the sending and receiving ends have successfully established an MPQUIC session.

[0071] Then, after the session is established, the path management modules of the sending and receiving ends poll for available local network interface card addresses. In this embodiment, the sending device simultaneously enables both the WiFi interface and the LTE cellular interface. The path management module announces multiple available IP addresses to the receiving end by exchanging ADDADDRESS frames defined by the MPQUIC protocol. After receiving the ADDADDRESS frames, the receiving end initiates a new path connection request based on the announced addresses. The sending end responds to the receiving end's path connection requests one by one, establishing sub-streams one by one between the end-to-end address pairs. , Indicates the sub-stream index; This represents the total number of substreams.

[0072] Finally, the sending end creates a logical data stream to carry video data based on the established MPQUIC session and obtains the corresponding data stream read / write interface for subsequent video data parsing, scheduling, and sending.

[0073] It should be further noted that, in this embodiment, These correspond to the sub-streams established by the wireless terminal through the WiFi and LTE network interfaces, respectively. That is, path 1 corresponds to the WiFi link and path 2 corresponds to the LTE link.

[0074] Further, step S2 includes:

[0075] Step S21: Obtain the original video stream, divide it into consecutive GoPs according to the encoding structure, use GoPs as the scheduling period, identify the I frames and P frames in it, and integrate them to establish a data packet set.

[0076] To clarify, an I-frame refers to a keyframe, which is fully intra-frame coded and does not reference any other frames. It contains complete image information on its own and can be decoded independently without relying on preceding or following frames. It usually consists of only one I-frame at the beginning. A P-frame refers to a prediction frame, which is inter-frame coded and cannot be decoded independently. It must rely on preceding reference frames and usually contains multiple P-frames.

[0077] Specifically, any raw video stream is acquired, and the raw video stream is divided into consecutive GoPs according to the encoding structure. The analysis is carried out with GoP as the scheduling period, and the current GoP is defined as the [number]th [goP]. One GoP, This represents the GoP index; it identifies the I-frames and P-frames within it, denoted as... and , Indicates the first I-frames within a GoP; Indicates the first The first one in the GoP P frames, Indicates the first Each GoP contains a P-frame index; these are integrated to create a video frame set. , Indicates the first The number of P-frames within a GoP. Next, since I-frame data packets are messages carrying I-frame stream fragments, P-frame data packets are messages carrying P-frame stream fragments. Combining I-frame and P-frame data packets yields the set of data packets used for the current analysis.

[0078] As an optional implementation, the raw video stream refers to the encoded bitstream that has been encoded using standards such as H.264, H.265, and H.266 but has not yet undergone fragmentation, encapsulation, or streaming processing. In this embodiment, the raw video stream uses the H.264 encoding standard, with an IPPP encoding structure, meaning each GoP contains one I-frame and three P-frames. The frame rate is set to 30 frames per second, and each GoP lasts for 133 milliseconds.

[0079] Step S22: At any transmission moment of the current video image group, collect the round-trip delay, window transmission rate, packet loss rate and congestion window of each sub-stream, and integrate them to form a context feature vector.

[0080] Specifically, defining the current analysis's first... The transmission time starting from each GoP is The system collects the status parameters of each substream, including round-trip time, window transmission rate, packet loss rate, congestion window, and the number of bytes in transit for subsequent analysis. , Indicates the first Slot stream at transmission time The round-trip delay is calculated by the sending end when it receives the acknowledgment frame, and then obtained after filtering and smoothing. Indicates the first Slot stream at transmission time The window transmission rate is the ratio of the congestion window size to the one-way delay, which is half the round-trip delay. Indicates the first Slot stream at transmission time The packet loss rate is determined by identifying bytes lost on a substream based on acknowledgment frames and timeout retransmission mechanisms. The packet loss rate is the result of dividing the number of lost bytes by the total number of bytes sent in the statistical period of that substream. Indicates the first Slot stream at transmission time The congestion window size, which is the congestion window (cwnd) maintained by the MPQUIC congestion control algorithm, refers to the amount of unacknowledged data that is currently allowed to remain in the network; Indicates the first Slot stream at transmission time The number of bytes in transit is calculated by counting the cumulative sent bytes and acknowledged bytes for each substream. Subtracting the acknowledged bytes from the cumulative sent bytes yields the number of bytes in transit for that substream that have not yet been acknowledged. According to the... Similarly, the state parameters of all sub-flows are determined for the sub-flows.

[0081] All sub-streams, i.e. The round-trip time, window transmission rate, packet loss rate, and congestion window size of each strip are concatenated to form a dimension. The context feature vector, i.e. In this embodiment, To determine the transmission time Context feature vector Dimensions .

[0082] Further, step S3 includes:

[0083] Step S31: Collect the number of bytes in transit for each sub-stream at the current transmission time, sort each sub-stream according to the round-trip delay, and determine the upper limit of the amount of data that should be reserved for each sub-stream based on the sorted sub-streams, combined with the number of bytes in transit, window transmission rate and congestion window.

[0084] Specifically, obtain the number of bytes in transit. It is used for data pre-allocation to reflect the transmission capacity currently occupied by each substream; The data flow is based on the current round-trip delay. Sort by size from smallest to largest, for example, It makes specific sorting based on the actual situation; for each sorted subflow, that is, for the first... For each stream, determine the upper limit of the amount of data that should be reserved, i.e., the maximum threshold of the buffer bytes to be sent that can be stored.

[0085] Further, in step S31, the upper limit of the data volume that should be reserved for each sub-stream is determined, and the corresponding calculation formula is as follows:

[0086]

[0087] in, Indicates the first The maximum amount of data that should be reserved for a strip stream; This indicates the operation of finding the maximum value. , They represent the first Strip flow and adjacent sorting after the first The window transmission rate of the strip stream; , They represent the first Strip flow and adjacent sorting after the first One-way delay of the strip stream; Indicates the first Round-trip delay of the strip stream; , They represent the first Strip flow and adjacent sorting after the first The number of bytes in transit in the data stream.

[0088] Step S32: Preset the total number of bytes of the data packets to be allocated, allocate them sequentially to the sorted sub-streams, and allocate all remaining sendable data to the last sorted sub-stream, determine the length of the continuous data segment carried by each sub-stream, and generate the data volume pre-allocation result.

[0089] Specifically, the total number of bytes of the data packets currently awaiting allocation is denoted as... Based on the aforementioned step S31, the sorted sub-streams are allocated sequentially, for the first sub-stream... Striped stream, allocating data volume , This indicates the minimum value operation; Indicates the first The size of the data window that the current stream can immediately send, i.e. , This indicates that the maximum value operation is performed, and then the updated total number of bytes of the currently unallocated data packet is obtained. Next, sort the last substream. Allocate all remaining sendable data. Determine the length of the continuous data segment carried by each sub-stream, that is, the allocated data amount corresponding to each sub-stream is the length of the continuous data segment, and generate the data amount pre-allocation result. .

[0090] It should be noted that in actual operation, if there is still data remaining after all available windows of all sub-streams have been filled, the data will wait for the next scheduling round to continue to be allocated.

[0091] Further, step S4 includes:

[0092] Step S41: Define the action space by combining two dimensions: whether forward error correction is enabled in I-frames and whether packet loss retransmission is enabled in P-frames. Each action corresponds to a set of action vectors. , Indicates the forward error correction selection for I-frames; This indicates the option to retransmit lost P-frames.

[0093] Provide an explanation, and denote the action space as... Every movement Corresponding to a set of behavior vectors , Indicates the action index; in this embodiment, the action space There are a total of 4 actions: the forward error correction selection for I-frames and the loss retransmission selection for P-frames each have two options, yes and no. Combining these results in a total of 4 actions in the entire action space.

[0094] Step S42: Define a matrix and vector for each action, initialize the LinUCB model parameters, determine the ridge regression parameter estimates, and combine the maintained matrix and context feature vectors to obtain the upper confidence bound of the corresponding action.

[0095] Specifically, each action Maintenance dimensional matrix and A dimensional vector, denoted as and , The dimension of the context feature vector is used to determine the ridge regression parameter estimates, and the corresponding calculation formula is as follows: , Indicates action The ridge regression parameter estimates are obtained; the upper confidence bound for the corresponding action is obtained by combining the maintained matrix and the context feature vector, and the corresponding calculation formula is as follows:

[0096]

[0097] in, Indicates action The upper confidence bound; Indicates transmission time The corresponding context feature vector; Indicates the transpose operation; This indicates the exploration weight.

[0098] It should be noted that, in this embodiment, the initial values ​​of the matrix and vector are... and Explore weights And the forgetting weights in the LinUCB model parameters These are all empirical coefficients, usually , All of these can be adjusted according to the actual situation. Based on the action... Similarly, determine the action space. The upper confidence bound of all actions in the process.

[0099] Step S43: Traverse the upper confidence bounds of each action and select the action with the largest upper confidence bound as the current GoP's transmission action; in this step, the action that maximizes the upper confidence bound is selected as the current GoP's transmission action. The transmission strategy of each GoP, namely .

[0100] Further, in step S5, specifically:

[0101] Arrange the current data packet set in I-frame priority, followed by P-frame, and prepare data segments of corresponding lengths for each sub-stream based on the data volume pre-allocation result. If transmission is in progress... Forward error correction coding is performed on all data packets belonging to I-frames in the current data packet set to generate redundant data packets, which are then sent together with the I-frame data packets; if the transmission operation is in progress... It directly sends all data packets belonging to the I-frame in the current data packet set; if the transmission action is in progress... In the current data packet set, packets belonging to P-frames follow the standard MPQUIC retransmission mechanism. The sender retains a buffer for P-frame packets. If no ACK is received from the receiver before the timeout retransmission timer expires, a retransmission is triggered. If the transmission is in progress... The P-frame data packet is marked as unreliable transmission. The sender does not maintain a retransmission buffer for unreliable P-frame data packets, and the receiver discards them directly without triggering a retransmission request.

[0102] As explained, during this step, the data volume pre-allocation result generated in the aforementioned step S3 is read. For each substream, a data segment of corresponding length is prepared. In this embodiment, the data packet set corresponding to the current GoP is arranged in the order of I-frames first, followed by P-frames, and allocated to each path according to the pre-allocation result, following the allocation rules in this step. During the allocation process, the behavior vector is used as the basis for the allocation. Two components are read and processed synchronously; the forward error correction coding has a coding rate of 30% redundancy.

[0103] Further, step S6 includes:

[0104] Step S61: Preset the I-frame reliability threshold and deadline. Count the number of I-frame data packets and P-frame data packets in the current data packet set. Combine the end-to-end delay, number, and deadline of the I-frame data packets to obtain the on-time delivery rate of the I-frame data packets and send it to the sending end.

[0105] It should be noted that both the I-frame reliability threshold and the deadline are empirical coefficients, denoted as follows: and In this embodiment, , All of these can be adjusted according to the actual situation.

[0106] Specifically, the current number After a GoP transmission is completed, the receiving end calculates the on-time delivery rate of I-frame data packets within that GoP. A single GoP contains a total of Each data packet is counted, and the number of I-frame data packets and P-frame data packets is recorded as follows: and Then the first The on-time delivery rate of I-frame packets within a GoP is , Indicates the first End-to-end latency of an I-frame data packet Indicates the index of an I-frame data packet; Describes the characteristic function, indicating that when the first... The end-to-end delay of each I-frame data packet is less than the deadline. The value is 1 if the condition is met, and 0 otherwise, and is sent to the sender.

[0107] Step S62: Combine the sending status of P-frame data packets and obtain the corresponding reward value based on whether the on-time delivery rate reaches the I-frame reliability threshold.

[0108] Specifically, the formula for calculating the reward value is as follows:

[0109]

[0110] in, Indicates the time of transmission The reward value; Indicates the first End-to-end delay of a P-frame data packet; This represents the attenuation coefficient.

[0111] It can be explained that the attenuation coefficient This is used to guide online learning algorithms to transmit as many P-frame data packets as possible while prioritizing the timely delivery of I-frame data packets. .

[0112] Step S63: Based on the reward value and combined with the context feature vector, update the LinUCB model parameters corresponding to the transmission action.

[0113] Specifically, for ease of explanation, we will directly assume the actions described in the preceding analysis. This refers to the transmission actions obtained through filtering, utilizing the transmission time. Context feature vector and reward value Update transmission action The corresponding LinUCB model parameters, i.e. 3D matrix and dimensional vector The corresponding calculation formula is:

[0114]

[0115]

[0116]

[0117] in, , , Indicates based on transmission action Updated matrix, vector, and ridge regression parameter estimates; Indicates the forgetting weight; This indicates transpose processing.

[0118] Further, in step S7, including

[0119] Step S71: Determine the maintenance selection count of each action in the action space based on the current data packet set, define the cold start flag, and update the LinUCB model parameters normally when in the cold start phase, but do not trigger protection mode and soft restart.

[0120] Specifically, for each action Maintain the number of selections. , Indicates the number of times it has been sent in the past. One GoP; Indicates the number of times it has been sent in the past. Each GoP performs a transmission action; defines the cold start flag. , This represents the minimum number of times each action can be selected. In this embodiment, ;when When the time is set to 0, it indicates that the system is in the cold start phase, during which the LinUCB model parameters are updated normally, but the protection mode and soft restart are not triggered.

[0121] Step S72: Based on the current GoP monitoring of the consecutive failure count and consecutive success count of I-frames, after the cold start phase ends, if the consecutive failure count is greater than or equal to the first threshold, enter the protection mode until the consecutive failure count is greater than or equal to the minimum number of successful I-frame transmissions, and then exit the protection mode.

[0122] Specifically, the corresponding counts of consecutive I-frame failures and consecutive I-frame successes maintained by the sending end are denoted as follows: and After each GoP transmission and feedback is completed, the relevant counts are updated. , After the cold start phase ends, if the consecutive failure count reaches the first threshold, i.e. When the value is greater than or equal to the first threshold, the system enters protection mode. Specifically, in this embodiment, the protection mode operation includes: adjusting the exploration weight to... Adjust the forgetting weight to Protection mode continues until Exit at the appropriate time to explore weights And forgetting weight Restore to initial value, This represents the minimum number of successful I-frame transmissions; that is, by increasing the exploration weight. This makes the algorithm more inclined to try new actions and reduces the weight of forgetting. This allows the algorithm to discard outdated historical experiences more quickly, thus adapting to the mutated network environment more rapidly.

[0123] Step S73: When in protection mode, if the consecutive success count is greater than or equal to the second threshold, trigger a global soft restart, perform a soft reset of the LinUCB model parameters for each action in the action space, until exiting protection mode.

[0124] Specifically, in protection mode, if the count is successful consecutively... When the threshold is greater than or equal to the second threshold, a global soft restart is triggered, and the LinUCB model parameters are soft-reset for each action in the action space. The corresponding calculation formula is as follows:

[0125]

[0126]

[0127]

[0128] in, This represents the historical experience retention coefficient, which is used to control the proportion of the original model experience retained after a soft reboot.

[0129] It can be noted that a soft reboot resets the system. Maintain protection mode until In this embodiment, the historical experience retention coefficient is used for exiting at any time. In other words, a soft reboot does not completely clear the model parameters, but retains 30% of the accumulated information and resets the selection count counter. This can preserve some effective experience and accelerate the adaptation to new network conditions, making it suitable for transmission processes in dynamic network environments.

[0130] It should be noted that both the first and second thresholds are empirical coefficients, denoted as follows: and It makes specific adjustments based on historical counts.

[0131] Finally, run step S8, which is to move to the next GoP after each GoP transmission and model parameter update is completed, and repeat steps S2 to S7 until the original video stream transmission is finished.

[0132] Understandably, firstly, multiple sub-streams are established for both the sending and receiving ends, with video GoP as the basic scheduling cycle. Video frame semantics are introduced into the MPQUIC multipath scheduling process, which can distinguish the importance differences between I-frames and P-frames, avoiding the traditional scheduling method's equivalent processing of all data packets. Secondly, the set of data packets to be sent is pre-allocated, i.e., pre-allocation of out-of-order-aware data, which can alleviate the out-of-order arrival and head-of-line congestion problems caused by concurrent transmission of heterogeneous paths. Next, action spaces are defined for I-frames and P-frames, and differentiated actions are taken. At the same time, corresponding reward values ​​are obtained based on whether the on-time delivery rate reaches a preset threshold. When the on-time delivery rate of I-frames is insufficient, the transmission reward of P-frames is reduced, so that the learning model prioritizes actions that are conducive to the reliable transmission of critical I-frames. When network resources are limited, the reliable transmission of critical I-frames can be guaranteed, and the video interruption rate can be reduced. Finally, a protection mode and a global soft restart mechanism are designed to increase exploration and accelerate the forgetting of expired experience when the quality of mobile network paths changes abruptly, thereby improving performance in dynamic network environments. It takes into account path status, video frame semantics, out-of-order control, and dynamic network environment adaptability to achieve lightweight and efficient multi-path video transmission optimization, which is suitable for high-quality video live streaming, remote monitoring, vehicle video and other real-time services in mobile heterogeneous network environments.

[0133] To better illustrate and verify the reliability of the present invention, it is compared with existing multipath transmission schemes, including Peekaboo, ECF (Earliest Completion First) and MinRTT (Minimum Round Trip Time First), to demonstrate that the present invention can improve effective aggregate throughput and reduce end-to-end latency and video interruption rate.

[0134] Please see Figure 3 Due to fluctuations in WiFi and LTE link quality caused by user movement, the throughput of each algorithm exhibits time-varying characteristics. The average effective aggregate throughput of this invention reaches 1.87 Mbps, representing improvements of 22.22%, 36.50%, and 50.81% compared to Peekaboo, ECF, and MinRTT, respectively. In terms of peak throughput, this invention achieves 3.41 Mbps, representing improvements of 34.25%, 40.91%, and 63.94% compared to the three baselines, respectively. These results demonstrate that this invention, by comprehensively utilizing multi-dimensional path state information such as RTT, window transmission rate, packet loss rate, and congestion window, combined with LinUCB online learning to dynamically select appropriate transmission actions, can more efficiently convert multi-path bandwidth into effective video data throughput.

[0135] Please see Figure 4 The latency distribution curve of this invention is located furthest to the left, with a median latency of 65ms, which is 19.75%, 22.62%, and 31.58% lower than Peekaboo, ECF, and MinRTT, respectively. Regarding tail latency, the P95 latency of this invention is 107ms, which is 46.23%, 62.72%, and 80.51% lower than Peekaboo, ECF, and MinRTT, respectively; the P99 latency is 212ms, which is 22.06%, 53.41%, and 65.64% lower than the other three, respectively. This latency performance improvement stems from three mechanisms: 1. Out-of-order awareness data pre-allocation reduces out-of-order waiting caused by concurrent transmission of heterogeneous paths from the source; 2. I-frame FEC protection reduces the additional latency introduced by key frame retransmission; 3. P-frame unreliable transmission avoids low-priority data continuously occupying the congestion window.

[0136] Please see Figure 5 The interruption rate of this invention is only 5.4%, significantly lower than ECF, MinRTT, and Peekaboo, with relative reductions of 79.22%, 81.65%, and 77.05%, respectively. This result verifies the effectiveness of the I-frame timeliness gating reward function, protection mode, and soft restart mechanism of this invention. Unlike simply optimizing throughput or average latency, this invention uses I-frame timeliness as the core optimization objective for scheduling decisions. When the I-frame timeliness is insufficient, it reduces the P-frame reward guidance algorithm to prioritize the protection of key frames, and in the event of mobile link mutations, it uses protection mode and soft restart to quickly restore the effectiveness of the strategy, thereby significantly reducing the video playback interruption rate.

[0137] The second embodiment of the present invention provides a multi-path real-time video transmission system based on the multi-path fast UDP Internet connection protocol. The system includes a sending end and a receiving end. The sending end is sequentially equipped with a video frame parsing module, a path status acquisition module, a data pre-allocation module, a LinUCB decision module, a forward error correction module, a packet loss retransmission control module, and a multi-path scheduling and sending module. The receiving end is sequentially equipped with a data receiving and reassembly module, a timeliness statistics module, and a feedback module to execute the multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness as described in any embodiment of the present invention.

[0138] It can be explained that, based on the operation of the aforementioned method, at the sending end, the video frame parsing module is used to divide the original video stream into consecutive GoPs; the path state acquisition module is used to obtain the state parameters of each sub-stream; the data pre-allocation module is used to pre-allocate the data packets to be sent according to the relevant state parameters, generating data volume pre-allocation results, which can effectively deal with the problems of out-of-order packets and head-of-line blocking; the LinUCB decision module is used to calculate the upper confidence bound of each action in the action space based on the context feature vector, and select the transmission action of the current GoP, that is, using the LinUCB-based online learning method, which can provide differentiated transmission strategies for I-frames and P-frames, and can effectively guarantee the transmission of key I-frames under network resource constraints; the forward error correction module, i.e., the FEC module, is used to perform forward error correction coding on all data packets belonging to I-frames in the GoP; the packet loss retransmission control module is used to implement packet loss retransmission when allocating action vectors in the action space; and the multi-path scheduling and sending module is used to allocate to each sub-stream according to the pre-allocation results.

[0139] In the receiving end, the data receiving and reassembly module is used to receive data transmitted from the sending end and to start the protection mode and global soft restart mechanism. It can effectively adapt to wireless video stream transmission in dynamic network environments, retain some effective experience, and accelerate the adaptation to new network conditions. The on-time rate statistics module is used to determine the on-time delivery rate of I-frame data packets in GoP. The feedback module is used to respond to the data in the receiving end and transmit it to the sending end.

[0140] When the system is in operation, it needs to utilize a multi-path real-time video transmission method based on LinUCB and GoP-level video semantic awareness. Therefore, whether the system and program data are integrated or different hardware is configured to produce functions with similar effects to those achieved by this invention, they all fall within the protection scope of this invention. This system has the same beneficial effects as the aforementioned multi-path real-time video transmission method based on LinUCB and GoP-level video semantic awareness, and will not be elaborated here.

[0141] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. The processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0142] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

Claims

1. A multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness, characterized in that, The method includes: Step S1: Establish multiple sub-streams at the sending and receiving ends using the Multipath Fast UDP Internet Connection Protocol and complete the session handshake; Step S2: Obtain the original video stream, use GoP as the scheduling period, identify the data packet sets of I-frames and P-frames in the current GoP, and construct a context feature vector based on the round-trip delay, window transmission rate, packet loss rate and congestion window of each sub-stream at any transmission time obtained from the sender. Step S3: Obtain the number of bytes in transit for each sub-stream at the current transmission time, and pre-allocate the set of data packets to be sent by combining the round-trip delay, window transmission rate and congestion window, determine the length of the continuous data segment carried by each sub-stream, and generate the data volume pre-allocation result; Step S4: Define the action space based on I-frames and P-frames, determine the upper confidence bound of each action based on the context feature vector, and select the transmission action of the current GOP. Step S5: Combine the data volume pre-allocation results and transmission actions, and send the current data packet set using a sub-stream; Step S6: Obtain the on-time delivery rate of the I-frame data packet through the receiving end and send it to the sending end. Obtain the corresponding reward value based on whether the on-time delivery rate reaches the preset threshold, and use the reward value to update the LinUCB model parameters corresponding to the transmission action. Step S7: Preset the first threshold and the second threshold respectively, and monitor the consecutive failure count and consecutive success count of I-frames. When the consecutive failure count is greater than or equal to the first threshold, enter the protection mode; when the consecutive success count is greater than or equal to the second threshold, trigger a global soft reboot. Step S8: After each GoP is completed and the model parameters are updated, move on to the next GoP and repeat steps S2 to S7 until the original video stream transmission is finished.

2. The multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness according to claim 1, characterized in that, Step S1 includes: Step S11: The sending end calls the MPQUIC handshake module to send a probe message to the receiving end through the UDP port. The message contains the Fast UDP Internet Connection Protocol version supported by the client, the new connection ID, and the encryption key parameters. Step S12: The receiving end receives the probe message, and returns a response after successful verification. The sending end and the receiving end establish an MPQUIC session. Step S13: After the session is established, the sending end and the receiving end poll for available local network card addresses respectively. The sending end announces multiple local addresses to the receiving end by exchanging the ADDADDRESS frame of the MPQUIC protocol. After receiving it, the receiving end initiates a new path connection and establishes multiple available sub-streams between the sending end and the receiving end.

3. The multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness according to claim 1, characterized in that, Step S2 includes: Step S21: Obtain the original video stream, divide it into consecutive GoPs according to the encoding structure, use GoPs as the scheduling period, identify the I frames and P frames in it, and integrate them to establish a data packet set; Step S22: At any transmission moment of the current video image group, collect the round-trip delay, window transmission rate, packet loss rate and congestion window of each sub-stream, and integrate them to form a context feature vector.

4. The multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness according to claim 1, characterized in that, Step S3 includes: Step S31: Collect the number of bytes in transit for each sub-stream at the current transmission time, sort each sub-stream according to the round-trip delay, and determine the upper limit of the amount of data that should be reserved for each sub-stream based on the sorted sub-streams, combined with the number of bytes in transit, window transmission rate and congestion window. Step S32: Preset the total number of bytes of the data packets to be allocated, allocate them sequentially to the sorted sub-streams, and allocate all remaining sendable data to the last sorted sub-stream, determine the length of the continuous data segment carried by each sub-stream, and generate the data volume pre-allocation result.

5. The multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness according to claim 4, characterized in that, In step S31, the upper limit of the data volume that should be reserved for each sub-stream is determined, and the corresponding calculation formula is as follows: ； in, Indicates the first The maximum amount of data that should be reserved for a strip stream; This indicates the operation of finding the maximum value. , They represent the first Strip flow and adjacent sorting after the first The window transmission rate of the strip stream; , They represent the first Strip flow and adjacent sorting after the first One-way delay of the stripe stream; Indicates the first Round-trip delay of the strip stream; , They represent the first Strip flow and adjacent sorting after the first The number of bytes in transit in the data stream.

6. The multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness according to claim 1, characterized in that, Step S4 includes: Step S41: Define the action space by combining two dimensions: whether forward error correction is enabled in I-frames and whether packet loss retransmission is enabled in P-frames. Each action corresponds to a set of action vectors. , Indicates the forward error correction selection for I-frames; Indicates the retransmission option for lost P-frames; Step S42: Define a matrix and vector for each action, initialize the LinUCB model parameters, determine the ridge regression parameter estimates, and combine the maintained matrix and context feature vectors to obtain the upper confidence bound of the corresponding action. Step S43: Traverse the upper confidence bound of each action and select the action with the largest upper confidence bound as the current GoP's transmission action.

7. The multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness according to claim 6, characterized in that, Step S5 specifically includes: Arrange the current data packet set in I-frame priority, followed by P-frame, and prepare data segments of corresponding lengths for each sub-stream based on the data volume pre-allocation result. If transmission is in progress... Forward error correction coding is performed on all data packets belonging to I-frames in the current data packet set to generate redundant data packets, which are then sent together with the I-frame data packets; if the transmission operation is in progress... It directly sends all data packets belonging to the I-frame in the current data packet set; If the transmission action is in progress In the current data packet set, packets belonging to P-frames follow the standard MPQUIC retransmission mechanism. The sender retains a buffer for P-frame packets. If no ACK is received from the receiver before the timeout retransmission timer expires, a retransmission is triggered. If the transmission is in progress... The P-frame data packet is marked as unreliable transmission. The sender does not maintain a retransmission buffer for unreliable P-frame data packets, and the receiver discards them directly without triggering a retransmission request.

8. The multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness according to claim 7, characterized in that, Step S6 includes: Step S61: Preset the I-frame reliability threshold and deadline. Count the number of I-frame data packets and P-frame data packets in the current data packet set. Combine the end-to-end delay, number, and deadline of the I-frame data packets to obtain the on-time delivery rate of the I-frame data packets and send it to the sending end. Step S62: Combine the sending status of P-frame data packets and obtain the corresponding reward value based on whether the on-time delivery rate reaches the I-frame reliability threshold; Step S63: Based on the reward value and combined with the context feature vector, update the LinUCB model parameters corresponding to the transmission action.

9. The multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness according to claim 8, characterized in that, Step S7 includes Step S71: Determine the maintenance selection count of each action in the action space based on the current data packet set, define the cold start flag, and update the LinUCB model parameters normally when in the cold start phase, but do not trigger the protection mode and soft restart; Step S72: Based on the current GoP monitoring of the consecutive failure count and consecutive success count of I-frames, after the cold start phase ends, if the consecutive failure count is greater than or equal to the first threshold, enter the protection mode until the consecutive failure count is greater than or equal to the minimum number of successful I-frame transmissions, and then exit the protection mode. Step S73: When in protection mode, if the consecutive success count is greater than or equal to the second threshold, trigger a global soft restart, perform a soft reset of the LinUCB model parameters for each action in the action space, until exiting protection mode.

10. A multipath real-time video transmission system based on the multipath fast UDP Internet connection protocol, characterized in that, The system includes a transmitter and a receiver. The transmitter is sequentially equipped with a video frame parsing module, a path status acquisition module, a data pre-allocation module, a LinUCB decision module, a forward error correction module, a packet loss retransmission control module, and a multi-path scheduling and transmission module. The receiver is sequentially equipped with a data reception and reassembly module, a timeliness statistics module, and a feedback module to execute the multi-path real-time video transmission method based on LinUCB with GoP-level video semantic awareness as described in any one of claims 1 to 9.

Images