SRS流媒体服务器中FFmpeg循环推流时长不一致问题解析

问题背景

在使用SRS(Simple Realtime Server)流媒体服务器时，开发者发现当通过FFmpeg推送循环播放(RTMP)视频流时，13分钟的长视频会出现"conversion failed"错误，而3分钟的短视频则能正常工作。这个问题在Windows和Linux系统下都会出现，且仅在SRS配置了RTMP转发功能时发生。

问题现象分析

通过FFmpeg推送视频流时，开发者使用了以下典型命令：

ffmpeg -hide_banner -stream_loop -1 -re -i input.mp4 -c copy -f flv -flvflags no_duration_filesize rtmp://SRS-HOST/live/stream0

错误日志显示在视频循环时出现了"Broken pipe"错误和"conversion failed"提示。深入分析后发现，问题视频的音频流和视频流存在时长不一致的情况，差异超过30秒。

技术原理

1. 流媒体容器格式特性：MP4等容器格式允许音频和视频轨道具有不同的时长，这在编辑视频时很常见。

2. FFmpeg循环推流机制：当使用-stream_loop -1参数时，FFmpeg会无限循环输入文件，但如果音视频轨道时长差异较大，会导致同步问题。

3. SRS转发机制：SRS在转发RTMP流时，对流的连续性有严格要求。音视频不同步会导致转发中断。

解决方案

1. 检查并修正媒体文件：

ffmpeg -i input.mp4 -c copy -shortest output.mp4

使用-shortest参数可以自动截取音视频轨道中最短的时长作为输出文件时长。

2. 显式指定输出时长：

ffmpeg -i input.mp4 -c copy -t 13:00 output.mp4

手动指定一个合理的输出时长，确保音视频同步。

3. 转码处理：

ffmpeg -i input.mp4 -c:v libx264 -c:a aac -b:v 1M output.mp4

完全重新编码可以确保音视频轨道的严格同步。

最佳实践建议

1. 在推流前使用ffprobe检查媒体文件信息：

ffprobe -show_streams input.mp4

重点关注各轨道的duration字段是否一致。

2. 对于直播推流场景，建议：

• 确保音视频时长一致
• 避免使用编辑过多次的源文件
• 考虑使用专业直播编码器而非FFmpeg

3. 在SRS配置方面：

• 适当调整time_jitter参数
• 监控转发节点的带宽和延迟

总结

这个案例展示了流媒体处理中音视频同步的重要性。开发者在使用FFmpeg推流时，特别是循环推流场景下，必须确保源文件的音视频轨道时长一致，否则会导致各种同步问题。通过正确的文件预处理和参数配置，可以避免这类问题的发生，确保直播流的稳定传输。