最近做项目遇到一个刚需：用 TRTC 做了实时连麦互动，但大量普通观众没法装专门的客户端，只能用 H5 或者常规直播播放器看。翻了一圈文档踩了不少坑，终于把 TRTC 房间里的音视频流无缝转推到直播 CDN 上了，今天把完整流程和避坑指南整理出来，给有同样需求的朋友参考。
一、先搞懂：为什么要做转推？
TRTC 本身是为低延迟实时互动设计的，用的是私有 UDP 协议，延迟能做到 100ms 以内，但缺点是只能用 TRTC SDK 播放。而直播 CDN 用的是 RTMP/HLS/FLV 这些标准协议，几乎所有浏览器、播放器都支持，能轻松支撑几十万甚至上百万观众同时观看。
转推（也叫旁路直播）就是在 TRTC 房间和直播 CDN 之间架一座桥：把房间里的某一路或多路音视频流，实时转换成标准直播流推送到 CDN，这样普通观众不用装任何插件，打开链接就能看。
二、两种转推方式怎么选？
TRTC 提供了两种转推方案，我都试过，给大家做个直观对比：
方案 实现方式 优点 缺点 适用场景
服务端转推 调用 TRTC 云服务 API 发起转推 客户端无压力，转推稳定，支持混流 成本略高，配置稍复杂 大多数生产环境，需要混流的场景
客户端转推 本地 SDK 采集编码后同时推两路流（一路给 TRTC，一路给 CDN） 成本低，配置简单，延迟更低 占用客户端带宽和算力，不稳定 临时测试，单主播无连麦的简单场景
个人建议：生产环境优先用服务端转推。虽然多了一点云服务成本，但稳定性和可维护性高太多，尤其是有多人连麦需要混流的场景，服务端混流是唯一靠谱的选择。
三、服务端转推核心步骤（5 分钟搞定）
我用的是服务端转推方案，核心其实就三步，官方文档写得有点绕，我提炼成最精简的流程： 1. 提前准备好两个东西
一个可用的直播 CDN 推流地址（RTMP 格式，比如 rtmp://xxx.livepush.myqcloud.com/live/stream1?txSecret=xxx&txTime=xxx）
你的 TRTC 应用 ID 和 API 密钥（在控制台就能拿到） 2. 调用 TRTC 云 API 发起转推
核心是调用 StartPublishCdnStream 接口，只需要填几个关键参数：
PublisherId 随便填一个唯一标识就行，用来区分不同的转推任务
CdnUrls 支持同时推到多个 CDN 地址，做多 CDN 备份
StreamParams 建议和 TRTC 房间里的编码参数保持一致，避免二次编码增加延迟 3. 测试播放
调用成功后，等个 2-3 秒，用你的 CDN 播放地址（HLS 或 FLV 格式）在 VLC 播放器或者浏览器里测试，能正常看到画面和声音就成功了。
如果要停止转推，调用 StopPublishCdnStream 接口，传入对应的 TaskId 就行。
四、我踩过的 5 个大坑（官方文档没写清楚）
这部分是重点，我花了两天时间踩的坑，大家直接避开：
转推地址必须是 RTMP 格式
很多人一开始会用 HLS 地址去推，肯定会失败。TRTC 只支持推 RTMP 流到 CDN，播放的时候再用 HLS/FLV 地址。
音视频编码参数不兼容会导致黑屏 / 无声
视频必须是 H.264 编码，音频必须是 AAC 编码。如果 TRTC 房间里有人用了其他编码，转推出来的流就会有问题。建议在进房的时候强制指定编码格式。
转推延迟过高的问题
默认配置下转推延迟大概在 3-5 秒，如果觉得太高，可以把 CDN 的 GOP 大小改成 1-2 秒，同时关闭 B 帧。我调整后延迟能降到 1.5 秒左右，完全满足大多数直播场景。
混流转推的布局坑
如果要把多个连麦用户的画面混在一起推出去，一定要注意布局坐标的计算。TRTC 的混流布局是左上角为原点，单位是像素，不要用百分比，否则不同分辨率下会出现画面错位。
转推中断后的自动重连
官方 API 没有自动重连机制，需要自己在服务端做心跳检测。我是每隔 10 秒调用 DescribePublishCdnStreams 接口查询转推状态，如果发现任务异常，就自动重新发起转推。
五、最后说几句
整体用下来，TRTC 的转推功能还是挺靠谱的，解决了我们实时互动 + 大规模直播的核心需求。之前也试过自己搭转推服务，稳定性和延迟都不如官方的方案。
唯一要注意的是成本问题，服务端转推是按转推时长收费的，不用的时候一定要及时停止任务，不然会产生不必要的费用。
如果大家在实现过程中遇到什么问题，欢迎在评论区交流，我会尽量回复。