使用FFmpeg同步RTSP流：合并后首输入流存在延迟问题求助

兄弟，这个问题我太熟了！之前帮几个做安防监控的朋友解决过一模一样的情况——FFmpeg对多路RTSP输入的默认缓存策略坑就坑在第一路，哪怕是同一个流当两路输入，都会因为初始化顺序导致第一路延迟堆积。给你几个亲测有效的方案：

1. 强制统一两路输入的同步与缓存参数 #

FFmpeg默认会给第一路输入分配更大的预缓存空间，加上RTSP流本身的时间戳可能存在抖动，很容易积累延迟。给两路输入完全相同的参数，从根源上对齐处理逻辑：

• -fflags +genpts：强制FFmpeg为输入流生成连续的时间戳，避免RTSP流自带的时间戳混乱
• -rtsp_transport tcp：用TCP传输替代默认的UDP，减少丢包导致的时间戳错位
• -buffer_size 1024000：限制输入缓存的大小，防止第一路缓存过度堆积
• -thread_queue_size 512：给两路输入设置相同的线程队列大小，避免第一路队列积压

完整命令示例 #

ffmpeg \
  -thread_queue_size 512 -fflags +genpts -rtsp_transport tcp -buffer_size 1024000 -i rtsp://cam1/stream \
  -thread_queue_size 512 -fflags +genpts -rtsp_transport tcp -buffer_size 1024000 -i rtsp://cam2/stream \
  -filter_complex "[0:v][1:v]hstack=inputs=2[v]" \
  -map "[v]" \
  -vsync 1 -async 1 \
  rtsp://output/stream

2. 降低编码端的延迟 #

如果输出流用了高延迟的编码器，也会放大两路输入的时间差。优先选择低延迟编码参数：

• -c:v libx264 -preset ultrafast -tune zerolatency：用x264的极速预设，专门针对实时流优化，几乎无编码延迟
• 避免使用需要帧间预测的高压缩率预设（比如slow、medium）

带低延迟编码的命令 #

ffmpeg \
  -thread_queue_size 512 -fflags +genpts -rtsp_transport tcp -buffer_size 1024000 -i rtsp://cam1/stream \
  -thread_queue_size 512 -fflags +genpts -rtsp_transport tcp -buffer_size 1024000 -i rtsp://cam2/stream \
  -filter_complex "[0:v][1:v]hstack=inputs=2[v]" \
  -map "[v]" \
  -c:v libx264 -preset ultrafast -tune zerolatency \
  -vsync 1 -async 1 \
  rtsp://output/stream

3. 验证单流双输入的同步性 #

按照你说的，用同一个RTSP流当两路输入测试，如果还有延迟，说明是FFmpeg的输入处理逻辑问题，再加一个参数：-fflags nobuffer，完全禁用输入缓存（适合低延迟场景，但可能会有卡顿，需要根据实际情况调整）：

ffmpeg \
  -thread_queue_size 512 -fflags +genpts+nobuffer -rtsp_transport tcp -buffer_size 1024000 -i rtsp://same/cam \
  -thread_queue_size 512 -fflags +genpts+nobuffer -rtsp_transport tcp -buffer_size 1024000 -i rtsp://same/cam \
  -filter_complex "[0:v][1:v]hstack=inputs=2[v]" \
  -map "[v]" \
  -vsync 1 \
  test_output.mp4

播放这个测试文件，如果两路画面完全同步，说明参数生效了；如果还是有延迟，可以尝试调整-thread_queue_size的数值（比如调到1024），或者升级FFmpeg到最新稳定版——旧版本的多路输入同步逻辑确实有bug。

内容的提问来源于stack exchange，提问作者Taits