ZLMediaKit推流性能优化：关键帧处理与低延迟模式探讨

问题背景

在RK3588开发板上使用ZLMediaKit进行实时视频推流时，开发者发现了一个周期性出现的性能问题：每60帧会出现一次明显的处理耗时尖峰。这种现象在H.264和H.265编码格式下表现略有不同，但都具有明显的周期性特征。

现象分析

通过详细的性能测试和代码分析，开发者发现了以下关键现象：

1. 周期性耗时尖峰：在未设置回调函数的情况下，H.264编码格式下每63帧出现一次耗时尖峰，H.265编码格式下每62帧出现一次。

2. 回调函数的影响：设置on_mk_frame_data_release回调函数后，耗时尖峰现象有所缓解，但并未完全消除。

3. 协议转换的影响：关闭除RTSP外的其他转协议功能后，尖峰高度降低但仍存在周期性。

4. 低延迟模式的效果：将lowLatency参数设置为1后，耗时尖峰现象完全消失。

技术原理

关键帧与内存拷贝

视频编码中的关键帧（I帧）通常包含完整的图像信息，数据量远大于预测帧（P帧/B帧）。在ZLMediaKit中，默认情况下创建mk_frame对象时会进行内存拷贝操作，当处理关键帧时，这种拷贝操作会消耗较多CPU资源，导致明显的性能波动。

低延迟模式机制

ZLMediaKit的lowLatency参数控制着RTP包的缓存策略：

• 设置为0（默认）：启用缓存机制，会积累一定数据后再发送，可能导致处理延迟
• 设置为1：禁用缓存，收到数据立即发送，减少处理延迟但可能增加CPU平均负载

优化方案

1. 使用回调函数减少拷贝

通过正确实现on_mk_frame_data_release回调函数，可以避免ZLMediaKit内部的数据拷贝操作：

void frame_data_release(void* user_data) {
    free(user_data);
}

// 创建frame时使用回调
mk_frame frame = mk_frame_create(codec_id, dts, pts, data, size, frame_data_release, data);

2. 合理配置协议转换

根据实际需求精简协议转换配置，只开启必要的协议转换功能：

[protocol]
enable_rtsp=1  # 只开启必要的RTSP协议
enable_rtmp=0
enable_hls=0
enable_mp4=0

3. 启用低延迟模式

在实时性要求高的场景下，可以启用低延迟模式：

[rtsp]
lowLatency=1

性能权衡

需要注意的是，这些优化方案存在一定的性能权衡：

1. 回调函数方案：减少了内存拷贝，但需要开发者自行管理内存生命周期，增加了代码复杂度。

2. 低延迟模式：消除了处理延迟尖峰，但可能导致CPU平均负载略有上升，网络传输效率可能降低。

最佳实践建议

1. 对于实时性要求高的应用场景，建议同时采用回调函数和低延迟模式。

2. 在资源受限的设备上，应仔细评估协议转换的必要性，避免不必要的资源消耗。

3. 定期监控系统性能指标，根据实际运行情况调整参数配置。

总结

通过分析ZLMediaKit在RK3588平台上的推流性能问题，我们发现关键帧处理和数据拷贝是导致周期性耗时尖峰的主要原因。合理使用回调函数、精简协议转换配置以及启用低延迟模式，可以有效解决这一问题。开发者应根据具体应用场景的需求，在这些优化方案中找到最适合的平衡点。