Nizka zakasnitev je univerzalna težnja medijev. Ko podjetje, kot je Wowza, izdela popoln grafikon za razlago tehnologij pretakanja z nizko zakasnitvijo, jim morate sleči klobuk in uporabiti grafikon z dodeljevanjem in nekaterimi manjšimi spremembami. Omenjeni grafikon predstavljam kot slika 1; razpravljajmo v vrstnem redu, označenem s poudarjenimi številkami, ki sem jih dodal.
1. Vloge za nizko zakasnitev
VODNIK IZDELKOV
Najboljše PTZ kamere za pretakanje v živo
Da se prepričamo, da smo vsi na isti strani, zakasnitev v okviru pretočnega predvajanja v živo pomeni zamudo od stekla do stekla. Prvi kozarec je kamera na dejanskem dogodku v živo, drugi je zaslon, ki ga gledate. Latencija je zakasnitev med tem, ko se kamera prikaže in ko se prikaže v telefonu. K zakasnitvi prispevajo dejavniki, kot so čas kodiranja (ob dogodku), čas prenosa v oblak, čas prekodiranja v oblaku (za ustvarjanje lestvice za kodiranje), čas dostave in kritično, koliko sekund predvajalnik shrani pred začetkom igranja.
Zgornja plast prikazuje tipične aplikacije in njihove zahteve glede zakasnitve. Priljubljene aplikacije, ki manjkajo z majhno zakasnitvijo in skoraj v realnem času, so spletna mesta za igre na srečo in dražbe.
Preden se potopite v našo tehnološko razpravo, se zavedajte, da nižja kot je zakasnitev vašega pretočnega predvajanja v živo, manj prožen je pretok prek pasovne širine. Na primer, z uporabo privzetih nastavitev se bo tok HLS predvajal prek 15 sekund prekinjene pasovne širine in če se obnovi v tem trenutku, gledalec morda nikoli ne bo vedel, da je prišlo do težave. V nasprotju s tem se bo tok z majhno zakasnitvijo skoraj takoj po prekinitvi ustavil. Torej je treba koristnost zagonskega časa z majhno zakasnitvijo vedno uravnotežiti z negativnimi zaustavitvami med predvajanjem. Če absolutno ne potrebujete nizke zakasnitve, se morda ne bi bilo vredno odrekati odpornosti, da bi jo dobili.
Kljub temu je koristno, da zakasnitev razdelimo v tri kategorije, kot sledi.
PRO NOVICEAvdio + Video + IT. Naši uredniki so strokovnjaki za povezovanje avdio / video in IT. Pridobite vsakodnevne vpoglede, novice in profesionalno mreženje. Naročite se na Pro AV danes.
- Lepo je imeti - Hitreje je vedno bolje, toda če v živo pretakate sejo odbora za izobraževanje ali nogometno tekmo srednje šole, se lahko odločite, da je robustnost prenosa pomembnejša od nizke zakasnitve, še posebej, če veliko gledalcev gleda na povezavah z nizko bitno hitrostjo.
- Konkurenčna prednost - V nekaterih primerih nizka zakasnitev zagotavlja konkurenčno prednost ali pa počasna zakasnitev pomeni konkurenčno slabost. V grafikonu boste opazili, da je običajna zakasnitev kabelske televizije približno pet sekund. Če vaša pretočna storitev tekmuje s kablom, morate biti v tem obsegu, z nižjo zakasnitvijo, ki zagotavlja skromno konkurenčno prednost.
- Komunikacije v realnem času - Če ste spletno mesto za igre na srečo ali dražbo ali če vaša aplikacija drugače zahteva komunikacijo v realnem času, morate nujno zagotoviti nizko zakasnitev.
- Primerjalni vodič za pretakanje v živo
- Kako napovedati uspeh kodeka
Zdaj, ko poznamo kategorije, poglejmo najučinkovitejši način za doseganje potrebne stopnje nizke zakasnitve.
2/3 Lepo je imeti nizko zakasnitev
Številka 2 kaže, da sta Apple HLS in MPEG-DASH, uporabljena s privzetimi nastavitvami, povzročila približno 30 sekund zakasnitve. Številke so preproste; če uporabljate velikosti deset sekund in želite, da so trije segmenti v predpomnilniku predvajalnika pred začetkom predvajanja, imate trideset sekund. V resnici je Apple pred nekaj leti svoje zahteve iz desetih sekund spremenil v šest sekund, večina proizvajalcev DASH pa uporablja 4-6 sekundne segmente, zato je privzeta številka res bližje 20 sekundam.
Kljub temu številka 3, HLS Tuned in DASH Tuned, kaže zakasnitev približno 6-8 sekund. V bistvu uglaševanje pomeni prehod z 10-sekundnih segmentov na 2-sekundne segmente, ki z enako matematiko zagotavlja 6-8 sekund zakasnitve. Torej, kadar je zakasnitev lepo imeti, lahko drastično zmanjšate zakasnitev brez razvojnega časa ali stroškov ali znatno povečanega tveganja za izvedljivost.
4. Konkurenčna prednost - HTTP tehnologije z nizko zakasnitvijo
Kadar je kot konkurenčna prednost potrebna nizka zakasnitev, samo rezanje velikosti segmentov ne bo uspelo; boste morali uporabiti resnično tehnologijo z nizko zakasnitvijo. Tu sta dva razreda; Tehnologije HTTP, kot sta HLS z nizko zakasnitvijo in CMAF z nizko zakasnitvijo za DASH, in rešitve, ki temeljijo na drugih tehnologijah, kot sta WebSockets in WebRTC.
Za večino proizvajalcev z aplikacijami v tem razredu tehnologije HTTP z nizko zakasnitvijo ponujajo najboljšo kombinacijo cenovne dostopnosti, združljivosti nazaj, prilagodljivosti in nabora funkcij. Torej bom v tem poglavju obravnaval HLS z nizko zakasnitvijo in CMAF z nizko zakasnitvijo za DASH, v naslednjem pa druge tehnologije.
Vsi sistemi z nizko zakasnitvijo, ki temeljijo na HLS / DASH / CMAF, delujejo na enak osnovni način, kot je prikazano na sliki 2. To pomeni, da ne čakajo na kodiranje celotnega segmenta, kar običajno traja od 6 do 10 sekund (vrh slike 2) , kodirnik ustvari veliko krajše koščke, ki se prenesejo na CDN takoj, ko so dokončani (dno slike 2).
Na primer, če bi vaš kodirnik ustvarjal šestsekundne segmente, bi imeli vsaj šest sekund zakasnitve; trojno, če bi moral gledalec pred začetkom predvajanja sprejeti običajne tri segmente. Če je vaš kodirnik potisnil koščke vsakih 200 milisekund in je bil predvajalnik konfiguriran za takojšnje začetek predvajanja, mora biti latenca veliko, veliko manjša. Ena ključnih prednosti te sheme je povratna združljivost; ker se segmenti še vedno ustvarjajo, bi morali igralci, ki niso združljivi s shemo z nizko zakasnitvijo, še vedno imeti možnost predvajati segmente, čeprav z daljšo zakasnitvijo. Ti segmenti so takoj na voljo tudi za predstavitve VOD iz prenosa v živo.
Poleg teh prednosti tehnologije HTTP z nizko zakasnitvijo podpirajo večino funkcij svojih običajnih zakasnitev, vključno s šifriranjem, vstavljanjem oglasov in podnaslavljanjem, kar ni splošno podprto v tehnologijah, ki temeljijo na WebRTC in WebSockets. Verjetno lahko izbrano tehnologijo z nizko zakasnitvijo uveljavite z obstoječo infrastrukturo predvajalnika in dostave, kar zmanjša razvojne in druge tehnološke stroške.
Izbira tehnologije HTTP z nizko zakasnitvijo
Obstajata dva glavna standarda za prilagodljivo pretakanje HTTP, HLS in DASH, ter povezovalni format vsebnika, CMAF. Ko je Apple objavil svojo rešitev HLS z nizko zakasnitvijo, je takoj premaknil več temeljnih prizadevanj in postal izbrana tehnologija za zagotavljanje nizke zakasnitve HLS. Čeprav je specifikacija še vedno razmeroma nova, jo s svojim izdelkom Nimble Streamer že podpirajo ponudniki tehnologije, kot sta Wowza in WMSPanel.
Obstaja standard DVB za DASH z nizko zakasnitvijo, industrijski forum DASH pa je odobril več načinov z nizko zakasnitvijo za DASH, ki jih je treba vključiti v naslednje smernice o interoperabilnosti. V skladu z vsemi temi specifikacijami si razvijalci kodirnikov in predvajalnikov ter omrežja za dostavo vsebin že nekaj let prizadevajo, da bi zagotovili interoperabilnost, tako da bi morale vse aplikacije DASH / CMAF z nizko zakasnitvijo udariti ob tla.
Kot primer sta Harmonic in Akamai skupaj pokazala NMA in IBC 2017 z nizko zakasnitvijo CMAF, pri čemer sta prikazala OTT dostavo v živo z zakasnitvijo manj kot pet sekund. Od takrat je Harmonic v svoje izdelke, ki temeljijo na napravah (Packager XOS in Electra XOS) in rešitve SaaS (VOS Cluster in VOS260), vključil funkcionalnost DASH z nizko zakasnitvijo. Številni drugi ponudniki kodirnikov in predvajalnikov so storili enako.
Ne glede na to, ali se odločite za uporabo HLS z nizko zakasnitvijo ali nizko zakasnitvijo za DASH, ali oboje, bi moral biti prehod z vaše obstoječe arhitekture za dostavo HLS in / ali DASH razmeroma nemoten in poceni.
5. Komunikacije v realnem času
WebRTC je običajno motor integriranega paketa, ki vključuje kodirnik, predvajalnik in dostavno infrastrukturo. Primeri obsežnih rešitev za pretakanje, ki temeljijo na WebRTC, vključujejo Real Time iz Phenixa, Limelight Realtime Streaming in Millicast iz CoSMo Software in Influxis (slika 3). Do tehnologije WebRTC lahko dostopate tudi v orodjih, kot so Wowza Streaming Engine, CoSMO Software in Red 5 Pro Server. Čas zakasnitve za tehnologije v tem razredu je od .5 sekund za 71% tokov (Phenix), manj kot 500 milisekund (Red5 Pro), do manj kot eno sekundo (Limelight). Če potrebujete zakasnitev pod dvema sekundama, morate upoštevati WebRTC.
Če potrebujete komunikacijo v realnem času, boste verjetno morali uporabiti rešitev, ki temelji na WebRTC ali Websockets. WebRTC je bil oblikovan za komunikacijo med brskalniki in ga podpirajo vsi večji namizni brskalniki v sistemih Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 in BlackBerry 10, zato bi moral delovati brez prenosov na kateri koli od teh platform. Kot že ime pove, je WebRTC protokol za dostavo pretočnih predvajanj v živo vsakemu pregledovalniku, bodisi peer-to-peer ali strežniku peer.
WebSockets je protokol v realnem času, ki ustvarja in vzdržuje trajno povezavo med strežnikom in odjemalcem, ki jo lahko katera koli stranka uporablja za prenos podatkov. Ta povezava se lahko uporablja za podporo video dostave in druge komunikacije, zato je priročna, če vaša aplikacija potrebuje interaktivnost. Tako kot izvedbe WebRTC so tudi storitve, ki uporabljajo WebSockets, običajno na voljo kot storitev, ki vključuje predvajalnik in CDN, lahko pa uporabite kateri koli kodirnik, ki lahko prenaša tokove na strežnik prek RTMP ali WebRTC. Primeri vključujejo nanoStream Cloud Nanocosmosa in Streaming Cloud Wowze z ultra nizko zakasnitvijo. Wowza za svojo rešitev trdi, da je njihova zakasnitev manjša od 3 sekunde, Nanocosmos pa približno eno sekundo, od stekla do stekla.
Druge tehnologije z nizko zakasnitvijo
Obstaja četrta kategorija izdelkov, ki se najbolje imenuje "drugo" in uporabljajo različne tehnologije za zagotavljanje nizke zakasnitve. Ta kategorija vključuje THEO Technologies High Efficiency Streaming Protocol (HESP), lastniški protokol za prilagodljivo pretakanje HTTP, ki po navedbah THEO zagotavlja zakasnitev pod 100 milisekund in hkrati zmanjša pasovno širino za približno 10% v primerjavi z drugimi tehnologijami z nizko zakasnitvijo. HESP uporablja standardne kodirnike in CDN-je, vendar zahteva podporo po meri v embalaži in predvajalniku (slika 4). Več o HESP lahko preberete v beli knjigi, ki je na voljo za prenos, tukaj.
Tu je seznam vprašanj, ki jih morate upoštevati pri odločanju, katero tehnologijo z nizko zakasnitvijo boste uporabili in kako to storiti.
Graditi ali kupiti?
Če tehnologijo izvajate sami, pred izbiro tehnologije odgovorite na vsa spodaj navedena vprašanja. Če izbirate ponudnika storitev, jih uporabite za primerjavo različnih ponudnikov storitev.
Ali izbirate standard ali partnerja?
Zgoraj smo opisali različne tehnologije za doseganje nizke zakasnitve, vendar se izvedbe od ponudnika storitev razlikujejo. Torej ne bodo vse izvedbe LL HLS vključevale dostave ABR, vsaj najprej ne. Večina tradicionalnih programov, podobnih oddajanju, se bo verjetno preselila v standarde, ki temeljijo na HTTP, kot so HLS / DASH / CMAF z nizko zakasnitvijo, medtem ko bodo aplikacije, ki zahtevajo izjemno nizko zakasnitev, kot so stave in dražbe, gravitirale k drugim tehnologijam. V obeh primerih je pri izbiri ponudnika storitev pomembneje ugotoviti, ali lahko izpolnijo vaše tehnološke in poslovne cilje, kot katero tehnologijo dejansko izvajajo.
Ali se lahko meri in za katero ceno?
Ena od prednosti tehnologij, ki temeljijo na HTTP, je, da se pri večini CDN-jev merijo po standardnih cenah. V nasprotju s tem pa večina tehnologij, ki temeljijo na WebRTC in WebSocket, zahteva namensko dostavno infrastrukturo, ki jo izvaja ponudnik storitev. Zaradi tega so storitve, ki ne temeljijo na HTTP, dražje kot HLS / DASH / CMAF. Ko primerjate ponudnike storitev, ugotovite stroške juhe in oreščkov dogodka, vključno z vstopom, prekodiranjem, pasovno širino, ustvarjanjem datotek VOD, enkratnimi konfiguracijami ali konfiguracijami na dogodek in podobno.
Vprašanja, povezana z izvajanjem?
Zastavite naslednja vprašanja v zvezi z izvajanjem in uporabo tehnologije.
- Kakšno zakasnitev je mogoče doseči v obsegu, ki ustreza vašemu občinstvu in geografski porazdelitvi?
- Ali obstajajo kakšne omejitve kakovosti - nekatere tehnologije so lahko omejene na določene največje ločljivosti ali profile H.264.
- Ali bodo paketi šli skozi požarni zid? Sistemi, ki temeljijo na HTTP, uporabljajo protokole HTTP, ki so prijazni požarnemu zidu. Drugi uporabljajo UDP, ki morda ne bo samodejno prešel skozi požarne zidove. Če je UDP, ali obstajajo povratni kanali za dostavo blokiranim gledalcem?
- Katere platforme so podprte? Verjetno računalniki in mobilne naprave, kaj pa STB, dongli, naprave OTT in pametni televizorji?
- Ali sistem lahko prilagodi vaše ciljne številke gledalcev? Ali je infrastruktura CDN zasebna in če lahko, jo lahko dostavi vsem ustreznim gledalcem na vseh upoštevnih trgih? Kakšni so predvideni stroški skaliranja?
- Ali lahko uporabljate svoj predvajalnik ali morate predvajalnik sistema? Če ste lastni, kakšne spremembe so potrebne in koliko bodo to stale?
- Kaj je potrebno za mobilno predvajanje? Se bodo tokovi predvajali v brskalniku ali je potrebna aplikacija? Če je potrebna (ali zaželena) aplikacija, ali so na voljo SDK-ji?
- Katere dajalnike lahko sistem uporablja? Večina bi morala uporabiti kateri koli kodirnik, ki lahko podpira povezave RTMP v transkoder v oblaku, vendar preveri, ali so potrebni drugi protokoli.
- Ali je mogoče vsebino ponovno uporabiti za VOD ali bo potrebno ponovno kodiranje? Nič hudega, saj stane videoposnetek približno 20 USD na uro za pretvorbo v razumno lestvico za kodiranje, vendar drago za pogoste oddaje.
- Kakšne so možnosti odpuščanja in kakšni so stroški? Pri kritičnih oddajah boste želeli vedeti, kako podvojiti potek dela kodiranja / oddajanja, če se katera koli sistemska komponenta med dogodkom spusti. Ali je ta presežek podprt in kakšni so stroški?
Katere funkcije so na voljo in v kakšnem obsegu?
Različni ponudniki bodo ponujali široko paleto funkcij, ki lahko vključujejo ali ne:
- ABR pretakanje - koliko tokov in ali obstajajo ustrezne omejitve hitrosti ali ločljivosti?
- Kaj pa funkcije DVR? Ali lahko gledalci predvajanje ustavijo in znova zaženejo, ne da bi pri tem izgubili vsebino.
- Video sinhronizacija - Ali lahko sistem sinhronizira vse gledalce na isto točko v toku? Potoki lahko plujejo po lokacijah in napravah, brez te možnosti pa imajo uporabniki nekaterih povezav prednost pri dražbah ali igrah na srečo.
- Katera zaščita vsebine je na voljo? Če ste proizvajalec vrhunskih vsebin, boste morda potrebovali resnično DRM. Drugi se lahko znajdejo z avtentikacijo ali drugimi podobnimi tehnikami.
- Ali so napisi na voljo? Napisi so zakonsko obvezni za nekatere oddaje, vendar na splošno koristni za vse.
- Kaj pa vstavljanje oglaševanja ali druga shema monetizacije? Ali ponudnik tehnologije / storitve to podpira?
Na splošno velja, da če ste pretočna trgovina, ki želi izpolniti ali premagati čas oddajanja v razponu od 5 do 6 sekund, je verjetno najboljša izbira standardna tehnologija HTTP, saj bo najbližje podpori istega nabora funkcij, ki ste ga trenutno uporabljajo, na primer zaščito vsebine, napise in zaslužek. Če imate aplikacijo, ki zahteva veliko nižjo zakasnitev, boste verjetno potrebovali rešitev, ki temelji na WebRTC ali Websockets, ali lastniško tehnologijo HTTP. V obeh primerih bi vam zgoraj zastavljena vprašanja pomagala prepoznati ponudnika tehnologije in / ali storitve, ki najbolje ustreza vašim potrebam.