Od pierwszych dni pracy nad systemem monitoringu wideo w chmurze staliśmy przed problemem, bez rozwiązania, z którego mogliśmy zrezygnować w Ivideon - to był nasz Everest, wspinaczka, która wymagała dużo energii, ale teraz w końcu się udało wbił czekan w szczyt wieloplatformowej układanki.
System transmisji audio i wideo przez Internet nie powinien zależeć od sprzętu, klientów sieciowych i obsługiwanych przez nich standardów, a także działać poprawnie w obecności Translatorów Adresów Sieciowych i zapór sieciowych. Użytkownik monitoringu wideo w chmurze chce mieć dostęp do usługi, nawet jeśli korzysta z kamer analogowych i woli oglądać transmisję wideo na żywo na najnowocześniejszym urządzeniu.
Bardzo istotne jest to, że użytkownik chce oglądać filmy z minimalnym opóźnieniem. Prawie jedynym sposobem wyświetlania wideo z niskim opóźnieniem w przeglądarce jest użycie WebRTC (komunikacja internetowa w czasie rzeczywistym). WebRTC to zestaw technologii do transmisji wideo i audio w trybie peer-to-peer w przeglądarkach, pierwotnie zaprojektowany do transmisji i odtwarzania strumieni wideo z niskim opóźnieniem. W tym celu wykorzystywany jest między innymi protokół UDP.
Zanim opowiemy co daje użytkownikowi nowy silnik, przypomnimy dlaczego i dlaczego wspieramy technologie HLS oraz dlaczego zdecydowaliśmy się pójść dalej.
Silnik HLS: zalety i wady
()
Technologia HLS (HTTP Live Streaming) została opracowana przez Apple, nic więc dziwnego, że początkowo była obsługiwana na urządzeniach Apple. Obecnie wideo HLS jest również obsługiwane przez praktycznie wszystkie dekodery telewizji kablowej i wiele urządzeń z tym systemem operacyjnym. Android.
Silnik HLS wykorzystuje dobrze znany kodek wideo H264 w połączeniu ze strumieniami audio AAC lub MP3 do strumieniowego przesyłania danych wideo. Cały strumień danych audio i wideo jest pakowany w kontener transportowy MPEG-TS. W celu transmisji poprzez protokół HTTP, informacje zawarte w strumieniu dzielone są na fragmenty opisane w playlistach m3u8. I dopiero wtedy te fragmenty wraz z playlistami przesyłane są poprzez HTTP. Dzielenie automatycznie oznacza opóźnienie w sekundach. Jest to cecha kontenera MPEG-TS.
Silnik HLS obsługuje także strumienie o wielu przepływnościach, Live/VOD.
Główne zalety HLS:
- wbudowana obsługa we wszystkich głównych przeglądarkach;
- łatwość wdrożenia (w porównaniu do WebRTC);
- Organizowanie wszelkiego rodzaju transmisji dla dużej grupy odbiorców jest bardzo wygodne i efektywne, ponieważ segmenty można jednorazowo wgrać do CDN.
Pomimo prostoty silnika, nie wszystko jest tak płynne, jak się wydaje. Głównym problemem jest to, że zewnętrzni twórcy odtwarzaczy odeszli od zaleceń Apple, na przykład w zakresie obsługiwanych formatów audio. W szczególności wielu programistów zaczęło dodawać możliwość pracy z popularnymi strumieniami audio: wideo mpeg2, audio mpeg2 itp. W rezultacie musieli stworzyć różne formaty list odtwarzania dla różnych odtwarzaczy.
Jednak jednym z największych problemów związanych z silnikiem HLS są duże opóźnienia w przesyłaniu danych.
Początki „hamulców”
Główną przyczyną dużych opóźnień HLS jest fakt, że programiści stworzyli silnik w celu uzyskania obrazów najwyższej jakości. Dlatego parametry użytego interwału klatek i wielkość bufora odtwarzania po prostu nie nadają się do transmisji wideo na żywo. Z tego powodu występuje dość duże opóźnienie w transmisji materiału wideo, które może wynosić 5-7 sekund.
Z jednej strony to niewiele, np. dla tych, którzy oglądają film z serwera hostingowego wideo. Jednak w przypadku systemów nadzoru wideo opóźnienie w przesyłaniu materiału wideo może być bardzo ważne.
Jeśli obserwujesz biuro, w którym pracownicy raz na godzinę odrywają wzrok od monitorów, wówczas 5-sekundowe opóźnienie nie ma żadnego znaczenia. Ale ludzie zaczęli narzekać, że np. podczas transmisji meczu piłkarskiego napisali już na czacie GOOOOL, ale tego jeszcze nie ma na filmie :). Mamy już wiele przypadków użytkowników, w których Ivideon powinien praktycznie zastąpić Skype.
Czy można pokonać opóźnienia w HLS? Odpowiedź na to pytanie brzmi jak przemówienie doświadczonego tępiciela szczurów na wykładzie skierowanym do początkujących specjalistów od zwalczania szkodników: „Szczurów nie można wytępić, ale można ograniczyć ich liczebność do rozsądnego minimum”. Podobnie z opóźnieniem w HLS, nie uda się go zredukować do zera, jednak na rynku istnieją rozwiązania, które mogą znacząco zmniejszyć opóźnienie.
Drobne cięcia
Kolejną wadą silnika jest wykorzystywanie małych plików do przesyłania danych. Wydawałoby się, że co w tym złego?
Każdy, kto próbował skopiować dużą liczbę małych plików z jednego nośnika na drugi, zapewne zauważył, że prędkość zapisu takiego zestawu jest znacznie niższa niż jednego dużego pliku o tej samej wielkości. A intensywność dostępu do dysku twardego znacznie wzrasta, co generalnie negatywnie wpływa na wydajność całego komputera. Dlatego przesyłanie danych wideo w małych 10-sekundowych fragmentach również przyczynia się do zwiększenia opóźnień silnika.
Podsumujmy pokrótce wszystkie zalety i wady technologii HLS.
Zalety HLS:
- Możliwość pracy z dowolnym urządzeniem. Możesz oglądać filmy na dowolnym nowoczesnym urządzeniu, czy to smartfonie, tablecie, laptopie czy komputerze stacjonarnym. Najważniejsze, że przeglądarka internetowa jest aktualna i kompatybilna z HTML5 i Media Source Extensions.
- Doskonała jakość obrazu. Zastosowana funkcja adaptacyjnej transmisji danych pozwala na dynamiczną zmianę jakości przesyłanego obrazu w zależności od przepustowości łącza internetowego, przy czym algorytm dąży do zachowania maksymalnej jakości.
- Nie ma potrzeby skomplikowanej konfiguracji sprzętu użytkownika.
Wady:
- Ograniczona obsługa pracy z silnikiem na niektórych urządzeniach.
- Duże opóźnienia w transmisji obrazu.
- Znaczący wzrost kosztów ogólnych i złożoności optymalizacji ze względu na użycie małych plików. Ze względu na charakter kontenera nigdy nie będziemy w stanie uzyskać opóźnienia mniejszego niż rozmiar segmentu.
Wady HLS przeważyły nad jego zaletami i zmusiły nas do poszukiwania alternatywnych opcji.
Co to jest WebRTC
()
Platforma WebRTC została opracowana przez Google w 2011 roku w celu przesyłania strumieniowego danych wideo i audio między przeglądarkami i aplikacjami mobilnymi przy minimalnym opóźnieniu. W tym celu stosuje się standardowy protokół UDP i specjalne algorytmy kontroli przepływu. Dziś jest to projekt open source, aktywnie utrzymywany i rozwijany przez Google.
WebRTC to zestaw technologii służących do transmisji obrazu i dźwięku typu peer-to-peer. Oznacza to, że na przykład przeglądarki użytkownika korzystające z WebRTC mogą przesyłać dane między sobą bezpośrednio, bez konieczności korzystania ze zdalnych serwerów do przechowywania i przetwarzania danych. Wszelkie informacje przetwarzane są także przez przeglądarki użytkowników końcowych i aplikacje mobilne.
Wygodę i szerokie możliwości tej technologii docenili twórcy wszystkich popularnych przeglądarek. Obsługa WebRTC jest obecnie dostępna w przeglądarkach Mozilla Firefox, Opera, Google Chrome (i wszystkich przeglądarkach opartych na Chromium), a także w aplikacjach mobilnych działających na Android i iOS.
Pomimo wszystkich swoich niewątpliwych zalet WebRTC ma kilka istotnych wad.
Trudności wyboru
Technologia WebRTC jest znacznie bardziej złożona pod względem interakcji sieciowych ze względu na fakt, że dotyczy P2P. Jest trudny do debugowania, testowania i może zachowywać się nieprzewidywalnie. Jednocześnie musimy pokonać NAT i firewall, musimy zapewnić działanie w sieciach, w których blokowane jest UDP.
Implementacja WebRTC firmy Google jest bardzo trudna w użyciu. Istnieje nawet cała firma świadcząca usługi montażu SDK. Poza tym wdrożenie Google było bardzo trudne do zintegrowania z naszym systemem bez ponownego kodowania całego wideo.
Jednak od dawna chcieliśmy dać użytkownikom możliwość pracy z pełnoprawnym wideo „na żywo” i zminimalizować opóźnienie pomiędzy obrazem na ekranie a samymi wydarzeniami. Ponadto chcieliśmy, aby korzystanie z kamer PTZ, gdzie opóźnienia są krytyczne, było wygodniejsze.
Biorąc pod uwagę, że inne implementacje przeciwdziałające lagom nadal mają ograniczoną funkcjonalność i działają zauważalnie gorzej, zdecydowaliśmy się zastosować WebRTC.
Co my zrobiliśmy
Prawidłowe wdrożenie platformy WebRTC nie jest zadaniem łatwym. Wszelkie błędne obliczenia lub niedokładności mogą prowadzić do tego, że opóźnienia w transmisji wideo nie tylko nie maleją w porównaniu z innymi platformami, ale nawet rosną.
Aby WebRTC działało poprawnie, należy przede wszystkim przeprowadzić modernizację technologiczną stosu do pracy z wideo w sieci. To właśnie zrobiliśmy.
Najpierw wdrożyliśmy serwer protokołu sygnalizacyjnego WebRTC za pośrednictwem protokołu Websocket, a także wdrożyliśmy serwer równorzędny WebRTC w chmurze w oparciu o pakiet SDK webrtc.org. Jego zadaniem jest dystrybucja strumieni wideo do klienckich partnerów WebRTC w formacie H.264 + Opus/G.711 bez transkodowania wideo.
Jako protokół sygnalizacyjny wybraliśmy Websocket, ponieważ zapewnia on już wysokiej jakości obsługę we wszystkich popularnych przeglądarkach internetowych. Dzięki temu można znacznie zmniejszyć nie tylko obciążenie programistyczne, ale także uniknąć marnowania czasu i zasobów na powtarzające się uzgadnianie TCP i TLS w porównaniu z AJAX.
Faktem jest, że WebRTC domyślnie nie udostępnia protokołu sygnalizacyjnego niezbędnego do prawidłowego skonfigurowania, utrzymania i zakończenia komunikacji wideo w czasie rzeczywistym pomiędzy aplikacją źródłową a aplikacją kliencką.
Aby samodzielnie wdrożyć technologię sygnalizacyjną, musieliśmy opracować własny serwer sygnalizacyjny obsługujący kilka protokołów internetowych (Websocet, WebRTC). Oraz możliwość bezpiecznego zarządzania sesjami i powiadomieniami w czasie rzeczywistym, zarządzanie wideo i wiele więcej.
Pokonaliśmy ograniczenia P2P, zmniejszając opóźnienia nie poprzez P2P, ale poprzez UDP i kontrolę przepływu, aby zmniejszyć opóźnienia. Jest to również wbudowane w WebRTC, ponieważ głównym przypadkiem użycia są rozmowy p2p za pośrednictwem przeglądarki.
W kliencie mobilnym odtwarzacz zaimplementowaliśmy przy użyciu zestawu SDK webrtc.org, ponieważ tylko on poprawnie implementuje kontrolę przepływu, posiada wszystkie znane schematy Forward Error Correction (FEC) i poprawnie implementuje mechanizm ponownego wysyłania pakietów dla wszystkich przeglądarek. Ważne jest również, że pakiet SDK webrtc.org jest aktywnie rozwijany przez Google.
Jaki jest rezultat wdrożenia WebRTC?
Aby oglądać wideo na żywo z kamer, do Twojego konta osobistego dodaliśmy nowy, zoptymalizowany odtwarzacz oparty na WebRTC. Zapewnia dużą prędkość ładowania wideo i całkowicie eliminuje problem opóźnień narastających wraz ze wzrostem czasu oglądania.
Po wprowadzeniu obsługi WebRTC w usłudze chmurowej Ivideon, możemy z całkowitą pewnością stwierdzić, że nasi klienci mogą teraz oglądać pełnoprawny obraz wideo na żywo. Teraz opóźnienie przy transmisji sekwencji wideo nie przekracza jednej sekundy! Dla porównania poprzedni silnik HLS zapewniał dostarczanie wideo z opóźnieniem 5-7 sekund. Różnica w szybkości demonstracji wideo jest bardzo znacząca i użytkownik zauważy ją natychmiast po rozpoczęciu pracy z naszym serwisem wideo.
Tak jak się spodziewaliśmy, wdrożenie nowego odtwarzacza poprawiło responsywność PTZ i komunikację głosową z kamerą.
Jest tylko jeden subtelny punkt, na który chcemy zwrócić uwagę. Nowy odtwarzacz WebRTC pracuje obecnie w trybie testowym. Dlatego też nie włączamy tej opcji domyślnie dla wszystkich naszych klientów. Ale możesz go aktywować samodzielnie, włączając odpowiedni element w ustawieniach aparatu (aby to zrobić, musisz przejść do ).
Funkcje wdrożenia WebRTC w usłudze Ivideon
WebRTC jest obecnie technologią wciąż eksperymentalną. Jego obsługa nie jest jeszcze poprawnie zaimplementowana we wszystkich przeglądarkach i urządzeniach użytkowników, a także nie we wszystkich aparatach.
Właśnie dlatego nie ustawiliśmy jeszcze odtwarzacza WebRTC jako domyślnego dla wszystkich użytkowników.
Na razie zalecamy korzystanie z WebRTC wyłącznie w przeglądarkach Google Chrome. Najnowsze wersje Firefoksa i Safari również obsługują tę technologię, ale niestety jest ona nadal niestabilna.
Nie wdrożyliśmy jeszcze obsługi WebRTC dla przeglądarek na urządzeniach mobilnych. Obecnie, jeśli logujesz się z urządzenia mobilnego i aktywujesz WebRTC, ten tryb nie będzie działać. Jednak WebRTC jest dostępny w naszych aplikacjach mobilnych dla и .
I kończąc opowieść o funkcjach implementacji WebRTC w naszym serwisie, zwróćmy uwagę na jeszcze dwie subtelne kwestie.
Po pierwsze, technologia koncentruje się na transmisji wideo na żywo w czasie rzeczywistym. Dlatego jeśli Twój kanał nie ma wystarczającej przepustowości, aby transmitować wideo, zauważysz spadki klatek (w przypadku HLS zauważysz zanikanie wideo i zwiększone opóźnienia, ale nie będzie spadków klatek), ale wideo będzie nadal transmitowane w rzeczywistości czas.
Po drugie, ponieważ technologia jest zaprojektowana do pracy z wideo na żywo w czasie rzeczywistym, nie wykorzystujemy jej do pracy z archiwalnymi danymi wideo.
Pozostałe zmiany w serwisie
W tej chwili Flash nie jest już zaangażowany w mechanizm automatycznego wyboru silnika. Nadal możesz korzystać z takiego odtwarzacza, jednak w tym celu musisz wybrać go ręcznie w ustawieniach konta lub aparatu. To nie jest hołd dla mody, po prostu według statystyk naszego serwisu praktycznie nie ma już użytkowników pracujących z Flashem. A próbując ustalić, czy przeglądarka użytkownika to obsługuje, tracimy około 2 sekund cennego czasu.
Oto krótki przegląd zmian, które czekają na Ciebie w naszym systemie nadzoru wideo w chmurze i koncie osobistym. Bądź z nami i śledź aktualności!
Źródło: www.habr.com
