З першых дзён працы над сістэмай хмарнага відэаназірання мы сутыкнуліся з праблемай, без рашэння якой на Ivideon можна было ставіць крыж - гэта быў наш Эверэст, узыходжанне на які адняло плойму сіл, але цяпер мы, нарэшце, уторкнулі ледасек у верхавіну кросплатформавага ребуса.
Сістэма перадачы гуку і відэа праз Інтэрнэт не павінна залежаць ад абсталявання, Web-кліентаў і падтрымліваемых імі стандартаў, а таксама карэктна працаваць пры наяўнасці Network Address Translators і файрвалаў. Карыстальнік хмарнага відэаназірання жадае атрымаць доступ да сэрвісу, нават калі ён выкарыстоўвае аналагавыя камеры, а трансляцыю жывога відэа аддае перавагу глядзець на самай сучаснай прыладзе.
Вельмі значна, што карыстач жадае глядзець відэа з мінімальнай затрымкай. Практычна адзіная магчымасць паказаць відэа з нізкай затрымкай у браўзэры - выкарыстоўваць WebRTC (web real-time communications). WebRTC уяўляе сабой набор тэхналогій для peer-to-peer перадачы відэа і гуку ў браўзэрах, першапачаткова разлічаны на перадачу і прайграванне відэаструменю з нізкай затрымкай. Для гэтага, апроч іншага, выкарыстоўваецца пратакол UDP.
Перш, чым расказаць вам, што дае карыстачу новы рухавічок, мы нагадаем, навошта і чаму падтрымліваем HLS-тэхналогіі, і дзеля чаго вырашылі рухацца далей.
Рухавічок HLS: плюсы і мінусы
()
Тэхналогія HLS (HTTP Live Streaming) распрацавана ў Apple, таму не дзіўна, што ўпершыню яе падтрымка з'явілася на прыладах менавіта гэтага брэнда. На сённяшні дзень відэашэраг у фармаце HLS таксама ўмеюць прайграваць практычна ўсе тэлевізійныя прыстаўкі і шматлікія прылады, якія працуюць на АС Android.
Рухавічок HLS выкарыстоўвае для струменевай перадачы відэададзеных добра ўсім знаёмы відэакодэк H264 у спалучэнні з AAC- або MP3-аўдыёструменю. Увесь струмень аўдыё- і відэададзеных пакуецца ў транспартны кантэйнер MPEG-TS. Для перадачы па пратаколе HTTP інфармацыя, якая змяшчаецца ў струмені, падзяляецца на фрагменты, апісаныя ў m3u8-плэйлістах. І толькі затым гэтыя фрагменты разам з плэйлістамі перадаюцца па HTTP. Дзяленне на фрагменты аўтаматычна азначае затрымку ў секундах. Такая асаблівасць кантэйнера MPEG-TS.
Рухавічок HLS таксама падтрымлівае мультыбітрэйтныя струмені, Live/VOD.
Асноўныя добрыя якасці HLS:
- убудаваная падтрымка ва ўсіх асноўных браўзэрах;
- прастата рэалізацыі (калі параўноўваць з WebRTC);
- вельмі зручна і эфектыўна арганізоўваць усякія трансляцыі на вялікую аўдыторыю дзякуючы таму, што можна сегменты адзін раз загружаць на CDN.
Пры ўсёй прастаце рухавічка з ім не ўсё так гладка, як здаецца. Асноўная праблема ў тым, што распрацоўшчыкі іншых плэераў адышлі ад рэкамендацый Apple, напрыклад у плане падтрымліваемых аўдыёфарматаў. У прыватнасці, шматлікія распрацоўнікі сталі дадаваць магчымасць працы з папулярнымі аўдыёструменю: mpeg2 video, mpeg2 audio і т. п. У выніку прыйшлося ствараць розныя фарматы плэйлістоў для розных плэераў.
Але адной з самых вялікіх праблем рухавічка HLS з'яўляецца высокая затрымка ў перадачы даных.
Вытокі тармазоў
Галоўная прычына высокай затрымкі ў HLS крыецца ў тым, што праграмісты стваралі рухавічок для атрымання максімальна якаснай карцінкі. Таму параметры выкарыстоўванага інтэрвалу кадраў і аб'ём буфера прайгравання проста не падыходзяць для вядзення прамых відэатрансляцый. З-за гэтага ўзнікае дастаткова высокая затрымка ў перадачы відэашэрагу, якая можа складаць 5-7 секунд.
З аднаго боку, гэта няшмат, напрыклад, для тых, хто глядзіць фільм з сервера відэахостынгу. Але для сістэм відэаназірання затрымка ў перадачы відэашэрагу можа мець вельмі вялікае значэнне.
Калі вы назіраеце за офісам, дзе супрацоўнікі адрываюцца раз у гадзіну ад манітораў, то затрымка 5 секунд ніякага значэння не мае. Але людзі пачалі скардзіцца, што, да прыкладу, пры трансляцыі футбольнага матча, у чаце ўжо напісалі ГООООЛ, а на відэа гэтага яшчэ няма :). У нас ужо ёсць шэраг карыстацкіх кейсаў, дзе Ivideon павінен практычна замяніць skype.
Ці можна перамагчы затрымку ў HLS? Адказ на гэтае пытанне гучыць як выступленне вопытнага знішчальніка пацукоў на лекцыі перад пачынаючымі дэратызатарамі: "Пацукоў вынішчыць нельга, але іх пагалоўе можна звесці да разумнага мінімуму". Так і з затрымкай у HLS, прыбраць яе да нуля не атрымаецца, але на рынку ёсць рашэнні, якія дазваляюць істотна паменшыць затрымку.
Дробная нарэзка
Яшчэ адным мінусам рухавічка з'яўляецца выкарыстанне невялікіх па памеры файлаў для перадачы дадзеных. Здавалася б, што ў гэтым дрэннага?
Любы, хто спрабаваў капіяваць вялікую колькасць маленькіх файлаў з аднаго носьбіта на іншы, напэўна заўважаў, што хуткасць запісу падобнага набору значна ніжэй, чым аднаго вялікага файла такога ж аб'ёму. Ды і інтэнсіўнасць зваротаў да цвёрдай кружэлкі істотна павялічваецца, што ў цэлым адмоўна адбіваецца на прадукцыйнасці ўсяго кампутара. Таму перадача відэададзеных у выглядзе невялікіх 10 секундных фрагментаў таксама ўносіць свой фундуш у падвышаную затрымку рухавічка.
Коратка падсумуем усе плюсы і мінусы HLS-тэхналогіі.
Добрыя якасці HLS:
- Магчымасць працы з любымі прыладамі. Вы можаце глядзець відэа на любым сучасным прыладзе, няхай гэта будзе смартфон, планшэт, ноўтбук або настольны ПК. Галоўнае, каб вэб-браўзэр быў сучаснай версіі і сумяшчальны з HTML5 і Media Source Extensions.
- Выдатная якасць выявы. Выкарыстоўваная функцыя адаптыўнай перадачы дадзеных дазваляе дынамічна змяняць якасць перадаецца відэашэрагу ў залежнасці ад паласы прапускання інтэрнэт-злучэння, пры гэтым алгарытм імкнецца захаваць якасць максімальным.
- Няма неабходнасці ў складанай наладзе абсталявання карыстальніка.
Недахопы:
- Абмежаваная падтрымка працы з рухавіком на некаторых прыладах.
- Высокія затрымкі ў перадачы выявы.
- Моцнае павелічэнне накладных выдаткаў і складанасць аптымізацыі з-за выкарыстанні файлаў невялікага памеру. З-за асаблівасцяў кантэйнера мы ніколі не зможам атрымаць затрымку менш, чым памер сегмента.
Недахопы HLS пераважылі для нас яго добрыя якасці і прымусілі шукаць альтэрнатыўныя варыянты.
Што такое WebRTC
()
Платформа WebRTC была распрацавана Google у 2011 годзе для перадачы струменевых відэа-і аўдыёдадзеных паміж браўзэрамі і мабільнымі праграмамі з мінімальнай затрымкай. Для гэтага выкарыстоўваецца стандартны пратакол UDP і спецыяльныя алгарытмы кіравання патокам. Сёння гэта праект з адчыненым зыходным кодам, ён актыўна падтрымліваецца Google і развіваецца.
WebRTC – гэта набор тэхналогій для peer-to-peer перадачы відэа і гуку. Гэта значыць, да прыкладу, браўзэры карыстачоў з дапамогай WebRTC могуць перадаваць дадзеныя адзін аднаму напроста, без выкарыстання выдаленых сервераў для захоўвання і апрацоўкі дадзеных. Уся інфармацыя таксама апрацоўваецца браўзэрамі і мабільнымі праграмамі канчатковых карыстальнікаў.
Выгода і вялікія магчымасці дадзенай тэхналогіі па добрай якасці ацанілі распрацоўшчыкі ўсіх папулярных браўзэраў. Сёння падтрымка WebRTC рэалізавана ў Mozilla Firefox, Opera, Google Chrome (і ўсімі браўзэрамі на базе Chromium), а таксама ў мабільных дадатках пад Android і iOS.
Пры ўсіх сваіх несумнеўных добрых якасцях, WebRTC мае некалькі істотных мінусаў.
Цяжкасці выбару
Тэхналогія WebRTC значна больш складана ўладкована ў плане сеткавых узаемадзеянняў з-за таго, што яна пра P2P. Яе складана адладжваць, тэставаць, яна можа паводзіць сябе непрадказальна. Пры гэтым нам трэба пераадольваць NAT і firewall, трэба забяспечваць працу ў сетках, дзе заблакаваны UDP.
Рэалізацыю WebRTC ад Google вельмі складана выкарыстоўваць. Ёсць нават цэлая кампанія, якая падае паслугі па зборцы SDK. Плюс рэалізацыю ад Google было вельмі складана інтэграваць з нашай сістэмай так, каб пры гэтым не перакадзіраваць усё відэа.
Аднак мы даўно жадалі даць карыстачам магчымасць працаваць з паўнавартасным «жывым» відэашэрагам і мінімізаваць адставанне малюнка на экране ад саміх падзей. Плюс да гэтага, у нас было жаданне зрабіць больш камфортным выкарыстанне PTZ-камер, дзе затрымкі маюць крытычнае значэнне.
Улічваючы, што іншыя рэалізацыі дужання з лагамі пакуль маюць абмежаваную функцыянальнасць і працуюць прыкметна горш, мы вырашылі выкарыстаць WebRTC.
Што мы зрабілі
Пісьменна ўкараніць платформу WebRTC – нялёгкая задача. Любы пралік ці недакладнасць могуць прывесці да таго, што затрымкі ў перадачы відэашэрагу не толькі не памяншацца ў параўнанні з іншымі платформамі, але і ўзрастуць.
Для карэктнай працы WebRTC, у першую чаргу, неабходна правесці тэхналагічную мадэрнізацыю стэка для працы з вэб-відэа. Што мы і зрабілі.
Спачатку рэалізавалі сервер сігнальнага пратакола WebRTC па-над Websocket, а таксама разгарнулі WebRTC peer-сервер у воблаку на аснове SDK webrtc.org. У яго задачу ўваходзіць раздача відэаструменяў кліенцкім WebRTC peer-ам у фармаце H.264 + Opus/G.711 без перакадавання відэа.
Мы выбралі Websocket у якасці сігнальнага пратакола таму, што ён ужо мае якасную падтрымку ва ўсіх папулярных вэб-браўзэрах. За рахунак гэтага можна істотна зменшыць не толькі накладныя выдаткі на распрацоўку, але і не марнаваць час і рэсурсы на паўторныя TCP і TLS handshake у параўнанні з AJAX.
Справа ў тым, што па змаўчанні WebRTC не падае сігнальны пратакол, неабходны для правільнай налады, падтрымкі і разрыву відэасувязі ў рэальным часе паміж зыходным і кліенцкім прыкладаннямі.
І каб самастойна рэалізаваць тэхналогію сігналізацыі нам было неабходна распрацаваць свой сігнальны сервер з падтрымкай некалькіх вэб-пратаколаў (Websocet, WebRTC). А таксама з магчымасцю бяспечнага кіравання сеансамі і апавяшчэннямі ў рэжыме рэальнага часу, кіраваннем відэа і многімі іншымі параметрамі.
Абмежаванні P2P мы пераадолелі, паменшыўшы затрымку не за рахунак P2P, а за рахунак UDP і кіраванні струменем, накіраванага на памяншэнне затрымкі. Гэта таксама закладзена ў WebRTC, бо асноўны use-case – p2p размовы праз браўзэр.
У мабільным кліенце мы рэалізавалі плэер з выкарыстаннем SDK webrtc.org, паколькі толькі ў ім правільна рэалізавана кіраванне патокам, ёсць усе вядомыя схемы Forward Error Correction (FEC), правільна рэалізаваны механізм паўторнай адпраўкі пакетаў для ўсіх браўзэраў. Немалаважны і той факт, што SDK webrtc.org актыўна развіваецца Google.
Які вынік ад укаранення WebRTC?
Для прагляду жывога відэа з камер мы дадалі ў асабісты кабінет новы аптымізаваны плэер на аснове WebRTC. Ён забяспечвае высокую хуткасць загрузкі відэашэрагу і цалкам ухіляе праблему назапашвання затрымкі па меры павелічэння часу прагляду.
Пасля ўкаранення падтрымкі WebRTC у хмарным сэрвісе Ivideon мы можам з поўнай упэўненасцю сказаць, што зараз нашым кліентам даступны прагляд паўнавартаснага жывога відэа. Цяпер затрымка пры трансляцыі відэашэрагу не перавышае адной секунды! Для параўнання, ранейшы HLS-рухавічок забяспечваў дастаўку відэа з затрымкай 5-7 секунд. Розніца ў хуткасці дэманстрацыі відэа вельмі значная, і карыстач яе заўважыць адразу пасля пачатку працы з нашым відэасэрвісам.
Як мы і меркавалі, рэалізацыя новага плэера дазволіла павысіць спагадлівасць PTZ і галасавой сувязі з камерай.
Ёсць толькі адзін тонкі момант, на які мы жадаем звярнуць увагу. Новы WebRTC-плэер пакуль працуе ў тэставым рэжыме. І менавіта таму мы не падключаем яго ўсім нашым кліентам па змаўчанні. Але вы можаце яго актываваць самастойна, улучыўшы адпаведны пункт у наладах камеры (для гэтага трэба зайсці ў ).
Асаблівасці рэалізацыі WebRTC у сэрвісе Ivideon
WebRTC на дадзены момант усё яшчэ эксперыментальная тэхналогія. Яе падтрымка пакуль карэктна рэалізавана не ва ўсіх браўзэрах і карыстацкіх прыладах, а таксама не ва ўсіх камерах.
Менавіта гэтым і тлумачыцца той факт, што мы пакуль не зрабілі WebRTC-плэер асноўным па змаўчанні для ўсіх карыстачоў.
Пакуль мы рэкамендуем выкарыстоўваць WebRTC толькі ў браўзэрах Google Chrome. Апошнія версіі Firefox і Safari таксама падтрымліваюць гэтую тэхналогію, але, нажаль, яшчэ нестабільна.
Мы пакуль не ўкаранілі падтрымку WebRTC для браўзэраў на мабільных прыладах. Цяпер, калі вы ўвойдзеце з мабільнай прылады і актывуеце WebRTC, гэты рэжым працаваць не будзе. Зрэшты, WebRTC ёсць у нашых мабільных прыкладаннях для и .
І завяршаючы аповяд аб асаблівасцях рэалізацыі WebRTC у нашым сэрвісе, адзначым яшчэ два тонкіх моманту.
Па-першае, тэхналогія арыентавана на трансляцыю менавіта жывога відэа ў рэальным часе. Таму, калі прапускной здольнасці вашага канала будзе нядосыць для перадачы відэашэрагу, вы заўважыце выпадзенне кадраў (з HLS вы заўважыце заміранні відэа і павелічэнне затрымкі, пры гэтым кадры выпадаць не будуць), але відэа ўсё роўна будзе транслявацца ў рэальным часе.
Па-другое, паколькі тэхналогія прызначаная для працы менавіта з жывым відэа ў рэальным часе, мы яе не выкарыстоўваем для працы з архіўнымі відэададзенымі.
Іншыя змены ў сэрвісе
У дадзены момант Flash больш не ўдзельнічае ў механізме аўтаматычнага выбару рухавічка. Скарыстацца такім плэерам усё яшчэ можна, але для гэтага трэба яго абраць уручную ў наладах акаўнта ці камеры. Гэта не даніна модзе, проста па статыстыцы нашага сэрвісу карыстальнікаў, якія працуюць з Flash, практычна не засталося. А на спробу вызначыць, ці падтрымлівае яго браўзэр карыстальніка, мы губляем каля 2 секунд каштоўнага часу.
Вось коратка пра тыя змены, якія вас чакаюць у нашай хмарнай сістэме відэаназірання і асабістым кабінеце. Заставайцеся з намі і сачыце за навінамі!
Крыніца: habr.com
