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