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的TNUMBERZG，就把现阶段接到的大部份包装配成一格统计数据寄送下层的h264音视频。
在前面的试验中再次出现了难题，音视频的P3100较好，但是音视频当人在动的 这时候就尚普托再次出现动圈。
预测辨认出了难题：当他们在选用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给下层。试验后全然恒定。
