An eBPF-based video cloud real-time back pressure method and system

Abstract

The application provides an eBPF-based video cloud real-time back pressure method and system. The method comprises the following steps: at an entrance of a network data path of an operating system kernel, video frame type information is parsed from a network data packet of a received cloud video, the video frame type information is used to indicate that a video frame is an independent decoding frame or a dependent decoding frame; according to the video frame type information, network data packets corresponding to the independent decoding frame are passed, and network data packets corresponding to the dependent decoding frame are discarded; and the passed network data packets are subjected to rate limiting processing. The interception of over-quota traffic is moved forward to the earliest programmable node of the operating system kernel, and the intercepted object is limited to the dependent decoding frame, and the passing set always maintains the frame structure continuity required by video decoding, so that the reduction of system resource occupation and the maintenance of video service availability are simultaneously realized in one processing flow.

Description

Technical Field

[0001] This application belongs to the field of video cloud backpressure, and in particular relates to a video cloud real-time backpressure method and system based on eBPF. Background Technology

[0002] As the core infrastructure of streaming media services, video cloud platforms need to stably handle high-concurrency streaming services based on multiple protocols such as RTMP, GB28181, and RTSP. The actual streaming bitrate of a user depends on the encoding parameter settings and is not technically bound to the cloud service fee standard they have purchased. Therefore, it is common for the actual streaming bitrate to exceed the quota. Existing solutions to this problem mainly fall into two categories. The first category is the user-space application layer rate limiting scheme, which performs bitrate statistics on received media stream data packets at the socket layer of the streaming media service and performs packet drop processing when the traffic exceeds the quota. The drawback of this scheme is that before the data packets are dropped, they have already undergone complete parsing by the network card driver, kernel interrupt handling, network protocol stack, and memory copying from kernel space to user space. The entire chain consumes a large amount of operating system computing resources, network resources, and memory resources, and can only reduce the storage overhead of subsequent media data, but cannot fundamentally solve the problem of excessive traffic occupying system resources. The second category is the kernel TC traffic control mechanism rate limiting scheme, which performs rate limiting operations on specified traffic based on the TC module of the operating system kernel, and manages the excess traffic through random packet drop. The packet loss in this scheme occurs in the middle to late stages of kernel protocol stack processing. Data packets still need to pass through network card interrupts and kernel network layer protocol stack processing, thus failing to intercept excessive traffic at the earliest node and minimize resource consumption. More importantly, both schemes perform indiscriminate or random dropping of media data packets without distinguishing the video frame type carried by the dropped packets. When random dropping affects independent decoding frames, it directly leads to abnormal video playback or decoding failure, making it difficult to guarantee user service availability. Summary of the Invention

[0003] This application provides a video cloud real-time backpressure method and system based on eBPF, which solves the problem of how to reduce the occupation of operating system computing resources, network resources and memory resources by excess traffic while ensuring the availability of user video services when the video cloud streaming bitrate exceeds the user quota.

[0004] This application discloses a real-time backpressure method for video cloud based on eBPF, including: At the network data path entry point of the operating system kernel, video frame type information is parsed from the network data packets of the received cloud video. The video frame type information is used to indicate whether the video frame is an independent decoding frame or a dependent decoding frame. Based on the video frame type information, allow network data packets corresponding to independent decoded frames to pass through, and discard network data packets corresponding to dependent decoded frames; Rate limiting and flow control are applied to incoming network data packets.

[0005] Optionally, parsing video frame type information from the network data packets of the received cloud video includes: Obtain connection policy information corresponding to network data packets, wherein the connection policy information includes network 5-tuple and protocol type; The network data packets are parsed according to the protocol type to obtain video frame payload data; The video frame type is identified from the video frame payload data to obtain the video frame type information.

[0006] Optionally, the network data packets are parsed according to the protocol type to obtain video frame payload data, including: When the protocol type is RTMP, RTMPChunk blocks are extracted from network data packets, RTMPChunk blocks are reassembled into RTMPMessage packets, media stream class Message packets are obtained from RTMPMessage packets, and video frame payload data is extracted from media stream class Message packets.

[0007] Optionally, the network data packets are parsed according to the protocol type to obtain video frame payload data, including: When the protocol type is GB28181, RTP format data packets are extracted from network data packets, RTP format data packets with the same RTP timestamp are combined into PS encapsulation packets, and the video frame payload data is extracted from the PS encapsulation packets.

[0008] Optionally, the network data packets are parsed according to the protocol type to obtain video frame payload data, including: When the protocol type is RTSP, RTP format data packets are extracted from network data packets, and RTP format data packets with the same RTP timestamp are combined into frame data. The video frame payload data is extracted from the frame data in FU format.

[0009] Optionally, identifying the video frame type from the video frame payload data includes: Obtain the video encoding format corresponding to the video frame payload data; Locate the frame type identifier field in the video frame payload data according to the video encoding format; The video frame is determined as either an independent decoding frame or a dependent decoding frame based on the value of the frame type identifier field.

[0010] Optionally, obtaining the connection policy information corresponding to the network data packet includes: The connection policy information matching the five-tuple of the network data packet is queried from the eBPFMAP, which is written by the user-space streaming media service module based on the comparison result of the real-time bitrate and the quota bitrate of the push connection.

[0011] Optionally, the data in the eBPFMAP is written by the user-space streaming media service module in the following way: when the real-time bitrate of the push streaming connection exceeds the quota bitrate, backpressure policy information is generated, which includes the network 5-tuple, protocol type and quota bitrate; the new interface of eBPFMAP is called to write the backpressure policy information into eBPFMAP.

[0012] Optionally, when the real-time bitrate of the detected push streaming connection exceeds the quota bitrate, the generation of backpressure strategy information includes: The real-time bitrate of the streaming connection is counted within a preset sliding time window; Compare the real-time bitrate with the quota bitrate; When the real-time bitrate exceeds the quota bitrate and the excess amount reaches a set threshold, the backpressure strategy information is generated.

[0013] This application also discloses an eBPF-based video cloud real-time backpressure system, including: The eBPFXDP data path processing module is used to load the eBPF program at the network data path entry point of the operating system kernel. The eBPF program parses video frame type information from the network data packets of the received cloud video. Based on the video frame type information, it allows network data packets corresponding to independent decoded frames to pass and discards network data packets corresponding to dependent decoded frames. The video frame type information is used to indicate whether a video frame is an independent decoded frame or a dependent decoded frame. The eBPFMAP shared memory communication module is used to store connection policy information containing network quintuples and protocol types for querying by the eBPF program. The user-mode streaming media service module is used to write connection policy information to the eBPFMAP based on the comparison result between the real-time bitrate and the quota bitrate of the push connection.

[0014] As can be seen from the above technical solution, the real-time backpressure method and system for video cloud based on eBPF provided by this invention directly performs video frame type parsing on the data packets received at the network data path entry point of the operating system kernel, instead of first handing them over to the kernel protocol stack for processing and then making a judgment. This entry point is located after the network card driver submits the data packets to the kernel and before the network protocol stack processes them, so that the decision on whether to pass or discard the data packets can be completed before the interrupt context, protocol stack memory allocation, and subsequent user-space data copying consume resources. After obtaining the video frame type information, the method allows the data packets corresponding to the independent decoded frames to pass through, and only discards the data packets corresponding to the dependent decoded frames at this point. The independent decoded frames carry complete image reconstruction information and are the basis for decoding other dependent decoded frames in their frame group. Ensuring that they pass through the kernel protocol stack completely and are delivered to the user-space streaming media service means that no matter what kind of encapsulation or distribution processing the data packets undergo, the receiving end has the necessary conditions to recover the decodeable video frame sequence. The dependent decoded frames are terminated in advance without consuming protocol stack and user-space resources, and the amount of data reduced corresponds to the interrupt processing time, protocol stack memory, and user-space copy bandwidth that would have been allocated. Once allowed, the data packets enter the rate limiting and flow control process, further smoothing out the data traffic entering the upper-layer services within the quota range. The overall effect of the above process is that the interception of over-quota traffic is moved forward to the earliest programmable node in the operating system kernel, and the intercepted objects are limited to frames that depend on decoding. The allowed set always maintains the continuity of the frame structure required for video decoding, thereby simultaneously reducing system resource consumption and maintaining the availability of video services in a single processing flow. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application 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 some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a flowchart of the real-time backpressure method for video cloud based on eBPF in the embodiments of this application; Figure 2 This is a flowchart illustrating the process of parsing video frame type information from network data packets of received cloud video in an embodiment of this application. Figure 3 This is a flowchart illustrating the process of identifying video frame types from the video frame payload data in an embodiment of this application. Figure 4 This is a flowchart illustrating the generation of backpressure strategy information when the real-time bitrate of the detected push stream connection exceeds the quota bitrate, as described in this application embodiment. Figure 5 This is a structural diagram of the real-time backpressure system for video cloud based on eBPF in the embodiments of this application. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not limiting, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without such specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0018] In this application embodiment, a real-time backpressure method for video cloud based on eBPF is provided, such as... Figure 1 As shown, it includes: S100. At the network data path entry point of the operating system kernel, the video frame type information is parsed from the network data packets of the received cloud video. The video frame type information is used to indicate whether the video frame is an independent decoding frame or a dependent decoding frame.

[0019] S200. Based on the video frame type information, allow network data packets corresponding to independent decoded frames to pass through, and discard network data packets corresponding to dependent decoded frames.

