一种RTP包丢包重传方法、装置及播放终端与流程

一种rtp包丢包重传方法、装置及播放终端
技术领域
1.本技术涉及网络通信技术领域，尤其涉及一种rtp包丢包重传方法、装置及播放终端。


背景技术：

2.rtp(real-time transport protocol，实时传输协议)是一种网络传输协议，用于在互联网上传输音视频数据，如用于视频会议。基于rtp，视频会议帮助众多企业机构实现跨区域、跨空间的高效沟通。
3.但由于数据传输中不可避免的技术问题，如丢包、延时、抖包等，进而会出现卡顿等音视频质量低下的情况，严重影响使用体验。其中丢包是数据传输中较为常见的技术难题之一。丢包会对视频会议的音视频产生影响，按照专业区分，丢包会对视频质量、音频传输、通话行为产生影响。对视频图像影响较为明显，直观的来看，丢包会使视频通话中出现视频图像马赛克、视频局部变形，图像模糊、图像静止有声音、图像闪烁等情况。例如在视频传输中，发现演示幻灯片模糊变形、翻页速度减慢或屏幕频繁刷新和图像静止等情况基本可确定丢包严重；丢包对音频的影响主要是音频失真、间断、间歇性噪音等，例如通话中突然出现刺耳的尖锐声，除去磁场干扰外，丢包也是主要原因之一，严重的丢包甚至会导致音频中断。因此丢包一直被技术人员长期关注。
4.目前为解决丢包问题，播放终端在进行音视频播放的过程中按照rtp包的序号顺序去读取、解析rtp包；若未读取到满足序号要求的rtp包，则认为该rtp包发生丢包，播放终端将根据该rtp包的序号向视频服务器发送丢包请求以使服务器重传被丢包的rtp包。然而服务器的数据发送有个窗口期，且窗口期是不断变化的，这就要求播放终端发送丢包请求要命中在窗口期内，才能获取到丢包数据，否则丢包数据将会一直等待不来。


技术实现要素：

