Transmission control method, apparatus, and device
Patent Information
- Application Number
- CN202610654375.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-05-13
- Publication Date
- 2026-08-18
AI Technical Summary
[0004]然而,现有方法传输效率低
[0018]This application provides a transmission control method, apparatus, and device, comprising: extending a frame priority field in the header of an SRT data packet to be transmitted, and writing a corresponding priority value in the frame priority field according to the type of the current video frame; configuring a retransmission timeout parameter based on the priority value of the SRT data packet to be transmitted, and sending the SRT data packet carrying the priority value to a receiving end according to the retransmission timeout parameter; receiving NAK feedback from the receiving end, wherein the NAK feedback includes at least the sequence number of the lost data packet and its corresponding priority information; and performing transmission control on the lost data packet according to the priority information in the NAK feedback. This application achieves a mapping between video semantics and transmission protocols by extending the frame priority field in the SRT data packet header and writing the corresponding priority value according to the video frame type. Based on this, differentiated retransmission timeout parameters are configured for data packets according to the priority value, and data packets are sent according to these parameters. This allows high-priority frames (such as I-frames) to obtain shorter retransmission timeout thresholds, thus enabling them to be retransmitted faster during network congestion, significantly reducing the packet loss rate of key frames, and effectively reducing video screen tearing and stuttering. At the same time, the NAK feedback returned by the receiving end carries the priority information of lost data packets. The sending end performs differentiated transmission control for packet loss based on this information, avoiding the invalid retransmission of low-priority frames that occupy bandwidth. This can improve bandwidth utilization and transmission efficiency in multi-stream concurrency and bandwidth-constrained scenarios.
Smart Images