[0020] S300 performs rate limiting and flow control on incoming network data packets.

[0021] It should be noted that the execution entity of the above method is the eBPF program running at the entry point of the operating system kernel's network data path. Specifically, the entry point of the operating system kernel's network data path refers to the XDP mount point. This mount point is located after the network card driver receives the data packet and before the kernel network protocol stack processes it; it is one of the earliest programmable intervention points in the Linux network data path. When a data packet is submitted from the network card to the kernel, it first reaches the XDP mount point. At this point, the data packet has not yet undergone the complete kernel interrupt handling process, nor has it undergone memory allocation and parsing operations by the kernel network protocol stack, nor has it experienced memory copying from kernel mode to user mode. Processing the data packet at this location allows for a decision on its destination before the data packet consumes more system resources.

[0022] For example, when a network packet arrives at the network interface card (NIC), the NIC writes the packet to kernel memory via DMA, triggering a hardware interrupt. The kernel interrupt handler responds to the interrupt and retrieves the packet from the NIC queue. At this point, the packet has not yet entered the kernel network protocol stack's processing flow; instead, it is directly passed to the XDP mount point. The eBPF program running at the XDP mount point receives the packet and processes it. After processing, the eBPF program returns a result, which can be XDP_PASS, indicating that the packet is allowed to enter the kernel network protocol stack for further processing, or XDP_DROP, indicating that the packet is discarded without further processing.

[0023] Specifically, parsing video frame type information at the XDP mount point requires the eBPF program to have the ability to parse application layer protocols and video coding layers. In traditional kernel network data processing, application layer protocol parsing is usually done by user-space processes, with the kernel only responsible for processing the protocol headers of the network and transport layers. In this embodiment, the eBPF program parses network data packets layer by layer at the front end of the kernel data path, reconstructing the application layer encapsulation format and video coding layer syntax elements from the network byte stream, thereby identifying the type of video frame.

[0024] Furthermore, rate limiting and flow control of incoming network data packets can be implemented in various ways. For example, flow control rules can be set in the kernel network protocol stack to limit the rate of allowed data packets; alternatively, further flow control can be applied to received data packets in the user-space streaming media service. The purpose of rate limiting and flow control is to ensure that the data traffic entering upper-layer services is smoothly within the user's purchased quota, preventing sudden traffic surges from impacting the system.

[0025] Those skilled in the art will understand that setting the traffic control point at an early programmable location in the operating system kernel's network data path allows the interception action to be moved forward to the beginning of the resource consumption path in a time dimension. Looking at the data packet reception direction, when a data packet is submitted from the network card to the kernel, if the control point is located inside the network protocol stack or the user-space socket layer, the data packet has already consumed system resources such as interrupt handling, protocol stack memory allocation, and context switching before reaching the control point. Discarding it at this point only avoids subsequent storage and processing overhead; it cannot recover the resources already consumed. Setting the control point at the XDP mount point allows the data packet to be evaluated at the first programmable location before entering the kernel protocol stack, determining whether it should continue to be transmitted. This allows unnecessary data packets to be removed before they consume more system resources.

[0026] This application is not limited to this; the specific implementation of the XDP mount point may differ under different operating system versions and kernel configurations. For example, in some kernel versions, the XDP mount point may be located at different stages of the network card driver; in network cards that support hardware offloading, some XDP processing logic can be offloaded to the network card hardware for execution to further improve processing efficiency. Further details are omitted here.

[0027] In alternative implementations, such as Figure 2 As shown, parsing video frame type information from the received cloud video network data packets includes: S101. Obtain connection policy information corresponding to network data packets, wherein the connection policy information includes network 5-tuple and protocol type; S102. Perform protocol parsing on the network data packets according to the protocol type to obtain video frame payload data; S103. Identify the video frame type from the video frame payload data to obtain the video frame type information.

[0028] It should be noted that the network 5-tuple includes the source IP address, destination IP address, source port number, destination port number, and transport layer protocol. Each network connection can be uniquely identified by the network 5-tuple. The connection policy information is generated by the user-space streaming media service module based on the comparison between the real-time bitrate and the quota bitrate of the streaming connection, and is used to instruct the eBPF program on what processing strategy to apply to the data packets of that connection.

[0029] For example, when a new streaming connection is established, the user-space streaming media service module records the network 5-tuple, protocol type, and the user's purchased quota bitrate for that connection. Subsequently, the user-space streaming media service module calculates the real-time bitrate of the connection within a preset sliding time window. When the real-time bitrate exceeds the quota bitrate and the excess reaches a set threshold, the user-space streaming media service module generates connection policy information containing the network 5-tuple, protocol type, and quota bitrate for that connection and writes it to the eBPFMAP. When the eBPF program running at the XDP mount point receives a network data packet, it first extracts the network 5-tuple from the packet and then checks the eBPFMAP for a matching connection policy. If a matching connection policy exists, the packet is parsed according to the protocol type in the connection policy information; otherwise, the packet is allowed to enter the kernel network protocol stack for further processing.

[0030] Specifically, protocol parsing of network data packets requires different parsing processes depending on the streaming protocol. Commonly used streaming protocols in video cloud platforms include RTMP, GB28181, and RTSP. Different protocols have different encapsulation formats and data structures, therefore they need to be parsed separately to extract video frame payload data.

[0031] Furthermore, identifying video frame types from video frame payload data requires locating the frame type identifier field within the video frame payload data according to the syntax rules of the video encoding format. Commonly used video encoding formats include H.264 and H.265. Different encoding formats have different frame type identification methods; therefore, appropriate identification methods must be used based on the specific encoding format.

[0032] Those skilled in the art will understand that simply shifting the interception point forward is insufficient to guarantee the availability of video services. In the video coding structure, independent decoded frames carry complete image information, while dependent decoded frames only encode the differences between them and the reference frame. If data packets are indiscriminately dropped proportionally or randomly at the XDP point, it may disrupt the complete transmission of independent decoded frames, causing the receiver to be unable to reconstruct the correct image for a period of time. This requires that the eBPF program in the XDP context not only be able to examine the fixed offset fields below the transport layer, but also to perform online parsing of the application layer encapsulation format and video coding layer syntax elements to identify the data packet boundaries corresponding to independent and dependent decoded frames from the continuous network byte stream. This parsing process is executed at the very beginning of the kernel data path, running in parallel with the protocol stack's subsequent processing without replacing it. Its role is to obtain the frame type determination criteria while avoiding submitting data packets to the complete protocol stack before determining their destination.

[0033] This application is not limited to these; in addition to the streaming protocols and video encoding formats mentioned above, the embodiments of this application can also be applied to other streaming protocols and video encoding formats. For different protocols and encoding formats, only the protocol parsing process and frame type identification method need to be adjusted accordingly. Further details are omitted here.

[0034] In an optional implementation, the step of parsing the network data packets according to the protocol type to obtain video frame payload data includes: When the protocol type is RTMP, RTMPChunk blocks are extracted from network data packets, RTMPChunk blocks are reassembled into RTMPMessage packets, media stream class Message packets are obtained from RTMPMessage packets, and video frame payload data is extracted from media stream class Message packets.

[0035] It's important to note that RTMP is an application-layer protocol based on TCP, primarily used for real-time transmission of streaming media data. RTMP divides data into multiple chunks for transmission. Each chunk contains a chunk header and a chunk body. The chunk header includes information such as the chunk stream ID, timestamp, message length, and message type; the chunk body contains the actual message data. Multiple chunks can be combined to form a complete RTMPMessage packet.

[0036] For example, when an eBPF program determines that the protocol type corresponding to a network packet is RTMP, it first extracts RTMPChunk chunks from the transport layer payload of the packet. Since RTMP is a TCP-based byte stream protocol, an RTMPChunk chunk may span multiple TCP packets, or a single TCP packet may contain multiple RTMPChunk chunks. Therefore, the eBPF program needs to maintain a state machine to track the chunk reassembly state for each RTMP connection. When the eBPF program receives an RTMPChunk chunk, it first reassembles it with previously received chunk chunks based on information such as the Chunk stream ID and timestamp in the Chunk header, forming a complete RTMPMessage packet.

[0037] Specifically, RTMPMessage packets come in various types, among which the main types related to media streams are video Message packets and audio Message packets. After reassembling the RTMPMessage packets, the eBPF program determines whether the Message packet is a media stream type Message packet based on the Message packet's type field. If it is a video Message packet, the video frame payload data is extracted from the Message packet's body data; if it is an audio Message packet, it can be processed as needed, or it can be allowed to pass directly.

[0038] Furthermore, when extracting video frame payload data, it's crucial to consider the RTMP protocol's encapsulation format for video data. The video message body in the RTMP protocol typically contains a video header and video frame data. The video header includes information such as the video encoding format, frame type, and timestamp; the video frame data contains the actual encoded video data. The eBPF program needs to extract the video frame data portion from the video message body data as the video frame payload data.

[0039] Those skilled in the art will understand that implementing RTMP protocol parsing within an eBPF program in an XDP context requires consideration of the eBPF program's execution environment limitations. eBPF programs run in kernel mode and have strict execution time and memory access restrictions, preventing complex computational operations and long-running blocking operations. Therefore, implementing RTMP protocol parsing requires efficient algorithms and data structures to minimize computational load and memory consumption. For example, fixed-size buffers can be used to store incompletely reassembled chunks, avoiding dynamic memory allocation; hash tables can be used to quickly look up and maintain the reassembly state of each RTMP connection.

