CN111385221A

CN111385221A - 一种数据处理方法和通信设备

Info

Publication number: CN111385221A
Application number: CN201811640869.7A
Authority: CN
Inventors: 陈雨辰; 魏岳军
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2018-12-29
Filing date: 2018-12-29
Publication date: 2020-07-07
Anticipated expiration: 2038-12-29
Also published as: CN111385221B

Abstract

本申请公开了一种数据处理方法，包括：确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，该丢弃条件为：第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且目标协议层已收到第二视频帧组中参考帧的数据包，第二视频帧组与第一视频帧组为不同的视频帧组；若确定满足丢弃条件，则丢弃第一数据包；若确定不满足丢弃条件，则保留第一数据包。本发明实施例还提供相应的通信设备。本发明技术方案由于数据包在超时的情况下，还必须满足不同视频帧组中的参考帧的数据包已到达的条件，才能对该超时数据包进行丢弃，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

Description

一种数据处理方法和通信设备

技术领域

本发明涉及通信技术领域，具体涉及一种数据处理方法和通信设备。

背景技术

随着网络的发展，实时视频的应用的越来越广泛，实时视频在进行数据传输时，由于原始视频的数据量太大，需要通过编码对视频数据进行压缩，使其形成适合网络传输的编码视频数据。

现有的视频压缩编码方案中，一个视频帧可以被编码为帧内编码帧(intraframe)或或向前预测编码帧(predictive-frame)，通常，帧内编码帧又被称为I帧，而向前预测编码帧被称为P帧，并以一个画面组(group of picture，GoP)，即一组视频帧为单位进行压缩，再以固定的频率发送出去。每一个GoP都以一个I帧开始，后面接着若干个P帧。其中，I帧的编码和解码都是独立的，P帧则需要参考其他帧，例如：I帧或者其他已编码的P帧进行编码。在解码时，除了I帧之外，每一个视频帧也都需要参考其他的帧进行解码，若被参考的帧不能正常解码，会造成后续的视频帧也不能正常解码，因此I帧具有非常重要的作用，若I帧不能正常解码或者缺失，会导致整组视频帧失效。

由于I帧为全帧压缩编码帧，包含一个完整的画面，而P帧只包含与前一帧的画面差别数据，因此I帧的数据量是远大于P帧的数据量，通常情况下可以达到P帧的100倍，这种高大小比例会造成视频流量具有很强的突发性，即在一段时间内，P帧数据量很小，浪费传输时间资源的浪费，而I帧数据量太大，很大概率下无法在这段时间内完成传输，而后被丢弃，使得整组视频帧无法正常解码，造成无线资源转化效率低，用户的应用体验差。

发明内容

本发明实施例提供一种数据处理方法，可以降低视频信息传输过程中的超时弃包率，从而提升无线资源转化效率，提升用户体验。

为达到上述目的，为达到上述目的，本申请第一方面提供一种数据处理方法，包括：确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，该丢弃条件为：第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且该目标协议层已收到第二视频帧组中参考帧的数据包，第二视频帧组与第一视频帧组为不同的视频帧组；若确定第一数据包满足丢弃条件，则从缓存队列中丢弃第一数据包；或者若确定第一数据包不满足丢弃条件，则在缓存队列中继续保留第一数据包。

由该第一方面可知，数据包在判断超时的情况下，还必须满足与该数据包对应的视频帧组不同的视频帧组中的数据包到达的情况下，才会对其进行丢弃，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

结合第一方面，在第一方面的第一种可能的实现方式中，所述方法还包括：接收第二数据包；确定第二数据包为第二视频帧组中参考帧的数据包。

由上述第一方面第一种可能的实现方式可知，对每个到达目标协议层的数据包，均会进行解析，确定数据包之间的帧间隔和帧类型信息的不同，从而提升判断数据包是否满足丢弃条件的精确度，更好的降低超时弃包率，提升无线资源转化效率，提升用户体验。

结合上述第一方面或第一方面第一种可能的实现方式，在第二种可能的实现方式中，确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件之前还包括：从缓存队列中获取第一数据包以响应目标协议层的下一协议层的调用。缓存队列中的数据包需要根据下一协议层中的调用指令进行发送，下一协议层需要调用缓存队列中的数据时，可以通过发送调用信息的形式从缓存队列中调用相应的数据包。

由上述第一方面第二种可能的实现方式可知，可以以接收缓存队列中数据包的调用信息为触发条件，在每次需要对缓存队列中的数据包进行发送时进行弃包条件的判断，从而提升方案的多样性。

结合上述第一方面或第一方面第一种可能的实现方式，在第三种可能的实现方式中，确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件之前还包括：数据队列的处理定时器超时。针对于缓存队列中的数据队列，处理定时器可以设置一个预设时长，每隔预设时长，处理定时器便处于超时状态，从而触发对缓存队列中的数据包的弃包条件的检测。

由上述第一方面第三种可能的实现方式可知，可以通过数据对了的处理定时器超时为触发条件，对缓存队列中的数据包进行弃包条件的判断，从而提升方案的多样性。

结合上述第一方面第一种可能的实现方式，在第四种可能的实现方式中，确定第二数据包为第二视频帧组中参考帧的数据包，包括：确定第二数据包的对应的视频帧的帧类型为参考帧，且第二数据包与前一到达所述目标协议层的数据包不是同一视频帧的数据包。

结合上述第一方面第四种可能的实现方式，在第五种可能的实现方式中，确定第二数据包与前一到达目标协议层的数据包不是同一视频帧的数据包，包括：确定第二数据包的实时传输协议RTP的协议头中的时间戳和前一到达所述目标协议层的数据包的RTP协议头中的时间戳不同。RTP协议头中的时间戳信息用于指示视频帧的产生时间，因此通过时间戳的对比可以确定两个数据包是否属于同一个视频帧。在已经确定第二数据包是参考帧的情况下，若前一个数据包与第二数据包不是同一个视频帧，可以确定第二数据包对应于一个新的视频帧组中的参考帧。

结合上述第一方面、第一方面第一种至第五种中任意一种可能的实现方式，在第六种可能的实现方式中，目标协议层包括第一子层和第二子层，第一子层用于从目标协议层的上一协议层接收数据包，并对接收到的数据包进行解析；第二子层用于响应与目标协议层的下一协议层对数据包的调用，并确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件。

结合上述第一方面第六种可能的实现方式，在第七种可能的实现方式中，第一子层还用于将解析得到数据包的帧类型传递至第二子层。

结合上述第一方面第六种或第七种可能的实现方式，在第八种可能的实现方式中，第一子层为分组数据汇聚协议PDCP层，第二子层为无线链路控制层协议RLC层。

结合上述第一方面、第一方面第一种至第五种中任意一种可能的实现方式，在第九种可能的实现方式中，目标协议层为无线局域网中的多路访问控制MAC层。

