MediaMTX RTSP转HLS 低延迟直播实操三步把延迟压进 1 秒【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtxMediaMTX 把 RTSP 流转成 HLS 分发默认延迟 6~10 秒。本文以现网实例为例给出 3 步低延迟直播配置加 1 套测延迟的方法参数可直接照抄目标是把端到端延迟压到 1 秒以内。 先看基线默认延迟有多大怎么测先说结论延迟不是一个固定值由三个参数共同决定——hlsVariant、hlsSegmentDuration、hlsPartDuration。旧版本 MediaMTX 默认是mpegts变体加 10s 分片播放器缓冲 2~3 个分片实测 20 秒起步就算把分片缩到 2s也还在 6~8 秒。新版 mediamtx.yml 默认已是lowLatency变体、1s 分片、200ms part但没验证过的人并不知道自己实际跑的是哪套。所以第一步是查本地配置grep -E hlsVariant|hlsSegmentDuration|hlsPartDuration|hlsSegmentCount mediamtx.yml。怎么测LL-HLS 播放列表里的EXT-X-PROGRAM-DATE-TIME带绝对时间戳拿它和当前时间做差就是服务端侧延迟# 取播放列表里最新的节目日期时间与当前 UTC 时间对比 curl -s http://localhost:8888/lowlatency/index.m3u8 | grep -m1 PROGRAM-DATE-TIME date -u now: %Y-%m-%dT%H:%M:%SZ两行输出相减得到从源流出帧到 HLS 可取的延迟不含播放器缓冲播放端延迟再用 VLC 媒体信息里的时间差交叉验证一次。⚙️ 第一步开启 LL-HLS低延迟直播里收益最大的参数现象分片调短了延迟却卡在一个分片下不来。原因是普通 HLS 的播放规则——分片没下载完整就不能播分片时长就是延迟的硬下限。LL-HLS 把一个分片拆成若干 part播放器取到一个 part 就能往下播下限从1 个分片降到2~3 个 part。在 mediamtx.yml 的全局 HLS 段写hlsVariant: lowLatency # 启用 LL-HLS 变体 hlsPartDuration: 200ms # part 时长决定延迟下限 hlsSegmentDuration: 1s # part 聚合成 1s 的分片 hlsSegmentCount: 7 # LL-HLS 模式最小就是 7填小会启动报错延迟理论下限约等于 2~3 个 part即 400~600ms。hlsSegmentCount只决定保留几个分片供回看拖动不影响延迟配置校验在 LL-HLS 模式下要求它不小于 7别指望改它省延迟。协议细节和客户端列表见 docs/4-read/06-hls.md。第二步HLS 分片时长与播放列表长度推荐组合那把分片调短就行吗没那么简单。服务端保证每个分片至少包含一个关键帧IDR如果源头 GOP 是 2 秒你写 1s实际分片就是 2s延迟也跟着翻倍。分片参数必须和源流的帧结构一起看参数推荐值说明hlsPartDuration200ms别低于 100mspart 请求过密会压 HTTP 开销hlsSegmentDuration1s实际时长按 IDR 间隔向上取整hlsSegmentCount7只影响回看窗口不影响延迟hlsMuxerCloseAfter默认 60s无读者时自动关复用器省 CPU源流的 GOP 才是这一节真正的主角把摄像头侧关键帧间隔设成 1 秒左右服务端 1s/200ms 的组合才拿得到。第三步播放器侧缓冲端到端延迟里被忽略的一环服务端测到 600ms 了为什么画面还是慢 1.5 秒差在播放器缓冲里。端到端延迟 服务端延迟 播放器缓冲后者常被漏算播放器一般先囤 2~3 个 part 再开播这正是 200ms part 下你仍看到 800ms 左右的原因。按播放器分别处理hls.js把liveSyncDurationCount从 3 改到 1并开启lowLatencyMode: trueVLC高级偏好里 Network Caching Value 默认 1000ms可降到 300~500msSafari 等原生 LL-HLS 客户端缓冲策略最激进通常不用动。这一层改完同一路流端到端延迟从 6 秒上下降到 1 秒以内属于正常结果。踩坑复盘调 RTSP转HLS 低延迟常走的弯路只改hlsSegmentDuration没开lowLatency下限还是一个完整分片改动白做。源流关键帧稀疏1s 配置实际跑成 2~3s。先查编码器 GOP再谈服务端参数。FFmpeg 转码参数没跟上用 FFmpeg 向 RTSP 推流转码时加-c:v libx264 -tune zerolatency -g 50这类低延迟参数完整写法见 docs/2-features/07-remuxing-reencoding-compression.md。中间有 CDN 或反代缓存了播放列表LL-HLS 播放列表必须每次实时请求缓存一开延迟直接打回原形见 docs/2-features/19-scalability.md。苹果设备打不开 LL-HLS需要 HTTPS把hlsEncryption设为yes并配好hlsServerKey/hlsServerCert。至于动源码——去改 internal/servers/hls/muxer.go 里的分片生成逻辑再抠 100ms生产环境不值得配置层面能拿的收益远大于此。常见问题QhlsSegmentDuration写成 1s实测分片是 3sA服务端会把分片时长向上取整保证内含至少一个 IDR 帧。先查源流关键帧间隔是不是 3 秒GOP 不改参数白调。Q播放器不支持 LL-HLS 会怎样A自动退回普通 HLS 的分片播放延迟回到 2~3 个分片的量级约 2~3 秒流本身仍可用属于向下兼容。Q把hlsSegmentCount调小是不是能降延迟A不能。这个参数只控制保留几个分片用于回看LL-HLS 模式下最小 7与延迟无关。【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
