ZLMediaKit中RTSP代理播放延迟与失败问题分析与解决方案

问题背景

在使用ZLMediaKit进行RTSP流媒体代理时，用户反馈遇到两个主要问题：一是播放加载时间过长（超过10秒），二是偶发性无法加载（播放器报loadtimeout错误）。该问题在海康威视设备的RTSP流代理场景下尤为明显，流地址格式为rtsp://[username]:[password]@[ip]:[port]/[codec]/[channel]/[subtype]/av_stream。

问题现象分析

从日志中可以观察到几个关键现象：

1. 媒体轨道准备异常：日志显示"H265"视频轨道长时间未就绪，最终被忽略。同时音频轨道"PCMU"虽然就绪，但缓存帧过多被清除。

2. 轨道准备超时：所有轨道准备完成耗时10020ms（约10秒），这正好与用户报告的加载延迟时间吻合。

3. 播放器兼容性问题：日志多次提示"flv播放器一般只支持H264和AAC编码，该编码格式可能不被播放器支持:PCMU"，表明音频编码格式可能存在兼容性问题。

4. 自动关闭机制干扰：配置中启用了无人观看自动关闭功能（streamNoneReaderDelayMS=20000），这可能导致流在不稳定状态下被意外关闭。

根本原因

经过深入分析，问题的根本原因可以归纳为以下几点：

1. 编码格式兼容性问题：

   • 源流使用H265视频编码和PCMU音频编码
   • 播放器端（Jessibuca pro）对这两种编码格式支持有限
   • ZLMediaKit在转封装过程中可能没有进行适当的编码转换

2. 轨道准备机制缺陷：

   • wait_track_ready_ms参数设置为10000ms（10秒）
   • 视频轨道（H265）在此时间内未能就绪
   • 导致整个流准备过程被延迟

3. 配置不匹配：

   • 使用旧版配置文件与新版本ZLMediaKit核心
   • 某些配置参数可能已在新版本中变更或废弃
   • 无人观看自动关闭功能在流不稳定时可能产生副作用

解决方案

针对上述问题，建议采取以下解决方案：

1. 编码格式处理

方案A：源端调整

• 修改海康设备输出格式为H264+AAC
• 这是最彻底的解决方案，可确保最佳兼容性

方案B：转码处理

• 使用ZLMediaKit的FFmpeg转码功能
• 配置转码参数将H265转为H264，PCMU转为AAC
• 示例配置：

  [ffmpeg]
  cmd=%s -re -i %s -c:a aac -strict -2 -ar 44100 -ab 48k -c:v libx264 -f flv %s
  

2. 参数优化调整

关键参数调整建议：

[general]
# 缩短轨道等待时间（根据实际网络状况调整）
wait_track_ready_ms=5000
# 增加未就绪帧缓存
unready_frame_cache=200
# 禁用无人观看自动关闭（或延长关闭时间）
streamNoneReaderDelayMS=0

3. 配置更新与验证

• 使用与ZLMediaKit版本匹配的最新配置文件
• 特别注意检查以下配置段的兼容性：
  • [protocol]中的编码相关参数
  • [rtsp]中的代理和低延迟设置
  • [general]中的超时和缓存参数

4. 网络优化

• 检查RTSP源服务器与ZLMediaKit服务器之间的网络状况
• 考虑使用TCP传输模式（在RTSP配置中设置lowLatency=0）
• 适当调整RTP相关参数（mtu大小、缓存等）

实施建议

1. 分阶段验证：

   • 先解决编码兼容性问题
   • 然后调整超时和缓存参数
   • 最后优化网络配置

2. 监控与日志分析：

   • 重点关注MediaSink.cpp相关的日志信息
   • 监控轨道准备时间和帧丢失率
   • 使用抓包工具分析RTSP/RTP交互过程

3. 性能测试：

   • 在不同网络条件下测试播放稳定性
   • 验证参数调整后的效果
   • 评估转码方案对服务器资源的消耗

总结

ZLMediaKit作为高性能流媒体服务器，在处理RTSP代理时表现出色，但对源流的编码格式和网络条件有一定要求。通过合理的配置调整和编码转换，可以显著改善播放延迟和失败的问题。建议用户根据实际场景选择最适合的解决方案，并保持配置与核心版本的同步更新，以获得最佳的性能和稳定性。