[0040] This application is not limited to this. In practical applications, the specific implementation of the RTMP protocol may differ. For example, different vendors may extend and modify the RTMP protocol. For these extensions and modifications, only the protocol parsing process needs to be adjusted accordingly. This will not be elaborated upon here.

[0041] In an optional implementation, the step of parsing the network data packets according to the protocol type to obtain video frame payload data includes: When the protocol type is GB28181, RTP format data packets are extracted from network data packets, RTP format data packets with the same RTP timestamp are combined into PS encapsulation packets, and the video frame payload data is extracted from the PS encapsulation packets.

[0042] It should be noted that the GB28181 protocol is a standard protocol for public security video surveillance networking systems developed in my country, primarily used for interconnection between video surveillance equipment and platforms. The GB28181 protocol uses SIP for signaling interaction and RTP for media data transmission. Before transmission, media data is encapsulated into PS packets, and then further divided into multiple RTP data packets for transmission.

[0043] For example, when the eBPF program determines that the protocol type corresponding to the network data packet is GB28181, it first extracts the RTP format data packet from the transport layer payload of the data packet. The RTP data packet contains an RTP header and an RTP body. The RTP header contains information such as version number, padding bits, extension bits, CSRC count, flag bits, payload type, sequence number, timestamp, and SSRC; the RTP body contains the actual PS encapsulation packet data.

[0044] Specifically, after extracting RTP format packets, the eBPF program determines the media stream to which the RTP packet belongs based on the SSRC value in the RTP header. Then, based on the timestamp in the RTP header, it collects RTP packets with the same timestamp together to form a complete PS encapsulation packet. Since a PS encapsulation packet may be split into multiple RTP packets for transmission, these RTP packets need to be reassembled according to their sequence numbers to obtain the complete PS encapsulation packet.

[0045] Furthermore, the PS (Programmable Streaming Package) is a program stream encapsulation format based on the MPEG-2 standard, used to multiplex multiple audio and video streams and other data together. A PS package contains a PS header and multiple PES (Programmable Streaming Serving) packets. The PS header contains information such as the packet start code, system clock reference, and program multiplexing rate; each PES packet contains a PES header and a PES body, with the PES body containing the actual audio and video data. After reassembling the PS package, the eBPF program needs to parse it, extract the video PES packets, and then extract the video frame payload data from the video PES packet body data.

[0046] Those skilled in the art will understand that implementing GB28181 protocol parsing within an eBPF program in an XDP context also requires consideration of the execution environment limitations of the eBPF program. Similar to RTMP protocol parsing, efficient algorithms and data structures are needed to minimize computation and memory usage. For example, hash tables can be used to quickly look up and maintain the PS encapsulation packet reassembly status for each media stream; fixed-size buffers can be used to store incompletely reassembled RTP packets.

[0047] This application is not limited to this; the GB28181 protocol also supports other media transmission methods and encapsulation formats, such as the TS encapsulation format. For these different transmission methods and encapsulation formats, only the protocol parsing process needs to be adjusted accordingly. Further details are omitted here.

[0048] In an optional implementation, the step of parsing network data packets according to the protocol type to obtain video frame payload data includes: When the protocol type is RTSP, RTP format data packets are extracted from network data packets, and RTP format data packets with the same RTP timestamp are combined into frame data. The video frame payload data is extracted from the frame data in FU format.

[0049] It's important to note that RTSP is an application layer protocol primarily used to control media stream transmission on streaming media servers. RTSP itself does not transmit media data; instead, it transmits media data via the RTP protocol. Similar to the GB28181 protocol, media data in RTSP is also segmented into multiple RTP packets for transmission.

[0050] For example, when the eBPF program determines that the protocol type corresponding to the network packet is RTSP, it first extracts the RTP format packet from the transport layer payload of the packet. Then, based on the SSRC value in the RTP header, it determines the media stream to which the RTP packet belongs. In the RTSP protocol, the SSRC value of the media stream is usually negotiated and determined during signaling interaction. Therefore, the eBPF program needs to cooperate with the user-space streaming media service module to obtain the SSRC value corresponding to each media stream to ensure the legitimacy of the media channel's RTP.

[0051] Specifically, after extracting and verifying the validity of RTP format data packets, the eBPF program collects RTP packets with the same timestamp according to the timestamp in the RTP header to form a frame of data. For video encoding formats such as H.264 and H.265, a frame of video data may be divided into multiple RTP packets for transmission. These RTP packets have the same timestamp but different sequence numbers. Therefore, these RTP packets need to be reassembled according to the sequence number order to obtain a complete frame of data.

[0052] Furthermore, in the RTSP protocol, video data is typically encapsulated using the FU format. The FU format is an encapsulation format used to segment a single video frame into multiple RTP packets. An FU-formatted RTP packet contains an FU header and an FU body. The FU header contains information such as start bits, end bits, and NAL unit type; the FU body contains the actual video frame data segment. After reassembling a frame of data, the eBPF program needs to parse the frame data according to the FU format to extract the video frame payload data.

[0053] Those skilled in the art will understand that implementing RTSP protocol parsing within an eBPF program in an XDP context also requires consideration of the eBPF program's execution environment limitations. Efficient algorithms and data structures are needed to minimize computational load and memory consumption. For example, hash tables can be used to quickly look up and maintain the reassembly status of each media stream's frame data; fixed-size buffers can be used to store incompletely reassembled RTP packets.

[0054] This application is not limited to this; the RTSP protocol also supports other media transmission methods and encapsulation formats, such as TCP transmission. For these different transmission methods and encapsulation formats, only the protocol parsing process needs to be adjusted accordingly. Details will not be elaborated here.

[0055] In alternative implementations, such as Figure 3 As shown, identifying the video frame type from the video frame payload data includes: S1031. Obtain the video encoding format corresponding to the video frame payload data; S1032. Locate the frame type identifier field in the video frame payload data according to the video encoding format; S1033. Determine whether the video frame is an independent decoding frame or a dependent decoding frame based on the value of the frame type identifier field.

[0056] It should be noted that the video encoding format determines the syntax structure of the video frame payload data and the frame type identification method. Different video encoding formats have different frame type definitions and identification methods. Commonly used video encoding formats include H.264 and H.265.

[0057] For example, in the H.264 encoding format, video frames are organized into multiple NAL units. Each NAL unit contains a NAL header and a NAL body. The lower 5 bits of the first byte of the NAL header indicate the NAL unit type. NAL unit type 5 indicates an IDR frame, a special type of independent decoded frame. Its appearance signifies that all previous reference frames are no longer valid, and the decoder can start decoding from the IDR frame. NAL unit type 1 indicates a non-IDR frame slice. A non-IDR frame slice may be a P-frame or a B-frame. Both P-frames and B-frames are dependent decoded frames, requiring reference to previous frames for decoding.

[0058] Specifically, after the eBPF program obtains the video frame payload data, it first determines the video encoding format corresponding to the payload data based on the information obtained during the previous protocol parsing process. Then, according to the syntax rules of that video encoding format, it locates the frame type identifier field in the payload data. For example, for the H.264 encoding format, the frame type identifier field is located in the lower 5 bits of the first byte of the NAL header. Finally, based on the value of the frame type identifier field, it determines whether the video frame is an independent decoding frame or a decoding-dependent frame.

[0059] Furthermore, for the H.265 encoding format, video frames are also organized into multiple NAL units. Each NAL unit contains a NAL header and a NAL body. The lower 6 bits of the first byte of the NAL header indicate the NAL unit type. NAL unit types 19 to 21 indicate IDR frames, which are independently decoded frames; NAL unit types 0 to 9 indicate slices of non-IDR frames, which are dependently decoded frames.

[0060] Those skilled in the art will understand that after obtaining frame type information, allowance and discard rules can be set separately. Data packets corresponding to independently decoded frames are allowed to enter the subsequent processing path, while data packets corresponding to frames dependent on decoded frames are terminated at the XDP layer. The effect of this differentiated operation is that, from the perspective of the entire link, although the total amount of data entering the system is reduced, the set of data packets entering the upper-layer protocol stack and user-space services always contains the basic frame sequence that maintains the continuity of video decoding, and there will be no picture anomalies caused by missing keyframes.

[0061] This application is not limited to these; in addition to the H.264 and H.265 encoding formats mentioned above, the embodiments of this application can also be applied to other video encoding formats. For different encoding formats, only the positioning method and recognition rules of the frame type identifier field need to be adjusted accordingly. Further details are omitted here.

[0062] In an optional implementation, obtaining the connection policy information corresponding to the network data packet includes: querying the connection policy information that matches the five-tuple of the network data packet from the eBPFMAP, wherein the eBPFMAP is written by the user-mode streaming media service module based on the comparison result of the real-time bitrate and the quota bitrate of the push connection.

[0063] It should be noted that eBPFMAP is a data sharing mechanism provided by eBPF technology between kernel mode and user mode. eBPFMAP is a key-value pair storage structure that allows data read and write operations between kernel mode and user mode. User-mode processes can write data to eBPFMAP via system calls, and kernel-mode eBPF programs can directly read data from eBPFMAP, and vice versa.