Figure CN122601148A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and more specifically, to a transmission control method, apparatus, and device. Background Technology
[0002] Against the backdrop of the explosive growth of internet video applications, services such as online live streaming, remote video conferencing, and cloud gaming have placed stringent demands on the real-time performance and stability of video transmission. The SRT (Secure Reliable Transport) protocol, as a mainstream real-time video transmission protocol based on UDP, has been widely used in live streaming, remote production, and video conferencing due to its low latency, high reliability, and support for multi-stream transmission. It effectively meets the needs of real-time video services for fast and stable transmission.
[0003] The existing SRT protocol uses a hybrid feedback mechanism of ACK (acknowledgment) and NACK (negative acknowledgment) to implement packet loss retransmission: after the sender sends a data packet, the receiver informs the sender of the successfully received data packet through ACK, and if packet loss is detected, it notifies the sender to retransmit through NACK.
[0004] However, existing methods have low transmission efficiency. Summary of the Invention
[0005] The main objective of this application is to provide a transmission control method, apparatus, or device that improves transmission efficiency.
[0006] To achieve the above objectives, in a first aspect, this application provides a transmission control method, comprising: The frame priority field is extended in the header of the SRT data packet to be sent, and the corresponding priority value is written in the frame priority field according to the type of the current video frame. The retransmission timeout parameter is configured based on the priority value of the SRT data packet to be sent, and the SRT data packet carrying the priority value is sent to the receiving end according to the retransmission timeout parameter. Receive NAK feedback from the receiving end, wherein the NAK feedback contains at least the sequence number of the lost data packet and its corresponding priority information; Based on the priority information in the NAK feedback, transmission control is performed on lost data packets.
[0007] In one embodiment, a frame priority field is extended in the header of the SRT data packet to be sent, and the corresponding priority value is written into the frame priority field according to the type of the current video frame, including: Reserved redundancy bits in the header of the SRT data packet to be sent extend the frame priority field; If the current video frame is an I-frame, the SRT data packet to be sent is marked as first priority, and the priority value corresponding to the first priority is written into the frame priority field. If the current video frame is a P-frame, the SRT data packet to be sent is marked as the second or third priority according to the P-frame's level in the GOP, where the first, second, and third priorities decrease sequentially.
[0008] In one embodiment, the SRT data packet to be sent is marked as a second priority or a third priority according to the P-frame's hierarchy in the GOP, including: If the P-frame is at a level before the preset position in the GOP, the SRT data packet to be sent is marked as the second priority; If the P-frame is at a level after a preset position in the GOP, the SRT data packet to be sent will be marked as the third priority.
[0009] In one embodiment, the retransmission timeout parameter is a retransmission timeout threshold; The retransmission timeout parameter, configured based on the priority value of the SRT data packet to be sent, includes: The retransmission timeout threshold for the SRT data packets to be sent is determined based on the priority value. If the SRT data packet to be sent is marked as an I-frame data packet, configure the first retransmission timeout threshold for the I-frame data packet; If the SRT data packet to be sent is marked as a P-frame data packet, configure a second retransmission timeout threshold for the P-frame data packet, wherein the first retransmission timeout threshold is less than the second retransmission timeout threshold.
[0010] In one embodiment, the first retransmission timeout threshold RTO1 is calculated as follows: RTO1 = SRTT + 2 × RTTVAR; Where SRTT is the smoothed round-trip time and RTTVAR is the round-trip time deviation.
[0011] In one embodiment, the second retransmission timeout threshold RTO2 is calculated as follows: RTO2 = SRTT + 4 × RTTVAR; Where SRTT is the smoothed round-trip time and RTTVAR is the round-trip time deviation.
[0012] In one embodiment, sending an SRT data packet carrying a priority value to the receiving end according to a retransmission timeout parameter includes: The retransmission timeout parameter starts the retransmission timer for the SRT data packet to be sent, which carries the priority value. If the SRT data to be sent has the highest priority, retransmission will be initiated immediately after the retransmission timer expires. If the SRT data to be sent is of the second or third priority, after the retransmission timer expires, it will be determined whether to retransmit immediately or delay retransmission based on the current network load status.
[0013] In one embodiment, transmission control is performed on lost data packets based on priority information in the NAK feedback, including: When the NAK feedback carries priority information corresponding to the first priority, the retransmission request corresponding to the lost data packet is inserted into the high-priority retransmission queue, and the lost data packet in the high-priority retransmission queue is scheduled and sent. When the high-priority retransmission queue is emptied or reaches a preset threshold, the retransmission of lost data packets of the second and third priorities is delayed or suppressed according to the backoff algorithm.
[0014] Secondly, embodiments of this application provide a transmission control device, including: The priority setting module is used to extend the frame priority field in the header of the SRT data packet to be sent, and write the corresponding priority value in the frame priority field according to the type of the current video frame. The data sending module is used to configure the retransmission timeout parameter based on the priority value of the SRT data packet to be sent, and to send the SRT data packet carrying the priority value to the receiving end according to the retransmission timeout parameter. The feedback receiving module is used to receive NAK feedback from the receiving end, wherein the NAK feedback contains at least the sequence number of the lost data packet and its corresponding priority information; The transmission control module is used to perform transmission control on lost data packets based on the priority information in the NAK feedback.
[0015] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the methods described above.
[0016] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described above.
[0017] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods described above.
[0018] This application provides a transmission control method, apparatus, and device, comprising: extending a frame priority field in the header of an SRT data packet to be transmitted, and writing a corresponding priority value in the frame priority field according to the type of the current video frame; configuring a retransmission timeout parameter based on the priority value of the SRT data packet to be transmitted, and sending the SRT data packet carrying the priority value to a receiving end according to the retransmission timeout parameter; receiving NAK feedback from the receiving end, wherein the NAK feedback includes at least the sequence number of the lost data packet and its corresponding priority information; and performing transmission control on the lost data packet according to the priority information in the NAK feedback. This application achieves a mapping between video semantics and transmission protocols by extending the frame priority field in the SRT data packet header and writing the corresponding priority value according to the video frame type. Based on this, differentiated retransmission timeout parameters are configured for data packets according to the priority value, and data packets are sent according to these parameters. This allows high-priority frames (such as I-frames) to obtain shorter retransmission timeout thresholds, thus enabling them to be retransmitted faster during network congestion, significantly reducing the packet loss rate of key frames, and effectively reducing video screen tearing and stuttering. At the same time, the NAK feedback returned by the receiving end carries the priority information of lost data packets. The sending end performs differentiated transmission control for packet loss based on this information, avoiding the invalid retransmission of low-priority frames that occupy bandwidth. This can improve bandwidth utilization and transmission efficiency in multi-stream concurrency and bandwidth-constrained scenarios. Attached Figure Description
[0019] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 This is a schematic flowchart of a transmission control method provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a frame priority identification method provided in an embodiment of this application; Figure 3 This is a flowchart illustrating a ROT configuration method provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a priority scheduling method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a transmission control device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the computer device provided in the embodiments of this application. Detailed Implementation
[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.
[0021] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein.
[0022] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
[0023] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0024] It should be understood that in this application, "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.
[0025] It should be understood that in this application, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, "and / or B" can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.
[0026] It should be understood that in this application, "B corresponding to A", "B corresponding to A", "A corresponds to B", or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.
[0027] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."
[0028] The data involved in this application may be data authorized by the tester or fully authorized by all parties. The collection, dissemination, and use of the data shall comply with the relevant laws, regulations and standards of the relevant countries and regions. The implementation methods / executives of this application may be combined with each other.
[0029] It is understood that in the specific embodiments of this application, data such as user information are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.
[0030] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.
[0031] With the explosive growth of internet video applications such as live streaming, remote video conferencing, and cloud gaming, stringent requirements have been placed on the real-time performance and stability of video transmission. While the SRT protocol, as an emerging UDP-based real-time transmission protocol, excels in low-latency transmission, it lacks effective video semantic mapping in complex network environments and when facing multi-stream transmission. This results in video frames of different importance being transmitted equally, failing to adequately guarantee the transmission quality of key frames (such as I-frames), thus impacting the overall video viewing experience.
[0032] SRT (Secure Reliable Transport), a mainstream real-time video transmission protocol based on UDP, has been widely used in live streaming, remote production, and video conferencing in recent years. With its low latency, high reliability, and support for multi-stream transmission, it effectively meets the demands of real-time video services for fast and stable transmission. In live streaming scenarios, the SRT protocol enables the rapid transmission of audio and video signals captured on-site to a server, which is then distributed to a large number of viewers, ensuring that viewers can watch high-definition live content in real time. In the field of remote production, it can stably transmit video streams from the shooting location to a remote production center, allowing production teams to collaborate remotely, greatly improving production efficiency and flexibility.
[0033] The SRT protocol employs a hybrid ACK (acknowledgment) + NACK (negative acknowledgment) feedback mechanism for packet retransmission. After the sender transmits a data packet, the receiver informs the sender of the successful reception via ACK. If the receiver detects packet loss, it notifies the sender to retransmit via NACK. This mechanism effectively improves the reliability of data transmission. Simultaneously, the SRT protocol precisely controls transmission delay through the Tsbpd (Timing-based Send Packet Delay) mechanism, dynamically adjusting the timing of data packet transmission based on network conditions to ensure low-latency transmission even in complex network environments.
[0034] However, existing SRT protocols have limitations in their packet header design, failing to define fields related to video semantics. In video coding, I-frames (keyframes) contain complete image information, forming the basis of video decoding and playing a decisive role in video quality; P-frames (predictive frames), on the other hand, are predicted and encoded based on the previous frame (I-frame or P-frame), containing information about the differences between the two frames. The importance of different types of video frames varies greatly during video decoding and playback, but existing SRT protocols cannot distinguish these differences, treating all video frames equally during transmission.
[0035] Because the existing SRT protocol uses a uniform Retransmission Timeout (RTO) configuration and NAK feedback strategy for all data packets, it has exposed many problems in practical applications. When network bandwidth is tight or packet loss occurs, retransmission requests for key frames (such as I-frames) and ordinary frames (such as P-frames) compete for limited bandwidth resources. I-frames are crucial for video decoding; if they are lost or have excessive transmission latency, subsequent frames cannot be correctly reconstructed during video decoding, leading to problems such as screen tearing and stuttering that seriously affect the viewing experience. P-frames have different levels of importance within a GOP (Group of Pictures), but the existing SRT protocol does not consider this difference and uses the same retransmission strategy for all P-frames. This causes some low-priority P-frames to frequently initiate retransmission requests even when the network is congested. These invalid retransmission requests not only fail to effectively improve video quality but also waste valuable bandwidth resources, further exacerbating network congestion and reducing overall transmission efficiency.
[0036] For example, during a live broadcast of a major sporting event, when the number of viewers surges and network bandwidth becomes strained, the SRT protocol cannot prioritize the transmission of I-frames, which may lead to I-frame packet loss. This can cause severe stuttering or even prolonged black screens on the viewer's end, greatly affecting the viewing experience. At the same time, the invalid retransmission of a large number of low-priority P-frames further consumes network bandwidth, hindering the transmission of other important data and making it difficult to guarantee the stability and smoothness of the live broadcast.
[0037] In video transmission, the existing SRT protocol lacks a semantic mapping for video frame priority. All video frames are treated equally during transmission, leading to competition for limited bandwidth resources between keyframes (such as I-frames) and ordinary frames (such as P-frames) in complex network environments. Loss or excessive transmission delay of keyframes can cause video artifacts, stuttering, and other serious issues that significantly impact the viewing experience. Furthermore, while P-frames at different levels have varying importance, the existing SRT protocol uses the same retransmission strategy. This results in low-priority P-frames frequently initiating retransmission requests during network congestion, wasting bandwidth resources, exacerbating network congestion, and reducing overall transmission efficiency.
[0038] To address the aforementioned problems, this application proposes a transmission control method.
[0039] Please see Figure 1 , Figure 1 This is a flowchart illustrating a transmission control method provided in an embodiment of this application. Figure 1 As shown, it includes the following steps: Step S101: Extend the frame priority field in the header of the SRT data packet to be sent, and write the corresponding priority value in the frame priority field according to the type of the current video frame.
[0040] In one embodiment, a frame priority field is extended in the header of the SRT data packet to be sent, and a corresponding priority value is written into the frame priority field according to the type of the current video frame. This includes: extending the frame priority field in the reserved redundancy bits of the header of the SRT data packet to be sent; if the type of the current video frame is an I-frame, the SRT data packet to be sent is marked as a first priority, and the priority value corresponding to the first priority is written into the frame priority field; if the type of the current video frame is a P-frame, the SRT data packet to be sent is marked as a second priority or a third priority according to the level of the P-frame in the GOP, wherein the first priority, second priority, and third priority decrease step by step.
[0041] Specifically, based on the P-frame's hierarchy within the GOP, the SRT data packet to be sent is marked as either the second or third priority. This includes: if the P-frame's hierarchy within the GOP is before a preset position, the SRT data packet to be sent is marked as the second priority; if the P-frame's hierarchy within the GOP is after a preset position, the SRT data packet to be sent is marked as the third priority.
[0042] Specifically, firstly, the sending end analyzes the 16-byte SRT header currently used by the SRT protocol and executes the operation procedure for the extended frame priority field. Combined with... Figure 2 As shown, the process includes: locating reserved redundant bits in the 16-byte SRT header; selecting specific reserved bits from these reserved redundant bits; embedding a 2-3 bit "Frame Priority (PRIO)" field into the selected reserved bit; subsequently verifying compatibility to ensure that the header length and structure remain unchanged and that it is compatible with the older SRT protocol; retaining existing fields such as sequence number and timestamp, so that the PRIO field coexists with the original fields in the extended header structure; and using the PRIO field to independently identify the frame priority, thus completing the frame priority identification function. Specifically, without changing the basic structure and length of the existing header, the sending end performs in-depth analysis of the header to locate the reserved redundant bits, which are not fully utilized in the current SRT protocol. After evaluation and testing, the sending end decides to select 2 or 3 bits from these reserved redundant bits as the embedding position for the PRIO field. When selecting the field position, core functional fields such as sequence number and timestamp are strictly avoided to ensure that the extended protocol maintains good compatibility with existing SRT devices and avoids data packet parsing failures due to field conflicts. The extended header structure consists of the original fields (sequence number, timestamp, etc.) and the newly added PRIO field. The PRIO field independently identifies the frame priority without changing the header length and structure, thus achieving compatibility with the old SRT protocol and completing the frame priority identification function.
[0043] After expanding the PRIO field, the sending end performs type identification on the video frames output by the encoder. If the current video frame is an I-frame, since I-frames contain complete image information and are the foundation of video decoding, playing a decisive role in video quality, the sending end marks the SRT data packet to be sent as first priority (highest priority) and writes the priority value corresponding to the first priority into the PRIO field. For example, when using a 3-bit PRIO field, the first priority can be assigned a value of 3 (binary "011"), so that I-frames can obtain transmission resources preferentially in complex situations such as network congestion, ensuring that they arrive at the receiving end quickly and reliably.
[0044] If the current video frame is a P-frame, its hierarchical position within the Group of Pictures (GOP) is further analyzed. The importance of P-frames varies depending on their hierarchical position within the GOP. Specifically, the sender prioritizes P-frames based on their GOP hierarchical position: For P-frames earlier in the GOP (e.g., those before a preset position), their impact on subsequent frame decoding is greater, and transmission reliability directly affects the correct reconstruction of subsequent video frames. Therefore, the SRT data packet to be sent is marked as second priority (higher priority), and the corresponding priority value (e.g., 2, binary "010") is written into the PRIO field. For P-frames later in the GOP (e.g., those after a preset position), their importance is relatively lower, and their transmission priority can be appropriately reduced when network resources are limited. Therefore, the SRT data packet to be sent is marked as third priority (lower priority), and the corresponding priority value (e.g., 1, binary "001") is written into the PRIO field. In this hierarchy, the transmission importance decreases progressively from first priority to third priority, with first priority being the highest, followed by second priority, and third priority being the lowest. For example, in a typical GOP structure, P-frames that are closer to I-frames (higher in the hierarchy) rely more heavily on I-frames during decoding. If these P-frames are lost or have excessive transmission delays, it will lead to decoding errors in a series of subsequent frames. Therefore, it is reasonable to mark them as higher priority. Conversely, P-frames that are later in the hierarchy are relatively less important and are marked as lower priority.
[0045] In this way, when the sending end encapsulates the SRT data packet, it writes the corresponding priority value into the frame priority field according to the type of the current video frame and its level in the GOP, thus realizing an accurate mapping from video frame semantics to the transport protocol priority field.
[0046] To accommodate the differences in GOP structures across different coding standards (such as H.264 and H.265), the above value rules can be flexibly adjusted through configuration parameters. In practical applications, different video coding standards may employ different GOP structures and inter-frame prediction methods. By configuring parameters, users can customize the value rules of the PRIO field according to the specific coding standard and application scenario, achieving precise control over video frame priority. For example, for the H.265 coding standard, its GOP structure may be more complex, containing more types of frames. Users can, based on its characteristics, mark certain special types of frames with specific priorities through configuration parameters to meet actual transmission requirements.
[0047] Step S102: Based on the priority value of the SRT data packet to be sent, configure the retransmission timeout parameter, and send the SRT data packet carrying the priority value to the receiving end according to the retransmission timeout parameter.
[0048] In one embodiment, the retransmission timeout parameter is a retransmission timeout threshold; the retransmission timeout parameter configured based on the priority value of the SRT data packet to be sent includes: determining the retransmission timeout threshold of the SRT data packet to be sent according to the priority value; if the SRT data packet to be sent is marked as an I-frame data packet, configuring a first retransmission timeout threshold for the I-frame data packet; if the SRT data packet to be sent is marked as a P-frame data packet, configuring a second retransmission timeout threshold for the P-frame data packet, wherein the first retransmission timeout threshold is less than the second retransmission timeout threshold.
[0049] The first retransmission timeout threshold RTO1 is calculated as follows: RTO1 = SRTT + 2 × RTTVAR; Where SRTT is the smoothed round-trip time and RTTVAR is the round-trip time deviation.
[0050] The second retransmission timeout threshold RTO2 is calculated as follows: RTO2 = SRTT + 4 × RTTVAR; Where SRTT is the smoothed round-trip time and RTTVAR is the round-trip time deviation.
[0051] In one embodiment, sending an SRT data packet carrying a priority value to the receiving end according to a retransmission timeout parameter includes: starting a retransmission timer for the SRT data packet carrying a priority value according to the retransmission timeout parameter; if the SRT data to be sent is of the first priority, retransmission is initiated immediately after the retransmission timer expires; if the SRT data to be sent is of the second or third priority, after the retransmission timer expires, immediate retransmission or delayed retransmission is determined according to the current network load status.
[0052] Specifically, such as Figure 3 As shown, after the sending end completes the priority marking of video frames, it further configures a differentiated retransmission timeout threshold for each SRT data packet to be sent according to the priority value. Specifically, the retransmission timeout parameter is the retransmission timeout threshold (RTO). The sending end determines the corresponding RTO calculation rule based on the priority value marked on the current data packet. If the current SRT data packet to be sent is marked as an I-frame data packet (i.e., a data packet carrying an I-frame, corresponding to the first priority), then a first retransmission timeout threshold is configured for it. This first retransmission timeout threshold adopts a shorter calculation rule, specifically based on the smooth round-trip time (SRTT) and round-trip time deviation (RTTVAR), calculated according to the following formula: RTO1 = SRTT + 2×RTTVAR. By setting a shorter retransmission timeout threshold, the retransmission response speed when I-frame packets are lost can be accelerated, ensuring that I-frames can be retransmitted as soon as possible when the network is congested, reducing video stuttering and screen tearing caused by I-frame loss.
[0053] If the SRT data packet to be sent is marked as a P-frame data packet (i.e., a data packet carrying a P-frame, corresponding to the second or third priority), then a second retransmission timeout threshold is configured for it. This second retransmission timeout threshold uses standard calculation rules, specifically based on the Smooth Round-Trip Time (SRTT) and Round-Trip Time Offset (RTTVAR), calculated according to the following formula: RTO2 = SRTT + 4 × RTTVAR. Wherein, the first retransmission timeout threshold (RTO1) is less than the second retransmission timeout threshold (RTO2), thus achieving fast retransmission of I-frames over P-frames.
[0054] Meanwhile, to avoid frequent retransmissions of P-frames during network congestion and wasting bandwidth resources, the sender also introduced a backoff algorithm: when a P-frame data packet is retransmitted, the retransmission timeout threshold for each retransmission increases progressively according to the backoff coefficient, which is set to 1.5 times. For example, if the RTO of a P-frame data packet is RTO2 during its first retransmission, then if it is retransmitted again, the RTO becomes RTO2 × 1.5, and so on. In this way, during network congestion, retransmission requests for P-frames will gradually decrease, bandwidth resources will be allocated reasonably, and priority will be given to the transmission of critical frames such as I-frames. In addition, the sender also incorporated optimization experience from the KCP protocol, drawing on its RTO backoff coefficient setting to further balance retransmission efficiency and network load.
[0055] After configuring the retransmission timeout threshold, the sending end sends an SRT data packet carrying the specified priority value to the receiving end and starts a retransmission timer for that data packet according to the retransmission timeout parameter. Specifically, when sending each SRT data packet, the sending end simultaneously starts a retransmission timer associated with that data packet, and the timeout duration is the aforementioned configured retransmission timeout threshold (RTO). During the retransmission timer's operation, if the sending end receives an acknowledgment (ACK) from the receiving end, it stops the timer and confirms that the data packet was successfully sent; if no acknowledgment is received after the retransmission timer expires, a retransmission operation is triggered.
[0056] The handling strategy after the retransmission timer expires differs for data packets of different priorities. If the SRT data packet to be sent is marked as first priority (i.e., an I-frame data packet), the sender immediately initiates a retransmission after the retransmission timer expires, without adding any delay or suppression conditions, to ensure that the I-frame can be retransmitted as quickly as possible, ensuring that the key information for video decoding reaches the receiver in a timely manner.
[0057] If the SRT data packet to be sent is marked as second or third priority (i.e., P-frame data packet, where second priority corresponds to P-frames at the earlier GOP level and third priority corresponds to P-frames at the later GOP level), the sender first assesses the current network load status after the retransmission timer expires. The sender determines whether the network is congested by monitoring changes in round-trip time (RTT), packet loss rate, and bandwidth utilization. If the network load is light (e.g., stable RTT, packet loss rate below a preset threshold), a retransmission is initiated immediately; if the network load is heavy or congested (e.g., a sudden increase in RTT, increased packet loss rate), delayed retransmission or direct suppression of retransmission is performed according to the priority value. For second priority (higher priority P-frames), a limited number of delayed retransmissions can be performed during congestion, with the delay time increasing by a backoff factor for each retransmission; for third priority (lower priority P-frames), their retransmission requests can be discarded directly during congestion to avoid invalid retransmissions consuming valuable bandwidth resources.
[0058] Furthermore, the sending end has optimized the packet buffering time based on priority. For high-priority packets (such as I-frames), to ensure that there are enough packets available for retransmission requests, the sending end sets its buffering time to 2 × RTT + NACK feedback interval + redundancy time. For low-priority packets (such as P-frames), considering their relatively small impact on video quality, to reduce memory usage, the sending end sets its buffering time to no more than one GOP cycle, automatically clearing and releasing memory after timeout. During packet transmission, the sending end synchronously maintains a priority-associated transmission buffer queue, storing transmitted but unacknowledged packets in the buffer queue according to priority. When a NACK feedback is received, retransmission is performed based on the packets in the buffer.
[0059] In this way, the sending end configures differentiated retransmission timeout parameters according to priority values, and based on different processing strategies after the retransmission timer expires, combined with network load status and cache management, it realizes differentiated transmission control of high-priority frames being retransmitted first and low-priority frames being delayed or suppressed for retransmission, thereby ensuring reliable transmission of video key frames in complex network environments.
[0060] Step S103: Receive NAK feedback from the receiving end.
[0061] The NAK feedback includes at least the sequence number of the lost data packet and its corresponding priority information.
[0062] Step S104: Perform transmission control on lost data packets based on the priority information in the NAK feedback.
[0063] In one embodiment, transmission control is performed on lost data packets based on priority information in the NAK feedback, including: When the NAK feedback carries priority information corresponding to the first priority, the retransmission request corresponding to the lost data packet is inserted into the high-priority retransmission queue, and the lost data packet in the high-priority retransmission queue is scheduled and sent. When the high-priority retransmission queue is emptied or reaches a preset threshold, the retransmission of lost data packets of the second and third priorities is delayed or suppressed according to the backoff algorithm.
[0064] Specifically, firstly, after receiving the SRT data packet, the receiving end executes a priority-based NAK feedback optimization strategy. For example... Figure 4 As shown, the receiving end first parses the PRIO field of each SRT data packet and determines the priority of the video frame to which the data packet belongs based on the field value.
[0065] When packet loss is detected, the receiver places packet loss requests for high-priority frames (e.g., PRIO=3 or 2, corresponding to I-frames and P-frames at the beginning of the GOP level) into a high-priority NAK queue; for low-priority frames (e.g., PRIO=1 or 0, corresponding to P-frames at the end of the GOP level or other low-importance frames), they are placed into a low-priority NAK queue. The receiver also monitors network bandwidth utilization in real time. When bandwidth utilization exceeds a preset threshold (i.e., network bandwidth is strained), a low-priority NAK request suppression mechanism is activated, which can choose to delay transmission or directly discard requests in the low-priority NAK queue. When sending NAK feedback, requests in the high-priority queue will skip the low-priority queue and be sent to the sender first.
[0066] In addition, the receiving end performs deduplication and aggregation optimization on the NAK queue: duplicate NAK requests for data packets with the same sequence number are deduplicated, retaining only one valid request; for lost requests with adjacent sequence numbers, they are aggregated into a single NAK request for transmission (e.g., consecutively lost sequence numbers 10, 11, and 12 are merged into one request to inform the sending end to retransmit 10-12); a maximum retransmission threshold for NAK requests is also set, and transmission stops when the threshold is exceeded. Through the above processing, the receiving end generates an optimized NAK feedback message, which at least contains the sequence number of the lost data packet and its corresponding priority information (this priority information comes from the value of the original PRIO field of the lost data packet), and sends this NAK feedback to the sending end.
[0067] The sending end receives NAK feedback from the receiving end and parses out the sequence number and corresponding priority information of each lost data packet. Then, the sending end performs differentiated transmission control on the lost data packets based on the priority information. Specifically, the sending end maintains a multi-level retransmission queue, including a high-priority retransmission queue and a low-priority retransmission queue. When the NAK feedback carries priority information corresponding to the first priority (PRIO=3, corresponding to an I-frame), the sending end inserts the retransmission request corresponding to the lost data packet into the high-priority retransmission queue and immediately schedules the transmission of the lost data packets in the high-priority retransmission queue, ensuring that I-frames can be retransmitted with priority. When the NAK feedback carries priority information corresponding to the second priority (PRIO=2, corresponding to P-frames earlier in the GOP level) or the third priority (PRIO=1, corresponding to P-frames later in the GOP level), the sending end inserts the corresponding retransmission request into the low-priority retransmission queue. After the high-priority retransmission queue is emptied or a preset threshold is reached (e.g., the high-priority queue length is zero, or a certain number of high-priority retransmission requests have been processed consecutively), the sender then performs delayed retransmission or suppressed retransmission on the second and third priority lost data packets in the low-priority retransmission queue according to the backoff algorithm.
[0068] The backoff algorithm is as follows: for packet loss of the second and third priority, after the first retransmission fails, the retransmission timeout is increased by a backoff coefficient of 1.5 times; when the number of retransmission attempts reaches the preset limit, subsequent retransmission requests for the lost packet are suppressed; if the sending end detects network congestion at the same time (such as a sudden increase in RTT or an increase in packet loss rate), the backoff coefficient is further increased or low-priority retransmission requests are directly discarded.
[0069] In this way, the sending end achieves priority retransmission of high-priority packet loss and backoff delay or suppression of low-priority packet loss based on the priority information in NAK feedback, thereby optimizing bandwidth resource utilization while ensuring the reliability of key frame transmission.
[0070] This application provides a transmission control method, comprising: extending a frame priority field in the header of an SRT data packet to be transmitted, and writing a corresponding priority value in the frame priority field according to the type of the current video frame; configuring a retransmission timeout parameter based on the priority value of the SRT data packet to be transmitted, and sending the SRT data packet carrying the priority value to the receiving end according to the retransmission timeout parameter; receiving NAK feedback from the receiving end, wherein the NAK feedback includes at least the sequence number of the lost data packet and its corresponding priority information; and performing transmission control on the lost data packet according to the priority information in the NAK feedback. This application achieves a mapping between video semantics and transmission protocols by extending the frame priority field in the SRT data packet header and writing the corresponding priority value according to the video frame type. Based on this, differentiated retransmission timeout parameters are configured for data packets according to the priority value, and data packets are sent according to these parameters. This allows high-priority frames (such as I-frames) to obtain shorter retransmission timeout thresholds, thus enabling them to be retransmitted faster during network congestion, significantly reducing the packet loss rate of key frames, and effectively reducing video screen tearing and stuttering. At the same time, the NAK feedback returned by the receiving end carries the priority information of lost data packets. The sending end performs differentiated transmission control for packet loss based on this information, avoiding the invalid retransmission of low-priority frames that occupy bandwidth. This can improve bandwidth utilization and transmission efficiency in multi-stream concurrency and bandwidth-constrained scenarios.
[0071] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0072] The following are device embodiments of this application. For details not described in detail, please refer to the corresponding method embodiments described above.
[0073] Figure 5 This diagram illustrates the structure of a transmission control device according to an embodiment of this application. For ease of explanation, only the parts relevant to the embodiment of this application are shown. The transmission control device includes: The priority setting module 501 is used to extend the frame priority field in the header of the SRT data packet to be sent, and write the corresponding priority value in the frame priority field according to the type of the current video frame. The data sending module 502 is used to configure the retransmission timeout parameter based on the priority value of the SRT data packet to be sent, and to send the SRT data packet carrying the priority value to the receiving end according to the retransmission timeout parameter. Feedback receiving module 503 is used to receive NAK feedback from the receiving end, wherein the NAK feedback contains at least the sequence number of the lost data packet and its corresponding priority information; The transmission control module 504 is used to perform transmission control on lost data packets based on the priority information in the NAK feedback.
[0074] In one embodiment, the priority setting module 501 is further configured to extend the frame priority field in the reserved redundancy bits of the header of the SRT data packet to be sent. If the current video frame is an I-frame, the SRT data packet to be sent is marked as first priority, and the priority value corresponding to the first priority is written into the frame priority field. If the current video frame is a P-frame, the SRT data packet to be sent is marked as the second or third priority according to the P-frame's level in the GOP, where the first, second, and third priorities decrease sequentially.
[0075] In one embodiment, the priority setting module 501 is further configured to mark the SRT data packet to be sent as the second priority if the P frame is at a level before a preset position in the GOP. If the P-frame is at a level after a preset position in the GOP, the SRT data packet to be sent will be marked as the third priority.
[0076] In one embodiment, the retransmission timeout parameter is a retransmission timeout threshold; The data sending module 502 is also used to determine the retransmission timeout threshold of the SRT data packet to be sent based on the priority value; If the SRT data packet to be sent is marked as an I-frame data packet, configure the first retransmission timeout threshold for the I-frame data packet; If the SRT data packet to be sent is marked as a P-frame data packet, configure a second retransmission timeout threshold for the P-frame data packet, wherein the first retransmission timeout threshold is less than the second retransmission timeout threshold.
[0077] In one embodiment, the first retransmission timeout threshold RTO1 is calculated as follows: RTO1 = SRTT + 2 × RTTVAR; Where SRTT is the smoothed round-trip time and RTTVAR is the round-trip time deviation.
[0078] In one embodiment, the second retransmission timeout threshold RTO2 is calculated as follows: RTO2 = SRTT + 4 × RTTVAR; Where SRTT is the smoothed round-trip time and RTTVAR is the round-trip time deviation.
[0079] In one embodiment, the data sending module 502 is further configured to start a retransmission timer for the SRT data packet to be sent, which carries a priority value, according to the retransmission timeout parameter. If the SRT data to be sent has the highest priority, retransmission will be initiated immediately after the retransmission timer expires. If the SRT data to be sent is of the second or third priority, after the retransmission timer expires, it will be determined whether to retransmit immediately or delay retransmission based on the current network load status.
[0080] In one embodiment, the transmission control module 504 is further configured to insert the retransmission request corresponding to the lost data packet into the high-priority retransmission queue when the NAK feedback carries priority information corresponding to the first priority, and schedule and send the lost data packet in the high-priority retransmission queue. When the high-priority retransmission queue is emptied or reaches a preset threshold, the retransmission of lost data packets of the second and third priorities is delayed or suppressed according to the backoff algorithm.
[0081] This application provides a transmission control device, specifically configured to: extend a frame priority field in the header of an SRT data packet to be transmitted, and write a corresponding priority value in the frame priority field according to the type of the current video frame; configure a retransmission timeout parameter based on the priority value of the SRT data packet to be transmitted, and send the SRT data packet carrying the priority value to the receiving end according to the retransmission timeout parameter; receive NAK feedback from the receiving end, wherein the NAK feedback includes at least the sequence number of the lost data packet and its corresponding priority information; and perform transmission control on the lost data packet according to the priority information in the NAK feedback. This application achieves a mapping between video semantics and transmission protocols by extending the frame priority field in the SRT data packet header and writing the corresponding priority value according to the video frame type. Based on this, differentiated retransmission timeout parameters are configured for data packets according to the priority value, and data packets are sent according to these parameters. This allows high-priority frames (such as I-frames) to obtain shorter retransmission timeout thresholds, thus enabling them to be retransmitted faster during network congestion, significantly reducing the packet loss rate of key frames, and effectively reducing video screen tearing and stuttering. At the same time, the NAK feedback returned by the receiving end carries the priority information of lost data packets. The sending end performs differentiated transmission control for packet loss based on this information, avoiding the invalid retransmission of low-priority frames that occupy bandwidth. This can improve bandwidth utilization and transmission efficiency in multi-stream concurrency and bandwidth-constrained scenarios.
[0082] This application Figure 6 A schematic diagram of a computer device is provided. (Example) Figure 6 As shown, the computer device 6 in this embodiment includes a processor 601, a memory 602, and a computer program 603 stored in the memory 602 and executable on the processor 601. When the processor 601 executes the computer program 603, it implements the steps in the various transmission control method embodiments described above, for example... Figure 1Steps 101 to 104 are shown. Alternatively, when processor 601 executes computer program 603, it implements the functions of each module / unit in the above-described embodiments of the transmission control device, for example... Figure 5 The functions of modules / units 501 to 504 are shown.
[0083] This application also provides a readable storage medium storing a computer program, which, when executed by a processor, is used to implement the transmission control methods provided in the various embodiments described above.
[0084] The readable storage medium can be a computer storage medium or a communication medium. A communication medium includes any medium that facilitates the transfer of computer programs from one location to another. A computer storage medium can be any available medium accessible to a general-purpose or special-purpose computer. For example, a readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application-Specific Integrated Circuit (ASIC). Alternatively, the ASIC can be located in a user equipment. Of course, the processor and the readable storage medium can also exist as discrete components in a communication device. The readable storage medium can be a read-only memory (ROM), random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.
[0085] This application also provides a program product including executable instructions stored in a readable storage medium. At least one processor of the device can read the executable instructions from the readable storage medium, and the execution of the executable instructions by the at least one processor causes the device to implement the transmission control methods provided in the various embodiments described above.
[0086] In the embodiments of the above-described device, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.
[0087] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.
Claims
1. A transmission control method, characterized in that, include: The frame priority field is extended in the header of the SRT data packet to be sent, and the corresponding priority value is written into the frame priority field according to the type of the current video frame. The retransmission timeout parameter configured for the SRT data packet to be sent is based on the priority value, and the SRT data packet to be sent carrying the priority value is sent to the receiving end according to the retransmission timeout parameter. Receive NAK feedback from the receiving end, wherein the NAK feedback includes at least the sequence number of the lost data packet and its corresponding priority information; Based on the priority information in the NAK feedback, transmission control is performed on the lost data packets.
2. The transmission control method as described in claim 1, characterized in that, The step of extending the frame priority field in the header of the SRT data packet to be sent, and writing the corresponding priority value into the frame priority field according to the type of the current video frame, includes: The frame priority field is extended in the reserved redundancy bits of the header of the SRT data packet to be sent; If the current video frame is an I-frame, the SRT data packet to be sent is marked as having the first priority, and the priority value corresponding to the first priority is written into the frame priority field. If the current video frame is a P-frame, the SRT data packet to be sent is marked as a second priority or a third priority according to the P-frame's level in the GOP, wherein the first priority, the second priority, and the third priority decrease sequentially.
3. The transmission control method as described in claim 2, characterized in that, The step of marking the SRT data packet to be sent as the second priority or the third priority according to the layer of the P frame in the GOP includes: If the P-frame is at a level before a preset position in the GOP, the SRT data packet to be sent is marked as the second priority; If the P-frame is at a preset position in the GOP, the SRT data packet to be sent is marked as the third priority.
4. The transmission control method as described in claim 1, characterized in that, The retransmission timeout parameter is the retransmission timeout threshold; The retransmission timeout parameter configured based on the priority value of the SRT data packet to be sent includes: Based on the priority value, determine the retransmission timeout threshold for the SRT data packet to be sent; If the SRT data packet to be sent is marked as an I-frame data packet, configure a first retransmission timeout threshold for the I-frame data packet; If the SRT data packet to be sent is marked as a P-frame data packet, a second retransmission timeout threshold is configured for the P-frame data packet, wherein the first retransmission timeout threshold is less than the second retransmission timeout threshold.
5. The transmission control method as described in claim 4, characterized in that, The first retransmission timeout threshold RTO1 is calculated as follows: RTO1 = SRTT + 2 × RTTVAR; Where SRTT is the smoothed round-trip time and RTTVAR is the round-trip time deviation.
6. The transmission control method as described in claim 4, characterized in that, The second retransmission timeout threshold RTO2 is calculated as follows: RTO2 = SRTT + 4 × RTTVAR; Where SRTT is the smoothed round-trip time and RTTVAR is the round-trip time deviation.
7. The transmission control method as described in claim 1, characterized in that, The step of sending the SRT data packet carrying the priority value to the receiving end according to the retransmission timeout parameter includes: The retransmission timeout parameter is used to start the retransmission timer for the SRT data packet to be sent, which carries the priority value. If the SRT data to be sent is of the first priority, a retransmission shall be initiated immediately after the retransmission timer expires. If the SRT data to be sent is of the second or third priority, after the retransmission timer expires, it is determined whether to retransmit immediately or delay retransmission based on the current network load status.
8. The transmission control method as described in claim 1, characterized in that, The step of performing transmission control on the lost data packets based on the priority information in the NAK feedback includes: When the NAK feedback carries priority information corresponding to the first priority, the retransmission request corresponding to the lost data packet is inserted into the high-priority retransmission queue, and the lost data packet in the high-priority retransmission queue is scheduled and sent. When the high-priority retransmission queue is emptied or reaches a preset threshold, the retransmission of lost data packets of the second and third priorities is delayed or suppressed according to the backoff algorithm.
9. A transmission control device, characterized in that, include: The priority setting module is used to extend the frame priority field in the header of the SRT data packet to be sent, and write the corresponding priority value in the frame priority field according to the type of the current video frame. The data sending module is used to configure a retransmission timeout parameter for the SRT data packet to be sent based on the priority value, and to send the SRT data packet carrying the priority value to the receiving end according to the retransmission timeout parameter. The feedback receiving module is used to receive NAK feedback from the receiving end, wherein the NAK feedback includes at least the sequence number of the lost data packet and its corresponding priority information; The transmission control module is used to perform transmission control on the lost data packets according to the priority information in the NAK feedback.
10. A computer device, characterized in that, Includes a memory, and one or more processors communicatively connected to the memory; The memory stores instructions that can be executed by the one or more processors to cause the one or more processors to implement the transmission control method as described in any one of claims 1 to 8.