CN115484240A

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

Info

Publication number: CN115484240A
Application number: CN202211127820.8A
Authority: CN
Inventors: 邵胜均
Original assignee: Vivo Mobile Communication Co Ltd
Current assignee: Vivo Mobile Communication Co Ltd
Priority date: 2022-09-16
Filing date: 2022-09-16
Publication date: 2022-12-16
Also published as: WO2024056032A1

Abstract

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

Description

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

技术领域

本申请属于视频传输技术领域，特别涉及一种解码、数据传输方法、装置、终端及服务器。

背景技术

在视频会议场景，为保障音视频的实时性，实时协议(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数据包，保证目标多媒体文件能够解码获取完整的目标多媒体文件，以保证目标多媒体文件播放的流畅。

附图说明

图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数据包的大小以及第一系数，确定所述目标多媒体文件对应的共享编码的初始值；

可选地，所述的方法，还包括：

接收多个终端发送的丢包率；

将满足第二条件的至少一个终端的信息发送给第一终端，所述第二条件包括：丢包率小于或等于第二预设阈值。

需要说明的是，上述实施例中所有关于服务器侧的描述均适用于该应用于服务器侧的数据传输方法的实施例中，也能达到相同的技术效果，在此不再赘述。

需要说明的是，本申请实施例提供的方法，执行主体可以为装置，或者该装置中的用于执行方法的控制模块。本申请实施例中以装置执行方法为例，说明本申请实施例提供的装置。

如图7所示，本申请实施例还提供一种解码装置700，应用于第一终端，包括：

第一接收模块701，用于接收服务器发送的目标多媒体文件的多个实时传输协议RTP数据包，所述RTP数据包的协议头部中携带所述RTP数据包对应的共享编码，所述共享编码用于指示所述RTP数据包在所述目标多媒体文件中的排列序号，所述RTP数据包对应的共享编码为所述服务器根据获取的所述目标多媒体文件对应的共享编码的初始值确定的；

第一发送模块702，用于在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码；

解码模块703，用于接收所述第一RTP数据包，并将所述第一RTP数据包插入缓存中进行所述目标多媒体文件的解码，所述第一RTP数据包为所述第二终端根据第一RTP数据包的共享编码发送的；

可选地，所述第一发送模块702，包括：

确定单元，用于根据接收的所述服务器发送的目标多媒体文件的多个RTP数据包，确定是否未接收到第一RTP数据包；

发送单元，用于在未接收到第一RTP数据包的情况下，向所述第二终端发送所述第一RTP数据包的共享编码。

可选地，所述确定单元，用于：

基于接收到的多个RTP数据包的共享编码，在多个RTP数据包的共享编码不连续的情况下，确定存在未接收到的第一RTP数据包。

可选地，所述装置，还包括：

连接模块，用于在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接，所述第一条件包括：丢包率大于或等于第一预设阈值。

可选地，所述连接模块，包括：

接收单元，用于接收所述服务器发送的至少一个终端的信息，所述至少一个终端中每个终端的丢包率均小于或等于第二预设阈值；

选择单元，用于在所述第一终端的丢包率满足第一条件的情况下，在所述至少一个终端中选择第二终端；

建立单元，用于建立与所述第二终端的连接。

需要说明的是，该装置实施例是与上述应用于第一终端侧的解码方法实施例一一对应的装置，上述方法实施例中所有实现方式均适用于该装置的实施例中，也能达到相同的技术效果。

本申请实施例中的解码装置可以是装置，也可以是终端中的部件、集成电路、或芯片。该装置可以是移动电子设备，也可以为非移动电子设备。示例性的，移动电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、可穿戴设备、超级移动个人计算机(ultra-mobile personal computer，UMPC)、上网本或者个人数字助理(personaldigital assistant，PDA)等，非移动电子设备可以为服务器、网络附属存储器(NetworkAttached 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，用于：

处理器910，用于接收所述第一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可以包括图形处理器(GraphicsProcessing 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数据包；

可选地，所述获取模块1001，用于：

可选地，所述装置，还包括：

第二接收模块，用于接收多个终端发送的丢包率；

第三发送模块，用于将满足第二条件的至少一个终端的信息发送给第一终端，所述第二条件包括：丢包率小于或等于第二预设阈值。

需要说明的是，该装置实施例是与上述应用于服务器侧的数据传输方法实施例一一对应的装置，上述方法实施例中所有实现方式均适用于该装置的实施例中，也能达到相同的技术效果。

本申请实施例中的数据传输装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的数据传输装置能够实现图6的方法实施例实现的各个过程。

可选地，如图11所示，本申请实施例还提供一种服务器1100，包括处理器1101，存储器1102，存储在存储器1102上并可在所述处理器1101上运行的程序或指令，该程序或指令被处理器1101执行时实现上述应用于服务器侧的数据传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本申请实施例另提供了一种芯片，所述芯片包括处理器和通信接口，所述通信接口和所述处理器耦合，所述处理器用于运行程序或指令，实现上述数据传输方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以计算机软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，或者网络设备等)执行本申请各个实施例所述的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims

1.一种解码方法，由第一终端执行，其特征在于，包括：

2.根据权利要求1所述的方法，其特征在于，所述在确定所述RTP数据包中不包括服务器发送的目标多媒体文件的第一RTP数据包的情况下，向第二终端发送所述第一RTP数据包的共享编码，包括：

3.根据权利要求2所述的方法，其特征在于，所述确定是否未接收到第一RTP数据包，包括：

4.根据权利要求1所述的方法，其特征在于，还包括：

在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接，所述第一条件包括：丢包率大于或等于第一预设阈值。

5.根据权利要求4所述的方法，其特征在于，在第一终端的丢包率满足第一条件的情况下，与所述第二终端建立连接，包括：

接收所述服务器发送的至少一个终端的信息，所述至少一个终端中每个终端的丢包率均小于或等于第二预设阈值；

在所述第一终端的丢包率满足第一条件的情况下，在所述至少一个终端中选择第二终端；

建立与所述第二终端的连接。

6.一种数据传输方法，由服务器执行，其特征在于，包括：

获取目标多媒体文件对应的共享编码的初始值；

7.根据权利要求6所述的方法，其特征在于，所述获取目标多媒体文件对应的共享编码的初始值，包括：

8.根据权利要求6所述的方法，其特征在于，还包括：

接收多个终端发送的丢包率；

9.一种解码装置，由第一终端执行，其特征在于，包括：

10.根据权利要求9所述的装置，其特征在于，所述第一发送模块，包括：

11.根据权利要求10所述的装置，其特征在于，所述确定单元，用于：

12.根据权利要求9所述的装置，其特征在于，还包括：

13.根据权利要求12所述的装置，其特征在于，所述连接模块，包括：

建立单元，用于建立与所述第二终端的连接。

14.一种数据传输装置，由服务器执行，其特征在于，包括：

15.根据权利要求14所述的装置，其特征在于，所述获取模块，用于：

16.根据权利要求14所述的装置，其特征在于，还包括：

第二接收模块，用于接收多个终端发送的丢包率；

17.一种电子设备，其特征在于，包括处理器，存储器及存储在所述存储器上并可在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1-5任一项所述的解码方法的步骤或实现如权利要求6-8任一项所述的数据传输方法的步骤。

18.一种可读存储介质，其特征在于，所述可读存储介质上存储程序或指令，所述程序或指令被处理器执行时实现如权利要求1-5任一项所述的解码方法的步骤或实现如权利要求6-8任一项所述的数据传输方法的步骤。