求助：FFmpeg处理YouTube HLS直播流输出RTMP时分段请求延迟

解决FFmpeg转推YouTube HLS直播到RTMP时分段请求延迟的问题 #

针对你遇到的FFmpeg处理YouTube HLS直播流时，下载完3秒分段后停滞10秒才请求新分段的问题，结合你使用的youtube-dl 2018.03.14版本，我整理了一套可行的命令方案和优化思路：

1. 先获取YouTube直播的HLS流地址

先用youtube-dl提取直播的直接HLS链接，这一步能确保FFmpeg拿到的是最适配的直播流：

youtube-dl -f best -g <你的YouTube直播URL>

执行后会输出1-2个URL，复制那个带.m3u8后缀的HLS流地址备用。

2. 优化后的FFmpeg转推命令

把上面拿到的HLS地址替换到<HLS_STREAM_URL>，目标RTMP地址替换到<RTMP_DESTINATION>：

ffmpeg -fflags +genpts -i <HLS_STREAM_URL> \
  -hls_flags delete_segments+discard_corrupt+seekable \
  -reconnect_streamed 1 -reconnect_delay_max 5 \
  -c:v copy -c:a copy -f flv <RTMP_DESTINATION>

关键参数为什么能解决你的问题？

• -fflags +genpts：强制生成连续的时间戳，避免直播流中时间戳缺失或不连续导致FFmpeg进入不必要的缓冲等待
• -hls_flags delete_segments+discard_corrupt+seekable：
  • delete_segments：下载完成的分段立即删除，不让旧分段占用缓存，同时触发FFmpeg更快地去检测新的直播分段
  • discard_corrupt：跳过损坏的分段，防止因个别分段异常导致整个流程卡住
  • seekable：让FFmpeg把HLS直播流识别为可检索的流，主动去探测最新的分段，而不是被动等待
• -reconnect_streamed 1 & -reconnect_delay_max 5：如果临时断流，FFmpeg会在5秒内自动重连，避免长时间停滞
• -c:v copy -c:a copy：直接复制音视频编码，不做转码，既节省资源又能保证最低延迟

额外的排查建议

• 考虑更新youtube-dl：你的版本是2018年的，YouTube的HLS直播协议有过不少更新，新版本的youtube-dl能更精准地获取直播流信息，减少兼容性问题
• 调整缓冲参数：如果还是有小延迟，可以尝试添加-max_delay 1000（限制最大延迟1秒）或者-avioflags direct（减少IO层的缓冲）
• 检查网络：确保你的机器到YouTube的网络连接稳定，高延迟或丢包也会让FFmpeg请求分段的速度变慢

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