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给上层。测试后完全正常。