我正在尝试通过 rtsp 接收来自三个摄像头的视频。我们使用具有多个输出的 ffmpeg（ffmpeg 解释如何），但延迟比我们直接运行三个不同的 linux 进程更糟糕，是否可以找到一些 ffmpeg 命令组合来在三个摄像头的录制过程的确切时刻启动。
目前，我们正在使用此命令：
ffmpeg -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -map 0 -vcodec copy video1.mp4 -map 1 -vcodec copy video2.mp4 -map 2 -vcodec copy video3.mp4 -y
它提供了大约 2 秒的延迟。
此外，我们尝试在录制时保持所有帧同步，但如果它们来自不同的设备，这似乎是不可能的，视频之间应该有可变的延迟......
答案1
有很多因素会影响不同来源的视频如何启动、交互和保持同步（或不同步）：
- 三台相机很可能不会确切地相同的帧速率。即使是 25fps 时时间基数相差 1/1000，也会使每 40 秒出现一个完整帧的差异
- 为了使流“开始”（即出现第一个输出图像），解码器需要等待第一个完整图像（I 帧），在此基础上可以构建后续的 B 帧和 P 帧。该上限由 GOP 长度决定，对于流媒体摄像机，该上限通常在 1-2 秒范围内。由于 I 帧通常不仅安排在每个 GOP 边界，而且还安排在发生显著变化的图像内容上（场景变化时的“机会性”I 帧），因此它们不太可能同时出现。这意味着，对于多输入情况，最小延迟是不同流中 I 帧之间的最大时间增量。请记住：H.264 流在设计上不能从任何给定的时间点进行解释，而只能从该时间点之后的第一个关键帧（I 帧）进行解释
- 你确定你问的是正确的问题吗？也许最好早点开始输入阶段，解码为仅关键帧的格式（这样可以立即启动），然后重新编码？这就是广播行业如何实现最低延迟的方法。
前两个问题回答了为什么不同的进程似乎比单个进程启动得更快：每个进程都必须等待一个关键帧，而不是全部三个。