[0064] For example, when the user-space streaming media service module detects that the real-time bitrate of a streaming connection exceeds the quota bitrate and the excess reaches a set threshold, it generates connection policy information containing the connection's network 5-tuple, protocol type, and quota bitrate. Then, the user-space streaming media service module writes this connection policy information into the eBPFMAP via an eBPF system call. Upon receiving a network data packet, the eBPF program running at the XDP mount point first extracts the packet's network 5-tuple, then uses this 5-tuple as the key to query the eBPFMAP. If a matching connection policy is found, the data packet is processed according to that policy; otherwise, the data packet is allowed to enter the kernel network protocol stack for further processing.

[0065] Specifically, the type of eBPFMAP can be selected according to actual needs. Commonly used eBPFMAP types include hash table MAP, array MAP, and queue MAP. In this embodiment, since it is necessary to quickly query connection policy information based on the network 5-tuple, a hash table type eBPFMAP can be selected. Hash table MAP has a query time complexity of O(1), which can meet the real-time requirements of XDP mount point for packet processing.

[0066] Furthermore, to ensure the consistency and validity of data in the eBPFMAP, the user-space streaming media service module needs to dynamically manage the data in the eBPFMAP. When a streaming connection is disconnected, the user-space streaming media service module needs to delete the connection policy information corresponding to that connection from the eBPFMAP; when the user-space streaming media service module restarts, it needs to clear all connection policy information in the eBPFMAP and then redeploy it.

[0067] Those skilled in the art will understand that, when observed in combination, the three technical features described above define a data processing framework. This framework establishes a control plane at the boundary between the network interface card (NIC) and the kernel protocol stack, possessing both protocol awareness and frame structure awareness capabilities. This control plane, on the one hand, makes a pass / fail decision with packet-level temporal precision before resource occupancy occurs; on the other hand, through frame-level semantic differentiation, it ensures that traffic reduction is not randomly applied to a set of packets, but rather to a pre-determined set of dependent decoding frames. The superposition of these two effects is not a linear extension of the result obtained by arbitrarily selecting two of the interception location, parsing depth, and dropping policy, but rather a holistic behavior formed by the sequential enabling of the three features and the progressive transmission of decision information.

[0068] This application is not limited to this; in practical applications, the specific implementation and usage of eBPFMAP may differ. For example, multiple eBPFMAPs can be used to store different types of information; other features of eBPFMAP, such as batch operations and atomic operations, can also be used to improve the efficiency and consistency of data reading and writing. These will not be elaborated upon here.

[0069] In an optional implementation, the data in the eBPFMAP is written by the user-space streaming media service module in the following way: when the real-time bitrate of the push stream connection is detected to exceed the quota bitrate, backpressure policy information is generated, which includes the network 5-tuple, protocol type and quota bitrate; the new interface of eBPFMAP is called to write the backpressure policy information into eBPFMAP.

[0070] It should be noted that the user-mode streaming media service module is one of the core components of the video cloud platform, responsible for handling functions such as push streaming connections, parsing media stream protocols, transcoding media data, distributing media streams, and storing media data. In this embodiment, the user-mode streaming media service module is also responsible for detecting the real-time bitrate of the push streaming connection, generating backpressure strategy information, and writing it into the eBPFMAP.

[0071] For example, when a new streaming connection is established, the user-space streaming media service module creates a connection context to store relevant information such as the network 5-tuple, protocol type, user-purchased quota bitrate, and real-time bitrate statistics. Then, the user-space streaming media service module calculates the real-time bitrate of the connection within a preset sliding time window. The size of the sliding time window can be set according to actual needs, for example, it can be set to 1 minute. Within the sliding time window, the user-space streaming media service module counts the number of bytes received for the connection at regular intervals and calculates the real-time bitrate.

[0072] Specifically, when the user-space streaming media service module detects that the real-time bitrate of a certain streaming connection exceeds the quota bitrate and the excess reaches a set threshold, it generates backpressure policy information. The backpressure policy information includes the network 5-tuple, protocol type, and quota bitrate for that connection. Then, the user-space streaming media service module calls the eBPFMAP's add interface to write the backpressure policy information into the eBPFMAP. Before writing, the user-space streaming media service module first checks whether the backpressure policy information corresponding to that connection already exists in the eBPFMAP. If it already exists, it returns success directly; otherwise, it writes the backpressure policy information into the eBPFMAP.

[0073] In addition, the user-space streaming media service module also needs to dynamically manage the backpressure policy information in the eBPFMAP. When the real-time bitrate of a certain streaming connection returns to the normal range, the user-space streaming media service module needs to delete the backpressure policy information corresponding to that connection from the eBPFMAP; when a streaming connection is disconnected, the user-space streaming media service module also needs to delete the backpressure policy information corresponding to that connection from the eBPFMAP; when the user-space streaming media service module restarts, it needs to clear all backpressure policy information in the eBPFMAP and then redeploy it.

[0074] Those skilled in the art will understand that the user-mode streaming media service module and the kernel-mode eBPF program communicate via eBPFMAP, achieving linkage between the service layer and the kernel layer. The user-mode streaming media service module possesses rich service information and protocol parsing capabilities, enabling it to accurately detect the real-time bitrate of the push streaming connection and generate corresponding backpressure policy information; the kernel-mode eBPF program possesses high-performance packet processing capabilities, enabling rapid processing of packets at the XDP mount point. The combination of these two ensures both the accuracy and flexibility of the backpressure policy, as well as high performance and low latency in packet processing.

[0075] This application is not limited to this. In practical applications, other methods can be used for communication between the user-space streaming media service module and the kernel-space eBPF program, such as netlink sockets. However, eBPFMAP has higher communication efficiency and lower latency, making it more suitable for the application scenarios of this application. Further details will not be elaborated here.

[0076] In alternative implementations, such as Figure 4 As shown, when the real-time bitrate of the detected push streaming connection exceeds the quota bitrate, the generated backpressure strategy information includes: S10111. Calculate the real-time bitrate of the streaming connection within a preset sliding time window; S10112. Compare the real-time bitrate with the quota bitrate; S10113. When the real-time bitrate exceeds the quota bitrate and the excess amount reaches a set threshold, the back pressure strategy information is generated.

[0077] It's important to note that the sliding window is a commonly used traffic statistics method. It smoothly tracks traffic over a period of time, avoiding the impact of sudden traffic spikes on the results. The size of the sliding window and the sliding step can be set according to actual needs. For example, the sliding window size can be set to 1 minute, and the sliding step to 10 seconds. This way, every 10 seconds, the traffic over the past minute will be tracked, and the real-time bitrate will be calculated.

[0078] For example, suppose a user's purchased quota bitrate is 2Mbps and the set threshold is 10%. When the user-space streaming media service module detects a real-time bitrate of 2.3Mbps for a certain streaming connection within a sliding time window, the proportion of the real-time bitrate exceeding the quota bitrate is 15%, which exceeds the set threshold of 10%. At this time, the user-space streaming media service module will generate the backpressure policy information corresponding to the connection and write it into the eBPFMAP.

[0079] Specifically, when calculating the real-time bitrate of a streaming connection, the user-space streaming media service module needs to count all bytes received by that connection within the sliding time window, including video data, audio data, and protocol header data. Then, the total number of received bytes is divided by the size of the sliding time window to obtain the real-time bitrate. The unit for real-time bitrate is typically bps or Mbps.

[0080] Furthermore, setting a threshold aims to avoid frequent triggering and cancellation of the backpressure policy. If the threshold is set too low, the backpressure policy will be frequently triggered and cancelled when the real-time bitrate fluctuates around the quota bitrate, leading to system instability. If the threshold is set too high, the backpressure policy will only be triggered when the real-time bitrate significantly exceeds the quota bitrate, resulting in excessive consumption of system resources. Therefore, the threshold setting needs to be adjusted based on actual business needs and system conditions.

[0081] Those skilled in the art will understand that, when the video cloud streaming bitrate exceeds the user's quota, the technical problem this application aims to solve is how to reduce the excessive traffic's consumption of operating system computing resources, network resources, and memory resources while ensuring the availability of the user's video service. Common user-space application-layer rate limiting schemes accept data packets into user space before discarding them. At this point, each data packet has already undergone complete processing by the network card driver, kernel interrupt, protocol stack parsing, and memory copying from the kernel to user space, resulting in resource consumption. Although the kernel TC rate limiting scheme advances the protocol stack processing path, it still occurs after the interrupt and protocol stack processing, failing to intercept traffic at an early stage. Furthermore, both schemes are unaware of the data packet content, employing random or statistically driven discarding methods without distinguishing video frame types. This application's embodiment achieves a smaller resource consumption window by moving the interception point forward to XDP, then establishing frame type awareness within this window, and finally implementing differentiated forwarding based on the awareness results. The combined effect of these three steps is that, at an earlier programmable point when a single data packet arrives, it can determine whether it continues to consume interrupt and protocol stack resources, while ensuring that the allow set always contains the necessary information to maintain video decodeability. This effect cannot be achieved by simply moving the interception point forward and omitting frame awareness, nor can it be achieved by only parsing the frame type in user space without changing the interception position, because the former would impair service availability, and the latter cannot avoid the problem of resources being consumed before interception.

[0082] This application is not limited to this. In practical applications, other traffic statistics methods can also be used, such as fixed-time-window statistics and exponentially weighted moving average statistics. Different statistical methods have different characteristics and applicable scenarios, and can be selected according to actual needs. These will not be elaborated upon here.

