Media data transmission method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a media data transmission method and device, electronic equipment and a storage medium, and the method applied to first equipment comprises the steps that under the condition that the first equipment needs to obtain media data of second equipment, transmission parameters of the second equipment are obtained, and the transmission parameters of the second equipment comprise negative acknowledgement (NACK) extension items of coding options; receiving a media data packet sent by the second equipment, and recording the media data packet which is not received under the condition that the NACK extension item in the transmission parameter of the second equipment can be identified; under the condition that the first condition is met, a retransmission request is sent to the second equipment, and the retransmission request is used for re-requesting the media data packet which is not received by the first equipment; and receiving the media data packet requested by the retransmission request retransmitted by the second equipment. Therefore, according to the embodiment of the invention, the problem that the media data display effect is reduced due to the fact that a processing scheme for the packet loss situation in the UDP transmission scene is not given in the prior art can be solved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a media data transmission method, device, electronic equipment and storage medium. Background Art

[0002] With the increasing demand for communication security, the security field has developed rapidly. Among them, the formulation and update of the Technical Requirements for Information Transmission, Exchange and Control of Public Security Video Surveillance Network Systems (i.e. GB / T 28181) is a standard for the security field, which stipulates the interconnection structure, transmission, exchange, control basic requirements, security requirements, and control and transmission processes and protocols of video surveillance network systems.

[0003] According to the specification, media data should be packaged using the Real-Time Transport Protocol (RTP) as a Packetized Elementary Stream (PS) or an Elementary Stream (ES) stream, and the transport layer should support the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP). However, since the TCP acknowledgment (ACK) mechanism may cause TCP cumulative delay, UDP has become the mainstream low-latency transmission protocol in the field of audio and video transmission.

[0004] However, for UDP transmission scenarios, there is currently no corresponding solution for packet loss. If packet loss occurs in the network, the display effect of media data will be reduced, such as video distortion and audio freeze, and this phenomenon will be amplified due to the step-by-step forwarding between platforms. Summary of the invention

[0005] The embodiments of the present application provide a media data transmission method, device, electronic device and storage medium to solve the problem that the prior art does not provide a solution for packet loss in UDP transmission scenarios, thereby reducing the media data display effect.

[0006] In a first aspect, an embodiment of the present application provides a method for transmitting media data, which is applied to a first device, and the method includes:

[0007] In a case where the first device needs to obtain media data of the second device, obtaining transmission parameters of the second device, wherein the transmission parameters of the second device include a negative acknowledgement NACK extension item of a coding option;

[0008] receiving a media data packet sent by the second device, and recording a media data packet that is not received if a NACK extension item in a transmission parameter of the second device can be identified;

[0009] If the first condition is met, sending a retransmission request to the second device, wherein the retransmission request is used to re-request the media data packet not received by the first device;

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

[0011] In a second aspect, an embodiment of the present application further provides a method for transmitting media data, which is applied to a second device, and the method includes:

[0012] In a case where the first device needs to obtain media data of the second device, providing the transmission parameters of the second device to the first device, and sending a media data packet to the first device, so that the first device records the unreceived media data packet when being able to identify a negative acknowledgement NACK extension item of a coding option included in the transmission parameters of the second device;

[0013] receiving a retransmission request sent by the first device when a first condition is met, wherein the retransmission request is used to re-request a media data packet that has not been received by the first device;

[0014] Resending the media data packet requested by the retransmission request to the first device.

[0015] In a third aspect, an embodiment of the present application provides a media data transmission apparatus, applied to a first device, the apparatus comprising:

[0016] A first acquisition module, configured to acquire, when the first device needs to acquire media data of a second device, a transmission parameter of the second device, wherein the transmission parameter of the second device includes a negative acknowledgement NACK extension item of a coding option;

[0017] A first receiving module, configured to receive a media data packet sent by the second device, and record a media data packet that is not received when a NACK extension item in a transmission parameter of the second device can be identified;

[0018] A first sending module, 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 a media data packet that has not been received by the first device;

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

[0020] In a fourth aspect, an embodiment of the present application provides a media data transmission apparatus, applied to a second device, the apparatus comprising:

[0021] Providing a module, configured to provide the transmission parameters of the second device to the first device and send a media data packet to the first device when the first device needs to obtain the media data of the second device, so that the first device records the unreceived media data packet when the first device can identify the negative acknowledgement NACK extension item of the coding option included in the transmission parameters of the second device;

[0022] A second receiving module, configured to receive a retransmission request sent by the first device when a first condition is met, wherein the retransmission request is used to re-request a media data packet that has not been received by the first device;

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

[0024] In a fifth aspect, an embodiment of the present application provides an electronic device, including a memory, a transceiver, and a processor:

[0025] A memory for storing a computer program; a transceiver for sending and receiving data under the control of the processor; 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] In a sixth aspect, an embodiment of the present application provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the media data transmission method described in the first aspect above is implemented, or the media data transmission method described in the second aspect above is implemented.

[0027] In an embodiment of the present application, when a first device needs to obtain media data from a second device, the first device is able to obtain transmission parameters of the second device and receive media data packets sent by the second device, wherein the transmission parameters of the second device include a negative acknowledgment NACK extension item of the coding option, so that when the first device is able to identify the NACK extension item in the transmission parameters of the second device, it records the media data packets that it has not received, and when a first condition is met, sends a retransmission request to the second device, wherein 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.

[0028] It can be seen that in the embodiment of the present application, the NACK extension item of the coding option can be added to the transmission parameters of the second device. In this way, if the first device can recognize the NACK extension item in the transmission parameters, it will record the media data packets that have not been received during the process of receiving the media data packets sent by the second device, so that these data packets can be requested from the second device again when the first condition is met. In this way, in the UDP transmission scenario, the media data transmission method of the embodiment of the present application can be used to deal with packet loss, thereby improving the transmission quality of the media data, and further improving the display effect of the media data. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0030] Figure 1 One of the flow charts of the media data transmission method provided in the embodiment of the present application;

[0031] Figure 2 The second flowchart of the media data transmission method provided in the embodiment of the present application;

[0032] Figure 3 A flowchart of a specific implementation of the media data transmission method of an embodiment of the present application;

[0033] Figure 4 One of the structural block diagrams of the media data transmission device provided in the embodiment of the present application;

[0034] Figure 5 The second structural block diagram of the media data transmission device provided in the embodiment of the present application;

[0035] Figure 6 A structural block diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] In the embodiments of the present application, the term "and / or" describes the association relationship of the associated objects, indicating that three relationships may exist. For example, A and / or B may represent: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the associated objects before and after are in an "or" relationship.

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

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

[0039] The embodiments of the present application provide a method and device for transmitting media data, so as to solve the problem that the prior art does not provide a solution for packet loss in a UDP transmission scenario, thereby reducing the media data display effect.

[0040] Among them, the method and the device are based on the same application concept. Since the method and the device solve the problem in a similar principle, the implementation of the device and the method can refer to each other, and the repeated parts will not be repeated.

[0041] Figure 1 A schematic diagram of a process flow of a media data transmission method provided in an embodiment of the present application is shown. The 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: When the first device needs to obtain media data of a second device, obtain transmission parameters of the second device.

[0043] The transmission parameter of the second device includes a negative acknowledgement (NACK) extension item of the coding option.

[0044] It should be noted that the transmission parameters of the second device may include a coding field, which includes multiple coding options, wherein each coding option has a corresponding negative acknowledgment (NACK) extension item. NACK represents a mechanism and technology for feedback packet loss, which is specified in IETF RFC 4585 as an extension of Real-time Transport Control Protocol (RTCP) feedback. Among them, IETF RFC 4585 is a basic document on RTCP feedback, which defines the feedback packet format, protocol behavior, constraints, and a general NACK extension, so that the receiver can provide different types of instant feedback to the sender, thereby allowing the sender to adjust its transmission behavior.

[0045] Exemplarily, the encoding field includes the following:

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

[0047] a=rtpmap:98H264 / 90000

[0048] a=rtcp-fb:98nack

[0049] Among them, "m=video 6000RTP / AVP / AVPF 96 97 98" means that the video stream supports the three encoding options 96, 97, and 98. The audio video profile feedback (AVPF) is a new item defined in IETF RFC 4585. Compared with AVP, it supports the RTCP feedback mechanism; "a=rtpmap:98H264 / 90000" means that the encoding option 98 uses the H264 encoding type and a sampling rate of 90000 Hz; "a=rtcp-fb:98nack" means that the encoding option 98 supports NACK feedback.

[0050] It can be understood that if there is a NACK extension item in the coding option in the transmission parameters of the second device, it means that the second device supports the NACK extension; the first device can recognize the NACK extension item in the transmission parameters of the second device, indicating that the first device supports the NACK extension, wherein the first device can carry "AVPF" and the NACK extension "a=rtcp-fb:98nack" in the message replied to the second device to inform the second device that it supports the NACK extension.

[0051] Optionally, the streaming media payload type of the NACK extension item is the same as the streaming media payload type of the coding option. For example, in the above example, the payload type (Payload Type, PT) in "a=rtpmap:98H264 / 90000" is 98, and the PT in "a=rtcp-fb:98nack" is also 98. In this way, the NACK extension item and the coding option can be matched one by one, that is, it can be clear which NACK extension item belongs to which coding option.

[0052] Optionally, the first device is a streaming media receiving 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 sending device.

