MicrocosmWorksInnover et Architecturer le Cosmos Numérique
À proposContact
MicrocosmWorksInnover et architecturer des cosmos numériques

Fournir des solutions informatiques qui comptent. Nous sommes passionnés par la technologie, la sécurité et aidons les entreprises à croître grâce à une infrastructure informatique fiable et innovante.

[email protected]
+91 7011868196
New Delhi, India

Hub de Croissance IA

Hub IAInnovation pour les startupsAccélérateur d'entreprise

Solutions

Toutes les solutionsApplications de bien-être et de fitnessPlateforme vidéo IADéveloppement d'agents IA

Ressources

PerspectivesGuides de l'industriePlans d'utilisationModèles d'architectureÉtudes de cas

Entreprise

À propos de nousContactNotre travail

Services

Consultation numériqueInfrastructure cloudDéveloppement SaaSDéveloppement IATechnologie vidéo
Développement ERPPersonnalisation ZohoDéveloppement OdooIntégration SalesforceDéveloppement CRM personnalisé
Intégration QuickBooksSolutions IoTDéveloppement Blockchain
Consultation en cybersécuritéSupport IT - L3

© 2026 MicrocosmWorks. Tous droits réservés.

Politique de confidentialitéConditions d'utilisation
Retour aux Études de Cas
Video EncodingPublié June 22, 2026 · Mis à jour June 22, 2026

AWS Media Services pour le streaming de chaînes FAST via SRT

Une société de médias avait besoin d'établir des flux de contribution fiables et à faible latence pour ses chaînes FAST en utilisant le protocole Secure Reliable Transport (SRT) — permettant l'ingestion de contenu de haute qualité depuis des studios distants, des systèmes de diffusion cloud et des partenaires de syndication sur des connexions internet imprévisibles.

Discutez de Votre Projet
aws-fast-channel-srt.webp
Video Encoding
Domain
10
Technologies
5
Key Results
Delivered
Status

Le Défi

Les workflows de contribution traditionnels s'appuyaient sur des liaisons fibre optique ou satellite dédiées, qui étaient coûteuses et inflexibles :

  • Les circuits dédiés coûtaient des milliers par mois et par liaison et prenaient des semaines à provisionner
  • Le transport basé sur Internet (RTMP) souffrait de pertes de paquets, de gigue et manquait de chiffrement
  • L'ingestion multi-source nécessitait une connectivité flexible, définie par logiciel
  • La correction d'erreurs et le chiffrement de SRT en faisaient la norme de diffusion émergente, mais son intégration dans un pipeline natif AWS nécessitait une ingénierie personnalisée
  • Le monitoring des métriques spécifiques à SRT (RTT, taux de retransmission, surcharge de bande passante) nécessitait des outils dédiés

Notre Solution

Nous avons construit un pipeline de contribution et de distribution basé sur SRT en utilisant AWS Elemental MediaLive et MediaConnect, permettant un transport de contenu fiable et chiffré sur l'internet public avec une correction d'erreurs de qualité diffusion.

Architecture

  • Contribution : AWS Elemental MediaConnect pour l'ingestion SRT depuis des sources distantes
  • Transport : Protocole SRT avec chiffrement AES et correction d'erreurs ARQ
  • Encodage : AWS Elemental MediaLive pour le transcodage des entrées SRT vers une sortie multi-débits
  • Packaging : AWS Elemental MediaPackage pour le packaging HLS/DASH pour la livraison aux téléspectateurs finaux
  • Distribution : Sortie SRT depuis MediaConnect pour la syndication B2B vers les partenaires de plateforme
  • Monitoring : Tableau de bord des métriques spécifiques à SRT (RTT, perte de paquets, retransmission, gigue)
  • CDN : Amazon CloudFront pour la livraison HLS du dernier kilomètre aux téléspectateurs finaux

Avantages du protocole SRT

vs. RTMP

SRT offre des avantages significatifs par rapport à RTMP pour les flux de contribution : correction d'erreurs ARQ intégrée (tolérant jusqu'à 20 % de perte de paquets contre une rupture de flux à 1-2 % avec RTMP), chiffrement AES natif, contrôle de latence configurable, transport basé sur UDP et compatible NAT, et une surcharge de bande passante minimale pour la récupération d'erreurs.

vs. Circuits dédiés

