我尝试使用ffmpeg从网络摄像头进行实时重播和RTSP反馈，但是流反复停止并显示错误：
＆＃34;没有更多的输出流要写，完成。＆＃34;
问题似乎在更高的比特率（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＆gt; encode.log 2＆gt;＆amp; 1
让我觉得错误是没有意义的，这是一个实时流，因此在关闭流之前总是需要输出。所以关闭它是因为输出不是非常奇怪的。如果ffmpeg由于输入问题而抱怨它会更有意义。
我正在运行3.3.4版本，我相信这是最新版本。
10月13日更新：
经过广泛的测试，我已经确定了“没有更多的产出＆＃34; FFMPEG生成的错误消息非常容易引起误解。如果来自RTSP的数据被延迟，例如通过相机通过路由器连接的其他活动，则似乎会产生错误。我有一个大的缓冲区和超时设置应该足够60秒，但我仍然可以故意触发这个错误，中断时间要短得多，所以显然缓冲区和超时都没有达到预期的效果。这可以通过在路由器上设置QOS策略并通过检查来自摄像机的TCP数据包具有适当高优先级设置来修复，但情况可能并非如此。
但是，如果输入流被短暂中断，我仍然希望提高输入流的健壮性。有没有办法说服FFMPEG容忍这个或实际上使用它似乎忽略的缓冲区？可以说服FFMPEG简单地停止写输出并等待输入变得可用而不是拯救吗？或者我可以让FFMPEG复制最后一个完整的帧，直到它能够获得更多数据？我可以忍受一下流的口吃，但是我必须大大减少当前的行为，在最轻微的问题提示下流消失。
2017年10月13日进一步更新：
经过更多测试后，我发现问题实际上似乎是HLS无法应对传入视频流中的不连续性。如果我故意切断摄像机和FFMPEG之间的网络连接，FFMPEG将等待连接重新建立很长时间。如果中断很长（> 10秒），则流将立即随着＆＃34; No More Outputs＆＃34;错误重新建立连接的瞬间。如果中断很短，那么RTSP实际上将再次开始从摄像机中提取数据，但几秒后流将以相同的错误丢弃。所以很明显输入数据中的间隙导致HLS编码器适应并在流恢复后放弃，但是间隙的大小会影响是否是即时丢弃。
答案 0 :(得分：0)
我有类似的问题。就我而言，几分钟后流停止了，没有任何错误。我通过从freebsd切换到linux来解决此问题。也许问题出在包依赖关系或ffmpeg版本不良。因此，我的建议是尝试使用较新版本的ffmpeg或其他操作系统。
更新：实际上，这不能解决问题。我进行了更多测试，并且15分钟后流停止了。