Niska latencija univerzalna je težnja medija. Kada tvrtka poput Wowze izradi savršen grafikon za objašnjenje tehnologija strujanja s malim kašnjenjem, morate im skinuti kapu i koristiti grafikon s atributom i nekim manjim izmjenama. Rečeni grafikon predstavljam kao sliku 1; razgovarajmo redom označenim brojevima koje sam dodao.
1. Prijave za malu latenciju
VODIČ ZA PROIZVODE
Najbolje PTZ kamere za streaming uživo
Samo da bismo bili sigurni da smo svi na istoj stranici, latencija u kontekstu streaminga uživo znači kašnjenje od stakla do stakla. Prva čaša je kamera na stvarnom događaju uživo, druga je zaslon koji gledate. Latencija je kašnjenje između pojavljivanja u fotoaparatu i kada se pojavi na vašem telefonu. Latenciji pridonose čimbenici kao što su vrijeme kodiranja (na događaju), vrijeme prijenosa u oblak, vrijeme prekodiranja u oblaku (radi stvaranja ljestvice za kodiranje), vrijeme isporuke i kritično koliko sekundi vaš igrač baferira prije početka igre.
Gornji sloj prikazuje tipične primjene i njihove zahtjeve za latencijom. Popularne aplikacije koje nedostaju zbog niske latencije i kašnjenja gotovo u stvarnom vremenu su web stranice za kockanje i aukcije.
Prije nego što uđete u našu raspravu o tehnologiji, shvatite da što je niža latencija vašeg prijenosa uživo, to je stream manje otporan na prekide propusnosti. Na primjer, pomoću zadanih postavki, HLS stream reproducirat će se preko 15 sekundi prekinutog propusnog opsega, a ako se u tom trenutku obnovi, gledatelj možda nikad neće znati da je bilo problema. Suprotno tome, tok s malim kašnjenjem prestat će se reproducirati gotovo odmah nakon prekida. Dakle, korist od vremena pokretanja s malim kašnjenjem uvijek treba uravnotežiti s negativnom zaustavljanjem u reprodukciji. Ako vam apsolutno nije potrebna mala latencija, možda se ne isplati žrtvovati elastičnost da biste je dobili.
Međutim, korisno je latentnost podijeliti u tri kategorije, kako slijedi.
PRO BILTENAudio + Video + IT. Naši urednici su stručnjaci za integraciju audio / video i IT-a. Dobijte svakodnevne uvide, vijesti i profesionalno umrežavanje. Pretplatite se na Pro AV danas.
- Lijepo je imati - Brže je uvijek bolje, ali ako uživo prenosite sastanak odbora za obrazovanje ili nogometnu utakmicu u srednjoj školi, možda ćete odlučiti da je robusnost prijenosa važnija od niske latencije, osobito ako mnogi gledatelji gledaju na vezama s malim brzinama.
- Konkurentska prednost - U nekim slučajevima, mala latencija pruža konkurentsku prednost, ili spora latencija znači konkurentski nedostatak. Na grafikonu ćete primijetiti da je uobičajena latencija kabelske televizije oko pet sekundi. Ako se vaša usluga streaminga natječe s kabelom, morate biti u tom rasponu, a niža kašnjenja pružaju skromnu konkurentsku prednost.
- Komunikacija u stvarnom vremenu - Ako ste mjesto za kockanje ili dražbu ili vaša aplikacija na drugi način zahtijeva komunikaciju u stvarnom vremenu, apsolutno morate pružiti malu kašnjenje.
- Vodič za usporedbu prijenosa uživo
- Kako predvidjeti uspjeh kodeka
Sad kad znamo kategorije, pogledajmo najučinkovitiji način za postizanje potrebne razine niske latencije.
2/3 Lijepo je imati malu kašnjenje
Broj 2 pokazuje da su Apple HLS i MPEG-DASH implementirani pomoću njihovih zadanih postavki rezultirali oko 30 sekundi latencije. Brojevi su jednostavni; ako koristite veličine od deset sekundi i želite da tri segmenta budu u međuspremniku playera prije početka reprodukcije, na trideset ste sekundi. Zapravo, Apple je prije nekoliko godina promijenio svoje zahtjeve s deset na šest sekundi, a većina proizvođača DASH-a koristi segmente od 4 do 6 sekundi, pa je zadani broj zaista bliži 20 sekundi.
Ipak, broj 3, HLS Tuned i DASH Tuned, pokazuje kašnjenje od oko 6-8 sekundi. U osnovi, ugađanje znači promjenu s 10-sekundnih segmenata na 2-sekundne segmente koji, primjenom iste matematike, daju 6-8 sekundi latencije. Dakle, kada je kašnjenje lijepo imati, možete dramatično smanjiti kašnjenje bez vremena za razvoj ili troškova ili znatno povećanog rizika isporučivosti.
4. Konkurentska prednost - HTTP tehnologije s malim kašnjenjem
Kada je niska latencija potrebna kao konkurentska prednost, samo rezanje veličina segmenata to neće učiniti; morat ćete primijeniti istinsku tehnologiju s malim kašnjenjem. Ovdje postoje dva razreda; HTTP tehnologije poput HLS-a s niskim kašnjenjem i CMAF-a s malim kašnjenjem za DASH, te rješenja temeljena na drugim tehnologijama, poput WebSockets i WebRTC.
Većini proizvođača s aplikacijama u ovoj klasi HTTP tehnologije s malim kašnjenjem nude najbolju kombinaciju pristupačnosti, povratne kompatibilnosti, fleksibilnosti i skupa značajki. Dakle, pokrivat ću HLS s niskim kašnjenjem i CMAF s niskim kašnjenjem za DASH u ovom odjeljku, a ostale tehnologije u sljedećem.
Svi sustavi niske latencije temeljeni na HLS / DASH / CMAF-u rade na isti osnovni način, kao što je prikazano na slici 2. To jest, umjesto da čekaju dok se ne kodira cijeli segment, što obično traje između 6-10 sekundi (vrh slike 2) , koder stvara puno kraće dijelove koji se prenose na CDN čim završe (dno slike 2).
Na primjer, ako vaš koder proizvodi segmente od šest sekundi, imali biste najmanje šest sekundi latencije; trostruko ako bi gledatelj trebao primiti normalna tri segmenta prije početka reprodukcije. Međutim, ako je vaš koder istiskivao dijelove svakih 200 milisekundi, a uređaj je konfiguriran da odmah započne reprodukciju, kašnjenje bi trebalo biti puno, puno manje. Jedna od ključnih prednosti ove sheme je povratna kompatibilnost; budući da se segmenti još uvijek izrađuju, igrači koji nisu kompatibilni sa shemom s malim kašnjenjem i dalje bi trebali moći reproducirati segmente, iako s duljom latencijom. Ti su segmenti odmah dostupni i za VOD prezentacije iz prijenosa uživo.
Osim ovih prednosti, HTTP tehnologije s niskim kašnjenjem podržavaju većinu značajki svoje uobičajene braće i sestara s latencijom, uključujući šifriranje, umetanje reklama i titlovanje, što nije univerzalna podrška u tehnologijama temeljenim na WebRTC i WebSockets. Vjerojatno možete implementirati odabranu tehnologiju s malim kašnjenjem koristeći postojeći player i infrastrukturu isporuke, minimalizirajući razvoj i druge tehnološke troškove.
Odabir HTTP tehnologije s malim kašnjenjem
Postoje dva glavna standarda za HTTP prilagodljivo strujanje, HLS i DASH, plus objedinjeni format spremnika, CMAF. Jednom kada je Apple najavio svoje HLS rješenje s malim kašnjenjem, odmah je istisnuo nekoliko osnovnih napora i postao tehnologija odabira za isporuku niske latencije HLS-u. Iako su specifikacije još uvijek relativno nove, pružatelji tehnologije poput Wowza i WMSPanel već ih podržavaju svojim proizvodom Nimble Streamer.
Postoji DVB standard za DASH s malim kašnjenjem, a industrijski forum DASH odobrio je nekoliko načina s niskom latencijom za DASH koji će se uključiti u njihove sljedeće smjernice za interoperabilnost. Sukladno svim ovim specifikacijama, programeri kodera i playera te mreže za dostavu sadržaja rade već nekoliko godina kako bi osigurali interoperabilnost tako da bi sve aplikacije DASH / CMAF s malim kašnjenjem trebale udariti u tlo.
Kao primjer, Harmonic i Akamai zajedno su pokazali CMAF s niskom latencijom još do NAB-a i IBC-a 2017, pokazujući OTT isporuku uživo s latencijom ispod pet sekundi. Od tada je Harmonic integrirao DASH funkcionalnost s malim kašnjenjem u svoje proizvode koji se temelje na uređajima (Packager XOS i Electra XOS) i SaaS rješenja (VOS Cluster i VOS260). Mnogi drugi dobavljači kodera i playera učinili su isto.
Bilo da se odlučite za implementaciju HLS-a s malim kašnjenjem ili s niskom latencijom za DASH, ili oboje, prijelaz s vaše postojeće arhitekture isporuke HLS-a i / ili DASH-a trebao bi biti relativno lagan i jeftin.
5. Komunikacije u stvarnom vremenu
WebRTC je obično pokretač integriranog paketa koji uključuje koder, player i infrastrukturu isporuke. Primjeri rješenja za strujanje velikih razmjera temeljenih na WebRTC-u uključuju Real Time iz Phenixa, Limelight Realtime Streaming i Millicast iz CoSMo Software i Influxis (slika 3). Tehnologiji WebRTC možete pristupiti i u alatima poput Wowza Streaming Engine, CoSMO Software i Red 5 Pro Server. Vremena kašnjenja za tehnologije ove klase kreću se od, 5 sekundi za 71% streamova (Phenix), manje od 500 milisekundi (Red5 Pro), do manje od jedne sekunde (Limelight). Ako trebate latenciju ispod dvije sekunde, WebRTC je opcija koju trebate uzeti u obzir.
Ako su vam potrebne komunikacije u stvarnom vremenu, vjerojatno ćete trebati implementirati rješenje temeljeno na WebRTC ili Websockets. WebRTC je formuliran za komunikaciju između preglednika i podržavaju ga svi glavni preglednici za stolna računala, na Androidu, iOS-u, Chrome OS-u, Firefox OS-u, Tizen 3.0 i BlackBerry 10, pa bi se trebao pokretati bez preuzimanja na bilo kojoj od ovih platformi. Kao što i samo ime govori, WebRTC je protokol za isporuku prijenosa uživo svakom gledatelju, bilo ravnopravnom ili poslužitelju.
WebSockets je protokol u stvarnom vremenu koji stvara i održava trajnu vezu između poslužitelja i klijenta kojeg bilo koja strana može koristiti za prijenos podataka. Ova se veza može koristiti za isporuku video zapisa i druge komunikacije, tako da je prikladna ako vaš program treba interaktivnost. Kao i implementacije WebRTC-a, usluge koje koriste WebSockets obično se nude kao usluga koja uključuje player i CDN, a možete koristiti bilo koji koder koji može prenositi streamove na poslužitelj putem RTMP-a ili WebRTC-a. Primjeri uključuju Nanocosmos nanoStream Cloud i Wowza Streaming Cloud s ultra malom kašnjenjem. Wowza tvrdi da je za njihovo rješenje kašnjenje ispod 3 sekunde, dok Nanocosmos tvrdi oko jedne sekunde, staklo na staklo.
Ostale tehnologije s malim kašnjenjem
Postoji četvrta kategorija proizvoda koja se najbolje naziva "ostalo" i koriste različite tehnologije kako bi osigurale malu kašnjenje. Ova kategorija uključuje THEO Technologies High Efficiency Streaming Protocol (HESP), vlasnički HTTP prilagodljivi protokol za streaming koji prema THEO-u pruža latenciju ispod 100 milisekundi, istovremeno smanjujući propusnost za oko 10% u usporedbi s ostalim tehnologijama s niskom latencijom. HESP koristi standardne kodere i CDN-ove, ali zahtijeva prilagođenu podršku u paketu i uređaju za reprodukciju (slika 4). Više o HESP-u možete pročitati u bijelom papiru dostupan za preuzimanje ovdje.
Evo popisa pitanja koja biste trebali uzeti u obzir prilikom odlučivanja koju tehnologiju s malim kašnjenjem primijeniti i kako to učiniti.
Graditi ili kupiti?
Ako sami implementirate tehnologiju, prije odabira tehnologije odgovorite na sva dolje navedena pitanja. Ako odabirete davatelja usluga, upotrijebite ih za usporedbu različitih davatelja usluga.
Birate li standard ili partnera?
Gore smo opisali različite tehnologije za postizanje niske latencije, ali implementacije se razlikuju od davatelja usluga do pružatelja usluga. Dakle, neće sva primjena LL HLS-a uključivati isporuku ABR-a, barem ne u početku. Većina tradicionalnih aplikacija sličnih emitiranju vjerojatno će se migrirati prema standardima temeljenim na HTTP-u, poput HLS / DASH / CMAF s malim kašnjenjem, dok će aplikacije koje zahtijevaju ultra nisku latenciju poput klađenja i aukcija gravitirati prema ostalim tehnologijama. U oba slučaja, prilikom odabira davatelja usluga važnije je utvrditi mogu li oni ispuniti vaše tehnološke i poslovne ciljeve, nego koju tehnologiju zapravo implementiraju.
Može li se skalirati i po kojoj cijeni?
Jedna od prednosti tehnologija temeljenih na HTTP-u je što se prilagođavaju standardnim cijenama koristeći većinu CDN-ova. Suprotno tome, većina tehnologija temeljenih na WebRTC i WebSocket zahtijeva namjensku infrastrukturu isporuke koju provodi davatelj usluga. Iz tog razloga, usluge koje se ne temelje na HTTP-u mogu biti skuplje isporučiti od HLS / DASH / CMAF. Kada uspoređujete pružatelje usluga, utvrdite cijenu događaja za juhu i orašaste plodove, uključujući ulaz, prekodiranje, propusnost, stvaranje VOD datoteke, jednokratne konfiguracije ili konfiguracije po događaju i slično.
Pitanja vezana uz provedbu?
Postavite sljedeća pitanja u vezi s primjenom i korištenjem tehnologije.
- Koja je latencija dostižna u mjerilu relevantnom za veličinu vaše publike i geografsku distribuciju?
- Postoje li ograničenja kvalitete - neke tehnologije mogu biti ograničene na određene maksimalne razlučivosti ili H.264 profile.
- Hoće li paketi proći kroz vatrozid? Sustavi temeljeni na HTTP-u koriste HTTP protokole koji su prilagođeni vatrozidu. Ostali koriste UDP koji možda neće automatski proći kroz vatrozid. Ako je UDP, postoje li povratni kanali za isporuku blokiranim gledateljima?
- Koje su platforme podržane? Vjerojatno računala i mobilni uređaji, ali što je sa STB-ovima, donglovima, OTT uređajima i pametnim televizorima?
- Može li sustav prilagoditi vaše ciljne brojeve gledatelja? Je li CDN infrastruktura privatna i ako može, može li je pružiti svim relevantnim gledateljima na svim relevantnim tržištima? Koji su predviđeni troškovi skaliranja?
- Možete li koristiti vlastiti player ili morate koristiti player sustava? Ako je vaš vlastiti, koje su promjene potrebne i koliko će to koštati?
- Što je potrebno za mobilnu reprodukciju? Hoće li se streamovi reproducirati u pregledniku ili je potrebna aplikacija? Ako postoji potrebna aplikacija (ili poželjna) jesu li dostupni SDK-ovi?
- Koje kodere sustav može koristiti? Većina bi trebala koristiti bilo koji koder koji može podržavati RTMP veze u transkoderu u oblaku, ali provjerite jesu li potrebni drugi protokoli.
- Može li se sadržaj ponovno koristiti za VOD ili će biti potrebno ponovno kodiranje? Nije velika stvar jer košta oko 20 USD / sat videozapisa za transkodiranje na razumnu ljestvicu kodiranja, ali skupo za česta emitiranja.
- Koje su mogućnosti tehnološkog viška i koji su troškovi? Za kritična emitiranja, trebali biste znati kako duplicirati tijek kodiranja / emitiranja ako bilo koja komponenta sustava padne tijekom događaja. Podržava li se ovaj višak i kolika je cijena?
Koje su značajke dostupne i u kojem opsegu?
Ponudit će se široka paleta značajki različitih dobavljača, što može uključivati ili ne uključivati:
- ABR streaming - koliko streamova i postoje li relevantna ograničenja brzine ili razlučivosti?
- Što je sa značajkama DVR-a? Mogu li gledatelji zaustaviti i ponovno pokrenuti reprodukciju bez gubitka sadržaja.
- Video sinkronizacija - Može li sustav sinkronizirati sve gledatelje na istu točku u streamu? Potoci se mogu prelijevati preko lokacija i uređaja, a bez te mogućnosti korisnici na nekim vezama mogu imati prednost za dražbe ili kockanje.
- Koja je zaštita sadržaja dostupna? Ako ste proizvođač vrhunskog sadržaja, možda će vam trebati pravi DRM. Drugi se mogu snaći autentifikacijom ili drugim sličnim tehnikama.
- Jesu li dostupni titlovi? Natpisi su zakonski potrebni za neka emitiranja, ali općenito su korisni za sve.
- Što je s umetanjem oglašavanja ili drugom shemom unovčavanja? Podržava li to pružatelj tehnologije / usluge?
Općenito, ako ste trgovina streamingom koja želi ispuniti ili nadmašiti vrijeme emitiranja u rasponu od 5 do 6 sekundi, HTTP tehnologija zasnovana na standardima vjerojatno je vaš najbolji ulog, jer će se najbliže podržati istu značajku koju ste postavili ' koji se trenutno koriste, poput zaštite sadržaja, opisa i unovčavanja. Ako imate aplikaciju koja zahtijeva mnogo niže kašnjenje, vjerojatno će vam trebati rješenje temeljeno na WebRTC ili Websockets, ili vlasnička HTTP tehnologija. U oba slučaja postavljanje gore navedenih pitanja trebalo bi vam pomoći da identificirate davatelja tehnologije i / ili usluge koji najbolje odgovara vašim potrebama.
