丢包导致的视频花屏马赛克问题解决办法

H264视频在分组网络中传输丢包不可避免,尤其在网络环境不好时传输h264码流,丢包会导致解码端花屏,马赛克严重,这方面的前沿技术是 FEC, NACK, 前者是 前向纠错技术,后者是重传,二者结合能很好的解决丢包引起的视觉效果,这东西一般小厂家都没有,如果想丢包时即使让画面停顿,也不要花屏,我想的最直接的办法是:一旦发现丢包,在下一个I帧到来之前,所有过来的包都丢掉,所以一旦发现丢包,做个标记,然后开始判断收到的rtp包是不是264 i帧, i帧的判断方法参考:

 
 
static bool isH264iFrame(byte[] paket)
    {
        int RTPHeaderBytes = 0;
 
        int fragment_type = paket[RTPHeaderBytes + 0] & 0x1F;
        int nal_type = paket[RTPHeaderBytes + 1] & 0x1F;
        int start_bit = paket[RTPHeaderBytes + 1] & 0x80;
 
        if (((fragment_type == 28 || fragment_type == 29) && nal_type == 5 && start_bit == 128) || 
fragment_type == 5 || fragment_type == 7 || fragment_type == 8)
        {
            return true;
        }
 
        return false;
   }
 
*****************************************************************************************************************************
 
ortp是RTP协议的一个具体实现,最近在做的视频会议重也用到了这个协议栈。需要将数据通过ortp协议进行传输后在处理。做的过程中碰到了一个问题,视频数据通过ortp后,会出现花屏的现象。

1:我们的视频数据采用H264进行压缩。基于h264的特性,如果物体的运动的话,视频数据就会增减(比起物体静止的时候)。这个时候一帧的视频数据就会由多个packet组成。

2:在使用ortp进行传输时为了方便区分每一帧的界限,规定了再每一帧的最后一个packet时,再RTP的头部的markbit位置标为1。

3:在接收端:主要时使用一个循环体接收每个timestamp中的数据。

while(rtp_session_recvm_with_ts (RtpSession * session, uint32_t user_ts)!=NULL)

主要的逻辑就是碰见了markbit为1的包后,就把当前收到的所有包组装成一帧数据发到上层的h264解码。

在后面的测试中出现了问题,音频的通话质量很好,但是视频当人在动的 时候就会卡出现花屏。

分析发现了问题:当我们在使用rtp_session_recvm_with_ts (RtpSession * session, uint32_t user_ts)进行接收时,忧郁传输延迟,不可能一个帧的所有packet都在一个这个user_ts中收完,实际中发现了一个user_ts收到的packet的timestamp往往发生了变化。如果这个时候再某一帧的最有packet恰好丢失,也就是markbit为1的那个packet丢失了。后面有收到了下一帧的第一个packet,原来的处理逻辑认为这个时侯发生了丢包。所有把下个帧的第一个packet和上个帧的前几个packet一起组成了一个帧发送了出去。导致后面的帧缺失了头部。所以在解码的时候无法进行。

改正的后逻辑应该是再timestamp发生改变或者碰见markbit为1的packet都要发送当前收到的所有packet给上层。测试后完全正常。

 
***************************************************************************************************************************************
 
总结一下,
1. 在接收端根据rtp包的seqnumber来判断是否丢包,如果丢包就标记一下。
2. 在mark为1或时间戳改变的时候,说明一帧结束了,此时如果标记为丢包了,就扔掉数据,没有丢包就给解码器。
3. 如果丢包的帧为I帧,则不仅丢掉当前I帧,此I帧之后的P帧也要丢掉,也就是说整个序列都丢掉。
 
  • 5
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 5
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值