[0053] The following takes the streaming media receiver device, media server, and streaming media sender device as examples to specifically introduce the transmission process of the transmission parameters of these devices:

[0054] The streaming media receiver can send an Invite signaling to a Session Initiation Protocol (SIP) server, carrying the transmission parameters of the streaming media receiver, so that the SIP server sends an Invite signaling to the media server, informing the media server that it is ready to receive the media data of the streaming media sender device; wherein, after receiving the Invite signaling, the media server can reply a corresponding response to the SIP server, carrying the transmission parameters of the media server, so that the SIP server sends an Invite signaling to the streaming media sender device, carrying the transmission parameters of the media server; then the streaming media sender device replies a corresponding response to the SIP server, carrying the transmission parameters of the streaming media sender, and then the SIP server replies an ACK to the media server, carrying the transmission parameters of the streaming media sender.

[0055] Optionally, the above transmission parameters can be called a Session Description Protocol (SDP) message body, which can 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 above-mentioned NACK extension.

[0056] Step 102: Receive the media data packet sent by the second device, and record the media data packet that is not received when the NACK extension item in the transmission parameter of the second device can be identified.

[0057] Among them, if the first device can recognize the NACK extension item 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 the media data packet sent by the second device, it can record the media data packet that it has not successfully received, so that it can re-request the second device.

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

[0059] In addition, it should be noted that if the first device cannot recognize the NACK extension item in the transmission parameters of the second device, it means that the first device does not support the NACK extension, and the first device does not record the media data packet it has not received, and does not execute steps 103 to 104, that is, in this case, the first device does not re-request the data packet that was not successfully received.

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

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

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

[0063] The first timing time arrives (i.e., the first device can periodically trigger a re-request for unreceived data packets);

[0064] The number of re-requests does not reach a first threshold, where the first threshold represents a maximum number of re-requests of the first device (ie, after the maximum number of re-requests is reached, the first device will no longer re-request the corresponding data packet).

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

[0066] Among them, if the first device records the identification information of the unreceived media data packets in the first list, then after it receives the media data packets requested by the retransmission request resent by the second device, it can update the first list based on the received media data packets, for example, remove the received media data packets from the first list.

[0067] It can be seen from the above steps 101 to 104 that in an embodiment of the present application, when the first device needs to obtain the media data of the second device, the first device can obtain the transmission parameters of the second device and receive the media data packet sent by the second device, wherein the transmission parameters of the second device include a negative acknowledgment NACK extension item of the coding option, so that when the first device can identify the NACK extension item in the transmission parameters of the second device, it records the media data packet that it has not received, and when the first condition is met, sends a retransmission request to the second device, wherein the retransmission request is used to re-request the media data packet that the first device has not received, thereby receiving the media data packet requested by the retransmission request resent by the second device.

[0068] It can be seen that in the embodiment of the present application, the NACK extension item of the coding option can be added to the transmission parameters of the second device. In this way, if the first device can recognize the NACK extension item in the transmission parameters, it will record the media data packets that have not been received during the process of receiving the media data packets sent by the second device, so that these data packets can be requested from the second device again when the first condition is met. In this way, in the UDP transmission scenario, the media data transmission method of the embodiment of the present application can be used to deal with packet loss, thereby improving the transmission quality of the media data, and further improving the display effect of the media data.

[0069] Exemplarily, when the first device is a media server and the second device is a streaming media sender device, when the media server needs to obtain media data of the streaming media sender device, the media server can obtain the transmission parameters of the streaming media sender device and receive the media data packets sent by the streaming media sender device, wherein the transmission parameters of the streaming media sender device include a negative acknowledgment NACK extension item of the encoding option, so that when the media server can identify the NACK extension item in the transmission parameters of the streaming media sender device, it records the media data packets that it has not received, and when certain conditions are met, sends a retransmission request to the streaming media sender device, wherein 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 sender device.

[0070] It can be seen that the embodiment of the present application provides a solution for processing packet loss in the process of transmitting data packets from a streaming media sending device to a media server, thereby improving the transmission quality of media data and further improving the display effect of media data.

[0071] Exemplarily, when the first device is a streaming media receiving device and the second device is a media server, when the streaming media receiving device needs to obtain media data from the media server, the streaming media receiving device can obtain the transmission parameters of the streaming media server and receive media data packets sent by the streaming media server, wherein the transmission parameters of the media server include a negative acknowledgment NACK extension item of the encoding option, so that when the streaming media receiving device can identify the NACK extension item in the transmission parameters of the media server, it records the media data packets that it has not received, and when certain conditions are met, sends a retransmission request to the media server, wherein the retransmission request is used to re-request the media data packets that the streaming media receiving device has not received, thereby receiving the media data packets requested by the retransmission request resent by the media server.

