WebRTC и видео надзор: како го победивме видео доцнењето од камерите

Уште од првите денови на работа на системот за видео надзор во облак, се соочивме со проблем, без решение за кое би можеле да се откажеме од Ивидеон - ова беше нашиот Еверест, искачувањето кое одзеде многу енергија, но сега конечно имаме заглави ледена секира во горниот дел од сложувалката со вкрстени платформи.

Системот за пренос на аудио и видео преку Интернет не треба да зависи од опремата, веб-клиентите и стандардите што тие ги поддржуваат, а исто така да работи правилно во присуство на преведувачи на мрежни адреси и заштитни ѕидови. Корисникот на видео надзор во облак сака да пристапи до услугата, дури и ако користи аналогни камери, и претпочита да гледа видео емитување во живо на најсовремениот уред.

Многу е значајно што корисникот сака да гледа видеа со минимално доцнење. Речиси единствениот начин да се прикаже видео со мала латентност во прелистувачот е да се користи WebRTC (веб-комуникации во реално време). WebRTC е збир на технологии за peer-to-peer пренос на видео и аудио во прелистувачите, првично дизајнирани за пренос и репродукција на видео потоци со мала латентност. За таа цел, меѓу другото, се користи протоколот UDP.

Пред да ви кажеме што му дава новиот мотор на корисникот, ќе ве потсетиме зошто и зошто ги поддржуваме технологиите HLS и зошто решивме да продолжиме понатаму.

HLS мотор: добрите и лошите страни

(c)

Технологијата HLS (HTTP Live Streaming) е развиена од Apple, па затоа не е изненадувачки што првично била поддржана на уредите на Apple. Денес, HLS видео е поддржано и од практично сите сет-топ боксови и многу уреди што го користат оперативниот систем. Android.

Моторот HLS го користи добро познатиот видео кодек H264 во комбинација со аудио преноси AAC или MP3 за пренос на видео податоци. Целиот поток на аудио и видео податоци е спакуван во транспортен контејнер MPEG-TS. За пренос преку протоколот HTTP, информациите содржани во потокот се поделени на фрагменти опишани во листите за репродукција m3u8. И само тогаш овие фрагменти, заедно со листите за репродукција, се пренесуваат преку HTTP. Распарчувањето автоматски значи доцнење во секунди. Ова е карактеристика на контејнерот MPEG-TS.

Моторот HLS поддржува и мултибитатни преноси, Live/VOD.

Главните предности на HLS:

• вградена поддршка во сите главни прелистувачи;
• леснотија на имплементација (во споредба со WebRTC);
• Многу е погодно и ефикасно да се организираат сите видови преноси до голема публика поради фактот што сегментите може да се прикачат еднаш на CDN.

И покрај едноставноста на моторот, не е сè толку мазно како што изгледа. Главниот проблем е што програмерите на трети лица се оддалечија од препораките на Apple, на пример во однос на поддржаните аудио формати. Особено, многу програмери почнаа да додаваат можност за работа со популарни аудио преноси: mpeg2 видео, mpeg2 аудио, итн. Како резултат на тоа, тие мораа да креираат различни формати на плејлисти за различни играчи.

Но, еден од најголемите проблеми со моторот HLS е високата латентност во преносот на податоци.

Потеклото на „сопирачките“

Главната причина за високата латентност на HLS лежи во фактот што програмерите го создадоа моторот за да добијат слики со највисок квалитет. Затоа, параметрите на користениот интервал на рамки и големината на баферот за репродукција едноставно не се погодни за видео преноси во живо. Поради ова, има прилично големо доцнење во преносот на видео снимката, што може да биде 5-7 секунди.

Од една страна, ова не е многу, на пример, за оние кои гледаат филм од сервер за видео хостинг. Но, за системите за видео надзор, доцнењето во преносот на видео снимката може да биде многу важно.

Ако гледате канцеларија во која вработените гледаат од нивните монитори еднаш на час, тогаш доцнењето од 5 секунди воопшто не е важно. Но, луѓето почнаа да се жалат дека, на пример, кога емитувале фудбалски натпревар, веќе напишале ГООООЛ во разговорот, но ова сè уште го нема на видеото :). Веќе имаме голем број на кориснички случаи каде што Ivideon практично треба да го замени Skype.

Дали е можно да се победи латентноста во HLS? Одговорот на ова прашање звучи како говор на искусен истребувач на стаорци на предавање пред почетници специјалисти за контрола на штетници: „Стаорците не можат да се истребат, но нивниот број може да се намали на разумен минимум“. Истото со доцнењето во HLS, нема да може да се сведе на нула, но на пазарот има решенија кои можат значително да го намалат доцнењето.

Фини парчиња

