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

解决方法：

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帧也要丢掉，也就是说整个序列都丢掉。

文章参考：http://t.csdn.cn/Leb1c