[0072] It can be seen that the embodiment of the present application provides a solution for processing packet loss in the process of transmitting data packets from a media server to a streaming media receiving device, thereby further improving the transmission quality of media data and further improving the display effect of media data.

[0073] Optionally, the transmission parameter of the second device further includes a first value and a second value, wherein the first value and the second value are used to identify different synchronization source (Synchronization SouRCe, SSRC) channels;

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

[0075] In a case where a NACK extension item in the transmission parameter of the second device can be identified, receiving a media data packet sent by the second device through the SSRC channel identified by the first value;

[0076] In the above step 104, 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] It can be seen from this that in the embodiment of the present application, the above-mentioned first value and second value can also be added to the transmission parameters of the second device to identify two SSRC channels. In this way, during the normal transmission of the data packet between the first device and the second device (i.e., the first transmission), the SSRC channel identified by the first value is used, and the SSRC channel identified by the second value is used during retransmission, thereby facilitating the statistics of indicators such as the retransmission rate.

[0079] Exemplarily, a specific line may be added to the transmission parameter (ie, the SDP message body) to indicate the added first value and second value, as shown below:

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

[0081] y=0100000001.

[0082] Among them, "y=0100000001" represents the "y" line in the SDP message body in 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, when the first device is able to recognize the NACK extension item in the transmission parameters of the second device, the first device can use the added specific row, thereby ignoring the y row in the prior art; when the first device cannot recognize the NACK extension item in the transmission parameters of the second device, the first device can ignore the added specific row, thereby using the y row in the prior art.

[0084] Figure 2 A schematic diagram of a flow chart of a media data transmission method provided in an embodiment of the present application is shown. The 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 the media data of the second device, the transmission parameters of the second device are provided to the first device, and a media data packet is sent to the first device, so that the first device records the media data packet that is not received when it is able to recognize the negative acknowledgment NACK extension item of the coding option included in the transmission parameters of the second device.

[0086] When the second device obtains the media data acquisition request of the first device, it means that the second device knows that the first device needs to obtain the media data of the second device, and then the second device can provide the transmission parameters of the second device to the first device.

[0087] It should be noted that the transmission parameters of the second device may include a coding field, which includes multiple coding options, wherein each coding option has a corresponding NACK extension item. In the UDP transmission scenario, NACK represents a mechanism and technology for feedback packet loss, which is specified in IETF RFC 4585 as an extension of RTCP feedback (FeedBack). Among them, IETF RFC 4585 is the basic document on RTCP feedback, which defines the feedback packet format, protocol behavior, constraints, and a general NACK extension, so that the receiver can provide different types of instant feedback to the sender, thereby allowing the sender to adjust its transmission behavior. Exemplarily, the coding field includes the following:

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

[0089] a=rtpmap:98H264 / 90000

[0090] a=rtcp-fb:98nack

[0091] Among them, "m=video 6000RTP / AVP / AVPF 96 97 98" means that the video stream supports the three encoding options 96, 97, and 98. The audio video profile feedback (AVPF) is a new item defined in IETF RFC 4585. Compared with AVP, it supports the RTCP feedback mechanism; "a=rtpmap:98H264 / 90000" means that the encoding option 98 uses the H264 encoding type and a sampling rate of 90000 Hz; "a=rtcp-fb:98nack" means that the encoding option 98 supports NACK feedback.

[0092] It can be understood that if there is a NACK extension item in the coding option in the transmission parameters of the second device, it means that the second device supports the NACK extension; the first device can recognize the NACK extension item in the transmission parameters of the second device, indicating that the first device supports the NACK extension, wherein the first device can carry "AVPF" and the NACK extension "a=rtcp-fb:98nack" in the message replied to the second device to inform the second device that it supports the NACK extension.

[0093] Optionally, the streaming media payload type of the NACK extension item is the same as the streaming media payload type of the coding option. For example, in the above example, the payload type (Payload Type, PT) in "a=rtpmap:98H264 / 90000" is 98, and the PT in "a=rtcp-fb:98nack" is also 98. In this way, the NACK extension item and the coding option can be matched one by one, that is, it can be clear which NACK extension item belongs to which coding option.

[0094] Optionally, the first device is a streaming media receiving 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 sending device.

[0095] The following takes the streaming media receiver device, media server, and streaming media sender device as examples to specifically introduce the transmission process of the transmission parameters of these devices:

[0096] The streaming media receiver can send an Invite signaling to the SIP server, carrying the transmission parameters of the streaming media receiver, so that the SIP server sends an Invite signaling to the media server, informing the media server that it is ready to receive the media data of the streaming media sender device; wherein, after receiving the Invite signaling, the media server can reply a corresponding response to the SIP server, carrying the transmission parameters of the media server, so that the SIP server sends an Invite signaling to the streaming media sender device, carrying the transmission parameters of the media server; then the streaming media sender device replies a corresponding response to the SIP server, carrying the transmission parameters of the streaming media sender, and then the SIP server replies an ACK to the media server, carrying the transmission parameters of the streaming media sender.