本申请第二方面提供一种通信设备，所述通信设备用于执行上述第一方面或第一方面的任一可能的实现方式中的数据处理方法。具体地，所述通信设备可以包括用于执行第一方面或第一方面的任一可能的实现方式中的数据处理方法的模块。

本申请第三方面提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现第一方面或第一方面的任一可能的实现方式中的方法。

本申请实施例采用一种数据处理方法，使得缓存队列中的数据包在超时的情况下，还必须满足下一视频帧组中的参考帧已经到达的条件，才能对该超时数据包进行丢弃，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

附图说明

图1(a)是终端设备视频通话场景的示意图；

图1(b)是视频监控场景的示意图；

图2为本申请实施例提供的视频数据传输协议栈的一个示意图；

图3为本申请实施例中数据处理方法的一个实施例示意图；

图4为本申请实施例中数据处理方法的另一个实施例示意图；

图5(a)为NAL协议头的示意图；

图5(b)为分段头的结构示意图；

图5(c)为IPv4结构的示意图；

图5(d)为IPv6结构的示意图；

图5(e)为RTP协议头示意图；

图6为本申请实施例中数据处理方法的另一个实施例示意图；

图7是本申请实施例中数据处理方法的另一个实施例示意图；

图8为本申请实施例中数据处理方法的另一个实施例示意图；

图9为本申请实施例中数据处理方法的另一个实施例示意图；

图10为本申请实施例提供的通信设备的一个示意图；

图11为本申请实施例提供的通信设备的另一示意图；

图12为本申请实施例提供的一种终端设备的结构示意图；

图13为本实施例提供的通信设备的另一示意图。

具体实施方式

下面结合附图，对本发明的实施例进行描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。本领域普通技术人员可知，随着图计算框架的演变和新应用场景的出现，本发明实施例提供的技术方案对于类似的技术问题，同样适用。

本申请实施例提供一种数据处理方法，使得缓存队列中的数据包在超时的情况下，还必须满足下一视频帧组中的参考帧到达的条件，才能对超时数据包进行丢弃，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。本发明实施例还提供相应的通信设备。以下分别进行详细说明。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

随着互联网的不断发展与普及化，人们迫切希望在互联网上传送或接收更多的多媒体信息。视频信号的传输是多媒体信息传输的核心关键所在，视频信号是一种实时信号，需要连续不断地在终端上显示，数据的丢失以及不及时显示都会影响用户的视觉体验。图1(a)和图1(b)分别给出了两个基于实时视频信息传输的常见应用场景。

图1(a)是终端设备视频通话场景的示意图。当代社会，视频通话也是一种很常见的基于实时视频信息传输的通信方法，在视频通话的过程中，终端设备101，如智能手机，通过对摄像头所采集的视频信息进行编码处理，形成适合网络传输的编码视频数据后，通过网络传输至另一终端设备102上进行解码后实时播放。

图1(b)是视频监控场景的示意图。随着平安城市、智能交通等各项建设的持续开展,视频监控系统在安防领域的应用保持着稳定的增长，如图1(b)所示，与监控摄像头相连接的终端设备对监控摄像头采集的监控视频信息进行编码处理，使其形成适合网络传输的编码视频数据，服务器接收经由网络传输的视频数据后，经过解码后再显示器上实时播放视频信息。

接下来将以3GPP协议的视频数据传输协议栈为例进行具体的视频信息传输过程的介绍，请参阅图2。

图2为本申请实施例提供的视频数据传输协议栈的一个示意图。

图2以使用3GPP协议的视频数据传输协议栈对本申请实施例中的视频传输过程进行介绍。需要说明的是，本申请实施例可以基于并使用3GPP协议的视频数据传输协议栈的相关技术及背景来对本申请实施例中的数据处理方法进行介绍，但并不应理解为对本申请实施例中的数据处理方法的限制；本申请实施例的技术方案除了可以应用于采用第三代合作伙伴计划(3rd generation partnership project，3GPP)协议的视频数据传输协议栈来传输视频数据，也可以应用于采用WiFi协议的视频数据传输协议栈来传输视频数据，除此之外，还可以应用于其它的视频数据传输协议栈，本申请实施例对此不作限定。

由图2可以看出，视频数据的传输依次需要经过应用层、RTP层、UDP层、IP层、PDCP层、PLC层、MAC层和物理层，此处的不同层级的划分是一种逻辑上的划分，每一层中包含相应的视频数据处理的协议，每一层协议都对数据包进行进一步的封装处理。

由于原始视频信息的数据量大，为了便于传输，原始视频信息会经过压缩编码，形成适合传输的视频数据，即视频帧，每一个GoP均由一个I帧开始，后面跟着若干个P帧。如图2中的应用层中柱状图的每一个柱子，均可以代表一个视频帧，柱子的高低代表每个视频帧的数据量大小，其中，两个黑色的柱子为I帧，每个I帧的数据量都远远大于其后的若干个表示P帧的白色柱子，I帧是一个GoP中最重要的视频帧，是后续的P帧在编解码时需要参考的参考帧。在应用层中，编码完的视频帧数据需要进行格式化及添加头信息，以保证数据适合在信道和存储介质中传输，因此可以用网络抽象层(network abstract layer,NAL)实现视频帧数据的封装，从而形成NAL单元，一个视频帧可以对应一个NAL单元也可以对应多个NAL单元。受限于网络传输的数据包的最大允许数据量，一个NAL单元在到达实时传输协议(real-time transport protocol，RTP)层，可能会被拆分为多个RTP数据包，RTP协议是一个网络传输协议，通常创建在用户报协议(user datagram protocol，UDP)上，在经过网络传输RTP协议封装处理之后形成包含RTP头的RTP数据包。RTP数据包会再经过传输层，其中的UDP协议是一种无连接的协议，其位于网际协议(internet protocol，IP)的顶层，用于将RTP数据包进行压缩，形成UDP数据包。UDP数据包到达IP层之后，形成IP数据包，然后传输至目标协议层中的PDCP层。为了保证视频信息的实时性，IP包到达目标协议层的PDCP层后，可以由PDCP层协议实体会对到达该层的IP包进行定时，可以是对IP包的到达时刻计时，如IP包在进入PDCP层开始计时，然后进行加密和添加PDCP协议头形成PDCP数据包，并传递至RLC层；RLC层协议实体在对PDCP数据包添加RLC头形成PLC数据包缓存于RLC队列中，并等待下一协议层，如MAC层协议实体的发送调用指令从而进行传输。最后数据经过空口传输到达接收端后，视频数据会被从RTP解封装后重组成NAL单元，然后以NAL单元为单位进行解码，生成原始视频帧，显示在终端屏幕上。其中，为了保证业务流的实时性，可以通过定时功能丢弃队列中超时未被传输的数据包。定时功能可以通过RLC层协议实体实现,也可以在PDCP层协议实体实现，如在相应的协议层设置一个循环定时器，该循环定时器设置为预设时长，如150ms，每隔150ms，该循环定时器便会检查RLC队列中的RLC数据包从进入PDCP层开始计时的时刻至当前时刻的时长是否超过了预设时长，若超过了预设时长，则RLC数据包便为超时数据包，超时的数据包将会被丢弃。否则，则继续保留在队列中等待调用并传输。需要说明的是，本申请中协议实体是根据协议层功能的逻辑划分，可以是不同的软件或硬件模块，或者软件和硬件模块实现，本申请并不以此为限制。

