Nízká latence je univerzální aspirací v médiích. Když společnost jako Wowza vytvoří perfektní graf, který vysvětlí technologie streamování s nízkou latencí, musíte před nimi sundat klobouk a použít graf s uvedením zdroje a několika drobnými úpravami. Uvedený graf uvádím jako obrázek 1; pojďme diskutovat v pořadí určeném zvýrazněnými čísly, která jsem přidal.
1. Aplikace pro nízkou latenci
PRŮVODCE VÝROBKY
Nejlepší kamery PTZ pro živé vysílání
Abychom se ujistili, že jsme všichni na stejné stránce, latence v kontextu živého vysílání znamená zpoždění mezi skleněnými plochami. První sklenice je kamera na skutečném živém přenosu, druhá je obrazovka, kterou sledujete. Latence je zpoždění mezi okamžikem, kdy se ve fotoaparátu objeví, a okamžikem, kdy se objeví ve vašem telefonu. Přispěním k latenci jsou faktory, jako je čas kódování (na akci), čas přenosu do cloudu, čas překódování v cloudu (pro vytvoření žebříčku kódování), doba dodání a kriticky, kolik sekund váš přehrávač vyrovnává, než začnete hrát.
Horní vrstva zobrazuje typické aplikace a jejich požadavky na latenci. Populární aplikace s nízkou latencí a latencí téměř v reálném čase jsou hazardní a aukční weby.
Než se ponoříte do naší diskuse o technologii, uvědomte si, že čím nižší je latence vašeho živého přenosu, tím méně odolný je tok k přerušení šířky pásma. Například pomocí výchozího nastavení bude stream HLS přehrávat více než 15 sekund přerušené šířky pásma a pokud bude v daném okamžiku obnoven, divák možná nikdy nebude vědět, že došlo k problému. Naproti tomu stream s nízkou latencí přestane hrát téměř okamžitě po přerušení. Takže výhoda doby spuštění s nízkou latencí musí být vždy vyvážena s negativem přerušení přehrávání. Pokud absolutně nepotřebujete nízkou latenci, nemusí být dobré obětovat odolnost, abyste ji získali.
To znamená, že je užitečné rozdělit latenci do tří kategorií následovně.
PRO NEWSLETTERAudio + Video + IT. Naši redaktoři jsou odborníci na integraci audio / video a IT. Získejte denní přehledy, zprávy a profesionální síťové připojení. Přihlaste se k odběru Pro AV ještě dnes.
- Pěkné mít - Rychlejší je vždy lepší, ale pokud živě streamujete schůzi Board of Education nebo fotbalový zápas na střední škole, můžete se rozhodnout, že robustnost streamování je důležitější než nízká latence, zvláště pokud mnoho diváků sleduje připojení s nízkou bitrate.
- Konkurenční výhoda - V některých případech nízká latence poskytuje konkurenční výhodu nebo pomalá latence znamená konkurenční nevýhodu. V tabulce si všimnete, že typická latence pro kabelovou televizi je přibližně pět sekund. Pokud vaše streamovací služba konkuruje kabelu, musíte být v tomto rozsahu a nižší latence poskytuje skromnou konkurenční výhodu.
- Komunikace v reálném čase - Pokud jste hazardní nebo aukční web nebo vaše aplikace jinak vyžaduje komunikaci v reálném čase, musíte absolutně zajistit nízkou latenci.
- Průvodce srovnáním živých přenosů
- Jak předvídat úspěch kodeku
Nyní, když známe kategorie, se podívejme na nejefektivnější způsob, jak zajistit potřebnou úroveň nízké latence.
2/3 Je příjemné mít nízkou latenci
Číslo 2 ukazuje, že Apple HLS a MPEG-DASH nasazené pomocí jejich výchozího nastavení mají za následek latenci asi 30 sekund. Čísla jsou jednoduchá; pokud používáte velikosti desetisekundových segmentů a požadujete, aby byly v segmentu přehrávače před spuštěním přehrávání tři segmenty, jste na třicet sekund. Po pravdě řečeno, Apple před několika lety změnil své požadavky z deseti sekund na šest sekund a většina producentů DASH používá segmenty o délce 4 až 6 sekund, takže výchozí číslo je opravdu blíže 20 sekundám.
Číslo 3, HLS Tuned a DASH Tuned, ukazuje latenci kolem 6-8 sekund. V podstatě ladění znamená změnu z 10sekundových segmentů na 2sekundové segmenty, které při použití stejné matematiky poskytují latenci 6-8 sekund. Když je tedy příjemné mít latenci, můžete dramaticky snížit latenci bez časových a nákladových nákladů na vývoj nebo výrazně zvýšit riziko doručitelnosti.
4. Konkurenční výhoda - technologie HTTP s nízkou latencí
Když je jako konkurenční výhoda nutná nízká latence, pouhé zmenšení velikosti segmentu to neudělá; budete muset implementovat skutečnou technologii s nízkou latencí. Tady jsou dvě třídy; Technologie HTTP jako Low-Latency HLS a Low-Latency CMAF for DASH a řešení založená na jiných technologiích, jako jsou WebSockets a WebRTC.
Pro většinu výrobců s aplikacemi v této třídě nabízejí technologie HTTP s nízkou latencí nejlepší kombinaci cenové dostupnosti, zpětné kompatibility, flexibility a sady funkcí. V této části se tedy budu zabývat Low Latency HLS a Low-Latency CMAF for DASH a dalšími technologiemi v další části.
Všechny systémy s nízkou latencí založené na HLS / DASH / CMAF fungují stejným základním způsobem, jak je znázorněno na obrázku 2. To znamená, spíše než čekat na zakódování celého segmentu, což obvykle trvá mezi 6–10 sekundami (horní část obrázku 2). , kodér vytvoří mnohem kratší bloky, které se přenesou do CDN, jakmile jsou kompletní (spodní část obrázku 2).
Například pokud váš kodér produkuje šestisekundové segmenty, měli byste latenci alespoň šest sekund; ztrojnásobit, pokud divák musel před zahájením přehrávání obdržet normální tři segmenty. Pokud však váš kodér vytlačil bloky každých 200 milisekund a přehrávač byl nakonfigurován tak, aby okamžitě zahájil přehrávání, latence by měla být mnohem, mnohem méně. Jednou z klíčových výhod tohoto schématu je zpětná kompatibilita; protože segmenty se stále vytvářejí, hráči, kteří nejsou kompatibilní se schématem nízké latence, by měli být schopni segmenty přehrát, i když s delší latencí. Tyto segmenty jsou také okamžitě k dispozici pro prezentace VOD z přímého přenosu.
Kromě těchto výhod podporují technologie HTTP s nízkou latencí většinu funkcí jejich běžných sourozenců, včetně šifrování, vkládání reklam a titulků, které v technologiích WebRTC a WebSockets nejsou univerzálně podporovány. Pravděpodobně můžete implementovat vybranou technologii s nízkou latencí pomocí vaší stávající přehrávací a doručovací infrastruktury, čímž se minimalizují náklady na vývoj a další technologie.
Výběr technologie HTTP s nízkou latencí
Existují dva hlavní standardy pro HTTP Adaptive Streaming, HLS a DASH, plus formát sjednocujícího kontejneru, CMAF. Jakmile společnost Apple oznámila své řešení HLS s nízkou latencí, okamžitě přesunula několik snah na místní úrovni a stala se technologií volby pro poskytování nízké latence HLS. Ačkoli je specifikace stále relativně nová, je již podporována poskytovateli technologií jako Wowza a WMSPanel s jejich produktem Nimble Streamer.
Existuje standard DVB pro DASH s nízkou latencí a DASH Industry Forum schválilo několik režimů s nízkou latencí pro DASH, které mají být zahrnuty do jejich dalších pokynů pro interoperabilitu. Na základě všech těchto specifikací vývojáři kodérů a přehrávačů a sítě pro doručování obsahu již několik let pracují na zajištění interoperability, aby se všechny aplikace s nízkou latencí DASH / CMAF dostaly do chodu.
Například Harmonic a Akamai společně předvedli CMAF s nízkou latencí již od NAB a IBC 2017, přičemž zobrazovali živé doručení OTT s latencí pod pět sekund. Od té doby společnost Harmonic integrovala funkce DASH s nízkou latencí do svých produktů založených na zařízeních (Packager XOS a Electra XOS) a řešení SaaS (VOS Cluster a VOS260). Mnoho dalších prodejců kódovacích zařízení a přehrávačů udělalo totéž.
Ať už se rozhodnete implementovat Low Latency HLS nebo Low Latency pro DASH, nebo obojí, přechod z vaší stávající architektury doručování HLS a / nebo DASH by měl být relativně bezproblémový a levný.
5. Komunikace v reálném čase
WebRTC je obvykle motorem pro integrovaný balíček, který zahrnuje infrastrukturu kodéru, přehrávače a doručování. Mezi příklady řešení pro streamování ve velkém měřítku založených na WebRTC patří Real Time od Phenix, Limelight Realtime Streaming a Millicast od CoSMo Software a Influxis (obrázek 3). Můžete také přistupovat k technologii WebRTC v nástrojích, jako je Wowza Streaming Engine, CoSMO Software a Red 5 Pro Server. Časy latence u technologií v této třídě se pohybují od 0,5 s pro 71% streamů (Phenix), pod 500 milisekund (Red5 Pro), až po jednu sekundu (Limelight). Pokud potřebujete latenci za dvě sekundy, je WebRTC volbou, kterou musíte zvážit.
Pokud potřebujete komunikaci v reálném čase, pravděpodobně budete muset implementovat řešení založené na WebRTC nebo Websockets. WebRTC byl vytvořen pro komunikaci mezi prohlížeči a je podporován všemi hlavními desktopovými prohlížeči v systémech Android, iOS, Chrome OS, Firefox OS, Tizen 3.0 a BlackBerry 10, takže by měl běžet bez stahování na jakékoli z těchto platforem. Jak název napovídá, WebRTC je protokol pro doručování živých přenosů každému divákovi, a to buď peer-to-peer, nebo server peer.
WebSockets je protokol v reálném čase, který vytváří a udržuje trvalé spojení mezi serverem a klientem, které může kterákoli strana použít k přenosu dat. Toto připojení lze použít k podpoře doručování videa a další komunikace, takže je vhodné, pokud vaše aplikace vyžaduje interaktivitu. Stejně jako implementace WebRTC jsou služby, které používají WebSockets, obvykle nabízeny jako služba, která zahrnuje přehrávač a CDN, a můžete použít jakýkoli kodér, který může přenášet proudy na server prostřednictvím RTMP nebo WebRTC. Mezi příklady patří cloud Nanocosmos NanoStream a streamovací cloud Wowza s extrémně nízkou latencí. Wowza tvrdí, že jejich řešení má latenci pod 3 sekundy, zatímco Nanocosmos tvrdí přibližně jednu sekundu, sklo na sklo.
Další technologie s nízkou latencí
Existuje čtvrtá kategorie produktů, která se nejlépe nazývá „jiné“ a které používají různé technologie k zajištění nízké latence. Tato kategorie zahrnuje THEO Technologies High Efficiency Streaming Protocol (HESP), proprietární HTTP adaptivní streamovací protokol, který podle THEO poskytuje latenci pod 100 milisekund a současně snižuje šířku pásma přibližně o 10% ve srovnání s jinými technologiemi s nízkou latencí. HESP používá standardní kodéry a CDN, ale vyžaduje vlastní podporu v balírně a přehrávači (obrázek 4). Více o HESP si můžete přečíst v dokumentu white paper ke stažení zde.
Tady je seznam otázek, které byste měli zvážit při rozhodování, kterou technologii s nízkou latencí implementovat a jak to udělat.
Postavit nebo koupit?
Pokud implementujete technologii sami, nezapomeňte před výběrem technologie odpovědět na všechny níže uvedené otázky. Pokud si vyberete poskytovatele služeb, použijte jej k porovnání různých poskytovatelů služeb.
Vybíráte si standard nebo partnera?
Výše jsme načrtli různé technologie pro dosažení nízké latence, ale implementace se u jednotlivých poskytovatelů služeb liší. Takže ne všechny implementace LL HLS budou zahrnovat dodávku ABR, alespoň ne zpočátku. Většina tradičních aplikací podobných vysílání bude pravděpodobně migrovat na standardy založené na protokolu HTTP, jako je HLS / DASH / CMAF s nízkou latencí, zatímco aplikace vyžadující extrémně nízkou latenci, jako jsou sázení a aukce, budou gravitovat k dalším technologiím. V obou případech je při výběru poskytovatele služeb důležitější určit, zda může splnit vaše technologické a obchodní cíle, než jakou technologii skutečně implementuje.
Může se škálovat a za jakou cenu?
Jednou z výhod technologií založených na protokolu HTTP je, že se škálovávají za standardní ceny pomocí většiny CDN. Naproti tomu většina technologií založených na WebRTC a WebSocket vyžaduje vyhrazenou doručovací infrastrukturu implementovanou poskytovatelem služeb. Z tohoto důvodu mohou být služby, které nejsou založeny na HTTP, nákladnější než HLS / DASH / CMAF. Při porovnávání poskytovatelů služeb zjistěte, jaké jsou náklady na událost, včetně příchodu, překódování, šířky pásma, vytvoření souboru VOD, jednorázových konfigurací nebo konfigurací pro jednotlivé události a podobně.
Problémy související s implementací?
Zeptejte se na následující otázky týkající se implementace a používání technologie.
- Jakou latenci lze dosáhnout v rozsahu relevantním pro velikost publika a geografické rozdělení?
- Existují nějaká omezení kvality - některé technologie mohou být omezeny na určitá maximální rozlišení nebo profily H.264.
- Projdou pakety firewallem? Systémy založené na protokolu HTTP používají protokoly HTTP, které jsou vhodné pro bránu firewall. Jiní používají UDP, které nemusí procházet branami firewall automaticky. Pokud UDP, existují nějaké zpětné kanály, které se dají doručit blokovaným divákům?
- Jaké platformy jsou podporovány? Pravděpodobně počítače a mobilní zařízení, ale co STB, hardwarové klíče, OTT zařízení a chytré televize?
- Může se systém přizpůsobit vašim cílovým číslům diváků? Je infrastruktura CDN soukromá, a pokud ano, může poskytovat všem relevantním divákům na všech příslušných trzích? Jaké jsou očekávané náklady na škálování?
- Můžete použít vlastní přehrávač nebo musíte použít přehrávač systému? Pokud jsou vaše, jaké změny jsou nutné a kolik to bude stát?
- Co je potřeba pro mobilní přehrávání? Budou se streamy přehrávat v prohlížeči nebo je vyžadována aplikace? Pokud existuje požadovaná (nebo žádoucí) aplikace, jsou k dispozici sady SDK?
- Jaké kodéry může systém používat? Většina by měla používat jakýkoli kodér, který podporuje připojení RTMP do cloudového transkodéru, ale zkontrolujte, zda nejsou potřeba další protokoly.
- Lze obsah znovu použít pro VOD nebo bude nutné nové kódování? Není to velký problém, protože překódování na rozumný kódovací žebřík stojí přibližně 20 $ / hodinu videa, ale drahé pro časté vysílání.
- Jaké jsou možnosti nadbytečnosti a jaké jsou náklady? U vysílání důležitých pro misi budete chtít vědět, jak duplikovat pracovní postup kódování / vysílání, pokud by během události došlo k výpadku jakékoli součásti systému. Je tato redundance podporována a jaké jsou náklady?
Jaké funkce jsou k dispozici a v jakém měřítku?
K dispozici bude široká škála nabídek funkcí od různých dodavatelů, které mohou nebo nemusí zahrnovat:
- Streamování ABR - kolik streamů a existují nějaká relevantní omezení bitrate nebo rozlišení?
- A co funkce DVR? Mohou diváci zastavit a znovu spustit přehrávání bez ztráty obsahu.
- Synchronizace videa - Může systém synchronizovat všechny diváky do stejného bodu ve streamu? Proudy se mohou přesouvat přes místa a zařízení a bez této funkce mohou mít uživatelé některých připojení výhodu pro aukce nebo hazardní hry.
- Jaká ochrana obsahu je k dispozici? Pokud jste producentem prémiového obsahu, možná budete potřebovat skutečné DRM. Ostatní si vystačí s autentizací nebo jinými podobnými technikami.
- Jsou k dispozici titulky? U některých vysílání jsou titulky legálně vyžadovány, ale obecně jsou prospěšné pro všechny.
- A co vložení reklamy nebo jiné schéma zpeněžení? Podporuje to poskytovatel technologie / služby?
Obecně platí, že pokud jste streamovacím obchodem, který se snaží splnit nebo překonat vysílací časy v rozmezí 5 až 6 sekund, je pravděpodobně vaše nejlepší sázková technologie založená na standardech HTTP, protože bude nejblíže podpořit stejnou sadu funkcí, která vás nastavuje. ' aktuálně používáte, jako je ochrana obsahu, titulky a zpeněžení. Pokud máte aplikaci, která vyžaduje mnohem nižší latenci, budete pravděpodobně potřebovat řešení založené na WebRTC nebo Websockets nebo proprietární technologii HTTP. V obou případech by vám položení výše uvedených otázek mělo pomoci určit poskytovatele technologie a / nebo služeb, který nejlépe vyhovuje vašim potřebám.
