背景痛点

在视频监控和直播场景中，RTSP协议因其低延迟特性被广泛使用，但面对Web端播放时往往需要转换为HLS协议。传统方案常遇到以下问题：

• 高延迟：RTSP默认使用TCP传输，转HLS时切片生成需要缓冲，导致延迟叠加
• 并发瓶颈：单个FFmpeg进程处理多路流时CPU资源竞争激烈
• 部署复杂：需要手动管理转码进程和分发服务

技术选型

对比常见转码方案：

1. FFmpeg：
2. 优势：支持硬件加速（VAAPI/NVDEC），参数调节灵活

3. 劣势：需要自行管理进程生命周期

4. GStreamer：

5. 优势：管道化处理更直观

6. 劣势：插件生态复杂

7. 商业转码器：

8. 优势：开箱即用
9. 劣势：license成本高

核心实现

FFmpeg转码配置

关键参数说明：

ffmpeg -rtsp_transport tcp \
       -i "rtsp://camera1" \
       -c:v libx264 -profile:v high -level 4.1 \
       -g 60 -keyint_min 60 \
       -sc_threshold 0 -b_strategy 0 \
       -hls_time 2 -hls_list_size 5 \
       -f hls /var/www/hls/stream1.m3u8

• -rtsp_transport tcp 确保网络抖动时仍能稳定连接
• -g 60 设置关键帧间隔，与HLS切片时长对齐
• -sc_threshold 0 禁用场景切割避免意外关键帧

Nginx配置优化

server {
    listen 8080;
    location /hls {
        types {
            application/vnd.apple.mpegurl m3u8;
            video/mp2t ts;
        }
        root /var/www;
        add_header Cache-Control no-cache;
        add_header Access-Control-Allow-Origin *;
    }
}

• no-cache 强制客户端实时获取最新片段
• CORS头解决跨域播放问题

性能考量

处理多路流时的优化策略：

1. 硬件加速：
2. 使用-hwaccel cuvid调用NVIDIA显卡解码

3. VAAPI参数：-hwaccel vaapi -hwaccel_device /dev/dri/renderD128

4. 进程隔离：

5. 每路流单独FFmpeg进程

6. 通过cgroups限制CPU占用

7. 内存优化：

8. 设置-thread_queue_size 1024避免丢帧
9. 调整-bufsize匹配网络状况

避坑指南

常见问题解决方案：

• 时间戳跳跃：添加-use_wallclock_as_timestamps 1
• 首屏延迟高：减少-hls_time到1秒并启用-hls_flags split_by_time
• 花屏问题：检查关键帧间隔是否对齐-g与-hls_time

实验建议

尝试组合下列参数观察效果：

1. 测试不同硬件加速方案（CPU/GPU）的转码延迟
2. 对比-preset ultrafast与-preset slower的CPU占用率
3. 调整HLS切片时长观察端到端延迟变化

期待大家在评论区分享自己的调优经验！