MediaMTX 移动端 HLS 卡顿慢调 3 个 LL-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/mediamtx你用手机在地铁、弱 WiFi 里打开直播间画面卡在缓冲圈转了十几秒才出来——这是用 MediaMTX 分发直播时最常见的 HLS 加载慢问题。MediaMTX 是一个开箱即用的实时媒体服务器能把 RTSP / RTMP / SRT / WebRTC 等直播流转成LL-HLS低延迟 HLS供手机浏览器和 App 直接播放。慢往往不是带宽不够而是几个配置项没调到位。下面按「排查 → 调整 → 验证」推进目标是把首帧等待从秒级压到 1 秒以内。参数速查表30 秒拿结论参数默认值建议值改完的效果hlsVariantlowLatency确保是lowLatency把秒级延迟降到百毫秒级 PartshlsPartDuration200ms100ms客户端 3-part 缓冲从 ~600ms 降到 ~300mshlsAlwaysRemuxfalsetrue省掉首次请求才生成的冷启动等待hlsMuxerCloseAfter60s120s用户短退再回不用重新建流hlsEncryptionfalseiOS 场景设trueApple 设备 LL-HLS 才正常工作udpReadBufferSize02097152弱网下减少丢包抖动注意hlsSegmentCount默认7只决定能回看多长配置文件注释里明确写着它不改变延迟改它并不能加速首帧。第1步 排查先分清是没切低延迟还是缓冲太大先别急着调参。打开浏览器地址栏访问播放列表看它长什么样http://localhost:8888/mystream/index.m3u8如果里面没有#EXT-X-PART行说明当前没在跑低延迟模式延迟自然以秒计如果有#EXT-X-PART但PART-TARGET偏大则是缓冲粒度过粗。这一步能帮你定位到底是模式问题还是时长问题避免白调。相关读取方式见 docs/4-read/06-hls.md。第2步 调整把 LL-HLS 缓冲压到最小在mediamtx.yml的 HLS 段落里改两项改完重启或热加载生效hlsVariant: lowLatency # 默认值就是它若被改成 mpegts/fmp4 请改回 hlsPartDuration: 100ms # 默认 200ms压到 100mshlsVariant默认lowLatency→ 确保保持lowLatency→ 用更小的 Part 替代整段 Segment延迟从秒级降到百毫秒级。hlsPartDuration默认200ms→ 建议100ms→ 播放器通常缓存 3 个 Part 才开始播缓冲从约 600ms 降到约 300ms首帧更快。hlsSegmentDuration保持1s它只是 Segment 下限Part 才是低延迟模式下真正决定延迟的粒度别动它去换速度。再顺手解决冷启动hlsAlwaysRemux: true # 默认 false → 改为 true hlsMuxerCloseAfter: 120s # 默认 60s → 改为 120shlsAlwaysRemux默认false有人请求才生成→ 建议true→ 持续预生成用户点进来无需等第一帧合成。hlsMuxerCloseAfter默认60s→ 建议120s→ 移动端用户切走再回来时流还在避免重建等待。第3步 调整为 iOS 打开 HTTPS ⚠️这是移动端最容易被忽略的一点。配置文件注释写明LL-HLS 在 Apple 设备上必须走 HTTPS 才能正常工作。hlsEncryption: true # 默认 false → iOS 场景改 true hlsServerKey: server.key hlsServerCert: server.crthlsEncryption默认false→ iOS 观众场景设true→ 手机 Safari / App 里的 LL-HLS 才会启用否则会回退到高延迟或加载失败。证书可用openssl生成见 docs/5-references/1-configuration-file.md。第4步 兜底弱网下减少丢包地铁、4G 抖动场景UDP 收发端缓冲太小会直接放大卡顿udpReadBufferSize: 2097152 # 默认 0用系统默认→ 设 2MBudpReadBufferSize默认0→ 建议20971522MB→ 网络拥塞时有更大读缓冲吸收瞬时抖动减少丢包。弱网排查思路见 docs/2-features/28-decrease-packet-loss.md。第5步 验证一条命令确认延迟下降改完别只看感觉用两条命令客观确认。先开 metrics默认关闭metrics: true metricsAddress: :9998# 1) 确认在跑低延迟模式并读出当前 Part 目标时长 curl -s http://localhost:8888/mystream/index.m3u8 | grep -E EXT-X-PART|PART-TARGET # 看到 PART-TARGET0.1 说明 100ms 已生效0.2 仍是旧值 # 2) 看 HLS 复用器是否在线 curl -s http://localhost:9998/metrics | grep hls_muxersPART-TARGET的值就是真实生效的 Part 时长是判断改没改到的硬指标hls_muxers有值说明流在持续生成。指标含义见 docs/2-features/22-metrics.md。收个尾把hlsVariant锁定lowLatency、hlsPartDuration压到100ms、给 iOS 打开hlsEncryption再用PART-TARGET和hls_muxers两个指标闭环验证移动端首帧等待就能从秒级降到 1 秒内。完整的性能调优背景参考 docs/2-features/23-performance.md各参数取值以 docs/5-references/1-configuration-file.md 为准。【免费下载链接】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），仅供参考
