macOS 上 RTMP 推拉流实践

一、为什么还要做 RTMP

RTMP 在传统直播与推流接入里仍有现实价值：协议成熟、工具链丰富、与 SRS/ZLMediaKit 等服务端对接成本低。对工程侧来说，掌握 RTMP 的打包与收发细节，能快速搭出稳定的推流入口，再衔接转码、录制与分发。

二、工程关注点

• 封装解析：FLV tag 的音视频负载拆解与重组。
• 发送链路：H.264、AAC 或 FLV 整体推送到 RTMP 服务器。
• 接收链路：从 RTMP 拉流并提取 AVC/AAC，供后续处理。
• 格式转换实验：FLV 到 TS/PS/fMP4 等中间格式验证。

三、最小联调闭环

按下面顺序走，基本都能定位到“是推流问题还是服务端问题”。

1. 本地或远端部署流媒体服务（SRS / ZLMediaKit 等）。
2. 发送端推流到指定 rtmp:// 地址。
3. 接收端或播放器验证拉流、音视频同步与关键帧恢复。
4. 出现异常时，通过二进制检查与日志对照定位封装问题。

# 1) 构建
git clone https://github.com/cgeffect/rtmp_macos.git
cd rtmp_macos
./build.sh   # 或 cmake 构建

# 2) 启动 SRS/ZLMediaKit（示例地址）
# rtmp://127.0.0.1/live/test

# 3) 发送端推流（按项目可执行名调整）
./src/send_flv

# 4) 播放器拉流验证
ffplay rtmp://127.0.0.1/live/test

# 5) 如需拆流调试
./src/recv_flv

实际调试时，先用最简单的一路视频跑通，再加音频，再做 FLV 到 TS/PS/fMP4 的转换实验，问题会更好定位。

四、常见问题与排障思路

• 推得上去但播不出来：优先检查 FLV tag 类型、关键帧与 SPS/PPS 是否正确。
• 有画无声/有声无画：检查音视频时间戳与编码参数是否匹配。
• 间歇卡顿：看发送速率与服务端缓冲策略，确认是否有突发阻塞。
• 容器转换异常：先做 hexdump 与帧级解析，明确错误发生在封装还是编码层。

hexdump -C ../res/wubai.aac | head -20

五、与 RTP 路线如何分工

在同一套音视频系统里，RTMP 常用于推流接入与传统直播链路；RTP/RTSP 更偏实时交互与低延迟传输。两条路线并不冲突，关键是统一编解码参数、 时间基与观测指标，避免系统边界处反复补锅。

六、工程化建议

• 把推流地址、鉴权、重连策略做成配置项，不写死在代码里。
• 统一输出发送/接收统计（码率、帧率、关键帧间隔、重连次数）。
• 将常见协议转换与解析流程做成独立工具，便于离线排障。