[0097] Optionally, the above transmission parameters can be called a Session Description Protocol (SDP) message body, which can 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 above-mentioned NACK extension.

[0098] Among them, if the first device can recognize the NACK extension item 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 the media data packet sent by the second device, it can record the media data packet that it has not successfully received, so that it can re-request the second device.

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

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

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

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

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

[0104] The first timing time arrives (i.e., the first device can periodically trigger a re-request for unreceived data packets);

[0105] The number of re-requests does not reach a first threshold, where the first threshold represents a maximum number of re-requests of the first device (ie, after the maximum number of re-requests is reached, the first device will no longer re-request the corresponding data packet).

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

[0107] Among them, if the first device records the identification information of the unreceived media data packets in the first list, then after it receives the media data packets requested by the retransmission request resent by the second device, it can update the first list based on the received media data packets, for example, remove the received media data packets from the first list.

[0108] It can be seen from the above steps 201 to 203 that in an embodiment of the present application, when the first device needs to obtain the media data of the second device, the first device can obtain the transmission parameters of the second device and receive the media data packet sent by the second device, wherein the transmission parameters of the second device include a negative acknowledgment NACK extension item of the coding option, so that when the first device can identify the NACK extension item in the transmission parameters of the second device, it records the media data packet that it has not received, and when the first condition is met, sends a retransmission request to the second device, wherein the retransmission request is used to re-request the media data packet that the first device has not received, thereby receiving the media data packet requested by the retransmission request resent by the second device.

[0109] It can be seen that in the embodiment of the present application, the NACK extension item of the coding option can be added to the transmission parameters of the second device. In this way, if the first device can recognize the NACK extension item in the transmission parameters, it will record the media data packets that have not been received during the process of receiving the media data packets sent by the second device, so that these data packets can be requested from the second device again when the first condition is met. In this way, in the UDP transmission scenario, the media data transmission method of the embodiment of the present application can be used to deal with packet loss, thereby improving the transmission quality of the media data, and further improving the display effect of the media data.

[0110] Exemplarily, when the first device is a media server and the second device is a streaming media sender device, when the media server needs to obtain media data of the streaming media sender device, the media server can obtain the transmission parameters of the streaming media sender device and receive the media data packets sent by the streaming media sender device, wherein the transmission parameters of the streaming media sender device include a negative acknowledgment NACK extension item of the encoding option, so that when the media server can identify the NACK extension item in the transmission parameters of the streaming media sender device, it records the media data packets that it has not received, and when certain conditions are met, sends a retransmission request to the streaming media sender device, wherein 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 sender device.

[0111] It can be seen that the embodiment of the present application provides a solution for processing packet loss in the process of transmitting data packets from a streaming media sending device to a media server, thereby improving the transmission quality of media data and further improving the display effect of media data.

[0112] Exemplarily, when the first device is a streaming media receiving device and the second device is a media server, when the streaming media receiving device needs to obtain media data from the media server, the streaming media receiving device can obtain the transmission parameters of the streaming media server and receive media data packets sent by the streaming media server, wherein the transmission parameters of the media server include a negative acknowledgment NACK extension item of the encoding option, so that when the streaming media receiving device can identify the NACK extension item in the transmission parameters of the media server, it records the media data packets that it has not received, and when certain conditions are met, sends a retransmission request to the media server, wherein the retransmission request is used to re-request the media data packets that the streaming media receiving device has not received, thereby receiving the media data packets requested by the retransmission request resent by the media server.

[0113] It can be seen that the embodiment of the present application provides a solution for processing packet loss in the process of transmitting data packets from a media server to a streaming media receiving device, thereby further improving the transmission quality of media data and further improving the display effect of media data.

[0114] Optionally, the method further comprises:

[0115] Acquire a transmission parameter of the first device, wherein the transmission parameter of the first device includes a NACK extension item of a coding option, a first value, and a second value, where the first value and the second value are used to identify different synchronization source SSRC channels;

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

[0117] In a case where a NACK extension item of a transmission parameter of the first device can be identified, sending a media data packet to the first device through the SSRC channel identified by the first value;

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

[0119] In a case where the NACK extension item of the transmission parameter of the first device can be identified, the media data packet requested by the retransmission request is resent to the first device through the SSC channel identified by the second value.

[0120] Among them, if the transmission parameters of the first device include the NACK extension item of the coding 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] It can be seen from this that in the embodiment of the present application, the above-mentioned first value and second value can also be added to the transmission parameters of the first device to identify two SSRC channels. In this way, during the normal transmission of the data packet between the first device and the second device (i.e., the first transmission), the SSRC channel identified by the first value is used, and the SSRC channel identified by the second value is used during retransmission, thereby facilitating the statistics of indicators such as the retransmission rate.

