AWS Media Services til FAST-kanalstreaming over SRT
Et mediefirma skulle etablere pålidelige bidragsfeeds med lav latenstid til deres FAST-kanaler ved hjælp af Secure Reliable Transport (SRT) protokollen – hvilket muliggjorde indtag af indhold af høj kvalitet fra fjerntliggende studier, cloud playout-systemer og syndikeringspartnere over uforudsigelige internetforbindelser.
Diskuter Dit Projekt
Udfordringen
Traditionelle bidragsworkflows var afhængige af dedikerede fiber- eller satellitforbindelser, som var dyre og ufleksible:
- Dedikerede kredsløb kostede tusindvis om måneden pr. forbindelse og tog uger at klargøre
- Internetbaseret transport (RTMP) led under pakketab, jitter og manglede kryptering
- Indtag fra flere kilder krævede fleksibel, softwaredefineret forbindelse
- SRT's fejlkorrektion og kryptering gjorde det til den nye broadcast-standard, men integrering af det i en AWS-native pipeline krævede specialudvikling
- Overvågning af SRT-specifikke metrics (RTT, retransmission rate, bandwidth overhead) krævede dedikerede værktøjer
Vores Løsning
Vi byggede en SRT-baseret bidrags- og distributionspipeline ved hjælp af AWS Elemental MediaLive og MediaConnect, hvilket muliggjorde pålidelig, krypteret indholdstransport over offentligt internet med broadcast-kvalitets fejlkorrektion.
Arkitektur
- Bidrag: AWS Elemental MediaConnect til SRT-indtag fra fjerntliggende kilder
- Transport: SRT-protokol med AES-kryptering og ARQ-fejlkorrektion
- Kodning: AWS Elemental MediaLive til transkodning af SRT-input til multi-bitrate output
- Pakning: AWS Elemental MediaPackage til HLS/DASH-pakning til slutbrugerlevering
- Distribution: SRT-output fra MediaConnect til B2B-syndikering til platformspartnere
- Overvågning: SRT-specifikt metrics-dashboard (RTT, pakketab, retransmission, jitter)
- CDN: Amazon CloudFront til last-mile HLS-levering til slutbrugere
SRT-protokollens fordele
vs. RTMP
SRT giver betydelige fordele i forhold til RTMP for bidragsfeeds: indbygget ARQ-fejlkorrektion (tolererer op til 20% pakketab kontra afbrydelse af stream ved 1-2% med RTMP), native AES-kryptering, konfigurerbar latenstidskontrol, UDP-baseret NAT-venlig transport og minimal båndbredde overhead til fejlgenoprettelse.
vs. Dedikerede kredsløb
SRT over internet tilbyder dramatisk lavere omkostninger og hurtigere klargøring sammenlignet med dedikeret fiber – med de yderligere fordele ved multi-path redundans og geografisk fleksibilitet fra enhver internetforbundet placering.
Pipelinedesign
Bidrag (Indtag)
- Fjerntliggende kilder — Studier, cloud playout eller partnere sender SRT-streams til MediaConnect
- SRT Listener — MediaConnect-endepunkt konfigureret som SRT listener
- Kryptering — AES-passphrase-kryptering for indholdssikkerhed under transport
- Fejlkorrektion — ARQ gendanner tabte pakker med konfigurerbar latenstidsbuffer
- Failover — Dobbelt SRT-input med automatisk failover ved primær stream-fejl
Behandling
- MediaConnect → MediaLive — SRT-flow sendt til MediaLive for transkodning
- Transkodning — Multi-bitrate kodning med SCTE-35 passthrough
- SCTE-35 Injektion — Reklamepausesignaler indsat på planlagte punkter
- Output — Transkodet stream sendt til MediaPackage til HLS-pakning
Distribution (B2B-syndikering via SRT)
Til syndikering til platformspartnere, der har brug for et broadcast-kvalitetsfeed:
- SRT-output i caller- eller listener-tilstand baseret på partnerkrav
- Separate krypteringspassphrases pr. partner til adgangskontrol
- Båndbreddekonfiguration pr. partner
- SRT-metrics pr. output til overvågning af partnerfeedets sundhed
SRT-konfiguration
Latenstidstuning
SRT-latenstiden justeres baseret på netværksforhold og brugsscenarie:
- Ultra-lav — Samme-region, højtydende netværk (studie til cloud)
- Lav — Cross-region, gode netværk
- Standard — Internationale, variable netværk
- Høj modstandsdygtighed — Dårlige netværk, maksimal pakketabstolerance
Indstillingerne optimeres pr. brugsscenarie med passende latenstid, båndbreddegrænser, krypteringsniveau og forbindelsestilstand (caller vs. listener).
Overvågning og alarmering
Platformen overvåger SRT-specifikke metrics i realtid:
- Round Trip Time (RTT) — Netværkslatenstid mellem sender og modtager
- Retransmission Rate — Procentdel af pakker, der kræver ARQ-retransmission
- Pakketab — Pre-ARQ pakketabshastighed, der indikerer netværkskvalitet
- Jitter — Variation i pakkernes ankomsttider
- Båndbreddeudnyttelse — Faktisk vs. konfigureret maksimal båndbredde
- Bufferniveau — Modtagerbufferens fyldningsniveau (underrun indikerer potentiel hakken)
Automatiserede alarmer udløses ved forringede metrics for proaktiv problemløsning.
Nøglefunktioner
- SRT-indtag — Modtag bidragsfeeds fra enhver internetforbundet kilde
- AES-kryptering — Indbygget indholdskryptering uden ekstern VPN eller TLS
- ARQ-gendannelse — Tolererer op til 20% pakketab med automatisk retransmission
- Konfigurerbar latenstid — Justerbar baseret på netværkskvalitet og brugsscenarie
- Dual-Input Failover — Automatisk skift ved primær SRT-feed-fejl
- B2B-syndikering — SRT-outputfeeds til partnerdistribution
- SRT Metrics Dashboard — Realtids-RTT-, tab-, jitter- og retransmissionsovervågning
- Hybridt output — SRT til B2B-bidrag, HLS via CloudFront til forbrugerlevering
Resultater
Teknologistak
caseStudyDetail.more Casestudier
Udforsk flere af vores tekniske implementeringer
Klient-side annonceindsættelse (CSAI) med SCTE-35-markørparsing og integration af afspillere på flere platforme
En videostreamingplatform skulle implementere klient-side annonceindsættelse (CSAI) på tværs af web-, mobil- og connected TV-apps – hvilket muliggjorde personaliserede annonceringer på enhedsniveau med fuld support for annonceinteraktion (klikbare overlays, følgebannere, skip-knapper), som server-side indsættelse ikke kan tilbyde.
SCTE-35 Reklamemarkør-signalering & Pipeline for indsættelse af medietrailere
Et streamingmedieselskab havde brug for en robust, automatiseret pipeline til at injicere SCTE-35 reklamemarkører i live- og VOD-streams, samt muligheden for at indsætte promoverende trailere (pre-roll, mid-roll og post-roll) på præcist timede positioner — hvilket muliggjorde monetarisering på tværs af FAST channels, live events og on-demand indholdsbiblioteker.
Ofte stillede spørgsmål
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.
Klar til at Transformere Din Virksomhed?
Lad os drøfte, hvordan vi kan anvende lignende løsninger til dine udfordringer.