ZLMediaKit项目中H265流转发异常问题分析与解决方案

问题背景

在视频监控系统中，我们经常会遇到需要将视频流进行多级转发的场景。本文将以ZLMediaKit项目中遇到的一个典型H265流转发异常案例为例，深入分析问题原因并提供解决方案。

环境配置

系统采用WVP+ZLM架构，具体配置如下：

• 软件环境：最新版WVP和ZLM媒体服务器
• 硬件环境：4台服务器、1台大华解码器、1台大华摄像头
• 网络拓扑：下级WVP A与上级WVP B级联
• 视频编码：H265编码（业务强制要求）

问题现象

当上级WVP B点播下级WVP A注册的H265视频流并传输到大华解码器时，出现图像右侧无法正常显示的问题。异常图像表现为右侧画面显示异常，而直接使用下级WVP A给出的RTSP流地址则能正常播放。

排查过程

技术团队进行了多方面的排查：

1. 网络层面：通过抓包分析，确认网络传输无丢包现象
2. 协议层面：对比正常和异常情况下的RTSP交互过程
3. 编码层面：测试H264编码情况，发现H264流转发完全正常
4. 日志分析：检查ZLM服务器日志，未发现异常报错

问题根源

经过深入分析，发现问题出在RTP负载类型(Payload Type)的协商上：

1. 在正常的下级流媒体RTSP交互中，服务器给出的Payload Type为98
2. 在异常的上级流媒体RTSP交互中，服务器给出的Payload Type为96
3. 大华解码器可能固化了Payload Type的解析逻辑，没有完全遵循RTSP协议中的rtpmap参数

解决方案

针对这个问题，ZLMediaKit项目组提供了代码层面的修改方案。需要修改RtspMuxer.cpp文件中的相关代码，将动态Payload Type的起始值从96调整为98，以确保与解码器兼容。

具体修改如下：

// 修改前
Sdp::Ptr sdp = track->getSdp(96 + _index);

// 修改后
Sdp::Ptr sdp = track->getSdp(98 + _index);

技术启示

这个案例给我们带来了几个重要的技术启示：

1. 设备兼容性：不同厂商的设备对协议标准的实现可能存在差异
2. 协议协商：RTSP/SDP协议中的参数协商需要特别注意
3. 问题定位：在流媒体问题排查中，需要从网络、协议、编解码等多维度分析
4. 解决方案：有时简单的参数调整就能解决复杂的兼容性问题

总结

通过这个案例，我们深入了解了H265视频流在多级转发过程中可能遇到的兼容性问题。ZLMediaKit项目组提供的解决方案不仅解决了当前问题，也为类似场景下的流媒体转发提供了参考。在实际应用中，我们需要充分考虑终端设备的特性，在协议实现上做好兼容性处理。