[0122] Exemplarily, a specific line may be added to the transmission parameter (ie, the SDP message body) to indicate the added first value and second value, as shown below:

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

[0124] y=0100000001.

[0125] Among them, "y=0100000001" represents the "y" line in the SDP message body in 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] In addition, when the second device is able to recognize the NACK extension item in the transmission parameters of the first device, the second device can use the added specific row, thereby ignoring the y row in the prior art; when the second device cannot recognize the NACK extension item in the transmission parameters of the first device, the second device can ignore the added specific row, thereby using the y row in the prior art.

[0127] In addition, it should be noted that in the prior art, when using web page playback, each platform utilizes browser plug-ins, or WASM software solution + Canvas (video rendering) + AudioContext (audio playback) solutions, but does not use the browser's own audio and video playback capabilities, such as Media Source Extensions (MSE) and Web Real-Time Communications (WebRTC). As a result, the playback technologies between platforms vary greatly or are completely incompatible. What's worse, there are problems such as audio and video asynchrony, high performance overhead, and unclear debugging methods.

[0128] Among them, WASM software decoding refers to the process of using WebAssembly technology to implement video decoding; 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 the present application, by adding the AVPF option to the transmission parameters (i.e., the SDP message body) of the first device and the second device, these transmission parameters can include more WebRTC technical points, such as the NACK feedback mechanism, so that the WebRTC SFU capability can be integrated into the media server, and the WebRTC playback capability natively supported by the browser can be utilized to improve the playback effect, reduce platform differences, and standardize the visualization of transmission quality.

[0131] In addition, it should be noted that the manner of recording the unreceived media data packets in the text is not limited to the list form, and any other form in the prior art may also be adopted.

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

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

[0134] Step 1: The streaming media receiving device sends a request (Invite) signaling to the SIP server, and carries the SDP (also called Offer) message body-1 of the streaming media receiving device.

[0135] Among them, SDP message body-1 adds AVPF option in m lines (for details, please refer to the above description) based on the content included in the prior art (such as the address of the streaming media receiving device, the supported encoding types, etc.), and adds a line of RTCP NACK extension item for each encoding option; the PT of the RTCP NACK extension item is consistent with the PT of the encoding option corresponding to the extension item;

