Streaming OTT : Construisez votre propre infrastructure de plateforme de streaming

Qu’est-ce que le streaming OTT ?

Le streaming OTT (Over-The-Top) délivre du contenu vidéo directement aux spectateurs via internet, en contournant la distribution broadcast et câble traditionnelle. Netflix, Disney+ et YouTube sont des plateformes OTT. Mais l’OTT ne se limite pas aux géants — les ligues sportives, les entreprises médias, les institutions éducatives, les lieux de culte et les organisateurs d’événements construisent de plus en plus leurs propres plateformes OTT pour atteindre leurs audiences directement.

Le défi d’infrastructure pour l’OTT est différent de la contribution et de la production. Les workflows de production déplacent un flux entre deux points. La distribution OTT déplace un flux vers des milliers ou des millions de spectateurs simultanément, chacun avec des conditions réseau et des capacités d’appareil différentes. Cela nécessite du streaming adaptatif (ABR), l’intégration CDN et une infrastructure d’origine évolutive.

Architecture OTT avec Vajra Cast

Vajra Cast sert de serveur d’origine dans une architecture OTT — le système qui reçoit les flux bruts, les traite et génère la sortie adaptive bitrate que les CDN distribuent aux spectateurs.

Sources                  Origine                   Diffusion
--------                 ------                    --------
Encodeur A --> SRT  -|                          |-- CDN Edge (US) --> Spectateurs
Encodeur B --> SRT  -|--> Vajra Cast --> HLS ---|-- CDN Edge (EU) --> Spectateurs
Encodeur C --> RTMP -|                          |-- CDN Edge (Asie) --> Spectateurs

Les trois étapes

Ingest : Recevoir les flux via SRT (préféré pour la fiabilité) ou RTMP (pour la compatibilité legacy)
Traitement : Transcodage accéléré par GPU pour générer les renditions adaptive bitrate
Distribution : Sortie HLS servie aux serveurs edge CDN pour la diffusion mondiale

Transcodage Adaptive Bitrate

Les spectateurs OTT regardent sur tout, des téléviseurs 65 pouces sur fibre gigabit aux téléphones sur des connexions cellulaires dans le métro. Le streaming adaptive bitrate (ABR) résout ce problème en encodant plusieurs niveaux de qualité et en laissant le lecteur choisir :

Exemple d’échelle ABR

Source : 1080p60 @ 12 Mbps (ingest SRT)

Transcodage Vajra Cast (Intel QSV) :
  --> 1080p @ 6 000 kbps (H.264 High)
  --> 720p  @ 3 000 kbps (H.264 Main)
  --> 480p  @ 1 500 kbps (H.264 Main)
  --> 360p  @ 800 kbps   (H.264 Baseline)
  --> Audio seul @ 128 kbps (AAC)

Sortie : Playlist master HLS référençant toutes les renditions

Vajra Cast génère toutes les renditions en utilisant l’accélération matérielle Intel QSV ou VAAPI. C’est crucial pour l’OTT — encoder cinq renditions en logiciel nécessiterait des ressources CPU significatives, tandis que l’accélération matérielle le gère pour une fraction de la puissance et du coût.

Considérations sur les codecs

Codec	Efficacité	Support navigateur	Recommandé pour
H.264	Base de référence	Universel	Compatibilité maximale
HEVC/H.265	~50 % meilleur que H.264	Safari, certains Android	Apps natives, smart TV
AV1	~30 % meilleur que HEVC	Chrome, Firefox, Edge	Vision future, VOD

Pour l’OTT live en 2026, H.264 reste le choix sûr pour une portée maximale. Utilisez HEVC pour les environnements d’apps dédiées où vous contrôlez le lecteur.

Intégration CDN

Le CDN est la pièce critique qui fait passer votre flux d’une origine à des millions de spectateurs. Vajra Cast génère le HLS à l’origine ; le CDN cache et distribue.

Configuration Origin Pull

La plupart des CDN fonctionnent en mode « origin pull » : les serveurs edge récupèrent les segments depuis votre origine (Vajra Cast) à la première requête, puis les mettent en cache pour les spectateurs suivants.

Le spectateur demande : https://cdn.example.com/live/channel-1/index.m3u8
  --> Le CDN edge vérifie le cache
  --> Si absent : récupère depuis l'origine Vajra Cast
  --> Met en cache le segment pour la durée du TTL
  --> Sert au spectateur (et tous les spectateurs suivants sur ce edge)

Bonnes pratiques de configuration CDN

TTL des segments : correspondre à la durée de vos segments HLS (ex. segments de 4 s = TTL de cache de 4 s)
TTL du manifeste : plus court que le TTL des segments (1-2 secondes) pour que les spectateurs découvrent les nouveaux segments rapidement
Origin shield : activer si disponible — réduit la charge sur l’origine en ajoutant une couche de cache intermédiaire
HTTP/2 : activer pour améliorer le téléchargement parallèle des segments
En-têtes CORS : configurer si vous servez du HLS à des lecteurs web sur des domaines différents

