Points clés à retenir
- Séparez l’ingestion, le traitement, le stockage, la diffusion et la lecture avant de choisir les produits, puis appliquez les contrôles d’autorisation sur tout le parcours des requêtes.
- Construisez les échelles de versions encodées à partir de la qualité de la source et des conditions mesurées chez les spectateurs plutôt que d’une liste fixe de résolutions.
- Empaquetez les versions encodées alignées en HLS, MPEG-DASH ou CMAF et préservez chaque chemin relatif de manifeste et de segment lors de l’exportation.
Un CDN vidéo ne se résume pas à un composant. Une lecture à la demande fiable repose sur une chaîne dont les couches d’ingestion, de traitement, de stockage, de diffusion et de lecture ont chacune une responsabilité explicite, l’autorisation étant appliquée comme une politique transversale. L’architecture échoue lorsqu’un manifeste en cache pointe vers des segments remplacés ou pas encore publiés, que les chemins des versions encodées sont rompus lors de l’exportation ou qu’un besoin de diffusion en direct est confondu avec le traitement VOD de fichiers.
L’essentiel
- Utilisez des chemins versionnés pour les ressources médias, des politiques de cache définies avec soin et un modèle d’autorisation unique pour les manifestes, les segments, les sous-titres et les affiches.
- Mesurez le délai de démarrage, les remises en mémoire tampon, les erreurs de lecture, le taux de succès du cache, le trafic provenant de l’origine, les échecs de traitement et le coût par ressource média publiée.
Attribuer à chaque couche une responsabilité claire
Partez du spectateur et remontez la chaîne. Le lecteur interprète le manifeste, sélectionne une version encodée, affiche les sous-titres, signale les événements de lecture et applique les contrôles du produit. Le CDN sert de point de terminaison aux requêtes des spectateurs, fait respecter la politique de diffusion choisie, met les réponses en cache et récupère auprès d’une origine les éléments absents du cache. Le stockage objet durable conserve les manifestes, segments, sous-titres et affiches approuvés, ainsi que tout fichier maître d’archivage. Un service de traitement crée ces sorties à partir d’une source complète. L’infrastructure de téléversement ou d’ingestion en direct achemine la source jusqu’à ce périmètre de traitement. L’autorisation est une politique transversale appliquée de manière cohérente au parcours des requêtes de diffusion et de lecture, et non une sixième couche de traitement des médias.
L’expression « CDN vidéo » masque souvent cette décomposition. Un CDN ne répare pas les horodatages corrompus et ne crée pas d’échelle de versions encodées adaptative. Un transcodeur ne fournit pas automatiquement de contrôles d’autorisation pour le public, de cache mondial, de lecteur ni d’analyses de la qualité d’expérience. Conservez entre les couches des identifiants stables de ressources médias et de versions, gérés par l’application, afin de pouvoir corréler une tâche de traitement, un paquet exporté, une requête de diffusion et une erreur du lecteur sans faire d’un nom de fichier une base de données.
Couche d’ingestion
Reçoit un téléversement ou un import complet, ou finalise un enregistrement en direct avant de transmettre une source persistante au traitement.
Couche de traitement
Crée des versions encodées et des paquets, tous techniquement valides, à partir de la source stockée durablement et transmise par l’ingestion.
Couche de stockage
Gère les fichiers approuvés et expose un chemin d’origine contrôlé ; elle ne constitue pas le catalogue de ressources médias de l’application.
Couche de diffusion
Protège les requêtes des spectateurs et les sert depuis le cache, récupère auprès de l’origine les résultats absents du cache et applique la politique de diffusion choisie.
Couche de lecture
Interprète le manifeste, sélectionne les versions encodées, affiche les sous-titres et prend en charge l’expérience de visionnage.
Créer une échelle de versions encodées qui justifie son coût
Inspectez la source avant de choisir les sorties. La résolution, la fréquence d’images, le codec, la profondeur de bits, la configuration des canaux audio, la durée et la complexité visuelle limitent les choix utiles. Une source 720p ne peut pas gagner de détails réels grâce à un encodage 1080p. Un cours avec peu de mouvement et un enregistrement sportif aux mouvements rapides peuvent nécessiter des débits différents à dimensions égales. Conservez une source d’archive de haute qualité lorsqu’un retraitement futur compte, mais ne faites pas passer ce fichier maître par le parcours de lecture public.
Encodez un ensemble réduit de versions encodées dont les débits et les dimensions offrent des paliers de changement pertinents. Utilisez la même durée de segment, des images clés alignées et des chronologies compatibles pour l’ensemble. Validez la qualité visuelle sur des contenus représentatifs plutôt que de vous fier aux noms des résolutions. Ajouter des versions encodées augmente les minutes d’encodage, les octets stockés, le nombre d’objets des paquets, le temps de validation et les absences possibles du cache. N’en ajoutez donc une que lorsque la télémétrie du lecteur révèle un besoin non couvert.
Respecter les limites de la source
N’augmentez jamais la résolution d’une source simplement pour compléter une échelle conventionnelle de versions encodées : cela n’ajoute aucun détail réellement capturé.
Utiliser un corpus représentatif
Comparez les mouvements, les dégradés, le texte, les visages, les scènes sombres et la synchronisation audio aux débits cibles.
Boucler le cycle de mesure
Ajustez l’échelle de versions encodées à partir des données de démarrage, de remise en mémoire tampon et de débit diffusé plutôt que sur la seule intuition.
Empaqueter les sorties adaptatives dans une seule arborescence interconnectée
Les paquets HLS et MPEG-DASH sont des graphes de références plutôt que des fichiers sans lien entre eux. Un manifeste de niveau supérieur identifie les versions encodées, les listes de lecture multimédias ou les représentations identifient les médias, et les entrées de médias permettent de localiser les segments. Les sous-titres, les pistes audio alternatives, les métadonnées de chiffrement et les segments d’initialisation peuvent ajouter d’autres relations. Validez l’ensemble du paquet à partir de son URL publique après l’exportation ; vérifier uniquement que le manifeste maître renvoie 200 ne permet pas de détecter les références rompues en aval, les problèmes de types MIME ou de règles CORS, ni les échecs d’autorisation.
L’exemple crée deux versions encodées prêtes pour HLS dans des Steps /video/encode distincts, puis les empaquette via /video/adaptive. Le Step adaptatif définit un seul segment_duration pour le paquet ; vérifiez que les chronologies des versions encodées et les réglages des images clés restent compatibles, en particulier avant de combiner des fichiers préparés en dehors d’un même flux de travail maîtrisé. /s3/store exporte ensuite les fichiers obtenus. Les résultats adaptatifs contiennent des métadonnées relative_path. La destination combine ${assembly.id}, commun à tout le paquet, avec ${file.meta.relative_path} et ${file.name}, afin que chaque résultat reste sous un même préfixe et préserve la structure de répertoires référencée par les listes de lecture. En production, utilisez un Template enregistré et des informations d’identification de Template limitées aux privilèges nécessaires. Remplacez l’échelle de l’exemple, le nom my_s3_credentials, le bucket et la région configurés dans ces informations d’identification de Template, ainsi que le préfixe de chemin vod, par des valeurs testées pour le corpus source, les lecteurs cibles et le bucket. L’exemple définit acl sur bucket-default pour omettre l’en-tête ACL généré. Utilisez un bucket S3 privé avec Block Public Access activé et le réglage Object Ownership défini sur Bucket owner enforced (ACL désactivées), et n’ajoutez aucun en-tête ACL ni aucun en-tête d’octroi de permissions dans headers. Ce sont les politiques du bucket et les politiques IAM, et non ce seul réglage, qui contrôlent la confidentialité ; configurez séparément l’accès du CDN à l’origine privée.
{
"steps": {
":original": { "robot": "/upload/handle" },
"hls_480p": {
"use": ":original",
"robot": "/video/encode",
"result": false,
"ffmpeg_stack": "v6",
"preset": "hls/480p"
},
"hls_720p": {
"use": ":original",
"robot": "/video/encode",
"result": false,
"ffmpeg_stack": "v6",
"preset": "hls/720p"
},
"vod_package": {
"use": {
"steps": ["hls_480p", "hls_720p"],
"bundle_steps": true
},
"robot": "/video/adaptive",
"result": true,
"technique": "hls",
"playlist_name": "master.m3u8"
},
"exported": {
"use": "vod_package",
"robot": "/s3/store",
"credentials": "my_s3_credentials",
"acl": "bucket-default",
"path": "vod/${assembly.id}/${file.meta.relative_path}/${file.name}"
}
}
}Fiabiliser le comportement du stockage et du cache lors des déploiements
Publiez chaque paquet approuvé sous un chemin de version immuable, par exemple un identifiant de ressource associé à une version ou à une empreinte du contenu. Téléversez chaque objet, validez le paquet, puis seulement modifiez l’enregistrement de l’application pour rendre accessible le nouveau manifeste maître. La publication est ainsi atomique du point de vue du spectateur, ce qui évite qu’un nouveau manifeste pointe vers des segments qui ne sont pas encore parvenus à l’origine. Conservez ou supprimez les anciennes versions selon une politique explicite de retour arrière et de conservation.
Les segments accessibles par des chemins immuables peuvent normalement bénéficier de longues durées de conservation en cache, car leurs octets ne changent jamais. Un manifeste modifié sans changement de chemin nécessite une politique de cache plus courte ou une invalidation active, mais versionner le paquet VOD complet est plus simple à maîtriser. Configurez les types de contenu corrects, le comportement des requêtes par plages d’octets lorsque nécessaire, CORS pour les origines réelles du lecteur et des règles de compression cohérentes. N’appliquez pas aux manifestes et aux segments les hypothèses génériques de mise en cache du HTML sans tester le lecteur et le CDN choisis.
Publier de manière atomique
Un paquet ne devient visible qu’après l’export et la validation de tous les objets référencés.
Utiliser des versions immuables
Une même URL renvoie toujours les mêmes octets, ce qui empêche les médias en cache de mélanger silencieusement différentes versions publiées.
Protéger la lecture sans détruire le cache
Choisissez si une vidéo est publique, accessible pendant une durée limitée ou soumise à un droit d’accès dans l’application. Appliquez la politique qui en résulte au manifeste maître, aux manifestes enfants, aux segments, aux sous-titres, aux affiches et aux téléchargements. Protéger uniquement la première requête ne suffit pas lorsqu’un spectateur peut réutiliser directement les URL des segments. Conservez les informations d’identification du stockage privé et les secrets de signature Transloadit sur des serveurs de confiance.
Tout paramètre de requête, cookie ou en-tête de requête dont la valeur varie peut affecter la réutilisation du cache s’il entre dans la clé de cache. À l’inverse, retirer de cette clé une valeur pertinente pour la sécurité peut conduire à servir une réponse autorisée dans un contexte inapproprié. Privilégiez un petit ensemble documenté de paramètres de diffusion, normalisez-les en périphérie du réseau lorsque cela convient et testez l’expiration, la révocation, le déplacement dans la vidéo et les requêtes simultanées de segments. Ne placez ni secrets ni données personnelles dans les URL des manifestes et des segments, car ces URL peuvent apparaître dans les journaux, les données d’analyse, l’historique du navigateur et les traces d’assistance.
Observer le parcours complet et simuler des incidents
La télémétrie du traitement devrait rendre visibles l’entrée acceptée, chaque version encodée, la création du paquet, l’achèvement de l’exportation, la durée et les échecs sous forme structurée. La télémétrie du stockage et du CDN devrait rendre visibles les objets manquants, le temps de réponse de l’origine, le taux de succès du cache, les octets transférés et les statuts de réponse par classe d’objet. La télémétrie du lecteur devrait rendre visibles le délai de démarrage, les remises en mémoire tampon, les erreurs fatales, le débit sélectionné, les échecs de déplacement dans la vidéo et les échecs d’affichage des sous-titres. Reliez ces observations à l’aide d’identifiants stables de ressource et de version, tout en limitant les données des spectateurs au strict nécessaire.
Testez les cas suivants : sources corrompues ou non prises en charge, téléversements interrompus, destination d’export indisponible, paquets partiels, notifications de fin dupliquées, manifeste périmé, panne de l’origine, autorisation de diffusion expirée, en-têtes CORS manquants et codec non pris en charge. Rapprochez les tâches de traitement qui n’ont pas atteint un état final de leur état de référence afin qu’une notification manquée ne laisse pas une ressource média bloquée indéfiniment. Conservez des états distincts pour « traité », « exporté », « lisible », « examiné » et « publié ».
Concevoir pour les répétitions
Des chemins réutilisables sans risque lors de nouvelles tentatives et des gestionnaires idempotents empêchent les notifications répétées de produire des publications répétées.
Rétablir la cohérence en cas d’événements manquants
Une vérification planifiée du statut rétablit la cohérence de l’état lorsqu’une notification est retardée ou n’atteint jamais l’application.
Modéliser le coût par ressource publiée et visionnée
Comptabilisez le téléversement ou l’importation de la source, chaque sortie encodée, l’empaquetage, les sous-titres, les miniatures, l’exportation, les originaux conservés, les segments stockés, les requêtes au CDN, les requêtes à l’origine et le trafic sortant. Ajoutez ensuite les échecs, les nouvelles tentatives, les modifications et les nouveaux formats requis. Une échelle de versions encodées plus étendue coûte davantage avant même l’arrivée de spectateurs, tandis qu’une architecture reposant sur de très petits segments peut augmenter le volume de requêtes et la surcharge liée aux manifestes. La fragmentation du cache reporte la charge de travail et le trafic sur l’origine.
Comparez les architectures avec des sources et des répartitions d’audience représentatives. Le coût par minute en entrée est utile pour le traitement, mais le coût par ressource publiée révèle le travail échoué ou abandonné, et le coût par heure visionnée reflète le comportement de la diffusion. Incluez le temps d’ingénierie consacré à la compatibilité des lecteurs, aux règles de cache, à l’autorisation, à l’observabilité, à la réponse aux incidents et à la migration. Le tarif unitaire annoncé le plus bas ne correspond pas nécessairement au système fiable le moins coûteux.
Détails techniques à connaître
- HLS et MPEG-DASH décrivent des paquets de diffusion adaptative ; aucun de ces protocoles ne fournit à lui seul l’ingestion en direct, le stockage, un CDN, un lecteur, des analyses ou des vérifications des droits d’accès.
- Le passage adaptatif entre versions encodées nécessite des chronologies compatibles et des limites de segments alignées. Des fichiers encodés indépendamment ne peuvent pas automatiquement être combinés sans risque dans une même échelle de versions encodées.
- Un manifeste maître référence des listes de lecture multimédias ou des représentations, qui référencent à leur tour des segments. Déplacer des fichiers sans préserver ces chemins relatifs interrompt la lecture, même lorsque chaque objet existe.
- Les manifestes et les segments multimédias évoluent différemment. Les segments VOD versionnés peuvent utiliser une mise en cache immuable de longue durée, tandis que les manifestes modifiables nécessitent une politique adaptée à leur mode de publication et de remplacement.
- Les clés de cache du CDN et l’autorisation doivent être conçues ensemble. Les chaînes de requête, les cookies ou les en-têtes qui varient inutilement peuvent fragmenter le cache, tandis que l’omission de données d’autorisation peut exposer des médias protégés.
- La durée des segments, et donc leur taille approximative à un débit donné, influe sur la latence de démarrage et sur la rapidité avec laquelle un lecteur peut passer d’une version encodée à une autre.
- L’adressage par plages d’octets permet de regrouper plusieurs segments dans une ressource fMP4 ou CMAF que les lecteurs récupèrent au moyen de requêtes HTTP par plages, ce qui réduit le nombre d’objets et de clés de cache. Il ne réduit pas le nombre total d’octets transmis lors d’une lecture linéaire et complète la diffusion segmentée sans la remplacer.
- Avec /video/adaptive, Transloadit empaquette les versions encodées préparées en HLS, MPEG-DASH ou CMAF. Les exports vers le stockage doivent conserver les métadonnées relative_path de chaque résultat pour maintenir les liens entre les éléments du paquet.
- L’application ne devrait pas marquer une vidéo comme publiable au seul motif que l’encodage est terminé. Elle doit également vérifier que l’exportation est complète, que les manifestes sont valides, que l’accès aux médias diffusés fonctionne, ainsi que les sous-titres, les images d’affiche et la lecture sur les clients cibles.
Une approche pratique
- 1
Schématisez le parcours des requêtes et des données, de l’ingestion de la source jusqu’au spectateur, en attribuant un responsable à chaque transition.
- 2
Produisez une échelle réduite de versions encodées à partir de sources représentatives et validez le passage d’une version encodée à l’autre sur les appareils cibles et dans des conditions réseau réalistes.
- 3
Exportez le paquet adaptatif complet vers des chemins de stockage versionnés et testez-le avec les règles du CDN de production.
- 4
Simulez des incidents impliquant des exports partiels, des manifestes périmés, des origines indisponibles, une autorisation expirée et des événements de fin manquants.
Quand Transloadit est utile
Utilisez un Template enregistré pour transformer des enregistrements téléversés, importés ou finalisés en une échelle de versions encodées adaptée aux conditions mesurées avec /video/encode, empaqueter ces versions encodées avec /video/adaptive et exporter l’arborescence complète des répertoires vers un stockage que vous contrôlez. Associez un CDN et un lecteur aux fichiers VOD obtenus selon vos exigences de diffusion.
Périmètre architectural
Transloadit traite des fichiers vidéo terminés et peut empaqueter des sorties adaptatives de vidéo à la demande (VOD), mais ne fournit ni ingestion en direct, ni CDN généraliste, ni lecteur vidéo. La diffusion en direct et la lecture par le public nécessitent des composants dédiés.
Questions fréquentes
Chaque service doit-il publier à la fois en HLS et en MPEG-DASH ?
Pas nécessairement. HLS bénéficie d’une large prise en charge native dans les environnements Apple, tandis que MPEG-DASH est courant dans d’autres piles logicielles de lecture. Certains produits publient les deux à partir de médias CMAF communs, mais cela ajoute du travail de validation et d’exploitation. Choisissez en fonction des exigences réelles des appareils et des lecteurs, puis testez précisément les manifestes, les codecs, les sous-titres et le parcours d’autorisation utilisés.
Existe-t-il une échelle standard de versions encodées pour le débit adaptatif ?
Non. Une échelle de versions encodées utile tient compte de la résolution de la source, de sa fréquence d’images, de sa complexité visuelle, des écrans cibles et de la bande passante mesurée chez les spectateurs. N’augmentez pas la résolution au-delà de celle de la source et n’ajoutez pas de versions encodées voisines qui n’améliorent pas le passage de l’une à l’autre. Commencez par une échelle réduite et ajustez-la à l’aide des données de lecture.
Comment remplacer une vidéo déjà en cache ?
Utilisez un chemin versionné et immuable pour chaque paquet approuvé et modifiez le pointeur de l’application vers la ressource média lorsqu’un remplacement est prêt. Cela empêche un nouveau manifeste de référencer des segments anciens ou partiellement remplacés et permet de conserver sans risque une mise en cache de longue durée pour les segments.
Transloadit peut-il prendre en charge la partie en direct d’un CDN vidéo ?
Il peut préparer des ressources de vidéo à la demande à partir de fichiers complets, après leur téléversement, leur import ou leur finalisation par un fournisseur de diffusion en direct. Il n’accepte pas de flux d’entrée continu en direct, parfois appelé flux de contribution, et n’assure pas la diffusion en direct. Un flux de travail en direct nécessite donc un service spécialisé d’ingestion et de distribution.
Que dois-je surveiller en premier ?
Suivez le délai de démarrage chez les spectateurs, le taux de remise en mémoire tampon, les erreurs de lecture fatales, le débit moyen diffusé, le taux de succès du cache du CDN, le volume d’octets provenant de l’origine, les échecs de réponse pour les manifestes et les segments, la durée du traitement, l’exhaustivité des exports et le coût par ressource média publiée. Conservez des identifiants permettant de croiser les données du lecteur, du CDN, du stockage et du traitement sans placer de données privées dans les URL.