由于视频数据的I帧数据量较大，上述方法可能会因为视频数据高突发性和RLC层的定时机制造成I帧传输超时，即在RLC层中常常出现I帧在超时之前未能完成传输，循环定时器判断超时后被丢弃的情况。因此，若接收端没有收到I帧就无法对相应的P帧数据进行正确解码，从而造成无线资源转化效率低，最终影响用户体验。

图3为本申请实施例中数据处理方法的一个实施例示意图，该数据处理方法可以降低超时数据包的弃包率，从而提升无线资源转化效率，提升用户体验。

参阅图3，本申请实施例中的数据处理方法包括：

301、通信设备确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，该丢弃条件为：第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且目标协议层已收到第二视频帧组中参考帧的数据包，第二视频帧组与第一视频帧组为不同的视频帧组。

本申请实施例中，第一数据包为第一视频帧组中第一视频帧的数据包，其中，第一视频帧可以是参考帧，也可以是非参考帧，本申请实施例对第一数据包对应的第一视频帧的帧类型不做具体的限定。其中，参考帧可以是重要性高的帧，例如，I帧或者P帧中重要性高的帧，相应地非参考帧往往是重要性较低的帧，例如，P帧中重要性低的帧。一种可能的实现方式中，如果P帧重要性相同，则参考帧可以是I帧，非参考帧可以是P帧。此处仅为举例说明，并不构成限制。

本申请实施例中，第一视频帧的第一数据包位于目标协议层的缓存队列中等待传输，若第一数据包在预设的丢弃时长内还没有发送出去，则可以认为该第一数据包超时，判断第一数据包超时的方式为从第一数据包进入目标协议层的某个时刻开始计时，至进行超时判断的时刻之间的时间间隔是否是大于预设的丢弃时间的，当第一数据包超时并且确定已经接收到第二视频帧组中参考帧的数据包时，便可以确定第一数据包满足丢弃条件。

302、若确定满足丢弃条件，则通信设备丢弃第一数据包。

本申请实施例中，若第一数据包满足丢弃条件，则将第一数据包从缓存队列中丢弃，例如可以是将其从缓存队列中删除。

303、若确定不满足丢弃条件，则通信设备保留第一数据包。

本申请实施例中，若不能同时满足第一数据包已经超时和已经接收到不同视频帧组中参考帧的数据包这两个条件，则在缓存队列中继续保留第一数据包，直到接收到不同视频帧组中参考帧的数据包或者当前用于调度视频帧传输的周期结束，若超时的第一数据包还未发送出去，才会被从缓存队列中丢弃。

本申请实施例中，当对缓存队列中的数据包进行超时判断时，只有当确认下一个视频帧组的参考帧到达时，超时数据才会被丢弃，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

上述对本申请实施例中数据处理方法的一个实施例进行了介绍，在对数据包进行弃包条件判断之前，还存在对接收的数据包进行解析的过程，因此，本申请实施例提供数据处理方法的另一个实施例，请参阅图4。

图4为本申请实施例中数据处理方法的另一个实施例示意图。

参阅图4，本申请实施例中的数据处理方法包括：

401、通信设备接收到达目标协议层的第二数据包，并对第二数据包进行解析，以确定第二数据包为第二视频帧组中参考帧的数据包。

本申请实施例中，当第二数据包到达目标协议层后，通信设备在对第二数据包进行目标协议层中的协议封装之前，会先对第二数据包的信息进行解析，从而确定第二数据包所对应的视频帧为第二视频帧组的参考帧。本申请实施例中的参考帧可以参阅图3中步骤301中的相关内容进行理解，此处不再赘述。需要说明的是，本申请实施例中目标协议层中的协议，可以是指一个协议，即通信设备通过一个协议实现相应的数据处理，例如无线局域网场景下视频数据的传输可能只存在MAC协议，通信设备在此场景下可以只通过MAC协议完成对第二数据包的数据处理；当然目标协议层也可以是指多个协议，对应于多个子层，即通信设备通过多个协议对第二数据包进行相应的数据处理。例如，目标协议层包含两个子层，第一子层和第二子层，第一子层用于接收和解析数据包，第二子层用于控制数据包的调用和发送例如3GPP场景下的PDCP层和RLC层，目标协议层的下一个协议层可以是MAC层，通信设备在此场景下分别在PDCP层和RCL层对第二数据包进行相应的数据处理，本申请实施例对此不做具体的限定。

本申请实施例中，通信设备确定第二数据包所对应的视频帧为第二视频帧组的参考帧的方式，可以是通过确定第二数据包对应的视频帧的帧类型为参考帧，且第二数据包与前一个到达目标协议层的数据包不是同一个视频帧的数据包的方式。

可选地，本申请实施例中可以通过帧边界识别的方法判断确定第二数据包与前一个到达目标协议层的数据包是否是同一个视频帧的数据包，可以是根据第二数据包与前一个到达目标协议层的数据包中的RTP协议头中的时间戳来判断。由于RTP协议头中的时间戳用于指示数据包对应的视频帧的生成时间，因此根据时间戳的异同，就可以判断两个数据包是否属于同一个视频帧。若时间戳相同，则可以确定，第二数据包和该前一个到达的数据包属于同一个视频帧，则根据该前一个到达目标协议层的数据包对应的帧类型信息就可以确定第二数据包对应的视频帧的帧类型信息；若时间戳不相同，则可以确定，第二数据包和该前一个到目标协议层的数据包属于不同的视频帧。

可选地，当第一时间戳和第二时间戳不相同时，第二数据包和该前一个到达目标协议层的数据包属于不同的视频帧，此时，可以根据两个数据包时间戳的大小以及第二数据包中的视频编码协议的协议头来判断第二数据包对应的视频帧的类型。

本申请实施例中，由于不同的帧类型在数据包中的视频编码协议的协议头中的标识字段的取值一般是不同的，即该标识字段的不同取值可以代表不同的帧类型，例如，该视频编码协议可以是NAL协议。因此，在第二数据包和前一个到达目标协议层的数据包的时间戳不相同的情况下，通信设备可以根据两个数据包时间戳的大小以及第二数据包中的视频编码协议的协议头来判断第二数据包对应的视频帧的类型，可以是直接通过视频编码协议的协议头中的标识字段的取值来确定。

可选地，若本申请实施例的第二数据包所使用的视频编码协议是NAL协议，解析第二数据包对应的视频帧的帧类别信息的方法，可以是采用解析NAL协议头的信息的方法：

