A media stream keep-alive method, device, storage medium and media stream transceiver

Abstract

The present application provides a media stream keep-alive method, apparatus, storage medium and media stream transceiver, which can use the RTP protocol to send and receive keep-alive messages. Compared with the RTP over TCP protocol, the RTP over UDP protocol has higher flexibility, real-time and scalability. At the same time, the present application can dynamically adjust the first response interval of the device according to the reception time interval of the local device for the first RTP keep-alive message sent by the opposite device, and send a second RTP keep-alive message to the opposite device, so that the opposite device adjusts the time interval for sending the first RTP keep-alive message according to the first response interval. In this way, the sending interval of the keep-alive message can be dynamically adjusted according to the network status, so as to better adapt to the network status and reduce resource waste, thereby improving network utilization and realizing efficient transmission of media streams. It can be seen that the present application can not only achieve efficient transmission, but also ensure the security and privacy of the transmission process.

Description

Technical Field

[0001] The present application relates to the field of security monitoring technology, and in particular to a media stream keep-alive method, apparatus, storage medium, and media stream transceiver. Background Art

[0002] In the field of video surveillance, how to achieve efficient and stable transmission of media streams is one of the technical focuses. With the large-scale promotion of the GB28181 standard, media streams are mostly transmitted using the unreliable network transport layer protocol UDP. Although the GB28181 standard stipulates a media stream keep-alive mechanism to improve the transmission reliability of media streams, this mechanism only considers various registration states and heartbeat states at the signaling level, which deviates from the situation where the actual media stream transmission process requires direct participation from both the sender and the receiver. At the same time, since devices or platforms are usually equipped with multiple video surveillance devices, and the status of a single device cannot cover multiple video surveillance devices and monitor the transmission status of multiple media streams, the existing technology cannot control multiple video surveillance devices one by one. Due to the lack of an effective media stream keep-alive mechanism, the existing technology often encounters abnormal phenomena such as cross-streaming and wild streams during media stream transmission, which greatly reduces the stability and availability of the video surveillance system.

[0003] To address the aforementioned issue of uncontrolled media stream transmission, existing technologies have proposed using RTP for media stream transmission while employing standard RTCP for flow control. However, standard RTCP technology is relatively cumbersome and exponentially increases the number of network ports used. This is inconsistent with the actual need to reduce the number of used ports, making standard RTCP difficult to promote in practical applications. Furthermore, existing technologies have proposed using TCP for keepalive transmission of media streams. However, this approach requires significant network resources, fails to achieve efficient transmission of media streams, and cannot guarantee the privacy and security of media stream data.

[0004] It can be seen that the existing media stream keep-alive methods cannot balance efficiency and security and privacy. Summary of the Invention

[0005] The purpose of this application is to solve at least one of the above-mentioned technical deficiencies, especially the technical deficiencies in the prior art that cannot balance efficiency and security and privacy.

[0006] In a first aspect, an embodiment of the present application provides a media stream keepalive method, applied to a first media device configured with a first response interval, where the first media device is any media stream transceiver device in a media stream transmission system; the method comprising:

[0007] Upon receiving a first RTP keep-alive message sent by a second media device, performing a keep-alive check on the first RTP keep-alive message; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device;

[0008] If the keep-alive check passes, calculating the message reception interval according to the latest reception time and the previous reception time of the first RTP keep-alive message, and determining the upper and lower thresholds respectively;

[0009] If the message receiving interval is greater than the upper threshold, lowering the first response interval;

[0010] If the message receiving interval is less than the lower limit threshold, increasing the first response interval;

[0011] In response to satisfying the triggering rule for sending the keep-alive message, a second RTP keep-alive message is generated according to the first response interval, and the second RTP keep-alive message is sent to the second media device, so that the second media device sends the first RTP keep-alive message to the first media device periodically according to the first response interval.

[0012] In some embodiments, determining the upper threshold and the lower threshold respectively includes:

[0013] Updating the interval average value according to the message receiving interval and a preset smoothing factor;

[0014] The product of the interval average value and the network variation coefficient is used as the upper threshold; wherein the network variation coefficient is a preset coefficient greater than 1;

[0015] The ratio of the interval average value to the network variation coefficient is used as the lower threshold.

[0016] In some embodiments, the method further comprises:

[0017] Determining a loss of connection determination interval according to the first response interval;

[0018] If the first RTP keepalive message is not received within the disconnection determination interval, determining that the second media device is disconnected;

[0019] If it is determined that the second media device is disconnected or fails the keep-alive check, the connection between the first media device and the second media device is disconnected, and resources are released.

[0020] In some embodiments, performing keep-alive verification on the first RTP keep-alive message includes:

[0021] Extracting a first device identifier and first network connection information from the first RTP message, respectively; wherein the first device identifier is a device identifier of a video capture device involved in the current media stream transceiving interaction of the second media device, and the first network connection information is network connection information involved in the current media stream transceiving interaction of the second media device;

[0022] If the first RTP keep-alive message is the first keep-alive message received by the first media device in this media stream sending and receiving interaction, the first device identifier is compared and verified with a pre-acquired target device identifier, and if the comparison and verification pass, the first network connection information is saved as the target network connection information;

[0023] If the first RTP keep-alive message is not the first keep-alive message received by the first media device in this media stream sending and receiving interaction, the first device identifier and the target device identifier are compared and verified, and the first network connection information and the target network connection information are compared and verified.

[0024] In some embodiments, generating a second RTP keep-alive message according to the first response interval includes:

[0025] Obtain a second device identifier and second network connection information; wherein the second device identifier is a device identifier of a video capture device involved in the current media stream transceiving interaction by the first media device, and the second network connection information is network connection information involved in the current media stream transceiving interaction by the first media device;

[0026] The second RTP keep-alive message is generated according to the first response interval, the second device identifier and the second network connection information, so that the extended header information of the second RTP keep-alive message carries the first response interval, the second device identifier and the second network connection information.

[0027] In some embodiments, the first network connection information includes the network address of the second media device, the port information corresponding to the current media stream transmission and reception interaction of the second media device, and the SSRC corresponding to the second media device;