SRT sur internet offre un coût considérablement inférieur et un provisionnement plus rapide par rapport à la fibre optique dédiée — avec les avantages supplémentaires de la redondance multi-chemin et de la flexibilité géographique depuis n'importe quel emplacement connecté à internet.

Conception du pipeline

Contribution (Ingestion)

  1. Sources distantes — Studios, diffusion cloud ou partenaires envoient des flux SRT à MediaConnect
  2. Écouteur SRT — Point de terminaison MediaConnect configuré comme écouteur SRT
  3. Chiffrement — Chiffrement par phrase secrète AES pour la sécurité du contenu en transit
  4. Correction d'erreurs — ARQ récupère les paquets perdus avec un tampon de latence configurable
  5. Basculement — Doubles entrées SRT avec basculement automatique en cas de défaillance du flux principal

Traitement

  1. MediaConnect → MediaLive — Le flux SRT est acheminé vers MediaLive pour le transcodage
  2. Transcodage — Encodage multi-débits avec passthrough SCTE-35
  3. Injection SCTE-35 — Signaux de coupure publicitaire insérés aux points planifiés
  4. Sortie — Flux transcodé envoyé à MediaPackage pour le packaging HLS

Distribution (Syndication B2B via SRT)

Pour la syndication aux partenaires de plateforme qui nécessitent un flux de qualité diffusion :

  • Sortie SRT en mode appelant ou écouteur selon les exigences du partenaire
  • Phrases secrètes de chiffrement distinctes par partenaire pour le contrôle d'accès
  • Configuration de la bande passante par partenaire
  • Métriques SRT par sortie pour le monitoring de l'état du flux partenaire

Configuration SRT

Réglage de la latence

La latence SRT est ajustée en fonction des conditions du réseau et du cas d'utilisation :

  • Ultra-faible — Réseaux de même région, de haute qualité (studio vers cloud)
  • Faible — Réseaux interrégionaux, de bonne qualité
  • Standard — Réseaux internationaux, variables
  • Haute résilience — Mauvais réseaux, tolérance maximale aux pertes de paquets

Les paramètres sont optimisés par cas d'utilisation avec une latence appropriée, des limites de bande passante, un niveau de chiffrement et un mode de connexion (appelant vs. écouteur).

Monitoring et alertes

La plateforme monitore les métriques spécifiques à SRT en temps réel :

  • Temps d'aller-retour (RTT) — Latence réseau entre l'expéditeur et le récepteur
  • Taux de retransmission — Pourcentage de paquets nécessitant une retransmission ARQ
  • Perte de paquets — Taux de perte de paquets avant ARQ indiquant la qualité du réseau
  • Gigue — Variation des temps d'arrivée des paquets
  • Utilisation de la bande passante — Bande passante réelle vs. maximale configurée
  • Niveau de la mémoire tampon — Niveau de remplissage de la mémoire tampon du récepteur (un sous-débit indique un bégaiement potentiel)

Des alertes automatisées se déclenchent sur les métriques dégradées pour une résolution proactive des problèmes.

Fonctionnalités clés

  1. Ingestion SRT — Recevoir des flux de contribution de toute source connectée à internet
  2. Chiffrement AES — Chiffrement de contenu intégré sans VPN ou TLS externe
  3. Récupération ARQ — Tolère jusqu'à 20 % de perte de paquets avec retransmission automatique
  4. Latence configurable — Ajustable en fonction de la qualité du réseau et du cas d'utilisation
  5. Basculement à double entrée — Basculement automatique en cas de défaillance du flux SRT principal
  6. Syndication B2B — Flux de sortie SRT pour la distribution aux partenaires
  7. Tableau de bord des métriques SRT — Monitoring en temps réel du RTT, des pertes, de la gigue et des retransmissions
  8. Sortie hybride — SRT pour la contribution B2B, HLS via CloudFront pour la livraison aux consommateurs

Résultats

Économies de coûts : Réduction de plus de 90 % par rapport aux circuits fibre optique dédiés pour la contribution
Fiabilité : La correction d'erreurs ARQ a maintenu une qualité de diffusion sur l'internet public
Flexibilité : Nouvelles sources distantes intégrées en quelques minutes contre des semaines pour les lignes dédiées

Stack Technologique

AWS Elemental MediaConnectAWS Elemental MediaLiveAWS Elemental MediaPackageAmazon CloudFrontSRT ProtocolAES EncryptionSCTE-35AWS CloudWatchHLSH.264

