背景痛点

在4K/8K超高清直播成为主流的今天，传统RTMP+H264方案面临巨大挑战。H264编码在同等画质下需要占用约2倍的带宽，而RTMP协议原生仅支持H264的AVC格式。H265（HEVC）虽能节省50%带宽，但直接通过RTMP传输会出现以下问题：

• 协议不兼容：标准RTMP的flv tag未定义HEVC的fourcc标识
• 播放器支持差：主流Flash播放器无法解析H265帧数据
• CDN转发失效：未改造的RTMP边缘节点会丢弃未知视频类型包

技术方案选型

协议支持对比

| 协议 | H265支持度 | 延迟 | 适用场景 | |---------|------------|--------|-------------------| | RTMP | 需扩展 | 1-3s | 传统直播推流 | | FLV over HTTP | 部分支持 | 3-5s | 点播回放 | | WebRTC | 原生支持 | <1s | 实时通信 | | DASH | 完全支持 | 5s+ | 自适应码率 |

决策树建议

1. 若需兼容旧设备 → 选择RTMP扩展方案
2. 若追求超低延迟 → WebRTC+H265
3. 若需要多码率适配 → DASH/HLS+HEVC

核心实现

FFmpeg编码优化

关键参数示例（完整命令行需包含错误处理）：

ffmpeg -i input.mp4 \
  -c:v libx265 \
  -x265-params \
    "keyint=60:min-keyint=30:bframes=3:b-adapt=1:crf=23" \
  -preset fast \
  -f flv \
  -flvflags no_duration_filesize \
  rtmp://example.com/live/stream

参数说明：

• keyint=60：每60帧强制IDR帧
• bframes=3：使用3个B帧提升压缩率
• crf=23：恒定质量模式（18-28为推荐范围）

RTMP协议扩展

C++伪代码示例（需实际实现内存回收）：

// 封装HEVC帧到RTMP包
void SendHEVCFrame(RTMPPacket* pkt, uint8_t* data, int size, uint32_t dts) {
  pkt->m_body = new char[size + 5];
  // 自定义HEVC标识头
  pkt->m_body[0] = 'H';
  pkt->m_body[1] = 'V';
  pkt->m_body[2] = 'C';
  pkt->m_body[3] = 1; // version
  pkt->m_body[4] = (dts >> 24) & 0xFF; // DTS高位
  memcpy(pkt->m_body+5, data, size);

  try {
    RTMP_SendPacket(pkt);
  } catch (...) {
    delete[] pkt->m_body; // 异常时释放内存
    throw;
  }
}

性能验证

测试环境：1080p@30fps直播流

| 编码格式 | 码率(Mbps) | CPU占用 | 延迟 | |----------|------------|---------|--------| | H264 | 4.2 | 35% | 1.8s | | H265 | 2.1 | 55% | 2.1s |

避坑指南

CDN兼容性检查

1. 使用Wireshark抓包查看RTMP的onMetadata事件
2. 检查videocodecid字段是否为0x0C（HEVC标识）
3. 测试边缘节点是否能转发大于1280字节的视频包

iOS B帧处理

# 禁用B帧避免Safari解码失败
-x265-params "bframes=0:no-open-gop=1"

开放讨论

H265编码耗时显著高于H264，在游戏直播等实时场景中，如何平衡以下因素：

• 编码速度（preset参数）
• 画质（CRF值）
• 硬件加速（QSV/NVENC）

欢迎在评论区分享你的优化策略！