保姆级教程：手把手教你修改FFmpeg源码，让ffplay也能播H265的RTMP直播流
从零实现FFmpeg源码改造：为ffplay添加H265 RTMP直播流支持
第一次在项目中遇到H265编码的RTMP直播流需求时，我像大多数开发者一样，本能地打开终端输入ffplay rtmp://example.com/live/stream，结果只看到一片报错信息。这让我意识到，标准FFmpeg套件对H265 RTMP的支持并非开箱即用——而解决这个问题的钥匙，就藏在FFmpeg的源码深处。
1. 问题诊断与环境准备
当ffplay遇到H265 RTMP流时，通常会抛出两类关键错误：
[flv @ 0x7f8f5c000800] Video codec not foundCould not find codec parameters for stream 0
这些错误直接指向FLV解复用器（demuxer）的问题根源。通过ffprobe分析流信息可以确认，问题出在FLV容器格式对H265编码的识别上：
ffprobe -i rtmp://example.com/live/stream -show_streams环境准备清单：
- FFmpeg源码（建议4.3以上版本）
- 支持H265的RTMP服务器环境（如SRS或Nginx-rtmp）
- 基础编译工具链（gcc/make/yasm等）
- 代码编辑器（VSCode或CLion等具备代码跳转功能的IDE）
提示：建议在修改前先完整编译一次原始代码，确保基础环境正常。编译命令通常为：
./configure --enable-shared --enable-gpl && make -j8
2. FLV协议与H265的兼容性解析
FLV格式的视频标签(Video Tag)结构决定了其对编码类型的支持能力。关键数据结构如下：
| 字段偏移 | 长度 | 说明 |
|---|---|---|
| 0x09 | 4bit | CodecID (0-15) |
| 0x09 | 4bit | FrameType (关键帧/非关键帧) |
现有CodecID分配情况：
- 2: Sorenson H.263
- 3: Screen video
- 4: On2 VP6
- 5: On2 VP6 with alpha
- 6: Screen video v2
- 7: AVC/H.264
- 12: HEVC/H.265 (行业共识)
协议限制的根本原因：
- FLV规范制定时(2003年)尚未出现H265标准
- Adobe官方已停止更新FLV规范
- 国内直播平台通过约定俗成使用CodecID=12表示HEVC
3. 源码修改实战
3.1 关键代码定位
修改的核心文件是libavformat/flvdec.c，这是FLV解复用器的实现。我们需要重点关注三个函数：
flv_same_video_codec()- 编码格式验证flv_set_video_codec()- 编码类型映射flv_read_packet()- 数据包处理
使用IDE的代码跳转功能（如VSCode的Go to Definition）可以快速定位这些关键函数。
3.2 枚举值添加
在flvdec.c开头部分找到视频编码类型定义，添加HEVC支持：
enum { FLV_CODECID_H263 = 2, FLV_CODECID_SCREEN = 3, FLV_CODECID_VP6 = 4, FLV_CODECID_VP6A = 5, FLV_CODECID_SCREEN2 = 6, FLV_CODECID_H264 = 7, FLV_CODECID_HEVC = 12, // 新增行 };3.3 核心逻辑修改
在flv_set_video_codec()函数中添加HEVC处理分支：
static void flv_set_video_codec(...) { switch(flv_codecid) { case FLV_CODECID_H264: *codec_id = AV_CODEC_ID_H264; break; case FLV_CODECID_HEVC: // 新增case *codec_id = AV_CODEC_ID_HEVC; *need_parsing = AVSTREAM_PARSE_FULL_RAW; ret = 3; break; // ...其他case保持不变 } }同样需要在flv_same_video_codec()中添加对应逻辑：
static int flv_same_video_codec(...) { if (st->codecpar->codec_id == AV_CODEC_ID_HEVC) // 新增判断 return flv_codecid == FLV_CODECID_HEVC; // ...原有逻辑 }3.4 辅助修改点
在文件内全局搜索AV_CODEC_ID_H264，在所有相关位置添加HEVC的并行处理。典型位置包括：
- 流信息解析部分（约1288行）
- 数据包处理逻辑（约1239行）
- 元数据处理（约1256行）
4. 编译验证与调试
完成修改后，执行增量编译：
make -j8 && sudo make install验证修改效果的实用命令组合：
# 基础播放测试 ffplay -i rtmp://example.com/live/stream # 带详细日志的输出 ffplay -loglevel debug -i rtmp://example.com/live/stream # 检查实际使用的解码器 ffprobe -show_frames -select_streams v rtmp://example.com/live/stream | grep codec_name常见问题排查：
- 如果播放时出现
No pixel format specified警告，尝试指定像素格式：ffplay -pix_fmt yuv420p -i rtmp://example.com/live/stream - 遇到解码延迟，可以调整缓冲区大小：
ffplay -fflags nobuffer -flags low_delay -i rtmp://example.com/live/stream
5. 进阶优化方向
对于需要深度定制的情况，还可以考虑以下增强点：
协议扩展支持：
- 修改
libavformat/rtmpproto.c优化RTMP握手过程 - 调整
libavformat/flvenc.c添加H265封装支持
- 修改
性能调优参数：
// 在flvdec.c中调整 #define FLV_MAX_QUEUE_SIZE 1024 // 增大包队列缓存 #define FLV_VIDEO_PACKET_TIMEOUT 10000 // 超时控制(ms)硬件加速集成：
./configure --enable-cuvid --enable-nvenc --enable-libmfx
实际项目中，我曾遇到一个需要同时支持H265 RTMP和SRT协议的需求。通过类似的本土化修改，最终实现了低于500ms的端到端延迟，这在4K HDR直播场景中表现尤为突出。