Optimisation des coûts

La bande passante CDN est généralement le coût le plus élevé du streaming OTT. Stratégies pour la réduire :

Échelle ABR efficace : ne proposez pas des résolutions que les spectateurs ne sélectionnent jamais
HEVC quand supporté : même qualité à la moitié du débit
Durée de segment appropriée : des segments plus longs = légèrement meilleure efficacité de compression
Routage géographique : servir depuis le edge le plus proche pour réduire les coûts de transit
Analytics spectateurs : comprendre quelles renditions sont réellement consommées et adapter l’échelle en conséquence

Routage multi-locataires

Si vous exploitez une plateforme OTT avec plusieurs chaînes ou fournisseurs de contenu, Vajra Cast peut router plusieurs flux indépendants à travers une seule instance :

Chaîne A : Encodeur --> SRT (Port 9001) --> Route A --> HLS /hls/channel-a/
Chaîne B : Encodeur --> SRT (Port 9002) --> Route B --> HLS /hls/channel-b/
Chaîne C : Encodeur --> RTMP (clé : ch-c) --> Route C --> HLS /hls/channel-c/

Chaque chaîne a sa propre route avec des paramètres indépendants :

Paramètres d’ingest (protocole, chiffrement, latence)
Profil de transcodage (échelle de résolutions, débits cibles)
Configuration de sortie (durée de segment HLS, longueur de playlist)
Chaîne de failover (sources de secours par chaîne)
Métriques de supervision

L’API REST de Vajra Cast permet le provisionnement automatisé des chaînes. Quand un nouveau fournisseur de contenu s’inscrit, le backend de votre plateforme appelle l’API pour créer la route, configurer l’ingest et provisionner la sortie HLS — sans intervention manuelle.

Gestion des chaînes pilotée par API

POST /api/routes
{
  "name": "Channel D",
  "inputs": [{
    "protocol": "srt",
    "mode": "listener",
    "port": 9004,
    "encryption": "aes-256",
    "passphrase": "generated-passphrase"
  }],
  "outputs": [{
    "protocol": "hls",
    "segmentDuration": 4,
    "playlistLength": 10
  }]
}

Supervision des spectateurs en direct

Le serveur HLS intégré de Vajra Cast suit les connexions de spectateurs actifs :

Compteur de spectateurs par chaîne : voir combien de spectateurs sont connectés à chaque flux HLS
Statistiques agrégées : total des spectateurs sur toutes les chaînes
Export Prometheus : vajracast_hls_viewers{channel="channel-a"} pour les tableaux de bord Grafana

Quand vous utilisez un CDN, les compteurs de spectateurs à l’origine représentent les requêtes pull des edges CDN plutôt que les spectateurs individuels. Pour des comptages précis d’utilisateurs finaux, corrélez les métriques d’origine Vajra Cast avec les analytics CDN.

Fiabilité pour une exploitation 24/7

Les plateformes OTT fonctionnent en continu. Vajra Cast est conçu pour une exploitation sans surveillance :

Reprise sur crash : l’adoption automatique de processus reconstruit toutes les routes depuis les processus en cours en moins de 5 secondes
Failover : le basculement automatique d’entrée maintient les chaînes à l’antenne même quand les sources tombent
Gestion à chaud : ajoutez, supprimez ou modifiez les chaînes sans affecter les autres flux
Supervision : métriques Prometheus et alertes Grafana détectent les problèmes avant qu’ils n’affectent les spectateurs
Docker/Kubernetes : orchestration de conteneurs avec health checks et politiques de redémarrage automatique

Scaling au-delà d’une seule instance

Pour les grandes plateformes OTT, Vajra Cast supporte le déploiement multi-instances :

Load Balancer
  --> Instance Vajra Cast 1 (Chaînes A-D)
  --> Instance Vajra Cast 2 (Chaînes E-H)
  --> Instance Vajra Cast 3 (Chaînes I-L)

Avec PostgreSQL comme backend d’état partagé, plusieurs instances Vajra Cast coordonnent le routage et la configuration. L’orchestration Kubernetes gère le scaling, le failover et la gestion des ressources.

Prochaines étapes

Explorez le Guide de la passerelle de streaming SRT pour l’architecture complète
Découvrez la configuration de sortie HLS pour la diffusion adaptive bitrate
Voyez comment la gestion à chaud permet la modification des chaînes en direct
Lisez les workflows de diffusion live pour l’architecture côté contribution
Comparez Vajra Cast avec Wowza ou Nimble Streamer pour les alternatives de plateforme

← Retour au guide principal