[0028] The second network connection information includes the network address of the first media device, the port information corresponding to the current media stream sending and receiving interaction of the first media device, and the SSRC corresponding to the first media device.

[0029] In some embodiments, the sending trigger rule of the keep-alive message is to determine whether a message sending period has arrived, and the message sending period is determined according to a second response interval carried by the first RTP keep-alive message.

[0030] In a second aspect, an embodiment of the present application provides a media stream keepalive apparatus, applied to a first media device configured with a first response interval, where the first media device is any media stream transceiver in a media stream transmission system; the apparatus includes:

[0031] a keep-alive verification module, configured to perform a keep-alive verification on a first RTP keep-alive message sent by a second media device upon receiving the first RTP keep-alive message; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device;

[0032] a receiving interval calculation module, configured to calculate a message receiving interval according to a latest receiving time and a previous receiving time of the first RTP keep-alive message when the keep-alive check passes, and to determine an upper threshold and a lower threshold respectively;

[0033] a first adjusting module, configured to lower the first response interval if the message receiving interval is greater than the upper threshold;

[0034] a second adjusting module, configured to increase the first response interval if the message receiving interval is less than the lower limit threshold;

[0035] A keep-alive message sending module is used to generate a second RTP keep-alive message according to the first response interval in response to the satisfaction of the keep-alive message sending trigger rule, and send the second RTP keep-alive message to the second media device, so that the second media device regularly sends the first RTP keep-alive message to the first media device according to the first response interval.

[0036] In a third aspect, an embodiment of the present application provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the media stream keep-alive method described in any of the above embodiments.

[0037] In a fourth aspect, an embodiment of the present application provides a media stream transceiver device, the media stream transceiver device comprising: one or more processors, and a memory;

[0038] The memory stores computer-readable instructions, and when the one or more processors execute the computer-readable instructions, the steps of the media stream keep-alive method described in any one of the above embodiments are executed.

[0039] In the media stream keep-alive method, device, storage medium and media stream transceiver provided in some embodiments of the present application, the RTP protocol can be used to send and receive keep-alive messages. Compared with the RTP over TCP protocol, the RTP over UDP protocol has higher flexibility, real-time and scalability. At the same time, the present application can dynamically adjust the first response interval of the present device according to the reception time interval of the present device for the first RTP keep-alive message sent by the opposite device, and send a second RTP keep-alive message to the opposite device, so that the opposite device adjusts the time interval for sending the first RTP keep-alive message according to the first response interval. In this way, the sending interval of the keep-alive message can be dynamically adjusted according to the network status, so as to better adapt to the network status and reduce resource waste, thereby improving network utilization and realizing efficient transmission of media streams. It can be seen that the present application can not only achieve efficient transmission, but also ensure the security and privacy of the transmission process. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0041] Figure 1 FIG1 is a schematic diagram of the architecture of a media streaming transmission system in one embodiment;

[0042] Figure 2 FIG1 is a flow chart of a method for keeping a media stream alive according to an embodiment;

[0043] Figure 3 FIG2 is a second flow chart of a method for keeping media streams alive in one embodiment;

[0044] Figure 4 In one embodiment, the message header format of the RTP keep-alive message;

[0045] Figure 5 1 is a schematic structural diagram of a media stream keep-alive device in one embodiment;

[0046] Figure 6 FIG. 1 is a diagram of the internal structure of a media stream transceiver device in one embodiment. DETAILED DESCRIPTION

[0047] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0048] The terms involved in this application are explained below.

[0049] UDP (User Datagram Protocol): A connectionless transport layer protocol.

[0050] RTP (Real-time Transport Protocol): A network transmission protocol used to transmit audio, video or other real-time data.

[0051] RTCP (RTP Control Protocol): A protocol used to monitor RTP transmission quality and control the sending rate of RTP streams.

[0052] TCP (Transmission Control Protocol): A connection-oriented, reliable, byte-stream-based transport layer communication protocol.

[0053] IP (Internet Protocol): The network layer protocol in the TCP / IP system.

[0054] Media stream keepalive mechanism: A series of measures taken to ensure stable transmission of media streams in unreliable network environments. These measures typically include periodic status reports and heartbeat signals to detect and / or recover from possible transmission interruptions.

[0055] Cross-streaming: This refers to a situation where media stream data is not correctly directed to the intended recipient, but is mistakenly captured by another recipient.

[0056] Wild flow: refers to the situation where media stream data is transmitted along a path that should not exist, usually caused by network configuration errors or equipment failures.

[0057] SSRC (Synchronization Source Identifier): A 32-bit integer in an RTP message that uniquely identifies the source of a media stream.

[0058] Smoothing factor: A coefficient used in the algorithm to smooth data changes. Smoothing can reduce the impact of noise and make the calculation results more stable.

[0059] In some embodiments, the media stream keep-alive method provided by this application can be applied to Figure 1 The media streaming transmission system shown in FIG. The media streaming transmission system may include a video capture device, a streaming media server, a central scheduling server, an access unit, and an electronic terminal. The electronic terminal may be installed with a client program for viewing the surveillance video captured by the video capture device through the client program.

[0060] Users can initiate video playback requests through the client program, and the streaming media server pulls the RTP media stream from the video capture device, and then the streaming media server pushes the video media stream to the client program, ultimately realizing real-time video playback.

[0061] Specifically, see Figure 2 The user can initiate a video playback request through the client program installed on the electronic terminal, which in turn sends a video push request to the central scheduling server. The central scheduling server responds to the video push request by sending signaling to the video capture device, streaming media server, access unit, and electronic terminal. Figure 2 In the RTP keepalive message, "extended media message" refers to the RTP keepalive message sent by the media stream sender, and "keepalive message" refers to the RTP keepalive message sent by the media stream receiver.

[0062] Furthermore, in some examples, the signaling sent by the central scheduling server to the streaming media server carries key information such as the device code to which the RTP media stream to be pulled belongs, the network address of the video acquisition device, the media stream push port of the streaming media server, the address of the client program decoding plug-in, and the media stream receiving port of the client. The signaling sent by the central scheduling server to the client program may carry the network address of the streaming media server, the media stream push port of the streaming media server, and the device code to which the RTP media stream to be pulled belongs. Among them, the device code to which the RTP media stream to be pulled belongs refers to the device code corresponding to the video acquisition device used to collect the surveillance video to be pulled. For example, when the surveillance video to be pulled is collected by the first video acquisition device, the device code of the first video acquisition device is the device code to which the RTP media stream to be pulled belongs as described above.

