技术领域
[0001] 本
申请涉及视频数据处理技术领域，更具体地说，涉及一种视频数据处理方法及装置。
背景技术
[0002] 近年来，随着智能手机和移动互联网的发展，VoIP(Video/voice over Internet Protocol，一种基于IP网络的音、视频数据实时传输应用)视频通话应用给人们提供了全新的沟通体验。而由于
信号衰落、突发丢包等原因，会导致视频卡顿、抖动等现象，影响视频
质量。
[0003] 传统的视频压缩编码标准一般采用IPPP编码架构。该架构下，视频数据的
帧分为两种，一种是I帧(I frame，又称为帧内编码帧)；另一种是P帧(P frame，又称为帧间编码帧或者前向预测编码帧)。参见图1，图1为IPPP编码结构示意图。IPPP编码架构为链式参考结构，视频数据的各帧能否成功解码不仅取决于该帧自身数据的完整性，还取决于参考帧是否已解出。在IPPP编码架构中，I帧不参考任何帧能够独立解码，P帧需要结合其参考帧才能成功解码。IPPP编码架构中，GOP(Group of Picture，
视频编码的最小重复单元)以I帧为分隔，GOP中任意一帧解码失败会导致GOP中该帧后面的所有帧均无法成功解码，造成视频卡顿现象。
[0004] 为此
现有技术提出了一种HPP(Hierarchical P-frame Prediction,分层预测编码结构)编码方式，参考图2所示的HPP编码结构，处于不同TL(Temporal Layer，时间层)的帧的重要性不同，能在一定程度上减少相邻帧间的参考耦合关系。如图2所示，HPP采用高TL的帧参考低TL的帧，相邻帧的TL不同，所以只要不是TL级别最低的帧丢了，后面的帧都有可能成功解码。举例如，P5帧丢了，不会影响后面的P6、P7、P8帧的成功解码。
[0005] 但是，HPP编码方式虽然在一定程度上减少了相邻帧间的参考耦合关系，但是在出现丢包时，解码端仍会出现部分帧无法成功解码，导致视频卡顿的问题。
发明内容
[0006] 有鉴于此，本申请提供了一种视频数据处理方法及装置，用于解决现有HPP编码方式在出现数据传输丢包时，解码端对部分帧无法解码，导致视频卡顿的问题。
[0007] 为了实现上述目的，现提出的方案如下：
[0008] 一种视频数据处理方法，应用于编码端，该方法包括：
[0009] 获取原始视频数据；
[0010] 按照分层预测编码结构HPP，对所述原始视频数据进行编码，得到HPP码流；
[0011] 按照前向纠错编码FEC，对所述HPP码流进行冗余编码，其中，所述HPP码流中各帧的冗余包数量按照各帧在HPP中所处时间层由低至高的顺序递减；
[0012] 将冗余编码后的HPP码流中的各帧，顺序发送给解码端。
[0013] 一种视频数据处理方法，应用于解码端，该方法包括：
[0014] 接收编码端发送的当前帧，所述当前帧为编码端按照分层预测编码结构HPP进行编码后的HPP码流中的帧；
[0015] 在确定所述当前帧为帧间编码帧P帧时，判断当前帧的参考帧是否完整；
[0016] 若所述当前帧的参考帧不完整，将所述当前帧丢弃，以放弃对当前帧进行解码；
[0017] 根据所述当前帧在分层预测编码结构HPP中所处
位置，确定以所述当前帧为参考帧的目标帧；
[0018] 将所述目标帧的参考状态标记为，参考帧不完整。
[0019] 一种视频数据处理装置，应用于编码端，该装置包括：
[0020] 原始视频数据获取单元，用于获取原始视频数据；
[0021] HPP编码单元，用于按照分层预测编码结构HPP，对所述原始视频数据进行编码，得到HPP码流；
[0022] 冗余编码单元，用于按照前向纠错编码FEC，对所述HPP码流进行冗余编码，其中，所述HPP码流中各帧的冗余包数量按照各帧在HPP中所处时间层由低至高的顺序递减；
[0023] 帧发送单元，用于将冗余编码后的HPP码流中的各帧，顺序发送给解码端。
[0024] 一种视频数据处理装置，应用于解码端，该装置包括：
[0025] 当前帧接收单元，用于接收编码端发送的当前帧，所述当前帧为编码端按照分层预测编码结构HPP进行编码后的HPP码流中的帧；
[0026] 参考帧判断单元，用于在确定所述当前帧为帧间编码帧P帧时，判断当前帧的参考帧是否完整；
[0027] 第一帧丢弃单元，用于在所述参考帧判断单元判断当前帧的参考帧不完整时，将所述当前帧丢弃，以放弃对当前帧进行解码；
[0028] 目标帧确定单元，用于根据所述当前帧在分层预测编码结构HPP中所处位置，确定以所述当前帧为参考帧的目标帧；
[0029] 第一参考状态标记单元，用于将所述目标帧的参考状态标记为，参考帧不完整。
[0030] 本申请
实施例提供的视频数据处理方法，编码端按照分层预测编码结构HPP，对获取的原始视频数据进行编码，得到HPP码流，按照前向纠错编码FEC，对HPP码流进行冗余编码，其中，HPP码流中各帧的冗余包数量按照各帧在HPP中所处时间层由低至高的顺序递减，最后将冗余编码后的HPP码流中的各帧，顺序发送给解码端。由此可见，本申请将HPP编码结构与FEC冗余编码相结合，对按照HPP编码结构编码后的HPP码流添加冗余包，并且在添加冗余包时按照HPP中所处时间层越低的帧，其添加的冗余包数量越多，对重要度高的处于低时间层的帧重点进行保护。通过这种方式，即便数据传输过程出现部分丢包，解码端也可以通过冗余包进行丢包恢复，大大提高了解码成功率，减少视频卡顿时间。
附图说明
[0031] 为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
[0032] 图1为IPPP编码结构示意图；
[0033] 图2为HPP编码结构示意图；
[0034] 图3为本申请实施例从编码端公开的一种视频数据处理方法
流程图；
[0035] 图4为本申请实施例从编码端公开的另一种视频数据处理方法流程图；
[0036] 图5为本申请实施例从编码端公开的又一种视频数据处理方法流程图；
[0037] 图6为本申请实施例从解码端公开的一种视频数据处理方法流程图；
[0038] 图7为本申请实施例从解码端公开的另一种视频数据处理方法流程图；
[0039] 图8为本申请实施例从解码端公开的又一种视频数据处理方法流程图；
[0040] 图9为本申请实施例从解码端公开的又一种视频数据处理方法流程图；
[0041] 图10为本申请实施例从解码端公开的又一种视频数据处理方法流程图；
[0042] 图11为本申请实施例从编码端公开的一种视频数据处理装置结构示意图；
[0043] 图12为本申请实施例从解码端公开的一种视频数据处理装置结构示意图；
[0044] 图13为本申请实施例提供的一种终端
硬件结构示意图。
具体实施方式
[0045] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
[0046] 本申请的视频数据处理方案中，解码端接收视频编码端发送的视频包，进而进行视频数据的处理。其中，视频编码端采用HPP编码结构。视频编码端采集原始视频裸流，以
图像序列的形式进行信源压缩编码，最终生成HPP码流。视频编码端在进行HPP编码时，可以根据编码端的硬件性能及使用场景配置HPP的最大层数M+1，最大参考距离为L＝2^M。如图2中，M＝2，即3层HPP参考结构，处于高时间层TL的帧参考低时间层TL的帧。L＝4，最长参考距离对应P4参考P0、P8参考P4。
[0047] 进一步地，视频编码端在信源HPP视频编码的
基础上，为了应对丢包，通过前向纠错编码FEC对HPP码流进行冗余编码，将冗余编码后的HPP码流中的各帧，顺序发送给解码端。
[0048] 在HPP码流中增加冗余包的方法可以是这样的，首先，对HPP码流的每个帧进行分包，每个帧的数据被分为p个视频包，然后，利用FEC(ForwardError Correction，前向纠错)编码，为该帧增加q个冗余包，最后，将该帧的视频包和冗余包一起向解码端传输；该种方法可以抵抗q个视频包的丢包，当有丢包时，就可以利用冗包将丢失的视频包恢复出来。其中，q和p均为正整数。需要说明的是，增加的冗余包的个数的多少，决定了抗丢包能
力的强弱。对于重要的，需要多保护的帧，可以增加较多的冗余包。
[0049] 基于HPP编码结构，高时间层TL的帧参考低TL的帧，因此时间层越低的帧的重要级别越高，本申请可以设置低时间层帧的冗余包多余高时间层帧的冗余包。举例如，TL0层的帧设置100％冗余包，即视频包和冗余包的个数相等，TL1层的帧设置50％冗余包，……，最高TL层的帧不设置冗余包。
[0050] 接下来，本申请以编码端
角度对视频数据处理过程进行介绍，参见图3，图3为本申请实施例从编码端公开的一种视频数据处理方法流程图。
[0051] 如图3所示，该方法包括：
[0052] 步骤S100、获取原始视频数据；
[0053] 步骤S110、按照分层预测编码结构HPP，对所述原始视频数据进行编码，得到HPP码流；
[0054] 具体地，可以根据编码端的硬件性能及使用场景配置HPP的最大时间层数M+1，最大参考距离为L＝2^M。
[0055] 步骤S120、按照前向纠错编码FEC，对所述HPP码流进行冗余编码；
[0056] 具体地，在对HPP码流进行冗余编码时，HPP码流中各帧的冗余包的数量可以按照，各帧在HPP中所处时间层由低至高的顺序递减。
[0057] 由于HPP中低时间层的帧的重要度高于高时间层的帧，因此低时间层的帧的冗余包的数量多于高时间层的帧的冗余包的数量。以便利用有限的冗余包资源保护重要度高的帧，提升冗余利用率。
[0058] 步骤S130、将冗余编码后的HPP码流中的各帧，顺序发送给解码端。
[0059] 编码端按照HPP码流中各帧的时间顺序，依次向解码端发送各帧。
[0060] 本申请实施例提供的视频数据处理方法，编码端按照分层预测编码结构HPP，对获取的原始视频数据进行编码，得到HPP码流，按照前向纠错编码FEC，对HPP码流进行冗余编码，其中，HPP码流中各帧的冗余包数量按照各帧在HPP中所处时间层由低至高的顺序递减，最后将冗余编码后的HPP码流中的各帧，顺序发送给解码端。由此可见，本申请将HPP编码结构与FEC冗余编码相结合，对按照HPP编码结构编码后的HPP码流添加冗余包，并且在添加冗余包时按照HPP中所处时间层越低的帧，其添加的冗余包数量越多，对重要度高的处于低时间层的帧重点进行保护。通过这种方式，即便数据传输过程出现部分丢包，解码端也可以通过冗余包进行丢包恢复，大大提高了解码成功率，减少视频卡顿时间。
[0061] 参见图4，图4为本申请实施例从编码端公开的另一种视频数据处理方法流程图。
[0062] 如图4所示，该方法包括：
[0063] 步骤S200、获取原始视频数据；
[0064] 步骤S210、按照分层预测编码结构HPP，对所述原始视频数据进行编码，得到HPP码流；
[0065] 步骤S220、按照前向纠错编码FEC，对所述HPP码流进行冗余编码；
[0066] 具体地，在对HPP码流进行冗余编码时，HPP码流中各帧的冗余包的数量可以按照，各帧在HPP中所处时间层由低至高的顺序递减。
[0067] 步骤S230、将冗余编码后的HPP码流中的各帧，顺序发送给解码端；
[0068] 步骤S240、在收到所述解码端发送的冗余等级调整
请求时，按照设定调整策略，动态调整所述HPP码流中后续发送帧的冗余包数量。
[0069] 其中，所述冗余等级调整请求为所述解码端在对接收的当前帧的视频包进行完整性检查，并根据检查结果确定当前帧不能解码时，由解码端生成的请求。
[0070] 本实施例中，如果网络状态差，导致解码端接收的各帧的数据包丢失严重，解码端可以向编码端发送冗余等级调整请求，由编码端提高所述HPP码流中后续发送的各帧的冗余包数量。
[0071] 其中可选的，上述按照设定调整策略，动态调整所述HPP码流中后续发送帧的冗余包数量的过程，具体可以包括：
[0072] 对所述HPP码流中处于设定时间层的各帧调整冗余包数量；
[0073] 或，
[0074] 按照各时间层对应的冗余包调整比例，对所述HPP码流中处于各时间层的各帧调整冗余包数量。
[0075] 具体地，编码端可以仅对设定时间层的帧提高冗余包数量，如对时间层小于某个
阈值的时间层的帧提高冗余包数量。除此之外，还可以按照相同或不同的调整比例，对各时间层的帧提高冗余包数量。
[0076] 举例如，初始时视频编码端对TL0层的帧设置50％冗余包，TL1层的帧设置20％冗余包，TL3层的帧设置5％冗余包。
[0077] 某一时刻视频编码端收到冗余等级调整请求，进而提高冗余包设置数量，将TL0层的帧设置70％冗余包，TL1层的帧设置40％冗余包，TL3层的帧设置20％冗余包。
[0078] 参见图5，图5为本申请实施例从编码端公开的又一种视频数据处理方法流程图。
[0079] 如图5所示，该方法包括：
[0080] 步骤S300、获取原始视频数据；
[0081] 步骤S310、按照分层预测编码结构HPP，对所述原始视频数据进行编码，得到HPP码流；
[0082] 步骤S320、按照前向纠错编码FEC，对所述HPP码流进行冗余编码；
[0083] 具体地，在对HPP码流进行冗余编码时，HPP码流中各帧的冗余包的数量可以按照，各帧在HPP中所处时间层由低至高的顺序递减。
[0084] 步骤S330、将冗余编码后的HPP码流中的各帧，顺序发送给解码端；
[0085] 步骤S340、在收到所述解码端发送的I帧请求时，在所述HPP码流中未发送的帧中查找最近一个帧内编码帧I帧；
[0086] 具体地，编码端如果确定当前帧处于最低时间层且不完整，则意味着参考结构产生断裂，当前I帧间隔里后面的帧由于失去参考帧无法解码，这种极端情况下视频卡顿已经不可避免，为了缩短卡顿时间，可以直接向视频编码端发送I帧请求，以请求所述视频编码端立即发送下一I帧。
[0087] 编码端在收到请求时，在HPP码流中未发送的帧中查找最近一个I帧。
[0088] 步骤S350、向所述解码端发送查找到的最近一个I帧，并顺序发送该I帧之后的帧。
[0089] 解码端在查找到最近的一个I帧之后，放弃发送该最近一个I帧之前的各帧，直接跳转到发送最近的一个I帧，后续顺序发送该最近的一个I帧之后的各帧。
[0090] 本实施例中，编码端在收到I帧请求时，立即在HPP码流中未发送的帧中查找最近一个I帧，并跳转发送该最近一个I帧及后续各帧，最大可能缩短解码端视频卡顿时间。
[0091] 接下来，本申请以接收端角度对视频数据处理过程进行介绍。参见图6，图6为本申请实施例从接收端角度公开的一种视频数据处理方法流程图。
[0092] 如图6所示，该方法包括：
[0093] 步骤S400、接收编码端发送的当前帧；
[0094] 其中，所述当前帧为编码端按照分层预测编码结构HPP进行编码后的HPP码流中的帧。
[0095] 可以理解的是，一帧包含若干个视频包，每个视频包的包头信息中都可以记录该视频包所属的帧，以及属于该帧总n个视频包的第i个。本步骤中确定接收到当前帧可以是，确定收到当前帧的第一个视频包，或者是确定收到当前帧的最后一个视频包。
[0096] 具体地，确定收到当前帧的最后一个视频包的具体实施方式可以是：
[0097] 根据已收到当前帧的视频包中包头记录的当前帧的总视频包的个数n，在收到第n个当前帧的视频包时确定该视频包为当前帧的最后一个视频包。或者是，在收到下一帧的视频包时，将前一个收到的视频包确定为当前帧的最后一个视频包。
[0098] 步骤S410、在确定所述当前帧为帧间编码帧P帧时，判断当前帧的参考帧是否完整；若否，执行步骤S420-S440；
[0099] 具体地，若当前帧的参考帧无法完整组包，或无法解码，或者其参考帧不完整，则均意味着当前帧也无法成功解码。
[0100] 步骤S420、将所述当前帧丢弃，以放弃对当前帧进行解码；
[0101] 步骤S430、根据所述当前帧在分层预测编码结构HPP中所处位置，确定以所述当前帧为参考帧的目标帧；
[0102] 具体地，根据HPP编码结构以及当前帧在HPP中所处位置，可以确定以当前帧为参考帧的目标帧。参见图2所示，假设当前帧为P2，则由于P3参考P2，因此可以设置P2为目标帧。再比如，当前帧为P4，则由于P5、P6、P8参考P4，因此可以设置P5、P6、P8为目标帧。
[0103] 步骤S440、将所述目标帧的参考状态标记为，参考帧不完整。
[0104] 具体地，由于确定了当前帧的参考帧不完整，也就意味着当前帧无法成功进行解码。因此，以当前帧为参考的目标帧也就无法成功解码，设置目标帧的参考状态为，参考帧不完整。
[0105] 可选的，本申请可以设置不同标识代表不同的参考状态，如“1”表示参考帧不完整，“0”表示参考帧完整。当然，还可以用其它标识来表示不同的参考状态。
[0106] 可选的，步骤S420和S430的执行顺序可以相互颠倒或并列执行，图6仅仅示例了一种可选方式。
[0107] 本实施例中，解码端对于接收当的当前帧，若确定其为P帧，则根据HPP编码结构可知，P帧需要参考之前的帧，因此本申请可以判断当前帧的参考帧是否完整，在其参考帧不完整时，意味着当前帧无法成功解码，因此直接丢弃当前帧，不对其进行解码处理，节省了解码时间，减少了视频卡顿时间。进一步，本申请在确定当前帧的参考帧不完整时，进一步将以当前帧我参考帧的目标帧的参考状态标记为，参考帧不完整，后续在接收到目标帧时，可以直接通过目标帧的参考状态来确定其参考帧是否完整，更加方便。
[0108] 可选的，上述判断当前帧的参考帧是否完整的过程，可以包括：
[0109] 1、获取所述当前帧的参考状态，所述参考状态用于表示当前帧的参考帧是否完整；
[0110] 其中，当前帧的参考状态为在先对其参考帧进行检查时所确定，若参考帧成功解码，则可以设置当前帧的参考状态为，参考帧完整，否则，设置参考状态为，参考帧不完整。
[0111] 2、根据所述当前帧的参考状态确定所述当前帧的参考帧是否完整。
[0112] 参见图7，图7为本申请实施例从解码端公开的另一种视频数据处理方法流程图。
[0113] 如图7所示，该方法包括：
[0114] 步骤S500、在确定收到当前帧的最后一个视频包，且所述当前帧为帧间编码帧P帧时，获取所述当前帧的参考状态；
[0115] 其中，所述参考状态用于表示当前帧的参考帧是否完整。
[0116] 步骤S510、判断所述当前帧的参考状态是否表示参考帧不完整；若是，执行步骤S520-S540，若否，执行步骤S550-S570；
[0117] 步骤S520、将所述当前帧丢弃，以放弃对当前帧进行解码；
[0118] 步骤S530、根据所述当前帧在分层预测编码结构HPP中所处位置，确定以所述当前帧为参考帧的目标帧；
[0119] 步骤S540、将所述目标帧的参考状态标记为，参考帧不完整；
[0120] 步骤S550、判断当前帧是否可解码，若否，执行步骤S520，若是，执行步骤S560；
[0121] 具体地，在确定当前帧的参考状态表示参考帧完整时，可以对已缓存的当前帧的视频包的完整性进行检查，并根据检查结果确定所述当前帧是否可解码。
[0122] 若判断当前帧不可解码，则可以返
回执行步骤S520-S540的操作。
[0123] 步骤S560、对所述当前帧进行解码处理，并判断是否成功解码；若是，执行步骤S570，若否，执行步骤S520；
[0124] 步骤S570、对解码处理后的当前帧进行显示。
[0125] 具体地，在判断当前帧可解码时，对当前帧进行解码处理。并根据解码结果判断是否成功解码，如果成功解码，则可以对解码处理后的当前帧进行显示，如果未成功解码，则可以返回执行步骤S520-S540的操作。
[0126] 相比于上一实施例，本实施例中进一步增加了在判断当前帧的参考状态表示参考帧完整时的处理流程。本实施例中在确定当前帧的参考状态表示参考帧完整时，进一步判断当前帧是否可解码，只有判断为可解码时才会对当前帧进行解码处理，进一步减少了对不可解码的帧的解码处理，减少了视频卡顿时间。
[0127] 可选的，上述步骤S550中，对已缓存的当前帧的视频包的完整性进行检查，并根据检查结果确定所述当前帧是否可解码的过程，可以包括：
[0128] 1)根据所述当前帧的视频包的包头信息，判断已缓存的当前帧的视频包能否完整组帧，以及在确定不能完整组帧时丢包能否恢复；
[0129] 2)若判断能够完整组帧，或判断不能完整组帧时丢包能够恢复，则确定所述当前帧可解码。
[0130] 可以理解的是，若判断不能够完整组帧，且丢包不能够恢复时，则可以确定当前帧不可解码。
[0131] 具体地，前文已经介绍，一帧包括若干视频包，每个视频包的包头信息中可以记录该视频包所属的帧，以及属于该帧总n个视频包的第i个。进一步，包头信息中还可以记录该帧有几个冗余包。基于此，根据当前帧收包结束时已经缓存的当前帧的视频包，以及包头信息，可以确定缓存的视频包能否完整组帧。如，包头信息记录当前帧共有n个视频包，而缓存的视频包如果小于n个，则表示当前帧的数据包存在丢包，确定无法完整组帧。
[0132] 在确定无法完整组帧时，可以进一步判断丢包能否恢复。具体地，如果确定当前帧丢包个数小于等于包头信息中记录的该帧的冗余包的个数，则可以确定丢包能够恢复，否则，确定丢包无法恢复。
[0133] 进一步地，对比图7和图8可知，在图7对应实施例的基础上，若确定当前帧不可解码时，可以进一步增加步骤S580、向视频编码端发送冗余等级调整请求。通过发送冗余等级调整请求，以请求所述视频编码端提高发送的冗余包的数量。
[0134] 具体地，如果确定当前帧不可解码，则表示丢包严重，超出现有冗余包的恢复能力，因此可以向视频编码端发送冗余等级调整请求，以请求提高发送的冗余包的数量。
[0135] 编码端在收到冗余等级调整请求后的调整策略可以参照前文相关介绍，此处不再赘述。
[0136] 参见图9，图9为本申请实施例从解码端公开的又一种视频数据处理方法流程图。
[0137] 如图9所示，该方法包括：
[0138] 步骤S600、在确定收到当前帧的最后一个视频包，且所述当前帧为处于HPP中最低时间层的P帧时，获取所述当前帧的参考状态；
[0139] 其中，所述参考状态用于表示当前帧的参考帧是否完整。
[0140] 本步骤中，当前帧为P帧且处于HPP编码结构的最低时间层。参考图2所示，其中P4、P8均为最低时间层的P帧。
[0141] 步骤S610、判断所述当前帧的参考状态是否表示参考帧不完整；若是，执行步骤S620-S650，若否，执行步骤S650-S680；
[0142] 步骤S620、将所述当前帧丢弃，以放弃对当前帧进行解码；
[0143] 步骤S630、根据所述当前帧在分层预测编码结构HPP中所处位置，确定以所述当前帧为参考帧的目标帧；
[0144] 步骤S640、将所述目标帧的参考状态标记为，参考帧不完整；
[0145] 步骤S650、向视频编码端发送I帧请求，以请求所述视频编码端立即发送下一I帧；
[0146] 具体地，由于HPP中最低时间层TL0的帧不可解码，导致参考结构断裂，当前I帧间隔里后面的帧由于失去参考帧无法解码，这种极端情况下视频卡顿已经不可避免，为了缩短卡顿时间，可以直接向视频编码端发送I帧请求，以请求所述视频编码端立即发送下一I帧。
[0147] 通过该处理手段，能够最大可能的减少视频卡顿的时间。
[0148] 步骤S660、判断当前帧是否可解码，若否，执行步骤S620，若是，执行步骤S670；
[0149] 具体地，在确定当前帧的参考状态表示参考帧完整时，可以对已缓存的当前帧的视频包的完整性进行检查，并根据检查结果确定所述当前帧是否可解码。
[0150] 若判断当前帧不可解码，则可以返回执行步骤S620-S650的操作。
[0151] 步骤S670、对所述当前帧进行解码处理，并判断是否成功解码；若是，执行步骤S680，若否，执行步骤S620；
[0152] 具体地，若判断未成功解码，则可以执行步骤S620-S640的操作。
[0153] 步骤S680、对解码处理后的当前帧进行显示。
[0154] 本实施例中介绍了在当前帧为处于HPP中最低时间层的P帧时的视频数据处理流程。相比于上述各实施例，在确定所述当前帧的参考状态表示所述参考帧不完整，或，确定所述当前帧不可解码，或，确定所述当前帧解码不成功时，增加了向视频编码端发送I帧请求，以请求所述视频编码端立即发送下一I帧的操作，通过这种处理方式，最大限度的减少了视频卡顿的时间。
[0155] 参见图10，图10为本申请实施例从解码端公开的又一种视频数据处理方法流程图。
[0156] 如图10所示，该方法包括：
[0157] 步骤S700、在确定收到当前帧的最后一个视频包时，判断当前帧是否为I帧；若是，执行步骤S710-S760，若否，执行步骤S770-S800；
[0158] 具体地，如果当前帧为I帧，则当前帧无参考帧，可以执行步骤S710，判断其是否可解码。如果当前帧不是I帧，则当前帧为P帧，可以执行步骤S770，获取其参考状态。
[0159] 步骤S710、判断当前帧是否可解码，若否，执行步骤S720-S740，若是，执行步骤S750；
[0160] 具体地，对已缓存的当前帧的视频包的完整性进行检查，并根据检查结果确定所述当前帧是否可解码。
[0161] 详细检查过程可以参照上文相关介绍，此处不再赘述。
[0162] 步骤S720、将所述当前帧与下一I帧间的各帧的参考状态标记为，参考帧不完整；
[0163] 具体地，如果判断当前I帧不可解码，则意味着参考结构断裂，当前I帧与下一I帧间的各P帧均无法成功解码，因此将当前帧与下一I帧间的各帧的参考状态标记为，参考帧不完整。
[0164] 步骤S730、将所述当前帧丢弃，以放弃对当前帧进行解码；
[0165] 步骤S740、向视频编码端发送I帧请求，以请求所述视频编码端立即发送下一I帧；
[0166] 具体地，由于I帧不可解码，导致参考结构断裂，当前I帧间隔里后面的帧由于失去参考帧无法解码，这种极端情况下视频卡顿已经不可避免，为了缩短卡顿时间，可以直接向视频编码端发送I帧请求，以请求所述视频编码端立即发送下一I帧。
[0167] 通过该处理手段，能够最大可能的减少视频卡顿的时间。
[0168] 步骤S750、对所述当前帧进行解码处理，判断解码是否成功，若成功，执行步骤S760，若不成功，执行步骤S720-S740；
[0169] 具体地，在步骤S710判断可解码的情况下，对当前帧进行解码处理，并根据解码结果判断解码是否成功。
[0170] 步骤S760、对解码处理后的当前帧进行显示；
[0171] 步骤S770、获取所述当前帧的参考状态，并判断参考状态是否表示参考帧不完整，若是，执行步骤S780；
[0172] 具体地，在步骤S700判断当前帧不是I帧时，代表当前帧存在参考帧。本步骤中获取当前帧的参考状态。其中，所述参考状态用于表示当前帧的参考帧是否完整。
[0173] 步骤S780、将所述当前帧丢弃，以放弃对当前帧进行解码；
[0174] 步骤S790、根据所述当前帧在分层预测编码结构HPP中所处位置，确定以所述当前帧为参考帧的目标帧；
[0175] 步骤S800、将所述目标帧的参考状态标记为，参考帧不完整。
[0176] 相比于上述各实施例，本实施例中增加了对当前帧为I帧或P帧的判断，以及在判断当前帧为I帧时的执行流程，也即，直接判断其是否可解码，以及解码是否成功，在判断不可解码或解码不成功时，将当前帧与下一I帧间各帧的参考状态标记为，参考帧不完整，将当前帧丢弃，并向视频编码端发送I帧请求，以请求立即发送下一I帧，最大可能的减少视频卡顿的时间。
[0177] 下面对本申请实施例提供的视频数据处理装置进行描述，下文描述的视频数据处理装置与上文描述的视频数据处理方法可相互对应参照。
[0178] 参见图11，图11为本申请实施例从编码端角度公开的一种视频数据处理装置结构示意图。
[0179] 如图11所示，该装置包括：
[0180] 原始视频数据获取单元11，用于获取原始视频数据；
[0181] HPP编码单元12，用于按照分层预测编码结构HPP，对所述原始视频数据进行编码，得到HPP码流；
[0182] 冗余编码单元13，用于按照前向纠错编码FEC，对所述HPP码流进行冗余编码，其中，所述HPP码流中各帧的冗余包数量按照各帧在HPP中所处时间层由低至高的顺序递减；
[0183] 帧发送单元14，用于将冗余编码后的HPP码流中的各帧，顺序发送给解码端。
[0184] 本申请实施例提供的视频数据处理装置，编码端按照分层预测编码结构HPP，对获取的原始视频数据进行编码，得到HPP码流，按照前向纠错编码FEC，对HPP码流进行冗余编码，其中，HPP码流中各帧的冗余包数量按照各帧在HPP中所处时间层由低至高的顺序递减，最后将冗余编码后的HPP码流中的各帧，顺序发送给解码端。由此可见，本申请将HPP编码结构与FEC冗余编码相结合，对按照HPP编码结构编码后的HPP码流添加冗余包，并且在添加冗余包时按照HPP中所处时间层越低的帧，其添加的冗余包数量越多，对重要度高的处于低时间层的帧重点进行保护。通过这种方式，即便数据传输过程出现部分丢包，解码端也可以通过冗余包进行丢包恢复，大大提高了解码成功率，减少视频卡顿时间。
[0185] 可选的，本申请的装置还可以包括：
[0186] 冗余调整单元，用于在收到所述解码端发送的冗余等级调整请求时，按照设定调整策略，动态调整所述HPP码流中后续发送帧的冗余包数量；
[0187] 其中，所述冗余等级调整请求为所述解码端在对接收的当前帧的视频包进行完整性检查，并根据检查结果确定当前帧不能解码时，由解码端生成的请求。
[0188] 可选的，所述冗余调整单元可以包括：
[0189] 冗余调整子单元，用于对所述HPP码流中处于设定时间层的各帧调整冗余包数量；或，按照各时间层对应的冗余包调整比例，对所述HPP码流中处于各时间层的各帧调整冗余包数量。
[0190] 可选的，本申请的装置还可以包括：
[0191] I帧查找单元，用于在收到所述解码端发送的I帧请求时，在所述HPP码流中未发送的帧中查找最近一个帧内编码帧I帧；
[0192] I帧发送单元，用于向所述解码端发送查找到的最近一个I帧，并顺序发送该I帧之后的帧。
[0193] 参见图12，图12为本申请实施例从解码端角度公开的一种视频数据处理装置结构示意图。
[0194] 如图12所示，该装置包括：
[0195] 当前帧接收单元21，用于接收编码端发送的当前帧，所述当前帧为编码端按照分层预测编码结构HPP进行编码后的HPP码流中的帧；
[0196] 参考帧判断单元22，用于在确定所述当前帧为帧间编码帧P帧时，判断当前帧的参考帧是否完整；
[0197] 第一帧丢弃单元23，用于在所述参考帧判断单元判断当前帧的参考帧不完整时，将所述当前帧丢弃，以放弃对当前帧进行解码；
[0198] 目标帧确定单元24，用于根据所述当前帧在分层预测编码结构HPP中所处位置，确定以所述当前帧为参考帧的目标帧；
[0199] 第一参考状态标记单元25，用于将所述目标帧的参考状态标记为，参考帧不完整。
[0200] 本申请实施例提供的视频数据处理装置，编码端按照分层预测编码结构HPP，对获取的原始视频数据进行编码，得到HPP码流，按照前向纠错编码FEC，对HPP码流进行冗余编码，其中，HPP码流中各帧的冗余包数量按照各帧在HPP中所处时间层由低至高的顺序递减，最后将冗余编码后的HPP码流中的各帧，顺序发送给解码端。由此可见，本申请将HPP编码结构与FEC冗余编码相结合，对按照HPP编码结构编码后的HPP码流添加冗余包，并且在添加冗余包时按照HPP中所处时间层越低的帧，其添加的冗余包数量越多，对重要度高的处于低时间层的帧重点进行保护。通过这种方式，即便数据传输过程出现部分丢包，解码端也可以通过冗余包进行丢包恢复，大大提高了解码成功率，减少视频卡顿时间。
[0201] 可选的，所述参考帧判断单元可以包括：
[0202] 参考状态获取单元，用于获取所述当前帧的参考状态，所述参考状态用于表示当前帧的参考帧是否完整；
[0203] 参考状态判断单元，用于根据所述当前帧的参考状态确定所述当前帧的参考帧是否完整。
[0204] 可选的，所述当前帧接收单元具体可以用于，确定接收到当前帧的最后一个视频包。
[0205] 基于此，该装置还可以包括：
[0206] 第一视频包检查单元，用于若所述当前帧的参考状态表示所述参考帧完整，对已缓存的当前帧的视频包的完整性进行检查，并根据检查结果确定所述当前帧是否可解码；若确定所述当前帧不可解码，执行所述第一帧丢弃单元。
[0207] 进一步地，本申请的装置还可以包括：
[0208] 第一解码处理单元，用于若确定所述当前帧可解码，对所述当前帧进行解码处理；若解码成功，执行第一显示单元，若解码不成功，执行所述第一帧丢弃单元；
[0209] 第一显示单元，对解码后的当前帧进行显示。
[0210] 可选的，若所述当前帧处于所述HPP中最低时间层，则本申请的装置还可以包括：
[0211] 第一I帧请求单元，用于在确定所述当前帧的参考状态表示所述参考帧不完整，或，确定所述当前帧不可解码，或，确定所述当前帧解码不成功时，向视频编码端发送I帧请求，以请求所述视频编码端立即发送下一I帧。
[0212] 可选的，本申请的装置还可以包括：
[0213] 冗余等级调整发送单元，用于在根据检查结果确定所述当前帧不可解码时，向视频编码端发送冗余等级调整请求，以请求所述视频编码端提高发送的冗余包的数量。
[0214] 可选的，本申请的装置还可以包括：
[0215] 第二视频包检查单元，用于在确定收到当前帧的最后一个视频包，且所述当前帧为帧内编码帧I帧时，对已缓存的当前帧的视频包的完整性进行检查，并根据检查结果确定所述当前帧是否可解码；
[0216] 第二参考状态标记单元，用于若确定所述当前帧不可解码，将所述当前帧与下一I帧间的各帧的参考状态标记为，参考帧不完整；
[0217] 第二帧丢弃单元，用于将所述当前帧丢弃，以放弃对当前帧进行解码；
[0218] 第二I帧请求单元，用于向视频编码端发送I帧请求，以请求所述视频编码端立即发送下一I帧。
[0219] 可选的，本申请的装置还可以包括：
[0220] 第二解码处理单元，用于若所述当前帧为I帧且确定其可解码时，对所述当前帧进行解码处理；若解码成功，执行第二显示单元，若解码不成功，执行所述第二参考状态标记单元；
[0221] 第二显示单元，用于对解码后的当前帧进行显示。
[0222] 可选的，上述第一视频包检查单元可以包括：
[0223] 组帧及恢复判断单元，用于若所述当前帧的参考状态表示所述参考帧完整，根据所述当前帧的视频包的包头信息，判断已缓存的当前帧的视频包能否完整组帧，以及在确定不能完整组帧时丢包能否恢复；
[0224] 解码判断单元，用于若判断能够完整组帧，或判断不能完整组帧时丢包能够恢复，则确定所述当前帧可解码。
[0225] 对于编码端和解码端的硬件结构，参照图13，图13为本申请实施例提供的一种终端硬件结构示意图。
[0226] 如图13所示，终端可以包括：
[0227] 处理器1，通信
接口2，
存储器3，通信总线4，和显示屏5；
[0228] 其中处理器1、
通信接口2、存储器3和显示屏5通过通信总线4完成相互间的通信；
[0229] 可选的，通信接口2可以为通信模
块的接口，如GSM模块的接口；
[0230] 处理器1，用于执行程序；
[0231] 存储器3，用于存放程序；
[0232] 程序可以包括程序代码，所述程序代码包括处理器的操作指令。
[0233] 处理器1可能是一个
中央处理器CPU，或者是特定集成
电路ASIC(Application Specific Integrated Circuit)，或者是被配置成实施本申请实施例的一个或多个集成电路。
[0234] 存储器3可能包含高速RAM存储器，也可能还包括
非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。
[0235] 其中，程序具体可以用于：
[0236] 获取原始视频数据；
[0237] 按照分层预测编码结构HPP，对所述原始视频数据进行编码，得到HPP码流；
[0238] 按照前向纠错编码FEC，对所述HPP码流进行冗余编码，其中，所述HPP码流中各帧的冗余包数量按照各帧在HPP中所处时间层由低至高的顺序递减；
[0239] 将冗余编码后的HPP码流中的各帧，顺序发送给解码端。
[0240] 或者，
[0241] 接收编码端发送的当前帧，所述当前帧为编码端按照分层预测编码结构HPP进行编码后的HPP码流中的帧；
[0242] 在确定所述当前帧为帧间编码帧P帧时，判断当前帧的参考帧是否完整；
[0243] 若所述当前帧的参考帧不完整，将所述当前帧丢弃，以放弃对当前帧进行解码；
[0244] 根据所述当前帧在分层预测编码结构HPP中所处位置，确定以所述当前帧为参考帧的目标帧；
[0245] 将所述目标帧的参考状态标记为，参考帧不完整。
[0246] 最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0247] 本
说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
[0248] 对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种
修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
