【发布时间】：2017-09-28 18:57:34
【问题描述】：
我正在尝试使用 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 copy -vcodec copy 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 编码器适应并在流恢复后放弃，但间隙的大小会影响下降是否是即时的。
【问题讨论】：
标签： ffmpeg