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

解决方法：

在分组网络中传输H264视频时，丢包是不可避免的，特别是在网络环境不好的情况下传输H264码流，丢包会导致解码端的画面出现花屏和马赛克等严重的视觉效果。为了解决这个问题，目前的前沿技术主要包括前向纠错技术（FEC）和重传机制（NACK）。这两种方法的结合可以有效解决丢包引起的视觉效果问题。然而，这些技术在一些小厂家的设备中可能没有得到广泛应用。

针对丢包问题，我想到了一种直接的解决方法：一旦检测到丢包的发生，在下一个H264的I帧到来之前，将所有到达的包都丢弃。因此，一旦发现丢包的情况，我们可以进行标记，并开始判断接收到的RTP包是否为H264的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帧也要丢掉，也就是说整个序列都丢掉。

以上就是良许教程网为各位朋友分享的Linu系统相关内容。想要了解更多Linux相关知识记得关注公众号“良许Linux”，或扫描下方二维码进行关注，更多干货等着你 ！