AWS Media Services for FAST Channel Streaming over SRT
A media company needed to establish reliable, low-latency contribution feeds for their FAST channels using the Secure Reliable Transport (SRT) protocol — enabling high-quality content ingest from remote studios, cloud playout systems, and syndication partners over unpredictable internet connections.
プロジェクトを相談する
課題
Traditional contribution workflows relied on dedicated fiber or satellite links, which were expensive and inflexible:
- Dedicated circuits cost thousands per month per link and took weeks to provision
- Internet-based transport (RTMP) suffered from packet loss, jitter, and lacked encryption
- Multi-source ingest required flexible, software-defined connectivity
- SRT's error correction and encryption made it the emerging broadcast standard, but integrating it into an AWS-native pipeline required custom engineering
- Monitoring SRT-specific metrics (RTT, retransmission rate, bandwidth overhead) needed dedicated tooling
私たちのソリューション
We built an SRT-based contribution and distribution pipeline using AWS Elemental MediaLive and MediaConnect, enabling reliable, encrypted content transport over public internet with broadcast-grade error correction.
Architecture
- Contribution: AWS Elemental MediaConnect for SRT ingest from remote sources
- Transport: SRT protocol with AES encryption and ARQ error correction
- Encoding: AWS Elemental MediaLive for transcoding SRT inputs to multi-bitrate output
- Packaging: AWS Elemental MediaPackage for HLS/DASH packaging for end-viewer delivery
- Distribution: SRT output from MediaConnect for B2B syndication to platform partners
- Monitoring: SRT-specific metrics dashboard (RTT, packet loss, retransmission, jitter)
- CDN: Amazon CloudFront for last-mile HLS delivery to end viewers
SRT Protocol Advantages
vs. RTMP
SRT provides significant advantages over RTMP for contribution feeds: built-in ARQ error correction (tolerating up to 20% packet loss vs. stream breakage at 1-2% with RTMP), native AES encryption, configurable latency control, UDP-based NAT-friendly transport, and minimal bandwidth overhead for error recovery.
vs. Dedicated Circuits
SRT over internet offers dramatically lower cost and faster provisioning compared to dedicated fiber — with the added benefits of multi-path redundancy and geographic flexibility from any internet-connected location.
Pipeline Design
Contribution (Ingest)
- Remote Sources — Studios, cloud playout, or partners send SRT streams to MediaConnect
- SRT Listener — MediaConnect endpoint configured as SRT listener
- Encryption — AES passphrase encryption for content security in transit
- Error Correction — ARQ recovers lost packets with configurable latency buffer
- Failover — Dual SRT inputs with automatic failover on primary stream failure
Processing
- MediaConnect → MediaLive — SRT flow piped to MediaLive for transcoding
- Transcoding — Multi-bitrate encoding with SCTE-35 passthrough
- SCTE-35 Injection — Ad break signals inserted at scheduled points
- Output — Transcoded stream sent to MediaPackage for HLS packaging
Distribution (B2B Syndication via SRT)
For syndication to platform partners who need a broadcast-grade feed:
- SRT output in caller or listener mode based on partner requirements
- Separate encryption passphrases per partner for access control
- Per-partner bandwidth configuration
- Per-output SRT metrics for partner feed health monitoring
SRT Configuration
Latency Tuning
SRT latency is tuned based on network conditions and use case:
- Ultra-Low — Same-region, high-quality networks (studio to cloud)
- Low — Cross-region, good networks
- Standard — International, variable networks
- High Resilience — Poor networks, maximum packet loss tolerance
Settings are optimized per use case with appropriate latency, bandwidth limits, encryption level, and connection mode (caller vs. listener).
Monitoring & Alerting
The platform monitors SRT-specific metrics in real-time:
- Round Trip Time (RTT) — Network latency between sender and receiver
- Retransmission Rate — Percentage of packets requiring ARQ retransmission
- Packet Loss — Pre-ARQ packet loss rate indicating network quality
- Jitter — Variation in packet arrival times
- Bandwidth Utilization — Actual vs. configured maximum bandwidth
- Buffer Level — Receiver buffer fill level (underrun indicates potential stutter)
Automated alerts trigger on degraded metrics for proactive issue resolution.
Key Features
- SRT Ingest — Receive contribution feeds from any internet-connected source
- AES Encryption — Built-in content encryption without external VPN or TLS
- ARQ Recovery — Tolerates up to 20% packet loss with automatic retransmission
- Configurable Latency — Tunable based on network quality and use case
- Dual-Input Failover — Automatic switchover on primary SRT feed failure
- B2B Syndication — SRT output feeds for partner distribution
- SRT Metrics Dashboard — Real-time RTT, loss, jitter, and retransmission monitoring
- Hybrid Output — SRT for B2B contribution, HLS via CloudFront for consumer delivery
成果
技術スタック
caseStudyDetail.more ケーススタディ
その他の技術実装事例をご覧ください
SCTE-35マーカー解析とマルチプラットフォームプレイヤー統合によるクライアントサイド広告挿入 (CSAI)
あるビデオストリーミングプラットフォームは、ウェブ、モバイル、コネクテッドTVアプリ全体でクライアントサイド広告挿入 (CSAI) を実装する必要がありました。これにより、サーバーサイド挿入では提供できない、完全な広告インタラクションサポート（クリック可能なオーバーレイ、コンパニオンバナー、スキップボタン）を備えた、パーソナライズされたデバイスレベルの広告体験が可能になります。
SCTE-35アドマーカーシグナリング＆メディアトレーラー挿入パイプライン
あるストリーミングメディア企業は、SCTE-35アドマーカーをライブおよびVODストリームに挿入し、プロモーション用トレーラー（プレロール、ミッドロール、ポストロール）を正確なタイミングで挿入できる堅牢な自動化パイプラインを必要としていました。これにより、FASTチャンネル、ライブイベント、オンデマンドコンテンツライブラリ全体での収益化が可能になります。
よくある質問
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.