A media data transmission method and apparatus, an electronic device, and a storage medium

Abstract

Embodiments of the present application provide a media data transmission method and device, electronic equipment and storage medium. The method applied to the first device comprises: in the case that the first device needs to obtain media data of the second device, obtaining the transmission parameter of the second device, the transmission parameter of the second device comprising a negative acknowledgement (NACK) extension item of the encoding option; receiving the media data packet sent by the second device, and recording the unreceived media data packet in the case that the NACK extension item in the transmission parameter of the second device can be identified; in the case that the first condition is met, sending a retransmission request to the second device, the retransmission request being used to re-request the unreceived media data packet of the first device; and receiving the media data packet requested by the retransmission request re-sent by the second device. Therefore, the embodiments of the present application can solve the problem that the prior art does not provide a processing scheme for the packet loss situation in the UDP transmission scenario, thereby reducing the display effect of the media data.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a media data transmission method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the increasing demand for communication security, the security field is developing rapidly. Among them, the formulation and updating of the technical requirements for information transmission, exchange and control of public security video surveillance network systems (i.e., GB / T 28181) are standards for the security field. They specify the basic requirements for the interconnection structure, transmission, exchange and control of video surveillance network systems, as well as the security requirements, control and transmission processes and protocols.

[0003] According to the specifications, media data should be packetized using Real-Time Transport Protocol (RTP) in the form of a basic stream (PS) or an elementary stream (ES), and the transport layer should support Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). However, because TCP's acknowledgment (ACK) mechanism can cause cumulative TCP latency, UDP has become the mainstream low-latency transport protocol in the field of audio and video transmission.

[0004] However, for UDP transmission scenarios, there is currently no corresponding solution for handling packet loss. As a result, if packet loss occurs in the network, it will reduce the display effect of media data, such as video screen tearing and audio stuttering. Moreover, this phenomenon will be amplified due to the cascading forwarding between platforms. Summary of the Invention

[0005] This application provides a media data transmission method, apparatus, electronic device, and storage medium to solve the problem that the prior art does not provide a solution for handling packet loss in UDP transmission scenarios, which leads to a reduction in the display effect of media data.

[0006] In a first aspect, embodiments of this application provide a media data transmission method applied to a first device, the method comprising:

[0007] When the first device needs to obtain media data from the second device, it obtains the transmission parameters of the second device, wherein the transmission parameters of the second device include the negative acknowledgment (NACK) extension of the encoding options;

[0008] Receive media data packets sent by the second device, and if the NACK extension item in the transmission parameters of the second device can be identified, record the media data packets that were not received;

[0009] If the first condition is met, a retransmission request is sent to the second device, wherein the retransmission request is used to re-request the media data packets that the first device has not received;

[0010] Receive the media data packet requested by the retransmission request resent by the second device.

[0011] Secondly, embodiments of this application also provide a media data transmission method applied to a second device, the method comprising:

[0012] When the first device needs to obtain media data from the second device, it provides the first device with the transmission parameters of the second device and sends media data packets to the first device, so that the first device can record the unreceived media data packets if it can identify the negative acknowledgment (NACK) extension item of the encoding options included in the transmission parameters of the second device.

[0013] Receive a retransmission request sent by the first device under a first condition, wherein the retransmission request is used to re-request media data packets that the first device has not received;

[0014] The media data packet requested by the retransmission request is resent to the first device.

[0015] Thirdly, embodiments of this application provide a media data transmission apparatus applied to a first device, the apparatus comprising:

[0016] The first acquisition module is used to acquire the transmission parameters of the second device when the first device needs to acquire the media data of the second device, wherein the transmission parameters of the second device include the negative acknowledgment (NACK) extension of the encoding options;

[0017] The first receiving module is used to receive media data packets sent by the second device, and, if it is able to identify the NACK extension item in the transmission parameters of the second device, record the media data packets that were not received.

[0018] A first sending module is configured to send a retransmission request to the second device when a first condition is met, wherein the retransmission request is used to re-request media data packets that the first device has not received.

[0019] The first receiving module is further configured to: receive the media data packet requested by the retransmission request resent by the second device.

[0020] Fourthly, embodiments of this application provide a media data transmission apparatus applied to a second device, the apparatus comprising:

[0021] A module is provided to provide the first device with the transmission parameters of the second device when the first device needs to obtain media data from the second device, and to send media data packets to the first device, so that the first device can record the unreceived media data packets if it can identify the negative acknowledgment (NACK) extension item of the encoding options included in the transmission parameters of the second device.

[0022] The second receiving module is configured to receive a retransmission request sent by the first device under the condition of satisfying the first condition, wherein the retransmission request is used to re-request media data packets that the first device has not received.

[0023] The second sending module is used to resend the media data packet requested by the retransmission request to the first device.

[0024] Fifthly, embodiments of this application provide an electronic device, including a memory, a transceiver, and a processor:

[0025] A memory for storing computer programs; a transceiver for sending and receiving data under the control of the processor; and a processor for reading the computer program in the memory and executing the media data transmission method described in the first aspect above, or the media data transmission method described in the second aspect above.

[0026] Sixthly, embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the media data transmission method described in the first aspect above, or implement the media data transmission method described in the second aspect above.

[0027] In this embodiment of the application, when the first device needs to obtain media data from the second device, the first device can obtain the transmission parameters of the second device and receive the media data packets sent by the second device. The transmission parameters of the second device include a negative acknowledgment (NACK) extension for encoding options. When the first device can identify the NACK extension in the transmission parameters of the second device, it records the media data packets it has not received. If a first condition is met, the first device sends a retransmission request to the second device. The retransmission request is used to re-request the media data packets that the first device has not received, thereby receiving the media data packets requested by the retransmission request sent by the second device.