NAL协议头的结构如图5(a)所示，本实施例中识别帧类别的信息需要用到的是该NAL协议头中的Type字段，表1示出了NAL单元的类型以及NRI域值的对应表。

由表1可以看出，当NAL的Type字段取值为7时，表示第二数据包为序列参数集包的重要数据，因而可以判断第二数据包对应的视频帧为参考帧。

在另外一些情况下，还需要结合时间戳的大小来进行判断，例如，若第二数据包的时间戳大于前一个数据包的时间戳，当NAL协议头的Type字段取值是5时，也可以确定第二数据包对应的视频帧为参考帧。若NAL协议头的Type字段是28，则表明第二数据包携带的是分段数据，此时，后面一个字节为分段头FU_HEADER，分段头的结构如图5(b)所示，其中的Type字段对应数据的类型，如果取值是5，则认为第二数据包为参考帧。需要说明的是，本申请实施例中仅仅是以现有的NAL协议以及对应的标识字段的取值来进行具体的举例说明，若采用其他相同功能的协议或者标识字段取值的含义产生变化，此处举例中的具体内容不应当被理解为本申请实施例中相应的数据处理方法的限制。

表1NAL单元类型与NRI域值的对应表

本申请实施例中，通信设备对第二数据包进行解析，在确定第二数据包为第二视频帧组中参考帧的数据包之前，由于传输到目标协议层的数据包可能包括很多类型的数据，不一定是本申请实施例中用于传输实时视频信息的数据包，因此通信设备会首先判断到达目标协议层的第二数据包是否是实时媒体传输协议的数据包，如RTP数据包，在确定第二数据包是实时媒体传输协议的数据包之后，通信设备才会对第二数据包进行下一步相应的数据处理。

例如，本申请实施例中的实时媒体传输协议可以是实时传输(real-timetransport protocol，RTP)协议，通信设备会首先判断第二数据包是否是RTP数据包，在确认第二数据包是RTP数据包之后，通信设备才会对该第二数据包进行本申请实施例中的进一步的相应的数据处理。

可选地，本申请实施例中通信设备判断第二数据包是否是实时媒体传输协议的数据包，具体的方式可以是首先解析第二数据包中是否包含实时媒体传输协议的协议头，然后根据协议头结构中的标识字段的内容的取值判断第二数据包是否是实时媒体传输协议的数据包。例如，本申请实施例中的实时媒体传输协议为RTP协议，则通信设备可以首先解析第二数据包中是否包含RTP的协议头。

可选地，当实时媒体传输协议为RTP协议，通信设备解析第二数据包中是否包含RTP的协议头的方法，可以是通过判断第二数据包使用的传输层协议是否是UDP协议来判断，具体如下：

通常情况下，UDP包一般都会对应RTP包或RTCP包，因此本申请实施例中通信设备解析第二数据包是否包含RTP的协议头的方法可以是首先判断第二数据包使用的传输层协议是否是UDP协议，具体的可以是通过第二数据包的头结构中的目标标识字段的取值来进行判断。第二数据包一般存在两种头结构，即IPv4和IPv6，不同的头结构下，判断的过程有所不同。

例如，若第二数据包的头结构是如图5(c)所示的IPv4结构，可以是通过IPv4头中的protocol字段，识别第二数据包所使用的的传输层协议。其中，传输层协议与protocol字段的对应表可以参阅表2。

表2传输协议层与Protocol字段的对应表

如表2可知，若IPv4头中的protocol字段取值为17，便可以确定第二数据包使用的传输层协议为UDP协议。

可选地，若第二数据包的头结构是如图5(d)所示的IPv6结构，若该IPv6结构不使用扩展头，可以是采用上述IPv4的方法读取基本头中的next header域的取值，该取值用于指示后续头的协议类型，具体的协议类型可以参阅表3进行了解，IPv6的的next header域的定义如表3所示。

表3 IPv6的的next header域的定义

由表3可知，IPv6的扩展头共有六种，对应表3中的取值，分别为逐跳选项扩展头(0)、路由扩展头(43)、分片扩展头(44)、ESP加密头(50)、AH认证头(51)和目的选项扩展头(60)。需要说明的是，IPv6的基本头和扩展头中都有next header域，用于指示紧邻的后续头的类型。因此，通常情况下如果该域的值为17，则可以确定第二数据包使用的传输层协议为UDP协议；若基本头中的next header域的取值不为17，可以进一步判断该取值是否为0、43、44、50、51或者60中的任意一个，若是，则需要再往后面的扩展头中读取头信息，直到读到最后一个扩展头中的next header域的取值为17，便可以确定第二数据包使用的传输层协议为UDP协议。

需要说明的是，本申请实施例中所例举的根据第二数据包头结构中相应字段的取值来确定传输层协议，不应被理解为本申请实施例中相应的数据处理方法的限制，具体的协议与目标字段的取值还可能在一些场景下是其他的对应关系，本申请实施例对此不做限定。

可选地，在确定第二数据包使用的传输层协议为UDP协议之后，判断第二数据包是否是RTP数据包的方法可以是通过协议头结构中的标识字段来确认，具体如下：

由于RTP协议和实时传输控制协议RTCP的协议头的结构是相同的，因此，通信设备可以分析协议头中可以用于指示视频帧帧类别信息的目标标识字段的取值是否是RTP数据包的取值来进行区分。

例如，协议头中的有效负载类型(payload type，PT)字段可以表示数据包的类型是RTP数据包，还是实时传输控制协议RTCP的数据包，若PT字段为200-204，则一般认为该数据包为RTCP包，否则，便可以认为第二数据包是RTP数据包。

RTP协议头如图5(e)所示，其中的PT字段可以用来区分RTP数据包和RTCP包。现有的协议中对RTCP包的有效负载类型(payload type，PT)字段定义如表4所示。基于表4中的PT字段定义，当协议头中的PT字段不为如表1中200-204取值时，便可以确定第二数据包是RTP数据包。

表4 RTCP包的PT字段定义

RTCP包	PT域对应的数值
		发送端报告SR	200
接收端报告RR	201
		源描述SDES	202
通知离开BYE	203
		应用程序APP	204

需要说明的是，本申请实施例中所提供的PT字段取值为200-204与RTCP包的对应关系，在一些场景下也可能会产生改变，如对应于不同的取值，因此本实施例中的所例举的取值对应关系不应当被理解为本申请实施例中数据处理方法的限制。

除此之外，本申请实施例中的实时媒体传输协议，除了可以是例举的RTP协议，在一些场景下，也可以是其他的用于实时媒体传输的协议，本申请实施例对此不做具体的限定,在实际应用中，若采用其他的实时媒体传输协议，也可以通过分析协议头中标识字段取值的方式来确定第二数据包所传输的信息的类型是否是实时视频信息，本申请实施例对此不做具体的限定。

