Niskie opóźnienie to uniwersalna aspiracja w mediach. Kiedy firma taka jak Wowza tworzy idealny wykres, aby wyjaśnić technologie przesyłania strumieniowego o niskich opóźnieniach, musisz zdjąć z nich kapelusz i użyć wykresu z atrybucją i kilkoma drobnymi modyfikacjami. Przedstawiam ten wykres jako rysunek 1; omówmy w kolejności wyznaczonej przez podświetlone liczby, które dodałem.
1. Aplikacje o małym opóźnieniu
PRZEWODNIK PO PRODUKCIE
Najlepsze kamery PTZ do transmisji na żywo
Aby upewnić się, że wszyscy jesteśmy na tej samej stronie, opóźnienie w kontekście transmisji na żywo oznacza opóźnienie szkło-szkło. Pierwsza szyba to kamera podczas rzeczywistego wydarzenia na żywo, druga to ekran, który oglądasz. Opóźnienie to opóźnienie między pojawieniem się ikony w aparacie a wyświetleniem jej w telefonie. Na opóźnienie wpływają takie czynniki, jak czas kodowania (podczas wydarzenia), czas transportu do chmury, czas transkodowania w chmurze (w celu utworzenia drabiny kodowania), czas dostawy i, co najważniejsze, ile sekund gracz buforuje przed rozpoczęciem gry.
Górna warstwa przedstawia typowe aplikacje i ich wymagania dotyczące opóźnień. Popularne aplikacje, których brakuje z powodu małych opóźnień i opóźnień w czasie zbliżonym do rzeczywistego, to witryny hazardowe i aukcyjne.
Zanim zagłębimy się w naszą dyskusję na temat technologii, zrozum, że im mniejsze opóźnienie transmisji na żywo, tym mniej odporny na przerwy w przepustowości. Na przykład przy ustawieniach domyślnych strumień HLS będzie odtwarzany przez ponad 15 sekund z przerwaną przepustowością, a jeśli w tym momencie zostanie przywrócony, widz może nigdy nie wiedzieć, że wystąpił problem. W przeciwieństwie do tego strumień o niskim opóźnieniu przestaje być odtwarzany prawie natychmiast po przerwie. Dlatego korzyści wynikające z krótkiego czasu uruchamiania muszą być zawsze równoważone z negatywnymi skutkami przerw w odtwarzaniu. Jeśli absolutnie nie potrzebujesz niskich opóźnień, może nie warto poświęcać odporności, aby to osiągnąć.
To powiedziawszy, warto podzielić opóźnienie na trzy kategorie w następujący sposób.
NEWSLETTER PROAudio + wideo + IT. Nasi redaktorzy są ekspertami w integracji audio / wideo i IT. Otrzymuj codzienne spostrzeżenia, wiadomości i profesjonalne kontakty. Zasubskrybuj Pro AV już dziś.
- Miło jest mieć - Szybsze jest zawsze lepsze, ale jeśli transmitujesz na żywo spotkanie Rady ds. Edukacji lub mecz piłki nożnej w liceum, możesz zdecydować, że niezawodność transmisji jest ważniejsza niż małe opóźnienie, zwłaszcza jeśli wielu widzów ogląda na połączeniach o niskiej przepływności.
- Przewaga konkurencyjna - W niektórych przypadkach małe opóźnienie zapewnia przewagę nad konkurencją, a wolne opóźnienie oznacza niekorzystną sytuację konkurencyjną. Na wykresie zauważysz, że typowe opóźnienie w telewizji kablowej wynosi około pięciu sekund. Jeśli Twoja usługa przesyłania strumieniowego konkuruje z kablami, musisz znajdować się w tym zakresie, a mniejsze opóźnienia zapewniają niewielką przewagę nad konkurencją.
- Komunikacja w czasie rzeczywistym - Jeśli prowadzisz witrynę hazardową lub aukcyjną lub Twoja aplikacja w inny sposób wymaga komunikacji w czasie rzeczywistym, absolutnie musisz zapewnić niskie opóźnienia.
- Poradnik porównawczy transmisji na żywo
- Jak przewidzieć sukces kodeka
Teraz, gdy znamy kategorie, przyjrzyjmy się najbardziej efektywnemu sposobowi zapewnienia wymaganego poziomu niskich opóźnień.
2/3 Miło mieć małe opóźnienie
Numer 2 pokazuje, że Apple HLS i MPEG-DASH wdrożone przy użyciu ich domyślnych ustawień skutkuje około 30-sekundowym opóźnieniem. Liczby są proste; jeśli używasz dziesięciosekundowych rozmiarów segmentów i chcesz, aby trzy segmenty znajdowały się w buforze odtwarzacza przed rozpoczęciem odtwarzania, masz trzydzieści sekund. Tak naprawdę Apple zmieniło swoje wymagania z dziesięciu do sześciu sekund kilka lat temu, a większość producentów DASH używa 4-6 sekundowych segmentów, więc domyślna liczba jest naprawdę bliższa 20 sekund.
Mimo to numer 3, HLS Tuned i DASH Tuned, pokazuje opóźnienie około 6-8 sekund. Zasadniczo strojenie oznacza zmianę z 10-sekundowych segmentów na 2-sekundowe segmenty, które przy zastosowaniu tej samej matematyki zapewniają 6-8 sekund opóźnienia. Tak więc, gdy przyjemnie jest mieć opóźnienie, można radykalnie zmniejszyć opóźnienie bez czasu i kosztów rozwoju lub znacznie zwiększonego ryzyka dostarczalności.
4. Przewaga konkurencyjna - Technologie HTTP o niskim opóźnieniu
Gdy małe opóźnienia są potrzebne jako przewaga konkurencyjna, samo zmniejszenie rozmiarów segmentów nie wystarczy; Będziesz musiał wdrożyć prawdziwą technologię o niskim opóźnieniu. Tutaj są dwie klasy; Technologie HTTP, takie jak Low-Latency HLS i Low-Latency CMAF dla DASH, oraz rozwiązania oparte na innych technologiach, takich jak WebSockets i WebRTC.
W przypadku większości producentów z aplikacjami tej klasy technologie HTTP o małych opóźnieniach oferują najlepsze połączenie przystępnej ceny, kompatybilności wstecznej, elastyczności i zestawu funkcji. Dlatego w tej sekcji omówię HLS o niskim opóźnieniu i CMAF o niskim opóźnieniu dla DASH, a inne technologie w następnej.
Wszystkie systemy o niskim opóźnieniu oparte na HLS / DASH / CMAF działają w ten sam podstawowy sposób, jak pokazano na rysunku 2. Oznacza to, że zamiast czekać na zakodowanie całego segmentu, co zwykle zajmuje od 6 do 10 sekund (góra rysunku 2) koder tworzy znacznie krótsze fragmenty, które są przesyłane do CDN, gdy tylko zostaną ukończone (dół rysunku 2).
Na przykład, jeśli koder tworzy sześciosekundowe segmenty, masz co najmniej sześć sekund opóźnienia; potrójnie, jeśli zwykłe trzy segmenty miały być odebrane przez widza przed rozpoczęciem odtwarzania. Jeśli jednak Twój koder wypuszczał fragmenty co 200 milisekund, a odtwarzacz został skonfigurowany do natychmiastowego rozpoczęcia odtwarzania, opóźnienie powinno być znacznie mniejsze. Jedną z kluczowych zalet tego schematu jest kompatybilność wsteczna; Ponieważ segmenty są nadal tworzone, odtwarzacze niezgodne ze schematem o niskim opóźnieniu powinny nadal mieć możliwość odtwarzania segmentów, aczkolwiek z dłuższym opóźnieniem. Te segmenty są również natychmiast dostępne dla prezentacji VOD z transmisji na żywo.
Poza tymi zaletami technologie HTTP o małych opóźnieniach obsługują większość funkcji ich rodzeństwa o normalnym opóźnieniu, w tym szyfrowanie, wstawianie reklam i napisy, które nie są powszechnie obsługiwane w technologiach opartych na WebRTC i WebSockets. Prawdopodobnie możesz wdrożyć wybraną technologię o niskim opóźnieniu przy użyciu istniejącego odtwarzacza i infrastruktury dostarczania, minimalizując koszty rozwoju i innych technologii.
Wybór technologii HTTP Low Latency
Istnieją dwa główne standardy HTTP Adaptive Streaming, HLS i DASH, a także ujednolicający format kontenera CMAF. Gdy Apple ogłosił swoje rozwiązanie Low Latency HLS, natychmiast zastąpiło kilka wysiłków oddolnych i stało się technologią z wyboru do dostarczania niskich opóźnień do HLS. Chociaż specyfikacja jest wciąż stosunkowo nowa, jest już obsługiwana przez dostawców technologii, takich jak Wowza i WMSPanel, w ich produkcie Nimble Streamer.
Istnieje standard DVB dla DASH o małych opóźnieniach, a DASH Industry Forum zatwierdziło kilka trybów Low-Latency dla DASH, które zostaną uwzględnione w kolejnych wytycznych dotyczących interoperacyjności. Zgodnie ze wszystkimi tymi specyfikacjami, twórcy koderów i odtwarzaczy oraz sieci dostarczania treści od kilku lat pracują nad zapewnieniem interoperacyjności, tak aby wszystkie aplikacje DASH / CMAF o niskich opóźnieniach mogły zacząć działać.
Na przykład Harmonic i Akamai razem zademonstrowały CMAF o niskim opóźnieniu już od NAB i IBC 2017, pokazując dostarczanie na żywo OTT z opóźnieniem poniżej pięciu sekund. Od tego czasu Harmonic zintegrował funkcjonalność DASH o niskim opóźnieniu w swoich produktach opartych na urządzeniach (Packager XOS i Electra XOS) oraz rozwiązaniach SaaS (VOS Cluster i VOS260). Wielu innych dostawców koderów i odtwarzaczy zrobiło to samo.
Niezależnie od tego, czy zdecydujesz się zaimplementować HLS o niskim opóźnieniu, czy też o niskim opóźnieniu dla DASH, przejście z istniejącej architektury dostarczania HLS i / lub DASH powinno być stosunkowo płynne i niedrogie.
5. Komunikacja w czasie rzeczywistym
WebRTC jest zwykle silnikiem zintegrowanego pakietu, który obejmuje koder, odtwarzacz i infrastrukturę dostarczania. Przykłady rozwiązań do przesyłania strumieniowego na dużą skalę opartych na WebRTC obejmują Real Time from Phenix, Limelight Realtime Streaming i Millicast z CoSMo Software and Influxis (Rysunek 3). Możesz również uzyskać dostęp do technologii WebRTC w narzędziach takich jak Wowza Streaming Engine, CoSMO Software i Red 5 Pro Server. Czasy opóźnienia dla technologii w tej klasie wahają się od 0,5 sekundy dla 71% strumieni (Phenix), poniżej 500 milisekund (Red5 Pro) do poniżej jednej sekundy (Limelight). Jeśli potrzebujesz opóźnienia poniżej dwóch sekund, WebRTC jest opcją, którą musisz rozważyć.
Jeśli potrzebujesz komunikacji w czasie rzeczywistym, prawdopodobnie będziesz musiał zaimplementować rozwiązanie oparte na WebRTC lub Websockets. WebRTC został opracowany do komunikacji między przeglądarką i jest obsługiwany przez wszystkie główne przeglądarki na komputery stacjonarne, na Androida, iOS, Chrome OS, Firefox OS, Tizen 3.0 i BlackBerry 10, więc powinien działać bez pobierania na każdej z tych platform. Jak sama nazwa wskazuje, WebRTC jest protokołem służącym do dostarczania strumieni na żywo do każdego widza, zarówno w trybie peer-to-peer, jak i server-to-peer.
WebSockets to protokół czasu rzeczywistego, który tworzy i utrzymuje trwałe połączenie między serwerem a klientem, którego każda ze stron może używać do przesyłania danych. To połączenie może służyć zarówno do dostarczania wideo, jak i innej komunikacji, więc jest wygodne, jeśli aplikacja wymaga interaktywności. Podobnie jak implementacje WebRTC, usługi korzystające z WebSockets są zwykle oferowane jako usługa obejmująca odtwarzacz i CDN i można użyć dowolnego kodera, który może przesyłać strumienie do serwera za pośrednictwem RTMP lub WebRTC. Przykłady obejmują chmurę nanoStream firmy Nanocosmos i chmurę strumieniową firmy Wowza z bardzo niskim opóźnieniem. Wowza twierdzi, że opóźnienie wynosi mniej niż 3 sekundy dla swojego rozwiązania, podczas gdy Nanocosmos twierdzi, że około jednej sekundy, szkło do szkła.
Inne technologie o niskim opóźnieniu
Istnieje czwarta kategoria produktów, które najlepiej określa się jako „inne”, które wykorzystują różne technologie w celu zapewnienia małych opóźnień. Ta kategoria obejmuje THEO Technologies High Efficiency Streaming Protocol (HESP), zastrzeżony adaptacyjny protokół przesyłania strumieniowego HTTP, który zgodnie z THEO zapewnia opóźnienie poniżej 100 milisekund, jednocześnie zmniejszając przepustowość o około 10% w porównaniu z innymi technologiami o niskim opóźnieniu. HESP wykorzystuje standardowe kodery i sieci CDN, ale wymaga niestandardowej obsługi w programie pakującym i odtwarzaczu (Rysunek 4). Możesz przeczytać więcej o HESP w białej księdze dostępnej do pobrania tutaj.
Oto lista pytań, które należy wziąć pod uwagę, decydując, którą technologię o niskim opóźnieniu zaimplementować i jak to zrobić.
Zbudować czy kupić?
Jeśli wdrażasz technologię samodzielnie, przed wyborem technologii odpowiedz na wszystkie poniższe pytania. Jeśli wybierasz usługodawcę, użyj go do porównania różnych usługodawców.
Wybierasz standard czy partnera?
Opisaliśmy powyżej różne technologie umożliwiające osiągnięcie niskich opóźnień, ale implementacje różnią się w zależności od usługodawcy. Tak więc nie wszystkie implementacje LL HLS będą obejmować dostarczanie ABR, przynajmniej nie na początku. Większość tradycyjnych aplikacji typu broadcast będzie prawdopodobnie migrować do standardów opartych na HTTP, takich jak HLS / DASH / CMAF o małych opóźnieniach, podczas gdy aplikacje wymagające bardzo małych opóźnień, takie jak zakłady i aukcje, będą kierować się w stronę innych technologii. W obu przypadkach przy wyborze dostawcy usług ważniejsze jest ustalenie, czy może on spełnić Twoje cele technologiczne i biznesowe, niż to, którą technologię faktycznie wdraża.
Czy można to skalować i jakim kosztem?
Jedną z zalet technologii opartych na protokole HTTP jest to, że można je skalować po standardowych cenach przy użyciu większości sieci CDN. W przeciwieństwie do tego większość technologii opartych na WebRTC i WebSocket wymaga dedykowanej infrastruktury dostarczania wdrożonej przez dostawcę usług. Z tego powodu dostarczanie usług innych niż HTTP może być droższe niż HLS / DASH / CMAF. Porównując dostawców usług, ustal koszt zupy do orzechów za wydarzenie, w tym koszty wejściowe, transkodowanie, przepustowość, tworzenie plików VOD, konfiguracje jednorazowe lub na wydarzenie i tym podobne.
Kwestie związane z wdrożeniem?
Zadaj następujące pytania związane z wdrażaniem i użytkowaniem technologii.
- Jakie jest możliwe opóźnienie w skali odpowiedniej do wielkości Twojej widowni i rozkładu geograficznego?
- Czy są jakieś ograniczenia jakościowe - niektóre technologie mogą być ograniczone do pewnych maksymalnych rozdzielczości lub profili H.264.
- Czy pakiety przejdą przez zaporę? Systemy oparte na protokole HTTP używają protokołów HTTP, które są przyjazne dla zapory. Inni używają protokołu UDP, który może nie przechodzić automatycznie przez zapory ogniowe. W przypadku UDP, czy są jakieś kanały wsteczne, które mają być dostarczane do zablokowanych widzów?
- Jakie platformy są obsługiwane? Prawdopodobnie komputery i urządzenia mobilne, ale co z STB, kluczami sprzętowymi, urządzeniami OTT i inteligentnymi telewizorami?
- Czy system może skalować się, aby osiągnąć docelową liczbę widzów? Czy infrastruktura CDN jest prywatna, a jeśli tak, czy może dostarczać ją wszystkim odpowiednim odbiorcom na wszystkich właściwych rynkach? Jakie są przewidywane koszty skalowania?
- Czy możesz użyć własnego odtwarzacza, czy też musisz użyć odtwarzacza systemu? Jeśli własne, jakie zmiany są wymagane i ile to będzie kosztować?
- Co jest potrzebne do odtwarzania na urządzeniach mobilnych? Czy strumienie będą odtwarzane w przeglądarce, czy wymagana jest aplikacja? Jeśli jest wymagana (lub pożądana) aplikacja, czy są dostępne pakiety SDK?
- Z jakich enkoderów może korzystać system? Większość z nich powinna używać dowolnego kodera, który może obsługiwać połączenia RTMP z transkoderem w chmurze, ale sprawdź, czy potrzebne są inne protokoły.
- Czy treść może zostać ponownie wykorzystana na potrzeby VOD, czy będzie wymagane ponowne kodowanie? Nie jest to wielka sprawa, ponieważ transkodowanie wideo do rozsądnej drabiny kodowania kosztuje około 20 USD / godzinę, ale jest drogie w przypadku częstych transmisji.
- Jakie są opcje zwolnienia i jakie są koszty? W przypadku transmisji o znaczeniu krytycznym warto wiedzieć, jak zduplikować przepływ pracy nad kodowaniem / rozgłaszaniem w przypadku awarii dowolnego elementu systemu podczas wydarzenia. Czy ta nadmiarowość jest obsługiwana i jaki jest jej koszt?
Jakie funkcje są dostępne iw jakiej skali?
Różni dostawcy będą oferować szeroką gamę funkcji, które mogą obejmować lub nie:
- Streaming ABR - ile strumieni i czy są jakieś istotne ograniczenia szybkości transmisji lub rozdzielczości?
- A co z funkcjami DVR? Czy widzowie mogą zatrzymać i wznowić odtwarzanie bez utraty treści.
- Synchronizacja wideo - Czy system może zsynchronizować wszystkich widzów w tym samym miejscu w strumieniu? Strumienie mogą dryfować po lokalizacjach i urządzeniach, a bez tej możliwości użytkownicy niektórych połączeń mogą mieć przewagę w aukcjach lub grach hazardowych.
- Jaka ochrona treści jest dostępna? Jeśli jesteś producentem treści premium, możesz potrzebować prawdziwego DRM. Inni mogą sobie poradzić z uwierzytelnianiem lub innymi podobnymi technikami.
- Czy dostępne są napisy? Napisy są prawnie wymagane w przypadku niektórych transmisji, ale ogólnie są korzystne dla wszystkich.
- A co ze wstawianiem reklam lub innym schematem zarabiania? Czy dostawca technologii / usług to obsługuje?
Ogólnie rzecz biorąc, jeśli prowadzisz sklep ze streamingiem, który stara się osiągnąć lub przekroczyć czasy transmisji w zakresie od 5 do 6 sekund, oparta na standardach technologia HTTP jest prawdopodobnie najlepszym rozwiązaniem, ponieważ będzie najbliżej obsługiwać ten sam zestaw funkcji, co Ty. obecnie używamy, takich jak ochrona treści, napisy i zarabianie. Jeśli masz aplikację, która wymaga znacznie krótszych opóźnień, prawdopodobnie będziesz potrzebować rozwiązania opartego na WebRTC lub Websockets albo zastrzeżonej technologii HTTP. W obu przypadkach zadawanie pytań wymienionych powyżej powinno pomóc w zidentyfikowaniu technologii i / lub dostawcy usług, który najlepiej spełnia Twoje potrzeby.