[0083] In this application embodiment, a real-time backpressure system for video cloud based on eBPF is also provided, such as... Figure 5 As shown, it includes: The eBPFXDP data path processing module 11 is used to load the eBPF program at the network data path entry point of the operating system kernel. The eBPF program parses the video frame type information from the network data packets of the received cloud video. According to the video frame type information, the network data packets corresponding to independent decoding frames are allowed to pass, and the network data packets corresponding to dependent decoding frames are discarded. The video frame type information indicates whether the video frame is an independent decoding frame or a dependent decoding frame. eBPFMAP shared memory communication module 12 is used to store connection policy information including network quintuples and protocol types for querying by the eBPF program; User-mode streaming media service module 13 is used to write connection strategy information to the eBPFMAP based on the comparison result between the real-time bitrate and the quota bitrate of the streaming connection.

[0084] It should be noted that this system adopts a layered architecture design, divided into a user-mode layer and a kernel-mode layer. The user-mode layer mainly includes the user-mode streaming media service module, which is responsible for business logic processing and backpressure strategy generation; the kernel-mode layer mainly includes the eBPFXDP data path processing module and the eBPFMAP shared memory communication module, which are responsible for high-performance packet processing and data communication between kernel-mode and user-mode.

[0085] For example, the eBPFXDP data path processing module runs in the operating system kernel mode, and its core is an eBPF program loaded on the XDP mount point. This eBPF program is loaded into the kernel by a user-mode process during system startup and mounted on the specified network interface card's XDP mount point. When a network packet arrives at this network interface card, the eBPF program is triggered to execute and process the packet.

[0086] Specifically, the eBPFMAP shared memory communication module is implemented based on eBPFMAP, providing a data sharing channel between the user-space streaming media service module and the kernel-space eBPF program. The user-space streaming media service module can write connection policy information to the eBPFMAP via eBPF system calls, and the kernel-space eBPF program can directly read connection policy information from the eBPFMAP. The eBPFMAP shared memory communication module also provides interfaces for adding backpressure policies, clearing the backpressure pool, and deleting specified backpressure policies, which can be called by the user-space streaming media service module.

[0087] Furthermore, the user-space streaming media service module runs in the operating system's user space and is a core business component of the video cloud platform. It is responsible for handling push streaming connections, parsing media stream protocols, transcoding media data, distributing media streams, and storing media data. Simultaneously, it is also responsible for detecting the real-time bitrate of the push streaming connection, generating backpressure strategy information, and writing it into the eBPFMAP. The user-space streaming media service module is also responsible for notifying the playback end to enable dynamic frame interpolation for smooth playback, thereby improving the user experience.

[0088] Those skilled in the art will understand that the various modules of this system collaborate to complete the real-time backpressure function for the video cloud. The user-mode streaming media service module detects the real-time bitrate of the push connection. When the real-time bitrate exceeds the quota bitrate, it generates backpressure policy information and writes it into the eBPFMAP. The eBPFXDP data path processing module reads the backpressure policy information from the eBPFMAP, performs protocol parsing and frame type identification on data packets that meet the conditions, and then performs differentiated allowance and drop operations based on the frame type. In this way, the system resource consumption of excessive traffic can be reduced while ensuring the availability of user video services.

[0089] This application is not limited to this. In practical applications, this system may also include other modules, such as a monitoring module and a logging module. The monitoring module is used to monitor the system's operating status and performance indicators, such as packet processing rate, packet loss rate, and CPU utilization; the logging module is used to record the system's operating logs and error information to facilitate troubleshooting and system maintenance. Further details are omitted here.

[0090] In this embodiment, the eBPFXDP data path processing module periodically monitors the bitrate of the streaming connection when executing the backpressure strategy. When the bitrate of the streaming connection returns to the normal range, the eBPFXDP data path processing module notifies the user-mode streaming media service module, which then deletes the backpressure strategy information corresponding to that connection from the eBPFMAP, thereby canceling the backpressure execution strategy.

[0091] It's important to note that the bitrate of a push streaming connection may fluctuate due to user reconfiguration of encoding parameters, changes in network conditions, or other factors. Once the bitrate of the push streaming connection returns to a normal range, continuing to implement the backpressure strategy will lead to unnecessary bandwidth reduction, impacting user experience. Therefore, it's necessary to monitor the bitrate of the push streaming connection regularly, and promptly cancel the backpressure strategy once the bitrate returns to normal.

[0092] For example, the eBPFXDP data path processing module can statistically analyze the bitrate of each streaming connection implementing the backpressure strategy at regular time intervals. The statistical method can employ a sliding time window approach, similar to the method used by the user-space streaming media service module. When the bitrate of a streaming connection is found to be lower than the quota bitrate for multiple consecutive sliding time windows, it is considered that the bitrate of that connection has returned to the normal range. At this time, the eBPFXDP data path processing module will send a notification message to the user-space streaming media service module via eBPFMAP, informing them that the bitrate of that connection has returned to normal. Upon receiving the notification message, the user-space streaming media service module will delete the backpressure strategy information corresponding to that connection from eBPFMAP, thereby canceling the backpressure execution strategy.

[0093] Specifically, the notification mechanism between the eBPFXDP data path processing module and the user-space streaming media service module can be implemented through eBPFMAP. For example, a dedicated notification field can be set in eBPFMAP. When the eBPFXDP data path processing module needs to notify the user-space streaming media service module, this notification field is set to the corresponding value. The user-space streaming media service module will periodically poll the notification field in eBPFMAP, and when a notification message is detected, it will perform the appropriate processing.

[0094] In addition, to ensure the reliability of the notification mechanism, an acknowledgment mechanism can be adopted. Once the user-mode streaming media service module receives the notification message and completes the corresponding processing, it sets the notification field to an acknowledgment value. The eBPFXDP data path processing module periodically checks the acknowledgment value of the notification field; if no acknowledgment is received within a certain time, the notification message is resent.

[0095] Those skilled in the art will understand that by periodically monitoring the bitrate of the streaming connection and promptly canceling the backpressure strategy, the system can be made more flexible and intelligent, ensuring the rational use of system resources while maximizing user experience. When the bitrate of the streaming connection is high, the backpressure strategy is executed to reduce system resource consumption; when the bitrate of the streaming connection returns to normal, the backpressure strategy is canceled, and normal media stream transmission is restored.

[0096] This application is not limited to this. In practical applications, other notification mechanisms can also be used, such as the netlink socket notification mechanism. Different notification mechanisms have different characteristics and applicable scenarios, and can be selected according to actual needs. These will not be elaborated upon here.

[0097] In this embodiment, after executing the backpressure strategy, the user-mode streaming media service module notifies the playback end to enable dynamic frame interpolation for smooth playback. Dynamic frame interpolation is a technique that generates intermediate frames at the playback end using algorithms to improve the smoothness of video playback.

[0098] It's important to note that when the backpressure strategy is implemented, the media stream only contains independent decoded frames and not dependent decoded frames. In this case, if the playback device directly plays the media stream, skipping frames will occur, impacting the user experience. To solve this problem, the playback device can enable dynamic frame interpolation technology, generating intermediate frames based on adjacent independent decoded frames, thus making video playback smoother.

[0099] For example, after receiving a notification from the user-mode streaming media service module to enable dynamic frame interpolation, the playback client will initiate the dynamic frame interpolation algorithm. The algorithm analyzes the motion information between two adjacent independent decoded frames and then generates an intermediate frame based on this motion information. This intermediate frame is inserted between the two independent decoded frames, thereby increasing the video's frame rate and making playback smoother.

[0100] Specifically, there are various dynamic frame interpolation algorithms, such as motion estimation-based interpolation algorithms and deep learning-based interpolation algorithms. Motion estimation-based interpolation algorithms calculate motion vectors between adjacent frames and then generate intermediate frames based on these vectors. Deep learning-based interpolation algorithms train a neural network model to learn the mapping relationships between video frames and then generate intermediate frames based on the neural network model. Different algorithms have different effects and computational complexities, and the choice can be made based on the hardware performance of the playback device and user needs.

[0101] Furthermore, dynamic frame interpolation technology is executed only on the playback end and does not consume cloud platform system resources. Therefore, while ensuring user experience, it does not increase the resource overhead of the cloud platform.

[0102] Those skilled in the art will understand that by enabling dynamic frame interpolation technology on the playback end, the problem of video playback skipping after implementing a backpressure strategy can be effectively solved, thus improving the user experience. Furthermore, since dynamic frame interpolation technology is only executed on the playback end and does not increase the resource overhead of the cloud platform, it can maintain the cloud platform's resource costs within a reasonable range while ensuring a good user experience.

[0103] This application is not limited to this. In practical applications, other playback optimization technologies, such as frame rate conversion technology and video enhancement technology, can also be used to further improve the user experience. These will not be elaborated upon here.

[0104] In this embodiment, the eBPFXDP data path processing module maintains the parsing state of each connection when performing protocol parsing on network packets. Since network packets arrive sequentially, maintaining the parsing state is necessary to process protocol data units spanning multiple packets.

[0105] It's important to note that for TCP-based application layer protocols, such as RTMP, data is transmitted as a byte stream, and a single protocol data unit may span multiple TCP packets. Therefore, when parsing protocol data, a parsing state machine needs to be maintained to record the current parsing position and state, so that parsing can continue when subsequent packets arrive.