[0136] In addition, a specific line "a=ssrc-group:FID" is added before the y line of the SDP message body-1. The first value carried by the specific line (for example, 0100000001) is the SSRC of RTP (that is, the same as y, and the purpose of retaining the y line is to be compatible with the old protocol), and the second value (for example, 0100000002) is the SSRC of the retransmitted RTP packet (that is, the retransmitted packet uses a different SSRC channel to facilitate the statistics of 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 to the media server. It should be noted that the Invite signaling does not carry an SDP message body, but instead notifies the media server to generate an SDP for waiting to receive the stream from the streaming media sender device.

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

[0139] Among them, Offer and Answer are aliases for SDP types in the WebRTC signaling negotiation process.

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

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

[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. It can be seen that through step 6, the SDP message body-3 of the streaming media sender device is notified to the media server.

[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 (ie, a data packet of the real-time media stream) to the media server through the SSRC channel identified by the first value.

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

[0146] Among them, for the NACK request of the same packet, the media server can take a backoff process, such as increasing the delay of each transmission by 25%, and not making any more requests when the maximum number of retries (such as 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 value.

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

[0149] The media server can process the retransmission packet as a normal packet according to the received RTP SSRC, such as removing it from the NACK list, counting the retransmission rate, etc.

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

[0151] Step 12: The media server parses the SDP message body -1. If it carries the AVPF option, the NACK extension line and the extended channel line "a=ssrc-group:FID", it means that it supports the NACK extension. When generating the SDP (also called Answer) message body -4, the media server adds the extension line accordingly and responds (i.e., 200OK).

[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 feeds back 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 media streams.

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

[0156] It should be noted that the media server can cache each sent RTP packet into a sent queue and update the sending time so as to retrieve it for retransmission.

[0157] Step 17: The streaming media receiving device maintains a missing RTP packet list (called NACK list) according to the SN of the received RTP packet, and sends a NACK request to the media server through the RTCP channel according to a certain strategy (such as SN-based inspection 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 backoff processing, such as increasing the delay of each transmission by 25%, and not requesting again when the maximum number of retries (such as 10 times) is exceeded.

[0159] Step 18: The media server device retransmits the requested RTP packet through the SSRC channel identified by the second value according to the NACK request.

[0160] It should be noted that when the media server receives a NACK request for an RTP packet, it will retransmit it only if the time since the last sending of the packet exceeds one RTT, thereby reducing invalid retransmissions.

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

[0162] The streaming media receiving device can process the retransmission packet as a normal packet according to the received RTP SSRC, such as removing it from the NACK list, counting the retransmission rate, etc.

[0163] In addition, it should be noted that by adding the NACK extension of RTCP corresponding to the coding option in the SDP message body involved in this embodiment, more WebRTC technical points can be included in these SDP message bodies. It can be seen that this embodiment can integrate WebRTC SFU capabilities in the media server and use the WebRTC playback capabilities natively supported by the browser to improve the playback effect, reduce platform differences, and standardize the visualization of transmission quality.

[0164] It can be understood that this implementation method is applicable to the platform based on GB / T 28181 protocol, which uses UDP protocol for real-time video and audio on demand, historical video and audio playback, and historical video and audio file downloading scenarios.

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

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

[0167] 2. Integrate WebRTC SFU capabilities in the media server of the GB / T 28181 platform, use the WebRTC playback capabilities natively supported by the browser to improve the playback effect, reduce platform differences, and standardize the visualization of transmission quality.

[0168] The above describes the media data transmission method provided in the embodiment of the present application. The following will describe the media data transmission device provided in the embodiment of the present application in conjunction with the accompanying drawings.

[0169] See also Figure 4 The embodiment of the present application further provides a media data transmission device, applied to a first device, the device comprising:

[0170] A first acquisition module 401 is configured to acquire, when the first device needs to acquire media data of a second device, a transmission parameter of the second device, wherein the transmission parameter of the second device includes a negative acknowledgement NACK extension item of a coding option;

[0171] A first receiving module 402 is configured to receive a media data packet sent by the second device, and record a media data packet that is not received when a NACK extension item in a transmission parameter of the second device can be identified;

[0172] A first sending module 403 is used to send a retransmission request to the second device when a first condition is met, wherein the retransmission request is used to re-request a media data packet that has not been received by the first device;

[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 parameter of the second device further includes a first value and a second value, where the first value and the second value are used to identify different synchronization source SSRC channels;

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

[0176] In a case where a NACK extension item in the transmission parameter of the second device can be identified, receiving a media data packet sent by the second device 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 media payload type of the NACK extension item is the same as the streaming media payload type of the coding option.

[0180] See also Figure 5 The embodiment of the present application further provides a media data transmission device, which is applied to a second device, and the device includes:

[0181] A providing module 501 is configured to provide the transmission parameters of the second device to the first device and send a media data packet to the first device when the first device needs to obtain the media data of the second device, so that the first device records the unreceived media data packet when the first device is able to identify the negative acknowledgement NACK extension item of the coding option included in the transmission parameters of the second device;

[0182] A second receiving module 502 is configured to receive a retransmission request sent by the first device when a first condition is met, wherein the retransmission request is used to re-request a media data packet that has not been received by the first device;

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

[0184] Optionally, the device further comprises:

[0185] A second acquisition module is used to acquire a transmission parameter of the first device, wherein the transmission parameter of the first device includes a NACK extension item of a coding 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 a media data packet to the first device, including:

[0187] In a case where a NACK extension item of a transmission parameter of the first device can be identified, sending a media data packet to the first device through the SSRC channel identified by the first value;

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

[0189] In a case where the NACK extension item of the transmission parameter of the first device can be identified, the media data packet requested by the retransmission request is resent to the first device through the SSC channel identified by the second value.

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

[0191] It should be noted that the division of units in the embodiments of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation. In addition, each functional unit in each embodiment of the present application may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0192] If the integrated unit is implemented in the form of 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 the present application is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) or a processor (processor) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), disk or optical disk and other media that can store program codes.

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

[0194] The embodiment of the present application also provides 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, used for storing computer programs;

[0196] The transceiver 610 is used to receive and send data under the control of the 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;

[0198] When the electronic device serves as the 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.

[0199] Among them, Figure 6 In the embodiment, the bus architecture may include any number of interconnected buses and bridges, specifically linking together various circuits of one or more processors represented by processor 600 and memory represented by memory 620. The bus architecture may also link together various other circuits such as peripherals, voltage regulators, and power management circuits, which are well known in the art and are therefore not further described herein. The bus interface provides an interface. The transceiver 610 may be a plurality of components, namely, a transmitter and a receiver, providing a unit for communicating with various other devices on a transmission medium, which transmission medium may include a wireless channel, a wired channel, an optical cable, and the like. The processor 600 is responsible for managing the bus architecture and general processing, and the memory 620 may store data used by the processor 600 when performing operations.

[0200] The processor 600 may 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 may also adopt a multi-core architecture.

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

[0202] An embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the media data transmission method described in the first aspect above is implemented, or the media data transmission method described in the second aspect above is implemented.

[0203] The computer-readable storage medium can be any available medium or data storage device that can be accessed by the processor, including but not limited to magnetic storage (such as floppy disks, hard disks, magnetic tapes, magneto-optical disks (Magnet-Optica, MO)), etc.), optical storage (such as Compact Disk (CD), Digital Versatile Disc (DVD), Blu-ray Disc (BD), Holographic Versatile Disc (HVD), etc.), and semiconductor memory (such as Read-Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), non-volatile memory (NAND FLASH), solid-state drive (Solid State Disk or Solid State Drive, SSD)), etc.

[0204] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt 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, etc.) that contain computer-usable program code.

[0205] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer executable instructions. These computer executable instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[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 specific manner, so that the instructions stored in the processor readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0207] These processor-executable instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0208] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A method for transmitting media data, characterized in that: Applied to a first device, the method includes: In a case where the first device needs to obtain media data of the second device, obtaining transmission parameters of the second device, wherein the transmission parameters of the second device include a negative acknowledgement NACK extension item of a coding option; receiving a media data packet sent by the second device, and recording a media data packet that is not received if a NACK extension item in a transmission parameter of the second device can be identified; If the first condition is met, sending a retransmission request to the second device, wherein the retransmission request is used to re-request the media data packet not received by the first device; Receive the media data packet requested by the retransmission request resent by the second device.

