AWS Mediendienste für FAST-Kanal-Streaming über SRT
Ein Medienunternehmen benötigte die Einrichtung zuverlässiger, latenzarmer Zuspiel-Feeds für seine FAST-Kanäle unter Verwendung des Secure Reliable Transport (SRT)-Protokolls – um die hochwertige Aufnahme von Inhalten aus entfernten Studios, Cloud-Playout-Systemen und Syndikationspartnern über unvorhersehbare Internetverbindungen zu ermöglichen.
Ihr Projekt besprechen
Die Herausforderung
Traditionelle Zuspiel-Workflows basierten auf dedizierten Glasfaser- oder Satellitenverbindungen, die teuer und unflexibel waren:
- Dedizierte Leitungen kosteten Tausende pro Monat und Verbindung und die Bereitstellung dauerte Wochen
- Internetbasierter Transport (RTMP) litt unter Paketverlust, Jitter und mangelnder Verschlüsselung
- Die Aufnahme mehrerer Quellen erforderte flexible, softwaredefinierte Konnektivität
- Die Fehlerkorrektur und Verschlüsselung von SRT machten es zum aufstrebenden Broadcast-Standard, aber die Integration in eine AWS-native Pipeline erforderte kundenspezifisches Engineering
- Die Überwachung SRT-spezifischer Metriken (RTT, Retransmissionsrate, Bandbreiten-Overhead) erforderte dedizierte Tools
Unsere Lösung
Wir haben eine SRT-basierte Zuspiel- und Distributions-Pipeline unter Verwendung von AWS Elemental MediaLive und MediaConnect aufgebaut, die einen zuverlässigen, verschlüsselten Inhaltstransport über das öffentliche Internet mit Fehlerkorrektur auf Broadcast-Niveau ermöglicht.
Architektur
- Zuspiel: AWS Elemental MediaConnect für SRT-Ingest von entfernten Quellen
- Transport: SRT-Protokoll mit AES-Verschlüsselung und ARQ-Fehlerkorrektur
- Kodierung: AWS Elemental MediaLive für die Transkodierung von SRT-Eingaben in Multi-Bitrate-Ausgaben
- Verpackung: AWS Elemental MediaPackage für HLS/DASH-Verpackung zur Bereitstellung an Endzuschauer
- Distribution: SRT-Ausgabe von MediaConnect für B2B-Syndication an Plattformpartner
- Überwachung: SRT-spezifisches Metrik-Dashboard (RTT, Paketverlust, Neuübertragung, Jitter)
- CDN: Amazon CloudFront für die HLS-Auslieferung auf der letzten Meile an Endzuschauer
Vorteile des SRT-Protokolls
vs. RTMP
SRT bietet erhebliche Vorteile gegenüber RTMP für Zuspiel-Feeds: integrierte ARQ-Fehlerkorrektur (toleriert bis zu 20 % Paketverlust im Vergleich zu Stream-Abbrüchen bei 1-2 % mit RTMP), native AES-Verschlüsselung, konfigurierbare Latenzsteuerung, UDP-basierter NAT-freundlicher Transport und minimaler Bandbreiten-Overhead für die Fehlerbehebung.
vs. Dedizierte Leitungen
SRT über das Internet bietet im Vergleich zu dedizierter Glasfaser dramatisch niedrigere Kosten und eine schnellere Bereitstellung – mit den zusätzlichen Vorteilen der Mehrpfad-Redundanz und geografischer Flexibilität von jedem mit dem Internet verbundenen Standort aus.
Pipeline-Design
Zuspiel (Ingest)
- Entfernte Quellen — Studios, Cloud-Playout oder Partner senden SRT-Streams an MediaConnect
- SRT Listener — MediaConnect-Endpunkt als SRT-Listener konfiguriert
- Verschlüsselung — AES-Passphrase-Verschlüsselung für Inhaltssicherheit während des Transports
- Fehlerkorrektur — ARQ stellt verlorene Pakete mit konfigurierbarem Latenzpuffer wieder her
- Failover — Duale SRT-Eingänge mit automatischem Failover bei Ausfall des primären Streams
Verarbeitung
- MediaConnect → MediaLive — SRT-Flow wird zur Transkodierung an MediaLive weitergeleitet
- Transkodierung — Multi-Bitrate-Kodierung mit SCTE-35-Passthrough
- SCTE-35-Injektion — Werbeunterbrechungssignale werden an geplanten Punkten eingefügt
- Ausgabe — Transkodierter Stream wird an MediaPackage zur HLS-Verpackung gesendet
Distribution (B2B-Syndication über SRT)
Für die Syndication an Plattformpartner, die einen Broadcast-fähigen Feed benötigen:
- SRT-Ausgabe im Caller- oder Listener-Modus basierend auf Partneranforderungen
- Separate Verschlüsselungs-Passphrasen pro Partner für die Zugangskontrolle
- Bandbreitenkonfiguration pro Partner
- SRT-Metriken pro Ausgabe zur Überwachung der Feed-Zustand des Partners
SRT-Konfiguration
Latenz-Feinabstimmung
Die SRT-Latenz wird basierend auf Netzwerkbedingungen und Anwendungsfall abgestimmt:
- Ultra-Niedrig — Netzwerke in derselben Region, hohe Qualität (Studio zu Cloud)
- Niedrig — Regionenübergreifend, gute Netzwerke
- Standard — International, variable Netzwerke
- Hohe Resilienz — Schlechte Netzwerke, maximale Paketverlusttoleranz
Die Einstellungen werden pro Anwendungsfall mit geeigneter Latenz, Bandbreitenbegrenzungen, Verschlüsselungsgrad und Verbindungsmodus (Caller vs. Listener) optimiert.
Überwachung & Alarmierung
Die Plattform überwacht SRT-spezifische Metriken in Echtzeit:
- Round Trip Time (RTT) — Netzwerklatenz zwischen Sender und Empfänger
- Retransmissionsrate — Prozentsatz der Pakete, die eine ARQ-Neuübertragung erfordern
- Paketverlust — Pre-ARQ Paketverlustrate, die die Netzwerkqualität anzeigt
- Jitter — Variation der Paketankunftszeiten
- Bandbreitenauslastung — Tatsächliche vs. konfigurierte maximale Bandbreite
- Pufferfüllstand — Füllstand des Empfängerpuffers (Unterlauf deutet auf potenzielles Stottern hin)
Automatisierte Warnungen werden bei verschlechterten Metriken zur proaktiven Problemlösung ausgelöst.
Hauptmerkmale
- SRT-Ingest — Empfang von Zuspiel-Feeds von jeder mit dem Internet verbundenen Quelle
- AES-Verschlüsselung — Integrierte Inhaltsverschlüsselung ohne externes VPN oder TLS
- ARQ-Wiederherstellung — Toleriert bis zu 20 % Paketverlust mit automatischer Neuübertragung
- Konfigurierbare Latenz — Abstimmbar basierend auf Netzwerkqualität und Anwendungsfall
- Dual-Input Failover — Automatische Umschaltung bei Ausfall des primären SRT-Feeds
- B2B-Syndication — SRT-Ausgabe-Feeds für die Partnerdistribution
- SRT-Metriken-Dashboard — Echtzeitüberwachung von RTT, Verlust, Jitter und Neuübertragung
- Hybrid-Ausgabe — SRT für B2B-Zuspiel, HLS über CloudFront für die Konsumentenlieferung
Ergebnisse
Technologie-Stack
caseStudyDetail.more Fallstudien
Entdecken Sie mehr unserer technischen Implementierungen
Clientseitige Anzeigeninsertion (CSAI) mit SCTE-35 Marker-Parsing & Multi-Plattform-Player-Integration
Eine Video-Streaming-Plattform musste die Clientseitige Anzeigeninsertion (CSAI) über Web-, Mobil- und Connected TV-Apps hinweg implementieren – was personalisierte, gerätespezifische Anzeigenerlebnisse mit vollständiger Unterstützung der Anzeigeninteraktion (anklickbare Overlays, Companion-Banner, Skip-Buttons) ermöglicht, die serverseitige Insertion nicht bieten kann.
SCTE-35 Ad-Marker-Signalisierung & Media-Trailer-Einfügepipeline
Ein Streaming-Medienunternehmen benötigte eine robuste, automatisierte Pipeline zur Injektion von SCTE-35 Ad-Markern in Live- und VOD-Streams sowie die Möglichkeit, Werbetrailer (Pre-Roll, Mid-Roll und Post-Roll) an präzise getimten Positionen einzufügen – um die Monetarisierung über FAST-Kanäle, Live-Events und On-Demand-Inhaltsbibliotheken zu ermöglichen.
Häufig gestellte Fragen
MicrocosmWorks wählte SRT aufgrund seiner überlegenen Leistung über unzuverlässige Netzwerke. Es bietet AES-128-Verschlüsselung, automatische Paketneuübertragung und adaptive Bitratenanpassung, die RTMP nicht bietet. SRT gewährleistet die Bereitstellung von Videos in Rundfunkqualität mit weniger als 1% Overhead zur Wiederherstellung von Paketverlusten, selbst über öffentliche Internetverbindungen, wo RTMP sichtbare Artefakte zeigen würde.
MicrocosmWorks konfigurierte AWS Elemental MediaLive so, dass es SRT-Eingaben sowohl im Caller- als auch im Listener-Modus akzeptiert, dann in eine ABR-Leiter transkodiert und HLS/DASH-Segmente an MediaPackage ausgibt. Der SRT-Ingest profitiert von MediaLives integrierter SRT-Entschlüsselung und Jitter-Puffer, um eine saubere Quellqualität vor der Transkodierungsphase zu gewährleisten.
Ja, MicrocosmWorks konfigurierte MediaLive mit mehreren SRT-Eingangsquellen und baute eine Routing-Kontrollebene auf, die basierend auf einem vordefinierten Zeitplan oder einer manuellen Übersteuerung zwischen den Feeds umschaltet. Jeder SRT-Zulieferer verbindet sich über einen eindeutigen Listener-Port mit individueller AES-Passphrase-Authentifizierung, und das System unterstützt Hot-Standby-Failover zwischen primären und Backup-SRT-Quellen.
MicrocosmWorks hat ein Überwachungs-Dashboard unter Verwendung von CloudWatch Custom Metrics erstellt, das SRT-Statistiken wie Umlaufzeit, Retransmissionsrate, Bandbreitenauslastung und Pufferstände erfasst. Automatisierte Alarme werden ausgelöst, wenn die Retransmissionsrate 2% überschreitet oder der RTT 200 ms übersteigt, was den Betriebsteams eine frühzeitige Warnung gibt, bevor die Qualitätsminderung für die Zuschauer sichtbar wird.
MicrocosmWorks implementiert SRT-basierte FAST-Kanal-Infrastruktur zu Preisen von $30-$50/Stunde, wobei das komplette Setup, einschließlich SRT-Ingest-Konfiguration, MediaLive-Kodierung, CDN-Bereitstellung und einem Monitoring-Dashboard, typischerweise 200-350 Entwicklungsstunden erfordert. Die SRT-spezifische Konfiguration fügt ungefähr 40-60 Stunden hinzu im Vergleich zu einem standardmäßigen RTMP-Ingest-Setup.
Bereit, Ihr Unternehmen zu transformieren?
Lassen Sie uns besprechen, wie wir ähnliche Lösungen für Ihre Herausforderungen anwenden können.