[0028] Therefore, in this embodiment, a NACK extension item for encoding options can be added to the transmission parameters of the second device. If the first device can recognize the NACK extension item in the transmission parameters, it can record any unreceived media data packets during the reception of media data packets sent by the second device, and thus re-request these data packets from the second device when the first condition is met. In this way, in a UDP transmission scenario, the media data transmission method of this embodiment can be used to address packet loss, thereby improving the transmission quality of media data and ultimately enhancing the display effect of the media data. Attached Figure Description

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

[0030] Figure 1 One of the flowcharts for the media data transmission method provided in the embodiments of this application;

[0031] Figure 2 A second flowchart illustrating the media data transmission method provided in this application embodiment;

[0032] Figure 3 This is a flowchart illustrating a specific implementation of the media data transmission method according to an embodiment of this application;

[0033] Figure 4 This is one of the structural block diagrams of the media data transmission apparatus provided in the embodiments of this application;

[0034] Figure 5 A second structural block diagram of the media data transmission apparatus provided in the embodiments of this application;

[0035] Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0036] In the embodiments of this application, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0037] In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0038] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0039] This application provides a media data transmission method and apparatus to solve the problem that the prior art does not provide a solution for handling packet loss in UDP transmission scenarios, which leads to a reduction in the display effect of media data.

[0040] The method and apparatus are based on the same concept of the application. Since the methods and apparatus solve problems in similar ways, the implementation of the apparatus and methods can refer to each other, and the repeated parts will not be described again.

[0041] Figure 1 This illustration shows a flowchart of a media data transmission method provided in an embodiment of this application. This media data transmission method can be applied to a first device, such as... Figure 1 As shown, the method may include the following steps 101 to 104:

[0042] Step 101: If the first device needs to obtain media data from the second device, obtain the transmission parameters of the second device.

[0043] The transmission parameters of the second device include the negative acknowledgment (NACK) extension of the encoding options.

[0044] It should be noted that the transmission parameters of the second device may include an encoding field, which contains multiple encoding options. Each encoding option has a corresponding Negative Acknowledgement (NACK) extension. NACK represents a mechanism and technique for handling lost feedback packets, and it is specified in IETF RFC 4585 as an extension of Real-time Transport Control Protocol (RTCP) Feedback. IETF RFC 4585 is the foundational document for RTCP Feedback, defining the feedback packet format, protocol behavior, constraints, and general NACK extensions, enabling the receiver to provide different types of immediate feedback to the sender, thereby allowing the sender to adjust its transmission behavior.

[0045] For example, the encoded field includes the following:

[0046] m=video 6000RTP / AVP / AVPF 96 97 98

[0047] a = rtpmap:98H264 / 90000

[0048] a = rtcp-fb:98nack

[0049] In this context, "m=video 6000RTP / AVP / AVPF 96 97 98" indicates that the video stream supports three encoding options: 96, 97, and 98. Audio video profile feedback (AVPF) is a new addition, defined in IETF RFC 4585. Compared to AVP, it supports the RTCP feedback mechanism. "a=rtpmap:98H264 / 90000" indicates that the encoding option 98 uses the H264 encoding type and a sampling rate of 90,000 Hz. "a=rtcp-fb:98nack" indicates that the encoding option 98 supports NACK feedback.

[0050] It is understandable that if the encoding options in the transmission parameters of the second device contain a NACK extension, it means that the second device supports NACK extension; if the first device can recognize the NACK extension in the transmission parameters of the second device, it means that the first device supports NACK extension. In this case, the first device can carry the NACK extension "AVPF" and "a=rtcp-fb:98nack" in the message it replies to the second device to inform the second device that it supports NACK extension.

[0051] Optionally, the streaming payload type of the NACK extension is the same as the streaming payload type of the encoding option. For example, in the example above, if the payload type (PT) in "a=rtpmap:98H264 / 90000" is 98, then the PT in "a=rtcp-fb:98nack" is also 98. In this way, the NACK extensions can be mapped one-to-one with the encoding options, that is, it can be clearly determined which NACK extension belongs to which encoding option.

[0052] Optionally, the first device is a streaming media receiver device and the second device is a media server, or the first device is a media server and the second device is a streaming media sender device.

[0053] The following section uses streaming media receiver devices, media servers, and streaming media sender devices as examples to illustrate the transmission process of their transmission parameters:

[0054] A streaming media receiver can send an Invite message to a Session Initiation Protocol (SIP) server, carrying the receiver's transmission parameters. This prompts the SIP server to send an Invite message to the media server, informing it that it is ready to receive media data from the streaming media sender's device. Upon receiving the Invite message, the media server can respond to the SIP server with its own transmission parameters. The SIP server then sends an Invite message to the streaming media sender, carrying its own transmission parameters. The streaming media sender responds to the SIP server with its own transmission parameters, and finally, the SIP server sends an ACK message to the media server, carrying its own transmission parameters.

[0055] Optionally, the aforementioned transmission parameters may be referred to as a Session Description Protocol (SDP) message body. The SDP message body may include relevant content of the requested data in the prior art (such as the address of the first device, encoding type, channel number, etc.) and a feedback mechanism, such as the aforementioned NACK extension.

[0056] Step 102: Receive media data packets sent by the second device, and if the NACK extension item in the transmission parameters of the second device can be identified, record the media data packets that were not received.

[0057] If the first device can identify the NACK extension in the transmission parameters of the second device, it means that the first device supports NACK extension. In this way, when the first device receives media data packets sent by the second device, it can record the media data packets that it failed to receive, and thus it can re-request the media data packets from the second device.

[0058] Optionally, the first device stores the identification information (e.g., serial number (SN)) of the media data packets it has not received in a first list, that is, the first device can maintain a list of missing data packets.

[0059] Furthermore, it should be noted that if the first device cannot recognize the NACK extension in the transmission parameters of the second device, it means that the first device does not support the NACK extension. In this case, the first device will not record the media data packets it did not receive, and will not execute steps 103 to 104. That is, in this case, the first device will not re-request the data packets that were not successfully received.