5.本技术实施例提供了一种rtp包丢包重传方法、装置及播放终端，相对较大概率的及时获得丢包数据，保证音视频播放质量。
6.第一方面，本技术提供的一种rtp包丢包重传方法，应用于播放终端，所述方法包括：
7.确定当前时间与上一次发送丢包请求的时间间隔是否达到丢包请求阈值时间；
8.若当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，则检查缓存队列中是否存在丢包；
9.若检查到所述缓存队列中存在丢包，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求；
10.若当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次检查缓存队列丢包比例的的时间间隔达到最小丢包请求时间，则检查所述缓存队列并确定所述缓存队列的丢包比例；
11.若所述缓存队列的丢包比例大于丢包比例阈值，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求。
12.第二方面，本技术提供的rtp包丢包重传装置，其特征在于，包括：
13.第一确定单元，用于确定当前时间与上一次发送丢包请求的时间间隔是否达到丢包请求阈值时间；
14.第一检查单元，用于若当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，则检查缓存队列中是否存在丢包；
15.第一请求单元，用于若检查到所述缓存队列中存在丢包，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求；
16.第二检查单元，用于若当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次检查缓存队列丢包比例的时间间隔达到最小丢包请求时间，则检查所述缓存队列并确定所述缓存队列的丢包比例；
17.第二请求单元，用于若所述缓存队列的丢包比例大于丢包比例阈值，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求。
18.第三方面，本技术提供的一种播放终端，所述播放终端包括处理器，所述处理器被配置为：
19.确定当前时间与上一次发送丢包请求的时间间隔是否达到丢包请求阈值时间；
20.若当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，则检查缓存队列中是否存在丢包；
21.若检查到所述缓存队列中存在丢包，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求；
22.若当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次检查缓存队列丢包比例的时间间隔达到最小丢包请求时间，则检查所述缓存队列并确定所述缓存队列的丢包比例；
23.若所述缓存队列的丢包比例大于丢包比例阈值，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求。
24.本技术提供的rtp包丢包重传方法、装置及播放终端，在进行音视频播放过程中，当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，检查缓存队列；当缓存队列存在丢包，则确定缓存队列中的丢包，并根据丢包待重传rtp包的序号向服务器发送丢包请求；而当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次检查缓存队列丢包比例的的时间间隔达到最小丢包请求时间，检查缓存队列，确定缓存队列的丢包比例；进而当缓存队列的丢包比例大于丢包比例阈值，根据丢包待重传rtp包的序号向服务器发送丢包请求。
25.因此，本技术提供的rtp包丢包重传方法、装置及播放终端，实现播放终端通过及时查找到缓存队列中的丢包序号及时向服务器发送丢包请求，增大播放终端丢包请求命中服务器窗口期的命中率，以使播放终端发送的丢包请求都尽量能够落在服务器的窗口期，进而相对较大概率的及时获得丢包数据以避免音视频播放出现卡顿，保证播放终端的音视频播放质量；以及在缓存队列的丢包比例大于丢包比例阈值时，增加播放终端向服务器发送丢包请求的频次，实现根据缓存队列的丢包比例动态调整向服务器发送丢包请求的时
间，以促进播放终端丢包请求命中服务器窗口期，进一步促使播放终端发送丢包请求命中服务器窗口期的命中率。
附图说明
26.为了更清楚地说明本技术实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
27.图1为本技术实施例提供的一种rtp包丢包重传方法的流程图；
28.图2为本技术实施例提供的另一种rtp包丢包重传方法的流程示意图；
29.图3为本技术实施例提供的再一种rtp包丢包重传方法的流程示意图；
30.图4为本技术实施例提供的一种rtp包丢包重传装置的结构示意图。
具体实施方式
31.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
32.本技术使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本技术。在本技术和所附权利要求书中所使用的单数形式的“一种”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
33.为解决上述技术问题，本技术实施例的发明构思为：当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，检查缓存队列；当缓存队列存在丢包，则确定缓存队列中的丢包，并根据丢包待重传rtp包的序号向服务器发送丢包请求；而当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次发送丢包请求的时间间隔达到最小丢包请求时间，检查缓存队列，当缓存队列存在丢包则确定缓存队列的丢包比例；当缓存队列的丢包比例大于丢包比例阈值，根据丢包待重传rtp包的序号向服务器发送丢包请求；其中，缓存队列用于缓存若干待播放的rtp包。因此本技术实施例提供的rtp包丢包重传方法，通过及时查找到缓存队列中的丢包序号及时向服务器发送丢包请求，增大丢包请求命中服务器窗口期的命中率，以使相对较大概率的获得丢包数据，保证音视频播放质量。
34.为了使本发明实施例的目的、技术方案和优点更加清楚，下面结合附图和具体实施例对本发明实施例执行详细描述：
35.播放终端接收到播放命令后，将会根据播放命令向服务器发送与该播放命令相关音视频数据的请求，服务器将接收到播放终端发送的音视频请求并根据音视频请求向播放终端发送音视频数据。服务器以rtp包的形式向播放终端发送的音视频数据，即服务器将播放终端请求的音视频数据分成若干rtp包并发送给播放终端，播放终端接收服务器发送的rtp包并将接收到的rtp包暂时存储至udp缓存区，然后播放终端将udp缓存区的rtp包读取
至缓存队列中并按照rtp包的顺序进行排序；如音视频数据的第一个rtp包的序号为0，然后依次进行排列。可选的，播放终端请求音视频播放后，播放终端先从udp缓存区一个rtp包，解析该rtp包，得到rtp包的序号，如果rtp包的序号是0，直接被音视频播放模块取走进行解析播放，后续先从缓存队列中读取rtp包，找到序号为1的rtp包等进行顺序播放。但由于数据传输中不可规避的技术问题，丢包问题不可避免，因此为避免因为丢包造成音视频出现卡顿，播放终端需要及时发现丢包并尽量在服务器的窗口期向服务器及时发送丢包请求，以及时获取到重传丢包。
36.图1为本技术实施例提供的一种rtp包丢包重传方法的流程示意图，用于播放终端与服务器之间的rtp包丢包处理，该方法的执行主体为播放终端，如机顶盒等。如图1所示，本技术实施例提供的rtp包丢包重传方法，包括：
37.s101：确定当前时间与上一次发送丢包请求的时间间隔是否达到丢包请求阈值时间。
38.在本技术实施例中，设置丢包请求阈值时间。丢包请求阈值时间可根据实际需要进行选择，如200ms、500ms等，但通常小于两个相邻rtp包中音视频数据的播放间隔。
39.播放终端开始播放请求播放的音视频，记录上一次发送丢包请求的时间，并随着音视频的播放确定当前时间与上一次发送丢包请求的时间间隔，将该时间间隔与丢包请求阈值时间进行比较，确定当前时间与上一次发送丢包请求的时间间隔是否达到丢包请求阈值时间。若播放终端从开始播放该音视频还没有向服务器发送过丢包请求，则记录上一次发送丢包请求的时间为t＝0；若播放终端在t1时间向服务器发送了丢包请求，更新t＝t1。
40.可选的，若缓存队列中有新的rtp插入，则确定当前时间与上一次发送丢包请求的时间间隔。
41.s102：若当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，则检查缓存队列中是否存在丢包。
42.缓存队列中缓存有若干rtp包，及时将缓存至udp缓存区的rtp包存储至缓存队列中，然后通过检查缓存队列可及时发现丢包。若当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，播放终端检查缓存队列中是否存在丢包。可选的，播放终端确定缓存队列中存储的rtp包的序号是否都是连续的；若缓存队列中存储的rtp包的序号均是连续的，则说明当前时刻播放终端接收到的音视频数据中不存在丢包；若缓存队列中存储的rtp包的序号存在不连续，则说明当前时刻播放终端接收到的音视频数据中存在丢包。
43.如，检查到缓存队列中包括rtp1包、rtp2包、rtp4包、rtp5包、rtp6包
……
，rtp2包、rtp4包之间不连续，则说明缓存队列中是存在丢包，进而目前接收到的音视频数据中存在丢包。
44.s103：若检查到所述缓存队列中存在丢包，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求。
45.当检查到缓存队列中存在丢包，获取缓存队列中所丢包的序号，即确定丢包待重传rtp包的序号，根据丢包待重传rtp包的序号向服务器发送丢包请求。
46.如，检查到缓存队列中包括rtp1包、rtp2包、rtp4包、rtp5包、rtp6包
……
，确定出缓存队列中所丢包的序号为3，确定丢包待重传的rtp包为rtp3包，向服务器发送丢包请求用以获取rtp3包，即播放终端向服务器发送重传请求，在重传请求中携带序号3。
47.s104：若当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次检查缓存队列丢包比例的时间间隔达到最小丢包请求时间，则检查所述缓存队列并确定所述缓存队列的丢包比例。
48.在本技术实施例中，设置最小丢包请求时间。丢包请求阈值时间可根据实际需要进行选择，如100ms、200ms等，但通常最小丢包请求时间小于丢包请求阈值时间，最小丢包请求时间可选30ms、50ms等。随着音视频的播放确定当前时间与上一次检查缓存队列丢包比例的时间间隔，将该时间间隔与最小丢包请求时间进行比较，确定当前时间与上一次检查缓存队列丢包比例的时间间隔是否达最小丢包请求时间；若当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次检查缓存队列丢包比例的时间间隔达到最小丢包请求时间，检查缓存队列并计算当前时间缓存队列的丢包比例。
49.如此，通过丢包请求阈值时间和最小丢包请求时间的协调选择，在根据丢包请求阈值时间进行检查缓存队列中是否存在丢包的过程中，可通过当前时间与上一次检查缓存队列丢包比例的时间间隔达到最小丢包请求时间进行多次检查缓存队列的丢包比例，有效保证发生超过丢包比例阈值时及时向服务器发送丢包请求，以及时重新获取被丢包的数据，保证音视频的播放质量。
50.可选的，记录上一次检查缓存队列丢包比例的时间，根据当前时间与上一次检查缓存队列丢包比例的时间确定当前时间与上一次检查缓存队列丢包比例的时间间隔。
51.可选的，本技术实施例提供的rtp包丢包重传方法中，检查所述缓存队列并确定所述缓存队列的丢包比例，包括：查找所述缓存队列中的丢包数量并统计确定所述缓存队列中rtp包的数量；根据丢包数量和所述缓存队列中rtp包的数量，计算所述缓存队列的丢包比例。
52.假设当前时刻缓存队列中包括rtp1包、rtp2包、rtp4包、rtp5包、rtp6包，当前时刻距离上一次检查缓存队列丢包比例的时间间隔否达最小丢包请求时间，通过检查缓存队列可知当前时刻缓存队列存中rtp3包发生丢包，统计当前时刻缓存队列中rtp包的数量为5个，计算当前时刻的丢包比例为1/5＝20％。
53.s105：若所述缓存队列的丢包比例大于丢包比例阈值，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求。
54.播放终端中的丢包比例可根据实际需要任意自主的选择，同时也可根据音视频播放质量要求进行选择，如7％、10％等。
55.假设上述举例中，播放终端中设置的丢包比例为7％，则当前时刻的丢包比例20％＞7％，确定丢包待重传rtp包的序号，根据丢包待重传rtp包的序号向服务器发送丢包请求，即播放终端向服务器发送重传请求，在重传请求中携带序号3。
56.本技术实施例提供的rtp包丢包重传方法，一方面，实现播放终端通过及时查找到缓存队列中的丢包序号及时向服务器发送丢包请求，增大播放终端丢包请求命中服务器窗口期的命中率，以使播放终端发送的丢包请求都尽量能够落在服务器的窗口期，进而相对较大概率的及时获得丢包数据以避免音视频播放出现卡顿，保证播放终端的音视频播放质量；另一方面，在缓存队列的丢包比例大于丢包比例阈值时，增加播放终端向服务器发送丢包请求的频次，实现根据缓存队列的丢包比例动态调整向服务器发送丢包请求的时间，即实现非定时的向服务器发送丢包请求，以促进播放终端丢包请求命中服务器窗口期，进一
步促使播放终端发送丢包请求命中服务器窗口期的命中率。
57.在本技术实施例中，播放设备在进行rtp0包内音视频数据播放时，将继续从udp缓存区读取rtp包，一方面为了将从udp缓存区读取rtp包存放入缓存队列中，另一方面为了及时找出与rtp0包连续的rtp1包等，使音视频正常播放。
58.为进一步保证本技术实施例中，播放终端能够正常的播放音视频，本技术实施例还提供了一种rtp包丢包重传方法。图2为本技术实施例提供的另一种rtp包丢包重传方法的流程示意图。作为一个实施例，如图2所示，本技术实施例提供的rtp包丢包重传方法，还包括：
59.s201：从udp缓存区读取第一rtp包，确定所述第一rtp包与当前播放音视频数据对应rtp包的序号是否连续。
60.本技术实施例中，第一rtp包只是为便于区分而进行的命名，并非用于限定，但通常是指udp缓存区现有rtp包中序号最小的rtp包。
61.当进行放音视频数据播放时，播放终端从缓存队列中读取第一rtp包并确定当前播放音视频数据对应rtp包的序号，解析获得第一rtp包的序号；根据当前播放音视频数据对应rtp包的序号和第一rtp包的序号，判定该第一rtp包是否为当前播放音视频数据对应rtp包的连续包。
62.如当前播放音视频数据对应rtp包的序号为0，若第一rtp包的序号为1，则第一rtp包是当前播放音视频数据对应rtp包的连续包，否则第一rtp包不是当前播放音视频数据对应rtp包的连续包。如，第一rtp包的序号为2或其他非1的序号，则第一rtp包不是当前播放音视频数据对应rtp包的连续包。
63.s202：若所述第一rtp包的序号与当前播放音视频数据对应rtp包的序号连续，则读取所述第一rtp包并播放所述第一rtp包内的音视频数据。
64.若从udp缓存区读取到的第一rtp包为当前播放音视频数据对应rtp包的连续包，读取以解码该第一rtp包，待当前播放rtp包内音视频数据播放完接连播放该第一rtp包内的音视频数据。
65.进一步，在本技术实施例中，若从udp缓存区读取到的第一rtp包为当前播放音视频数据对应rtp包的连续包，则继续读取udp缓存区，若能够从所述udp缓存区读取到第三rtp包，将所述第三rtp包存入所述缓存队列中。本技术实施例中，第三rtp包只是为便于区分而进行的命名，并非用于限定。如此，便于及时更新缓存队列，保证后续音视频的正常播放；如当读取到第三rtp包为rtp2包时，将rtp2包及时存入缓存队列中，进而当播放终端播放rtp1包中的音视频数据时，可直接从缓存队列中取到rtp2包，进而方便rtp2包内的音视频数据播放。
66.可选的，将所述第三rtp包存入所述缓存队列中，包括：确定所述缓存队列中的rtp包数量是否达到预设数量；若所述缓存队列中的rtp包数量未达到预设数量，则将所述第三rtp包存入所述缓存队列中。
67.通常缓存队列中能够存储的rtp包数量为定值，为保证缓存队列中数据可以有效的存储，在将udp缓存区读取的第三rtp包存入缓存队列中前，确定缓存队列中的rtp包数量是否达到预设数量。预设数量可根据需要进行选择，预设数量可为定值，也可为变化的值，如根据音视频播放进度调整。
68.s203：若所述第一rtp包的序号与当前播放音视频数据对应rtp包的序号不连续，则将所述第一rtp包存入所述缓存队列中。
69.若从udp缓存区读取到的第一rtp包不是当前播放音视频数据对应rtp包的连续包，将该第一rtp包存入缓存队列中。
70.进一步，缓存队列中通常只能存放一定数量的rtp包，而这个数量通常小于播放命令对应音视频数据的rtp包总数量或播放命令对应的音视频数据的rtp包并不能一次性从服务器发送至播放终端，因此需要在将缓存队列中存储的rtp包取走后及时将udp缓存区暂时存储的rtp包及时的存储至缓存队列中；另外服务器通过丢包重传返回的被丢rtp包也将被播放终端先暂存至udp缓存区，因此为避免该被丢包能够正常的被播放需要及时的将该重传的被丢rtp包及时的存储至缓存队列中。进而在本技术实施例中，当从udp缓存区中读取到与当前播放音视频数据对应rtp包不连续的第一rtp包，进行缓存队列的更新，即从udp缓存区读取到rtp包，将读取到的rtp包插入到缓存队列中。
71.进一步本技术实施例中，播放终端能够正常的播放音视频，本技术实施例还提供了一种rtp包丢包重传方法。图3为本技术实施例提供的再一种rtp包丢包重传方法的流程示意图。作为一个实施例，如图3所示，本技术实施例提供的rtp包丢包重传方法，还包括：
72.s301：确定所述缓存队列中是否存在第二rtp包的序号与当前播放音视频数据对应rtp包的序号连续。
73.本技术实施例中，第二rtp包只是为便于区分而进行的命名，并非用于限定，但通常是指缓存队列中现有的第一个rtp包。
74.当进行放音视频数据播放时，播放终端从缓存队列中读取第二rtp包并确定当前播放音视频数据对应rtp包的序号，解析获得第二rtp包的序号；根据当前播放音视频数据对应rtp包的序号和第二rtp包的序号，判定该第二rtp包是否为当前播放音视频数据对应rtp包的连续包。
75.如当前播放音视频数据对应rtp包的序号为10，若第二rtp包的序号为11，则第二rtp包是当前播放音视频数据对应rtp包的连续包，否则第二rtp包不是当前播放音视频数据对应rtp包的连续包。如，第二rtp包的序号为12或其他非11的序号，则第二rtp包不是当前播放音视频数据对应rtp包的连续包。
76.s302：若存在所述第二rtp包的序号与当前播放音视频数据对应rtp包的序号连续，则读取所述第二rtp包。
77.若第二rtp包是当前播放音视频数据对应rtp包的连续包，从缓存队列中取走该第二rtp包，解码该第二rtp包，待当前播放rtp包内音视频数据播放完接连播放该第二rtp包内的音视频数据。
78.s303：若不存在所述第二rtp包的序号与当前播放音视频数据对应rtp包的序号连续，则从udp缓存区读取第一rtp包。
79.若第二rtp包不是当前播放音视频数据对应rtp包的连续包，则从udp缓存区读取第一rtp包。
80.在本实施例提供的rtp包丢包重传方法中，播放终端在缓存队列中未找到与当前播放音视频数据对应rtp包连续的rtp包时，通过查找udp缓存区确定udp缓存区是否存在与当前播放音视频数据对应rtp包连续的rtp包；因为播放终端可通过丢包重传获取被丢包的
rtp包，当播放终端通过丢包重传获取到被丢包的rtp包将首先会被存储至udp缓存区，进而当udp缓存区存在与当前播放音视频数据对应rtp包连续的rtp包时，通过查找读取udp缓存区或许能够及时获取被丢包的rtp包以保证播放终端可连续播放音视频数据。
81.在本技术实施例中，播放终端还可以设置第一阈值数量；若缓存队列中的rtp数量达到第一阈值数量，则检查所述缓存队列中是否存在丢包；若检查到所述缓存队列中存在丢包，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求。
82.如此，能够在缓存队列中的rtp数量达到第一阈值数量时，及时的检查是否发生丢包，并在发现丢包后及时向服务器发送丢包请求，便于进一步的提高播放终端丢包请求命中服务器窗口期的命中率。
83.下面通过具体实施例对本发明实施例提供的方法进行描述：
84.以机顶盒作为播放终端为例。机顶盒向服务器请求音视频数据。服务器基于机顶盒的请求，依次向机顶盒发送携带音视频数据的200个rtp包，分别记为rtp0～rtp199。每一个rtp包中包括对应的序号，分别为0～199。机顶盒接收服务器返回的rtp包，但在200个rtp包从服务器依次传输至机顶盒的过程中，可能存在都丢包，即rtp0～rtp199中仅部分rtp包传输至机顶盒，进而机顶盒接收到rtp0～rtp199中部分rtp包，机顶盒将接收到的rtp包先暂存储至udp缓存区，再从udp缓存区将rtp包读取到队列中。
85.若机顶盒接收到rtp0，从udp缓存区中解析获取该rtp0的序号0，可知该rtp0为第一个rtp包。机顶盒解析rtp0，记录当前解析的rtp包的序号n＝0。机顶盒解码并播放rtp0中的音视频数据，记录当前播放音视频数据对应rtp包的序号为0。
86.若机顶盒接收到rtp1，机顶盒再次从udp缓存区读取rtp包，即读取到rtp1包，解析rtp1包获得rtp1包的序号n＝1。将rtp1存放至缓存队列中，同时机顶盒重复的从udp缓存区读取rtp包存放至缓存队列中，如表1；另外确定当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间。另外，机顶盒在播放rtp0中的音视频数据后从缓存队列中读取并解码播放rtp1中的音视频数据，并更新当前播放音视频数据对应rtp包的序号为1。
87.表1：
88.缓存队列rtp1
……
89.若机顶盒接收到rtp3，从udp缓存区中读取第一rtp包获取rtp3，解析获取rtp3的序号3，rtp3包的序号与当前播放音视频数据对应rtp包的序号不连续，机顶盒将rtp3存入缓存队列。另外，机顶盒进行rtp0中的音视频数据播放时通过从缓存队列中读取第二rtp包读取到rtp1，确定rtp1的序号与当前播放音视频数据对应rtp0包的序号连续，检查缓存队列中是否存在丢包，另外从缓存队列中读取rtp1并更新缓存队列，如表2所示。
90.表2：
91.缓存队列rtp3
……
92.或者，此过程中可判断当前时间与上一次发送丢包请求的时间间隔是否达到丢包
请求阈值时间；假设由于音视频刚开始播放，机顶盒还没有向服务器发送过丢包请求，则上一次发送丢包请求的时间t＝0；若当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，检查缓存队列中是否存在丢包，若是存在丢包，则基于根据丢包待重传rtp包的序号向服务器发送丢包请求。进而，机顶盒可判断出rtp2被丢包，确定丢包待重传rtp包的序号为2，则机顶盒向服务器发送重传请求，在重传请求中携带序号2，并记录丢包请求的时间t1，则更新上一次发送丢包请求的时间t＝t1。
93.或者，当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间，确定上一次检查缓存队列丢包比例的时间间隔是否达到最小丢包请求时间；假设由于音视频刚开始播放，机顶盒还从没有检查缓存队列丢包比例，则记录上一次发送检查缓存队列丢包比例的时间s＝0；若确定上一次检查缓存队列丢包比例的时间间隔达到最小丢包请求时间，则检查缓存队列中是否存在丢包，若是存在丢包，则确定当前时间缓存队列的丢包比例，并记录检查丢包比例的时间s1，更新上一次发送检查缓存队列丢包比例的时间s＝s1。进而，机顶盒可判断出rtp2被丢包，确定当前时刻缓存队列的丢包比例为50％；假设机顶盒内丢包比例阈值为10％，50％＞10％，则机顶盒向服务器发送重传请求，在重传请求中携带序号2，记录丢包请求的时间s2，并更新上一次发送丢包请求的时间t＝s2。通过最小丢包请求时间，一方面有助于避免过度频繁的检查缓存队列的丢包造成的资源浪费，另一方面有助于控制播放终端向服务器发送丢包请求的频繁程度。
94.机顶盒进行rtp1中的音视频数据播放时通过从缓存队列中读取第二rtp包读取到rtp3，确定rtp3的序号与当前播放音视频数据对应rtp1包的序号不连续，从udp缓存区读取rtp包；若机顶盒从udp缓存区读取到rtp4包，rtp4包与rtp1不连续，将rtp4包放入缓存队列中，如表3所示；若机顶盒从udp缓存区读取到rtp2包，rtp2包与rtp1连续，机顶盒解码并播放rtp2中的音视频数据，记录当前播放音视频数据对应rtp包的序号为2。
95.表3：
96.缓存队列rtp3rtp4
……
97.以此类推，若机顶盒依次接收到rtp6、rtp8、rtp9、rtp10、rtp11、rtp12，机顶盒依次将rtp6、rtp8、rtp9、rtp10、rtp11、rtp12从udp缓存区中存入缓存队列，如表4所示。
98.表4：
99.缓存队列rtp3rtp4rtp6rtp8rtp9rtp10rtp11rtp12
……
100.机顶盒在进行rtp2中的音视频数据播放时，继续从缓存队列中读取第二rtp包，读取到第二rtp包rtp3，确定rtp3的序号与当前播放音视频数据对应rtp2包的序号连续，机顶盒从缓存队列中的取走rtp3。若当前时间与上一次发送丢包请求时间t1的时间间隔达到丢包请求阈值时间，则检查缓存队列中是否存在丢包；通过检查缓存队列，获得rtp5和rtp7被丢包，确定丢包待重传rtp包的序号为5和7，机顶盒向视频服务器发送重传请求，在重传请求中携带序号5和7。另外，机顶盒在播放rtp2中的音视频数据后从缓存队列中读取并解码播放rtp3中的音视频数据，并更新当前播放音视频数据对应rtp包的序号为3，机顶盒删除缓存队列中的rtp3，进行缓存队列更新。
101.若机顶盒接收到视频服务器基于重传请求回应的rtp5，获取rtp5的序号5，机顶盒将rtp5插入缓存队列，如表5所示。
102.表5：
103.缓存队列rtp4rtp5rtp6rtp8rtp9rtp10rtp11rtp12
……
104.以此类推，机顶盒从缓存队列中依次读取rtp4～rtp6，并依次播放rtp4～rtp6携带的音视频数据，机顶盒删除缓存队列中的rtp4～rtp6。若在机顶盒向服务器发送重传请求，重传请求中携带序号5和7中未能获取成功的获取到rtp 7，那么在读取rtp4～rtp6后将还会向服务器发送重传请求且可能不止一次，重传请求中携带序号7，用于获取rtp7，因此将有较大概率的获取到rtp7，以保证rtp6后能正常的播放到rtp7的音视频数据。当然如此还是未能获取到rtp7，缓存队列如表6。
105.表6：
106.缓存队列rtp8rtp9rtp10rtp11rtp12
……
107.假设机顶盒预设最大播放间隔为2s。若当前时间与开始播放rtp6中音视频数据相差达到2s，则机顶盒直接读取缓存队列中rtp8并解析rtp8，获取rtp8中的音视频数据进行播放，以避免画面卡顿。
108.基于本技术实施例提供的rtp包丢包重传方法，本技术实施例还提供了一种rtp包丢包重传装置。图4为本技术实施例还提供的一种rtp包丢包重传装置的结构示意图。如图4所示，本技术实施例提供的rtp包丢包重传装置中，包括：
109.第一确定单元401，用于确定当前时间与上一次发送丢包请求的时间间隔是否达到丢包请求阈值时间；
110.第一检查单元402，用于若当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，则检查缓存队列中是否存在丢包；
111.第一请求单元403，用于若检查到所述缓存队列中存在丢包，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求；
112.第二检查单元404，用于若当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次检查缓存队列丢包比例的时间间隔达到最小丢包请求时间，则检查所述缓存队列并确定所述缓存队列的丢包比例；
113.第二请求单元405，用于若所述缓存队列的丢包比例大于丢包比例阈值，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求。
114.进一步，本技术实施例提供的rtp包丢包重传装置中，还包括：
115.第一读取单元，用于从udp缓存区读取第一rtp包，确定所述第一rtp包与当前播放音视频数据对应rtp包的序号是否连续；
116.第二读取单元，用于若所述第一rtp包的序号与当前播放音视频数据对应rtp包的序号连续，则读取所述第一rtp包并播放所述第一rtp包内的音视频数据；
117.第一插入单元，用于若所述第一rtp包的序号与当前播放音视频数据对应rtp包的序号不连续，则将所述第一rtp包存入所述缓存队列中。
118.进一步，本技术实施例提供的rtp包丢包重传装置中，还包括：
119.第一确定单元，用于确定所述缓存队列中是否存在第二rtp包的序号与当前播放音视频数据对应rtp包的序号连续；
120.第三读取单元，用于若存在所述第二rtp包的序号与当前播放音视频数据对应rtp包的序号连续，则读取所述第二rtp包；
121.第二读取单元，还用于若不存在所述第二rtp包的序号与当前播放音视频数据对应rtp包的序号连续，则从udp缓存区读取第一rtp包。
122.关于rtp包丢包重传装置的详细内容可参见本技术实施例提供的rtp包丢包重传方法中的详细描述。
123.基于本技术实施例提供的rtp包丢包重传方法，本技术实施例还提供一种播放终端。本技术实施例提供的播放终端，包括处理器，所述处理器被配置为：
124.确定当前时间与上一次发送丢包请求的时间间隔是否达到丢包请求阈值时间；
125.若当前时间与上一次发送丢包请求的时间间隔达到丢包请求阈值时间，则检查缓存队列中是否存在丢包；
126.若检查到所述缓存队列中存在丢包，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求；
127.若当前时间与上一次发送丢包请求的时间间隔未达到丢包请求阈值时间但当前时间与上一次检查缓存队列丢包比例的时间间隔达到最小丢包请求时间，则检查所述缓存
队列并确定所述缓存队列的丢包比例；
128.若所述缓存队列的丢包比例大于丢包比例阈值，确定丢包待重传rtp包的序号，并根据丢包待重传rtp包的序号向服务器发送丢包请求。
129.本技术实施例提供的播放终端可为机顶盒、社交电视等。进一步，关于播放终端的详细内容可参见本技术实施例提供的rtp包丢包重传方法中的详细描述。
130.最后应说明的是：以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围。