[0063] After receiving the signaling request forwarded by the central scheduling server, the access unit can send a video request to the video capture device, carrying the Session Description Protocol (SDP). This allows a session to be established between the streaming media server and the video capture device, allowing media streams to be exchanged based on the established session. Furthermore, the access unit can also establish a session between the streaming media server and the electronic terminal, allowing the two to exchange media streams based on the established session.

[0064] Specifically, the streaming server can pull the RTP video media stream (i.e., the media stream of the surveillance video) from the video capture device. The video capture device can send the RTP video media stream to the streaming server and can also send RTP keepalive messages to the streaming server at regular intervals. In one example, the RTP keepalive message can include extended header information, which can carry keepalive information including the device code, the network address of the video capture device, the media stream push port of the video capture device, and the SSRC corresponding to the video capture device.

[0065] When a streaming media server receives an RTP keepalive message from a video capture device, it extracts the device code from the message and compares it with the device code obtained by the device during signaling interaction. If the two device codes are inconsistent, an exception is determined to have occurred, and the streaming media server sends an exception report to the central scheduling server. The central scheduling server forwards the exception report to the access unit, instructing the access unit to stop the target task. The target task refers to the media stream receiving and sending task associated with the device code carried in the RTP keepalive message.

[0066] If the two devices have the same encoding, the streaming media server can include the keepalive information in the RTP keepalive message, including the network address of the video capture device, the media stream push port of the video capture device, and the SSRC corresponding to the video capture device. The streaming media server can compare the device encoding and saved keepalive information obtained from the signaling interaction with the RTP streaming media messages subsequently received from the video capture device. If the network address, port, SSRC, or device encoding of the subsequent RTP message changes, it indicates that the message is not the media stream sent by the device of the current task and is an abnormal media stream. Therefore, these messages can be filtered.

[0067] If the network address, port, SSRC, and device code of subsequent RTP packets are consistent with the saved information, the streaming media server can determine that the keepalive check has passed. After receiving the normal media stream sent by the video capture device, the streaming media server can send RTP keepalive packets to the client program at intervals (for example, every 5 seconds).

[0068] In an example, the RTP keep-alive message may have extended header information, which may carry keep-alive information including device code, network address of the streaming server, media stream push port of the streaming server, and SSRC corresponding to the streaming server.

[0069] When the client program receives the RTP keepalive message sent by the streaming server, it can perform a keepalive check on the RTP keepalive message sent by the streaming server according to the keepalive check process of the streaming server for the RTP keepalive message sent by the video capture device.

[0070] If the keepalive check passes, the client program can receive the normal media stream from the streaming server and then send RTP keepalive messages to the streaming server at regular intervals (for example, every 5 seconds). In one example, the RTP keepalive message may include extended header information, which may carry keepalive information including the device code, the network address of the client program (i.e., the electronic terminal), the media stream receiving port of the client program, and the SSRC corresponding to the client program.

[0071] Similarly, the streaming media server can also send RTP keepalive messages to the video capture device at regular intervals (e.g., every 5 seconds) to facilitate the video capture device to verify the liveness of the streaming media server. In one example, the RTP keepalive message can have extended header information, which can carry keepalive information including the device code, the network address of the streaming media server, the media stream receiving port of the media server, and the SSRC corresponding to the streaming media server.

[0072] Each of the three devices—the video capture device, the streaming media server, and the electronic terminal—receives RTP keepalive messages from the peer device and calculates the interval between two consecutive RTP keepalive messages based on the reception timestamp of each RTP keepalive message. Based on the peer device's corresponding reception interval, the local device dynamically adjusts its expected reception interval (i.e., the response interval) for the peer device's RTP keepalive messages and includes the response interval in the RTP keepalive message it sends. This RTP keepalive message then communicates the response interval to the peer device.

[0073] The local device can determine whether the peer device is disconnected based on its expected reception interval, P. For example, if the local device does not receive RTP keepalive messages from the peer device within N consecutive Ps, the peer device can be determined to be disconnected. N can be a preset positive integer, such as N=3.

[0074] If the peer device is determined to be disconnected, the local device can report to the central scheduling server to request a disconnection, simultaneously releasing its own resources related to the task and no longer pushing and / or receiving the relevant video stream. In one example, if the peer device is determined to be disconnected, the local device can send a disconnection request to the central scheduling server. Upon receiving the disconnection request, the central scheduling server requests the access unit to forward the media stream disconnection signaling, allowing the device to release media resources.

[0075] It should be noted that in this solution, the local device can periodically send RTP keepalive messages to the remote device, and the remote device can periodically send RTP keepalive messages to the local device. Because the network conditions seen by both parties in the UDP protocol are different, the local and remote devices do not affect each other's calculation of the response interval.

[0076] In other words, for the local device, whether the remote device sends an RTP keepalive message does not affect the local device's ability to deliver RTP keepalive messages to the remote device. After receiving the RTP keepalive message from the remote device, the response interval P2 parsed from the message affects the interval at which the local device sends the next RTP keepalive message, but does not factor into the calculation of the local device's response interval P1.

[0077] In one example, response intervals P1 and P2 can be initialized to P0 in the initial state to prevent P1 and P2 from being empty. As the media stream transmission and reception process progresses, the local device can subsequently adjust P1 based on the arrival time of the RTP keepalive message sent by the remote device, and the remote device can subsequently adjust P2 based on the arrival time of the RTP keepalive message sent by the local device.

[0078] It is understood that the local device and the opposite device can be determined based on the execution device and the two parties involved in the interaction of the keep-alive message. For example, when the execution device is a streaming media server, in the scenario where the streaming media server sends an RTP keep-alive message to the video capture device, and in the scenario where the streaming media server receives an RTP keep-alive message sent by the video capture device, the local device is the streaming media server and the opposite device is the video capture device. When the execution device is a streaming media server, in the scenario where the streaming media server sends an RTP keep-alive message to the client program, and in the scenario where the streaming media server receives an RTP keep-alive message sent by the client program, the local device is the streaming media server and the opposite device is the electronic terminal.

