---

直播技术中，FLV和RTMP协议就像快递员，负责把视频数据从主播端送到观众眼前。但这两个"快递员"各有脾气——一个容易堵车（RTMP延迟低但协议老旧），一个喜欢绕路（FLV兼容性好但延迟高）。今天我们就来聊聊怎么给它们规划最优配送路线。

一、为什么我的直播总在转圈圈？

遇到这些情况你可能需要优化：

• 观众抱怨画面卡成PPT，但带宽明明够用
• 服务器半夜偷偷哭诉CPU负载90%
• 东南亚用户总是连不上你的高清流

根本原因是协议没调教好。RTMP像跑车——延迟低（1-3秒）但对网络抖动敏感；FLV像货车——能适应各种路况（HTTP穿透性强）但默认需要5秒以上缓冲。

二、两大协议巅峰对决

| 维度 | RTMP | FLV over HTTP | |------------|-------------------|-------------------| | 延迟 | 1-3秒 | 5秒+ | | 防火墙穿透 | 常被拦截 | 畅通无阻 | | 压缩效率 | 较好 | 需额外优化 | | CDN支持 | 需要特殊节点 | 普通CDN即可 |

三、FFmpeg调优三连击

1. 关键帧对齐策略

ffmpeg -i input.mp4 \
  -c:v libx264 -g 60 -keyint_min 60 \  # 每2秒强制关键帧（假设30fps）
  -preset faster -crf 23 \
  -f flv rtmp://your_server/live/stream

-g参数是救命稻草，设置太小会增大体积，太大则影响seek。游戏直播建议30帧，带货直播可以60帧。

2. 动态分片传输

用Node.js实现的分片处理器：

const ffmpeg = require('fluent-ffmpeg');

function createHLS(input, outputDir) {
  ffmpeg(input)
    .outputOptions([
      '-hls_time 2',       // 每个切片2秒
      '-hls_list_size 5',  // 保持5个切片在列表
      '-hls_flags delete_segments' // 自动删除旧切片
    ])
    .output(`${outputDir}/playlist.m3u8`)
    .run();
}

3. CDN缓存预热

通过边缘节点预加载热门流的分片，首次播放速度提升40%。Nginx配置示例：

location /live {
  proxy_cache livestream;
  proxy_cache_valid 200 2s; # 只缓存2秒应对突发流量
  proxy_pass http://upstream;
}

四、性能提升看得见

某游戏直播优化前后对比：

| 指标 | 优化前 | 优化后 | |--------------|--------|--------| | 平均延迟 | 4.2s | 1.8s | | 带宽波动 | ±30% | ±12% | | 服务器负载 | 75% | 45% |

五、血泪教训备忘录

1. 时间戳跳变：用-use_wallclock_as_timestamps 1防止手机断网重连后音画不同步
2. 跨协议兼容：在FLV的onMetaData里添加videocodecid=7确保iOS浏览器兼容
3. 内存泄漏：FFmpeg进程要及时kill，特别是转码失败时

六、未来快递员QUIC

新一代QUIC协议就像装了火箭推进器的快递员，能实现： - 0-RTT快速重连 - 多路径传输（WiFi/4G同时发） - 前向纠错（丢包自动修复）

不过现在CDN支持度还不够高，你会考虑当第一个吃螃蟹的人吗？