挑战
传统的贡献工作流程依赖于专用的光纤或卫星链路，这些链路昂贵且缺乏灵活性：
- 专用线路每月每条成本数千，配置需要数周时间
- 基于互联网的传输 (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 selected SRT for its superior performance over unreliable networks, providing AES-128 encryption, automatic packet retransmission, and adaptive bitrate adjustment that RTMP lacks. SRT maintains broadcast-quality video delivery with less than 1% packet loss recovery overhead even over public internet paths where RTMP would show visible artifacts.
MicrocosmWorks configured AWS Elemental MediaLive to accept SRT inputs in both caller and listener modes, then transcode to an ABR ladder and output HLS/DASH segments to MediaPackage. The SRT ingest benefits from MediaLive's built-in SRT decryption and jitter buffer, ensuring clean source quality before the transcoding stage.
Yes, MicrocosmWorks configured MediaLive with multiple SRT input sources and built a routing control plane that switches between feeds based on a predefined schedule or manual override. Each SRT contributor connects via a unique listener port with individual AES passphrase authentication, and the system supports hot-standby failover between primary and backup SRT sources.
MicrocosmWorks built a monitoring dashboard using CloudWatch custom metrics that ingests SRT statistics including round-trip time, retransmission rate, bandwidth utilization, and buffer levels. Automated alerts trigger when retransmission rates exceed 2% or RTT exceeds 200ms, giving operations teams early warning before quality degradation becomes visible to viewers.
MicrocosmWorks deploys SRT-based FAST channel infrastructure at rates of $30-$50/hr, with the complete setup including SRT ingest configuration, MediaLive encoding, CDN delivery, and monitoring dashboard typically requiring 200-350 development hours. The SRT-specific configuration adds approximately 40-60 hours compared to a standard RTMP ingest setup.