[0079] When the executing device is a video capture device, in the scenario where the video capture device sends an RTP keepalive message to the streaming media server, and in the scenario where the video capture device receives an RTP keepalive message sent by the streaming media server, the local device is the video capture device and the remote device is the streaming media server. When the executing device is an electronic terminal, in the scenario where the electronic terminal sends an RTP keepalive message to the streaming media server, and in the scenario where the electronic terminal receives an RTP keepalive message sent by the streaming media server, the local device is the electronic terminal and the remote device is the streaming media server.

[0080] In the RTP media stream transmission process provided in this embodiment, an extended field for detecting the media stream transmission status is added to the RTP keep-alive message, thereby ensuring that the sender and receiver can accurately perceive the transmission status of the other end and ensure the authenticity and effectiveness of the media stream transmission. Compared with the traditional keep-alive method, the media stream keep-alive solution provided by this application does not require a separate channel, reducing bandwidth and port exposure. At the same time, this application dynamically adjusts the response interval of the device so that the sending of keep-alive messages can better adapt to network conditions, avoiding resource waste and improving network utilization.

[0081] At the same time, by regularly adding extended fields during the RTP media stream transmission process of the media stream transmission system, only the address information, device code and response interval control field of the two parties in the media stream interaction are used, so that the media stream sender and receiver can ensure the normal progress of the media stream transmission process by perceiving the real-time status of each other's media stream transmission, and can make timely and effective recovery processing when an abnormality occurs, to ensure the authenticity and effectiveness of the media stream transmission, and avoid the situation where the media stream sender has stopped sending the stream, while the receiver continues to wait for receiving and occupies system resources, or the media stream receiver has stopped receiving, but the sender continues to send, resulting in streaming or wild streaming, leading to waste and exhaustion of resources such as bandwidth, thereby improving the stability and availability of the video surveillance system and reducing the port exposure of the video surveillance platform.

[0082] The media stream keep-alive method provided in this application is described in detail below.

[0083] In some embodiments, the present application provides a method for keeping a media stream alive. The following embodiments illustrate this method using a first media device as an example. The first media device and a second media device exchange media streams. In some examples, the first media device and the second media device may exchange media streams based on the RTP protocol.

[0084] The first media device refers to any media stream transceiver device in the media stream transmission system, that is, the first media device can be any media stream transceiver device in the media stream transmission system. The second media device refers to any media device in the media stream transmission system except the first media device.

[0085] It should be noted that the first media device can be a media stream sender, and the second media device can be a media stream receiver. Alternatively, the first media device can be a media stream receiver, and the second media device can be a media stream sender. This document does not impose specific restrictions on this.

[0086] For example, in Figure 1 In the illustrated media streaming system, the first media device can be a video capture device, a streaming media server, or an electronic terminal. When the first media device is a video capture device, the second media device can be a streaming media server. When the first media device is a streaming media server, the second media device can be a video capture device or an electronic terminal. When the first media device is an electronic terminal, the second media device can be a streaming media server.

[0087] The first media device is configured with a first response interval, which is the expected time interval for the first media device to send a first RTP keepalive message to the second media device. For example, when the first response interval is P1, the first media device expects the second media device to send the first RTP keepalive message according to P1.

[0088] like Figure 3 The media stream keep-alive method provided in this application may include the following steps:

[0089] S302: When a first RTP keep-alive message sent by the second media device is received, a keep-alive check is performed on the first RTP keep-alive message.

[0090] The second media device is a media stream transceiver device that performs media stream transceiver interaction with the first media device in the media stream transmission system. The first RTP keep-alive message refers to a keep-alive message based on the RTP protocol sent by the second media device.

[0091] In this step, when the first media device receives the first RTP keep-alive message, it can perform a keep-alive check based on the information carried by the first RTP keep-alive message and / or preset verification rules to determine whether the media stream transmission channel between the first media device and the second media device is normal and whether any abnormalities occur during the transmission process.

[0092] S304: When the keep-alive check passes, the message receiving interval is calculated according to the latest receiving time and the previous receiving time of the first RTP keep-alive message, and the upper and lower thresholds are determined respectively.

[0093] Among them, the latest reception time refers to the time when the first media device last received the first RTP keep-alive message, and the previous reception time refers to the time when the first media device previously received the first RTP keep-alive message. For example, the first media device receives the first RTP message at times t1, t2, and t3 respectively, where t1 < t2 < t3, and the current time is t3. Then the latest reception time is t3, and the previous reception time is t2.

[0094] In this step, in response to receiving the first RTP message, the first media device can calculate the message reception interval based on the latest reception time and the previous reception time, and respectively determine the upper threshold and the lower threshold. In one example, the message reception interval . Among them, is the timestamp corresponding to the latest reception time, is the timestamp corresponding to the previous reception time. In another example, the upper threshold and the lower threshold can be obtained by pre-setting.

[0095] It should be noted that in the case of receiving each first RTP keep-alive message, the first media device will re-perform the keep-alive check, and re-determine the message reception interval, the upper threshold, and the lower threshold during the keep-alive check.

[0096] For example, if the first media device receives the first RTP message at times t1, t2, and t3 respectively, when the first media device receives the first RTP keep-alive message at time t1, it will calculate the message reception interval corresponding to this message and respectively determine the upper threshold and the lower threshold; when receiving the first RTP keep-alive message at time t2, the first media device will re-calculate the message reception interval corresponding to this message based on times t1 and t2, and respectively determine the upper threshold and the lower threshold. When receiving the first RTP keep-alive message at time t3, the first media device will re-calculate the message reception interval corresponding to this message based on times t2 and t3, and respectively determine the upper threshold and the lower threshold.

[0097] S306: If the message reception interval is greater than the upper threshold, then lower the first response interval.

[0098] In this step, the first media device can compare the message reception interval with the upper threshold, and adjust the first response interval configured in the first media device according to the size relationship between the message reception interval and the upper threshold. Specifically, if the message reception interval is greater than the upper threshold, it indicates that the second media device has too long a sending interval for the first RTP keep-alive message, or there is a possibility of message loss in the first RTP keep-alive message. Therefore, the first media device can lower the first response interval to more accurately detect the situation of the media stream transmission channel.