2. The method according to claim 1, characterized in that The transmission parameter of the second device further includes a first value and a second value, wherein the first value and the second value are used to identify different synchronization signal source SSRC channels; The receiving the media data packet sent by the second device includes: In a case where a NACK extension item in the transmission parameter of the second device can be identified, receiving a media data packet sent by the second device through the SSRC channel identified by the first value; The receiving 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.

3. The method according to claim 1 or 2, characterized in that: The streaming media payload type of the NACK extension item is the same as the streaming media payload type of the coding option.

4. A media data transmission method, characterized in that: Applied to the second device, the method includes: In a case where the first device needs to obtain media data of the second device, providing the transmission parameters of the second device to the first device, and sending a media data packet to the first device, so that the first device records the unreceived media data packet when being able to identify a negative acknowledgement NACK extension item of a coding option included in the transmission parameters of the second device; receiving a retransmission request sent by the first device when a first condition is met, wherein the retransmission request is used to re-request a media data packet that has not been received by the first device; Resending the media data packet requested by the retransmission request to the first device.

5. The method according to claim 4, characterized in that The method further comprises: Acquire a transmission parameter of the first device, wherein the transmission parameter of the first device includes a NACK extension item of a coding option, a first value, and a second value, where the first value and the second value are used to identify different synchronization source SSRC channels; The sending of the media data packet to the first device includes: In a case where a NACK extension item of a transmission parameter of the first device can be identified, sending a media data packet to the first device through the SSRC channel identified by the first value; The resending the media data packet requested by the retransmission request to the first device includes: In a case where the NACK extension item of the transmission parameter of the first device can be identified, the media data packet requested by the retransmission request is resent to the first device through the SSC channel identified by the second value.

6. The method according to claim 4, characterized in that The streaming media payload type of the NACK extension item is the same as the streaming media payload type of the coding option.

7. A media data transmission device, characterized in that: Applied to a first device, the apparatus comprises: A first acquisition module, configured to acquire, when the first device needs to acquire media data of a second device, a transmission parameter of the second device, wherein the transmission parameter of the second device includes a negative acknowledgement NACK extension item of a coding option; A first receiving module, configured to receive a media data packet sent by the second device, and record a media data packet that is not received when a NACK extension item in a transmission parameter of the second device can be identified; A first sending module, 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 a media data packet that has not been received by the first device; The first receiving module is further used to: receive the media data packet requested by the retransmission request resent by the second device.

8. A media data transmission device, characterized in that: Applied to a second device, the apparatus comprises: Providing a module, configured to provide the transmission parameters of the second device to the first device and send a media data packet to the first device when the first device needs to obtain the media data of the second device, so that the first device records the unreceived media data packet when the first device can identify the negative acknowledgement NACK extension item of the coding option included in the transmission parameters of the second device; A second receiving module, configured to receive a retransmission request sent by the first device when a first condition is met, wherein the retransmission request is used to re-request a media data packet that has not been received by the first device; The second sending module is used to resend the media data packet requested by the retransmission request to the first device.

9. An electronic device, characterized in that: Including memory, transceiver, processor: A memory for storing a computer program; a transceiver for sending and receiving data under the control of the processor; a processor for reading the computer program in the memory and executing the media data transmission method according to any one of claims 1 to 3, or executing the media data transmission method according to any one of claims 4 to 6.

10. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by the processor, it implements the media data transmission method as described in any one of claims 1 to 3, or implements the media data transmission method as described in any one of claims 4 to 6.

Images