Lav ventetid er en universell ambisjon i media. Når et selskap som Wowza produserer det perfekte diagrammet for å forklare streaming-teknologier med lav latens, må du ta hatten av dem og bruke diagrammet med tilskrivning og noen mindre endringer. Jeg presenterte nevnte diagram som figur 1; la oss diskutere i den rekkefølgen som er angitt av de uthevede tallene jeg har lagt til.
1. Søknader om lav latens
PRODUKTGUIDE
Beste PTZ-kameraer for live streaming
Bare for å være sikker på at vi alle er på samme side, betyr ventetid i sammenheng med live streaming forsinkelsen mellom glass og glass. Det første glasset er kameraet ved selve live-arrangementet, det andre er skjermen du ser på. Forsinkelse er forsinkelsen mellom når vises i kameraet og når det vises på telefonen din. Å bidra til ventetid er faktorer som kodingstid (på arrangementet), transporttid til skyen, transkodingstid i skyen (for å lage kodestigen), leveringstid og kritisk hvor mange sekunder spilleren din buffrer før du begynner å spille.
Det øverste laget viser typiske applikasjoner og krav til ventetid. Populære applikasjoner som mangler lav latens og nær sanntid er gambling og auksjonssteder.
Før du dykker inn i teknologidiskusjonen vår, må du forstå at jo lavere ventetid på live-strømmen din er, desto mindre motstandsdyktig er strømmen mot båndbreddeavbrudd. For eksempel, ved å bruke standardinnstillinger, vil en HLS-strøm spille gjennom 15+ sekunders avbrutt båndbredde, og hvis den er gjenopprettet på det tidspunktet, kan viseren aldri vite at det var et problem. Derimot vil en strøm med lav latens stoppe å spille nesten umiddelbart etter et avbrudd. Så fordelen med oppstartstid med lav ventetid må alltid balanseres mot det negative av stopp i avspilling. Hvis du ikke absolutt trenger lav ventetid, kan det ikke lønne seg å ofre spenst for å få det.
Når det er sagt, er det nyttig å dele ventetid i tre kategorier, som følger.
PRO NYHETSBREVAudio + Video + IT. Våre redaktører er eksperter på å integrere lyd / video og IT. Få daglig innsikt, nyheter og profesjonelt nettverk. Abonner på Pro AV Today.
- Fint å ha - Raskere er alltid bedre, men hvis du livestrømmer et Board of Education-møte eller videregående fotballkamp, kan du bestemme at strømstyrke er viktigere enn lav ventetid, spesielt hvis mange seere ser på forbindelser med lav bithastighet.
- Konkurransefordel - I noen tilfeller gir lav latens et konkurransefortrinn, eller langsom latens betyr en konkurransemessig ulempe. Du vil merke i diagrammet at den typiske ventetiden for kabel-TV er rundt fem sekunder. Hvis streamingtjenesten din konkurrerer mot kabel, må du være i det området, med lavere ventetid som gir et beskjedent konkurransefortrinn.
- Kommunikasjon i sanntid - Hvis du er et spill- eller auksjonssted, eller hvis søknaden din ellers krever kommunikasjon i sanntid, må du absolutt levere lav ventetid.
- Live streaming sammenligningsguide
- Hvordan forutsi suksess for kodek
Nå som vi kjenner til kategoriene, la oss se på den mest effektive måten å levere det nødvendige nivået med lav ventetid.
2/3 Fint å ha lav ventetid
Nummeret 2 viser at Apple HLS og MPEG-DASH distribuert ved hjelp av standardinnstillingene resulterer i omtrent 30 sekunders ventetid. Tallene er enkle; hvis du bruker ti sekunders segmentstørrelser og krever at tre segmenter er i spillerbufferen før avspilling starter, er du på tretti sekunder. I sannhet endret Apple sine krav fra ti sekunder til seks sekunder for noen år siden, og de fleste DASH-produsenter bruker 4-6 sekunders segmenter, så standardnummeret er virkelig nærmere 20 sekunder.
Likevel viser nummer 3, HLS Tuned og DASH Tuned, ventetid på rundt 6-8 sekunder. I hovedsak betyr tuning å bytte fra 10 sekunders segmenter til 2 sekunders segmenter som, ved å bruke samme matte, gir 6-8 sekunders ventetid. Så når ventetid er hyggelig å ha, kan du kutte ventetid dramatisk uten utviklingstid eller kostnad, eller betydelig økt leveringsrisiko.
4. Konkurransedyktig fordel - HTTP-teknologier med lav latens
Når det er behov for lav latens som et konkurransefortrinn, vil ikke bare kutte segmentstørrelser gjøre det. må du implementere en ekte teknologi med lav latens. Her er det to klasser; HTTP-teknologier som HLS med lav latens og CMAF med lav latens for DASH, og løsninger basert på andre teknologier, som WebSockets og WebRTC.
For de fleste produsenter med applikasjoner i denne klassen tilbyr HTTP-teknologier med lav latens den beste blandingen av overkommelighet, bakoverkompatibilitet, fleksibilitet og funksjonssett. Så jeg vil dekke Low Latency HLS og Low-Latency CMAF for DASH i denne delen, og andre teknologier i det neste.
Alle HLS / DASH / CMAF-baserte systemer med lav latens fungerer på samme grunnleggende måte, som vist i figur 2. Det vil si i stedet for å vente til et komplett segment er kodet, som vanligvis tar mellom 6-10 sekunder (toppen av figur 2) , lager koderen mye kortere biter som overføres til CDN så snart de er ferdige (nederst i figur 2).
Som et eksempel, hvis koderen din produserte seks sekunders segmenter, ville du ha minst seks sekunders ventetid; tredobbelt at hvis de normale tre segmentene måtte mottas av betrakteren før avspilling begynner. Hvis koderen din skjøv ut biter hver 200 millisekund, og spilleren ble konfigurert til å starte avspilling umiddelbart, burde ventetiden være mye, mye mindre. En viktig fordel med dette skjemaet er bakoverkompatibilitet; siden segmenter fremdeles blir opprettet, bør spillere som ikke er kompatible med skjemaet med lav latens, fremdeles kunne spille segmentene, om enn med lengre ventetid. Disse segmentene er også umiddelbart tilgjengelige for VOD-presentasjoner fra live stream.
Utover disse fordelene støtter HTTP-teknologier med lav latens de fleste funksjonene til deres normale latensøsken, inkludert kryptering, reklameinnsetting og teksting, som ikke er universell støtte i WebRTC og WebSockets-baserte teknologier. Du kan sannsynligvis implementere den valgte teknologien med lav latens ved å bruke din eksisterende spiller og leveringsinfrastruktur, og minimere utvikling og andre teknologikostnader.
Velge en HTTP-teknologi med lav latens
Det er to hovedstandarder for HTTP Adaptive Streaming, HLS og DASH, pluss et samlende containerformat, CMAF. Når Apple kunngjorde HLS-løsningen med lav latens, fortrengte den øyeblikkelig flere grasrotinnsatser og ble den valgte teknologien for å levere lav ventetid til HLS. Selv om spesifikasjonen fortsatt er relativt ny, støttes den allerede av teknologileverandører som Wowza og WMSPanel med sitt Nimble Streamer-produkt.
Det er en DVB-standard for DASH med lav latens, og DASH Industry Forum har godkjent flere lavforsinkelsesmoduser for DASH som skal inkluderes i deres neste retningslinjer for interoperabilitet. I henhold til alle disse spesifikasjonene har kode- og spillerutviklere og innholdsleveringsnettverk jobbet i flere år for å sikre interoperabilitet, slik at alle DASH / CMAF applikasjoner med lav latens skal slå i bakken.
Som et eksempel demonstrerte Harmonic og Akamai sammen CMAF med lav latens så langt tilbake som NAB og IBC 2017, og viste live OTT-levering med en latens under fem sekunder. Siden den gang har Harmonic integrert DASH-funksjonalitet med lav latens i sine enhetsbaserte produkter (Packager XOS og Electra XOS) og SaaS-løsninger (VOS Cluster og VOS260). Mange andre kode- og spilleleverandører har gjort det samme.
Enten du velger å implementere lav latens HLS eller lav latens for DASH, eller begge deler, bør overgangen fra din eksisterende HLS og / eller DASH leveringsarkitektur være relativt sømløs og billig.
5. Sanntidskommunikasjon
WebRTC er vanligvis motoren for en integrert pakke som inkluderer koderen, spilleren og leveringsinfrastrukturen. Eksempler på WebRTC-baserte streamingløsninger i stor skala inkluderer Real Time from Phenix, Limelight Realtime Streaming og Millicast fra CoSMo Software og Influxis (figur 3). Du kan også få tilgang til WebRTC-teknologi i verktøy som Wowza Streaming Engine, CoSMO Software og Red 5 Pro Server. Forsinkelsestider for teknologier i denne klassen varierer fra 0,5 sekunder for 71% av bekker (Phenix), under 500 millisekunder (Red5 Pro), til under ett sekund (rampelys). Hvis du trenger forsinkelse på to sekunder, er WebRTC et alternativ du må vurdere.
Hvis du trenger sanntidskommunikasjon, vil du sannsynligvis trenge å implementere enten en WebRTC- eller Websockets-basert løsning. WebRTC ble formulert for nettleser-til-nettleserkommunikasjon og støttes av alle større stasjonære nettlesere, på Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 og BlackBerry 10, så den skal kjøre uten nedlastinger på noen av disse plattformene. Som navnet antyder, er WebRTC en protokoll for å levere live streams til hver seer, enten peer-to-peer eller server til peer.
WebSockets er en sanntidsprotokoll som oppretter og vedlikeholder en vedvarende forbindelse mellom en server og klient som begge parter kan bruke til å overføre data. Denne tilkoblingen kan brukes til å støtte både videoleveranse og annen kommunikasjon, så det er praktisk hvis applikasjonen din trenger interaktivitet. I likhet med WebRTC-implementeringer tilbys tjenester som bruker WebSockets vanligvis som en tjeneste som inkluderer spiller og CDN, og du kan bruke hvilken som helst koder som kan transportere strømmer til serveren via RTMP eller WebRTC. Eksempler inkluderer Nanocosmos ’nanoStream Cloud og Wowzas Streaming Cloud With Ultra Low Latency. Wowza hevder sub-3 sekunders latens for løsningen mens Nanocosmos hevder rundt ett sekund, glass til glass.
Andre teknologier med lav latens
Det er en fjerde kategori av produkter som best kalles “annet” som bruker forskjellige teknologier for å gi lav ventetid. Denne kategorien inkluderer THEO Technologies High Efficiency Streaming Protocol (HESP), en proprietær HTTP-adaptiv streamingprotokoll som ifølge THEO leverer under 100 millisekunders latenstid mens den reduserer båndbredden med ca. 10% sammenlignet med andre teknologier med lav latens. HESP bruker standard kodere og CDNer, men krever tilpasset støtte i pakker og spiller (figur 4). Du kan lese mer om HESP i et dokument som er tilgjengelig for nedlasting, her.
Her er en liste med spørsmål du bør vurdere når du bestemmer hvilken teknologi med lav latens som skal implementeres og hvordan du gjør det.
Bygg eller kjøp?
Hvis du implementerer teknologien selv, må du svare på alle spørsmålene nedenfor før du velger en teknologi. Hvis du velger en tjenesteleverandør, kan du bruke dem til å sammenligne de forskjellige tjenesteleverandørene.
Velger du en standard eller en partner?
Vi har skissert de forskjellige teknologiene for å oppnå lav ventetid ovenfor, men implementeringer varierer fra tjenesteleverandør til tjenesteleverandør. Så ikke alle LL HLS-implementeringer vil omfatte levering av ABR, i det minste ikke først. De fleste tradisjonelle kringkastingslignende applikasjoner vil sannsynligvis migrere mot HTTP-baserte standarder som HLS / DASH / CMAF med lav latens, mens applikasjoner som krever ultra-lav latens som veddemål og auksjoner vil trekke seg mot de andre teknologiene. I begge tilfeller er det viktigere å bestemme om de kan oppfylle dine teknologiske og forretningsmessige mål enn hvilken teknologi de faktisk implementerer når du velger en tjenesteleverandør.
Kan den skaleres og til hvilken pris?
En av fordelene med HTTP-baserte teknologier er at de skaleres til standardpriser ved bruk av de fleste CDN-er. I motsetning til dette krever de fleste WebRTC- og WebSocket-baserte teknologier en dedikert leveringsinfrastruktur implementert av tjenesteleverandøren. Av denne grunn kan ikke-HTTP-baserte tjenester være dyrere å levere enn HLS / DASH / CMAF. Når du sammenligner tjenesteleverandører, må du fastslå suppen til kostnadene ved arrangementet, inkludert inngang, transkoding, båndbredde, opprettelse av VOD-filer, engangskonfigurasjoner eller konfigurasjoner per hendelse og lignende.
Implementeringsrelaterte problemer?
Still følgende spørsmål knyttet til implementering og bruk av teknologien.
- Hva er ventetiden som kan oppnås på en skala som er relevant for målgruppestørrelse og geografisk fordeling?
- Er det noen kvalitetsbegrensninger - Noen teknologier kan være begrenset til visse maksimale oppløsninger eller H.264-profiler.
- Vil pakkene passere gjennom en brannmur? HTTP-baserte systemer bruker HTTP-protokoller, som er brannmurvennlige. Andre bruker UDP, som kanskje ikke går gjennom brannmurer automatisk. Hvis UDP, er det noen backchannels å levere til blokkerte seere?
- Hvilke plattformer støttes? Antagelig datamaskiner og mobile enheter, men hva med STB, dongler, OTT-enheter og smarte TV-er?
- Kan systemet skaleres for å oppfylle målvisertallene dine? Er CDN-infrastrukturen privat, og i så fall kan den levere til alle relevante seere i alle relevante markeder? Hva er forventede kostnader for skalering?
- Kan du bruke din egen spiller, eller må du bruke systemets spiller? Hvis dine egne, hvilke endringer er nødvendige og hvor mye vil det koste?
- Hva er nødvendig for mobilavspilling? Vil strømmene spille i en nettleser, eller er det nødvendig med en app? Hvis det kreves en app (eller ønskelig), er SDK-er tilgjengelige?
- Hvilke kodere kan systemet bruke? De fleste bør bruke en hvilken som helst kode som kan støtte RTMP-tilkoblinger til skytranskoderen, men sjekk om det er behov for andre protokoller.
- Kan innholdet brukes på nytt for VOD, eller vil det kreves omkoding? Ikke en stor avtale siden det koster omtrent $ 20 / time video å omkode til en rimelig kodestige, men dyr for hyppige sendinger.
- Hva er alternativene for permittering og hva koster det? For oppdragskritiske sendinger, vil du vite hvordan du kopierer arbeidsflyten for koding / kringkasting hvis en hvilken som helst systemkomponent skulle gå ned under arrangementet. Støttes denne redundansen, og hva koster det?
Hvilke funksjoner er tilgjengelige og i hvilken skala?
Det vil være et bredt utvalg av funksjonstilbud fra de forskjellige leverandørene, som kan eller ikke inkluderer:
- ABR-streaming - hvor mange strømmer og er det noen relevante bithastighet eller oppløsningsbegrensninger?
- Hva med DVR-funksjoner? Kan seerne stoppe og starte avspillingen uten å miste noe innhold.
- Videosynkronisering - Kan systemet synkronisere alle seere til samme punkt i strømmen? Strømmer kan drive over steder og enheter, og uten denne muligheten kan brukere på noen tilkoblinger ha en fordel for auksjoner eller pengespill.
- Hvilken innholdsbeskyttelse er tilgjengelig? Hvis du er en førsteklasses produsent av innhold, trenger du kanskje ekte DRM. Andre kan klare seg med autentisering eller andre lignende teknikker.
- Er billedtekst tilgjengelig? Teksting er lovlig påkrevd for noen sendinger, men generelt sett gunstig for alle.
- Hva med annonseinnsetting eller annet inntektsskjema? Støtter teknologien / tjenesteleverandøren dette?
Generelt sett, hvis du er en streamingbutikk som ønsker å møte eller slå sendetid i 5 til 6 sekunders rekkevidde, er sannsynligvis en standardbasert HTTP-teknologi det beste alternativet, siden det kommer nærmest å støtte den samme funksjonen som setter deg ' bruker for øyeblikket, som innholdsbeskyttelse, bildetekst og inntektsgenerering. Hvis du har et program som krever mye lavere ventetid, trenger du sannsynligvis en WebRTC- eller Websockets-basert løsning eller en egenutviklet HTTP-teknologi. I begge tilfeller kan det å stille spørsmålene ovenfor, hjelpe deg med å identifisere teknologien og / eller tjenesteleverandøren som best oppfyller dine behov.
