Un live peut être un événement ponctuel (une Sunday service, un lancement de produit, une keynote de conférence, un mariage, un webinaire, une table ronde dans un petit festival), une diffusion occasionnelle (une émission hebdomadaire, un Q&A mensuel) ou une chaîne continue 24/7. La tuyauterie que l’industrie du streaming a empilée depuis quinze ans part du principe que ces trois cas demandent la même pile lourde : une caméra, un encodeur, un push RTMP vers un serveur de streaming, un transcodeur cloud, un packager, un CDN et un lecteur. Cinq pièces mobiles, quatre factures, trois endroits où l’authentification peut planter, et un schéma d’architecture que personne dans votre équipe ne sait redessiner de mémoire.
Pour une audience petite ou moyenne, vous n’avez besoin de rien de tout ça. Ni du serveur de streaming, ni du transcodeur cloud, ni du packager, ni du CDN. Que vous diffusiez deux heures le dimanche matin ou que vous fassiez tourner une chaîne qui ne dort jamais, la même architecture simple suffit.
Le secret mal gardé, c’est que sur un Mac moderne, quatre de ces cinq boîtes existent déjà à l’intérieur du portable posé sur votre bureau. L’encodeur H.264 que Final Cut Pro utilise pour l’export est exactement le même encodeur matériel embarqué dans chaque puce Apple silicon. Les encodeurs HEVC et AV1 sont juste à côté. Empaqueter du fragmented MP4 en segments HLS, c’est quelques centaines de lignes de code. Téléverser ces segments vers un serveur web, c’est du HTTPS PUT, que tous les serveurs parlent déjà. Le serveur de streaming au milieu n’est pas une loi de la physique. C’est juste quelque chose que l’industrie a pris l’habitude de louer.
My Live TV Channel est une application macOS qui réalise toute la chaîne dans un seul logiciel. Capture, encodage, packaging, publication. La sortie est du broadcast-standard HLS, le même format que Netflix, Apple, Disney+ et la BBC livrent à leurs spectateurs. La destination, c’est n’importe quel endpoint HTTPS que vous lui indiquez. Votre propre site web sur un hébergement mutualisé bon marché (sans CDN devant), un bucket S3, Cloudflare R2, Bunny Storage, ou Akamai MSL4 si vous diffusez par hasard des événements à l’échelle d’un Super Bowl. L’application s’en moque. Elle écrit des segments. Internet les ramasse.
Cet article détaille ce qui change quand vous repliez la chaîne de streaming dans une seule application, ce que ça coûte, et où sont les limites.
Ce dont vous avez réellement besoin pour passer en live
Trois choses, dans cet ordre.
Un Mac avec une entrée vidéo. N’importe quel Mac Apple silicon (M1 et au-delà) fait l’affaire. La caméra FaceTime intégrée suffit pour les streams en plan poitrine. Une caméra USB se branche et apparaît comme source. Votre iPhone apparaît en Continuity Camera, ce qui marche vraiment bien comme caméra B sur un événement parce qu’Apple gère le sans-fil et l’autofocus à votre place. Choisissez n’importe quelle caméra intégrée, USB ou Continuity Camera comme entrée. Une prévisualisation flottante en picture-in-picture garde la caméra visible pendant que vous travaillez dans une autre fenêtre.
Un endroit où poser les segments HLS. C’est la seule pièce qui compte vraiment et la seule sur laquelle les gens se prennent la tête. L’application téléverse de petits fichiers (des segments .m4s, six secondes chacun par défaut, plus de minuscules fichiers de playlist .m3u8) en HTTPS PUT ou POST. Tout ce qui accepte du HTTPS PUT fonctionne :
- Un dossier sur votre propre serveur web, avec PHP, Python, Node ou ce que vous faites déjà tourner, qui accepte le téléversement et l’écrit sur disque. La plupart des hébergements statiques (cPanel, simple Apache, simple nginx) peuvent être configurés pour ça en moins de trente minutes.
- Un bucket Amazon S3. Avec CloudFront en façade pour la distribution mondiale, en option.
- Cloudflare R2 (API compatible S3, sans frais d’egress), Bunny Storage, Wasabi, Backblaze B2.
- Akamai MSL4, qui est la couche de stockage derrière l’ingest live d’Akamai. Même protocole, dimensionné pour les plus gros événements live de la planète.
- N’importe quel autre endpoint qui parle HTTPS PUT et renvoie un code 2xx.
Un essai gratuit de 7 jours de l’application. Ensuite, la fonction de publication live demande un abonnement hebdomadaire qui démarre à $0.99/week. La prévisualisation caméra et l’enregistrement local restent toujours gratuits, ce qui est bon à savoir si vous cherchez juste un enregistreur.
Voilà toute la liste de courses. Pas de serveur de streaming. Pas de RTMP. Pas de VM media server à maintenir à jour. L’encodeur, le transcodeur, le packager et le publisher sont à l’intérieur de l’application sur votre Mac. La seule chose qui passe sur le câble, c’est du HLS finalisé, dans un seul sens, vers un bucket.
Ce que ça remplace
Ça vaut le coup d’être concret sur ce qui disparaît du schéma d’architecture.
Le serveur de streaming. Wowza Streaming Engine, Nimble Streamer, Ant Media Server, AWS Elemental MediaLive, l’ingest RTMP de Mux, et la dizaine d’autres services de cette catégorie existent pour une seule raison : recevoir un flux RTMP depuis un encodeur et le transformer en HLS. Si votre encodeur produit du HLS directement, le serveur de streaming n’a plus rien à faire. Vous pouvez le rayer du schéma et du budget.
Le transcodeur cloud. AWS Elemental MediaConvert, Mux Live, Bitmovin, Google Live Transcoder. Ils facturent à la minute d’entrée et à la minute de sortie. Un flux 1080p poussé à un seul bitrate, transcodé en quatre bitrates de sortie, monte vite en factures bien réelles, même pour un seul événement d’après-midi, et en factures sérieuses sur une chaîne continue. L’encodeur matériel Apple silicon de votre Mac est plus rapide, gratuit, et issu de la même famille de puces que celle qui fait tourner l’export de Final Cut Pro. Encoder les quatre variantes ABR directement sur le Mac fait disparaître la ligne « transcodage » de la facture.
Le packager. AWS Elemental MediaPackage, Unified Streaming, le packager de Wowza Streaming Cloud, qui existent tous pour empaqueter un flux en HLS ou en DASH. L’application produit du broadcast-standard HLS à la source. Il n’y a plus rien à empaqueter.
Le CDN, dans le petit cas. Celle-là surprend la plupart des gens. Les CDN existent pour deux raisons : encaisser un trafic mondial lourd au plus près du spectateur, et absorber les pics éclairs qu’une origine ne pourrait pas tenir. Le serveur web pas cher que vous avez déjà délivre parfaitement bien des segments HLS tout seul, jusqu’à un nombre fini et bien réel de spectateurs simultanés. Le calcul est simple : une variante HLS 1080p à 5 Mbps sur un uplink gigabit sature le lien autour de 200 spectateurs simultanés (1000 ÷ 5). La variante 720p à 3 Mbps fait monter ce chiffre à environ 330. La variante 540p à 1.8 Mbps atteint dans les 550. Sur une vraie audience en débit adaptatif, les spectateurs se répartissent sur tous ces barreaux (les mobiles sur les variantes basses, le desktop sur les variantes hautes), de sorte qu’un petit VPS porte tranquillement quelques centaines de spectateurs simultanés, et souvent davantage selon le mix d’appareils. Ça couvre la grande majorité des événements ponctuels et des chaînes petites à moyennes. Vous n’avez besoin d’un CDN que quand l’audience dépasse durablement cette enveloppe, ce qui arrive plus tard que la plupart des gens ne le pensent.
Les surprises de bande passante au GB. Quand votre origine est un serveur de streaming que vous louez et que votre distribution passe par un CDN que vous louez, chaque minute-spectateur fait tourner les deux compteurs. L’auto-hébergement déplace le compteur sur votre propre infrastructure : un VPS à $5 VPS avec une bande passante généreuse, un bucket R2 sans frais d’egress, une distribution CloudFront à votre tarif réservé, ce que vous avez déjà négocié. Personne ne va vous appeler en fin de mois parce que votre stream est devenu viral.
Les conditions de plateforme. YouTube et Twitch vous offrent un endpoint RTMP gratuit et un lecteur, et en échange ils décident de ce qui est monétisable, de ce qui passe en age-gating, de ce qui est recommandé, de ce qui est démonétisé telle ou telle semaine. L’auto-hébergement n’est gratuit ni en temps ni en argent, mais il ne vient pas avec un règlement tiers. Votre stream, votre domaine, vos conditions.
Ce qui ne change pas
L’auto-hébergement est un vrai virage, et il est honnête de dire ce qu’il ne change pas.
Vous payez toujours de la bande passante quelque part. Les octets doivent bien sortir d’un endroit. Le choix se joue entre un SaaS de streaming qui regroupe transcodage et distribution sur une seule facture, et l’auto-hébergement où vous payez séparément la couche de stockage et l’egress. Pour la plupart des audiences non triviales, la seconde option est moins chère. Pour un stream à cinq spectateurs, un compte YouTube gratuit est moins cher. Faites coller l’outil à l’audience.
Il vous faut toujours un lecteur. N’importe quel
lecteur HLS fonctionne. Video.js, hls.js, Shaka Player, le HLS natif du
navigateur dans Safari et sur iOS, l’AVPlayer d’Apple TV,
les lecteurs Roku, Fire TV et Android. Aucun n’a besoin de quoi que ce
soit de spécial du côté de votre origine. Si votre URL de destination
sert un index.m3u8 valide, tous les lecteurs modernes le
liront.
Il faut toujours penser à la latence. Du HLS standard avec des segments de six secondes tourne à peu près à 18 to 30 seconds de latence verre-à-verre. C’est très bien pour des talk-shows, des sets musicaux, des sermons, des cours, des coulisses, des highlights de gaming, des chaînes FAST, tout ce qui n’est pas une vente aux enchères ou un tournoi esport. Pour passer sous les cinq secondes de latence, il faut du LL-HLS, du WebRTC ou du DASH-LL, et l’équation change.
Il faut toujours de la disponibilité, calibrée à la diffusion. Un Mac sur votre bureau suffit pour un événement ponctuel : un SSD, un onduleur, une connexion filaire, et l’après-midi est sécurisée. Pour une diffusion longue ou en continu, vous voudrez plutôt un Mac mini dans un coin frais, un onduleur, une connexion filaire, et idéalement un second Mac sur lequel basculer. La fonction d’enregistrement local de l’application vous laisse de toute façon un fichier de secours. Rien de tout ça n’est plus dur que de faire tourner un serveur de streaming, et la plupart est même plus accueillant.
Le test de cinq minutes
Le moyen le plus rapide de savoir si ça vous convient, c’est de publier un stream de test sur un endpoint public et d’inspecter le résultat. L’application embarque un type de destination « HTTP PUT Server » qui ne demande aucune authentification ni aucune configuration de votre côté :
- Ouvrez l’application, allez dans Destinations, touchez +.
- Choisissez HTTP PUT Server.
- Nommez-la « Test », URL d’upload
https://ams.ireplay.tv/hls/test/, URL de lecture identique. - Laissez l’authentification vide.
- Test Connection. Le serveur renvoie HTTP 201.
- Sauvegardez.
- Profiles, créez un profil, sélectionnez la destination de test, les valeurs par défaut conviennent.
- Live, choisissez le profil, Go Live. Parlez à votre caméra pendant trente secondes, Stop.
- L’écran de récapitulatif affiche l’URL de lecture. Ouvrez-la dans
Safari, dans
ffprobe, dans n’importe quel lecteur HLS.
Si ça lit, votre Mac vient de jouer le rôle d’encodeur, de transcodeur, de packager et de publisher. De bout en bout, sans serveur de streaming dans la boucle. Les octets que vous regardez ont voyagé directement de l’encodeur H.264 de votre puce Apple jusqu’à un bucket public, puis jusqu’à votre lecteur. Tout le pipeline a tenu dans une seule application.
Ce même type de destination pointe vers n’importe quel endpoint HTTPS PUT. Remplacez l’URL par celle de votre propre bucket et vous auto-hébergez un stream sur votre propre infrastructure.
Stream ponctuel, ou chaîne 24/7 qui l’enrobe
Un live unique est un produit complet en soi. Vous appuyez sur Go Live pour la durée de l’événement, Stop quand c’est fini, vous laissez l’enregistrement sur votre domaine en replay. C’est un usage parfaitement valide de l’application, et c’est ce que la plupart des utilisateurs feront la plupart du temps.
Ce qui se passe quand vous n’êtes pas en live, c’est la question qui sépare un événement d’une station. Si un spectateur tombe sur la page de votre chaîne un mardi après-midi alors que rien n’est diffusé, il voit un écran « stream offline » et il s’en va. La plupart des diffuseurs indépendants perdent ce trafic sans s’en rendre compte.
L’application compagnon, My TV Channel, comble ce trou. C’est un outil de playout 24/7 : vous lui donnez votre bibliothèque vidéo existante, et il construit une grille linéaire continue (VOD2Live, parfois appelée FAST) qui tourne en boucle. Les spectateurs qui arrivent à n’importe quelle heure du jour tombent toujours sur quelque chose, même quand aucun événement live n’est en cours. Le même compte My TV Channel que vous utilisez pour le playout se branche directement sur l’application My Live TV Channel, donc quand vous appuyez sur Go Live, votre flux live est inséré dans la grille en cours. Les spectateurs en VOD2Live voient votre live prendre la main. Quand vous arrêtez, la grille reprend là où il faut.
Vous pouvez l’adopter dans l’ordre que vous voulez. Démarrer avec des lives ponctuels, et ajouter une présence 24/7 plus tard quand l’audience le demande. Ou démarrer avec une grille 24/7, et utiliser l’application live pour glisser par-dessus du news, des moments forts, des sessions Q&A, ou des shows live programmés.
L’outil live, l’outil de playout et l’outil de publication sont trois applications qui partagent une seule destination de stockage. Il n’y a aucun serveur de streaming dans cette architecture, juste le stockage que vous avez choisi, le Mac sur votre bureau, et les lecteurs entre les mains de vos spectateurs.
Verdict honnête
Si vous diffusez une petite émission devant trois spectateurs et que vous n’avez pas de plan de croissance, ouvrez un compte YouTube gratuit et collez l’embed sur votre site. Ce n’est pas pour vous.
Si vous faites tourner un stream payant, une diffusion réservée aux membres, une Sunday service pour votre paroisse, une chaîne FAST de niche, un événement live d’entreprise, une rediffusion interne (réunion plénière, formation) vers votre serveur web on-prem, une ligue sportive, un mariage retransmis pour la famille éloignée, une chaîne linéaire détenue par un créateur, ou n’importe quoi où les conditions de plateforme et les factures au GB sont des coûts bien réels, le calcul devient vite intéressant. Un Mac mini, un bucket de destination ou même un simple serveur web, et un abonnement à $0.99/week remplacent une pile de factures cloud qui, prises ensemble, démarraient à trois chiffres par mois et grimpaient à partir de là. Le schéma d’architecture tient sur un post-it. Le nombre de fournisseurs qui peuvent couper votre stream à coups de mise à jour des TOS passe de « plusieurs » à « zéro ».
Le serveur de streaming au milieu a toujours été optionnel. Le matériel présent dans chaque Mac sur chaque bureau attendait tranquillement de faire ce travail depuis des années. My Live TV Channel est le logiciel qui le lui permet enfin.
Essayez-le gratuitement pendant 7 jours sur le Mac App Store →