Een livestream kan een eenmalig evenement zijn (een zondagsdienst, een productlancering, een keynote op een conferentie, een bruiloft, een webinar, een paneldiscussie op een klein festival), een incidentele uitzending (een wekelijkse show, een maandelijkse Q&A) of een doorlopend 24/7-kanaal. De infrastructuur die de streamingindustrie de afgelopen vijftien jaar heeft opgebouwd, gaat ervan uit dat alle drie dezelfde zware stack nodig hebben: een camera, een encoder, een RTMP-push naar een streamingserver, een cloudtranscoder, een packager, een CDN en een speler. Vijf bewegende onderdelen, vier rekeningen, drie plekken waar authenticatie kan mislukken, en één architectuurdiagram dat niemand in je team uit het hoofd kan tekenen.
Voor een klein tot middelgroot publiek heb je daar niets van nodig. Niet de streamingserver, niet de cloudtranscoder, niet de packager en niet het CDN. Of je nu zondagochtend twee uur streamt of een kanaal draait dat nooit stilstaat: dezelfde eenvoudige architectuur dekt het.
Het smerige geheim is dat op een moderne Mac vier van die vijf blokken al binnenin de laptop op je bureau zitten. De H.264-encoder die Final Cut Pro gebruikt voor export, is dezelfde hardware-encoder die in elke Apple silicon-chip zit. De HEVC- en AV1-encoders staan er pal naast. Het verpakken van fragmented MP4 in HLS-segmenten is een paar honderd regels code. Die segmenten uploaden naar een webserver gebeurt via HTTPS PUT, een protocol dat elke server al spreekt. De streamingserver in het midden is geen natuurwet. Het is gewoon iets wat de industrie gewend is geraakt te huren.
My Live TV Channel is een macOS-app die de hele keten in één stuk software afhandelt. Capture, encode, package, publish. De uitvoer is broadcast-standaard HLS, hetzelfde formaat dat Netflix, Apple, Disney+ en de BBC naar hun kijkers sturen. De bestemming is welk HTTPS-endpoint je er ook op richt. Je eigen website op een goedkope shared host (zonder CDN ervoor), een S3-bucket, Cloudflare R2, Bunny Storage of Akamai MSL4 als je toevallig live-evenementen draait op de schaal van een Super Bowl. De app maakt het niet uit. Hij schrijft segmenten. Het internet pakt ze op.
Dit artikel loopt door wat er verandert wanneer je de streamingketen samenvouwt tot één app, wat het kost en waar de grenzen liggen.
Wat je werkelijk nodig hebt om live te gaan
Drie dingen, in deze volgorde.
Een Mac met een video-ingang. Elke Apple silicon-Mac (M1 en later) werkt. De ingebouwde FaceTime-camera is prima voor talking-head-streams. Een USB-camera prik je erin en die verschijnt als bron. Je iPhone verschijnt als Continuity Camera, wat eerlijk gezegd uitstekend werkt als B-camera bij evenementen, omdat Apple de draadloze verbinding en de autofocus voor je regelt. Kies een ingebouwde camera, USB-camera of Continuity Camera als bron. Een zwevende picture-in-picture-preview houdt de camera in beeld terwijl je in een ander venster werkt.
Een plek om HLS-segmenten neer te zetten. Dit is het enige onderdeel dat ertoe doet, en het enige onderdeel waar mensen zich te druk over maken. De app uploadt kleine bestanden (.m4s-segmenten, standaard zes seconden per stuk, plus piepkleine .m3u8-playlistbestanden) via HTTPS PUT of POST. Alles wat HTTPS PUT accepteert, werkt:
- Een directory op je eigen webserver, met PHP, Python, Node of wat je al draait, die de upload accepteert en op schijf wegschrijft. De meeste static hosts (cPanel, kale Apache, kale nginx) zijn binnen dertig minuten zo te configureren.
- Een Amazon S3-bucket. Eventueel met CloudFront ervoor voor wereldwijde delivery.
- Cloudflare R2 (S3-compatible API, geen egresskosten), Bunny Storage, Wasabi, Backblaze B2.
- Akamai MSL4, de storagelaag achter Akamai’s live ingest. Hetzelfde protocol, getest op schaal voor de grootste live-evenementen ter wereld.
- Elk ander endpoint dat HTTPS PUT spreekt en een 2xx-code teruggeeft.
Een gratis proefperiode van 7 dagen voor de app. Daarna vereist de live-publicatiefunctie een wekelijks abonnement vanaf $0,99/week. Camerapreview en lokale opname zijn altijd gratis, handig om te weten als je alleen een recorder nodig hebt.
Dat is het hele boodschappenlijstje. Geen streamingserver. Geen RTMP. Geen mediaserver-VM die je moet blijven patchen. De encoder, de transcoder, de packager en de publisher zitten allemaal in de app op je Mac. Het enige wat over de lijn gaat, is afgewerkte HLS, één kant op, een bucket in.
Wat het vervangt
Het is goed om concreet te zijn over wat er uit het architectuurdiagram verdwijnt.
De streamingserver. Wowza Streaming Engine, Nimble Streamer, Ant Media Server, AWS Elemental MediaLive, Mux’s RTMP-ingest en de tien andere diensten in deze categorie bestaan om één reden: een RTMP-stream van een encoder ontvangen en die omzetten naar HLS. Als je encoder direct HLS produceert, heeft de streamingserver niets te doen. Je kunt hem uit het diagram en uit het budget schrappen.
De cloudtranscoder. AWS Elemental MediaConvert, Mux Live, Bitmovin, Google Live Transcoder. Ze rekenen per minuut input en per minuut output. Een 1080p-stream die op één bitrate omhoog wordt geduwd en getranscodeerd naar vier output-bitrates, loopt zelfs voor een eenmalig middagevenement snel in het echte geld, en op een doorlopend kanaal in serieus geld. De Apple silicon-hardware-encoder in je Mac is sneller, gratis, en uit dezelfde chipfamilie die de export van Final Cut Pro draait. Door de vier ABR-varianten direct op de Mac te encoderen, verdwijnt de transcoderegel volledig uit de begroting.
De packager. AWS Elemental MediaPackage, Unified Streaming, de packager van Wowza Streaming Cloud, allemaal bedoeld om een stream in HLS of DASH te verpakken. De app produceert al broadcast-standaard HLS aan de bron. Er valt niets meer te verpakken.
Het CDN, in het kleine geval. Dit is het onderdeel dat de meeste mensen verbaast. CDN’s bestaan om twee redenen: zwaar wereldwijd verkeer dicht bij de kijker afhandelen, en flash-crowd-verkeer opvangen dat een origin niet aankan. De goedkope webserver die je toch al hebt, kan HLS-segmenten prima zelfstandig leveren tot aan een echt, eindig aantal gelijktijdige kijkers. De rekensom is simpel: een 1080p HLS-variant op 5 Mbps over een gigabit-uplink verzadigt de lijn bij ongeveer 200 gelijktijdige kijkers (1000 ÷ 5). De 720p-variant op 3 Mbps brengt dat naar ongeveer 330. De 540p-variant op 1,8 Mbps haalt rond de 550. In een echt adaptive-bitrate-publiek zijn de kijkers verdeeld over al die treden (mobiele gebruikers op lagere varianten, desktop op hogere), dus een kleine VPS draagt comfortabel een paar honderd gelijktijdige kijkers, en vaak meer, afhankelijk van de mix aan apparaten. Daarmee dek je de overgrote meerderheid van eenmalige evenementen en kleine tot middelgrote kanalen. Een CDN heb je pas nodig wanneer het publiek consequent buiten dat raamwerk groeit, en dat is later dan de meeste mensen denken.
Onverwachte kosten per GB bandbreedte. Wanneer je origin een streamingserver is die je huurt en je delivery via een CDN loopt dat je huurt, raakt elke kijkminuut beide meters. Self-hosting verschuift de meter naar je eigen infrastructuur: een VPS van $5 met royale bandbreedte, een R2-bucket zonder egresskosten, een CloudFront-distributie tegen je gereserveerde tarief, of wat je ook al onderhandeld hebt. Niemand belt jou eind van de maand op omdat je stream viral is gegaan.
Platformvoorwaarden. YouTube en Twitch geven je een gratis RTMP-endpoint en een speler, en in ruil daarvoor bepalen zij wat te gelde gemaakt mag worden, wat een leeftijdsgrens krijgt, wat aanbevolen wordt en wat in welke week wordt verwijderd. Self-hosting is niet gratis in tijd of geld, maar er hoort geen externe regelboek bij. Jouw stream, jouw domein, jouw voorwaarden.
Wat hetzelfde blijft
Self-hosting is een echte verschuiving, en het is eerlijk om duidelijk te zijn over wat het niet verandert.
Je betaalt nog steeds ergens voor bandbreedte. De bytes moeten ergens vandaan komen. De keuze is tussen een streaming-SaaS die transcoding plus delivery in één rekening bundelt, en self-hosting waarbij je apart betaalt voor de storagelaag en de egress. Voor de meeste niet-triviale doelgroepen is het tweede goedkoper. Voor een stream met vijf kijkers is een gratis YouTube-account goedkoper. Stem het gereedschap af op het publiek.
Je hebt nog steeds een speler nodig. Elke HLS-speler
werkt. Video.js, hls.js, Shaka Player, native HLS in Safari en op iOS,
AVPlayer van Apple TV, de spelers op Roku, Fire TV en Android. Geen
daarvan vraagt iets bijzonders van je origin. Als je bestemmings-URL een
geldige index.m3u8 serveert, speelt elke moderne speler hem
af.
Je moet nog steeds nadenken over latency. Standaard HLS met segmenten van zes seconden draait op zo’n 18 tot 30 seconden glass-to-glass-latency. Dat is prima voor talkshows, muzieksets, preken, lezingen, behind-the-scenes-content, gaming-highlights, FAST-kanalen, alles wat geen veiling of esports-toernooi is. Voor latency onder vijf seconden heb je LL-HLS, WebRTC of DASH-LL nodig, en dan verandert de berekening.
Je hebt nog steeds uptime nodig, op de schaal van de uitzending. Een Mac op je bureau is prima voor een eenmalig evenement: een SSD, een UPS, een bedrade verbinding en je komt de middag wel door. Voor een langlopende of altijd-aan uitzending wil je een Mac mini op een koele plek, een UPS, een bedrade verbinding en idealiter een tweede Mac waar je naar kunt failoveren. De lokale opnamefunctie van de app geeft je in beide gevallen een back-upbestand. Niets hiervan is moeilijker dan het draaien van een streamingserver, en het meeste is vriendelijker.
De vijfminutentest
De snelste manier om uit te vinden of dit voor jou werkt, is een teststream publiceren naar een publiek endpoint en het resultaat inspecteren. De app wordt geleverd met een bestemmingstype “HTTP PUT Server” dat geen authenticatie en geen setup aan jouw kant vereist:
- Open de app, ga naar Destinations, tik op +.
- Kies HTTP PUT Server.
- Noem hem “Test”, upload-URL
https://ams.ireplay.tv/hls/test/, playback-URL hetzelfde. - Laat authenticatie leeg.
- Test Connection. De server retourneert HTTP 201.
- Opslaan.
- Profiles, maak een profiel, kies de testbestemming, de standaardinstellingen zijn prima.
- Live, kies het profiel, Go Live. Praat dertig seconden tegen je camera, Stop.
- Het samenvattingsscherm toont de playback-URL. Open hem in Safari,
in
ffprobe, in elke HLS-speler.
Als hij speelt, heeft je Mac zojuist gefungeerd als encoder, transcoder, packager en publisher. End-to-end, zonder streamingserver in de keten. De bytes die je bekijkt, reisden rechtstreeks van de H.264-encoder op je Apple-chip naar een publieke bucket en uit naar je speler. De hele pipeline leefde in één app.
Datzelfde bestemmingstype wijst naar elk willekeurig HTTPS PUT-endpoint. Vervang de URL door die van je eigen bucket en je host een stream op je eigen infrastructuur.
Een eenmalige stream, of een 24/7-kanaal eromheen
Een enkele livestream is op zichzelf een compleet product. Druk op Go Live voor de duur van het evenement, Stop wanneer het voorbij is, laat de opname op je domein staan als replay. Dat is een volstrekt geldig gebruik van de app en is wat de meeste gebruikers het grootste deel van de tijd zullen doen.
Wat er gebeurt wanneer je niet live bent, is de vraag die een evenement van een station onderscheidt. Als een kijker op een dinsdagmiddag op je kanaalpagina belandt terwijl er niets wordt uitgezonden, ziet hij een “stream offline”-scherm en stuitert weg. De meeste onafhankelijke broadcasters verliezen dat verkeer zonder het door te hebben.
De begeleidende app, My TV Channel, vult dat gat. Het is een 24/7-playouttool: voer er je bestaande videobibliotheek in, en hij bouwt een doorlopende lineaire schedule (VOD2Live, soms FAST genoemd) die de klok rond draait. Kijkers die op welk tijdstip dan ook afstemmen, belanden altijd op iets, ook wanneer er geen live-evenement bezig is. Hetzelfde My TV Channel-account dat je voor playout gebruikt, koppelt direct aan de My Live TV Channel-app, dus wanneer je op Go Live drukt, wordt je live-feed in de lopende schedule ingevoegd. Kijkers die zijn afgestemd op VOD2Live, zien je live-uitzending het overnemen. Wanneer je stopt, hervat de schedule op het juiste punt.
Je kunt dit in beide volgordes invoeren. Begin met eenmalige live-evenementen en voeg later 24/7-aanwezigheid toe wanneer het publiek erom vraagt. Of begin met een 24/7-schedule en gebruik de live-app om er nieuws, breaking moments, Q&A-sessies of geplande live-shows bovenop te zetten.
De live-tool, de playout-tool en de publicatietool zijn drie apps die één opslagbestemming delen. Er staat nergens een streamingserver in deze architectuur, alleen de opslag die jij gekozen hebt, de Mac op je bureau en de spelers in de handen van je kijkers.
Eerlijk eindoordeel
Als je een kleine show streamt met drie kijkers en geen plannen om te groeien, meld je je aan voor een gratis YouTube-account en zet je de embed op je site. Jij bent niet het publiek voor dit verhaal.
Als je een betaalde stream draait, een uitzending alleen voor leden, een zondagsdienst voor je gemeente, een niche FAST-kanaal, een corporate live-event, een interne herdistributie (town hall, training) naar je on-prem webserver, een sportcompetitie, een bruiloftsuitzending voor verre familie, een lineair kanaal in eigen beheer of wat dan ook waar platformvoorwaarden en kosten per GB reële uitgaven zijn, wordt de rekensom snel interessant. Een Mac mini, een bestemmings-bucket of zelfs een gewone webserver, en een abonnement van $0,99/week vervangen een stapel cloudfacturen die samen vroeger begonnen bij drie cijfers per maand en daarvandaan oplopen. Het architectuurdiagram past op een geeltje. Het aantal leveranciers dat je stream kan offline halen met een TOS-update gaat van “meerdere” naar “nul”.
De streamingserver in het midden was altijd al optioneel. De hardware in elke Mac op elk bureau heeft jarenlang stilletjes klaargestaan om die taak te doen. My Live TV Channel is het stuk software dat dit eindelijk mogelijk maakt.