OBS
RTMP / SRT让平台处理路由、协议转换和一对多分发，让源端编码器只负责发送一条干净稳定的贡献流。
交付
接入与路由
将一个经过验证的贡献源引入 Callaba，然后为每个目的地创建一个单独的 Restream 作业。每个作业都有自己的目标设置和运行时状态；录制、网络播放器和恢复是您在需要时添加的独立工作流程。
在 AWS 上部署 Callaba把一路接入变成多个输出
接受一次贡献源，然后为每个社交平台、合作伙伴端点或其他目的地创建单独的 Restream 作业。
每个 Restream 作业都有自己的目标设置和运行时状态。独立审查每个输出，以便每个目的地都有自己明确的操作证据。
YouTube
RTMP · 独立输出任务 01
RTMP · 独立输出任务 02
交互式工作流模型 · 状态示例只有这个目标会变化；另外两个仍会继续运行。已接收的输入由各任务共享，同时每个目标端分别报告自己的运行状态。
工作流
把目标分发逻辑掌握在自己手里
即使所有目标端都使用同一个源，也应将每个发布渠道视为独立的交付约定。
把一路接入变成多个输出
为每个目标端创建独立输出任务，使凭据、限制和故障彼此隔离。
刻意准备路线
在直播节目需要备用端点之前，就应完成记录和测试。
将录制或播放添加为单独的工作流程
将录制或浏览器播放作为独立任务连接到已接收的源，并分别检查。
现在把它投入使用
在 Callaba 中完成配置，再验证交接
本页说明产品的能力边界。以下指南会告诉您要打开哪些控制项、接下来连接哪个模块，以及如何确认工作流已经就绪。
技术规格
我可以把一路源信号路由到多个目标吗？
使用此约定确认摄取阶段共享哪些内容，以及每个输出需要单独验证哪些内容。
| 功能 | 支持的行为 | 验收检查 |
|---|---|---|
| 把一路接入变成多个输出 | 一份已验证的源流可以供多个独立配置的 Restream 任务使用。 | 输入只需确认一次，然后观察每个目标任务是否分别进入直播状态。 |
| 把目标分发逻辑掌握在自己手里 | 端点 URL、凭据、媒体要求和重试行为都属于各自的输出任务。 | 分别打开每个任务，并在对应目标端确认其直播状态。 |
| 把重活从编码器上移走 | 源编码器只发布一份干净的源流，由 Callaba 完成后续分发。 | 将编码器的上传状态与每个已创建输出的状态进行对照，而不是让源端重复推流。 |
| 使用跨目的地的路由灵活性 | 云端适合快速验证工作流；需要控制网络和数据驻留位置时，可选择自托管基础设施。 | 在将路由用于生产前，先在所选环境中使用真实源和目标端完成测试。 |
工作流
根据运营需求选择云端或自托管
使用云快速验证真实来源和目的地。当您需要基础设施、网络或数据位置控制时，请选择自托管，然后在部署后重新验证工作流程。
在 AWS 上部署 Callaba
按量付费的云端方案适合希望获得云端优势的团队：快速部署、全球低延迟、可靠基础设施、备份、弹性扩展以及托管运维。
在 AWS 上部署 Callaba安装自托管 Callaba
对多个业务目标使用一个贡献输入，并为每个平台或合作伙伴端点提供明确的目标设置。
安装自托管 CallabaAPI
多路分发 REST API路线工作后自动执行独立输出作业
每个目的地都是其自己的 Restream 作业。在您的团队在 Callaba 中验证源、目标和媒体配置文件后，使用 API 创建、启动和检查作业。
常见问题
这里说的“接入与路由”具体指什么？
意思是先把一路直播输入接入一个受控入口点，再决定这路信号接下来如何移动：发送到社交平台、合作方终点、播放器，或其他工作流模块。
团队什么时候会选它，而不是直接从 OBS 发布？
当一路源信号需要送往多个目标、备份路径很重要，或团队希望把路由逻辑放进受控工作流而不是塞进编码器配置里时，通常会选择这一层。
我可以把一路源信号路由到多个目标吗？
是的。 Callaba 接受源一次，然后您为每个目标创建一个独立的 Restream 作业。单独配置和检查每个作业。
每增加一个目标，我都需要更多上行带宽吗？
如果工作流设计正确，编码器侧通常不需要。源端一般只需发送一条受控贡献流，平台会处理下游的一对多分发。
我可以把 SRT 用作贡献输入吗？
可以。当网络条件、贡献质量或接收侧基础设施可控性很重要时，SRT 是很常见的接入选择。
这是更偏 API 还是更偏控制台？
在控制界面中启动以验证源、目标和配置文件。然后使用 API 创建、启动和检查每个独立的 Restream 作业。
文档应该从哪里开始看？
如果第一个问题是“信号从哪里进入”，就先看 SRT 服务器；然后继续看 SRT 路由 和 Restreams 转发，定义这条流如何移动。
交付
使用跨目的地的路由灵活性
先用当前需要的目标端验证一路源流，再按需添加独立的录制或播放任务。