[0099] S308: If the message receiving interval is less than the lower threshold, increase the first response interval.

[0100] In this step, the first media device may compare the message reception interval with a lower threshold and adjust the first response interval based on the relative magnitude between the message reception interval and the lower threshold. Specifically, if the message reception interval is less than the lower threshold, indicating a good network condition between the first media device and the second media device, the first response interval may be increased to reduce the network resources occupied by media stream keepalives and to utilize more network resources for transmitting media stream data (e.g., video data).

[0101] S310: In response to satisfying the triggering rule for sending the keep-alive message, a second RTP keep-alive message is generated according to the first response interval, and the second RTP keep-alive message is sent to the second media device, so that the second media device periodically sends the first RTP keep-alive message to the first media device according to the first response interval.

[0102] The keep-alive message sending triggering rule refers to a rule for determining whether the first media device needs to send the second RTP keep-alive message to the second media device. The content of the rule can be determined according to actual conditions and is not specifically limited in this document.

[0103] In one example, the first RTP keepalive message may carry a second response interval, which refers to the expected time interval for the second media device to send a second RTP keepalive message to the first media device. The first media device may determine a message sending period based on the second response interval and determine whether the message sending period has arrived to determine whether a triggering rule for sending a keepalive message has been met. When the message sending period arrives, the first media device may determine that the triggering rule for sending a keepalive message has been met. In this manner, the first media device may periodically send a second RTP keepalive message based on the second response interval.

[0104] When the triggering rules for sending keep-alive messages are met, the first media device can generate a second RTP keep-alive message according to the first response interval, and send the second RTP keep-alive message to the second media device to instruct the second media device to send the first RTP keep-alive message to the first media device periodically according to the first response interval.

[0105] In the present application, the RTP protocol can be used to send and receive keep-alive messages. Compared with the RTP over TCP protocol, the RTP over UDP protocol has higher flexibility, real-time and scalability. At the same time, the present application can dynamically adjust the first response interval of the present device according to the reception time interval of the present device for the first RTP keep-alive message sent by the opposite device, and send a second RTP keep-alive message to the opposite device, so that the opposite device adjusts the time interval for sending the first RTP keep-alive message according to the first response interval. In this way, the sending interval of the keep-alive message can be dynamically adjusted according to the network status, so as to better adapt to the network status and reduce resource waste, thereby improving network utilization and realizing efficient transmission of media streams. It can be seen that the present application can not only achieve efficient transmission, but also ensure the security and privacy of the transmission process.

[0106] In some embodiments, the steps of determining the upper threshold and the lower threshold, respectively, include:

[0107] Step A1: Update the interval average value according to the message receiving interval and the preset smoothing factor;

[0108] Step A2: multiplying the interval average value by the network variation coefficient as the upper threshold; wherein the network variation coefficient is a pre-set coefficient greater than 1;

[0109] Step A3: The ratio between the interval average and the network variation coefficient is used as the lower threshold.

[0110] In this embodiment, to reduce the impact of noise, this embodiment may update the interval average value according to a preset smoothing factor and a message receiving interval; and determine the upper threshold and the lower threshold value based on the updated interval average value.

[0111] In one example, the first media device may Implement the update of interval average value. Among them, is the updated interval average, is the preset smoothing factor, Can be between 0 and 1, is the message receiving interval, is the interval average before updating.

[0112] I understand. The value can be adjusted and The weight of the network can be determined in advance based on the actual situation. For example, in order to quickly respond to network changes, A smaller value (for example, between 0.1 and 0.3) can be used to quickly respond to network changes.

[0113] To facilitate the evaluation of the network situation, the first media device can calculate the upper threshold and the lower threshold according to the updated interval average value and the preset network variation coefficient. Specifically, the upper threshold can be , the lower threshold can be , is the network variation coefficient.

[0114] I understand. It can be used to reflect network changes. For example, when the network is relatively stable, A larger value can be selected to reduce the possibility of misjudgment. Smaller values ​​can be chosen to respond more quickly to network changes. In one example, A value of 1.2 to 1.5 can be selected to quickly respond to network changes.

[0115] In one example, the first response interval P may be adjusted according to the following expression:

[0116]

[0117] in, is an adjustment factor between 0 and 1.

[0118] when When , it indicates that the current network status of the first media device and the second media device is congested or blocked, so the first response interval can be appropriately reduced to improve network utilization. , it indicates that the current network status is smooth, so the first response interval can be appropriately increased.

[0119] Furthermore, considering the larger A value of will result in a larger adjustment of the first response interval, which may cause system instability in extreme cases; while a smaller A value of will result in smaller adjustments to the first response interval, which can make the system more stable but less responsive. It is more stable to choose around 0.3.

[0120] In some embodiments, the media stream keep-alive method may further include the following steps:

[0121] Step B1: determining the loss of connection determination interval according to the first response interval;

[0122] Step B2: If the first RTP keepalive message is not received within the disconnection determination interval, it is determined that the second media device is disconnected;

[0123] Step B3: When it is determined that the second media device is disconnected or fails the keep-alive check, the connection between the first media device and the second media device is disconnected, and resources are released.

[0124] In this embodiment, the first media device may determine the connection loss determination interval T according to the first response interval P. In one example, the first media device may be pre-set with a maximum tolerance number N, and the connection loss determination interval T may be N×P.

[0125] The first media device can determine whether it has not received the first RTP keepalive message for a long time based on the loss of connection determination interval. If the first RTP keepalive message is not received within the loss of connection determination interval, the first media device can directly determine that the second media device is lost, and can disconnect and release media resources. When the most recently received first RTP keepalive message fails the keepalive check, the first media device can disconnect and release media resources. For example, when T=10s, if the first media device does not receive the first RTP keepalive message for 10 consecutive seconds, it can be determined that the second media device is lost.

[0126] It can be understood that, when the first RTP keep-alive message is not received, the first media device may keep the first response interval and the second response interval unchanged, and send the second RTP keep-alive message to the second media device according to the second response interval.

