WO2024056032A1 - 解码、数据传输方法、装置、终端及服务器 - Google Patents

解码、数据传输方法、装置、终端及服务器 Download PDF

Info

Publication number
WO2024056032A1
WO2024056032A1 PCT/CN2023/118839 CN2023118839W WO2024056032A1 WO 2024056032 A1 WO2024056032 A1 WO 2024056032A1 CN 2023118839 W CN2023118839 W CN 2023118839W WO 2024056032 A1 WO2024056032 A1 WO 2024056032A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
rtp data
data packet
multimedia file
target multimedia
Prior art date
Application number
PCT/CN2023/118839
Other languages
English (en)
French (fr)
Inventor
邵胜均
Original Assignee
维沃移动通信有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 维沃移动通信有限公司 filed Critical 维沃移动通信有限公司
Publication of WO2024056032A1 publication Critical patent/WO2024056032A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets

Definitions

  • This application belongs to the field of video transmission technology, and particularly relates to a decoding and data transmission method, device, terminal and server.
  • RTP Real Time Protocol
  • RTCP Real-time Transport Control Protocol
  • UDP User Datagram Protocol
  • the server delivers the pronunciation video to the terminal, and the terminal feedbacks the service quality of the pronunciation video to the server through the RTCP protocol, as shown in Figure 1.
  • the terminal cannot successfully receive the data packet, it needs to request the server to retransmit the data packet. If multiple terminals request the server to retransmit the data packet at the same time, it will cause the server to be overloaded and also As a result, the terminal cannot obtain the lost data packets in time and cannot ensure smooth video playback.
  • Embodiments of the present application provide a decoding and data transmission method, device, terminal and server, which can solve the problem that if multiple terminals request retransmission of data packets from the server, the server will be overloaded and the terminal will be unable to obtain the lost data in time. The package cannot guarantee the smooth playback of the video.
  • embodiments of the present application provide a decoding method, executed by a first terminal, including:
  • the protocol header of the RTP data packet carries the shared code corresponding to the RTP data packet.
  • the shared code is used to indicate the RTP data packet.
  • the arrangement number in the target multimedia file and the shared code corresponding to the RTP data packet are determined by the server based on the obtained initial value of the shared code corresponding to the target multimedia file;
  • the first RTP data packet is the second terminal's data according to the first RTP data packet. Sent by shared code;
  • the first terminal and the second terminal jointly receive the RTP data packet of the target multimedia file sent by the server.
  • embodiments of the present application provide a decoding device, executed by a first terminal, including:
  • the first receiving module is used to receive multiple real-time transmission protocol RTP data packets of the target multimedia file sent by the server.
  • the protocol header of the RTP data packet carries the shared code corresponding to the RTP data packet.
  • the shared code is In order to indicate the sequence number of the RTP data packet in the target multimedia file, the shared code corresponding to the RTP data packet is determined by the server based on the obtained initial value of the shared code corresponding to the target multimedia file;
  • a first sending module configured to send the shared code of the first RTP data packet to the second terminal when it is determined that the RTP data packet does not include the first RTP data packet of the target multimedia file sent by the server;
  • a decoding module configured to receive the first RTP data packet and insert the first RTP data packet into the cache to decode the target multimedia file, where the first RTP data packet is generated by the second terminal according to the first An RTP packet is sent in the shared encoding;
  • the first terminal and the second terminal jointly receive the RTP data packet of the target multimedia file sent by the server.
  • embodiments of the present application provide a data transmission method, executed by a server, including:
  • the shared encoding determines the shared encoding corresponding to each of the multiple real-time transmission protocol RTP data packets of the target multimedia file;
  • the protocol header of the RTP data packet carries a shared code corresponding to the RTP data packet, and the shared code is used to indicate the sequence number of the RTP data packet in the target multimedia file.
  • embodiments of the present application provide a data transmission device, executed by a server, including:
  • the acquisition module is used to obtain the initial value of the shared encoding corresponding to the target multimedia file
  • a determination module configured to determine the shared encoding corresponding to each of the multiple real-time transmission protocol RTP data packets of the target multimedia file according to the initial value of the shared encoding
  • a second sending module configured to send multiple RTP data packets of the target multimedia file to the first terminal and the second terminal;
  • the protocol header of the RTP data packet carries a shared code corresponding to the RTP data packet, and the shared code is used to indicate the sequence number of the RTP data packet in the target multimedia file.
  • inventions of the present application provide an electronic device.
  • the electronic device is a first terminal and includes a processor and a memory.
  • the memory stores programs or instructions that can be run on the processor.
  • inventions of the present application provide an electronic device.
  • the electronic device is a server and includes a processor and a memory.
  • the memory stores programs or instructions that can be run on the processor.
  • the program or instructions When executed by the processor, the steps of the data transmission method described in the third aspect are implemented.
  • embodiments of the present application provide a readable storage medium.
  • Programs or instructions are stored on the readable storage medium.
  • the implementation is as described in the first aspect or the third aspect. steps of the method.
  • embodiments of the present application provide a chip.
  • the chip includes a processor and a communication interface.
  • the communication interface is coupled to the processor.
  • the processor is used to run programs or instructions to implement the first aspect. or the method described in the third aspect.
  • embodiments of the present application provide a computer program product, the program product is stored in a storage medium, and the program product is executed by at least one processor to implement the method described in the first aspect or the third aspect.
  • the receiving server when it is determined that the multiple RTP data packets of the target multimedia file sent by the receiving server do not include the first RTP data packet of the target multimedia file sent by the server, sending the first RTP data packet of the target multimedia file sent by the server to the second terminal.
  • a shared code of an RTP data packet inserting the received first RTP data packet sent by the second terminal according to the shared code of the first RTP data packet into the cache to decode the target multimedia file; thus, it is possible to avoid The server requests to retransmit the data packet, causing the server to be overloaded and the terminal cannot obtain the lost data packet in time.
  • the terminal By obtaining the lost data packet from other terminals, it is ensured that the terminal can obtain the complete RTP data packet of the target multimedia file in time, ensuring The target multimedia file can be decoded to obtain the complete target multimedia file to ensure smooth playback of the target multimedia file.
  • Figure 1 is a schematic diagram of the interaction process between the server and the terminal
  • Figure 2 is one of the flow diagrams of the decoding method according to the embodiment of the present application.
  • Figure 3 is a schematic diagram of the communication process between the first terminal, the second terminal and the server;
  • FIG. 4 is a schematic structural diagram of an RTP data packet
  • Figure 5 is a schematic diagram of the location of the shared coding calculation module
  • Figure 6 is a schematic flow chart of the data transmission method according to the embodiment of the present application.
  • Figure 7 is a schematic module diagram of a decoding device according to an embodiment of the present application.
  • Figure 8 is a schematic structural diagram of a terminal according to an embodiment of the present application.
  • Figure 9 is a structural block diagram of a terminal according to an embodiment of the present application.
  • Figure 10 is a module schematic diagram of a data transmission device according to an embodiment of the present application.
  • Figure 11 is a structural block diagram of a server according to an embodiment of the present application.
  • first, second, etc. in the description and claims of this application are used to distinguish similar objects and are not used to describe a specific order or sequence. It is to be understood that the figures so used are interchangeable under appropriate circumstances so that the embodiments of the present application can be practiced in orders other than those illustrated or described herein, and that "first,” “second,” etc. are distinguished Objects are usually of one type, and the number of objects is not limited. For example, the first object can be one or multiple.
  • “and/or” in the description and claims indicates at least one of the connected objects, and the character “/" generally indicates that the related objects are in an "or” relationship.
  • the decoding method in this embodiment of the present application includes:
  • Step 201 Receive multiple real-time transmission protocol RTP data packets of the target multimedia file sent by the server, and the protocol header of the RTP data packet carries the shared code corresponding to the RTP data packet;
  • the shared code is used to indicate the sequence number of the RTP data packet in the target multimedia file
  • the shared code corresponding to the RTP data packet is the corresponding code of the target multimedia file obtained by the server.
  • the initial value of the shared encoding is determined.
  • Step 202 If it is determined that the RTP data packet does not include the first RTP data packet of the target multimedia file sent by the server, send the shared code of the first RTP data packet to the second terminal;
  • the first terminal and the second terminal jointly receive the RTP data packet of the target multimedia file sent by the server.
  • Step 203 Receive the first RTP data packet, and insert the first RTP data packet into the cache to decode the target multimedia file.
  • the first RTP data packet is the second terminal's data according to the first RTP
  • the shared encoding of the data packet is sent;
  • the receiving server when it is determined that the multiple RTP data packets of the target multimedia file sent by the receiving server do not include the first RTP data packet of the target multimedia file sent by the server, sending the first RTP to the second terminal.
  • the shared coding of the data packet inserts the received first RTP data packet sent by the second terminal according to the shared coding of the first RTP data packet into the cache to decode the target multimedia file; in this way, the data packet can be lost
  • it can also ensure that the terminal can obtain the complete RTP data packet of the target multimedia file to ensure the smooth playback of the multimedia file.
  • this method can also avoid the server load caused by multiple terminals requesting the retransmission of data packets from the server. Overweight occurs.
  • the target multimedia file mentioned in the embodiment of this application refers to the multimedia service performed by the first terminal together with other terminals including the second terminal.
  • the multimedia service may be audio and/or video services.
  • the video can be understood as a video shared by multiple terminals, and can also be called a shared video.
  • the shared code of the RTP data packet not received by the first terminal is sent to the second terminal, because the same video stream uses a set of shared codes, that is to say, the second terminal determines the third code using the shared codes.
  • a terminal The lost RTP data packet is consistent with the RTP data packet lost by the first terminal determined by the server using the packet sequence of the RTP data packet. This can ensure that the first terminal can reacquire the lost RTP data packet from channels other than the server. Ensure that the terminal can decode and obtain the complete video stream.
  • the method further includes :
  • Step 200 When the packet loss rate of the first terminal meets the first condition, establish a connection with the second terminal;
  • the first condition includes: the packet loss rate is greater than or equal to the first preset threshold;
  • establishing a connection with the second terminal may refer to when the first terminal determines that its packet loss rate is greater than or equal to the first preset threshold. , immediately establishes a connection with the second terminal; of course, in order to avoid misjudgment by the first terminal, the first terminal can also communicate with the second terminal after the packet loss rate is greater than or equal to the first preset threshold for a duration greater than or equal to the first duration.
  • the terminal establishes a connection.
  • the first condition includes that the packet loss rate is greater than or equal to the first preset threshold and the duration for which the packet loss rate is greater than or equal to the first preset threshold is greater than or equal to the first duration. .
  • the first preset threshold and the first duration may be configured, preconfigured, or agreed upon by a protocol.
  • step 200 includes:
  • Step 2001 Receive information about at least one terminal sent by the server
  • the packet loss rate of each terminal in the at least one terminal is less than or equal to the second preset threshold
  • the second preset threshold may be configured, preconfigured, or agreed upon by a protocol.
  • the packet loss rate The number of RTP data packets that have not been received/(the number of RTP data packets that have been received + the number of RTP data packets that have not been received); then the packet loss rate is sent to the server, and the server chooses to lose it among all terminals.
  • the terminal whose packet rate is less than or equal to the second preset threshold then sends the terminal information to the first terminal.
  • the terminal information sent by the server to the first terminal may be the identification of the terminal (for example, terminal index) or the terminal information. IP port address.
  • Step 2002 When the packet loss rate of the first terminal meets the first condition, select a second terminal from the at least one terminal;
  • Step 2003 Establish a connection with the second terminal.
  • the establishment of a connection with the second terminal can be understood as performing P2P hole drilling. If the hole drilling between the first terminal and the second terminal is successful, the first terminal and the second terminal are successfully connected.
  • the first terminal can sort multiple other terminals based on the packet loss rate, and first select the terminal with the lowest packet loss rate in order from low to high packet loss rate to try to connect with it. , after the connection is successful, the first terminal will no longer try to connect with other terminals. If the first terminal does not successfully connect to the terminal with the lowest packet loss rate, then the terminal with the next lowest packet loss rate will be selected to try to connect to it, and so on. until a connection is successfully established with a terminal.
  • This method can ensure that the first terminal can connect to the second terminal with better network quality, thereby increasing the probability that the first terminal obtains the complete video stream.
  • step 202 includes:
  • Step 2021 Determine whether the first RTP data packet has not been received based on the received multiple RTP data packets of the target multimedia file sent by the server;
  • Step 2022 If the first RTP data packet is not received, send the shared code of the first RTP data packet to the second terminal.
  • step 2021 can be further implemented by: based on the shared codes of the received multiple RTP data packets, in the case where the shared codes of the multiple RTP data packets are discontinuous, determine that there is unreceived first RTP data. Bag.
  • RTP data packets are sent continuously in order, when the first terminal receives some RTP data packets, it can infer the unsuccessfully received RTP data packets based on the received data packets. This method can ensure Obtain shared encoding accuracy for lost RTP packets.
  • the server sends multiple RTP data packets to the first terminal and the second terminal, the protocol header of the RTP data packet carries the shared code corresponding to the RTP data packet, and the first terminal performs the processing based on the obtained RTP Whether some RTP data packets are lost can be determined by whether the shared codes of the data packets are continuous. For example, if the shared codes of the RTP data packets received by the first terminal are 101, 103, 104, 105, and 106, then the first terminal can It is determined that the RTP packet with shared encoding 102 was not received.
  • the server before the server sends multiple RTP data packets of the target multimedia file to the first terminal and the second terminal, it needs to obtain the initial value of the shared encoding corresponding to the target multimedia file; according to the shared encoding The initial value determines the shared encoding corresponding to each of the multiple RTP data packets of the target multimedia file, and then sends the multiple RTP data packets.
  • the server obtains the initial value of the shared encoding corresponding to the target multimedia file by: based on the initial value of the shared encoding corresponding to the first multimedia file, the size of the data block of the target multimedia file, and the size of the RTP data packet.
  • the size and the first coefficient determine the initial value of the shared encoding corresponding to the target multimedia file;
  • the first coefficient is determined by the size of the data block of the target multimedia file and the size of the RTP data packet.
  • the first multimedia file is a multimedia file transmitted before the target multimedia file.
  • the initial value of the shared encoding corresponding to the body file, m is the size of the data block of the target multimedia file, and p is the size of the RTP data packet.
  • a unified identifier is assigned to the RTP data packet to ensure that different terminals have a consistent understanding of the RTP data packet.
  • the protocol header of each RTP data packet sent by the server to the first terminal includes a packet sequence number.
  • the packet sequence number is used to indicate the sequence number of the RTP data packet sent by the server to the first terminal. Because different terminals access The server time may be different, so the same data packet sent by the server to different terminals may have different packet sequence numbers.
  • the first terminal sends the shared code of the first RTP data packet to the second terminal. At the same time, the packet sequence number of the first RTP data packet can also be sent to the server, and then the first terminal waits for the feedback of the first RTP data packet.
  • the terminal If the terminal first receives the first RTP data packet sent by the second terminal, the first terminal inserts the received first RTP data packet sent by the second terminal into the cache to decode the target multimedia file; if the terminal first receives The first RTP data packet retransmitted by the server, then the first terminal inserts the received retransmitted first RTP data packet into the cache to decode the target multimedia file; by obtaining the data packet from the second terminal and the server at the same time, Added a way to obtain data packets to avoid the situation where the server is overloaded due to a simple server request to retransmit data packets and the terminal cannot obtain the lost data packets in time. It can ensure that the first terminal obtains the lost data packets in time and ensures the playback of the video. Smooth.
  • the specific implementation process includes:
  • packet loss rate lost data packets/total data packets.
  • Each terminal will report its own packet loss situation in real time, and the system will report it every interval (such as 10s ), screen out several terminals with the smallest packet loss rate, and the packet loss rate must be less than a certain threshold (such as below 5%), and then deliver the IP port information of the qualified terminals to all terminals (including qualified terminals) Own).
  • Step 2 When the packet loss rate of a terminal (such as terminal 1 in Figure 3) continues to be higher than a certain threshold (such as 20%), the terminal with the best network will be selected in turn to perform P2P hole punching (you can understand the attempt Connect other terminals), if the hole drilling is successful (that is, the two terminals can send data to each other), stop p2p hole drilling with subsequent terminals.
  • a certain threshold such as 20%
  • Step 3 When terminal 1 loses a packet, it sends the shared code of the lost data packet to terminal 2 and obtains the lost data packet from terminal 2.
  • terminal 1 sends the packet sequence number of the lost data packet to terminal 2, there is a high probability that it cannot get the data from terminal 2, or the data it gets is wrong.
  • the reasons are as follows: For example, when terminal 2 joins the conference first , when terminal 1 joins the conference, the RTP packet sequence number of terminal 2 has rotated from 0 to 65535 many times, and terminal 1 has just entered the conference. Although the shared video seen is the same as that of terminal 2, the packet sent to terminal 1 The sequence number starts counting, so the packet sequence numbers of terminal 2 and terminal 1 are completely different at the same time.
  • the RTP data packet with the same sequence number (the packet sequence number of the lost packet from terminal 1) can be found from terminal 2, but the RTP video data is also different. So how can we obtain the correct data from the terminal 2? This problem is solved in four steps in the embodiment of this application.
  • the first step is to extend a field in the RTP header.
  • the X in Figure 4 is used for extension. If The packet sequence number is distinguished. The sequence number of the extension field is later called the shared encoding. If it is other video streams (such as cameras), this field defaults to 0.
  • the second step is to share the encoded I-frame or p-frame (hereinafter referred to as data block) of the video.
  • a new module will be added, which can be called the shared encoding calculation module, as shown in Figure 5.
  • the shared encoding calculation module will not increase with the increase of terminals. It is a shared module like the encoding module.
  • There is a variable v in the shared coding calculation module (0 when the system starts), which records the first initial value of the previous data block.
  • the second initial value v' of the secondary data block (variable v').
  • the shared encoding of the first RTP data packet generated is the initial value v'. After that, 1 is added to each RTP data packet generated. If the shared encoding number reaches 65535, starting from 0 again. This can ensure that no matter when and where you enter the meeting, or you enter the meeting and perform other actions (such as exiting the background, or watching the camera video stream, etc.), as long as you watch the data stream of the shared video, the shared RTP received will be Data packets, whose shared coding and video data are the same as those of other terminals.
  • the terminal After the terminal receives the RTP data packet, it finds that the RTP data packet is a data stream of the shared video (can be judged by the SSRC field in Figure 4). The received data will be put into the cache in turn, and try to frame it. , and at the same time, put the received shared RTP data packets into a special shared cache pool (used by other terminals to obtain lost data).
  • the shared cache pool has a priority order (sorted according to the shared encoding), and only caches 2 seconds of shared data. .
  • Step 4 In the previous steps, we have already introduced how terminal 1 found terminal 2 and successfully made a hole with terminal 2. If terminal m finds that the RTP data packet with packet sequence number 123 is lost (the RTP data packets that have been received have packet sequence numbers 121 and 124), by reading the extension fields of packets 121 and 124, it knows that the shared codes are 4671 and 124 respectively. 4673, so the shared code of the missing 123 packages is 4672. Terminal 1 notifies Terminal 2 through the P2P channel that Terminal 1 is missing the RTP packet with shared code 4672, as shown in Figure 3. Terminal 1 receives the RTP data packet from Terminal 2 and inserts it into the ordered buffer for decoding according to the packet sequence number.
  • the embodiments of this application are mainly used in video conference sharing scenarios to increase the solution of obtaining lost RTP data packets from other terminals, thereby increasing the probability of terminals obtaining lost RTP data packets, and also speeding up the speed of terminals obtaining lost RTP data packets, thus Ensure the real-time and smoothness of shared videos.
  • the data transmission method in the embodiment of the present application is executed by the server and includes:
  • Step 601 Obtain the initial value of the shared encoding corresponding to the target multimedia file
  • Step 602 Determine the shared encoding corresponding to each of the multiple real-time transmission protocol RTP data packets of the target multimedia file according to the initial value of the shared encoding;
  • Step 603 Send multiple RTP data packets of the target multimedia file to the first terminal and the second terminal;
  • the protocol header of the RTP data packet carries a shared code corresponding to the RTP data packet, and the shared code is used to indicate the sequence number of the RTP data packet in the target multimedia file.
  • the obtaining the initial value of the shared encoding corresponding to the target multimedia file includes:
  • the first coefficient is determined by the size of the data block of the target multimedia file and the size of the RTP data packet.
  • the first multimedia file is a multimedia file transmitted before the target multimedia file.
  • the method also includes:
  • Information about at least one terminal that meets a second condition is sent to the first terminal, and the second condition includes: the packet loss rate is less than or equal to a second preset threshold.
  • the execution subject may be a device, or a control module in the device for executing the method.
  • the device execution method is taken as an example to describe the device provided by the embodiments of this application.
  • this embodiment of the present application also provides a decoding device 700, which is applied to the first terminal and includes:
  • the first receiving module 701 is used to receive multiple real-time transmission protocol RTP data packets of the target multimedia file sent by the server.
  • the protocol header of the RTP data packet carries the shared code corresponding to the RTP data packet.
  • the shared code Used to indicate the sequence number of the RTP data packet in the target multimedia file, and the shared code corresponding to the RTP data packet is determined by the server based on the obtained initial value of the shared code corresponding to the target multimedia file;
  • the first sending module 702 is configured to send the shared code of the first RTP data packet to the second terminal when it is determined that the RTP data packet does not include the first RTP data packet of the target multimedia file sent by the server;
  • Decoding module 703 configured to receive the first RTP data packet and insert the first RTP data packet into the cache to decode the target multimedia file.
  • the first RTP data packet is generated by the second terminal according to The shared encoding of the first RTP packet is sent;
  • the first terminal and the second terminal jointly receive the RTP data packet of the target multimedia file sent by the server.
  • the first sending module 702 includes:
  • a determining unit configured to determine whether the first RTP data packet has not been received based on the received multiple RTP data packets of the target multimedia file sent by the server;
  • a sending unit configured to send the shared code of the first RTP data packet to the second terminal when the first RTP data packet is not received.
  • the determining unit is used for:
  • the device also includes:
  • a connection module configured to establish a connection with the second terminal when the packet loss rate of the first terminal meets a first condition, where the first condition includes: the packet loss rate is greater than or equal to a first preset threshold.
  • connection module includes:
  • a receiving unit configured to receive information about at least one terminal sent by the server, each of the at least one terminal The packet loss rate of each terminal is less than or equal to the second preset threshold;
  • a selection unit configured to select a second terminal from the at least one terminal when the packet loss rate of the first terminal satisfies the first condition
  • An establishing unit is configured to establish a connection with the second terminal.
  • this device embodiment is a device that corresponds one-to-one to the above-mentioned decoding method embodiment applied to the first terminal side. All implementation methods in the above-mentioned method embodiments are applicable to the embodiment of the device, and can also achieve Same technical effect.
  • the decoding device in the embodiment of the present application may be a device, or may be a component, integrated circuit, or chip in a terminal.
  • the device may be a mobile electronic device or a non-mobile electronic device.
  • the mobile electronic device may be a mobile phone, a tablet computer, a notebook computer, a handheld computer, a vehicle-mounted electronic device, a wearable device, an ultra-mobile personal computer (UMPC), a netbook or a personal digital assistant (personal digital assistant).
  • UMPC ultra-mobile personal computer
  • PDA personal digital assistant
  • non-mobile electronic devices can be servers, network attached storage (Network Attached Storage, NAS), personal computers (personal computers, PC), televisions (television, TV), teller machines or self-service machines, etc., this application The examples are not specifically limited.
  • the decoding device in the embodiment of the present application may be a device with an operating system.
  • the operating system can be an Android operating system, an ios operating system, or other possible operating systems, which are not specifically limited in the embodiments of this application.
  • the decoding device provided by the embodiment of the present application can implement each process implemented by the method embodiment in Figure 2.
  • this embodiment of the present application also provides a terminal 800.
  • the terminal is a first terminal and includes a processor 801 and a memory 802.
  • a program or instruction running on the processor 801 implements each process of the above decoding method embodiment when executed by the processor 801, and can achieve the same technical effect. To avoid duplication, it will not be described again here.
  • terminals in the embodiments of the present application include the above-mentioned mobile terminals and non-mobile terminals.
  • Figure 9 is a schematic diagram of the hardware structure of a terminal that implements an embodiment of the present application.
  • the terminal 900 includes but is not limited to: a radio frequency unit 901, a network module 902, an audio output unit 903, an input unit 904, a sensor 905, a display unit 906, a user input unit 907, an interface unit 908, a memory 909, a processor 910 and other components. .
  • the terminal 900 may also include a power supply (such as a battery) that supplies power to various components.
  • the power supply may be logically connected to the processor 910 through a power management system, thereby managing charging, discharging, and power consumption through the power management system. Management and other functions.
  • the structure of the electronic device shown in Figure 9 does not constitute a limitation on the electronic device.
  • the electronic device may include more or less components than shown in the figure, or combine certain components, or arrange different components, which will not be described again here. .
  • the radio frequency unit 901 is used for:
  • the protocol header of the RTP data packet carries the shared code corresponding to the RTP data packet.
  • the shared code is used to indicate the RTP
  • the sequence number of the data packet in the target multimedia file, and the shared code corresponding to the RTP data packet is determined by the server based on the obtained initial value of the shared code corresponding to the target multimedia file;
  • Processor 910 configured to receive the first RTP data packet and insert the first RTP data packet into the cache to decode the target multimedia file.
  • the first RTP data packet is generated by the second terminal according to The shared encoding of the first RTP packet is sent;
  • the first terminal and the second terminal jointly receive the RTP data packet of the target multimedia file sent by the server.
  • processor 910 is used to:
  • the radio frequency unit 901 is used for:
  • the shared code of the first RTP data packet is sent to the second terminal.
  • the processor 910 is configured to determine, based on the shared codes of the received multiple RTP data packets, that there is unreceived first RTP data when the shared codes of the multiple RTP data packets are discontinuous. Bag.
  • the radio frequency unit 901 is configured to establish a connection with the second terminal when the packet loss rate of the first terminal satisfies a first condition.
  • the first condition includes: the packet loss rate is greater than or equal to the first preset threshold.
  • the radio frequency unit 901 is configured to: receive information about at least one terminal sent by the server, and the packet loss rate of each terminal in the at least one terminal is less than or equal to the second preset threshold;
  • the processor 910 is configured to select a second terminal from the at least one terminal when the packet loss rate of the first terminal meets the first condition;
  • the radio frequency unit 901 is used to establish a connection with the second terminal.
  • the first RTP data is sent to the second terminal.
  • the received first RTP data packet sent by the second terminal according to the shared coding of the first RTP data packet is inserted into the cache to decode the target multimedia file; in this way, repeated requests to the server can be avoided. Transmitting data packets causes the server to be overloaded and the terminal cannot obtain the lost data packets in time.
  • the terminal By obtaining the lost data packets from other terminals, it is ensured that the terminal can obtain the complete RTP data packet of the target multimedia file in time, ensuring that the target multimedia file is It can decode and obtain the complete target multimedia file to ensure smooth playback of the target multimedia file.
  • the input unit 904 may include a graphics processing unit (GPU) 9041 and a microphone 9042.
  • the graphics processor 9041 is responsible for the image capture device (GPU) in the video capture mode or the image capture mode. Process the image data of still pictures or videos obtained by cameras (such as cameras).
  • Display unit 906 A display panel 9061 may be included, and the display panel 9061 may be configured in the form of a liquid crystal display, an organic light emitting diode, or the like.
  • the user input unit 907 includes a touch panel 9071 and other input devices 9072. Touch panel 9071, also known as touch screen.
  • the touch panel 971 may include two parts: a touch detection device and a touch controller.
  • Other input devices 9072 may include but are not limited to physical keyboards, function keys (such as volume control keys, switch keys, etc.), trackballs, mice, and joysticks, which will not be described again here.
  • Memory 909 may be used to store software programs as well as various data, including but not limited to application programs and operating systems.
  • the processor 910 can integrate an application processor and a modem processor, where the application processor mainly processes the operating system, user interface, application programs, etc., and the modem processor mainly processes wireless communications. It can be understood that the above modem processor may not be integrated into the processor 910.
  • Embodiments of the present application also provide a readable storage medium, which stores a program or instructions.
  • a program or instructions When the program or instructions are executed by a processor, each of the above-mentioned decoding method embodiments applied to the first terminal side is implemented. The process can achieve the same technical effect. To avoid repetition, it will not be described again here.
  • the processor is the processor in the first terminal described in the above embodiment.
  • the readable storage media includes computer-readable storage media, such as computer read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disks or optical disks, etc.
  • this embodiment of the present application also provides a data transmission device 1000, which is applied to a server and includes:
  • the acquisition module 1001 is used to obtain the initial value of the shared encoding corresponding to the target multimedia file
  • Determining module 1002 configured to determine the shared encoding corresponding to each of the multiple real-time transmission protocol RTP data packets of the target multimedia file according to the initial value of the shared encoding;
  • the second sending module 1003 is used to send multiple RTP data packets of the target multimedia file to the first terminal and the second terminal;
  • the protocol header of the RTP data packet carries a shared code corresponding to the RTP data packet, and the shared code is used to indicate the sequence number of the RTP data packet in the target multimedia file.
  • the acquisition module 1001 is used for:
  • the first coefficient is determined by the size of the data block of the target multimedia file and the size of the RTP data packet.
  • the first multimedia file is a multimedia file transmitted before the target multimedia file.
  • the device also includes:
  • the second receiving module is used to receive packet loss rates sent by multiple terminals
  • the third sending module is configured to send the information of at least one terminal that meets the second condition to the first terminal.
  • the second condition includes: the packet loss rate is less than or equal to the second preset threshold.
  • the device embodiment is a device that corresponds one-to-one to the above-mentioned data transmission method embodiment applied to the server side. All implementation methods in the above-mentioned method embodiment are applicable to the device embodiment and can achieve the same technical effect.
  • the data transmission device in the embodiment of the present application may be a device with an operating system.
  • the operating system can be Android
  • the (Android) operating system can be an ios operating system or other possible operating systems, which are not specifically limited in the embodiments of this application.
  • the data transmission device provided by the embodiment of the present application can implement each process implemented by the method embodiment in Figure 6.
  • this embodiment of the present application also provides a server 1100, including a processor 1101, a memory 1102, and programs or instructions stored on the memory 1102 and executable on the processor 1101.
  • a server 1100 including a processor 1101, a memory 1102, and programs or instructions stored on the memory 1102 and executable on the processor 1101.
  • the program or instruction is executed by the processor 1101, each process of the above-mentioned data transmission method embodiment applied to the server side is implemented, and the same technical effect can be achieved. To avoid duplication, the details will not be described here.
  • An embodiment of the present application further provides a chip.
  • the chip includes a processor and a communication interface.
  • the communication interface is coupled to the processor.
  • the processor is used to run programs or instructions to implement the above data transmission method embodiment. Each process can achieve the same technical effect. To avoid duplication, it will not be described again here.
  • the embodiment of the present application further provides a computer program product, which is stored in a storage medium.
  • the program product is executed by at least one processor to implement each process of the above data transmission method embodiment, and can achieve the same technology. The effect will not be described here to avoid repetition.
  • chips mentioned in the embodiments of this application may also be called system-on-chip, system-on-a-chip, system-on-a-chip or system-on-chip, etc.
  • the methods of the above embodiments can be implemented by means of software plus the necessary general hardware platform. Of course, it can also be implemented by hardware, but in many cases the former is better. implementation.
  • the technical solution of the present application can be embodied in the form of a computer software product that is essentially or contributes to the existing technology.
  • the computer software product is stored in a storage medium (such as ROM/RAM, disk , optical disk), including several instructions to cause a terminal (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in various embodiments of this application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本申请公开了一种解码、数据传输方法、装置、终端及服务器，属于视频传输技术领域。该数据传输方法，包括：接收服务器发送的目标多媒体文件的多个RTP数据包，RTP数据包的协议头部中携带RTP数据包对应的共享编码；在确定RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送第一RTP数据包的共享编码；接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行目标多媒体文件的解码，第一RTP数据包为第二终端根据第一RTP数据包的共享编码发送的；第一终端与第二终端共同接收服务器发送的目标多媒体文件的RTP数据包。

Description

解码、数据传输方法、装置、终端及服务器
相关申请的交叉引用
本申请主张在2022年09月16日在中国提交的中国专利申请No.202211127820.8的优先权，其全部内容通过引用包含于此。
技术领域
本申请属于视频传输技术领域，特别涉及一种解码、数据传输方法、装置、终端及服务器。
背景技术
在视频会议场景，为保障音视频的实时性，实时协议(Real Time Protocol，RTP)音视频数据包和实时传输协议(Real-time Transport Control Protocol，RTCP)控制包同时通过底层用户数据报协议(User Datagram Protocol，UDP)进行传输的。UDP传输是不可靠的，发出去的数据不保障能到达目的地，特别是在网络抖动或弱网下，数据会严重丢失。为保障声音的连续性和视频的流畅性，客户端与服务器通过丢包重传来解决数据丢失问题。
服务器下发音视频给终端，终端通过RTCP协议向服务器反馈下发音视频的服务质量如何，如图1所示。
但是在网络质量不好的情况，若终端不能成功接收到数据包需要向服务器请求数据包的重传，若多个终端同时向服务器请求数据包的重传，会造成服务器负载过重，也会造成终端无法及时获取丢失的数据包无法保证视频流畅播放。
发明内容
本申请实施例提供一种解码、数据传输方法、装置、终端及服务器，能够解决若多个终端均向服务器请求数据包的重传，会造成服务器负载过重进而使得终端无法及时获取丢失的数据包无法保证视频流畅播放的问题。
第一方面，本申请实施例提供了一种解码方法，由第一终端执行，包括：
接收服务器发送的目标多媒体文件的多个实时传输协议RTP数据包，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号，所述RTP数据包对应的共享编码为所述服务器根据获取的所述目标多媒体文件对应的共享编码的初始值确定的；
在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码；
接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行所述目标多媒体文件的解码，所述第一RTP数据包为所述第二终端根据第一RTP数据包的共享编码发送的；
其中，所述第一终端与所述第二终端共同接收所述服务器发送的所述目标多媒体文件的RTP数据包。
第二方面，本申请实施例提供了一种解码装置，由第一终端执行，包括：
第一接收模块，用于接收服务器发送的目标多媒体文件的多个实时传输协议RTP数据包，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号，所述RTP数据包对应的共享编码为所述服务器根据获取的所述目标多媒体文件对应的共享编码的初始值确定的；
第一发送模块，用于在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码；
解码模块，用于接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行所述目标多媒体文件的解码，所述第一RTP数据包为所述第二终端根据第一RTP数据包的共享编码发送的；
其中，所述第一终端与所述第二终端共同接收所述服务器发送的所述目标多媒体文件的RTP数据包。
第三方面，本申请实施例提供了一种数据传输方法，由服务器执行，包括：
获取目标多媒体文件对应的共享编码的初始值；
根据所述共享编码的初始值，确定所述目标多媒体文件的多个实时传输协议RTP数据包中的每一个RTP数据包所对应的共享编码；
向第一终端和第二终端发送目标多媒体文件的多个RTP数据包；
其中，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号。
第四方面，本申请实施例提供了一种数据传输装置，由服务器执行，包括：
获取模块，用于获取目标多媒体文件对应的共享编码的初始值；
确定模块，用于根据所述共享编码的初始值，确定所述目标多媒体文件的多个实时传输协议RTP数据包中的每一个RTP数据包所对应的共享编码；
第二发送模块，用于向第一终端和第二终端发送目标多媒体文件的多个RTP数据包；
其中，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号。
第五方面，本申请实施例提供了一种电子设备，所述电子设备为第一终端，包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第一方面所述的解码方法的步骤。
第六方面，本申请实施例提供了一种电子设备，所述电子设备为服务器，包括处理器和存储器，所述存储器存储可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如第三方面所述的数据传输方法的步骤。
第七方面，本申请实施例提供了一种可读存储介质，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如第一方面或第三方面所述的方法的步骤。
第八方面，本申请实施例提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如第一方面或第三方面所述的方法。
第九方面，本申请实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如第一方面或第三方面所述的方法。
在本申请实施例中，通过在确定接收服务器发送的目标多媒体文件的多个RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码，将接收到的所述第二终端根据第一RTP数据包的共享编码发送的第一RTP数据包插入缓存中进行所述目标多媒体文件的解码；以此能够避免向服务器请求重传数据包造成服务器负载过重导致终端不能及时获取丢失的数据包的情况出现，通过向其他终端获取丢失的数据包保证终端能够及时获取到目标多媒体文件的完整的RTP数据包，保证目标多媒体文件能够解码获取完整的目标多媒体文件，以保证目标多媒体文件播放的流畅。
附图说明
图1是服务器与终端交互过程示意图；
图2是本申请实施例的解码方法的流程示意图之一；
图3是第一终端与第二终端、服务器的通信过程示意图；
图4是RTP数据包的结构示意图；
图5是共享编码计算模块所处位置示意图；
图6是本申请实施例的数据传输方法的流程示意图；
图7是本申请实施例的解码装置的模块示意图；
图8是本申请实施例的终端的简略结构示意图；
图9是本申请实施例的终端的结构框图；
图10是本申请实施例的数据传输装置的模块示意图；
图11是本申请实施例的服务器的结构框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实 施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。
本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。
下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的解码、数据传输方法、装置、终端及服务器进行详细地说明。
如图2所示，本申请实施例的解码方法，包括：
步骤201，接收服务器发送的目标多媒体文件的多个实时传输协议RTP数据包，所述RTP数据包的协议头部中携带所述RTP数据包对应共享编码；
需要说明的是，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号，所述RTP数据包对应的共享编码为所述服务器根据获取的所述目标多媒体文件对应的共享编码的初始值确定的。
步骤202，在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码；
需要说明的是，所述第一终端与所述第二终端共同接收所述服务器发送的所述目标多媒体文件的RTP数据包。
步骤203，接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行所述目标多媒体文件的解码，所述第一RTP数据包为所述第二终端根据第一RTP数据包的共享编码发送的；
需要说明的是，通过在确定接收服务器发送的目标多媒体文件的多个RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码，将接收到的所述第二终端根据第一RTP数据包的共享编码发送的第一RTP数据包插入缓存中进行所述目标多媒体文件的解码；以此能够在丢失数据包的情况下，也能保证终端能够获取到目标多媒体文件的完整的RTP数据包，以保证多媒体文件播放的流畅，同时此种方式还能避免多个终端向服务器请求数据包的重传造成服务器负载过重的情况出现。
需要说明的是，本申请实施例中所说的目标多媒体文件指的是第一终端与包括第二终端在内的其他终端一同进行的多媒体服务，该多媒体服务可以为音频和/或视频服务，例如多个终端一起进行视频通话，该视频可以理解为是多个终端一起共享的视频，也可以称为共享视频。
本申请实施例中通过向第二终端发送第一终端未接收到的RTP数据包的共享编码，因同一个视频流采用一套共享编码，也就是说，第二终端利用共享编码所确定的第一终端 丢失的RTP数据包与服务器利用RTP数据包的包序列所确定的第一终端丢失的RTP数据包是一致的，以此可以保证第一终端能够从除了服务器的渠道重新获取丢失的RTP数据包，保证终端能够解码获取到完整的视频流。
可选地，为了保证第一终端能够与第二终端通信，本申请的至少一个实施例中，在第一终端向第二终端发送第一RTP数据包的共享编码之前，所述方法，还包括：
步骤200，在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接；
其中，所述第一条件包括：丢包率大于或等于第一预设阈值；
可选地，在第一终端的丢包率满足第一条件的情况下，与第二终端建立连接可以指的是，当第一终端确定自身的丢包率大于或等于第一预设阈值时，立即与第二终端建立连接；当然为了避免第一终端的误判，第一终端还可以在丢包率大于或等于第一预设阈值的持续时间大于或等于第一时长之后再与第二终端建立连接，在此种情况下，可以理解为第一条件同时包括丢包率大于或等于第一预设阈值以及丢包率大于或等于第一预设阈值的持续时长大于或等于第一时长。
可选地，该第一预设阈值、第一时长可以是配置、预配置或协议约定的。
可选地，本申请的至少一个实施例中，所述步骤200的实现方式，包括：
步骤2001，接收所述服务器发送的至少一个终端的信息；
需要说明的是，所述至少一个终端中每个终端的丢包率均小于或等于第二预设阈值；
可选地，该第二预设阈值可以是配置、预配置或协议约定的。
需要说明的是，通常情况下，接入该目标多媒体文件的所有终端均需要基于接收到的多个RTP数据包以及未接收到的RTP数据包，获取终端的丢包率，即丢包率＝未接收到的RTP数据包的个数/(接收到的RTP数据包的个数+未接收到的RTP数据包的个数)；然后将丢包率发送给服务器，服务器在所有终端中选择丢包率小于或等于第二预设阈值的终端，然后将终端的信息发送给第一终端，服务器向第一终端发送的终端的信息可以是终端的标识(例如，终端索引)，也可以是终端的IP端口地址。
步骤2002，在所述第一终端的丢包率满足第一条件的情况下，在所述至少一个终端中选择第二终端；
步骤2003，建立与所述第二终端的连接。
该建立与第二终端的连接可以理解为是进行P2P打洞，若第一终端与第二终端打洞成功，则第一终端与第二终端成功连接。
可选地，在选择第二终端过程中，第一终端可以基于丢包率对多个其他终端进行排序，依次按照丢包率从低到高的顺序先选择丢包率最低的终端尝试与其连接，在连接成功后第一终端便不再与其他终端尝试连接，若第一终端与丢包率最低的终端未连接成功，则再选择丢包率次低的终端尝试与其连接，依此类推，直到与一个终端成功建立连接。此种方式能够保证第一终端能够连接到网络质量较好的第二终端，进而提高第一终端获取到完整视频流的机率。
可选地，本申请的至少一个实施例中，所述步骤202的实现方式包括：
步骤2021，根据接收的所述服务器发送的目标多媒体文件的多个RTP数据包，确定是否未接收到第一RTP数据包；
步骤2022，在未接收到第一RTP数据包的情况下，向所述第二终端发送所述第一RTP数据包的共享编码。
可选地，步骤2021的进一步实现方式为：基于接收到的多个RTP数据包的共享编码，在多个RTP数据包的共享编码不连续的情况下，确定存在未接收到的第一RTP数据包。
需要说明的是，因RTP数据包是按照顺序连续发送的，当第一终端接收到一些RTP数据包后便可以基于接收到的数据包推测出未成功接收的RTP数据包，此种方式能够保证获取的丢失的RTP数据包的共享编码的准确性。
可选地，服务器向所述第一终端和第二终端发送多个RTP数据包，所述RTP数据包的协议头部携带所述RTP数据包对应的共享编码，第一终端在基于获取的RTP数据包的共享编码是否连续便可确定是否丢了某一些RTP数据包，例如，第一终端接收到的RTP数据包的共享编码分别为101、103、104、105、106，则第一终端可以确定未接收到共享编码为102的RTP数据包。
还需要说明的是，服务器在向第一终端和第二终端发送目标多媒体文件的多个RTP数据包之前，需要先获取所述目标多媒体文件对应的共享编码的初始值；根据所述共享编码的初始值，确定所述目标多媒体文件的多个RTP数据包中的每一个RTP数据包所对应的共享编码，然后再进行多个RTP数据包的发送。
可选地，服务器获取目标多媒体文件对应的共享编码的初始值的方式为：根据第一多媒体文件对应的共享编码的初始值、所述目标多媒体文件的数据块的大小、RTP数据包的大小以及第一系数，确定所述目标多媒体文件对应的共享编码的初始值；
其中，所述第一系数由所述目标多媒体文件的数据块的大小和RTP数据包的大小确定，所述第一多媒体文件为位于所述目标多媒体文件之前传输的多媒体文件。
可选地，服务器基于公式v’＝v+m/p+r，确定目标多媒体文件对应的共享编码的初始值，v’为目标多媒体文件对应的共享编码的初始值，v为第一多媒体文件对应的共享编码的初始值，m为目标多媒体文件的数据块的大小，p为RTP数据包的大小，其中，当m/p能整除，r＝0；不能整除，r＝1。
需要说明的，通过在RTP数据包的协议头部的扩展字段增加共享编码的指示，以此为RTP数据包分配统一的标识，保证不同终端对RTP数据包的理解一致。
可选地，服务器向第一终端发送的每一个RTP数据包的协议头部均包括包序号，该包序号用于指示服务器向第一终端发送的RTP数据包的序号，因不同的终端接入服务器的时间可能不一样，因此服务器向不同的终端发送的同一数据包可能包序号也不同，本申请的另一实施例中，在第一终端向第二终端发送第一RTP数据包的共享编码的同时还可以向服务器发送第一RTP数据包的包序号，然后第一终端等待第一RTP数据包的反馈， 若终端先接收到第二终端发送第一RTP数据包，则第一终端将接收到的第二终端发送的第一RTP数据包插入缓存中进行所述目标多媒体文件的解码；若终端先接收到服务器重传的第一RTP数据包，则第一终端将接收到的重传的第一RTP数据包插入缓存中进行所述目标多媒体文件的解码；通过同时向第二终端和服务器获取数据包，增加了获取数据包的途径，避免单纯服务器请求重传数据包造成服务器负载过重导致终端不能及时获取丢失的数据包的情况出现，能够保证第一终端及时获取丢失的数据包，保证视频的播放流畅。
以多个终端进行共享视频通话为例，下面对本申请实施例的具体应用进行详细说明如下。
具体实现过程包括：
步骤一：网络好坏通过丢包率(丢包率＝丢失的数据包/总的数据包)来判断的，每个终端都会实时上报自己的丢包情况，系统会每间隔一段时间(比如10s)，筛选一次丢包率最小的几个终端，且要满足丢包率小于一定阈值(如5％以下)，然后将符合条件的终端的IP端口信息下发到所有终端(包括符合条件的终端自己)。
步骤二：当某个终端(比如图3中的终端1)的丢包率持续高于某个阈值(比如20％)，就会依次选择网络最好的终端，进行P2P打洞(可以理解尝试连接其它终端)，如果打洞成功(即两个终端可以互发数据)，就停止与后续终端的p2p打洞。
步骤三：当终端1丢包后，向终端2发送丢失的数据包的共享编码，从终端2获取丢失的数据包。
这里需要说明的是，若终端1向终端2发送丢失数据包的包序号，其大概率不能从终端2拿到数据，或者拿到的数据也是错误的，原因如下：比如当终端2先加入会议，当终端1加入会议时，终端2的RTP数据包序号已经从0到65535轮转好多次了，而终端1刚进入会议，虽然看到的共享视频和终端2一样，但是发给终端1的包序号才开始计数，所以同一时刻终端2和终端1的包序号完全不同。假如包序号相隔很近，由于会缓存，所以能从终端2中找到序号相同(与终端1丢失包的包序号)的RTP数据包，但RTP的视频数据也是不同的。那么怎么才能从终端2那里获取到正确的数据呢，本申请实施例中通过四步来解决这个问题。
第一步，首先在RTP头部扩展一个字段，图4中的X就是用于扩展，如果X＝1就是扩展一个字段，扩展的这个字段用于记录共享视频数据包的序号，为和RTP数据包序号区分开，扩展字段这个序号后续称之为共享编码，如果是其它视频流(如摄像头)该字段默认为0。
第二步，共享视频经过编码后的I帧或p帧(后续简称数据块)，在送入RTP数据包生成前，会新增一个模块可以称之为共享编码计算模块，如图5所示，该共享编码计算模块不会随着终端的增加而增加，它跟编码模块一样，是一个共用模块。共享编码计算模块中有一个变量v(系统启动时为0)，它记录之前一个数据块的第一初始值，当数据块送入共享编码计算模块后，根据送入数据块的大小，计算本次数据块的第二初始值v’(变量v’ 的计算如下：v’＝v+m/p+r，其中m为本次数据块的大小，p为一个RTP视频数据的大小。当m/p能整除，r＝0；不能整除，r＝1。当v’大于65535时，v’＝v’–65536)，然后将v’赋值给v，初始值v’和数据块送入所有需要共享视频的数据流(观看共享视频的终端)的RTP数据包生成模块之后，数据块会被拆分，生成RTP数据包，生成的第一个RTP数据包的共享编码就是初始值v’，之后每生成一个RTP数据包就加1，如果共享编码数字到达65535，又从0开始。这样就可以保障，无论何时何地进入会议，亦或进入会议做了其它动作(比如退后台，或观看摄像头视频流等等)，只要再观看共享视频的数据流流，收到的共享RTP数据包，其共享编码与视频数据与其它终端都是相同的。
第三步，终端收到RTP数据包后，发现RTP数据包是共享视频的数据流(可以图4中的SSRC字段来判断)，收到的数据会依次放入缓存中，并尝试去组帧，同时将收到的共享RTP数据包放入特设共享缓存池(为其他终端来获取丢失数据使用)，共享缓存池有优先后顺序(根据共享编码排序)，也只缓存2秒的共享数据。
第四步，在前面的步骤中已经介绍过终端1怎么如何找到终端2的，并且和终端2打洞成功。假如终端m发现丢失了包序号为123的RTP数据包(已经收到的RTP数据包，包序号为121和124)，通过读取121和124包的扩展字段，知道共享编码分别是为4671和4673，所以缺失的123包，其共享编码为4672。终端1通过P2P通道告知终端2，终端1缺失共享编码为4672的RTP数据包，如图3所示。终端1接收到终端2的RTP数据包，根据包序号插入有序缓存中进行解码。
综上可知，本申请实施能够实现以下效果：
本申请实施例主要应用于视频会议共享场景下，增加从其它终端获取丢失RTP数据包的方案，从而使终端提高获取丢失RTP数据包的概率，也加快了终端获取丢失RTP数据包的速度，从而保障共享视频的实时性和流畅性。
对应于第一终端侧的实现方式，如图6所示，本申请实施例的数据传输方法，由服务器执行，包括：
步骤601，获取目标多媒体文件对应的共享编码的初始值；
步骤602，根据所述共享编码的初始值，确定所述目标多媒体文件的多个实时传输协议RTP数据包中的每一个RTP数据包所对应的共享编码；
步骤603，向第一终端和第二终端发送目标多媒体文件的多个RTP数据包；
其中，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号。
可选地，所述获取目标多媒体文件对应的共享编码的初始值，包括：
根据第一多媒体文件对应的共享编码的初始值、所述目标多媒体文件的数据块的大小、RTP数据包的大小以及第一系数，确定所述目标多媒体文件对应的共享编码的初始值；
其中，所述第一系数由所述目标多媒体文件的数据块的大小和RTP数据包的大小确定，所述第一多媒体文件为位于所述目标多媒体文件之前传输的多媒体文件。
可选地，所述的方法，还包括：
接收多个终端发送的丢包率；
将满足第二条件的至少一个终端的信息发送给第一终端，所述第二条件包括：丢包率小于或等于第二预设阈值。
需要说明的是，上述实施例中所有关于服务器侧的描述均适用于该应用于服务器侧的数据传输方法的实施例中，也能达到相同的技术效果，在此不再赘述。
需要说明的是，本申请实施例提供的方法，执行主体可以为装置，或者该装置中的用于执行方法的控制模块。本申请实施例中以装置执行方法为例，说明本申请实施例提供的装置。
如图7所示，本申请实施例还提供一种解码装置700，应用于第一终端，包括：
第一接收模块701，用于接收服务器发送的目标多媒体文件的多个实时传输协议RTP数据包，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号，所述RTP数据包对应的共享编码为所述服务器根据获取的所述目标多媒体文件对应的共享编码的初始值确定的；
第一发送模块702，用于在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码；
解码模块703，用于接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行所述目标多媒体文件的解码，所述第一RTP数据包为所述第二终端根据第一RTP数据包的共享编码发送的；
其中，所述第一终端与所述第二终端共同接收所述服务器发送的所述目标多媒体文件的RTP数据包。
可选地，所述第一发送模块702，包括：
确定单元，用于根据接收的所述服务器发送的目标多媒体文件的多个RTP数据包，确定是否未接收到第一RTP数据包；
发送单元，用于在未接收到第一RTP数据包的情况下，向所述第二终端发送所述第一RTP数据包的共享编码。
可选地，所述确定单元，用于：
基于接收到的多个RTP数据包的共享编码，在多个RTP数据包的共享编码不连续的情况下，确定存在未接收到的第一RTP数据包。
可选地，所述装置，还包括：
连接模块，用于在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接，所述第一条件包括：丢包率大于或等于第一预设阈值。
可选地，所述连接模块，包括：
接收单元，用于接收所述服务器发送的至少一个终端的信息，所述至少一个终端中每 个终端的丢包率均小于或等于第二预设阈值；
选择单元，用于在所述第一终端的丢包率满足第一条件的情况下，在所述至少一个终端中选择第二终端；
建立单元，用于建立与所述第二终端的连接。
需要说明的是，该装置实施例是与上述应用于第一终端侧的解码方法实施例一一对应的装置，上述方法实施例中所有实现方式均适用于该装置的实施例中，也能达到相同的技术效果。
本申请实施例中的解码装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personal digital assistant，PDA)等，非移动电子设备可以为服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(personal computer，PC)、电视机(television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。
本申请实施例中的解码装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。
本申请实施例提供的解码装置能够实现图2的方法实施例实现的各个过程。
可选地，如图8所示，本申请实施例还提供一种终端800，所述终端为第一终端，包括处理器801，存储器802，存储在存储器802上并可在所述处理器801上运行的程序或指令，该程序或指令被处理器801执行时实现上述解码方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
需要说明的是，本申请实施例中的终端包括上述所述的移动终端和非移动终端。
图9为实现本申请实施例的一种终端的硬件结构示意图。
该终端900包括但不限于：射频单元901、网络模块902、音频输出单元903、输入单元904、传感器905、显示单元906、用户输入单元907、接口单元908、存储器909、以及处理器910等部件。
本领域技术人员可以理解，终端900还可以包括给各个部件供电的电源(比如电池)，电源可以通过电源管理系统与处理器910逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。图9中示出的电子设备结构并不构成对电子设备的限定，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置，在此不再赘述。
具体地，在终端900为第一终端的情况下，射频单元901，用于：
接收服务器发送的目标多媒体文件的多个实时传输协议RTP数据包，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP 数据包在所述目标多媒体文件中的排列序号，所述RTP数据包对应的共享编码为所述服务器根据获取的所述目标多媒体文件对应的共享编码的初始值确定的；
在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码；
处理器910，用于接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行所述目标多媒体文件的解码，所述第一RTP数据包为所述第二终端根据第一RTP数据包的共享编码发送的；
其中，所述第一终端与所述第二终端共同接收所述服务器发送的所述目标多媒体文件的RTP数据包。
可选地，所述处理器910，用于：
根据接收的所述服务器发送的目标多媒体文件的多个RTP数据包，确定是否未接收到第一RTP数据包；
所述射频单元901，用于：
在未接收到第一RTP数据包的情况下，向所述第二终端发送所述第一RTP数据包的共享编码。
可选地，所述处理器910，用于基于接收到的多个RTP数据包的共享编码，在多个RTP数据包的共享编码不连续的情况下，确定存在未接收到的第一RTP数据包。
可选地，所述射频单元901，用于：在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接，所述第一条件包括：丢包率大于或等于第一预设阈值。
可选地，所述射频单元901，用于：接收所述服务器发送的至少一个终端的信息，所述至少一个终端中每个终端的丢包率均小于或等于第二预设阈值；
所述处理器910，用于在所述第一终端的丢包率满足第一条件的情况下，在所述至少一个终端中选择第二终端；
所述射频单元901，用于：建立与所述第二终端的连接。
本申请实施例通过在确定接收服务器发送的目标多媒体文件的多个RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码，将接收到的所述第二终端根据第一RTP数据包的共享编码发送的第一RTP数据包插入缓存中进行所述目标多媒体文件的解码；以此能够避免向服务器请求重传数据包造成服务器负载过重导致终端不能及时获取丢失的数据包的情况出现，通过向其他终端获取丢失的数据包保证终端能够及时获取到目标多媒体文件的完整的RTP数据包，保证目标多媒体文件能够解码获取完整的目标多媒体文件，以保证目标多媒体文件播放的流畅。
应理解的是，本申请实施例中，输入单元904可以包括图形处理器(Graphics Processing Unit，GPU)9041和麦克风9042，图形处理器9041对在视频捕获模式或图像捕获模式中由图像捕获装置(如摄像头)获得的静态图片或视频的图像数据进行处理。显示单元906 可包括显示面板9061，可以采用液晶显示器、有机发光二极管等形式来配置显示面板9061。用户输入单元907包括触控面板9071以及其他输入设备9072。触控面板9071，也称为触摸屏。触控面板971可包括触摸检测装置和触摸控制器两个部分。其他输入设备9072可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆，在此不再赘述。存储器909可用于存储软件程序以及各种数据，包括但不限于应用程序和操作系统。处理器910可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器910中。
本申请实施例还提供一种可读存储介质，所述可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述应用于第一终端侧的解码方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
其中，所述处理器为上述实施例中所述的第一终端中的处理器。所述可读存储介质，包括计算机可读存储介质，如计算机只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等。
如图10所示，本申请实施例还提供一种数据传输装置1000，应用于服务器，包括：
获取模块1001，用于获取目标多媒体文件对应的共享编码的初始值；
确定模块1002，用于根据所述共享编码的初始值，确定所述目标多媒体文件的多个实时传输协议RTP数据包中的每一个RTP数据包所对应的共享编码；
第二发送模块1003，用于向第一终端和第二终端发送目标多媒体文件的多个RTP数据包；
其中，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号。
可选地，所述获取模块1001，用于：
根据第一多媒体文件对应的共享编码的初始值、所述目标多媒体文件的数据块的大小、RTP数据包的大小以及第一系数，确定所述目标多媒体文件对应的共享编码的初始值；
其中，所述第一系数由所述目标多媒体文件的数据块的大小和RTP数据包的大小确定，所述第一多媒体文件为位于所述目标多媒体文件之前传输的多媒体文件。
可选地，所述装置，还包括：
第二接收模块，用于接收多个终端发送的丢包率；
第三发送模块，用于将满足第二条件的至少一个终端的信息发送给第一终端，所述第二条件包括：丢包率小于或等于第二预设阈值。
需要说明的是，该装置实施例是与上述应用于服务器侧的数据传输方法实施例一一对应的装置，上述方法实施例中所有实现方式均适用于该装置的实施例中，也能达到相同的技术效果。
本申请实施例中的数据传输装置可以为具有操作系统的装置。该操作系统可以为安卓 (Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。
本申请实施例提供的数据传输装置能够实现图6的方法实施例实现的各个过程。
可选地，如图11所示，本申请实施例还提供一种服务器1100，包括处理器1101，存储器1102，存储在存储器1102上并可在所述处理器1101上运行的程序或指令，该程序或指令被处理器1101执行时实现上述应用于服务器侧的数据传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述数据传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
本申请实施例另提供了一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现上述数据传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。
上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (20)

  1. 一种解码方法，由第一终端执行，包括：
    接收服务器发送的目标多媒体文件的多个实时传输协议RTP数据包，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号，所述RTP数据包对应的共享编码为所述服务器根据获取的所述目标多媒体文件对应的共享编码的初始值确定的；
    在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码；
    接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行所述目标多媒体文件的解码，所述第一RTP数据包为所述第二终端根据第一RTP数据包的共享编码发送的；
    其中，所述第一终端与所述第二终端共同接收所述服务器发送的所述目标多媒体文件的RTP数据包。
  2. 根据权利要求1所述的方法，其中，所述在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码，包括：
    根据接收的所述服务器发送的目标多媒体文件的多个RTP数据包，确定是否未接收到第一RTP数据包；
    在未接收到第一RTP数据包的情况下，向所述第二终端发送所述第一RTP数据包的共享编码。
  3. 根据权利要求2所述的方法，其中，所述确定是否未接收到第一RTP数据包，包括：
    基于接收到的多个RTP数据包的共享编码，在多个RTP数据包的共享编码不连续的情况下，确定存在未接收到的第一RTP数据包。
  4. 根据权利要求1所述的方法，所述方法还包括：
    在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接，所述第一条件包括：丢包率大于或等于第一预设阈值。
  5. 根据权利要求4所述的方法，其中，在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接，包括：
    接收所述服务器发送的至少一个终端的信息，所述至少一个终端中每个终端的丢包率均小于或等于第二预设阈值；
    在所述第一终端的丢包率满足第一条件的情况下，在所述至少一个终端中选择第二终端；
    建立与所述第二终端的连接。
  6. 一种数据传输方法，由服务器执行，所述方法包括：
    获取目标多媒体文件对应的共享编码的初始值；
    根据所述共享编码的初始值，确定所述目标多媒体文件的多个实时传输协议RTP数据包中的每一个RTP数据包所对应的共享编码；
    向第一终端和第二终端发送目标多媒体文件的多个RTP数据包；
    其中，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号。
  7. 根据权利要求6所述的方法，其中，所述获取目标多媒体文件对应的共享编码的初始值，包括：
    根据第一多媒体文件对应的共享编码的初始值、所述目标多媒体文件的数据块的大小、RTP数据包的大小以及第一系数，确定所述目标多媒体文件对应的共享编码的初始值；
    其中，所述第一系数由所述目标多媒体文件的数据块的大小和RTP数据包的大小确定，所述第一多媒体文件为位于所述目标多媒体文件之前传输的多媒体文件。
  8. 根据权利要求6所述的方法，所述方法还包括：
    接收多个终端发送的丢包率；
    将满足第二条件的至少一个终端的信息发送给第一终端，所述第二条件包括：丢包率小于或等于第二预设阈值。
  9. 一种解码装置，由第一终端执行，所述解码装置包括：
    第一接收模块，用于接收服务器发送的目标多媒体文件的多个实时传输协议RTP数据包，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号，所述RTP数据包对应的共享编码为所述服务器根据获取的所述目标多媒体文件对应的共享编码的初始值确定的；
    第一发送模块，用于在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码；
    解码模块，用于接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行所述目标多媒体文件的解码，所述第一RTP数据包为所述第二终端根据第一RTP数据包的共享编码发送的；
    其中，所述第一终端与所述第二终端共同接收所述服务器发送的所述目标多媒体文件的RTP数据包。
  10. 根据权利要求9所述的装置，其中，所述第一发送模块，包括：
    确定单元，用于根据接收的所述服务器发送的目标多媒体文件的多个RTP数据包，确定是否未接收到第一RTP数据包；
    发送单元，用于在未接收到第一RTP数据包的情况下，向所述第二终端发送所述第一RTP数据包的共享编码。
  11. 根据权利要求10所述的装置，其中，所述确定单元，用于：
    基于接收到的多个RTP数据包的共享编码，在多个RTP数据包的共享编码不连续的情况下，确定存在未接收到的第一RTP数据包。
  12. 根据权利要求9所述的装置，所述装置还包括：
    连接模块，用于在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接，所述第一条件包括：丢包率大于或等于第一预设阈值。
  13. 根据权利要求12所述的装置，其中，所述连接模块，包括：
    接收单元，用于接收所述服务器发送的至少一个终端的信息，所述至少一个终端中每个终端的丢包率均小于或等于第二预设阈值；
    选择单元，用于在所述第一终端的丢包率满足第一条件的情况下，在所述至少一个终端中选择第二终端；
    建立单元，用于建立与所述第二终端的连接。
  14. 一种数据传输装置，由服务器执行，所述数据传输装置包括：
    获取模块，用于获取目标多媒体文件对应的共享编码的初始值；
    确定模块，用于根据所述共享编码的初始值，确定所述目标多媒体文件的多个实时传输协议RTP数据包中的每一个RTP数据包所对应的共享编码；
    第二发送模块，用于向第一终端和第二终端发送目标多媒体文件的多个RTP数据包；
    其中，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号。
  15. 根据权利要求14所述的装置，其中，所述获取模块，用于：
    根据第一多媒体文件对应的共享编码的初始值、所述目标多媒体文件的数据块的大小、RTP数据包的大小以及第一系数，确定所述目标多媒体文件对应的共享编码的初始值；
    其中，所述第一系数由所述目标多媒体文件的数据块的大小和RTP数据包的大小确定，所述第一多媒体文件为位于所述目标多媒体文件之前传输的多媒体文件。
  16. 根据权利要求14所述的装置，所述装置还包括：
    第二接收模块，用于接收多个终端发送的丢包率；
    第三发送模块，用于将满足第二条件的至少一个终端的信息发送给第一终端，所述第二条件包括：丢包率小于或等于第二预设阈值。
  17. 一种电子设备，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，其中，所述程序或指令被所述处理器执行时实现如权利要求1-5任一项所述的解码方法的步骤或实现如权利要求6-8任一项所述的数据传输方法的步骤。
  18. 一种可读存储介质，所述可读存储介质上存储程序或指令，其中，所述程序或指令被处理器执行时实现如权利要求1-5任一项所述的解码方法的步骤或实现如权利要求6-8任一项所述的数据传输方法的步骤。
  19. 一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现如权利要求1-5任一项所述的解码方法的步骤或实 现如权利要求6-8任一项所述的数据传输方法的步骤。
  20. 一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如权利要求1-5任一项所述的解码方法的步骤或实现如权利要求6-8任一项所述的数据传输方法的步骤。
PCT/CN2023/118839 2022-09-16 2023-09-14 解码、数据传输方法、装置、终端及服务器 WO2024056032A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211127820.8A CN115484240A (zh) 2022-09-16 2022-09-16 解码、数据传输方法、装置、终端及服务器
CN202211127820.8 2022-09-16

Publications (1)

Publication Number Publication Date
WO2024056032A1 true WO2024056032A1 (zh) 2024-03-21

Family

ID=84423780

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/118839 WO2024056032A1 (zh) 2022-09-16 2023-09-14 解码、数据传输方法、装置、终端及服务器

Country Status (2)

Country Link
CN (1) CN115484240A (zh)
WO (1) WO2024056032A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115484240A (zh) * 2022-09-16 2022-12-16 维沃移动通信有限公司 解码、数据传输方法、装置、终端及服务器
CN115865941A (zh) * 2023-02-15 2023-03-28 花瓣云科技有限公司 丢包重传方法、分组确定方法、装置、设备以及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1645787A (zh) * 2005-03-01 2005-07-27 广东省电信有限公司研究院 在分布式对等流媒体服务系统中实现可靠组播的方法
CN101119249A (zh) * 2006-08-02 2008-02-06 华为技术有限公司 一种数据下载方法及系统
US20100017673A1 (en) * 2008-07-15 2010-01-21 Hitachi, Ltd. Data transmission system and data transmission method
CN106850595A (zh) * 2017-01-17 2017-06-13 烽火通信科技股份有限公司 一种流媒体传输优化方法及装置
CN115484240A (zh) * 2022-09-16 2022-12-16 维沃移动通信有限公司 解码、数据传输方法、装置、终端及服务器

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1645787A (zh) * 2005-03-01 2005-07-27 广东省电信有限公司研究院 在分布式对等流媒体服务系统中实现可靠组播的方法
CN101119249A (zh) * 2006-08-02 2008-02-06 华为技术有限公司 一种数据下载方法及系统
US20100017673A1 (en) * 2008-07-15 2010-01-21 Hitachi, Ltd. Data transmission system and data transmission method
CN106850595A (zh) * 2017-01-17 2017-06-13 烽火通信科技股份有限公司 一种流媒体传输优化方法及装置
CN115484240A (zh) * 2022-09-16 2022-12-16 维沃移动通信有限公司 解码、数据传输方法、装置、终端及服务器

Also Published As

Publication number Publication date
CN115484240A (zh) 2022-12-16

Similar Documents

Publication Publication Date Title
WO2024056032A1 (zh) 解码、数据传输方法、装置、终端及服务器
CN109996097B (zh) 一种投屏方法、系统及存储装置
CN113037440B (zh) 数据重传处理方法、装置、计算机设备和存储介质
US20230083441A1 (en) Managing subpacket transmission and reception for advanced interactive services
US11792130B2 (en) Audio/video communication method, terminal, server, computer device, and storage medium
US8112480B2 (en) Signaling support for sharer switching in application sharing
US10469627B2 (en) Rapid optimization of media stream bitrate
WO2018121742A1 (zh) 一种流数据的传输方法和装置
CN111147606B (zh) 数据传输的方法、装置、终端及存储介质
US20230071243A1 (en) Conserving network resources during transmission of packets of interactive services
CN110830460B (zh) 一种连接建立方法、装置、电子设备及存储介质
WO2020248649A1 (zh) 音视频数据同步播放方法、装置、系统、电子设备及介质
WO2015000337A1 (zh) 视频传输方法及设备
CN111787026B (zh) 一种媒体数据的传输方法、装置、设备及存储介质
CN114221909B (zh) 数据传输方法、装置、终端及存储介质
CN109889922B (zh) 流媒体数据的转发方法、装置、设备和存储介质
CN114710568B (zh) 音视频数据通信方法、设备及存储介质
CN113726817B (zh) 一种流媒体数据的传输方法、装置及介质
CN115208864A (zh) 数据传输方法、装置、设备、车辆及存储介质
CN113573004A (zh) 视频会议处理方法、装置、计算机设备及存储介质
WO2024001451A1 (zh) 业务数据包的处理方法、装置、介质及电子设备
CN114024868B (zh) 流量统计方法、流量质量分析方法及装置
WO2023213086A1 (zh) 数据处理方法、装置、计算机可读介质及电子设备
CN111404908B (zh) 数据交互方法、装置、电子设备及可读存储介质
WO2022228037A1 (zh) 一种流媒体数据传输的方法及相关设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23864762

Country of ref document: EP

Kind code of ref document: A1