Друг недостаток на моторот е употребата на мали датотеки за пренос на податоци. Се чини дека што не е во ред со ова?

Секој што се обидел да копира голем број мали датотеки од еден медиум на друг, веројатно забележал дека брзината на пишување на таков сет е многу помала од една голема датотека со иста големина. И интензитетот на пристап до хард дискот значително се зголемува, што генерално негативно влијае на перформансите на целиот компјутер. Затоа, преносот на видео податоци во мали делови од 10 секунди, исто така, придонесува за зголемена латентност на моторот.

Ајде накратко да ги сумираме сите добрите и лошите страни на HLS технологијата.

Предности на HLS:

1. Способност за работа со кој било уред. Можете да гледате видеа на кој било модерен уред, било да е тоа паметен телефон, таблет, лаптоп или десктоп компјутер. Главната работа е што веб-прелистувачот е ажуриран и компатибилен со HTML5 и екстензии за извор на медиуми.
2. Одличен квалитет на сликата. Користената адаптивна функција за пренос на податоци ви овозможува динамички да го менувате квалитетот на пренесеното видео во зависност од пропусниот опсег на интернет конекцијата, додека алгоритмот се стреми да го одржи максималниот квалитет.
3. Нема потреба од сложена конфигурација на опремата на корисникот.

Недостатоци:

1. Ограничена поддршка за работа со моторот на некои уреди.
2. Големи доцнења во преносот на сликата.
3. Значително зголемување на трошоците и сложеноста на оптимизацијата поради употребата на мали датотеки. Поради природата на контејнерот, никогаш нема да можеме да добиеме латентност помала од големината на сегментот.

Недостатоците на HLS ги надминаа неговите предности за нас и не принудија да бараме алтернативни опции.

Што е WebRTC

(c)

Платформата WebRTC беше развиена од Google во 2011 година за да пренесува стриминг видео и аудио податоци помеѓу прелистувачите и мобилните апликации со минимална латентност. За ова се користат стандардниот UDP протокол и специјалните алгоритми за контрола на протокот. Денес тоа е проект со отворен код, активно се одржува од Google и се развива.

WebRTC е збир на технологии за peer-to-peer видео и аудио пренос. Тоа е, на пример, корисничките прелистувачи кои користат WebRTC можат директно да префрлаат податоци еден на друг, без да користат оддалечени сервери за складирање и обработка на податоци. Сите информации се обработуваат и од прелистувачите на крајните корисници и мобилните апликации.

Практичноста и широките можности на оваа технологија се ценети од развивачите на сите популарни прелистувачи. Поддршката за WebRTC моментално е достапна во Mozilla Firefox, Opera, Google Chrome (и сите прелистувачи базирани на Chromium), како и во мобилните апликации што работат Android и iOS.

И покрај сите свои несомнени предности, WebRTC има неколку значајни недостатоци.

Тешкотии на избор

Технологијата WebRTC е многу посложена во однос на мрежните интеракции поради фактот што се работи за P2P. Тешко е да се дебагира, тестира и може да се однесува непредвидливо. Во исто време, треба да ги надминеме NAT и заштитен ѕид, треба да обезбедиме работа во мрежи каде што UDP е блокиран.

Имплементацијата на Google WebRTC е многу тешка за користење. Постои дури и цела компанија која обезбедува услуги за склопување на SDK. Плус, имплементацијата на Google беше многу тешко да се интегрира со нашиот систем без повторно да се шифрира целото видео.

Сепак, долго време сакавме да им дадеме на корисниците можност да работат со полноправно видео „во живо“ и да го минимизираат заостанувањето помеѓу сликата на екранот и самите настани. Плус, имавме желба да ги користиме PTZ камерите, каде доцнењата се критични, поудобно.

Имајќи предвид дека другите имплементации против задоцнување сè уште имаат ограничена функционалност и работат значително полошо, решивме да користиме WebRTC.

Што направивме

Правилната имплементација на платформата WebRTC не е лесна задача. Секое погрешно пресметување или неточност може да доведе до доцнење во преносот на видео не само што не се намалува во споредба со другите платформи, туку дури и се зголемува.

За WebRTC да работи правилно, пред сè, неопходно е да се изврши технолошка надградба на стекот за работа со веб-видео. Тоа е она што го направивме.

Прво, имплементиравме сервер за протокол за сигнализација WebRTC преку Websocket, а исто така распоредивме и врснички сервер WebRTC во облакот базиран на webrtc.org SDK. Нејзината задача е да дистрибуира видео преноси до клиентите WebRTC во формат H.264 + Opus/G.711 без видео транскодирање.