通信设备在步骤401中，记录确定接收到第二视频帧组中参考帧的数据包这一状态，一种可能的实现方式为，待数据队列的定时器超时，例如下述实施例图7中的步骤701，或者响应下一协议层调用获取第一数据包，例如下述实施例图6中的步骤601，再根据下述步骤402～404处理所述第一数据包，另一种可能的实现方式为，继续根据下述步骤402～404处理所述第一数据包，而无需等待数据队列的定时器超时或者下一协议层调用。

402、通信设备确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，该丢弃条件为：第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且目标协议层已收到第二视频帧组中参考帧的数据包，第二视频帧组与第一视频帧组为不同的视频帧组。

本申请实施例中，第一数据包为第一视频帧组中第一视频帧的数据包，本申请实施例对第一数据包对应的第一视频帧的帧类型不做具体的限定。第一数据包位于目标协议层的缓存队列中等待传输，若第一数据包在预设的丢弃时长内还没有发送出去，则可以认为该第一数据包超时，判断第一数据包超时的方式为从第一数据包进入目标协议层的某个时刻开始计时，至进行超时判断的时刻之间的时间间隔是否是大于预设的丢弃时间的。例如，通信设备在第一数据包到达目标协议层的时刻起开始计时，并设置丢弃时长为150ms，当通信设备检测到位于缓存队列中的第一数据包的计时时长超过150ms，即可以判断第一数据包超时未发送。通信设备确定第一数据包超时并且确定已经接收到第二视频帧组中参考帧的数据包时，便可以确定第一数据包满足丢弃条件。

本申请实施例中，由于通信设备已经接收到第二视频帧组中参考帧的第二数据包，因此本申请实施例可以是在通信设备接收到第二数据包，并确定第二数据包为第二视频帧组中参考帧的数据包之后，立刻对目标协议层的缓存队列中待发送的第一数据包进行超时判断，若检测到第一数据包的缓存队列中的计时时长大于丢弃时长，则确定第一数据包满足了丢弃条件。本申请实施例中，除了可以是在接收到第二数据包，且确定第二数据包为不同视频帧组中参考帧的数据包时，触发对第一数据包的超时判断，还可以是其他的触发条件，本申请实施例对此不做限定。

403、若确定满足丢弃条件，则丢弃第一数据包。

本申请实施例可以参阅图3中的步骤302进行理解，此处不再赘述。

404、若确定不满足丢弃条件，则保留第一数据包。

本申请实施例可以参阅图3中的步骤303进行理解，此处不再赘述。

本申请实施例中，通过对接收到的数据包进行解析，确定数据包对应的帧类型的信息，以及帧边界，从而可以提升本申请实施例中对数据包的弃包条件判断的精确性，使得缓存队列中的数据包超时时，只有当确认下一个视频帧组的参考帧到达时，超时数据才会被丢弃，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

图6为本申请实施例中数据处理方法的另一个实施例示意图。

参阅图6，本申请实施例中的数据处理方法包括：

601、通信设备从缓存队列中获取第一数据包以响应目标协议层的下一协议层的调用。

本申请实施例中，通信设备从缓存队列中获取第一数据包以相应目标协议层的下一协议层的调用，可以是通信设备接收从目标协议层的下一协议层对于目标协议层缓存队列中的第一数据包的调用指令，在接收到该指令后，通信设备对第一数据包进行进一步的处理。

602、通信设备确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，该丢弃条件为：第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且目标协议层已收到第二视频帧组中参考帧的数据包，第二视频帧组与第一视频帧组为不同的视频帧组。

本申请实施例中，通信设备从缓存队列中获取第一数据包以相应目标协议层的下一协议层的调用，例如，接收到下一协议层对于目标协议层缓存队列中的第一数据包的调用指令后，会首先确定第一数据包是否满足丢弃条件。

本申请实施例中，确定第一数据包是否满足丢弃条件可以参阅图4中的步骤403进行理解，此处不再赘述。

603、若确定满足丢弃条件，则丢弃第一数据包。

604、若确定不满足丢弃条件，则保留第一数据包。

本申请实施例中，若不能同时满足第一数据包已经超时和已经接收到不同视频帧组中参考帧的数据包这两个条件，则第一数据包按照目标协议层的下一协议层的调用进行发送。

可选地，在步骤602之前，本申请实施例还可以包括通信设备接收到达目标协议层的第二数据包，并确定第二数据包为第二视频帧组中参考帧的数据包的步骤，具体也参阅图4中的步骤401进行理解，此处不再赘述。

本申请实施例中，通信设备在接收到缓存队列中数据包的调用指令时，触发对被调用的数据包的弃包条件判断，超时的数据包只有在下一个视频帧组中参考帧的数据包到达之后，才会被丢弃，剩下的数据包再接收调用，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

图7为本申请实施例中数据处理方法的另一个实施例示意图。

参阅图7，本申请实施例中的数据处理方法包括：

701、数据队列中的处理定时器超时。

本申请实施例中，目标协议层中可以存在一个处理定时器触发缓存队列中的数据包的超时判断，该处理定时器可以是针对缓存队列中的数据包的处理定时器，用于周期性的检测缓存队列中的数据包是否满足丢弃条件。

702、通信设备确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，该丢弃条件为：第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且目标协议层已收到第二视频帧组中参考帧的数据包，第二视频帧组与第一视频帧组为不同的视频帧组。

本申请实施例中，当处理定时器超时时，通信设备立刻对缓存队列中的第一数据包进行检测，以确定其是否满足丢弃条件。

703、若确定满足丢弃条件，则丢弃第一数据包。

704、若确定不满足丢弃条件，则保留第一数据包。

可选地，本申请实施例在步骤702之前，还可以包括通信设备接收到达目标协议层的第二数据包，并确定第二数据包为第二视频帧组中参考帧的数据包的步骤，具体也参阅图4中的步骤401进行理解，此处不再赘述。

本申请实施例中，通信设备可以通过处理定时器超时的触发条件，触发对被调用的数据包的弃包条件判断，超时的数据包只有在下一个视频帧组中参考帧的数据包到达之后，才会被丢弃，剩下的数据包再接收调用，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

图8为本申请实施例中数据处理方法的另一个实施例示意图。

参阅图8，本申请实施例中的数据处理方法包括：

801、通信设备对到达目标协议层第一子层的第二数据包进行解析，以确定第二数据包为第二视频帧组中参考帧的数据包。

本申请实施例中，目标协议层包含第一子层和第二子层，第一子层用于从目标协议层的上一协议层中接收数据包，并对数据包进行解析。

本申请实施例中，通信设备在第一子层接收第二数据包，并对第二数据包进行解析，第一子层中包括对传输数据进行接收时对应的第一协议，例如PDCP协议，和控制数据传输的第二协议，例如RLC协议，因此针对这两种不同功能的协议，可以分别对应着目标协议层中的两个不同的协议子层。第一协议对应于第一子层，第二协议对应于第二子层。需要说明的是，目标协议层还可以包含除了该第一协议和第二协议的其他协议，例如MAC协议，本申请实施例对此不做具体的限定。