[0127] In some embodiments, performing a keep-alive check on the first RTP keep-alive message includes:

[0128] Step C1: Extracting a first device identifier and first network connection information from the first RTP message; wherein the first device identifier is the device identifier of the video capture device involved in the current media stream transceiving interaction of the second media device, and the first network connection information is the network connection information involved in the current media stream transceiving interaction of the second media device;

[0129] Step C2: If the first RTP keepalive message is the first keepalive message received by the first media device in this media stream transmission and reception interaction, the first device identifier is compared and verified with the pre-acquired target device identifier. If the comparison and verification pass, the first network connection information is saved as the target network connection information.

[0130] Step C3: If the first RTP keep-alive message is not the first keep-alive message received by the first media device in this media stream transceiver interaction, the first device identifier and the target device identifier are compared and verified, and the first network connection information and the target network connection information are compared and verified.

[0131] In this embodiment, a keep-alive check can be performed based on the device identification and network connection information, thereby improving the reliability of the keep-alive check, and further increasing the sensitivity of the media stream transmission process, ensuring that the video stream is transmitted under reliable and accurate technical conditions, and resolving various situations in which the media stream transmission is out of control.

[0132] If the media stream data involved in this media stream transmission and reception interaction between the first media device and the second media device is the first media stream data, the first device identifier may be the national standard device code of the video capture device used to capture the first media stream data. The target device identifier may be the device identifier of the video capture device pre-acquired by the first media device. In one example, the target device identifier may be obtained during the signaling interaction between the first media device and the central scheduling server.

[0133] The first network connection information may be the network connection information involved in the current media stream transceiving interaction of the second media device. In one example, the first network connection information includes the network address of the second media device, the port information corresponding to the current media stream transceiving interaction of the second media device, and the SSRC corresponding to the second media device.

[0134] During the keepalive verification process for the first RTP keepalive message, the first media device may first extract the first device identifier and first network connection information from the received first RTP keepalive message, and then compare these key fields with the information obtained during signaling interaction to determine whether the two are consistent. If there is a deviation in the key fields, the media stream protection mechanism may be triggered. The media stream receiver and media stream sender can take appropriate actions based on their roles, increasing the sensitivity of the media stream transmission process, ensuring that the video stream is transmitted under reliable and accurate technical conditions, and resolving various situations in which the media stream transmission is out of control.

[0135] Specifically, the first media device can determine whether the first RTP keep-alive message received this time is the first keep-alive message received by the first media device in this media stream transmission and reception interaction. If so, the first device identifier carried by the first RTP keep-alive message can be compared and verified with the target device identifier pre-acquired by the first media device to determine whether the two are consistent. In the case that the first device identifier and the target device identifier are the same, it can be determined that the comparison and verification are passed, and the first media device can save the first network connection information as the target network connection information, so as to facilitate the keep-alive verification of the first RTP keep-alive message received subsequently based on the target network connection information.

[0136] If the first RTP keepalive message received this time is not the first keepalive message received by the first media device in this media stream transmission and reception interaction, the first media device may perform a keepalive check based on the first device identifier and the first network connection information. Specifically, the first media device may compare the first device identifier with the target device identifier, and compare the first network connection information with the saved target network connection information. If the first device identifier is the same as the target device identifier, and the first network connection information is the same as the target network connection information, it can be determined that the keepalive check has passed. Otherwise, it can be determined that the keepalive check has failed.

[0137] Furthermore, in one example, if the keep-alive check passes, the first media device may continue to receive the device stream. If the keep-alive check fails, the first media device may stop the current task.

[0138] In another example, if the first media device is a media stream receiver, the first media device receives RTP media packets after starting the video task, and does not process any media stream data before confirming the arrival of the first RTP keep-alive message.

[0139] In some embodiments, generating a second RTP keep-alive message according to the first response interval includes:

[0140] Obtain a second device identifier and second network connection information; wherein the second device identifier is a device identifier of a video capture device involved in the current media stream transceiving interaction by the first media device, and the second network connection information is network connection information involved in the current media stream transceiving interaction by the first media device;

[0141] A second RTP keep-alive message is generated according to the first response interval, the second device identifier, and the second network connection information, so that extended header information of the second RTP keep-alive message carries the first response interval, the second device identifier, and the second network connection information.

[0142] If the media stream data involved in the current media stream transceiving interaction between the first media device and the second media device is the first media stream data, the second device identifier may be the national standard device code of the video capture device used to capture the first media stream data.

[0143] The second network connection information may be the network connection information involved in the current media stream transceiving interaction of the first media device. In one example, the second network connection information includes the network address of the first media device, the port information corresponding to the current media stream transceiving interaction of the first media device, and the SSRC corresponding to the first media device.

[0144] Specifically, the present application can extend the RTP protocol header and directly add information such as the second device identifier, the second network connection information and the first response interval to the extended field of the RTP protocol header to form a new RTP message (i.e., the second RTP keep-alive message). The second RTP keep-alive message can be directly transmitted on the media stream transmission port. For the media stream receiver, it can verify the received RTP message while performing the media stream receiving task on the receiving port of the RTP media stream. If the RTP message of the media stream sender is identified as an extended message, its content is parsed. In this way, there is no need to occupy additional port resources, thereby saving the use of port resources. In addition, the RTP keep-alive message and the real RTP media stream message can be distinguished by the extended flag bit allowed by the RTP protocol, so as not to affect the encapsulation and transmission format of the original media stream.

[0145] In one example, the header format of the second keep-alive message may be as follows: Figure 4 As shown, ExtensionID is the extension identifier, ExtensionID is the extension length, Port Number is the port information of the first media device used for the media stream sending and receiving interaction, IP Address is the IP address of the first media device, DeviceID is the second device identifier, DynamicTimestamp is the timestamp corresponding to the first response interval, and the remaining fields can be the native fields of the RTP protocol header.

[0146] In another example, if the first media device is the media stream sender, the first message transmitted by the first media stream device in this media stream sending and receiving interaction may be the second RTP keep-alive message to monitor the transmission status of the media stream receiver before officially transmitting the media stream data.

