【音视频】RTMP 直播推流实战
内容提要
本文介绍用Claude Code开发生产级RTMP推流器，涵盖C核心层与iOS/Android封装。核心功能包括自适应码率（根据网络拥塞动态调整）、断线重连（指数退避）、音视频交错复用、静音检测省带宽。通过实战案例展示卡顿排查，并对比基础与生产级方案在弱网、断线恢复、带宽节省等方面的显著提升。
延伸解读
生产级推流器的核心挑战
文章指出，RTMP推流看似简单，但生产级推流器需处理弱网卡顿、断线重连、音视频交错、静音检测等边缘情况。这些功能并非FFmpeg默认提供，需要开发者自行实现。例如，自适应码率需根据网络拥塞动态调整，断线重连需指数退避策略，静音检测可节省带宽。这些细节决定了推流质量，是基础方案与生产级方案的主要区别。
自适应码率与断线重连的实践
文章通过实战案例展示了自适应码率的重要性：重连后码率恢复过快会导致二次拥塞。解决方案是重连后从较低码率开始，并采用AIMD算法调整。此外，断线重连需注意TCP keepalive设置和重连后重新创建AVFormatContext，避免重复写FLV header。这些经验对实际开发具有直接参考价值。
静音检测与带宽节省
静音检测通过计算PCM能量判断是否发送音频帧，可节省30%以上上行带宽。但需注意跳帧后PTS的连续性，否则会导致播放端音视频不同步。文章建议跳帧时仍累计时间戳，避免PTS跳跃。这一细节体现了生产级推流器对用户体验的细致考量。
Q&A
RTMP推流器有哪些核心功能？
RTMP推流器的核心功能包括自适应码率、断线重连、音视频交错复用、静音检测和弱网指示。自适应码率根据网络状况动态调整视频码率，断线重连采用指数退避策略，音视频交错复用确保音视频同步，静音检测在主播不说话时跳过音频帧以节省带宽，弱网指示对外暴露网络状态回调。
如何实现自适应码率？
自适应码率通过监控网络质量（如连续丢帧数）来调整视频码率。网络良好时逐步上调码率（每次增加10%），轻度拥塞时降至70%并跳帧（每2帧发1帧），严重拥塞时降至40%并只发关键帧。调整每2秒进行一次，且码率被限制在最小和最大码率之间。
断线重连的指数退避策略是怎样的？
断线重连采用指数退避策略，重连延迟按1秒、2秒、4秒、8秒、16秒递增，最多尝试5次。每次重连前会等待相应的延迟时间，重连成功后重置尝试次数。重连时需重新创建AVFormatContext，并重新发送SPS/PPS。
静音检测是如何节省带宽的？
静音检测通过计算PCM音频帧的能量（绝对值均值），当能量低于阈值（如100）且静音持续时间超过设定值（如5秒）时，跳过该音频帧不发送，从而节省上行带宽。在主播不说话时，可节省约30%的带宽。
音视频交错复用有什么作用？
音视频交错复用是指音频和视频帧交替发送，避免先发完视频再发音频导致播放器缓存溢出和音视频不同步的问题。通过交错发送，确保播放器能及时获取音视频数据，维持同步。
生产级推流器相比基础推流有哪些提升？
生产级推流器相比基础推流在弱网下画面质量从完全花屏提升为模糊但可看（低码率），断线恢复从手动重启变为自动重连（3-8秒），静音带宽节省从0提升到30%以上，首帧延迟从3-5秒降低到1-2秒，码率利用率从60-80%提升到85-95%。
直播卡顿排查中常见的重连码率恢复过快问题如何解决？
重连后码率直接跳到初始值（如3000 kbps）会导致二次拥塞。解决方案是重连后从min(上次码率*1.5, 目标码率*0.5)开始，并使用AIMD（加法增大乘法减小）算法替代比例调整，避免码率恢复过快。
RTMP推流中常见的踩坑问题有哪些？
常见问题包括：推流2小时后断开不重连（TCP keepalive未设置，需设置AVIOInterruptCB和定期发送RTMP PING）；重连时FLV header写了两次（需重新创建AVFormatContext）；静音检测丢帧后音频PTS跳跃导致A/V不同步（跳帧时仍累计时间）；RTMP URL含中文导致DNS解析失败（需做percent encoding）。
