En livesändning kan vara ett enstaka evenemang (en söndagsgudstjänst, en produktlansering, ett konferensanförande, ett bröllop, ett webbinarium, en panel på en liten festival), en återkommande sändning (ett veckovis program, en månatlig Q&A) eller en kontinuerlig 24/7-kanal. De rörledningar som streamingbranschen byggt upp under de senaste femton åren utgår från att alla tre behöver samma tunga stack: en kamera, en encoder, en RTMP-push till en streamingserver, en molntranskodare, en packager, en CDN och en spelare. Fem rörliga delar, fyra fakturor, tre ställen där autentiseringen kan fallera och ett arkitekturdiagram som ingen i ditt team kan rita ur minnet.
För en liten till medelstor publik behöver du inget av detta. Inte streamingservern, inte molntranskodaren, inte packagern och inte CDN:en. Oavsett om du sänder i två timmar på söndagsmorgonen eller driver en kanal som aldrig sover så täcker samma enkla arkitektur det.
Den smutsiga hemligheten är att fyra av dessa fem boxar redan finns inuti den bärbara datorn på ditt skrivbord, om det är en modern Mac. H.264-kodaren som Final Cut Pro använder för export är samma hårdvarukodare som sitter i varje Apple silicon-chip. HEVC- och AV1-kodarna ligger precis bredvid. Att paketera fragmented MP4 till HLS-segment är några hundra rader kod. Att ladda upp dessa segment till en webbserver är HTTPS PUT, vilket varje server redan talar. Streamingservern i mitten är ingen fysisk lag. Den är bara en sak som branschen har vant sig vid att hyra.
My Live TV Channel är en macOS-app som gör hela kedjan i ett enda program. Capture, encode, package, publish. Utdata är broadcast-standard HLS, samma format som Netflix, Apple, Disney+ och BBC levererar till sina tittare. Destinationen är vilken HTTPS-endpoint du än pekar mot. Din egen webbplats på en billig delad server (utan CDN framför), en S3-bucket, Cloudflare R2, Bunny Storage eller Akamai MSL4 om du råkar köra liveevenemang i Super Bowl-skala. Appen bryr sig inte. Den skriver segment. Internet plockar upp dem.
Den här artikeln går igenom vad som ändras när du komprimerar streamingkedjan till en enda app, vad det kostar och var gränserna går.
Vad du faktiskt behöver för att gå live
Tre saker, i denna ordning.
En Mac med en videoingång. Vilken Apple silicon-Mac som helst (M1 och uppåt) fungerar. Den inbyggda FaceTime-kameran duger fint för pratshuvudssändningar. En USB-kamera ansluts och dyker upp som en källa. Din iPhone visar sig som en Continuity Camera, vilket faktiskt är riktigt bra som B-kamera vid evenemang eftersom Apple sköter det trådlösa och autofokusen åt dig. Välj en inbyggd, USB- eller Continuity Camera som ingång. En flytande bild-i-bild-förhandsvisning håller kameran synlig medan du arbetar i ett annat fönster.
En plats att lägga HLS-segment. Detta är den enda biten som spelar roll och den enda biten folk övertänker. Appen laddar upp små filer (.m4s-segment, sex sekunder vardera som standard, plus pyttesmå .m3u8-spellistor) över HTTPS PUT eller POST. Allt som accepterar HTTPS PUT fungerar:
- En katalog på din egen webbserver, med PHP, Python, Node eller vad du nu redan kör, som tar emot uppladdningen och skriver den till disk. De flesta statiska hostar (cPanel, vanlig Apache, vanlig nginx) kan konfigureras att göra detta på under trettio minuter.
- En Amazon S3-bucket. Eventuellt med CloudFront framför för global leverans.
- Cloudflare R2 (S3-kompatibelt API, inga egress-avgifter), Bunny Storage, Wasabi, Backblaze B2.
- Akamai MSL4, som är lagringsnivån bakom Akamais live-ingest. Samma protokoll, skalningstestat för planetens största liveevenemang.
- Vilken annan endpoint som helst som talar HTTPS PUT och returnerar en 2xx-kod.
En 7 dagars gratis provperiod av appen. Därefter kräver live-publiceringsfunktionen ett veckoabonnemang som börjar på $0,99/vecka. Kameraförhandsvisning och lokal inspelning är alltid gratis, vilket är värt att veta om du bara behöver en inspelare.
Det är hela inköpslistan. Det finns ingen streamingserver. Det finns ingen RTMP. Det finns ingen mediaserver-VM som du behöver hålla patchad. Encoder, transcoder, packager och publisher sitter inuti appen på din Mac. Det enda som går på tråden är färdig HLS, åt ett håll, in i en bucket.
Vad det ersätter
Det är värt att vara konkret om vad som försvinner från arkitekturdiagrammet.
Streamingservern. Wowza Streaming Engine, Nimble Streamer, Ant Media Server, AWS Elemental MediaLive, Mux RTMP-ingest och det dussintal andra tjänster i samma kategori existerar av en enda anledning: att ta emot en RTMP-ström från en encoder och göra om den till HLS. Om din encoder producerar HLS direkt har streamingservern inget att göra. Du kan ta bort den från diagrammet och från budgeten.
Molntranskodaren. AWS Elemental MediaConvert, Mux Live, Bitmovin, Google Live Transcoder. De tar betalt per minut indata och per minut utdata. En 1080p-ström som pushas upp i en bitrate och transkodas till fyra utgångsbitrates blir snabbt riktiga pengar även för en enda eftermiddagshändelse, och allvarliga pengar på en kontinuerlig kanal. Apple silicon-hårdvarukodaren i din Mac är snabbare, gratis och från samma chipfamilj som driver Final Cut Pros export. Att koda de fyra ABR-varianterna direkt på Macen eliminerar transcode-posten helt.
Packagern. AWS Elemental MediaPackage, Unified Streaming, packagern i Wowza Streaming Cloud, alla finns för att linda en ström i HLS eller DASH. Appen producerar broadcast-standard HLS vid källan. Det finns inget kvar att paketera.
CDN:en, i det lilla fallet. Det här är det som överraskar de flesta. CDN:er finns av två skäl: att terminera tung global trafik nära tittaren, och att absorbera flash-crowd-trafik som ett origin inte klarar. Den billiga webbserver du redan har klarar att leverera HLS-segment alldeles utmärkt på egen hand upp till ett verkligt, ändligt antal samtidiga tittare. Matematiken är enkel: en 1080p HLS-variant på 5 Mbps över en gigabit-uplink mättar länken vid ungefär 200 samtidiga tittare (1000 ÷ 5). 720p-varianten på 3 Mbps tar det till runt 330. 540p-varianten på 1,8 Mbps når omkring 550. I en verklig adaptiv-bitrate-publik fördelar sig tittarna över alla dessa pinnar (mobilanvändare på lägre varianter, desktop på högre), så en liten VPS bär bekvämt några hundra samtidiga tittare och ofta fler, beroende på enhetsmixen. Det täcker den absoluta majoriteten av engångsevent och små till medelstora kanaler. Du behöver bara en CDN när publiken konsekvent växer ur det kuvertet, vilket inträffar senare än de flesta tror.
Per-GB-bandbreddsöverraskningar. När ditt origin är en streamingserver du hyr och din leverans är en CDN du hyr, så går varje tittarminut förbi båda mätarna. Att hosta själv flyttar mätaren till din egen infrastruktur: en VPS för $5 med generös bandbredd, en R2-bucket utan egress-avgifter, en CloudFront-distribution till din förhandlade taxa, vad du nu har förhandlat fram. Ingen kommer ringa dig vid månadens slut för att din ström blev viral.
Plattformsvillkor. YouTube och Twitch ger dig en gratis RTMP-endpoint och en spelare, och i utbyte bestämmer de vad som går att monetisera, vad som åldersgräns-spärras, vad som rekommenderas, vad som tas ner vilken vecka. Att hosta själv är inte gratis i tid eller pengar, men det kommer inte med en tredjepartsregelbok. Din ström, din domän, dina villkor.
Vad som förblir oförändrat
Att hosta själv är ett verkligt skifte, och det är ärligt att vara tydlig med vad det inte ändrar.
Du betalar fortfarande för bandbredd någonstans. Bytena måste komma från någonstans. Valet står mellan en streaming-SaaS som buntar ihop transkodning och leverans i en enda faktura, och egen hosting där du betalar separat för lagringsnivån och egress. För de flesta icke-triviala publiker är det andra billigare. För en ström med fem tittare är ett gratis YouTube-konto billigare. Matcha verktyget mot publiken.
Du behöver fortfarande en spelare. Vilken
HLS-spelare som helst fungerar. Video.js, hls.js, Shaka Player,
webbläsarens inbyggda HLS i Safari och på iOS, Apple TV:s
AVPlayer, spelarna i Roku, Fire TV och Android. Inget av
detta kräver något särskilt från ditt origin. Om din destinations-URL
serverar en giltig index.m3u8 kommer varje modern spelare
att spela upp den.
Du måste fortfarande tänka på latens. Standard HLS med sex sekunder långa segment ligger på ungefär 18 till 30 sekunders glas-till-glas-latens. Det är fint för pratprogram, musikset, predikningar, föreläsningar, bakom-kulisserna-innehåll, gaming-höjdpunkter, FAST-kanaler, allt som inte är en auktion eller en esports-turnering. För latenser under fem sekunder behöver du LL-HLS, WebRTC eller DASH-LL, och kalkylen ändras.
Du behöver fortfarande drifttid, anpassad till sändningen. En Mac på ditt skrivbord duger för ett engångsevent: en SSD, en UPS, en trådbunden anslutning och du klarar eftermiddagen. För en långkörande eller alltid-på-sändning vill du ha en Mac mini på en sval plats, en UPS, en trådbunden anslutning och helst en andra Mac att kunna failovra till. Appens funktion för lokal inspelning ger dig en backupfil i båda fallen. Inget av detta är svårare än att driva en streamingserver, och det mesta är trevligare.
Femminuterstestet
Snabbaste sättet att ta reda på om det här fungerar för dig är att publicera en teststream till en publik endpoint och inspektera resultatet. Appen levereras med en destinationstyp kallad “HTTP PUT Server” som inte kräver autentisering och ingen setup från din sida:
- Öppna appen, gå till Destinations, tryck +.
- Välj HTTP PUT Server.
- Döp den till “Test”, upload-URL
https://ams.ireplay.tv/hls/test/, playback-URL densamma. - Lämna autentisering tomt.
- Test Connection. Servern returnerar HTTP 201.
- Spara.
- Profiles, skapa en profil, välj testdestinationen, standardvärdena duger.
- Live, välj profilen, Go Live. Prata till kameran i trettio sekunder, Stop.
- Sammanfattningsskärmen visar playback-URL:en. Öppna den i Safari, i
ffprobe, i vilken HLS-spelare som helst.
Om den spelas upp har din Mac just agerat encoder, transcoder, packager och publisher. Hela vägen, utan någon streamingserver i loopen. Bytena du tittar på reste direkt från H.264-kodaren på ditt Apple-chip in i en publik bucket och ut till din spelare. Hela pipelinen levde i en enda app.
Samma destinationstyp pekar mot vilken HTTPS PUT-endpoint som helst. Byt ut URL:en mot en av din egen bucket och du hostar en stream själv på din egen infrastruktur.
Engångsstream, eller en 24/7-kanal som kapslar in den
En enskild livesändning är en komplett produkt i sig själv. Tryck Go Live under evenemangets gång, Stop när det är över, lämna inspelningen på din domän som repris. Det är ett helt giltigt sätt att använda appen och vad de flesta användare kommer att göra för det mesta.
Vad som händer när du inte är live är frågan som skiljer ett evenemang från en station. Om en tittare hamnar på din kanalsida en tisdag eftermiddag när inget sänds, ser de en “stream offline”-skärm och studsar bort. De flesta oberoende sändningsbolag förlorar den trafiken utan att inse det.
Kompanjonsappen, My TV Channel, fyller den luckan. Den är ett 24/7-playoutverktyg: mata den med ditt befintliga videobibliotek, så bygger den ett kontinuerligt linjärt schema (VOD2Live, ibland kallat FAST) som rullar dygnet runt. Tittare som slår på vid vilken tid som helst på dagen landar alltid på något, även när inget liveevenemang pågår. Samma My TV Channel-konto som du använder för playout kopplas direkt till My Live TV Channel-appen, så när du trycker Go Live läggs din live-feed in i det rullande schemat. Tittare som är inställda på VOD2Live ser din livesändning ta över. När du stoppar återupptas schemat på rätt plats.
Du kan införa det här i vilken ordning som helst. Börja med engångs-liveevent och lägg till 24/7-närvaro senare när publiken efterfrågar det. Eller börja med ett 24/7-schema och använd live-appen för att lägga in nyheter, oväntade händelser, Q&A-sessioner eller schemalagda liveprogram ovanpå.
Live-verktyget, playoutverktyget och publiceringsverktyget är tre appar som delar på en lagringsdestination. Det finns ingen streamingserver någonstans i den här arkitekturen, bara den lagring du valt, Macen på ditt skrivbord och spelarna i dina tittares händer.
Ärlig dom
Om du sänder ett litet program med tre tittare och inga planer på att växa, skapa ett gratis YouTube-konto och lägg in embed-koden på din sajt. Du är inte målgruppen för det här.
Om du driver en betald stream, en sändning enbart för medlemmar, en söndagsgudstjänst för din församling, en nisch-FAST-kanal, ett företagsliveevent, en intern återutsändning (town hall, utbildning) till din on-prem-webbserver, en sportliga, en bröllopssändning för avlägsna släktingar, en creator-ägd linjär kanal, eller vad som helst där plattformsvillkor och per-GB-räkningar är reella kostnader, då blir matematiken intressant snabbt. En Mac mini, en destinationsbucket eller till och med en helt vanlig webbserver, och ett abonnemang för $0,99/vecka ersätter en stack molnfakturor som tillsammans brukade börja på trecifrigt belopp i månaden och stiga därifrån. Arkitekturdiagrammet får plats på en post-it-lapp. Antalet leverantörer som kan stänga ner din stream med en TOS-uppdatering går från “flera” till “noll”.
Streamingservern i mitten har alltid varit valfri. Hårdvaran i varje Mac på varje skrivbord har tyst väntat på att få göra det jobbet i åratal. My Live TV Channel är den mjukvara som äntligen låter den göra det.