caseStudyDetail.more Études de Cas

Découvrez plus de nos implémentations techniques

Video Encoding

Insertion d'annonces côté client (CSAI) avec analyse des marqueurs SCTE-35 et intégration de lecteurs multiplateformes

Une plateforme de streaming vidéo devait implémenter l'insertion d'annonces côté client (CSAI) sur les applications web, mobiles et de télévision connectée — permettant des expériences publicitaires personnalisées au niveau de l'appareil avec un support complet d'interaction publicitaire (superpositions cliquables, bannières complémentaires, boutons de saut) que l'insertion côté serveur ne peut pas offrir.

Lire l'Étude de Cas
Video Encoding

Signalisations des marqueurs publicitaires SCTE-35 et pipeline d'insertion de bandes-annonces média

Une société de médias en streaming avait besoin d'un pipeline robuste et automatisé pour injecter des marqueurs publicitaires SCTE-35 dans les flux en direct et VOD, ainsi que de la capacité d'insérer des bandes-annonces promotionnelles (pre-roll, mid-roll et post-roll) à des positions précisément chronométrées – permettant la monétisation sur les chaînes FAST, les événements en direct et les bibliothèques de contenu à la demande.

Prêt à Transformer Votre Entreprise ?

Discutons de la façon dont nous pouvons appliquer des solutions similaires à vos défis.

Contactez-NouscaseStudyDetail.viewAllCaseStudies
Portée mondiale : Flux SRT ingérés depuis n'importe quel emplacement dans le monde
Basculement : L'architecture à double entrée a atteint 99,99 % de disponibilité des flux de contribution
Lire l'Étude de Cas
Video Encoding

AWS Media Services pour le Streaming de Chaînes FAST sur HLS

Une entreprise de médias devait lancer des chaînes de télévision en streaming gratuites financées par la publicité (FAST) — des flux linéaires 24h/24 et 7j/7 de contenu vidéo sélectionné diffusés via HLS vers des smart TV, des décodeurs et des lecteurs web/mobiles, monétisés par l'insertion publicitaire programmatique.

Lire l'Étude de Cas

Questions fréquemment posées

MicrocosmWorks a choisi le SRT pour ses performances supérieures sur les réseaux non fiables, offrant un chiffrement AES-128, une retransmission automatique des paquets et un ajustement adaptatif du débit binaire, ce qui manque au RTMP. Le SRT maintient une diffusion vidéo de qualité broadcast avec moins de 1 % de surcharge de récupération de perte de paquets, même sur des chemins internet publics où le RTMP afficherait des artefacts visibles.

MicrocosmWorks a configuré AWS Elemental MediaLive pour accepter les entrées SRT en modes appelant et écoutant, puis pour transcoder vers une échelle ABR et générer des segments HLS/DASH vers MediaPackage. L'ingestion SRT bénéficie du déchiffrement SRT intégré de MediaLive et du jitter buffer, assurant une qualité de source nette avant l'étape de transcodage.

Oui, MicrocosmWorks a configuré MediaLive avec plusieurs sources d'entrée SRT et a construit un plan de contrôle de routage qui bascule entre les flux selon un calendrier prédéfini ou une annulation manuelle. Chaque contributeur SRT se connecte via un port d'écoute unique avec une authentification par phrase secrète AES individuelle, et le système prend en charge le hot-standby failover entre les sources SRT principales et de secours.

MicrocosmWorks a développé un tableau de bord de surveillance utilisant des métriques personnalisées CloudWatch qui ingère les statistiques SRT, y compris le temps d'aller-retour, le taux de retransmission, l'utilisation de la bande passante et les niveaux de tampon. Des alertes automatisées se déclenchent lorsque les taux de retransmission dépassent 2 % ou que le RTT dépasse 200 ms, donnant aux équipes d'exploitation un avertissement précoce avant que la dégradation de la qualité ne devienne visible pour les spectateurs.

MicrocosmWorks déploie une infrastructure de chaînes FAST basée sur SRT à des tarifs de 30 à 50 $/heure, la configuration complète comprenant la configuration d'ingestion SRT, l'encodage MediaLive, la diffusion CDN et un tableau de bord de surveillance nécessitant généralement 200 à 350 heures de développement. La configuration spécifique à SRT ajoute environ 40 à 60 heures par rapport à une configuration d'ingestion RTMP standard.