[0106] For example, for RTMP protocol parsing, the eBPFXDP data path processing module maintains a parsing state for each RTMP connection. The parsing state includes information about the currently reassembled RTMP chunk, the number of bytes received, and the parsing status of the chunk header. When a new TCP packet arrives, the eBPF program continues parsing the RTMP chunk based on the connection's parsing state. If the packet contains a complete RTMP chunk, it parses the chunk and updates the parsing state; if the packet contains only a portion of an RTMP chunk, that portion is saved to a buffer, the parsing state is updated, and parsing continues until subsequent packets arrive.

[0107] Specifically, to maintain the resolution state, the eBPFXDP data path processing module needs to use an eBPFMAP to store the resolution state information for each connection. For example, a hash table-type eBPFMAP can be used, with the network 5-tuple as the key and the resolution state structure as the value. When a new connection is established, a new resolution state entry is created in the eBPFMAP; when a connection is closed, the corresponding resolution state entry is deleted from the eBPFMAP.

[0108] In addition, to prevent the resolution state entries in eBPFMAP from growing indefinitely, a timeout mechanism needs to be set. If no packets arrive for a connection within a certain period of time, the connection is considered closed, and the corresponding resolution state entry is deleted from eBPFMAP.

[0109] Those skilled in the art will understand that maintaining the parsing state is crucial for implementing application layer protocol parsing in an eBPF procedure within an XDP context. By maintaining the parsing state, protocol data units spanning multiple data packets can be correctly parsed, thereby accurately extracting video frame payload data and frame type information.

[0110] This application is not limited to this. For UDP-based application layer protocols, such as GB28181 and RTSP, although data is transmitted in datagrams, a video frame may be segmented into multiple UDP packets for transmission. Therefore, it is also necessary to maintain the parsing state to reassemble the complete video frame. This will not be elaborated upon here.

[0111] In this embodiment, the eBPFXDP data path processing module uses the XDP_DROP action when performing a packet dropping operation. The XDP_DROP action directly drops the packet without further processing by the kernel network protocol stack.

[0112] It's important to note that the XDP_DROP action is a processing outcome supported by the XDP program. When the eBPF program returns XDP_DROP, the kernel directly releases the memory of the data packet, without passing it to the kernel network protocol stack. This prevents the data packet from consuming subsequent interrupt handling, protocol stack parsing, and memory copying system resources.

[0113] For example, when an eBPF program parses a network packet and determines that the corresponding video frame is a dependent decoding frame, it returns an XDP_DROP action. Upon receiving the XDP_DROP action, the kernel directly releases the memory of the packet without further processing. This prevents the packet from entering the kernel network protocol stack and from being passed to the user-space streaming media service module, thus avoiding the consumption of system resources.

[0114] Specifically, the XDP_PASS action corresponds to the XDP_DROP action. When the eBPF program returns XDP_PASS, the kernel passes the data packet to the kernel network protocol stack for further processing. When the eBPF program parses a network data packet and determines that the corresponding video frame is an independent decoded frame, it returns the XDP_PASS action, allowing the data packet to enter the kernel network protocol stack for further processing.

[0115] In addition, the XDP program supports other processing results, such as XDP_TX and XDP_REDIRECT. The XDP_TX action sends the data packet out of the receiving network card; the XDP_REDIRECT action redirects the data packet to another network card or socket. In the embodiments of this application, the XDP_DROP and XDP_PASS actions are mainly used.

[0116] Those skilled in the art will understand that using the XDP_DROP action to drop packets can remove them before they consume more system resources, thereby effectively reducing system resource usage. Compared to traditional methods of dropping packets in user space or late in the kernel protocol stack, the XDP_DROP action can save more system resources and improve overall system performance.

[0117] This application is not limited to this. In practical applications, other processing results supported by the XDP program can be used as needed. For example, the XDP_REDIRECT action can be used to redirect packets to a dedicated processing queue for further processing. Details will not be elaborated here.

[0118] In this embodiment of the application, when the user-mode streaming media service module calculates the real-time bitrate of the streaming connection, it counts the number of bytes of all data packets received by the connection, including data packets allowed by the eBPFXDP data path processing module and data packets that are dropped.

[0119] It should be noted that data packets dropped by the eBPFXDP data path processing module at the XDP mount point are not transmitted to the user-space streaming media service module. Therefore, the user-space streaming media service module cannot directly count the number of bytes in the dropped data packets. In order to accurately count the real-time bitrate of the streaming connection, the user-space streaming media service module needs to cooperate with the eBPFXDP data path processing module to obtain the number of bytes in the dropped data packets.

[0120] For example, the eBPFXDP data path processing module can maintain packet loss statistics for each connection in the eBPFMAP. When the eBPF program drops a data packet, it adds the number of bytes in that packet to the packet loss statistics for the corresponding connection. The user-space streaming media service module periodically reads the packet loss statistics for each connection from the eBPFMAP, then adds it to its own count of received bytes to obtain the total number of bytes for that connection. Finally, the real-time bitrate is calculated based on the total number of bytes.

[0121] Specifically, packet loss statistics can be stored in a dedicated eBPFMAP, such as a hash table-type eBPFMAP, using the network 5-tuple as the key and the number of bytes lost as the value. When the eBPF program drops a data packet, it uses the network 5-tuple of that data packet as the key to look up the corresponding entry for the number of bytes lost in the eBPFMAP and adds the number of bytes lost to that entry. The user-space streaming media service module will read the packet loss statistics in the eBPFMAP at regular intervals and clear it to zero in order to perform statistics for the next time period.

[0122] Furthermore, to ensure the accuracy of the statistical results, atomic operations are required on the packet loss statistics in the eBPFMAP. Because the eBPF program runs in kernel mode, multiple CPU cores may execute the eBPF program simultaneously, updating the packet loss statistics for the same connection. Therefore, atomic operations are necessary to avoid race conditions and guarantee the accuracy of the statistical results.

[0123] Those skilled in the art will understand that accurately calculating the real-time bitrate of the push streaming connection is fundamental to generating a correct backpressure strategy. Inaccurate real-time bitrate calculations may lead to the incorrect triggering or cancellation of the backpressure strategy, impacting system performance and user experience. By cooperating with the user-space streaming media service module and the eBPFXDP data path processing module to count the number of bytes of dropped data packets, the real-time bitrate of the push streaming connection can be accurately calculated, thereby generating a correct backpressure strategy.

[0124] This application is not limited to this; in practical applications, other methods can also be used to count the real-time bitrate of streaming connections. For example, the number of bytes received for each connection can be counted in the network card driver, and then the statistical information can be passed to the user-space streaming media service module. Further details are omitted here.

[0125] In this embodiment, the eBPFXDP data path processing module performs a validity check on network data packets during protocol parsing. If a data packet is invalid, it is discarded without further processing.

[0126] It's important to note that malicious or malformed data packets may exist on the network. If these packets are passed to the kernel network protocol stack or user-space streaming media service modules, they could cause system crashes or security vulnerabilities. Therefore, during protocol parsing, it's necessary to perform validity checks on data packets and filter out invalid ones.

[0127] For example, when parsing the RTMP protocol, the eBPF program checks whether the RTMP Chunk format is correct. This includes checking if the Chunk stream ID is within a valid range, if the message length matches the actual received data length, and if the message type is a known type. If an incorrect RTMP Chunk format is found, the packet is discarded without further processing.

[0128] Specifically, when parsing the GB28181 protocol, the eBPF program checks whether the RTP packet format is correct. For example, it checks if the RTP version number is 2, if the payload type is a valid media payload type, and if the SSRC value is consistent with the previously negotiated value. If an incorrect RTP packet format is found, the packet is discarded without further processing.

[0129] In addition, when parsing video frame payload data, the eBPF program also performs a validity check on the video frame format. For example, it checks whether the video encoding format is supported and whether the value of the frame type identifier field is within a valid range. If an incorrect video frame format is found, the data packet is discarded without further processing.

[0130] Those skilled in the art will understand that performing validity checks on data packets can improve system stability and security. By filtering out invalid data packets, the adverse effects of these packets on the system can be avoided, ensuring the normal operation of the system.

[0131] This application is not limited to this. In practical applications, other legality checks can be added as needed to further improve the stability and security of the system. These will not be elaborated upon here.

[0132] In this embodiment, the eBPFXDP data path processing module performs version and compatibility checks when loading the eBPF program. If the kernel version does not support the eBPFXDP function, or the eBPF program is incompatible with the kernel version, loading will fail and return the corresponding error message.

[0133] It's important to note that the eBPFXDP feature was introduced in a later version of the Linux kernel. Different kernel versions have varying levels of support for eBPFXDP. Therefore, before loading an eBPF program, it's necessary to check if the kernel version supports eBPFXDP and whether the eBPF program is compatible with the kernel version.

[0134] For example, before loading an eBPF program, the user-space process reads the kernel version information and checks if the kernel version meets the minimum requirements. For instance, the eBPFXDP feature was introduced in Linux kernel version 4.8 and later, so it's necessary to check if the kernel version is greater than or equal to 4.8. If the kernel version is lower than 4.8, the eBPF program cannot be loaded, and the user needs to be prompted to upgrade the kernel.

[0135] Specifically, when loading an eBPF program, the kernel verifies it. This verification includes checking the legality of the eBPF program's instructions, the presence of security vulnerabilities, and compliance with kernel execution environment restrictions. If the eBPF program fails verification, loading will fail, and an appropriate error message will be returned. The user-space process will then modify the eBPF program based on the error message and reload it.

