Od pierwszych dni pracy nad systemem chmurowego monitoringu wideo napotkaliśmy problem, bez rozwiązania którego na Ivideon można byłoby postawić krzyżyk – to była nasza Góra Lodowa, wspinaczka na którą zabrała mnóstwo sił, ale teraz w końcu wbiliśmy czekan w szczyt międzyplatformowego zagadnienia.
System przesyłania dźwięku i wideo przez Internet nie powinien zależeć od sprzętu, klientów internetowych i ich standardów oraz powinien poprawnie działać w obecności translatorów adresów sieciowych i zapór ogniowych. Użytkownik chmurowego monitoringu wideo chce mieć dostęp do usługi, nawet jeśli korzysta z analogowych kamer, a transmisję na żywo woli oglądać na najnowocześniejszym urządzeniu.
To bardzo istotne, że użytkownik chce oglądać wideo z minimalnym opóźnieniem. Praktycznie jedyną możliwością pokazania wideo z niskim opóźnieniem w przeglądarce jest użycie WebRTC (web real-time communications). WebRTC to zbiór technologii do peer-to-peer przesyłania wideo i dźwięku w przeglądarkach, pierwotnie zaprojektowany do przesyłania i odtwarzania strumienia wideo z niskim opóźnieniem. W tym celu, między innymi, stosowany jest protokół UDP.
Zanim opowiemy, co nowy silnik daje użytkownikowi, przypomnimy, dlaczego wspieramy technologie HLS oraz po co zdecydowaliśmy się na dalszy rozwój.
Silnik HLS: zalety i wady
()
Technologia HLS (HTTP Live Streaming) została opracowana przez Apple, dlatego nie jest zaskoczeniem, że po raz pierwszy jej wsparcie pojawiło się na urządzeniach tej marki. Obecnie strumienie wideo w formacie HLS potrafią odtwarzać praktycznie wszystkie dekodery telewizyjne oraz wiele urządzeń działających na systemie Android.
Silnik HLS wykorzystuje do przesyłania strumieni wideo dobrze znany kodek wideo H264 w połączeniu z strumieniami audio AAC lub MP3. Cały strumień danych audio-wideo jest pakowany w kontener transportowy MPEG-TS. Aby przesłać dane przez protokół HTTP, informacje zawarte w strumieniu są dzielone na fragmenty, opisane w playlistach m3u8. Dopiero potem te fragmenty wraz z playlistami są przesyłane przez HTTP. Podział na fragmenty automatycznie oznacza opóźnienie w sekundach. Ta cecha kontenera MPEG-TS.
Silnik HLS obsługuje również strumienie wielobitowe, Live/VOD.
Główne zalety HLS:
- wbudowane wsparcie we wszystkich popularnych przeglądarkach;
- łatwość implementacji (w porównaniu do WebRTC);
- bardzo wygodne i efektywne organizowanie transmisji dla dużych odbiorców, dzięki możliwości jednorazowego załadowania segmentów na CDN.
Pomimo całej prostoty silnika, nie wszystko w nim jest tak płynne, jak się wydaje. Głównym problemem jest to, że deweloperzy zewnętrznych odtwarzaczy odeszli od zaleceń Apple, na przykład w zakresie obsługiwanych formatów audio. W szczególności wielu deweloperów zaczęło dodawać możliwość pracy z popularnymi strumieniami audio: mpeg2 video, mpeg2 audio itd. W rezultacie trzeba było stworzyć różne formaty list odtwarzania dla różnych odtwarzaczy.
Jednak jednym z największych problemów silnika HLS jest duża opóźnienie w przesyłaniu danych.
Przyczyny "zacięć"
Główną przyczyną wysokiego opóźnienia w HLS jest to, że programiści stworzyli silnik z myślą o uzyskaniu jak najwyższej jakości obrazu. Dlatego parametry używanego interwału klatek i objętość bufora odtwarzania po prostu nie pasują do prowadzenia transmisji wideo na żywo. W wyniku tego występuje stosunkowo wysokie opóźnienie w przesyłaniu wideo, które może wynosić 5-7 sekund.
Z jednej strony to niespecjalnie dużo, na przykład dla tych, którzy oglądają film z serwera wideo. Ale dla systemów monitoringu opóźnienie w przesyłaniu wideo może mieć ogromne znaczenie.
Jeśli obserwujesz biuro, w którym pracownicy co godzinę odrywają się od monitorów, to 5 sekund opóźnienia nie ma większego znaczenia. Jednak ludzie zaczęli narzekać, że na przykład podczas transmisji meczu piłkarskiego w czacie już napisano GOOOOL, a na wideo tego jeszcze nie ma :). Już mamy kilka przypadków użytkowników, gdzie Ivideon musi prawie zastąpić skype.
Czy można pokonać opóźnienie w HLS? Odpowiedź na to pytanie brzmi jak wystąpienie doświadczonego zwalczyciela szczurów na wykładzie przed początkującymi deratyzatorami: "Szczurów nie da się wyeliminować, ale ich populację można zredukować do rozsądnego minimum". Tak i z opóźnieniem w HLS, nie da się go zredukować do zera, ale na rynku są rozwiązania, które pozwalają znacznie zmniejszyć opóźnienie.
Małe segmenty
Kolejnym minusem silnika jest użycie 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 inny, na pewno zauważył, że prędkość zapisu takiego zestawu jest znacznie niższa niż w przypadku jednego dużego pliku o tej samej objętości. Intensywność odwołań do dysku twardego również znacznie wzrasta, co ogólnie negatywnie wpływa na wydajność całego komputera. Dlatego przesyłanie danych wideo w postaci małych 10-sekundowych fragmentów także przyczynia się do zwiększonego opóźnienia silnika.
Podsumujmy wszystkie zalety i wady technologii HLS.
Zalety HLS:
- Możliwość pracy z dowolnymi urządzeniami. Możesz oglądać wideo na każdym nowoczesnym urządzeniu, czy to smartfonie, tablecie, laptopie czy komputerze stacjonarnym. Ważne, aby przeglądarka internetowa była nowoczesnej wersji i była zgodna z HTML5 oraz Media Source Extensions.
- Doskonała jakość obrazu. Używana funkcja adaptacyjnego przesyłania danych pozwala dynamicznie zmieniać jakość przesyłanego obrazu w zależności od pasma przepustowości połączenia internetowego, przy czym algorytm stara się zachować maksymalną jakość.
- Brak potrzeby skomplikowanej konfiguracji sprzętu użytkownika.
Wady:
- Ograniczone wsparcie dla działania silnika na niektórych urządzeniach.
- Wysokie opóźnienia w przesyłaniu obrazu.
- Znaczny wzrost kosztów operacyjnych i trudności w optymalizacji z powodu użycia małych plików. Z powodu specyfiki pojemnika nigdy nie będziemy mogli uzyskać opóźnienia mniejszego niż rozmiar segmentu.
Wady HLS przewyższyły dla nas jego zalety i zmusiły nas do poszukiwania alternatywnych rozwiązań.
Czym jest WebRTC
()
Platforma WebRTC została opracowana przez Google w 2011 roku, aby przesyłać strumieniowe dane wideo i audio między przeglądarkami a aplikacjami mobilnymi z minimalnym opóźnieniem. W tym celu używany jest standardowy protokół UDP oraz specjalne algorytmy zarządzania strumieniem. Dziś jest to projekt o otwartym kodzie źródłowym, który jest aktywnie wspierany i rozwijany przez Google.
WebRTC to zestaw technologii do transmisji wideo i dźwięku peer-to-peer. Oznacza to, że na przykład przeglądarki użytkowników mogą przesyłać dane bezpośrednio do siebie za pośrednictwem WebRTC, bez użycia zdalnych serwerów do przechowywania i przetwarzania danych. Wszystkie informacje są także przetwarzane przez przeglądarki i aplikacje mobilne końcowych użytkowników.
Wygodę i dużą funkcjonalność tej technologii docenili programiści wszystkich popularnych przeglądarek. Dziś wsparcie dla WebRTC jest realizowane w Mozilla Firefox, Operze, Google Chrome (i wszystkich przeglądarkach opartych na Chromium), a także w aplikacjach mobilnych na Androida i iOS.
Pomimo wszystkich swoich niewątpliwych zalet, WebRTC ma kilka istotnych wad.
Trudności w wyborze
Technologia WebRTC jest znacznie bardziej skomplikowana pod względem interakcji sieciowych, ponieważ jest oparta na P2P. Trudno ją debugować i testować, może działać w sposób nieprzewidywalny. Musimy też pokonywać NAT i zapory sieciowe, zapewniając funkcjonowanie w sieciach, w których UDP jest zablokowane.
Realizacja WebRTC od Google jest bardzo trudna w użyciu. Istnieje nawet cała firma, która świadczy usługi w zakresie budowy SDK. Dodatkowo implementacja od Google była bardzo trudna do zintegrowania z naszym systemem w taki sposób, aby nie trzeba było przetwarzać całego wideo.
Jednak od dawna chcieliśmy dać użytkownikom możliwość pracy z pełnoprawnym, 'na żywo' wideo i zminimalizować opóźnienia obrazu na ekranie w porównaniu z rzeczywistymi wydarzeniami. Co więcej, chcieliśmy ułatwić korzystanie z kamer PTZ, w których opóźnienia mają kluczowe znaczenie.
Biorąc pod uwagę, że inne implementacje walki z lagami mają ograniczoną funkcjonalność i działają zauważalnie gorzej, postanowiliśmy skorzystać z WebRTC.
Co zrobiliśmy
Rozsądne wdrożenie platformy WebRTC to niełatwe zadanie. Każde niedopatrzenie lub nieścisłość mogą spowodować, że opóźnienia w transmisji wideo nie tylko nie zmniejszą się w porównaniu do innych platform, ale wręcz wzrosną.
Aby WebRTC działało poprawnie, należy najpierw przeprowadzić modernizację technologii stosu do pracy z wideo w Internecie. I to zrobiliśmy.
Najpierw zrealizowaliśmy serwer sygnalizacyjny protokołu WebRTC oparty na Websocket oraz wdrożyliśmy serwer peer WebRTC w chmurze na podstawie SDK webrtc.org. Jego zadaniem jest dostarczanie strumieni wideo do klienckich peerów WebRTC w formacie H.264 + Opus/G.711 bez transkodowania wideo.
Wybór Websocket jako protokołu sygnalizacyjnego wynika z jego solidnego wsparcia w popularnych przeglądarkach internetowych. Dzięki temu można znacząco zmniejszyć zarówno koszty rozwoju, jak i czas oraz zasoby potrzebne na powtarzające się zestawienia TCP i TLS w porównaniu do AJAX.
Faktem jest, że domyślnie WebRTC nie dostarcza protokołu sygnalizacyjnego, który jest niezbędny do prawidłowego ustawienia, wsparcia i zakończenia wideo rozmowy w czasie rzeczywistym między aplikacjami źródłowymi a klienckimi.
Aby samodzielnie zaimplementować technologię sygnalizacji, musieliśmy opracować własny serwer sygnalizacyjny obsługujący różne protokoły internetowe (Websockt, WebRTC). A także z możliwością bezpiecznego zarządzania sesjami i powiadomieniami w czasie rzeczywistym, zarządzania wideo i wieloma innymi parametrami.
Ograniczenia P2P pokonaliśmy, zmniejszając opóźnienia nie poprzez P2P, ale poprzez UDP i zarządzanie strumieniem, które koncentruje się na redukcji opóźnień. To również jest zawarte w WebRTC, ponieważ głównym zastosowaniem są rozmowy p2p przez przeglądarkę.
W mobilnym kliencie zaimplementowaliśmy odtwarzacz z użyciem SDK webrtc.org, ponieważ tylko w nim prawidłowo zaimplementowano zarządzanie strumieniem, są wszystkie znane schematy Forward Error Correction (FEC), a mechanizm ponownej wysyłki pakietów działa poprawnie we wszystkich przeglądarkach. Nie bez znaczenia jest również fakt, że SDK webrtc.org jest aktywnie rozwijane przez Google.
Jaki jest wynik wdrożenia WebRTC?
Aby oglądać na żywo wideo z kamer, dodaliśmy do panelu użytkownika nowy zoptymalizowany odtwarzacz oparty na WebRTC. Oferuje on wysoką prędkość ładowania obrazu wideo i całkowicie eliminuje problem gromadzenia opóźnień w miarę wydłużania się czasu oglądania.
Po wprowadzeniu wsparcia dla WebRTC w chmurze Ivideon możemy z pełnym przekonaniem stwierdzić, że teraz nasi klienci mają dostęp do pełnowymiarowego transmisji na żywo. Obecnie opóźnienie przy przesyłaniu wideo nie przekracza jednej sekundy! Dla porównania, poprzedni silnik HLS zapewniał dostawę z opóźnieniem 5-7 sekund. Różnica w szybkości pokazu wideo jest znaczna, a użytkownik od razu to zauważy po rozpoczęciu korzystania z naszego serwisu wideo.
Jak przewidywaliśmy, wdrożenie nowego odtwarzacza umożliwiło zwiększenie reaktywności PTZ i głosowej komunikacji z kamerą.
Jest tylko jeden drobny element, na który chcemy zwrócić uwagę. Nowy odtwarzacz WebRTC obecnie działa w trybie testowym. Dlatego nie włączamy go domyślnie dla wszystkich naszych klientów. Możesz go jednak aktywować samodzielnie, włączając odpowiedni punkt w ustawieniach kamery (musisz wejść w ).
Cechy implementacji WebRTC w usłudze Ivideon
WebRTC w tej chwili wciąż jest technologią eksperymentalną. Jej wsparcie nie zostało jeszcze prawidłowo wdrożone we wszystkich przeglądarkach i urządzeniach użytkowników, ani we wszystkich kamerach.
Właśnie to wyjaśnia, dlaczego nie uczyniliśmy odtwarzacza WebRTC domyślnym dla wszystkich użytkowników.
Na razie zalecamy korzystać z WebRTC tylko w przeglądarkach Google Chrome. Najnowsze wersje Firefox i Safari również wspierają tę technologię, ale niestety jeszcze nie są stabilne.
Nie wprowadziśmy jeszcze wsparcia dla WebRTC w przeglądarkach na urządzeniach mobilnych. Jeśli teraz zalogujesz się z urządzenia mobilnego i aktywujesz WebRTC, tryb ten nie będzie działał. Niemniej jednak, WebRTC jest dostępne w naszych aplikacjach mobilnych dla i .
Kończąc naszą opowieść o cechach implementacji WebRTC w naszej usłudze, zwróćmy uwagę na jeszcze dwa drobne szczegóły.
Po pierwsze, technologia ta jest ukierunkowana na transmisję właśnie na żywo w czasie rzeczywistym. Z tego powodu, jeśli wydajność Twojego łącza będzie niewystarczająca do przesyłania wideo, zauważysz utratę klatek (z HLS zauważysz zamarzanie wideo i zwiększenie opóźnienia, przy tym klatki nie będą się gubić), ale wideo nadal będzie przesyłane w czasie rzeczywistym.
Po drugie, ponieważ technologia została stworzona specjalnie do pracy z żywym wideo w czasie rzeczywistym, nie używamy jej do pracy z archiwalnymi danymi wideo.
Inne zmiany w usłudze
Obecnie Flash nie bierze już udziału w mechanizmie automatycznego wyboru silnika. Nadal można skorzystać z tego odtwarzacza, jednak należy go wybrać ręcznie w ustawieniach konta lub kamery. To nie moda, lecz według statystyk naszego serwisu niemal nie ma użytkowników korzystających z Flasha. Przy próbie określenia, czy jego przeglądarka obsługuje Flasha, tracimy około 2 sekundy cennego czasu.
Oto krótko o zmianach, które czekają na Ciebie w naszym chmurowym systemie monitoringu wideo i panelu użytkownika. Pozostań z nami i śledź nowości!
Źródło: habr.com