第二数据包到达第一子层后，通信设备在对第二数据包进行第一子层的协议封装之前，会首先在第一子层中对该第二数据包进行解析，从而获取该第二数据包所对应的视频帧的帧类型。例如，本申请实施例中若第一子层对应的协议可以是PDCP协议，在第一子层对第二数据包进行封装可以是指对第二数据包进行加密和加PDCP协议头。

本申请实施例中，通信设备对第二数据包进行第二视频帧的帧类型的解析方式，可以参阅图4中的步骤401进行理解。

可选地，由于一个画面组中，参考帧中的数据量在一般情况下，是远远大于其他帧的，例如可以是十倍的数据量差距，因此，本申请实施例中通信设备对第二数据包进行视频帧的帧类型的解析，还可以采用第二种方式来判断第二数据包对应的视频帧的帧类型。第二种判断帧类别的方式可以是：通信设备对到达第一子层中的数据包的数据量进行实时的统计，计算每个目标单位时间内到达第一子层的多个数据包中的总流量的大小；若第二数据包是属于某个目标单位时间内到达第一子层的数据包，且该目标单位时间下所有到达的数据包的总流量是否超过了预设阈值的数据量，例如，预设阈值的数据量可以是5万字节，若超过了5万字节，则可以确定属于该目标单位时间内到达的所有数据包是帧类别为参考帧的视频帧的数据包，即第二数据包对应的视频帧为参考帧。

802、通信设备将第二数据包对应的视频帧的帧类型的信息传递至目标协议层第二子层。

本申请实施例中，通信设备在第一子层解析出第二数据包对应的视频帧的帧类型信息后，会将该帧类型的信息从第一子层传输到第二子层。本申请实施例中，通信设备将帧类型的信息从第一子层传输到第二子层，可以是通过物理接口的方式进行传输，也可以是通过第一子层和第二子层的私有接口，如在对第二数据包进行第一子帧中的协议的协议头封装时，通过该协议的协议头传输，可以理解的是，本申请实施例也可以其他的方式将在数据链路第一子层中解析出来的帧类型的信息传递至第二子层中，本申请实施例对此不做具体的限定。

803、在第二子层中，确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，该丢弃条件为：第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且目标协议层已收到第二视频帧组中参考帧的数据包，第二视频帧组与第一视频帧组为不同的视频帧组。

本申请实施例中，第二子层用于响应下一协议层对数据包的调用，例如，根据下一协议层发送来的对缓存队列中的数据包的调用指令，将数据包发送给下一协议层。除此之外，第二子层还用于确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件。本申请实施例中，确定第一数据包是否满足丢弃条件可以参阅图4中的步骤403进行理解，此处不再赘述。

804、若确定满足丢弃条件，则丢弃第一数据包。

805、若确定不满足丢弃条件，则保留第一数据包。

上述介绍了当目标协议层中存在多层数据处理协议时，本申请实施例中通信设备对第二数据包进行分层处理的数据处理方法，接下来将具体介绍3GPP协议下，上述实施例中，目标协议层的第一子层为PDCP层，第二子层为RLC层时本申请实施例中的数据处理方法，请参阅图9。

图9是本申请实施例中数据处理方法的另一个实施例示意图。

参阅图9，本申请实施例中的数据处理方法包括：

901、通信设备判断到达PDCP层的第二数据包的传输协议是否为UDP协议。

本申请实施例中，目标协议层包括PDCP层和RLC层。第二数据包首先到达PDCP层，在PDCP层，通信设备会首先判断第二数据包的传输层协议是否为UDP协议。

本申请实施例可以参阅图4中的步骤401中的内容进行理解，此处不再赘述。

902、若是，通信设备确定该第二数据包是否是RTP数据包。

本申请实施例中，由于所有的UDP包在一般情况下都对应RTP或者RTCP包，因此在通信设备确定第一数据包的传输层协议为UDP协议之后，还需要进一步的判断第二数据包是否是RTP数据包。由于RTP包和RTCP包的协议头结构相同，具体的区别在于PT字段的取值。

具体的，本申请实施例可以参阅图4中步骤401中的相应内容进行理解，此处不再赘述。

903、若第二数据包是RTP数据包，则通信设备识别第二数据包对应的视频帧的帧类别。

本申请实施例中，在确定第二数据包是RTP数据包之后，通信设备便开始解析第二数据包对应的视频帧的类型。

本申请实施例中，通信设备解析第二数据包对应的视频帧的帧类型，可以先进行视频帧的帧边界识别，帧边界的识别可以使用RTP协议头中的时戳信息来完成，RTP的时间戳字段记录了数据包中数据的第一个字节的采样时刻，对于一个视频帧来说，属于该视频帧的所有数据包都具有相同的RTP时戳信息。

基于图4中步骤401的相关内容，一般情况下，时戳信息在RTP协议头中第5-8个字节，因此RTP时戳信息可以直接从第二数据包中的第33-36个字节中读取。具体的，可以是先将第二数据包的RTP时戳信息与该第数据包前一个到达的数据包的RTP时戳信息进行对比。若RTP时戳信息相同，则可以确定第二数据包和该前一个到达的数据包属于同一个视频帧，根据该前一个到达目标协议层的数据包对应的帧类型信息就可以确定第一数据包对应的第一视频帧的帧类型信息。若RTP时戳信息不相同，则可以确定第二数据包和该前一个到达目标协议层的数据包属于不同的视频帧，此时，便可以根据两个RTP时戳信息的大小以及第二数据包中的NAL协议头来判断视频帧的类型。本申请实施例中可以采用三种判断方式来判断帧类别的信息：若通信设备判断第二数据包的NAL协议头中的Type字段取值为7，可以确定第二数据包为序列参数集，则可以确认视频帧为I帧；若第二数据包的RTP时戳信息大于上一个数据包的RTP时戳信息，且Type字段取值为5，则可以确认视频帧为I帧；若通信设备判断第二数据包的NAL协议头中的Type字段取值为28，则说明第二数据包是分段数据，若后面的一个字节为分段头，且分段头的取值为5，则确定视频帧为I帧。

904、通信设备将第二数据包对应的视频帧的帧类别的信息从PDCP层传递给RLC层。

本申请实施例中，通信设备在PDCP层解析出第二数据包对应的视频帧的帧类型信息后，会将该帧类型的信息从PDCP层传递到RLC层。

可选地，本申请实施例中通信设备将帧类型的信息从PDCP层传递到RLC层，可以是通过PDCP层和RLC层之间的一个物理接口来传输，具体的，通信设备可以通过该物理接口从PDCP层向RLC传递一个私有信令，该私有信令中包含有用于指示第二数据包的指示信息和第二数据包对应的视频帧的帧类别信息，通过该私有信令，通信设备在RLC层可以确定第二数据包对应的视频帧的类型信息。

