挑战
传统的贡献工作流依赖于专用光纤或卫星链路，这些链路既昂贵又不灵活：
- 专用电路每条链路每月花费数千美元，并需数周时间来配置
- 基于互联网的传输（RTMP）存在数据包丢失、抖动且缺乏加密
- 多源采集需要灵活的软件定义连接
- SRT 的错误校正和加密使其成为新兴的广播标准，但将其集成到 AWS 原生管道中需要定制工程
- 监控 SRT 特定指标（RTT、重传率、带宽开销）需要专用工具
我们的解决方案
我们使用 AWS Elemental MediaLive 和 MediaConnect 构建了一个基于 SRT 的贡献和分发管道，实现了通过公共互联网进行可靠、加密的内容传输，并具备广播级错误校正。
架构
- 贡献：AWS Elemental MediaConnect 用于从远程源进行 SRT 采集
- 传输：SRT 协议，结合 AES 加密和 ARQ 错误校正
- 编码：AWS Elemental MediaLive 用于将 SRT 输入转码为多比特率输出
- 打包：AWS Elemental MediaPackage 用于 HLS/DASH 打包以供终端观众交付
- 分发：来自 MediaConnect 的 SRT 输出用于 B2B 平台合作伙伴的分发
- 监控：SRT 特定指标仪表板（RTT、数据包丢失、重传、抖动）
- CDN：Amazon CloudFront 用于最后一公里的 HLS 交付给终端观众
SRT 协议优势
与 RTMP 相比
SRT 在贡献源流方面相较 RTMP 具有显著优势：内置 ARQ 错误校正（可容忍高达 20% 的数据包丢失，而 RTMP 在 1-2% 时流中断）、原生 AES 加密、可配置的延迟控制、基于 UDP 的 NAT 友好传输，以及用于错误恢复的最小带宽开销。
与专用电路相比
通过互联网的 SRT 提供了显著更低的成本和更快的配置速度，相较于专用光纤——并具有多路径冗余和从任何互联网连接位置的地理灵活性。
管道设计
贡献（采集）
- 远程源——工作室、云播出或合作伙伴将 SRT 流发送至 MediaConnect
- SRT 监听器——将 MediaConnect 端点配置为 SRT 监听器
- 加密——AES 密码加密以确保传输中的内容安全
- 错误校正——ARQ 使用可配置的延迟缓冲区恢复丢失的数据包
- 故障切换——双 SRT 输入，主流故障时自动故障切换
处理
- MediaConnect → MediaLive——SRT 流传输至 MediaLive 进行转码
- 转码——多比特率编码，支持 SCTE-35 透传
- SCTE-35 注入——在预定点插入广告中断信号
- 输出——转码流发送至 MediaPackage 进行 HLS 打包
分发（通过 SRT 进行 B2B 分发）
对于需要广播级源流的合作伙伴平台分发：
- 根据合作伙伴要求，SRT 输出以呼叫者或监听器模式
- 每个合作伙伴使用单独的加密密码短语进行访问控制
- 每个合作伙伴的带宽配置
- 每个输出的 SRT 指标用于合作伙伴源流健康监控
SRT 配置
延迟调优
SRT 延迟根据网络条件和使用场景进行调优：
- 超低——同一区域，高质量网络（工作室到云）
- 低——跨区域，良好网络
- 标准——国际，网络可变
- 高弹性——差网络，最大数据包丢失容忍度
根据使用场景优化设置，适当的延迟、带宽限制、加密级别和连接模式（呼叫者 vs. 监听器）。
监控与警报
平台实时监控 SRT 特定指标：
- 往返时间（RTT）——发送方和接收方之间的网络延迟
- 重传率——需要 ARQ 重传的数据包百分比
- 数据包丢失——ARQ 前的数据包丢失率，指示网络质量
- 抖动——数据包到达时间的变化
- 带宽利用率——实际 vs. 配置的最大带宽
- 缓冲级别——接收缓冲区填充级别（欠载表示潜在卡顿）
自动警报在指标恶化时触发，以主动解决问题。
关键特性
- SRT 采集——从任何互联网连接源接收贡献源流
- AES 加密——内置内容加密，无需外部 VPN 或 TLS
- ARQ 恢复——容忍高达 20% 的数据包丢失，自动重传
- 可配置延迟——根据网络质量和使用场景进行调节
- 双输入故障切换——主 SRT 源流故障时自动切换
- B2B 分发——用于合作伙伴分发的 SRT 输出源流
- SRT 指标仪表板——实时 RTT、丢失、抖动和重传监控
- 混合输出——用于 B2B 贡献的 SRT，通过 CloudFront 的 HLS 进行消费者交付
成果
技术栈
caseStudyDetail.more 案例研究
探索更多我们的技术实施案例
常见问题
MicrocosmWorks 选择 SRT 是因为它在不可靠网络上的卓越性能，提供了 RTMP 所缺乏的 AES-128 加密、自动丢包重传以及自适应比特率调整。SRT 即使在公共互联网路径上也能保持广播级视频传输质量，且丢包恢复开销低于 1%，而 RTMP 在同样情况下则会显示可见的伪影。
MicrocosmWorks 配置了 AWS Elemental MediaLive，使其在呼叫者和监听者两种模式下接受 SRT 输入，然后转码为 ABR 码率阶梯，并将 HLS/DASH 片段输出到 MediaPackage。SRT 摄取得益于 MediaLive 内置的 SRT 解密和抖动缓冲区，确保在转码阶段之前源质量清晰。
是的，MicrocosmWorks 配置了 MediaLive，使其具有多个 SRT 输入源，并构建了一个路由控制平面，该平面可以根据预定义的时间表或手动覆盖来切换传输流。每个 SRT 贡献者通过唯一的监听端口连接，带有独立的 AES 密码认证，并且系统支持 primary 和 backup SRT 源之间的 hot-standby failover。
MicrocosmWorks 使用 CloudWatch 自定义指标构建了一个监控仪表板，该仪表板摄取 SRT 统计数据，包括往返时间、重传率、带宽利用率和缓冲级别。当重传率超过 2% 或 RTT 超过 200 毫秒时，自动化警报会触发，在质量下降对观众可见之前，为运营团队提供早期预警。
MicrocosmWorks以每小时$30-$50的费率部署基于SRT的FAST频道基础设施，完整的设置包括SRT摄取配置、MediaLive编码、CDN交付和监控仪表板，通常需要200-350个开发小时。与标准RTMP摄取设置相比，SRT特定配置大约额外增加40-60小时。