Nízka latencia je univerzálnou ašpiráciou v médiách. Keď spoločnosť ako Wowza vytvorí dokonalý graf na vysvetlenie technológií streamovania s nízkou latenciou, musíte pred nimi zložiť klobúk a tento graf používať s uvedením zdroja a niekoľkými drobnými úpravami. Uvedený graf uvádzam ako obrázok 1; poďme diskutovať v poradí určenom zvýraznenými číslami, ktoré som pridal.
1. Žiadosti o nízku latenciu
PRÍRUČKA VÝROBKU
Najlepšie kamery PTZ na živé vysielanie
Len aby sme sa ubezpečili, že sme všetci na jednej stránke, latencia v kontexte živého vysielania znamená oneskorenie typu „medzi jednotlivými sklami“. Prvé sklo je kamera na skutočnom živom vysielaní, druhé je obrazovka, ktorú sledujete. Latencia je oneskorenie medzi zobrazením vo fotoaparáte a časom, keď sa objaví na telefóne. K latencii prispievajú faktory, ako je čas kódovania (v prípade udalosti), čas prenosu do cloudu, čas transkódovania v cloude (na vytvorenie rebríčka kódovania), čas dodania a kriticky počet sekúnd, ktoré váš prehrávač vyrovná, než začne hrať.
Horná vrstva zobrazuje typické aplikácie a požiadavky na ich latenciu. Populárnymi aplikáciami, ktoré chýbajú s nízkou latenciou a takmer v reálnom čase, sú hazardné a aukčné stránky.
Predtým, ako sa ponoríte do diskusie o našej technológii, pochopte, že čím je latencia vášho priameho prenosu nižšia, tým menej odolný je prúd voči prerušeniam šírky pásma. Napríklad pri použití predvolených nastavení bude stream HLS prehrávať viac ako 15 sekúnd prerušenej šírky pásma a ak sa v danom okamihu obnoví, divák nemusí nikdy vedieť, že nastal problém. Naopak prúd s nízkou latenciou sa prestane hrať takmer okamžite po prerušení. Výhoda doby spustenia s nízkou latenciou musí byť vždy vyvážená s negatívom zastavenia pri prehrávaní. Ak absolútne nepotrebujete nízku latenciu, nemusí byť užitočné obetovať odolnosť, aby ste ju dosiahli.
To znamená, že je užitočné rozdeliť latenciu do troch kategórií nasledovne.
PRO NEWSLETTERAudio + Video + IT. Naši redaktori sú odborníkmi na integráciu audio / video a IT. Získajte denné prehľady, správy a profesionálne siete. Prihláste sa na odber programu Pro AV ešte dnes.
- Pekné mať - Rýchlejšie je vždy lepšie, ale ak práve streamujete stretnutie rady pre vzdelávanie alebo futbalový zápas na strednej škole, môžete sa rozhodnúť, že robustnosť streamu je dôležitejšia ako nízka latencia, najmä ak veľa divákov sleduje pripojenie s nízkou bitovou rýchlosťou.
- Konkurenčná výhoda - V niektorých prípadoch nízka latencia poskytuje konkurenčnú výhodu alebo pomalá latencia znamená konkurenčnú nevýhodu. V grafe si všimnete, že typická latencia pre káblovú televíziu je okolo päť sekúnd. Ak vaša streamovacia služba konkuruje káblovým sieťam, musíte sa nachádzať v tomto rozmedzí a nižšia latencia poskytuje skromnú konkurenčnú výhodu.
- Komunikácia v reálnom čase - Ak ste hazardné hry alebo aukčné stránky alebo ak vaša aplikácia inak vyžaduje komunikáciu v reálnom čase, musíte bezpodmienečne poskytnúť nízku latenciu.
- Sprievodca porovnaním priamych prenosov
- Ako predpovedať úspešnosť kodeku
Teraz, keď poznáme kategórie, sa pozrime na najefektívnejší spôsob, ako dosiahnuť potrebnú úroveň nízkej latencie.
2/3 Je príjemné mať nízku latenciu
Číslo 2 ukazuje, že Apple HLS a MPEG-DASH nasadené pomocou svojich predvolených nastavení majú za následok latenciu asi 30 sekúnd. Čísla sú jednoduché; ak používate desaťsekundové veľkosti segmentov a požadujete, aby boli tri segmenty v medzipamäti prehrávača pred začiatkom prehrávania, ste na tridsať sekundách. Po pravde povedané, Apple zmenil pred niekoľkými rokmi svoje požiadavky z desiatich sekúnd na šesť sekúnd a väčšina producentov DASH používa segmenty 4 až 6 sekúnd, takže predvolené číslo sa skutočne blíži k 20 sekundám.
Číslo 3, vyladené HLS a DASH, stále ukazuje latenciu okolo 6 - 8 sekúnd. Ladenie v podstate znamená zmenu z 10-sekundových segmentov na 2-sekundové segmenty, ktoré pri použití rovnakej matematiky poskytujú latenciu 6-8 sekúnd. Takže keď je latencia príjemná, môžete latenciu dramaticky znížiť bez potreby času a nákladov na vývoj alebo výrazne zvýšeného rizika doručiteľnosti.
4. Konkurenčná výhoda - technológie HTTP s nízkou latenciou
Ak je ako konkurenčná výhoda potrebná nízka latencia, samotné rezanie veľkostí segmentov to neurobí; budete musieť implementovať skutočnú technológiu s nízkou latenciou. Tu existujú dve triedy; Technológie HTTP ako Low-Latency HLS a Low-Latency CMAF for DASH a riešenia založené na iných technológiách, ako sú WebSockets a WebRTC.
Pre väčšinu výrobcov s aplikáciami v tejto triede ponúkajú technológie HTTP s nízkou latenciou najlepšiu kombináciu cenovej dostupnosti, spätnej kompatibility, flexibility a súboru funkcií. V tejto časti sa teda budem venovať HLS s nízkou latenciou a CMAF s nízkou latenciou pre DASH a v nasledujúcej časti ďalším technológiám.
Všetky systémy s nízkou latenciou založené na HLS / DASH / CMAF fungujú rovnakým základným spôsobom, ako je to znázornené na obrázku 2. To znamená, že namiesto čakania na zakódovanie celého segmentu to zvyčajne trvá 6 - 10 sekúnd (horná časť obrázku 2) , kódovač vytvorí oveľa kratšie bloky, ktoré sa prenesú do CDN, akonáhle sú dokončené (dolná časť obrázku 2).
Napríklad, ak váš kódovač produkoval šesťsekundové segmenty, mali by ste latenciu minimálne šesť sekúnd; trojnásobok, ak divák pred začiatkom prehrávania vyžadoval prijatie troch normálnych segmentov. Ak však váš kódovač vytlačil bloky každých 200 milisekúnd a prehrávač bol nakonfigurovaný na okamžité spustenie prehrávania, latencia by mala byť oveľa, oveľa menšia. Jednou z kľúčových výhod tejto schémy je spätná kompatibilita; keďže sa segmenty stále vytvárajú, hráči nekompatibilní so schémou nízkej latencie by mali byť schopní hrať segmenty, aj keď s dlhšou latenciou. Tieto segmenty sú tiež okamžite k dispozícii pre prezentácie VOD z priameho prenosu.
Okrem týchto výhod podporujú technológie HTTP s nízkou latenciou väčšinu funkcií ich súrodencov s normálnou latenciou, vrátane šifrovania, vkladania reklám a titulkov, ktoré nie sú univerzálne podporované v technológiách WebRTC a WebSockets. Vybranú technológiu s nízkou latenciou môžete pravdepodobne implementovať pomocou svojej existujúcej prehrávacej a doručovacej infraštruktúry, čím sa minimalizujú náklady na vývoj a ďalšie technológie.
Výber technológie HTTP s nízkou latenciou
Existujú dva hlavné štandardy pre HTTP Adaptive Streaming, HLS a DASH, plus formát zjednocujúceho kontajnera, CMAF. Hneď ako spoločnosť Apple oznámila svoje riešenie HLS s nízkou latenciou, okamžite presunula úsilie miestnych obyvateľov a stala sa technológiou voľby poskytovania nízkej latencie HLS. Aj keď je špecifikácia stále relatívne nová, je už podporovaná poskytovateľmi technológií ako Wowza a WMSPanel s ich produktom Nimble Streamer.
Existuje štandard DVB pre DASH s nízkou latenciou a DASH Industry Forum schválilo niekoľko režimov s nízkou latenciou pre DASH, ktoré sa majú zahrnúť do ich ďalších usmernení o interoperabilite. Podľa všetkých týchto špecifikácií vývojári kódovacích a prehrávacích zariadení a siete na doručovanie obsahu pracujú už niekoľko rokov na zaistení interoperability, aby sa všetky aplikácie s nízkou latenciou DASH / CMAF dostali do behu.
Napríklad Harmonic a Akamai spoločne predviedli CMAF s nízkou latenciou už v období NAB a IBC 2017, pričom ukazovali živé dodanie OTT s latenciou pod päť sekúnd. Odvtedy spoločnosť Harmonic integrovala funkčnosť DASH s nízkou latenciou do svojich produktov založených na zariadeniach (Packager XOS a Electra XOS) a riešení SaaS (VOS Cluster a VOS260). To isté urobilo mnoho ďalších predajcov kódovacích zariadení a prehrávačov.
Či už sa rozhodnete pre DASH implementovať Low Latency HLS alebo Low Latency, alebo oboje, prechod z vašej existujúcej architektúry doručovania HLS a / alebo DASH by mal byť relatívne plynulý a lacný.
5. Komunikácia v reálnom čase
WebRTC je zvyčajne motorom pre integrovaný balík, ktorý obsahuje infraštruktúru kódovacieho zariadenia, prehrávača a doručovania. Medzi príklady riešení pre rozsiahle streamovanie založené na WebRTC patria Real Time od spoločnosti Phenix, Limelight Realtime Streaming a Millicast od CoSMo Software and Influxis (obrázok 3). Môžete tiež získať prístup k technológii WebRTC v nástrojoch, ako je Wowza Streaming Engine, softvér CoSMO a server Red 5 Pro. Časy latencie pre technológie v tejto triede sa pohybujú od 0,5 sekundy pre 71% streamov (Phenix), do 500 milisekúnd (Red5 Pro) až do jednej sekundy (Limelight). Ak potrebujete latenciu do dvoch sekúnd, je potrebné zvážiť WebRTC.
Ak potrebujete komunikáciu v reálnom čase, pravdepodobne budete musieť implementovať riešenie založené na WebRTC alebo Websockets. WebRTC bol vyvinutý pre komunikáciu medzi prehliadačmi a je podporovaný všetkými hlavnými desktopovými prehliadačmi v systémoch Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 a BlackBerry 10, takže by mal bežať bez sťahovania na ktorejkoľvek z týchto platforiem. Ako naznačuje názov, WebRTC je protokol na doručovanie živých prenosov každému divákovi, a to buď peer-to-peer, alebo server to peer.
WebSockets je protokol v reálnom čase, ktorý vytvára a udržiava trvalé spojenie medzi serverom a klientom, ktoré môže ktorákoľvek zo strán použiť na prenos údajov. Toto pripojenie je možné použiť na podporu doručovania videa a ostatnej komunikácie, takže je vhodné, ak vaša aplikácia vyžaduje interaktivitu. Rovnako ako implementácie WebRTC, aj služby využívajúce WebSockets sa zvyčajne ponúkajú ako služba zahŕňajúca prehrávač a CDN. Môžete použiť akýkoľvek kódovač, ktorý dokáže prenášať prúdy na server prostredníctvom RTMP alebo WebRTC. Príklady zahŕňajú cloud nanoStream Nanocosmos a Streaming Cloud Wowza s ultra nízkou latenciou. Wowza tvrdí, že ich riešenie má latenciu nižšiu ako 3 sekundy, zatiaľ čo Nanocosmos tvrdí asi jednu sekundu zo skla na sklo.
Ostatné technológie s nízkou latenciou
Existuje štvrtá kategória výrobkov, ktorá sa najlepšie nazýva „iné“ a ktoré na zaistenie nízkej latencie používajú rôzne technológie. Táto kategória zahŕňa THEO Technologies High Efficiency Streaming Protocol (HESP), patentovaný adaptívny streamovací protokol HTTP, ktorý podľa THEO poskytuje latenciu kratšiu ako 100 milisekúnd a súčasne znižuje šírku pásma o približne 10% v porovnaní s inými technológiami s nízkou latenciou. HESP používa štandardné kódovacie zariadenia a CDN, ale vyžaduje vlastnú podporu v baliacom stroji a prehrávači (obrázok 4). Viac informácií o HESP si môžete prečítať v bielej knihe dostupnej na stiahnutie tu.
Tu je zoznam otázok, ktoré by ste mali vziať do úvahy pri rozhodovaní, ktorú technológiu s nízkou latenciou implementovať a ako to urobiť.
Postaviť alebo kúpiť?
Ak si technológiu implementujete sami, nezabudnite si pred výberom technológie odpovedať na všetky otázky uvedené nižšie. Ak si vyberáte poskytovateľa služieb, použite ho na porovnanie rôznych poskytovateľov služieb.
Vyberáte si štandard alebo partnera?
Vyššie sme načrtli rôzne technológie na dosiahnutie nízkej latencie, implementácie sa však u jednotlivých poskytovateľov služieb líšia. Takže nie každá implementácia LL HLS bude obsahovať doručenie ABR, prinajmenšom najskôr nie. Väčšina tradičných aplikácií podobných vysielaniu bude pravdepodobne migrovať na štandardy založené na protokole HTTP, ako sú HLS / DASH / CMAF s nízkou latenciou, zatiaľ čo aplikácie vyžadujúce ultra nízku latenciu, ako sú stávky a aukcie, budú gravitovať k iným technológiám. V obidvoch prípadoch je pri výbere poskytovateľa služieb dôležitejšie určiť, či dokáže splniť vaše technologické a obchodné ciele, než ktorú technológiu skutočne implementuje.
Môže sa to škálovať a za akú cenu?
Jednou z výhod technológií založených na protokole HTTP je, že ich škálovanie je za štandardné ceny pomocou väčšiny sietí CDN. Naproti tomu väčšina technológií založených na WebRTC a WebSocket vyžaduje vyhradenú infraštruktúru dodávok implementovanú poskytovateľom služieb. Z tohto dôvodu môže byť poskytovanie služieb, ktoré nie sú založené na HTTP, nákladnejšie ako HLS / DASH / CMAF. Pri porovnávaní poskytovateľov služieb zistite, aké sú náklady na udalosť, vrátane vstupu, transkódovania, šírky pásma, vytvárania súborov VOD, jednorazových konfigurácií alebo konfigurácií podľa jednotlivých udalostí, a podobne.
Problémy súvisiace s implementáciou?
Položte nasledujúce otázky týkajúce sa implementácie a používania technológie.
- Akú latenciu je možné dosiahnuť v rozsahu relevantnom pre veľkosť publika a geografické rozdelenie?
- Existujú nejaké obmedzenia kvality - niektoré technológie môžu byť obmedzené na určité maximálne rozlíšenie alebo profily H.264.
- Budú pakety prechádzať cez bránu firewall? Systémy založené na protokole HTTP používajú protokoly HTTP, ktoré sú priateľské k bráne firewall. Iné používajú protokol UDP, ktorý nemusí automaticky prechádzať bránami firewall. Ak je UDP, existujú nejaké spätné kanály, ktoré sa dajú doručiť blokovaným divákom?
- Aké platformy sú podporované? Pravdepodobne počítače a mobilné zariadenia, ale čo STB, hardvérové kľúče, zariadenia OTT a inteligentné televízory?
- Môže sa systém prispôsobiť tak, aby zodpovedal vašim cieľovým počtom divákov? Je infraštruktúra CDN súkromná, a ak áno, môže sa poskytovať všetkým relevantným divákom na všetkých relevantných trhoch? Aké sú predpokladané náklady na škálovanie?
- Môžete použiť svoj vlastný prehrávač alebo musíte použiť prehrávač systému? Ak sú vaše zmeny, aké zmeny sú potrebné a koľko to bude stáť?
- Čo je potrebné na prehrávanie v mobile? Budú sa streamy hrať v prehliadači alebo je vyžadovaná aplikácia? Ak existuje požadovaná (alebo žiaduca) aplikácia, sú k dispozícii súpravy SDK?
- Ktoré kódovacie zariadenia môže systém používať? Väčšina by mala používať akýkoľvek kódovač, ktorý podporuje pripojenie RTMP do cloudového transkodéra, ale skontrolujte, či nie sú potrebné ďalšie protokoly.
- Je možné obsah znova použiť na VOD alebo bude potrebné opätovné kódovanie? Nie je to nič veľké, pretože transkódovanie na rozumný kódovací rebrík stojí približne 20 dolárov za hodinu videa, ale pri častom vysielaní drahé.
- Aké sú možnosti prepúšťania a aké sú náklady? V prípade kriticky dôležitých vysielaní budete potrebovať vedieť, ako duplikovať pracovný postup kódovania / vysielania, ak by počas udalosti došlo k výpadku niektorého komponentu systému. Je táto nadbytočnosť podporovaná a aké sú náklady?
Aké funkcie sú k dispozícii a v akom rozsahu?
Od rôznych dodávateľov bude k dispozícii široká škála ponúk funkcií, ktoré môžu alebo nemusia obsahovať:
- Streamovanie ABR - koľko prúdov a existujú nejaké príslušné obmedzenia prenosovej rýchlosti alebo rozlíšenia?
- A čo funkcie DVR? Môžu diváci zastaviť a reštartovať prehrávanie bez straty obsahu?
- Synchronizácia videa - Môže systém synchronizovať všetkých divákov do rovnakého bodu v streame? Prúdy sa môžu presúvať cez miesta a zariadenia a bez tejto možnosti môžu mať používatelia niektorých pripojení výhodu pre aukcie alebo hazardné hry.
- Aká ochrana obsahu je k dispozícii? Ak ste producentom prémiového obsahu, možno budete potrebovať skutočné DRM. Ostatní si vystačia s autentifikáciou alebo inými podobnými technikami.
- Sú dostupné titulky? Pre niektoré vysielania sú zákonne požadované titulky, ale všeobecne výhodné pre všetkých.
- A čo vloženie reklamy alebo iná schéma speňaženia? Podporuje to poskytovateľ technológie / služby?
Všeobecne platí, že ak ste streamovacím obchodom, ktorý sa snaží uspokojiť alebo prekonať vysielacie časy v rozmedzí od 5 do 6 sekúnd, je pravdepodobne najlepšou technológiou založenou na štandardoch HTTP, pretože bude najbližšie k podpore rovnakej sady funkcií, ako ste vy. “ momentálne používa, ako napríklad ochrana obsahu, titulky a speňaženie. Ak máte aplikáciu, ktorá vyžaduje oveľa nižšiu latenciu, pravdepodobne budete potrebovať riešenie založené na WebRTC alebo Websockets alebo proprietárnu technológiu HTTP. V obidvoch prípadoch by vám položenie otázok uvedených vyššie malo pomôcť určiť technológiu a / alebo poskytovateľa služieb, ktoré najlepšie vyhovujú vašim potrebám.