Låg latens är en universell ambition i media. När ett företag som Wowza producerar det perfekta diagrammet för att förklara streamingteknologier med låg latens, måste du ta av dig hatten för dem och använda diagrammet med attribution och några mindre modifieringar. Jag presenterar nämnda diagram som figur 1; låt oss diskutera i den ordning som anges med de markerade siffrorna som jag har lagt till.
1. Ansökningar om låg latens
PRODUKTGUIDE
Bästa PTZ-kameror för direktuppspelning
Bara för att se till att vi alla är på samma sida betyder fördröjning i samband med direktuppspelning fördröjningen mellan glas och glas. Det första glaset är kameran vid det faktiska liveevenemanget, det andra är skärmen du tittar på. Latency är förseningen mellan när den visas i kameran och när den dyker upp på din telefon. Att bidra till latens är faktorer som kodningstid (vid evenemanget), transporttid till molnet, omkodningstid i molnet (för att skapa kodningsstegen), leveranstid och kritiskt hur många sekunder din spelare buffrar innan du börjar spela.
Det översta lagret visar typiska applikationer och deras latenskrav. Populära applikationer som saknas från låg latens och nästan realtidslatens är spel- och auktionssidor.
Innan du dyker in i vår tekniska diskussion bör du förstå att ju lägre latensen för din liveström är, desto mindre motståndskraftig är strömmen för bandbreddsavbrott. Till exempel, med standardinställningar, kommer en HLS-ström att spela upp i mer än 15 sekunders avbruten bandbredd, och om den återställs vid den tidpunkten kanske tittaren aldrig vet att det fanns ett problem. Däremot kommer en ström med låg latens att sluta spela nästan omedelbart efter ett avbrott. Så, fördelen med starttid med låg latens måste alltid balanseras mot det negativa av stopp i uppspelningen. Om du inte absolut behöver låg latens kan det inte vara värt att offra motståndskraft för att få det.
Med det sagt är det användbart att dela upp latens i tre kategorier enligt följande.
PRO NYHETSBREVLjud + Video + IT. Våra redaktörer är experter på att integrera ljud / video och IT. Få dagliga insikter, nyheter och professionellt nätverk. Prenumerera på Pro AV Today.
- Trevligt att ha - Snabbare är alltid bättre, men om du livestreamar ett Board of Education-möte eller gymnasiefotbollsmatch kan du bestämma att strömstyrka är viktigare än låg latens, särskilt om många tittare tittar på anslutningar med låg bithastighet.
- Konkurrensfördel - I vissa fall ger låg latens en konkurrensfördel, eller långsam latens innebär en konkurrensnackdel. Du kommer att notera i diagrammet att den typiska latensen för kabel-TV är cirka fem sekunder. Om din streamingtjänst tävlar mot kabel måste du vara inom det intervallet, med lägre latens som ger en blygsam konkurrensfördel.
- Kommunikation i realtid - Om du är en spel- eller auktionswebbplats eller om din ansökan annars kräver kommunikation i realtid måste du absolut leverera låg latens.
- Live streaming guide
- Hur man förutsäger codec-framgång
Nu när vi känner till kategorierna, låt oss titta på det mest effektiva sättet att leverera den nödvändiga nivån med låg latens.
2/3 Trevligt att ha låg latens
Siffran 2 visar att Apple HLS och MPEG-DASH som används med sina standardinställningar resulterar i cirka 30 sekunders latens. Siffrorna är enkla; Om du använder segmentstorlekar på tio sekunder och kräver att tre segment är i spelarbufferten innan uppspelningen startar, har du trettio sekunder. I själva verket ändrade Apple sina krav från tio sekunder till sex sekunder för några år sedan, och de flesta DASH-producenter använder 4-6 sekunders segment, så standardnumret är verkligen närmare 20 sekunder.
Ändå visar nummer 3, HLS Tuned och DASH Tuned, latens på cirka 6-8 sekunder. I grund och botten betyder inställning att man byter från 10-sekunderssegment till 2-sekunderssegment som, med samma matematik, ger 6-8 sekunders latens. Så, när latens är trevligt att ha, kan du minska latensen dramatiskt utan utvecklingstid eller kostnad, eller avsevärt ökad leveransrisk.
4. Konkurrensfördel - HTTP-teknik med låg latens
När låg latens behövs som en konkurrensfördel, gör det bara inte att klippa segmentstorlekar. måste du implementera en riktig teknik med låg latens. Här finns det två klasser; HTTP-teknik som LL-Latency HLS och Low-Latency CMAF för DASH, och lösningar baserade på andra tekniker, som WebSockets och WebRTC.
För de flesta producenter med applikationer i den här klassen erbjuder HTTP-teknologier med låg latens den bästa blandningen av överkomliga priser, bakåtkompatibilitet, flexibilitet och funktionsuppsättning. Så jag kommer att täcka över låg latens HLS och låg latens CMAF för DASH i detta avsnitt och andra tekniker i nästa.
Alla HLS / DASH / CMAF-baserade system med låg latens fungerar på samma grundläggande sätt, som visas i figur 2. Det vill säga snarare än att vänta tills ett komplett segment kodas, vilket vanligtvis tar mellan 6-10 sekunder (överst i figur 2) skapar kodaren mycket kortare bitar som överförs till CDN så snart de är färdiga (längst ner i figur 2).
Som ett exempel, om din kodare producerade segment på sex sekunder, skulle du ha minst sex sekunders latens; tredubbla att om de normala tre segmenten måste tas emot av tittaren innan uppspelningen börjar. Om din kodare tryckte ut bitar var 200: e millisekund, och spelaren var konfigurerad att starta uppspelning omedelbart, borde latensen vara mycket, mycket mindre. En viktig fördel med detta schema är bakåtkompatibilitet. eftersom segment fortfarande skapas bör spelare som inte är kompatibla med schemat med låg latens fortfarande kunna spela segmenten, om än med längre latens. Dessa segment är också direkt tillgängliga för VOD-presentationer från liveströmmen.
Utöver dessa fördelar stöder HTTP-teknik med låg latens de flesta funktionerna hos deras normala latenssyskon, inklusive kryptering, reklaminsättning och undertexter, som inte är allmänt stödda i WebRTC- och WebSockets-baserad teknik. Du kan troligen implementera din valda teknik med låg latens med din befintliga spelare och leveransinfrastruktur, vilket minimerar utveckling och andra teknikkostnader.
Välja en HTTP-teknik med låg latens
Det finns två huvudstandarder för HTTP Adaptive Streaming, HLS och DASH, plus ett enhetligt containerformat, CMAF. När Apple tillkännagav sin LLatency HLS-lösning fördrev det omedelbart flera gräsrotsansträngningar och blev den teknik som valts för att leverera låg latens till HLS. Även om specifikationen fortfarande är relativt ny stöds den redan av teknologileverantörer som Wowza och WMSPanel med sin Nimble Streamer-produkt.
Det finns en DVB-standard för DASH med låg latens och DASH Industry Forum har godkänt flera låg-latens-lägen för DASH att ingå i deras nästa riktlinjer för driftskompatibilitet. Enligt alla dessa specifikationer har kodare- och spelarutvecklare och innehållsleveransnätverk arbetat i flera år för att säkerställa interoperabilitet så att alla DASH / CMAF-applikationer med låg latens bör slå igång.
Som ett exempel visade Harmonic och Akamai tillsammans CMAF med låg latens så långt tillbaka som NAB och IBC 2017, vilket visar live OTT-leverans med en latens under fem sekunder. Sedan dess har Harmonic integrerat DASH-funktion med låg latens i sina apparatbaserade produkter (Packager XOS och Electra XOS) och SaaS-lösningar (VOS Cluster och VOS260). Många andra leverantörer av kodare och spelare har gjort detsamma.
Oavsett om du väljer att implementera Low Latency HLS eller Low Latency för DASH eller båda, bör övergången från din befintliga HLS- och / eller DASH-leveransarkitektur vara relativt sömlös och billig.
5. Kommunikation i realtid
WebRTC är vanligtvis motorn för ett integrerat paket som inkluderar kodaren, spelaren och leveransinfrastrukturen. Exempel på WebRTC-baserade storskaliga streaminglösningar inkluderar Real Time from Phenix, Limelight Realtime Streaming och Millicast från CoSMo Software and Influxis (Figur 3). Du kan också komma åt WebRTC-teknik i verktyg som Wowza Streaming Engine, CoSMO Software och Red 5 Pro Server. Fördröjningstider för tekniker i denna klass sträcker sig från .5 sekunder för 71% av strömmarna (Phenix), under 500 millisekunder (Red5 Pro), till under en sekund (Limelight). Om du behöver latens på två sekunder är WebRTC ett alternativ du måste överväga.
Om du behöver kommunikation i realtid måste du antagligen implementera antingen en WebRTC- eller Websockets-baserad lösning. WebRTC har formulerats för webbläsare-till-webbläsarkommunikation och stöds av alla större stationära webbläsare, på Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 och BlackBerry 10, så det ska köras utan nedladdningar på någon av dessa plattformar. Som namnet antyder är WebRTC ett protokoll för att leverera liveströmmar till varje tittare, antingen peer-to-peer eller server till peer.
WebSockets är ett realtidsprotokoll som skapar och upprätthåller en ihållande anslutning mellan en server och klient som endera parten kan använda för att överföra data. Denna anslutning kan användas för att stödja både videoleverans och annan kommunikation, så det är bekvämt om din applikation behöver interaktivitet. Liksom WebRTC-implementeringar erbjuds tjänster som använder WebSockets vanligtvis som en tjänst som inkluderar spelare och CDN, och du kan använda valfri kodare som kan transportera strömmar till servern via RTMP eller WebRTC. Exempel är Nanocosmos nanoStream Cloud och Wowzas Streaming Cloud With Ultra Low Latency. Wowza hävdar sub-3 sekunders latens för sin lösning medan Nanocosmos hävdar cirka en sekund, glas till glas.
Andra tekniker med låg latens
Det finns en fjärde kategori av produkter som bäst kallas ”andra” som använder olika tekniker för att ge låg latens. Denna kategori inkluderar THEO Technologies High Efficiency Streaming Protocol (HESP), ett proprietärt HTTP-adaptivt streamingprotokoll som enligt THEO levererar under 100 millisekunders latens samtidigt som bandbredden minskas med cirka 10% jämfört med andra tekniker med låg latens. HESP använder standardkodare och CDN: er men kräver anpassat stöd i förpackaren och spelaren (Figur 4). Du kan läsa mer om HESP i en vitbok som kan laddas ner här.
Här är en lista med frågor du bör tänka på när du bestämmer vilken teknik med låg latens som ska implementeras och hur du gör det.
Bygga eller köpa?
Om du implementerar tekniken själv, var noga med att svara på alla frågor som listas nedan innan du väljer en teknik. Om du väljer en tjänsteleverantör kan du jämföra de olika tjänsteleverantörerna med dem.
Väljer du en standard eller en partner?
Vi har beskrivit de olika teknikerna för att uppnå låg latens ovan, men implementeringarna varierar från tjänsteleverantör till tjänsteleverantör. Så inte alla LL HLS-implementeringar kommer att inkludera ABR-leverans, åtminstone inte först. De flesta traditionella sändningsliknande applikationer kommer sannolikt att migrera mot HTTP-baserade standarder som HLS / DASH / CMAF med låg latens medan applikationer som kräver ultra-låg latens som vadslagning och auktioner kommer att dra till andra tekniker. I båda fallen är det viktigare att bestämma om de kan uppfylla dina tekniska och affärsmål än vilken teknik de faktiskt implementerar när du väljer en tjänsteleverantör.
Kan den skala och till vilken kostnad?
En av fördelarna med HTTP-baserad teknik är att de skalas till standardprissättning med de flesta CDN. Däremot kräver de flesta WebRTC- och WebSocket-baserade tekniker en dedikerad leveransinfrastruktur implementerad av tjänsteleverantören. Av denna anledning kan icke-HTTP-baserade tjänster vara dyrare att leverera än HLS / DASH / CMAF. När du jämför tjänsteleverantörer, kontrollera soppan till nötterna för evenemanget, inklusive inträde, omkodning, bandbredd, skapande av VOD-filer, engångskonfigurationer eller per händelsekonfigurationer och liknande.
Implementeringsrelaterade frågor?
Ställ följande frågor relaterade till implementering och användning av tekniken.
- Vilken latens uppnås på en skala som är relevant för din målgruppsstorlek och geografiska fördelning?
- Finns det några kvalitetsbegränsningar - vissa tekniker kan vara begränsade till vissa maximala upplösningar eller H.264-profiler.
- Kommer paketen att passera genom en brandvägg? HTTP-baserade system använder HTTP-protokoll, som är brandväggsvänliga. Andra använder UDP, som kanske inte passerar genom brandväggar automatiskt. Om UDP, finns det några bakkanaler att leverera till blockerade tittare?
- Vilka plattformar stöds? Antagligen datorer och mobila enheter, men hur är det med STB: er, donglar, OTT-enheter och smarta TV-apparater?
- Kan systemet skalas för att möta dina målvisningsnummer? Är CDN-infrastrukturen privat, och i så fall kan den leverera till alla relevanta tittare på alla relevanta marknader? Vilka är de förväntade kostnaderna för skalning?
- Kan du använda din egen spelare eller måste du använda systemets spelare? Om din egen, vilka ändringar krävs och hur mycket kommer det att kosta?
- Vad behövs för mobil uppspelning? Kommer strömmarna att spelas i en webbläsare eller krävs en app? Om det behövs en app (eller önskvärt) finns SDK: er tillgängliga?
- Vilka kodare kan systemet använda? De flesta borde använda valfri kodare som kan stödja RTMP-anslutningar till molnet, men kontrollera om andra protokoll behövs.
- Kan innehållet återanvändas för VOD eller krävs omkodning? Inte en enorm affär eftersom det kostar ungefär $ 20 / timme video att omkoda till en rimlig kodningsstege men dyr för frekventa sändningar.
- Vilka är uppsägningsalternativen och vad kostar det? För uppdragskritiska sändningar vill du veta hur du kopierar arbetsflödet för kodning / sändning om någon systemkomponent skulle sjunka under evenemanget. Stöds denna redundans och vad kostar det?
Vilka funktioner finns och i vilken skala?
Det kommer att finnas ett brett utbud av funktionserbjudanden från olika leverantörer, som kanske eller inte inkluderar:
- ABR-streaming - hur många strömmar och finns det några relevanta bithastigheter eller upplösningsbegränsningar?
- Vad sägs om DVR-funktioner? Kan tittarna stoppa och starta om uppspelningen utan att förlora något innehåll.
- Videosynkronisering - Kan systemet synkronisera alla tittare till samma punkt i strömmen? Strömmar kan glida över platser och enheter, och utan denna möjlighet kan användare på vissa anslutningar ha en fördel för auktioner eller spel.
- Vilket innehållsskydd finns tillgängligt? Om du är en premiuminnehållsproducent kan du behöva äkta DRM. Andra kan klara sig med autentisering eller andra liknande tekniker.
- Finns bildtexter? Bildtexter krävs enligt lag för vissa sändningar men i allmänhet fördelaktiga för alla.
- Vad sägs om reklaminsättning eller annat schema för intäktsgenerering? Stöder teknik- / tjänsteleverantören detta?
I allmänhet, om du är en streamingbutik som vill möta eller slå sändningstider inom 5 till 6 sekunders intervall, är en standardbaserad HTTP-teknik förmodligen din bästa insats, eftersom den kommer närmast att stödja samma funktion som du ' använder för närvarande, som innehållsskydd, bildtexter och intäktsgenerering. Om du har ett program som kräver mycket lägre latens behöver du förmodligen en WebRTC- eller Websockets-baserad lösning eller en egen HTTP-teknik. I båda fallen kan du ställa frågorna ovan som hjälper dig att identifiera den teknik och / eller tjänsteleverantör som bäst uppfyller dina behov.