[0147] In the present application, a method for periodically adding extended fields during the RTP media stream transmission process of the media stream transmission system is provided. This method only uses the address information, device code and response interval control field of the two parties interacting with the media stream, so that the sender and receiver of the media stream can ensure the normal progress of the media stream transmission process by perceiving the real-time status of the other party's media stream transmission, and can make timely and effective recovery processing when an abnormality occurs, to ensure the authenticity and effectiveness of the media stream transmission, and avoid the situation where the sender of the media stream has stopped sending the stream, while the receiver continues to wait for receiving and occupies system resources, or the media stream receiver has stopped receiving, while the sender continues to send, resulting in streaming or wild streaming, resulting in waste and exhaustion of resources such as bandwidth, thereby improving the stability and availability of the video surveillance system and reducing the port exposure of the video surveillance platform.

[0148] The following describes a media stream keep-alive device provided in an embodiment of the present application. The media stream keep-alive device described below and the media stream keep-alive method described above can refer to each other.

[0149] In some embodiments, the present application provides a media stream keep-alive device, which is applied to a first media device configured with a first response interval, wherein the first media device is any media stream transceiver device in a media stream transmission system. Figure 5 As shown, the media stream keep-alive device 500 includes:

[0150] A keep-alive verification module 502 is configured to perform a keep-alive verification on a first RTP keep-alive message sent by a second media device upon receiving the first RTP keep-alive message; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device;

[0151] a receiving interval calculation module 504, configured to calculate a message receiving interval based on the latest receiving time and the previous receiving time of the first RTP keep-alive message when the keep-alive check passes, and determine an upper threshold and a lower threshold respectively;

[0152] A first adjusting module 506 is configured to lower the first response interval if the message receiving interval is greater than the upper threshold;

[0153] A second adjusting module 508 is configured to increase the first response interval if the message receiving interval is less than the lower threshold;

[0154] The keep-alive message sending module 510 is used to generate a second RTP keep-alive message according to the first response interval in response to the satisfaction of the keep-alive message sending trigger rule, and send the second RTP keep-alive message to the second media device, so that the second media device sends the first RTP keep-alive message to the first media device regularly according to the first response interval.

[0155] In some embodiments, the receiving interval calculation module 504 of the present application includes:

[0156] An interval updating unit, configured to update an interval average value according to the message receiving interval and a preset smoothing factor;

[0157] an upper threshold value determining unit, configured to use the product of the interval average value and a network variation coefficient as the upper threshold value; wherein the network variation coefficient is a pre-set coefficient greater than 1;

[0158] The lower threshold determination unit is configured to use the ratio of the interval average value to the network variation coefficient as the lower threshold.

[0159] In some embodiments, the media stream keep-alive device 500 of the present application further includes:

[0160] a loss of connection determination interval determining module, configured to determine a loss of connection determination interval according to the first response interval;

[0161] a disconnection determination module, configured to determine that the second media device is disconnected if the first RTP keepalive message is not received within a disconnection determination interval;

[0162] The disconnection module is configured to disconnect the first media device and the second media device and release resources when it is determined that the second media device is disconnected or fails the keep-alive check.

[0163] In some embodiments, the keep-alive check module 502 of the present application includes:

[0164] a message information extraction unit, configured to extract a first device identifier and first network connection information from the first RTP message, respectively; wherein the first device identifier is a device identifier of a video capture device involved in the current media stream transceiving interaction by the second media device, and the first network connection information is network connection information involved in the current media stream transceiving interaction by the second media device;

[0165] a first verification unit, configured to compare and verify the first device identifier with a pre-acquired target device identifier if the first RTP keep-alive message is the first keep-alive message received by the first media device in this media stream transceiver interaction, and save the first network connection information as the target network connection information if the comparison and verification pass;

[0166] The second verification unit is used to compare and verify the first device identifier and the target device identifier if the first RTP keep-alive message is not the first keep-alive message received by the first media device in this media stream sending and receiving interaction, and to compare and verify the first network connection information and the target network connection information.

[0167] In some embodiments, the keep-alive message sending module 510 of the present application includes:

[0168] An information acquisition unit, configured to acquire a second device identifier and second network connection information; wherein the second device identifier is a device identifier of a video capture device involved in the current media stream transceiving interaction by the first media device, and the second network connection information is network connection information involved in the current media stream transceiving interaction by the first media device;

[0169] A message generation unit is used to generate the second RTP keep-alive message according to the first response interval, the second device identifier and the second network connection information, so that the extended header information of the second RTP keep-alive message carries the first response interval, the second device identifier and the second network connection information.

[0170] In some embodiments, the first network connection information includes the network address of the second media device, the port information corresponding to the second media device in the current media stream transceiver interaction, and the SSRC corresponding to the second media device;

[0171] The second network connection information includes the network address of the first media device, the port information corresponding to the current media stream sending and receiving interaction of the first media device, and the SSRC corresponding to the first media device.

[0172] In some embodiments, the sending trigger rule of the keep-alive message is to determine whether a message sending period has arrived, and the message sending period is determined according to a second response interval carried by the first RTP keep-alive message.

[0173] In one embodiment, the present application further provides a storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the media stream keep-alive method in any embodiment.

[0174] In one embodiment, the present application further provides a media stream transceiver device, in which computer-readable instructions are stored. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the media stream keepalive method in any embodiment.

[0175] Schematically, Figure 6 This is a schematic diagram of the internal structure of a media stream transceiver device provided in an embodiment of the present application. In one example, the media stream transceiver device may be a video capture device, a streaming media server, or an electronic terminal. Figure 6 Media stream transceiver device 900 includes a processing component 902, which further includes one or more processors, and a memory resource represented by memory 901 for storing instructions executable by processing component 902, such as an application. The application stored in memory 901 may include one or more modules, each corresponding to a set of instructions. In addition, processing component 902 is configured to execute the instructions to perform the steps of the media stream keepalive method described in any of the above embodiments.

[0176] The media stream transceiver device 900 may further include a power supply component 903 configured to perform power management of the media stream transceiver device 900 , a wired or wireless network interface 904 configured to connect the media stream transceiver device 900 to the network, and an input / output (I / O) interface 905 .

