fix(hls): correct LLHLS timestamps and SPS context handling

[tadebao]

问题描述

LL-HLS 输出不可用（针对 GB28181 摄像头实测）：

1. 切片时长 0.54ms / bitrate 5.6Gbps：llhls.go 用 v.GetPTS() 作为 gohlslib.WriteH264/WriteH265 的时间参数。但 GetPTS() 返回的是 90kHz tick 数（(Timestamp+CTS)*90/time.Millisecond），而 gohlslib 期望真实 time.Duration（纳秒）。帧间隔 40ms 被解释为 3.6µs，一个 GOP（150 帧）只有 540µs → 切片 0.54ms、BANDWIDTH 5.6Gbps。

2. Muxer 每 2 秒崩溃重试：videoFunc 闭包捕获了 Run() 开始时的旧 codec context。摄像头 SPS 变化后，DTS extractor 报 invalid SPS: invalid pic_order_cnt_type: 6，Muxer 崩溃 → subscribe → 读取几帧 → 又崩溃，无限循环，stream.m3u8 时常为空。

修复

1. 时间单位修正：v.GetPTS() → ts + v.CTS（Timestamp 本身是纳秒 time.Duration，v.CTS 同理）。H264/H265 两条路径都改。

2. 动态获取最新编码上下文：IDR 帧时不再使用闭包捕获的 ctx，而是 subscriber.Publisher.GetVideoCodecCtx() 现场取最新 SPS/PPS/VPS，避免旧 context 的 SPS 与当前流不匹配导致 extractor 崩溃。

验证（真实 GB28181 摄像头 + watch 页面双流）

指标	修复前	修复后
切片时长	0.54ms	2s / 4s ✅
BANDWIDTH	5.6Gbps	518Kbps / 259Kbps ✅
分辨率	-10x-9 (002)	1280x720 双流 ✅
SPS 崩溃循环	每 2s 一次	0 次 ✅

• 001/002 两路摄像头 LLHLS 均正常（index.m3u8 / stream.m3u8 参数正常）
• 修复后的二进制用 -tags sqlite 编译（纯 Go sqlite driver，无 CGO），本地 smoke test 插件加载正常后部署

备注

改动最小化：仅 plugin/hls/llhls.go，+15/-4。

[Copilot]

Pull request overview

This PR fixes LL-HLS output correctness and stability in the HLS plugin by correcting timestamp units passed into gohlslib and avoiding stale (captured) video codec parameter sets when SPS/PPS/VPS changes at runtime.

Changes:

• Pass real presentation timestamps (Timestamp + CTS, time.Duration in nanoseconds) to Muxer.WriteH264/WriteH265 instead of GetPTS() (90kHz ticks).
• On IDR frames, fetch the latest video codec context from the publisher and prepend current SPS/PPS (H264) or VPS/SPS/PPS (H265) into the access unit to prevent crashes caused by outdated parameter sets.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.