挑战
传统的贡献工作流程依赖于专用的光纤或卫星链路,这些链路昂贵且缺乏灵活性:
- 专用线路每月每条成本数千,配置需要数周时间
- 基于互联网的传输 (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 输入,在主 SRT 流故障时自动故障转移
处理
- MediaConnect → MediaLive — SRT 流传输到 MediaLive 进行转码
- 转码 — 带有 SCTE-35 直通的多码率编码
- SCTE-35 注入 — 在预定点插入广告中断信号
- 输出 — 转码流发送到 MediaPackage 进行 HLS 封装
分发(通过 SRT 进行 B2B 联合发行)
为了向需要广播级源的平台合作伙伴进行联合发行:
- 根据合作伙伴要求,以呼叫者或监听者模式输出 SRT
- 每个合作伙伴独立的加密密码短语,用于访问控制
- 每个合作伙伴的带宽配置
- 每个输出的 SRT 指标,用于合作伙伴源健康监测
SRT 配置
延迟调整
SRT 延迟根据网络条件和用例进行调整:
- 超低延迟 — 同区域、高质量网络(工作室到云)
- 低延迟 — 跨区域、良好网络
- 标准延迟 — 国际、可变网络
- 高弹性 — 差网络,最大丢包容忍度
设置根据具体用例进行优化,包括适当的延迟、带宽限制、加密级别和连接模式(呼叫者 vs. 监听者)。
监控与告警
该平台实时监控 SRT 特定指标:
- 往返时间 (RTT) — 发送方和接收方之间的网络延迟
- 重传率 — 需要 ARQ 重传的数据包百分比
- 丢包率 — ARQ 前的丢包率,指示网络质量
- 抖动 — 数据包到达时间的变异
- 带宽利用率 — 实际带宽与配置的最大带宽对比
- 缓冲区水平 — 接收方缓冲区填充水平(欠载表示可能出现卡顿)
当指标恶化时,会自动触发告警,以便主动解决问题。
主要特性
- SRT 摄取 — 从任何互联网连接的源接收贡献源
- AES 加密 — 内置内容加密,无需外部 VPN 或 TLS
- ARQ 恢复 — 自动重传,可容忍高达 20% 的丢包
- 可配置延迟 — 可根据网络质量和用例进行调整
- 双输入故障转移 — 在主 SRT 源故障时自动切换
- B2B 联合发行 — 用于合作伙伴分发的 SRT 输出源
- SRT 指标仪表板 — 实时 RTT、丢包、抖动和重传监控
- 混合输出 — SRT 用于 B2B 贡献,通过 CloudFront 的 HLS 用于消费者交付
成果
技术栈
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小时。