[0060] Step 103: If the first condition is met, send a retransmission request to the second device.

[0061] The retransmission request is used to re-request media data packets that the first device has not received.

[0062] Optionally, the first condition includes at least one of the following:

[0063] The first timeout period has elapsed (i.e., the first device can periodically trigger a re-request for the unreceived data packet);

[0064] The number of retries has not reached the first threshold, where the first threshold represents the maximum number of retries for the first device (i.e., after reaching the maximum number of retries, the first device will no longer retrieve the corresponding data packet).

[0065] Step 104: Receive the media data packet requested by the retransmission request resent by the second device.

[0066] If the first device records the identification information of the unreceived media data packets in the first list, then after receiving the media data packets requested by the retransmission request resent by the second device, it can update the first list based on these received media data packets, for example, by removing the already received media data packets from the first list.

[0067] As can be seen from steps 101 to 104 above, in this embodiment of the application, when the first device needs to obtain media data from the second device, the first device can obtain the transmission parameters of the second device and receive the media data packets sent by the second device. The transmission parameters of the second device include a negative acknowledgment (NACK) extension for the encoding options. Thus, when the first device can identify the NACK extension in the transmission parameters of the second device, it records the media data packets it has not received. And when the first condition is met, it sends a retransmission request to the second device. The retransmission request is used to re-request the media data packets that the first device has not received, thereby receiving the media data packets requested by the retransmission request resent by the second device.

[0068] Therefore, in this embodiment, a NACK extension item for encoding options can be added to the transmission parameters of the second device. If the first device can recognize the NACK extension item in the transmission parameters, it can record any unreceived media data packets during the reception of media data packets sent by the second device, and thus re-request these data packets from the second device when the first condition is met. In this way, in a UDP transmission scenario, the media data transmission method of this embodiment can be used to address packet loss, thereby improving the transmission quality of media data and ultimately enhancing the display effect of the media data.

[0069] For example, when the first device is a media server and the second device is a streaming media transmitter device, if the media server needs to obtain media data from the streaming media transmitter device, the media server can obtain the transmission parameters of the streaming media transmitter device and receive the media data packets sent by the streaming media transmitter device. The transmission parameters of the streaming media transmitter device include a negative acknowledgment (NACK) extension for encoding options. If the media server can recognize the NACK extension in the transmission parameters of the streaming media transmitter device, it can record the media data packets it has not received. Under certain conditions, it can send a retransmission request to the streaming media transmitter device. The retransmission request is used to re-request the media data packets that the media server has not received, thereby receiving the media data packets requested by the retransmission request resent by the streaming media transmitter device.

[0070] As can be seen, the embodiments of this application provide a packet loss handling scheme during the transmission of data packets from the streaming media sending device to the media server, thereby improving the transmission quality of media data and further enhancing the display effect of media data.

[0071] For example, when the first device is a streaming media receiver device and the second device is a media server, if the streaming media receiver device needs to obtain media data from the media server, the streaming media receiver device can obtain the transmission parameters of the streaming media server and receive the media data packets sent by the streaming media server. The transmission parameters of the media server include a negative acknowledgment (NACK) extension for encoding options. If the streaming media receiver device can recognize the NACK extension in the transmission parameters of the media server, it can record the media data packets it has not received. Under certain conditions, it can send a retransmission request to the media server. The retransmission request is used to re-request the media data packets that the streaming media receiver device has not received, thereby receiving the media data packets requested by the retransmission request resent by the media server.

[0072] As can be seen, the embodiments of this application provide a packet loss handling scheme during the transmission of data packets from a media server to a streaming media receiving device, which can further improve the transmission quality of media data and thus further improve the display effect of media data.

[0073] Optionally, the transmission parameters of the second device further include a first value and a second value, which are used to identify different Synchronization Source (SSRC) channels;

[0074] In step 102 above, receiving the media data packet sent by the second device includes:

[0075] If the NACK extension item in the transmission parameters of the second device can be identified, the media data packets sent by the second device are received through the SSRC channel identified by the first value.

[0076] In step 104 above, receiving the media data packet requested by the retransmission request resent by the second device includes:

[0077] The media data packet requested by the retransmission request resent by the second device is received through the SSRC channel identified by the second numerical value.

[0078] Therefore, in this embodiment of the application, the first value and the second value can be added to the transmission parameters of the second device to identify the two SSRC channels. In this way, during the normal transmission (i.e. the first transmission) of data packets between the first device and the second device, the SSRC channel identified by the first value is used, and the SSRC channel identified by the second value is used during retransmission, which makes it convenient to count indicators such as retransmission rate.

[0079] For example, a specific line can be added to the transmission parameters (i.e., the SDP message body) to represent the first and second added values, as shown below:

[0080] a = ssrc-group:FID 0100000001 0100000002; (i.e., the specific row to be added)

[0081] y = 0100000001.

[0082] Here, "y = 0100000001" represents the "y" line in the SDP message body of the prior art; 0100000001 represents the first value, and 0100000002 represents the second value. It can be seen that the first value in the added specific line can be equal to the value in the existing y line.

[0083] It should be noted that if the first device can recognize the NACK extension in the transmission parameters of the second device, the first device can use the added specific line to ignore the y line in the prior art; if the first device cannot recognize the NACK extension in the transmission parameters of the second device, the first device can ignore the added specific line and use the y line in the prior art.

[0084] Figure 2 This illustration shows a flowchart of a media data transmission method provided in an embodiment of this application. This media data transmission method can be applied to a second device, such as... Figure 2 As shown, the method may include the following steps 201 to 203:

[0085] Step 201: When the first device needs to obtain media data from the second device, the first device is provided with the transmission parameters of the second device and a media data packet is sent to the first device, so that the first device can record the unreceived media data packet if it can identify the negative acknowledgment (NACK) extension of the encoding options included in the transmission parameters of the second device.

[0086] When the second device receives a media data acquisition request from the first device, it means that the second device knows that the first device needs to acquire the media data of the second device, and can then provide the second device with the transmission parameters of the second device.

[0087] It should be noted that the transmission parameters of the second device may include an encoding field, which includes multiple encoding options, each with a corresponding NACK extension. In UDP transmission scenarios, NACK represents a mechanism and technique for handling lost feedback packets, and it is specified in IETF RFC 4585 as an extension of RTCP Feedback. IETF RFC 4585 is the foundational document for RTCP Feedback, defining the feedback packet format, protocol behavior, constraints, and general NACK extensions, enabling the receiver to provide different types of immediate feedback to the sender, thereby allowing the sender to adjust its transmission behavior. For example, the encoding field includes the following:

[0088] m=video 6000RTP / AVP / AVPF 96 97 98

[0089] a = rtpmap:98H264 / 90000

[0090] a = rtcp-fb:98nack

[0091] In this context, "m=video 6000RTP / AVP / AVPF 96 97 98" indicates that the video stream supports three encoding options: 96, 97, and 98. Audio video profile feedback (AVPF) is a new addition, defined in IETF RFC 4585. Compared to AVP, it supports the RTCP feedback mechanism. "a=rtpmap:98H264 / 90000" indicates that the encoding option 98 uses the H264 encoding type and a sampling rate of 90,000 Hz. "a=rtcp-fb:98nack" indicates that the encoding option 98 supports NACK feedback.

[0092] It is understandable that if the encoding options in the transmission parameters of the second device contain a NACK extension, it means that the second device supports NACK extension; if the first device can recognize the NACK extension in the transmission parameters of the second device, it means that the first device supports NACK extension. In this case, the first device can carry the NACK extension "AVPF" and "a=rtcp-fb:98nack" in the message it replies to the second device to inform the second device that it supports NACK extension.

[0093] Optionally, the streaming payload type of the NACK extension is the same as the streaming payload type of the encoding option. For example, in the example above, if the payload type (PT) in "a=rtpmap:98H264 / 90000" is 98, then the PT in "a=rtcp-fb:98nack" is also 98. In this way, the NACK extensions can be mapped one-to-one with the encoding options, that is, it can be clearly determined which NACK extension belongs to which encoding option.

[0094] Optionally, the first device is a streaming media receiver device and the second device is a media server, or the first device is a media server and the second device is a streaming media sender device.

[0095] The following section uses streaming media receiver devices, media servers, and streaming media sender devices as examples to illustrate the transmission process of their transmission parameters:

[0096] A streaming media receiver can send an Invite message to a SIP server, carrying the receiver's transmission parameters. This prompts the SIP server to send an Invite message to the media server, informing it that it is ready to receive media data from the streaming media sender's device. Upon receiving the Invite message, the media server can respond to the SIP server with its own transmission parameters. This response then prompts the SIP server to send an Invite message to the streaming media sender's device, carrying its own transmission parameters. The streaming media sender's device then responds to the SIP server with its own transmission parameters. Finally, the SIP server sends an ACK message to the media server, carrying its own transmission parameters.

[0097] Optionally, the aforementioned transmission parameters may be referred to as a Session Description Protocol (SDP) message body. The SDP message body may include relevant content of the requested data in the prior art (such as the address of the first device, encoding type, channel number, etc.) and a feedback mechanism, such as the aforementioned NACK extension.

[0098] If the first device can identify the NACK extension in the transmission parameters of the second device, it means that the first device supports NACK extension. In this way, when the first device receives media data packets sent by the second device, it can record the media data packets that it failed to receive, and thus it can re-request the media data packets from the second device.

[0099] Optionally, the first device stores the identification information (e.g., serial number (SN)) of the media data packets it has not received in a first list, that is, the first device can maintain a list of missing data packets.

[0100] Furthermore, it should be noted that if the first device cannot recognize the NACK extension in the transmission parameters of the second device, it means that the first device does not support the NACK extension. In this case, the first device will not record the media data packets it has not received and will not send a retransmission request. That is, in this case, the first device will not re-request the data packets that were not successfully received.

[0101] Step 202: Receive the retransmission request sent by the first device when the first condition is met.

[0102] The retransmission request is used to re-request media data packets that the first device has not received.

[0103] Optionally, the first condition includes at least one of the following:

[0104] The first timeout period has elapsed (i.e., the first device can periodically trigger a re-request for the unreceived data packet);

[0105] The number of retries has not reached the first threshold, where the first threshold represents the maximum number of retries for the first device (i.e., after reaching the maximum number of retries, the first device will no longer retrieve the corresponding data packet).

[0106] Step 203: Resend the media data packet requested by the retransmission request to the first device.

[0107] If the first device records the identification information of the unreceived media data packets in the first list, then after receiving the media data packets requested by the retransmission request resent by the second device, it can update the first list based on these received media data packets, for example, by removing the already received media data packets from the first list.

[0108] As can be seen from steps 201 to 203 above, in this embodiment of the application, when the first device needs to obtain media data from the second device, the first device can obtain the transmission parameters of the second device and receive the media data packets sent by the second device. The transmission parameters of the second device include a negative acknowledgment (NACK) extension for the encoding options. Thus, when the first device can identify the NACK extension in the transmission parameters of the second device, it records the media data packets it has not received. And when the first condition is met, it sends a retransmission request to the second device. The retransmission request is used to re-request the media data packets that the first device has not received, thereby receiving the media data packets requested by the retransmission request resent by the second device.