可选地，本申请实施例中通信设备将帧类型的信息从PDCP层传递到RLC层，还可以是通过PDCP协议头中的保留位进行帧类别信息的传输。具体的，通信设备在PDCP层对识别过帧类别信息的第二数据包进行加密和加PDCP协议头处理时，可以在PDCP协议头中的保留位字段中设置可以表示帧类别信息的取值。

例如，若第二数据包对应的视频帧为I帧，在为第二数据包加PDCP头生成PDCP数据包时，把该PDCP头中的前两位保留位字段取值设置为11，“11”代表数据包为重要数据，即I帧数据，则当通信设备在RLC层接收到该PDCP数据包，通过读取PDCP数据包的PDCP头的保留位字段为11，就可以确定第二数据包对应的视频帧为I帧。对于其他类型的视频帧，本申请实施例还提供一种视频帧类型和保留字段取值的对应关系，请参阅表5。通信设备可以在识别数据包对应的视频帧类型后，对应在数据包的PDCP头的保留位中标记相应取值。

表5视频帧类型与PDCP头的保留位字段取值的对应关系

视频帧类型	保留位字段取值
		重要数据	11
非重要数据	10
		保留	01
无关数据	00

需要说明的是，在实际应用过程中，还可以采用其他的取值和设置方式，本实施例对此不做限定；除此之外，本申请实施例也可以其他的方式将在数据链路PDCP层中解析出来的帧类型的信息传递至RLC层中，本申请实施例对此也不做具体的限定。

905、若该信息指示第二数据包对应的视频帧是I帧，则通信设备在RLC层记录第二数据包到达PDCP层的时刻，且缓存封装有第二数据包和PDCP协议头的PDCP数据包。

本申请实施例中，通信设备在RLC层会根据第二数据包对应的视频帧的帧类型对第二数据包进行处理。若该帧类型的信息指示第二数据包对应的视频帧是参考帧，通信设备会记录该第二数据包到达PDCP层的时间，为PDCP数据包封装RLC协议头之后形成RLC数据包缓存在缓存队列中，若该帧类型的信息指示第二数据包对应的视频帧是其他帧，则只需缓存下RLC数据包等待下一步的传输。

本申请实施例中，通信设备在RLC层可以是通过读取PDCP包中的PDCP协议头的保留位中的取值来判断第二数据对应的视频帧的类型。例如，若采用步骤905中的表5中的视频帧类型与PDCP头的保留位字段取值的对应关系，当通信设备读取到该PDCP数据包的PDCP协议头保留位中的取值为“11”，则可以确定该PDCP包为I帧的数据包，若该PDCP包的前一个数据包的保留位不为“11”，则证明第二数据包是第二视频帧组中的I帧数据包，记录下的该PDCP包到达PDCP层的时间即为距离当前时间最近到达的参考帧的数据包，根据该记录下的时间，便可以确定该PDCP数据包与对缓存队列中的数据包是否是同一个视频帧的数据包，进而进行弃包判断。

906、若RLC层的定时器超时，判断缓存队列中的第一视频帧组中第一视频帧的第一数据包是否超时，且第二视频帧组中I帧的第二数据包是否已经到达。

本申请实施例中，RLC层中的定时器设置有弃包时长，例如150ms，则每过150ms，定时器便会超时，从而触发会对缓存队列中待发送的第一数据包进行超时判断，若缓存的第一数据包超时，通信设备不会立即将该第一数据包丢弃，而是会根据PDCP层是否接收到第二视频帧组中I帧的第二数据包来确定是否丢弃超时的第一数据包。若通信设备判断下一个视频帧组中I帧的第二数据包还没到，则暂缓丢弃超时的第一数据包。

907、通信设备确认第一数据包超时，且第二视频帧组中的第二数据包已经到达，则丢弃超时的第一数据包。

本申请实施例中，在第一数据包已经超时的情况下，若通信设备已经确定下一个视频帧组中I帧的数据包已经到达PDCP层，则可以确定第一数据包满足丢弃条件，可以将第一数据包从缓存队列中删除。

本申请实施例通过在目标协议层的PDCP层接收并且识别数据包所对应的视频帧的类别，使得当RLC层的定时器判断数据包超时时，若下一组视频帧组的参考帧还未到达，暂缓丢弃当前的超时数据，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

上述图3、图4、图6至图9具体介绍了本申请实施例的数据处理方法，接下来将介绍本申请实施例中的数据处理方法应用于接收端的实施例，请参阅图10。

上述对本申请实施例中的数据处理方法进行了介绍，接下来将对本申请实施例中的数据处理的通信设备进行介绍。首先介绍本申请实施例中数据处理方法应用于发送端的通信设备，请参阅图10。

图10为本申请实施例提供的通信设备10的示意图，通信设备10包括：

确定模块1010，用于确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，所述丢弃条件为：所述第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且所述目标协议层已收到第二视频帧组中参考帧的数据包，所述第二视频帧组与所述第一视频帧组为不同的视频帧组；

处理模块1020，用于在所述确定模块1010确定所述第一数据包满足丢弃条件时，丢弃所述第一数据包；或者在所述确定模块1010确定所述第一数据包不满足丢弃条件时，保留所述第一数据包。本申请实施例中，通信设备通过在目标协议层识别数据包对应的视频帧的类别，使得当定时器判断超时时，若下一组视频帧组的参考帧还未到达时，暂缓丢弃当前的超时数据，从而降低超时弃包率，提升无线资源转化效率，提升用户体验。

可选地，作为一个实施例，通信设备10还包括：接收模块1030，用于接收第二数据包；所述确定模块1010，还用于确定所述接收模块1030接收的所述第二数据包为所述第二视频帧组中参考帧的数据包。

可选地，作为一个实施例，通信设备10还包括：获取模块1040，用于从所述缓存队列中获取所述第一数据包以响应所述目标协议层的下一协议层的调用。

可选地，作为一个实施例，通信设备10还包括：定时器模块1050，用于进行超时判断。

可选地，作为一个实施例，所述确定模块1010，用于确定所述接收模块1030接收的所述第二数据包的帧类型为参考帧，且所述第二数据包与前一到达所述目标协议层的数据包不是同一视频帧的数据包。

可选地，作为一个实施例，所述确定模块1010，用于确定所述接收模块1030接收的所述第二数据包的实时传输协议RTP的协议头中的时间戳和所述前一到达所述目标协议层的数据包的RTP协议头中的时间戳不同。

应理解，本申请实施例中的确定模块1010、处理模块1020、接收模块1030以及获取模块1040均可以由处理器或处理器相关电路组件实现。其实现的功能也可以参考前述各方法实施例中相应步骤的说明。

如图11所示，本申请实施例还提供一种通信设备11，该通信设备11包括处理器1110，存储器1120和收发器1130，其中，存储器1120存储指令或程序，处理器1110用于执行存储器1120中存储的指令或程序。当存储器1120中的指令或者程序被执行时，该处理器1110用于执行上述实施例中确定模块1010、处理模块1020、接收模块1030以及获取模块1040执行的操作。

