ZLMediaKit中RTSP流pts_time负值问题的分析与解决

问题背景

在使用ZLMediaKit进行RTSP流媒体服务时，开发者发现通过ffprobe工具检测流媒体时，会出现pts_time(显示时间戳)为负值的情况。这种现象在流媒体处理中是不正常的，可能导致播放器处理异常或显示问题。

问题现象

通过ffprobe工具分析RTSP流时，输出结果显示大量负的pts_time值，如：

pts_time=-1.055875
pts_time=-1.035875
pts_time=-1.015875
...

随后逐渐增加到正值。同时ffprobe日志中还显示有丢包和解码错误信息。

技术分析

经过深入分析，发现问题根源在于ZLMediaKit的RTSP会话处理中存在两个关键问题：

1. 类型转换问题：在计算RTP时间戳(rtptime)时，代码中将uint32类型的时间戳强制转换为int类型，当时间戳值较大时会导致溢出，产生负值。

2. 时间戳基准问题：RTSP会话中发送的RTP-info头部中的rtptime值可能大于实际RTP包中的时间戳，导致播放器计算出的相对时间出现负值。

解决方案

针对上述问题，提出了多层次的解决方案：

1. 类型转换修正：

// 原代码(有问题)
<< "rtptime=" << (int)(track->_time_stamp * (track->_samplerate / 1000)) << ",";

// 修正后
<< "rtptime=" << (int64_t)(track->_time_stamp * (track->_samplerate / 1000)) << ",";

2. 时间戳基准调整： 通过访问环形缓冲区的存储数据，获取实际RTP包中的最小时间戳作为基准：

uint32_t _ts_audio = UINT32_MAX;
uint32_t _ts_video = UINT32_MAX;
auto _cache = play_src->getRing()->getStorage()->getCache();
for (auto p : *_cache.begin()) {
    p.second->for_each([&_ts_audio, &_ts_video](const RtpPacket::Ptr &rtp) {
        int64_t i = (int64_t)rtp->getStamp() * 1000 / rtp->sample_rate;
        if (rtp->type == TrackAudio) {
            if (i < _ts_audio) _ts_audio = i;
        } else if (rtp->type == TrackVideo) {
           if (i < _ts_video) _ts_video = i;
        }
        if(_ts_audio < UINT32_MAX && _ts_video < UINT32_MAX) return;
    });
}

3. RTSP会话优化： 确保发送的rtptime不大于实际RTP包中的时间戳，避免播放器计算出负的相对时间。

技术原理

在RTP/RTSP协议中，时间戳处理有几个关键点需要注意：

1. RTP时间戳是32位无符号整数，会周期性回绕
2. RTSP的RTP-info头部中的rtptime用于同步不同媒体流
3. 播放器会根据第一个收到的RTP包时间戳和rtptime计算相对时间

当rtptime大于实际RTP包时间戳时，播放器计算出的相对时间就会是负值，导致ffprobe显示负的pts_time。

实现建议

对于ZLMediaKit项目，建议采取以下改进措施：

1. 在RingBuffer类中增加getStorage()方法，提供对底层存储的访问
2. 修改RTSP会话处理中的时间戳计算逻辑
3. 确保所有时间戳转换使用足够大的数据类型(int64_t)
4. 在发送RTP-info头部前，验证rtptime的合理性

总结

RTSP流媒体服务中的时间戳处理是一个需要特别注意的技术点。ZLMediaKit通过修正类型转换问题和优化时间戳基准选择，可以有效解决pts_time负值问题，提升流媒体服务的兼容性和稳定性。这一改进对于需要精确时间同步的应用场景尤为重要，如视频监控、直播等。