问题分析

最近在一个新环境下保持RTP的H264视频数据花屏，按照以往经验，最大可能性是丢包了，遂抓包分析，发现包个数足够，并没有反馈任何包的丢失，这就有意思了。

不过在看抓包过程中，不经意间发现了下面的现象

seq 51 的包跑到 seq 50 的前面了，怪不得解包的视频不正确。顺着这个线索继续看发现

• 乱序现象一直存在，间隔时间不长就出现一次
• 乱序的包是一个视频帧，即其时间戳是相同的

解决方法

项目中使用的是开源的 ortp 库，分析其实现代码，接收数据后并没有针对序号的判断(较早的版本)，因此在接收数据后根据上面的规律，将相同时间戳内的包进行缓存，等时间戳变化之后再进行排序解包，确保包的顺序是正确的。当然按这个思路并不能解决丢包问题，但是应该是可以解决我们当前环境的问题。

另外新版的库已经开始支持Feedback机制了，那么在遇到这种情况下，肯定会先发送 NACK 包让对方重传丢失的包，这样是不是通过升级新版的库就可以解决呢（假设客户端是支持Feedback机制的）？

然而事情并不像想象的那么美好，通过分析其 rtp_session_recvm_with_ts 函数实现，其中的关键代码

mblk_t *
rtp_session_recvm_with_ts (RtpSession * session, uint32_t user_ts)
{
    ...
    if ((rtp_session_avpf_enabled(session) == TRUE) && ...) {
        /*
        * If immediate nack is disabled then we check for missing packets here instead of
        * rtp_session_rtp_parse
        */
        check_for_seq_number_gap(session, rtp);
    }
    ...
    return mp
}

在判断了丢包需要发送 NACK 等操作后，依然是直接返回了接收的包，所以无论如何底层依然是没有实现乱序重排机制的，还得上层应用来做。