[0109] Therefore, in this embodiment, a NACK extension item for encoding options can be added to the transmission parameters of the second device. If the first device can recognize the NACK extension item in the transmission parameters, it can record any unreceived media data packets during the reception of media data packets sent by the second device, and thus re-request these data packets from the second device when the first condition is met. In this way, in a UDP transmission scenario, the media data transmission method of this embodiment can be used to address packet loss, thereby improving the transmission quality of media data and ultimately enhancing the display effect of the media data.

[0110] For example, when the first device is a media server and the second device is a streaming media transmitter device, if the media server needs to obtain media data from the streaming media transmitter device, the media server can obtain the transmission parameters of the streaming media transmitter device and receive the media data packets sent by the streaming media transmitter device. The transmission parameters of the streaming media transmitter device include a negative acknowledgment (NACK) extension for encoding options. If the media server can recognize the NACK extension in the transmission parameters of the streaming media transmitter device, it can record the media data packets it has not received. Under certain conditions, it can send a retransmission request to the streaming media transmitter device. The retransmission request is used to re-request the media data packets that the media server has not received, thereby receiving the media data packets requested by the retransmission request resent by the streaming media transmitter device.

[0111] As can be seen, the embodiments of this application provide a packet loss handling scheme during the transmission of data packets from the streaming media sending device to the media server, thereby improving the transmission quality of media data and further enhancing the display effect of media data.

[0112] For example, when the first device is a streaming media receiver device and the second device is a media server, if the streaming media receiver device needs to obtain media data from the media server, the streaming media receiver device can obtain the transmission parameters of the streaming media server and receive the media data packets sent by the streaming media server. The transmission parameters of the media server include a negative acknowledgment (NACK) extension for encoding options. If the streaming media receiver device can recognize the NACK extension in the transmission parameters of the media server, it can record the media data packets it has not received. Under certain conditions, it can send a retransmission request to the media server. The retransmission request is used to re-request the media data packets that the streaming media receiver device has not received, thereby receiving the media data packets requested by the retransmission request resent by the media server.

[0113] As can be seen, the embodiments of this application provide a packet loss handling scheme during the transmission of data packets from a media server to a streaming media receiving device, which can further improve the transmission quality of media data and thus further improve the display effect of media data.

[0114] Optionally, the method further includes:

[0115] Obtain the transmission parameters of the first device, wherein the transmission parameters of the first device include the NACK extension of the encoding option, a first value and a second value, and the first value and the second value are used to identify different synchronization source SSRC channels;

[0116] In step 201 above, sending media data packets to the first device includes:

[0117] If the NACK extension of the transmission parameters of the first device can be identified, a media data packet is sent to the first device through the SSRC channel identified by the first value.

[0118] In step 204 above, retransmitting the media data packet requested by the retransmission request to the first device includes:

[0119] If the NACK extension of the transmission parameters of the first device can be identified, the media data packet requested by the retransmission request is retransmitted to the first device through the SSC channel identified by the second value.

[0120] If the transmission parameters of the first device include the NACK extension item of the encoding option, it means that the first device supports NACK extension; if the second device can recognize the NACK extension item in the transmission parameters of the first device, it means that the second device supports NACK extension.

[0121] Therefore, in this embodiment of the application, the first value and the second value can be added to the transmission parameters of the first device to identify the two SSRC channels. In this way, during the normal transmission (i.e. the first transmission) of data packets between the first device and the second device, the SSRC channel identified by the first value is used, and the SSRC channel identified by the second value is used during retransmission, which makes it convenient to count indicators such as retransmission rate.

[0122] For example, a specific line can be added to the transmission parameters (i.e., the SDP message body) to represent the first and second added values, as shown below:

[0123] a = ssrc-group:FID 0100000001 0100000002; (i.e., the specific row to be added)

[0124] y = 0100000001.

[0125] Here, "y = 0100000001" represents the "y" line in the SDP message body of the prior art; 0100000001 represents the first value, and 0100000002 represents the second value. It can be seen that the first value in the added specific line can be equal to the value in the existing y line.

[0126] Furthermore, if the second device can recognize the NACK extension in the transmission parameters of the first device, the second device can use the added specific line to ignore the y line in the prior art; if the second device cannot recognize the NACK extension in the transmission parameters of the first device, the second device can ignore the added specific line and use the y line in the prior art.

[0127] Furthermore, it should be noted that in existing technologies, when using web page playback, each platform utilizes browser plugins or a solution of WASM software decoding + Canvas (video rendering) + AudioContext (audio playback), instead of using the browser's own audio and video playback capabilities, such as Media Source Extensions (MSE) and Web Real-Time Communications (WebRTC). This results in significant differences or complete incompatibility between playback technologies across platforms, and even more serious issues such as audio-visual asynchrony, high performance overhead, and unclear debugging methods.

[0128] WASM software decoding refers to the process of using WebAssembly technology to decode video; WebAssembly is a virtual instruction set architecture.

[0129] WebRTC is an open web standard that allows browsers to establish peer-to-peer (P2P) connections for transmitting audio and video streams and other arbitrary data.

[0130] In the embodiments of this application, by adding the AVPF option to the transmission parameters (i.e. SDP message body) of the first and second devices, more WebRTC technology points, such as the NACK feedback mechanism, can be included in these transmission parameters. This allows WebRTC SFU capabilities to be integrated into the media server, and the native WebRTC playback capabilities supported by the browser to improve playback effects, reduce platform differences, and standardize the visualization of transmission quality.

[0131] Furthermore, it should be noted that the method of recording unreceived media data packets in the text is not limited to a list format, and can also adopt any other form in the existing technology.

[0132] It should also be noted that the first value in the transmission parameters of the first device is the same as the first value in the transmission parameters of the second device; the second value in the transmission parameters of the first device is the same as the second value in the transmission parameters of the second device.

[0133] In summary, the specific implementation methods of the media data transmission method in this application can be as follows: Figure 3 As shown, it includes the following steps 1 to 18:

[0134] Step 1: The streaming media receiver device sends an Invite message to the SIP server, carrying the streaming media receiver device's SDP (also known as Offer) message body-1.

[0135] In particular, SDP message body-1 adds AVPF options (see above for details) to m lines based on the content included in the existing technology (such as the address of the streaming media receiver device, supported encoding types, etc.), and adds a corresponding RTCP NACK extension for each encoding option; the PT of the RTCP NACK extension is consistent with the PT of the encoding option corresponding to the extension.

[0136] Furthermore, a specific line “a=ssrc-group:FID” is added before line y in the SDP message body-1. The first value carried by this specific line (e.g., 0100000001) is the SSRC of the RTP (i.e., the same as y; the purpose of keeping line y is to maintain compatibility with the old protocol), and the second value (e.g., 0100000002) is the SSRC of the retransmitted RTP packet (i.e., the retransmitted packet uses a different SSRC channel, which is convenient for calculating the retransmission rate, etc.), which is used to specify the SSRC used by the retransmitted RTP packet.

[0137] Step 2: When the media server does not have the stream requested in Step 1, the SIP server sends an Invite signaling message to the media server. It should be noted that this Invite signaling message does not carry an SDP message body; instead, it instructs the media server to generate an SDP to wait for the stream to be received from the streaming media sender's device.

[0138] Step 3: The media server generates an SDP message body-2 with NACK extension, also known as an Offer, and responds (i.e., 200 OK). The SDP message body-2 carries AVPF options, a NACK extension line, and an extended channel line "a=ssrc-group:FID".

[0139] Offer and Answer are alternative names for SDP types during the WebRTC signaling negotiation process.

[0140] Step 4: The SIP server sends an Invite message to the streaming media sender device. This Invite message carries the SDP (also known as Offer) message body-2 of the media server.

[0141] Step 5: The streaming media sending device parses the SDP message body-2. If it can recognize (and supports) the NACK extension, it will also carry the AVPF option, the NACK extension line and the extended channel line "a=ssrc-group:FID" when generating the SDP (also known as Answer) message body-3, and respond (i.e., 200 OK).

[0142] Step 6: The SIP server sends an ACK to the media server, carrying the SDP message body-3 of the streaming media sender device; thus, step 6 notifies the media server of the SDP message body-3 of the streaming media sender device.

[0143] Step 7: The SIP server sends an ACK to the streaming media sender device, notifying the streaming media sender device that it can start sending the media stream.

[0144] Step 8: After receiving the ACK, the streaming media sending device sends an RTP packet (i.e., a data packet of the real-time media stream) to the media server through the SSRC channel identified by the first numerical value mentioned above.

[0145] Step 9: The media server maintains a list of missing RTP packets (called the NACK list) based on the SN of the received RTP packets (i.e., the data packets of the real-time media stream). According to a certain strategy (such as SN-based checks or timed triggering), the media server sends a NACK request to the streaming media sender device through the RTCP channel to request the data packets in the NACK list. The format of the NACK request can be found in IETF RFC 4585.

[0146] For NACK requests for the same packet, the media server can take a backoff approach, such as increasing the delay by 25% for each transmission and stopping the request once the maximum number of retries (e.g., 10 times) is exceeded.

[0147] Step 10: The streaming media sending device parses the NACK request and retransmits the requested RTP packet through the SSRC channel identified by the second numerical value mentioned above.

[0148] It should be noted that when the streaming media sending device receives a NACK request for an RTP packet, it will only retransmit the packet if the time since the last transmission of the packet exceeds the round-trip time (RTT) of a connection, thereby reducing invalid retransmissions.

[0149] The media server can treat retransmitted packets as normal packets based on the SSRC of the received RTP, such as removing them from the NACK list or calculating the retransmission rate.

[0150] Step 11: When the media server already has the stream requested in Step 1, the SIP server sends an Invite signaling message to the media server, carrying the SDP (also known as Offer) message body-1 of the streaming media receiver device, to request the media server to send the media stream to the streaming media receiver device.

[0151] Step 12: The media server parses the SDP message body-1. If it carries AVPF options, a NACK extension line, and an extended channel line "a=ssrc-group:FID", it indicates that it supports NACK extension. When generating the SDP (also known as Answer) message body-4, the extension line is added accordingly, and a response (i.e., 200 OK) is sent.

[0152] Step 13: The SIP server forwards the SDP message body-4 received in step 12 to the streaming media receiving device.

[0153] Step 14: The streaming media receiving device sends an ACK to the SIP server.

[0154] Step 15: The SIP server sends an ACK to the media server, informing the media server that it can start sending the media stream.

[0155] Step 16: The media server sends an RTP packet to the streaming media receiving device through the SSRC channel identified by the first numerical value mentioned above.

[0156] It should be noted that the media server can cache each sent RTP packet in the sent queue and update the sending time so that it can be retrieved and retransmitted.

[0157] Step 17: The streaming media receiver device maintains a list of missing RTP packets (called the NACK list) based on the SN of the received RTP packets, and sends a NACK request to the media server through the RTCP channel according to a certain strategy (such as SN-based checking or timed triggering) to request the data packets in the NACK list. The format of the NACK request can be found in IETF RFC4585.

[0158] It should be noted that for NACK requests for the same packet, the streaming media receiving device can take a backoff approach, such as increasing the delay by 25% for each transmission and no longer requesting if the maximum number of retries (e.g., 10 times) is exceeded.

[0159] Step 18: The media server device retransmits the requested RTP packet through the SSRC channel identified by the second numerical value mentioned above, in accordance with the NACK request.

[0160] It should be noted that when a media server receives a NACK request for an RTP packet, it will only retransmit the packet if more than one RTT has passed since the packet was last sent, thus reducing unnecessary retransmissions.

