背景痛点

最近在做视频点播项目时，发现HLS流处理存在几个典型问题：

• 转码耗时严重，一段10分钟的视频软编码需要近30分钟
• 生成的TS分片在不同CDN上播放时出现卡顿或无法加载
• 移动端播放时频繁缓冲，尤其在网络波动时体验很差

技术对比

测试了FFmpeg和GStreamer在HLS场景的表现：

1. FFmpeg优势
2. 硬件加速支持全面（NVENC/QSV/VAAPI）
3. 社区资源丰富，问题容易排查

4. 参数调节灵活度更高

5. GStreamer特点

6. 管道式处理更直观
7. 更适合嵌入式设备
8. 但文档较少，调试困难

核心实现

基础HLS生成命令

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 23 -preset fast \
  -c:a aac -b:a 128k \
  -hls_time 6 -hls_list_size 0 \
  -f hls output.m3u8

关键参数说明：

• -hls_time 6：每个TS分片约6秒
• -hls_list_size 0：m3u8保留所有分片记录
• -master_pl_name：主播放列表名称（多码率时使用）

硬件加速方案

Intel核显示例：

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 \
  -i input.mp4 -c:v h264_vaapi -global_quality 28 \
  -f hls -hls_time 4 output.m3u8

多码率自适应方案

完整脚本示例：

#!/bin/bash
INPUT="input.mp4"
OUTPUT_DIR="hls_output"

mkdir -p $OUTPUT_DIR

# 生成三种码率
ffmpeg -i $INPUT \
  -filter_complex \
    "[0:v]split=3[v1][v2][v3]; \
     [v1]scale=w=1920:h=1080[v1out]; \
     [v2]scale=w=1280:h=720[v2out]; \
     [v3]scale=w=854:h=480[v3out]" \
  -map "[v1out]" -c:v:0 libx264 -b:v:0 5000k \
  -map "[v2out]" -c:v:1 libx264 -b:v:1 2500k \
  -map "[v3out]" -c:v:2 libx264 -b:v:2 1000k \
  -map 0:a -c:a aac -b:a 128k -ac 2 \
  -f hls -var_stream_map "v:0,a:0 v:1,a:0 v:2,a:0" \
  -hls_time 6 -hls_list_size 0 \
  -master_pl_name master.m3u8 \
  "$OUTPUT_DIR/playlist_%v.m3u8"

性能优化

1. 分片大小建议
2. 直播场景：2-6秒
3. 点播场景：6-10秒

4. 避免超过10秒影响CDN缓存效率

5. QoE分析命令

   ffprobe -show_frames -select_streams v -print_format json input.ts

避坑指南

• iOS兼容性：必须包含-profile:v baseline
• TS延迟问题：定期插入关键帧`-force_key_frames "expr:gte(n,n_forced*30)"
• 防盗链：使用-hls_key_info_file配合Nginx实现

延伸思考

可以尝试： 1. 动态码率调整算法（ABR） 2. 迁移到DASH协议实现更低延迟 3. 结合WebRTC做实时流传输

参考资料： - FFmpeg官方文档 - 调试技巧：添加-report参数生成详细日志