Го избравме Websocket како сигнален протокол бидејќи веќе има висококвалитетна поддршка во сите популарни веб-прелистувачи. Поради ова, можете значително да ги намалите не само трошоците за развој, туку и да избегнете губење време и ресурси за повторено ракување со TCP и TLS во споредба со AJAX.

Факт е дека, по дифолт, WebRTC не го обезбедува сигналниот протокол неопходен за правилно конфигурирање, одржување и прекинување на видео комуникацијата во реално време помеѓу изворот и клиентските апликации.

И со цел самостојно да ја имплементираме технологијата за сигнализација, требаше да развиеме сопствен сигнален сервер со поддршка за неколку веб протоколи (Websocet, WebRTC). И со можност за безбедно управување со сесиите и известувањата во реално време, управување со видео и многу повеќе.

Ги надминавме ограничувањата на P2P со намалување на латентноста не преку P2P, туку преку UDP и контрола на протокот за да се намали латентноста. Ова е исто така вградено во WebRTC, бидејќи главната употреба се p2p разговори преку прелистувач.

Во мобилниот клиент, го имплементиравме плеерот користејќи ја webrtc.org SDK, бидејќи само тој правилно ја спроведува контролата на протокот, ги има сите познати шеми за корекција на грешка напред (FEC) и правилно го имплементира механизмот за повторно испраќање пакети за сите прелистувачи. Исто така, важно е дека webrtc.org SDK активно се развива од Google.

Кој е резултатот од спроведувањето на WebRTC?

За да гледате видео во живо од камерите, додадовме нов оптимизиран плеер базиран на WebRTC на вашата лична сметка. Обезбедува брзи брзини на вчитување на видеото и целосно го елиминира проблемот со акумулацијата на доцнењето како што се зголемува времето на гледање.

Откако ја воведовме поддршката за WebRTC во облак услугата Ivideon, можеме со целосна доверба да кажеме дека нашите клиенти сега можат да гледаат полноправно видео во живо. Сега доцнењето при емитување видео секвенци не надминува една секунда! За споредба, претходниот HLS мотор обезбеди испорака на видео со задоцнување од 5-7 секунди. Разликата во брзината на видео демонстрација е многу значајна, а корисникот ќе ја забележи веднаш откако ќе започне да работи со нашата видео услуга.

Како што очекувавме, имплементацијата на новиот плеер ја подобри респонзивноста на PTZ и гласовната комуникација со камерата.

Има само една суптилна точка на која сакаме да привлечеме внимание. Новиот WebRTC плеер моментално работи во режим на тестирање. И затоа не го овозможуваме стандардно за сите наши клиенти. Но, можете сами да го активирате со овозможување на соодветната ставка во поставките на камерата (за да го направите ова, одете на кабинет).

Карактеристики на имплементација на WebRTC во услугата Ivideon

WebRTC сè уште е експериментална технологија во моментов. Неговата поддршка сè уште не е правилно имплементирана во сите прелистувачи и кориснички уреди, а исто така не во сите камери.

Токму затоа сè уште не сме го направиле WebRTC плеерот стандарден за сите корисници.

Засега, препорачуваме користење на WebRTC само во прелистувачите на Google Chrome. Најновите верзии на Firefox и Safari исто така ја поддржуваат оваа технологија, но, за жал, сè уште е нестабилна.

Сè уште немаме имплементирано WebRTC поддршка за прелистувачи на мобилни уреди. Во моментов, ако се најавите од мобилен уред и го активирате WebRTC, овој режим нема да работи. Сепак, WebRTC е достапен во нашите мобилни апликации за Android и iOS.

И завршувајќи ја приказната за карактеристиките на имплементацијата на WebRTC во нашата услуга, да забележиме уште две суптилни точки.

Прво, технологијата е фокусирана на емитување видео во живо во реално време. Затоа, ако вашиот канал нема доволно пропусен опсег за пренос на видеото, ќе забележите падови на рамката (со HLS ќе забележите избледување на видеото и зголемена латентност, но нема да има падови на рамката), но видеото сепак ќе се емитува во реално време.

Второ, бидејќи технологијата е дизајнирана да работи специјално со видео во живо во реално време, ние не ја користиме за работа со архивирани видео податоци.

Други промени во услугата

Во моментов, Flash повеќе не е вклучен во механизмот за автоматско избирање мотор. Сè уште можете да користите таков плеер, но за да го направите ова, треба да го изберете рачно во поставките за сметката или камерата. Ова не е почит кон модата, само што според статистиката на нашата услуга, практично нема корисници кои работат со Flash. И обидувајќи се да утврдиме дали прелистувачот на корисникот го поддржува, губиме околу 2 секунди од драгоценото време.

Еве краток преглед на промените што ве очекуваат во нашиот облак систем за видео надзор и лична сметка. Останете со нас и следете ги новостите!

Извор: www.habr.com