[0177] Those skilled in the art will understand that the internal structure of the media stream transceiver device shown in the present application is merely a block diagram of a partial structure related to the solution of the present application, and does not constitute a limitation on the media stream transceiver device to which the solution of the present application is applied. The specific media stream transceiver device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0178] Finally, it should be noted that, in this article, relational terms such as first and second are merely used to distinguish one entity or operation from another, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. Without further restriction, an element defined by the phrase "comprising a..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element. Herein, "one," "said," "the," and "its" may also include plural forms unless the context clearly indicates otherwise. A plurality refers to at least two, such as 2, 3, 5, or 8. "And / or" includes any and all combinations of the relevant listed items.

[0179] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referenced to each other.

[0180] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A media stream keep-alive method, characterized in that: The method is applied to a first media device configured with a first response interval, where the first media device is any media stream transceiver device in a media stream transmission system; the method includes: Upon receiving a first RTP keepalive message sent by a second media device, performing a keepalive check on the first RTP keepalive message; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device; wherein RTP is a real-time transport protocol; If the keep-alive check passes, calculating the message reception interval according to the latest reception time and the previous reception time of the first RTP keep-alive message, and determining the upper and lower thresholds respectively; If the message receiving interval is greater than the upper threshold, lowering the first response interval; If the message receiving interval is less than the lower limit threshold, increasing the first response interval; In response to satisfying a keep-alive message sending triggering rule, generating a second RTP keep-alive message according to the first response interval, and sending the second RTP keep-alive message to the second media device, so that the second media device regularly sends the first RTP keep-alive message to the first media device according to the first response interval; The determining of the upper threshold and the lower threshold respectively includes: Updating the interval average value according to the message receiving interval and a preset smoothing factor; The product of the interval average value and the network variation coefficient is used as the upper threshold; wherein the network variation coefficient is a preset coefficient greater than 1; The ratio of the interval average value to the network variation coefficient is used as the lower threshold.

2. The method according to claim 1, characterized in that The method further comprises: Determining a loss of connection determination interval according to the first response interval; If the first RTP keepalive message is not received within the disconnection determination interval, determining that the second media device is disconnected; If it is determined that the second media device is disconnected or fails the keep-alive check, the connection between the first media device and the second media device is disconnected, and resources are released.

3. The method according to claim 1, characterized in that The performing keep-alive verification on the first RTP keep-alive message includes: Extracting a first device identifier and first network connection information from the first RTP message, respectively; wherein the first device identifier is a device identifier of a video capture device involved in the current media stream transceiving interaction of the second media device, and the first network connection information is network connection information involved in the current media stream transceiving interaction of the second media device; If the first RTP keep-alive message is the first keep-alive message received by the first media device in this media stream sending and receiving interaction, the first device identifier is compared and verified with a pre-acquired target device identifier, and if the comparison and verification pass, the first network connection information is saved as the target network connection information; If the first RTP keep-alive message is not the first keep-alive message received by the first media device in this media stream sending and receiving interaction, the first device identifier and the target device identifier are compared and verified, and the first network connection information and the target network connection information are compared and verified.

4. The method according to claim 3, characterized in that Generating a second RTP keep-alive message according to the first response interval includes: Obtain a second device identifier and second network connection information; wherein the second device identifier is a device identifier of a video capture device involved in the current media stream transceiving interaction by the first media device, and the second network connection information is network connection information involved in the current media stream transceiving interaction by the first media device; The second RTP keep-alive message is generated according to the first response interval, the second device identifier and the second network connection information, so that the extended header information of the second RTP keep-alive message carries the first response interval, the second device identifier and the second network connection information.

5. The method according to claim 4, characterized in that The first network connection information includes the network address of the second media device, the port information corresponding to the second media device in the current media stream transmission and reception interaction, and the SSRC corresponding to the second media device, where the SSRC is a synchronization source identifier; The second network connection information includes the network address of the first media device, the port information corresponding to the current media stream sending and receiving interaction of the first media device, and the SSRC corresponding to the first media device.

6. The method according to any one of claims 1 to 4, characterized in that The sending trigger rule of the keep-alive message is to determine whether a message sending period has arrived, and the message sending period is determined according to the second response interval carried by the first RTP keep-alive message.

7. A media stream keep-alive device, characterized in that: The apparatus is applied to a first media device configured with a first response interval, where the first media device is any media stream transceiver in a media stream transmission system; the apparatus includes: a keep-alive verification module, configured to perform a keep-alive verification on a first RTP keep-alive message sent by a second media device upon receiving the first RTP keep-alive message; wherein the second media device is a media stream transceiver device in the media stream transmission system that performs media stream transceiver interaction with the first media device; wherein RTP is a real-time transport protocol; a receiving interval calculation module, configured to calculate a message receiving interval according to a latest receiving time and a previous receiving time of the first RTP keep-alive message when the keep-alive check passes, and to determine an upper threshold and a lower threshold respectively; a first adjusting module, configured to lower the first response interval if the message receiving interval is greater than the upper threshold; a second adjusting module, configured to increase the first response interval if the message receiving interval is less than the lower limit threshold; a keep-alive message sending module, configured to generate a second RTP keep-alive message according to the first response interval in response to satisfying a keep-alive message sending trigger rule, and send the second RTP keep-alive message to the second media device, so that the second media device regularly sends the first RTP keep-alive message to the first media device according to the first response interval; Wherein, the receiving interval calculation module includes: An interval updating unit, configured to update an interval average value according to the message receiving interval and a preset smoothing factor; an upper threshold value determining unit, configured to use the product of the interval average value and a network variation coefficient as the upper threshold value; wherein the network variation coefficient is a pre-set coefficient greater than 1; The lower threshold determination unit is configured to use the ratio of the interval average value to the network variation coefficient as the lower threshold.

8. A storage medium, characterized in that: The storage medium stores computer-readable instructions, which, when executed by one or more processors, enable the one or more processors to perform the steps of the media stream keep-alive method according to any one of claims 1 to 6.

9. A media stream transceiver device, characterized in that: include: one or more processors, and memory; The memory stores computer-readable instructions, which, when executed by the one or more processors, perform the steps of the media stream keep-alive method according to any one of claims 1 to 6.

Images