跳转到主要内容
C SDK 不做采集也不做编码。推流的完整链路是:业务方采集 → 业务方编码 → rtc_write_sample 喂裸数据 → SDK 打包发送。 标准流程:

rtc_create_local_track

创建一条本地轨道,返回轨道句柄;失败返回 NULL。 轨道是音频还是视频由 codec 决定,不需要额外指定。

rtc_destroy_local_track

销毁本地轨道。已发布的轨道应先 rtc_unpublish_local_track 再销毁。 0.0.11 起会先摘掉关键帧请求回调,并等正在执行的关键帧回调返回后才返回,之后可以安全释放传给 rtc_set_keyframe_request_callback 的 context。0.0.10 及更早版本销毁轨道后仍可能触发关键帧回调。

rtc_publish_local_track

发布本地轨道到频道。 发布选项 rtc_publish_options_t
props 解析失败时 SDK 只打一条告警日志、按无自定义属性继续发布,不会让发布失败。
返回值

rtc_unpublish_local_track

取消发布。返回值同上。

rtc_publish_mcu_video_track / rtc_publish_mcu_audio_track

发布频道级合成流,见 合成流(program)。

rtc_write_sample

向已发布的轨道推送一帧编码数据。 samples 按各编码的时钟频率算: 返回值
SDK 会拷贝一份传入的数据,调用返回后你可以立即复用或释放 data 缓冲区。
SDK 不控制发送节奏,写入一帧就立即发出。数据源比实时快时(读文件、TTS 合成),必须由你按帧时长的节奏写入(如音频每 20ms 写一包),否则一瞬间发出几秒的数据,对端的抖动缓冲装不下就会丢,听起来是吞字或加速。

rtc_set_keyframe_request_callback

设置关键帧请求回调。当 SFU 通过 RTCP(PLI / FIR)要求这条轨道立即产出关键帧时触发,业务方应在回调里让编码器立刻编一个 IDR 并通过 rtc_write_sample 发出去。
必须在发布之前对该轨道设置。 不设置的话,新加入的观众要等到编码器下一个自然 GOP 才出画面 —— GOP 长的话就是几秒钟黑屏。回调在独立线程触发,注意与编码线程的同步。传 NULL 可清除回调。

完整示例


C 接口不支持发布 simulcast 多层流 —— 服务端场景(录制 / MCU / AI Agent)几乎不需要主动发多层。订阅侧的多层自动切换由 SDK 自动完成,无需任何配置。确有发多层的需求请联系我们。