[0136] Furthermore, to improve the compatibility of eBPF programs, cross-version compilation techniques can be used. For example, the BPF Compiler Collection toolset can be used to compile eBPF programs, generating eBPF bytecode that can run on multiple kernel versions.

[0137] Those skilled in the art will understand that performing version checks and compatibility checks ensures that eBPF programs run correctly in different kernel environments. If the kernel version does not support the eBPFXDP feature, or if the eBPF program is incompatible with the kernel version, the eBPF program will fail to load and run properly, causing the entire system to malfunction.

[0138] This application is not limited to this; in practical applications, other methods can be used to improve the compatibility of eBPF programs. For example, multiple versions of the eBPF program can be provided, each suitable for different kernel versions. These will not be elaborated upon here.

[0139] In this embodiment, the user-space streaming media service module performs deduplication when writing connection policy information to the eBPFMAP. If the connection policy information corresponding to the connection already exists in the eBPFMAP, it will not be written again.

[0140] It should be noted that the user-space streaming media service module may generate the same backpressure policy information for a connection multiple times for various reasons. Writing this information to the eBPFMAP each time would result in duplicate data in the eBPFMAP, increasing the query time of the eBPF program and impacting system performance. Therefore, deduplication is necessary before writing the connection policy information.

[0141] For example, when the user-space streaming media service module generates backpressure policy information for a connection, it first checks whether the corresponding connection policy information already exists in the eBPFMAP. The query method uses the network 5-tuple of the connection as the key to search within the eBPFMAP. If the search result is not empty, it means that the corresponding connection policy information already exists in the eBPFMAP, and it will not be written again; if the search result is empty, it means that the corresponding connection policy information does not exist in the eBPFMAP, and the connection policy information will be written into the eBPFMAP.

[0142] Specifically, to ensure the atomicity of deduplication, atomic operations of eBPFMAP are required. Because multiple threads in the user-space streaming media service module may simultaneously write data to eBPFMAP, this could lead to race conditions. Therefore, atomic operations are needed to guarantee the correctness of deduplication. For example, the lookup_and_delete atomic operation of eBPFMAP can be used, or a spinlock can be used to protect eBPFMAP read and write operations.

[0143] In addition, the user-space streaming media service module also needs to perform a check when deleting connection policy information from the eBPFMAP. If the connection policy information corresponding to the connection does not exist in the eBPFMAP, it will directly return success and will not perform the deletion operation.

[0144] Those skilled in the art will understand that deduplication can prevent data duplication in the eBPFMAP, improve the query efficiency of eBPF programs, and thus improve the overall performance of the system. At the same time, it can also reduce the memory footprint of the eBPFMAP and prevent memory overflow.

[0145] This application is not limited to this; in practical applications, other methods can also be used for deduplication. For example, a local connection policy information cache can be maintained in the user-space streaming media service module, deduplication can be performed in the local cache first, and then the information can be written into the eBPFMAP. Further details are omitted here.

[0146] In this embodiment, the eBPFXDP data path processing module prioritizes high-priority data packets when processing network data packets. For example, audio data packets have a higher priority than video data packets, and signaling data packets have a higher priority than media data packets.

[0147] It's important to note that in video cloud platforms, different types of data packets have different priorities. Audio data packets are more sensitive to latency and packet loss; if audio data packets are lost or experience excessive latency, the sound heard by the user will be intermittent, affecting the user experience. Signaling data packets are used to control the transmission of media streams; if signaling data packets are lost or experience excessive latency, the media stream may fail to establish properly or be interrupted. Therefore, high-priority data packets need to be processed first to ensure their transmission quality.

[0148] For example, when an eBPF program receives a network data packet, it first determines the type of the packet. If it is a signaling data packet, it is allowed to pass directly and enters the kernel network protocol stack for further processing; if it is an audio data packet, it is processed first to ensure that it can pass quickly; if it is a video data packet, it is processed according to the backpressure strategy.

[0149] Specifically, the type of data packet can be determined based on the transport layer port number and protocol type. For example, the default port number for the RTMP protocol is 1935, the default port number for the SIP protocol is 5060, and the port number for the RTP protocol is usually an even-numbered port between 1024 and 65535. Based on these port numbers and protocol types, the type of data packet can be roughly determined.

[0150] Furthermore, the type of data packet can be determined based on its content. For example, for RTMP protocol data packets, the type of the message packet can be used to determine whether it is a signaling message packet or a media message packet. Signaling message packets are allowed to pass directly; for media message packets, further determination is needed to determine whether it is an audio message packet or a video message packet.

[0151] Those skilled in the art will understand that prioritizing high-priority data packets ensures the transmission quality of important data packets and improves user experience. When system resources are limited, prioritizing the transmission of high-priority data packets prevents the processing of low-priority data packets from affecting their transmission.

[0152] This application is not limited to this. In practical applications, different priority rules can be set according to business needs. For example, different priorities can be set for different users, providing higher service quality to paying users. This will not be elaborated upon here.

[0153] In this embodiment, the user-mode streaming media service module considers the user's service level when generating backpressure policy information. For users with high service levels, the trigger threshold of the backpressure policy can be appropriately increased, or a more lenient backpressure policy can be adopted to ensure the experience of users with high service levels.

[0154] It's important to note that video cloud platforms typically offer different service levels to different users. Users with higher service levels pay higher fees and should receive better service. Therefore, when generating backpressure strategy information, it's necessary to consider the user's service level and provide differentiated services to users at different service levels.

[0155] For example, for ordinary users, the trigger threshold for the backpressure policy can be set to 10% of the quota bitrate. When the real-time bitrate exceeds 10% of the quota bitrate, the backpressure policy is triggered, and all dependent decoded frames are discarded. For users with high service levels, the trigger threshold for the backpressure policy can be set to 20% of the quota bitrate. The backpressure policy is triggered only when the real-time bitrate exceeds 20% of the quota bitrate, and only some dependent decoded frames are discarded to ensure the smoothness of the video.

[0156] Specifically, a user's service level information can be stored in the user database of the user-mode streaming media service module. When a streaming connection is established, the user-mode streaming media service module retrieves the user's service level information from the user database based on the user's account information. Then, based on the user's service level information, it sets the corresponding backpressure policy trigger threshold and backpressure policy type.

[0157] In addition, different quota bitrates can be set for users with different service levels. Users with higher service levels can obtain higher quota bitrates, thus enabling them to transmit higher quality video streams.

[0158] Those skilled in the art will understand that providing differentiated backpressure strategies to users with different service levels can improve user satisfaction and increase the revenue of the video cloud platform. Users with higher service levels are willing to pay higher fees for better service quality; by providing them with differentiated services, more high-service-level users can be attracted, thereby enhancing the platform's competitiveness.

[0159] This application is not limited to this. In practical applications, differentiated backpressure strategies can be set based on other factors, such as service type, time period, and network conditions. These will not be elaborated upon here.

[0160] In this embodiment, the eBPFXDP data path processing module dynamically adjusts the proportion of discarded dependent decoding frames based on network conditions when executing the backpressure strategy. When network conditions are good, the proportion of discarded dependent decoding frames can be appropriately reduced; when network conditions are poor, the proportion of discarded dependent decoding frames can be appropriately increased.

[0161] It should be noted that network conditions are dynamic. When network conditions are good, bandwidth is sufficient, and packet loss is low, the proportion of dropped dependent decoding frames can be appropriately reduced to improve video quality. When network conditions are poor, bandwidth is insufficient, and packet loss is high, the proportion of dropped dependent decoding frames can be appropriately increased to reduce the video bitrate and avoid network congestion.

[0162] For example, the eBPFXDP data path processing module can determine network conditions by monitoring packet loss rate and latency. When the packet loss rate and latency are both below a certain threshold, the network condition is considered good; when the packet loss rate or latency is above a certain threshold, the network condition is considered poor. Then, based on the network condition, the proportion of dependent decoded frames dropped is dynamically adjusted.

[0163] Specifically, adjusting the proportion of dropped dependent decoded frames can be achieved by setting a drop factor. The drop factor ranges from 0 to 1, where 0 means no dependent decoded frames are dropped, and 1 means all dependent decoded frames are dropped. When network conditions are good, a smaller drop factor is set, such as 0.5, which means dropping 50% of dependent decoded frames; when network conditions are poor, a larger drop factor is set, such as 0.8, which means dropping 80% of dependent decoded frames.

[0164] In addition, the proportion of dependent decoded frames dropped can be adjusted based on the difference between the real-time bitrate and the quota bitrate of the streaming connection. When the difference is large, the proportion of dropped frames is increased; when the difference is small, the proportion of dropped frames is decreased.

[0165] Those skilled in the art will understand that dynamically adjusting the proportion of discarded dependent decoding frames based on network conditions can maximize video quality while ensuring the rational utilization of system resources. When network conditions are good, reducing the discarding ratio improves video quality; when network conditions are poor, increasing the discarding ratio avoids network congestion.

[0166] This application is not limited to this. In practical applications, other methods can be used to dynamically adjust the backpressure strategy, such as adjusting the drop ratio based on CPU utilization and memory utilization. These will not be elaborated upon here.

[0167] In this embodiment, the user-space streaming media service module periodically cleans up the connection policy information in the eBPFMAP. If no data packets arrive at a connection within a certain period of time, the connection is considered to be disconnected, and the connection policy information corresponding to that connection is deleted from the eBPFMAP.

