FFMPEG:RTSP 到 HLS 重新流停止以 "No more output streams to write to, finishing."

Question

我正在尝试使用 ffmpeg 从网络摄像头实时重新流式传输 RTSP 提要，但流反复停止并出现错误:

“没有更多的输出流要写入，完成。”

这个问题似乎在更高的比特率下变得更糟(256kbps 是最可靠的)并且它的发生非常随机。在 1mbps 时，有时流会运行几个小时而没有任何问题，在其他情况下，流每隔几分钟就会失败。我有一个 cron 作业正在运行，它在失败时会自动重新启动流，但我更愿意避免持续的中断。

我在少数其他论坛上看到过这个问题的报告，所以这不是一个独特的问题，但这些报告中没有一个附有解决方案。我的 ffmpeg 命令如下所示:

ffmpeg -loglevel verbose -r 25 -rtsp_transport tcp -i rtsp://user:password@camera.url/live/ch0 -reset_timestamps 1 -movflags frag_keyframe+empty_moov -bufsize 7168k -stimeout 60000 -hls_flags temp_file -hls_time 5 -hls_wrap 180 -acodec 复制 -vcodec 复制 streaming.m3u8 > encode.log 2>&1

让我明白的是，这个错误毫无意义，这是一个实时流，所以在我关闭流之前总是需要输出。因此，因为不需要输出而将其关闭是非常奇怪的。如果 ffmpeg 由于输入问题而提示，那将更有意义。

我正在运行 3.3.4 版，我相信它是最新的。

17 年 10 月 13 日更新:

经过大量测试后，我确定 FFMPEG 生成的“不再有输出”错误消息非常具有误导性。如果来自 RTSP 的数据延迟，例如由于连接相机的路由器上的其他事件，似乎会生成错误。我有一个很大的缓冲区和超时设置，应该足够 60 秒，但我仍然可以故意以更短的中断触发这个错误，所以很明显缓冲区和超时没有达到预期的效果。这可以通过在路由器上设置 QOS 策略并检查来自摄像机的 TCP 数据包是否具有适当的高优先级来解决，但情况可能并非如此。

但是，如果输入流被短暂中断，我仍然想提高它的鲁棒性。有什么方法可以说服 FFMPEG 容忍这一点或实际使用它似乎忽略的缓冲区？是否可以说服 FFMPEG 简单地停止写入输出并等待输入可用而不是退出？或者我可以让 FFMPEG 复制最后一个完整的帧，直到它能够获得更多数据？我可以忍受流有点卡顿，但我必须显着减少流在最轻微的问题提示下下降的当前行为。

2017 年 10 月 13 日进一步更新:

经过更多测试，我发现问题实际上似乎是 HLS 无法应对传入视频流中的不连续性。如果我故意切断相机和 FFMPEG 之间的网络连接，FFMPEG 将等待连接重新建立相当长的时间。如果中断时间很长(>10 秒)，则在重新建立连接的那一刻，流将立即丢弃并出现“No More Outputs”错误。如果中断时间很短，那么 RTSP 实际上会再次开始从摄像头中提取数据，但几秒钟后流会因同样的错误而丢失。因此，很明显，输入数据中的差距导致 HLS 编码器适应并在流恢复后放弃，但差距的大小会影响下降是否是即时的。

Answer 1

我有一个类似的问题。在我的情况下，几分钟后流停止，没有任何错误。我通过从 freebsd 切换到 linux 解决了这个问题。可能问题出在不良的包依赖关系或 ffmpeg 版本上。所以我的建议是尝试旧版本或新版本的 ffmpeg 或其他操作系统。

更新:实际上这并不能解决问题。我进行了更多测试，并在 15 分钟后停止了流式传输。