[0161] The media server can also delete older retransmittable packets based on the timestamps of the sent RTP packets.

[0162] The streaming media receiver device can treat retransmitted packets as normal packets based on the SSRC of the received RTP, such as removing them from the NACK list and calculating the retransmission rate.

[0163] Furthermore, it should be noted that by adding the RTCP NACK extension item corresponding to the encoding option to the SDP message body involved in this embodiment, more WebRTC technology points can be included in these SDP message bodies. Therefore, this embodiment can integrate WebRTC SFU capabilities into the media server and utilize the browser's native support for WebRTC playback capabilities to improve playback quality, reduce platform differences, and standardize the visualization of transmission quality.

[0164] It is understood that this implementation method is applicable to platforms based on the GB / T 28181 protocol, and to scenarios where the UDP protocol is used for real-time video and audio on-demand, historical video and audio playback, and historical video and audio file download.

[0165] In summary, the embodiments of this application have the following advantages:

[0166] 1. Apply the RTCP Feedback and NACK extension specified in IETF RFC 4585 to the UDP media negotiation and transmission process of the national standard to improve the media transmission quality of the national standard platform, and be compatible with platforms that do not support the NACK extension.

[0167] 2. Integrate WebRTC SFU capability into the media server of the GB / T 28181 platform, utilize the browser's native support for WebRTC playback to improve playback quality, reduce platform differences, and standardize the visualization of transmission quality.

[0168] The media data transmission method provided by the embodiments of this application has been described above. The media data transmission device provided by the embodiments of this application will be described below with reference to the accompanying drawings.

[0169] See Figure 4 This application also provides a media data transmission apparatus, applied to a first device, the apparatus comprising:

[0170] The first acquisition module 401 is used to acquire the transmission parameters of the second device when the first device needs to acquire the media data of the second device, wherein the transmission parameters of the second device include the negative acknowledgment (NACK) extension item of the encoding option;

[0171] The first receiving module 402 is used to receive media data packets sent by the second device, and, if it is able to identify the NACK extension item in the transmission parameters of the second device, record the media data packets that were not received.

[0172] The first sending module 403 is configured to send a retransmission request to the second device when a first condition is met, wherein the retransmission request is used to re-request media data packets that the first device has not received.

[0173] The first receiving module 402 is further configured to: receive the media data packet requested by the retransmission request resent by the second device.

[0174] Optionally, the transmission parameters of the second device further include a first value and a second value, which are used to identify different synchronization source SSRC channels;

[0175] The first receiving module 402 receives media data packets sent by the second device, including:

[0176] If the NACK extension item in the transmission parameters of the second device can be identified, the media data packets sent by the second device are received through the SSRC channel identified by the first value.

[0177] The first receiving module 402 receives the media data packet requested by the retransmission request resent by the second device, including:

[0178] The media data packet requested by the retransmission request resent by the second device is received through the SSRC channel identified by the second numerical value.

[0179] Optionally, the streaming payload type of the NACK extension is the same as the streaming payload type of the encoding option.

[0180] See Figure 5 This application also provides a media data transmission apparatus for use in a second device, the apparatus comprising:

[0181] The module 501 is configured to provide the first device with the transmission parameters of the second device and send media data packets to the first device when the first device needs to obtain media data from the second device, so that the first device can record the unreceived media data packets if it can identify the negative acknowledgment (NACK) extension of the encoding options included in the transmission parameters of the second device.

[0182] The second receiving module 502 is configured to receive a retransmission request sent by the first device under the condition of satisfying the first condition, wherein the retransmission request is used to re-request media data packets that the first device has not received.

[0183] The second sending module 503 is used to resend the media data packet requested by the retransmission request to the first device.

[0184] Optionally, the device further includes:

[0185] The second acquisition module is used to acquire the transmission parameters of the first device, wherein the transmission parameters of the first device include the NACK extension of the encoding option, a first value and a second value, and the first value and the second value are used to identify different synchronization source SSRC channels.

[0186] The second sending module 503 sends media data packets to the first device, including:

[0187] If the NACK extension of the transmission parameters of the first device can be identified, a media data packet is sent to the first device through the SSRC channel identified by the first value.

[0188] The second sending module 503 retransmits the media data packet requested by the retransmission request to the first device, including:

[0189] If the NACK extension of the transmission parameters of the first device can be identified, the media data packet requested by the retransmission request is retransmitted to the first device through the SSC channel identified by the second value.

[0190] Optionally, the streaming payload type of the NACK extension is the same as the streaming payload type of the encoding option.

[0191] It should be noted that the division of units in the embodiments of this application is illustrative and only represents one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0192] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a processor-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0193] It should be noted that the apparatus provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0194] Embodiments of this application also provide an electronic device, such as... Figure 6 As shown, the electronic device includes a memory 620, a transceiver 610, and a processor 600;

[0195] Memory 620 is used to store computer programs;

[0196] Transceiver 610 is used to receive and send data under the control of processor 600;

[0197] When the electronic device is used as the first device, the processor 600 is used to read the computer program in the memory 620 and execute the media data transmission method described in the first aspect above.

[0198] When the electronic device is used as a second device, the processor 600 is used to read the computer program in the memory 620 and execute the media data transmission method described in the second aspect above.

[0199] Among them, Figure 6 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits together, represented by one or more processors (processor 600) and memory (memory 620). The bus architecture can also link together various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 610 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over transmission media, including wireless channels, wired channels, optical fibers, etc. The processor 600 is responsible for managing the bus architecture and general processing, and the memory 620 can store data used by the processor 600 during operation.

[0200] The processor 600 can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a complex programmable logic device (CPLD). The processor 600 can also adopt a multi-core architecture.

[0201] It should be noted that the apparatus provided in this application embodiment can implement all the method steps implemented in the above method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0202] Embodiments of this application also provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the media data transmission method described in the first aspect above, or implement the media data transmission method described in the second aspect above.