应理解，根据本申请实施例的通信设备11可对应于本申请实施例的数据处理方法中的通信设备，并且通信设备11中的各个模块的操作和/或功能分别为了实现图3至图9中的各个方法的相应流程，为了简洁，在此不再赘述。

本申请实施例还提供一种通信设备，该通信设备可以是终端设备也可以是电路。

当该通信设备为终端设备时，图12示出了一种简化的终端设备的结构示意图。便于理解和图示方便，图12中，终端设备以手机作为例子。如图12所示，终端设备包括处理器、存储器、射频电路、天线以及输入输出装置。处理器主要用于对通信协议以及通信数据进行处理，以及对终端设备进行控制，执行软件程序，处理软件程序的数据等，用于执行上述实施例中解确定模块1010、处理模块1020、接收模块1030以及获取模块1040执行的操作。存储器主要用于存储软件程序和数据。射频电路主要用于基带信号与射频信号的转换以及对射频信号的处理。天线主要用于收发电磁波形式的射频信号。输入输出装置，主要用于接收用户输入的数据以及对用户输出数据。需要说明的是，有些种类的终端设备可以不具有输入输出装置。图12中仅示出了一个存储器和处理器。在实际的终端设备产品中，可以存在一个或多个处理器和一个或多个存储器。存储器也可以称为存储介质或者存储设备等。存储器可以是独立于处理器设置，也可以是与处理器集成在一起，本申请实施例对此不做限制。

当该通信设备为芯片时，该芯片包括收发单元和处理单元。其中，收发单元可以是输入输出电路、通信接口；处理单元为该芯片上集成的处理器或者微处理器或者集成电路。

图13示出本实施例的通信设备另一种形式。处理装置13中包括调制子系统、中央处理子系统、周边子系统等模块。本实施例中的通信设备可以作为其中的调制子系统。具体的，该调制子系统可以包括处理器1303，接口1304。其中处理器1303完成上述执行上述实施例中确定模块1010、处理模块1020、接收模块1030以及获取模块1040执行的操作。作为另一种变形，该调制子系统包括存储器1306、处理器1303及存储在存储器1306上并可在处理器上运行的程序，该处理器1303执行该程序时实现上述方法实施例中的数据处理方法。需要注意的是，所述存储器1306可以是非易失性的，也可以是易失性的，其位置可以位于调制子系统内部，也可以位于处理装置13中，只要该存储器1306可以连接到所述处理器1303即可。

作为本实施例的另一种形式，提供一种计算机可读存储介质，其上存储有指令，该指令被执行时执行上述方法实施例中的数据处理方法。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时可以实现上述方法实施例提供的数据处理方法中与通信设备相关的流程。

应理解，本申请实施例中提及的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现成可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

还应理解，本申请实施例中提及的存储器可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double DataRate SDRAM，DDR SDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synchlink DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DR RAM)。

需要说明的是，当处理器为通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件时，存储器(存储模块)集成在处理器中。

应注意，本文描述的存储器旨在包括但不限于这些和任意其它适合类型的存储器。

应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上对本发明实施例所提供的数据处理方法和通信设备进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种数据处理方法，其特征在于，包括：

确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，所述丢弃条件为：所述第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且所述目标协议层已收到第二视频帧组中参考帧的数据包，所述第二视频帧组与所述第一视频帧组为不同的视频帧组；

若确定满足丢弃条件，则丢弃所述第一数据包；或者

若确定不满足丢弃条件，则保留所述第一数据包。

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

接收第二数据包；

确定所述第二数据包为所述第二视频帧组中参考帧的数据包。

3.根据权利要求1或2所述的方法，其特征在于，所述确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件之前还包括：

从所述缓存队列中获取所述第一数据包以响应所述目标协议层的下一协议层的调用。

4.根据权利要求1或2所述的方法，其特征在于，所述确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件之前还包括：

数据队列的处理定时器超时。

5.根据权利要求2所述的方法，其特征在于，所述确定所述第二数据包为所述第二视频帧组中参考帧的数据包，包括：

确定所述第二数据包的对应的视频帧的帧类型为参考帧，且所述第二数据包与前一到达所述目标协议层的数据包不是同一视频帧的数据包。

6.根据权利要求5所述的方法，其特征在于，所述确定所述第二数据包与前一到达所述目标协议层的数据包不是同一视频帧的数据包，包括：

确定所述第二数据包的实时传输协议RTP的协议头中的时间戳和所述前一到达所述目标协议层的数据包的RTP协议头中的时间戳不同。

7.根据权利要求1-6中任一所述的方法，其特征在于，所述目标协议层包括第一子层和第二子层，

所述第一子层用于从所述目标协议层的上一协议层接收数据包，并对所述接收到的数据包进行解析；

所述第二子层用于响应与所述目标协议层的下一协议层对数据包的调用，并确定所述第一视频帧组中所述第一视频帧的所述第一数据包是否满足丢弃条件。

8.根据权利要求7所述的方法，其特征在于，所述第一子层还用于将解析得到数据包的帧类型传递至所述第二子层。

9.根据权利要求7-8中任一所述的方法，其特征在于，所述第一子层为分组数据汇聚协议PDCP层，所述第二子层为无线链路控制层协议RLC层。

10.根据权利要求1-6中任一所述的方法，其特征在于，所述目标协议层为无线局域网中的多路访问控制MAC层。

11.一种数据处理的装置，其特征在于，所述装置包括：

确定模块，用于确定第一视频帧组中第一视频帧的第一数据包是否满足丢弃条件，所述丢弃条件为：所述第一数据包在目标协议层的缓存队列中的计时时长大于丢弃时长，且所述目标协议层已收到第二视频帧组中参考帧的数据包，所述第二视频帧组与所述第一视频帧组为不同的视频帧组；

处理模块，用于在所述确定模块确定所述第一数据包满足丢弃条件时，丢弃所述第一数据包；或者在所述确定模块确定所述第一数据包不满足丢弃条件时，保留所述第一数据包。

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

接收模块，用于接收第二数据包；

所述确定模块，还用于确定所述接收模块接收的所述第二数据包为所述第二视频帧组中参考帧的数据包。

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

获取模块，用于从所述缓存队列中获取所述第一数据包以响应所述目标协议层的下一协议层的调用。

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

定时器模块，用于进行超时判断。

15.根据权利要求12所述的装置，其特征在于，

所述确定模块，用于确定所述接收模块接收的所述第二数据包的帧类型为参考帧，且所述第二数据包与前一到达所述目标协议层的数据包不是同一视频帧的数据包。

16.根据权利要求15所述的装置，其特征在于，

所述确定模块，用于确定所述接收模块接收的所述第二数据包的实时传输协议RTP的协议头中的时间戳和所述前一到达所述目标协议层的数据包的RTP协议头中的时间戳不同。

17.一种通信设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的程序，其特征在于，所述处理器执行所述程序时实现权利要求1至10中任一项所述的方法。

18.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1至10中任一项所述的方法。