[0168] It should be noted that in practical applications, some abnormal situations may occur, such as the streaming client disconnecting abnormally without sending a disconnection request to the user-space streaming media service module. In this case, connection policy information corresponding to that connection will remain in the eBPFMAP, causing the eBPFMAP's memory usage to increase continuously and affecting system performance. Therefore, it is necessary to periodically clean up the connection policy information in the eBPFMAP and delete invalid connection policy information.

[0169] For example, the user-space streaming media service module can iterate through all connection policy information in the eBPFMAP at regular time intervals, such as 5 minutes. For each connection policy information, it checks whether any data packets have arrived at that connection in the recent past period, such as 1 minute. If no data packets have arrived, the connection is considered to be broken, and the connection policy information corresponding to that connection is deleted from the eBPFMAP.

[0170] Specifically, checking for incoming data packets can be achieved through the packet statistics maintained by the eBPFXDP data path processing module. The eBPFXDP data path processing module maintains the last data packet arrival time for each connection in the eBPFMAP. When a data packet arrives, the last data packet arrival time for that connection is updated. When the user-space streaming media service module cleans up connection policy information, it reads the last data packet arrival time for each connection. If the difference between the current time and the last data packet arrival time exceeds a set timeout, the connection is considered to be closed.

[0171] In addition, when cleaning up connection policy information, the user-mode streaming media service module also needs to clean up the corresponding parsing status information and packet loss statistics in eBPFMAP to release memory resources.

[0172] Those skilled in the art will understand that periodically cleaning up invalid connection policy information in the eBPFMAP can prevent eBPFMAP memory overflow and ensure stable system operation. At the same time, it can also improve the query efficiency of eBPF programs, thereby improving the overall system performance.

[0173] This application is not limited to this; in practical applications, other methods can also be used to clean up invalid connection policy information. For example, a timeout mechanism can be set in the eBPF program to automatically delete the connection policy information corresponding to a connection from the eBPFMAP when no data packets arrive within a certain period of time. Further details are omitted here.

[0174] In this embodiment, the eBPFXDP data path processing module timestamps network data packets during processing. The timestamps can be used to analyze data packet processing latency, as well as for traffic analysis and troubleshooting.

[0175] It's important to note that packet processing latency is a crucial metric for measuring system performance. By analyzing packet processing latency, we can understand the system's load and identify performance bottlenecks promptly. Furthermore, timestamps can be used for traffic analysis and troubleshooting, helping developers pinpoint and resolve issues.

[0176] For example, when a network packet arrives at the XDP mount point, the eBPF program obtains the current system time and stores it as the packet's arrival timestamp in the packet's metadata. Then, at each stage of packet processing, timestamps are recorded, such as the timestamp for protocol parsing completion, frame type identification completion, and processing result return. Finally, based on these timestamps, the processing latency at each stage and the total processing latency can be calculated.

[0177] Specifically, system time can be obtained using helper functions provided by the eBPF program. For example, the `bpf_ktime_get_ns` helper function can be used to obtain the current kernel time in nanoseconds. This helper function returns the time since system startup and has high accuracy and stability.

[0178] In addition, timestamps can also be used to calculate the real-time bitrate of a push streaming connection. By counting the number of bytes in the packets arriving over a period of time and the time intervals, the real-time bitrate of the push streaming connection can be calculated.

[0179] Those skilled in the art will understand that timestamping data packets provides crucial information for system performance analysis and troubleshooting. By analyzing data packet processing latency, one can understand the system's performance status, promptly identify and resolve problems, and improve system stability and reliability.

[0180] This application is not limited to this. In practical applications, other metadata information can also be recorded as needed, such as the source network card of the data packet, the CPU core number, and the processing result. This will not be elaborated upon here.

[0181] In this embodiment, the user-space streaming media service module records the execution status of the backpressure policy in a log. The log information includes the network 5-tuple of the connection, the time when the backpressure policy is triggered, the time when the backpressure policy is canceled, the number of packets dropped, and the number of bytes dropped.

[0182] It's important to note that recording the execution status of backpressure policies helps developers understand the system's operational status, analyze the effectiveness of the backpressure policies, and troubleshoot problems. By analyzing log information, developers can identify which connections frequently trigger backpressure policies, their trigger frequency, and the number of packets and bytes dropped, allowing for optimization and adjustment of the backpressure policies.

[0183] For example, when the user-space streaming media service module generates backpressure policy information and writes it into the eBPFMAP, it records a log entry, including the network 5-tuple of the connection, the time the backpressure policy was triggered, and the quota bitrate, etc. When the user-space streaming media service module deletes backpressure policy information from the eBPFMAP, it records a log entry, including the network 5-tuple of the connection, the time the backpressure policy was canceled, and the number of packets and bytes dropped, etc.

[0184] Specifically, log information can be stored in local files or sent to a remote log server. To facilitate log querying and analysis, a structured log format, such as JSON, can be used. Structured log formats are easily processed by log analysis tools to extract useful information.

[0185] In addition, you can set log levels, such as DEBUG, INFO, WARNING, and ERROR. Based on the log level, you can control the amount of log output, preventing excessive log information from impacting system performance.

[0186] Those skilled in the art will understand that recording the execution status of backpressure strategies can provide important information for system optimization and maintenance. By analyzing log information, the effectiveness of the backpressure strategy can be understood, system problems can be identified, and thus the system can be optimized and improved to enhance system performance and user experience.

[0187] This application is not limited to this. In practical applications, other log information can be recorded as needed, such as system performance indicators, error messages, and user operation information. These will not be elaborated upon here. The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system embodiments, since they are basically similar to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0188] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A real-time backpressure method for video cloud based on eBPF, characterized in that, include: At the network data path entry point of the operating system kernel, video frame type information is parsed from the network data packets of the received cloud video. The video frame type information is used to indicate whether the video frame is an independent decoding frame or a dependent decoding frame. Based on the video frame type information, allow network data packets corresponding to independent decoded frames to pass through, and discard network data packets corresponding to dependent decoded frames; Rate limiting and flow control are applied to incoming network data packets.

2. The method according to claim 1, characterized in that, Parsing video frame type information from received cloud video network data packets includes: Obtain connection policy information corresponding to network data packets, wherein the connection policy information includes network 5-tuple and protocol type; The network data packets are parsed according to the protocol type to obtain video frame payload data; The video frame type is identified from the video frame payload data to obtain the video frame type information.

3. The method according to claim 2, characterized in that, Based on the aforementioned protocol type, network data packets are parsed to obtain video frame payload data, including: When the protocol type is RTMP, RTMPChunk blocks are extracted from network data packets, RTMPChunk blocks are reassembled into RTMPMessage packets, media stream class Message packets are obtained from RTMPMessage packets, and video frame payload data is extracted from media stream class Message packets.

4. The method according to claim 2, characterized in that, Based on the aforementioned protocol type, network data packets are parsed to obtain video frame payload data, including: When the protocol type is GB28181, RTP format data packets are extracted from network data packets, RTP format data packets with the same RTP timestamp are combined into PS encapsulation packets, and the video frame payload data is extracted from the PS encapsulation packets.

5. The method according to claim 2, characterized in that, Based on the aforementioned protocol type, network data packets are parsed to obtain video frame payload data, including: When the protocol type is RTSP, RTP format data packets are extracted from network data packets, and RTP format data packets with the same RTP timestamp are combined into frame data. The video frame payload data is extracted from the frame data in FU format.

6. The method according to claim 2, characterized in that, Identifying the video frame type from the video frame payload data includes: Obtain the video encoding format corresponding to the video frame payload data; Locate the frame type identifier field in the video frame payload data according to the video encoding format; The video frame is determined as either an independent decoding frame or a dependent decoding frame based on the value of the frame type identifier field.

7. The method according to claim 2, characterized in that, The connection policy information corresponding to the network data packets obtained includes: The connection policy information matching the five-tuple of the network data packet is queried from the eBPFMAP, which is written by the user-space streaming media service module based on the comparison result of the real-time bitrate and the quota bitrate of the push connection.

8. The method according to claim 7, characterized in that, The data in the eBPFMAP is written by the user-space streaming media service module in the following way: when the real-time bitrate of the push stream connection exceeds the quota bitrate, backpressure policy information is generated, which includes the network 5-tuple, protocol type and quota bitrate; the new interface of eBPFMAP is called to write the backpressure policy information into eBPFMAP.

9. The method according to claim 8, characterized in that, When the real-time bitrate of the detected push stream connection exceeds the quota bitrate, the generated backpressure strategy information includes: The real-time bitrate of the streaming connection is counted within a preset sliding time window; Compare the real-time bitrate with the quota bitrate; When the real-time bitrate exceeds the quota bitrate and the excess amount reaches a set threshold, the backpressure strategy information is generated.

10. A real-time backpressure system for video cloud based on eBPF, characterized in that, include: The eBPFXDP data path processing module is used to load the eBPF program at the network data path entry point of the operating system kernel. The eBPF program parses video frame type information from the network data packets of the received cloud video. Based on the video frame type information, it allows network data packets corresponding to independent decoded frames to pass and discards network data packets corresponding to dependent decoded frames. The video frame type information is used to indicate whether a video frame is an independent decoded frame or a dependent decoded frame. The eBPFMAP shared memory communication module is used to store connection policy information containing network quintuples and protocol types for querying by the eBPF program. The user-mode streaming media service module is used to write connection policy information to the eBPFMAP based on the comparison result between the real-time bitrate and the quota bitrate of the push connection.

Images