[0203] The computer-readable storage medium can be any available medium or data storage device that the processor can access, including but not limited to magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., compact disks (CDs), digital versatile optical discs (DVDs), Blu-ray discs (BDs), holographic versatile optical discs (HVDs), etc.), and semiconductor storage (e.g., read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), non-volatile memory (NAND FLASH), solid-state disks (SSDs), etc.).

[0204] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0205] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-executable instructions. These computer-executable instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0206] These processor-executable instructions may also be stored in a processor-readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the processor-readable memory produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0207] These processors can execute instructions that can also be loaded onto a computer or other programmable data processing device, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0208] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A media data transmission method, characterized in that, Applied to a first device, the method includes: When the first device needs to obtain media data from the second device, it obtains the transmission parameters of the second device, wherein the transmission parameters of the second device include the negative acknowledgment (NACK) extension of the encoding options; Receive media data packets sent by the second device, and if the NACK extension item in the transmission parameters of the second device can be identified, record the media data packets that were not received; If the first condition is met, a retransmission request is sent to the second device, wherein the retransmission request is used to re-request the media data packets that the first device has not received; Receive the media data packet requested by the retransmission request resent by the second device; The transmission parameters of the second device also include a first value and a second value, which are used to identify different synchronization source SSRC channels; The receiving of media data packets sent by the second device includes: If the NACK extension item in the transmission parameters of the second device can be identified, the media data packets sent by the second device are received through the SSRC channel identified by the first value. The media data packet requested by the retransmission request resent by the second device includes: The media data packet requested by the retransmission request resent by the second device is received through the SSRC channel identified by the second numerical value.

2. The method according to claim 1, characterized in that, The streaming payload type of the NACK extension is the same as the streaming payload type of the encoding option.

3. A media data transmission method, characterized in that, Applied to a second device, the method includes: When the first device needs to obtain media data from the second device, it provides the first device with the transmission parameters of the second device and sends media data packets to the first device, so that the first device can record the unreceived media data packets if it can identify the negative acknowledgment (NACK) extension item of the encoding options included in the transmission parameters of the second device. Receive a retransmission request sent by the first device under a first condition, wherein the retransmission request is used to re-request media data packets that the first device has not received; Resend the media data packet requested by the retransmission request to the first device; The method further includes: Obtain the transmission parameters of the first device, wherein the transmission parameters of the first device include the NACK extension of the encoding option, a first value and a second value, and the first value and the second value are used to identify different synchronization source SSRC channels; Sending media data packets to the first device includes: If the NACK extension of the transmission parameters of the first device can be identified, a media data packet is sent to the first device through the SSRC channel identified by the first value. The step of retransmitting the media data packet requested by the retransmission request to the first device includes: If the NACK extension of the transmission parameters of the first device can be identified, the media data packet requested by the retransmission request is retransmitted to the first device through the SSC channel identified by the second value.

4. The method according to claim 3, characterized in that, The streaming payload type of the NACK extension is the same as the streaming payload type of the encoding option.

5. A media data transmission device, characterized in that, Applied to a first device, the device includes: The first acquisition module is used to acquire the transmission parameters of the second device when the first device needs to acquire the media data of the second device, wherein the transmission parameters of the second device include the negative acknowledgment (NACK) extension of the encoding options; The first receiving module is used to receive media data packets sent by the second device, and, if it is able to identify the NACK extension item in the transmission parameters of the second device, record the media data packets that were not received. A first sending module is configured to send a retransmission request to the second device when a first condition is met, wherein the retransmission request is used to re-request media data packets that the first device has not received. The first receiving module is further configured to: receive the media data packet requested by the retransmission request retransmitted by the second device; The transmission parameters of the second device also include a first value and a second value, which are used to identify different synchronization source SSRC channels; The first receiving module receives media data packets sent by the second device, including: If the NACK extension item in the transmission parameters of the second device can be identified, the media data packets sent by the second device are received through the SSRC channel identified by the first value. The first receiving module receives the media data packet requested by the retransmission request resent by the second device, including: The media data packet requested by the retransmission request resent by the second device is received through the SSRC channel identified by the second numerical value.

6. A media data transmission device, characterized in that, Applied to a second device, the device includes: A module is provided to provide the first device with the transmission parameters of the second device when the first device needs to obtain media data from the second device, and to send media data packets to the first device, so that the first device can record the unreceived media data packets if it can identify the negative acknowledgment (NACK) extension item of the encoding options included in the transmission parameters of the second device. The second receiving module is configured to receive a retransmission request sent by the first device under the condition of satisfying the first condition, wherein the retransmission request is used to re-request media data packets that the first device has not received. The second sending module is used to resend the media data packet requested by the retransmission request to the first device; The device further includes: The second acquisition module is used to acquire the transmission parameters of the first device, wherein the transmission parameters of the first device include the NACK extension of the encoding option, a first value and a second value, and the first value and the second value are used to identify different synchronization source SSRC channels. The second sending module sends media data packets to the first device, including: If the NACK extension of the transmission parameters of the first device can be identified, a media data packet is sent to the first device through the SSRC channel identified by the first value. The second sending module retransmits the media data packet requested by the retransmission request to the first device, including: If the NACK extension of the transmission parameters of the first device can be identified, the media data packet requested by the retransmission request is retransmitted to the first device through the SSC channel identified by the second value.

7. An electronic device, characterized in that, Includes memory, transceiver, and processor: Memory, used to store computer programs; Transceiver, used to send and receive data under the control of the processor; A processor is configured to read a computer program from the memory and execute the media data transmission method according to any one of claims 1 to 2, or execute the media data transmission method according to any one of claims 3 to 4.

8. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the media data transmission method as described in any one of claims 1 to 2, or implement the media data transmission method as described in any one of claims 3 to 4.

Images