挑战
传统的传输工作流程依赖于专用光纤或卫星链路，这既昂贵又缺乏灵活性：
- 专用线路每条每月成本数千美元，并且需要数周才能完成部署
- 基于互联网的传输 (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 输出可以是呼叫者（caller）或监听者（listener）模式
- 为每个合作伙伴设置独立的加密密码以进行访问控制
- 每个合作伙伴的带宽配置
- 每个输出的 SRT 指标，用于监测合作伙伴流的健康状况
SRT 配置
延迟调优
SRT 延迟根据网络条件和用例进行调优：
- 超低延迟 — 同区域、高质量网络（工作室到云）
- 低延迟 — 跨区域、良好网络
- 标准延迟 — 国际、可变网络
- 高弹性 — 较差网络，最大丢包容忍度
根据每个用例，优化设置包括适当的延迟、带宽限制、加密级别和连接模式（caller 与 listener）。
监控与告警
该平台实时监控 SRT 特定指标：
- 往返时间 (RTT) — 发送方和接收方之间的网络延迟
- 重传率 — 需要 ARQ 重传的数据包百分比
- 丢包率 — ARQ 之前的数据包丢失率，指示网络质量
- 抖动 — 数据包到达时间的变动
- 带宽利用率 — 实际带宽与配置的最大带宽对比
- 缓冲区级别 — 接收器缓冲区填充级别（underrun 表示可能出现卡顿）
当指标退化时，自动告警会触发，以便主动解决问题。
主要功能
- SRT 摄取 — 从任何联网源接收传输流
- AES 加密 — 内置内容加密，无需外部 VPN 或 TLS
- ARQ 恢复 — 自动重传，可容忍高达 20% 的丢包率
- 可配置延迟 — 根据网络质量和用例进行调优
- 双输入故障转移 — 在主 SRT 流故障时自动切换
- B2B 分发 — 用于合作伙伴分发的 SRT 输出流
- SRT 指标仪表板 — 实时 RTT、丢包、抖动和重传监控
- 混合输出 — SRT 用于 B2B 内容传输，HLS 通过 CloudFront 用于消费者交付
成果
技术栈
caseStudyDetail.more 案例研究
探索更多我们的技术实施案例
SCTE-35 广告标记信令与媒体预告片插入管道
一家流媒体公司需要一个强大、自动化的管道，用于将 SCTE-35 广告标记注入直播和 VOD 流中，并能将宣传预告片（前贴片、中贴片和后贴片）精确地插入指定位置——从而实现跨 FAST 频道、直播活动和点播内容库的变现。
AWS Media Services 用于基于 HLS 的 FAST 频道流媒体
一家媒体公司需要推出免费广告支持的流媒体电视 (FAST) 频道——24/7 全天候的精选视频内容线性流，通过 HLS 传输到智能电视、机顶盒和网络/移动播放器，并通过程序化广告插入实现盈利。
常见问题
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小时。