Pourquoi la vidéo est différente de tout ce que vous servez d'autre
Une page web pèse quelques mégaoctets. Dix minutes de vidéo en 1080p pèsent de l'ordre d'un gigaoctet par spectateur. Cet écart de trois ordres de grandeur explique pourquoi une vidéo qui serait une erreur d'arrondi en tant que page vue peut saturer un serveur d'origine le jour où elle devient populaire : cent spectateurs simultanés d'un même fichier, ce sont cent flux soutenus à haut débit depuis une seule machine.
L'économie suit la même courbe. Chez les fournisseurs qui facturent l'egress au gigaoctet, une vidéo modestement réussie est une facture visible ; une vidéo virale, c'est un appel du service financier. Les deux problèmes — le plafond de bande passante et la facture — ont la même forme que tout autre problème de contenu statique, et donc la même solution : répondre aux requêtes répétées depuis un cache proche du spectateur plutôt que depuis l'origine, à chaque fois.
HLS démystifié : une playlist et un dossier de fichiers
HLS (HTTP Live Streaming) semble exotique jusqu'à ce qu'on ouvre les fichiers. L'encodeur découpe la vidéo en segments courts — quelques secondes chacun — et écrit une playlist en texte brut (.m3u8) qui les liste dans l'ordre. Le lecteur télécharge la playlist, puis récupère les segments un par un en HTTP ordinaire, quelques secondes en avance sur ce qu'il affiche. La qualité adaptative est la même astuce appliquée deux fois : une playlist maîtresse pointe vers plusieurs playlists de variantes (1080p, 720p, 480p), et le lecteur saute de l'une à l'autre quand la bande passante varie.
La conséquence mérite d'être énoncée clairement : il n'y a aucun protocole vidéo spécial dans le chemin de diffusion. Pas de sockets, pas de serveur de streaming, pas d'infrastructure exotique. Chaque requête du lecteur est un GET vers un petit fichier statique — et de petits fichiers statiques servis des millions de fois, c'est exactement la charge de travail pour laquelle une périphérie CDN existe.
Une playlist de variante — du texte brut pointant vers des fichiers ordinaires
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:6
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:6.000,
segment_000.ts
#EXTINF:6.000,
segment_001.ts
#EXTINF:6.000,
segment_002.ts
#EXT-X-ENDLISTLe pipeline VOD : encoder une fois, stocker une fois, servir depuis la périphérie
Pour la vidéo à la demande, le pipeline comporte trois stations. Encoder une fois, sur votre machine ou dans votre build — ffmpeg transforme une vidéo source en dossier playlist-plus-segments en une seule commande. Stocker une fois, dans un stockage d'objets compatible S3, qui existe précisément pour ce genre de fichiers écrits une fois et lus des millions de fois. Servir depuis la périphérie : avec le bucket derrière le CDN, le premier spectateur de chaque segment remplit le cache et tous les suivants sont servis près de là où ils se trouvent, tandis que votre stockage ne répond à chaque fichier unique qu'environ une fois.
Sur cdn.com.tr, le stockage et la périphérie forment une seule plateforme, ce n'est donc pas un projet d'intégration : créez un bucket, uploadez le dossier, et la périphérie du même compte — WAF et protection DDoS incluses — se place devant.
Du fichier source au flux servi par le CDN
# 1) encode into HLS (6-second segments, one quality for brevity)
ffmpeg -i talk.mp4 -c:v h264 -c:a aac \
-hls_time 6 -hls_playlist_type vod \
-hls_segment_filename 'talk/segment_%03d.ts' talk/playlist.m3u8
# 2) create the bucket and an access key (panel works too)
cdnctl object-storage buckets create --account <uuid> --name videos
cdnctl object-storage access-keys create --account <uuid> --bucket <bucket_uuid>
# 3) upload the folder with the standard AWS CLI
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./talk s3://videos/talk
# the player now points at the playlist behind your CDN hostname:
# https://video.example.com/talk/playlist.m3u8Les règles de cache qui font ou défont la diffusion vidéo
La vidéo récompense la discipline des en-têtes de cache que les autres contenus se contentent d'apprécier, car les deux types de fichiers d'un flux HLS exigent un traitement opposé.
Les segments sont immuables par construction — segment_042.ts ne contiendra jamais d'autres octets, car un ré-encodage écrit un nouveau dossier. Mettez-les en cache aussi longtemps que vous voulez ; un an n'est pas imprudent, c'est correct. Chaque segment caché longtemps est de la bande passante que votre origine ne servira plus jamais.
Les playlists sont la partie mouvante. Pour une VOD terminée, elles ne changent que lorsque vous remplacez la vidéo : une heure convient. Dès qu'une playlist est en cours d'écriture — c'est ainsi que fonctionne le quasi-direct — elle doit être cachée quelques secondes seulement, car le lecteur la relit pour découvrir les nouveaux segments. Se tromper sur ce seul en-tête est le bug vidéo classique : des spectateurs figés sur d'anciens segments pendant que la playlist leur affirme qu'il n'existe rien de nouveau.
Sur cdn.com.tr, vous configurez exactement cette séparation via des règles de diffusion dans le panneau : une règle sur le chemin des segments avec une durée longue, une autre sur *.m3u8 avec une durée courte.
Les détails qui piquent : ranges, CORS et compression
Trois notes pratiques évitent la plupart des tickets de support vidéo. D'abord, les requêtes de plage : lecteurs et navigateurs demandent régulièrement des plages d'octets des fichiers médias, et la périphérie sert le contenu partiel depuis le cache — c'est aussi ce qui permet à un spectateur de sauter à la sixième minute sans télécharger les cinq premières d'un MP4.
Ensuite, CORS : si le lecteur tourne sur un autre nom d'hôte que les fichiers vidéo, le navigateur exigera des en-têtes Access-Control-Allow-Origin sur les segments et les playlists — le symptôme de l'oubli est un lecteur qui fonctionne dans un onglet nu mais pas intégré dans votre page.
Enfin, la compression : laissez-la désactivée pour les médias. La vidéo et l'audio sont déjà compressés par le codec ; gzipper un segment .ts dépense du CPU pour ne rien gagner. Compressez les playlists si vous voulez — c'est du texte — mais le gain est microscopique. La périphérie sait déjà ne pas recompresser les types médias ; cette note vaut pour la configuration de votre propre origine.
Et le streaming en direct ? Une réponse honnête
Le live, c'est la même histoire de diffusion avec une chaîne d'approvisionnement plus dure. La moitié diffusion est identique : un flux HLS en direct reste une playlist et des segments, simplement avec une playlist qui grandit toutes les quelques secondes et un cache très bref. Une périphérie sert cela à merveille — des milliers de spectateurs lisant des fichiers vieux de quelques secondes, ce ne sont toujours que des hits de cache.
Ce que le live ajoute, c'est tout ce qui précède l'existence des fichiers : l'ingest (recevoir le flux caméra en RTMP ou SRT), le transcodage en temps réel vers l'échelle de qualités, et le packaging — un pipeline en fonctionnement permanent avec ses propres modes de défaillance, pas un dossier qu'on uploade une fois. Ce pipeline ne s'assemble pas à la légère, et ce n'est pas ce que fait le produit en libre-service de cette plateforme : cdn.com.tr est la moitié stockage-et-diffusion de l'histoire. Si votre projet a besoin de la chaîne live complète, parlez-en directement avec nous plutôt que de la forcer dans un workflow taillé pour la VOD — et méfiez-vous de tout fournisseur qui vend du « streaming en direct » sans dire qui opère l'encodeur.
Questions fréquentes
Puis-je simplement servir un fichier MP4 directement au lieu de HLS ?
Pour les clips courts, oui — un MP4 derrière le CDN avec les requêtes de plage fonctionne, et les lecteurs s'y déplacent sans problème. HLS mérite sa complexité quand les vidéos s'allongent ou que les audiences varient : qualité adaptative, démarrages plus rapides, et de petits segments qui se cachent et reprennent mieux qu'un seul gros fichier.
Est-ce que cdn.com.tr encode mes vidéos ?
Non — l'encodage est votre côté du pipeline (ffmpeg en local ou en CI est la voie standard, et la commande ci-dessus est un point de départ complet). La plateforme stocke la sortie encodée dans le stockage d'objets et la diffuse via la périphérie.
Que se passe-t-il quand une vidéo devient virale ?
C'est exactement le scénario pour lequel cette architecture existe : après le premier spectateur par emplacement de périphérie, les segments sont servis depuis le cache, donc la charge de l'origine bouge à peine tandis que la diffusion suit l'échelle de la périphérie. Le point à surveiller, ce sont vos en-têtes de cache — des segments immuables cachés longtemps, c'est ce qui fait tenir le calcul.
Comment remplacer une vidéo sans que les spectateurs voient un mélange cassé d'ancien et de nouveau ?
Encodez dans un NOUVEAU dossier (talk-v2/) et pointez le lecteur vers la nouvelle URL de playlist — les anciens segments cachés deviennent hors sujet au lieu de devenir faux, sans purge nécessaire. Écraser les fichiers en place puis purger fonctionne, mais les chemins versionnés sont le schéma le plus serein, exactement comme pour n'importe quel asset statique.