З перших днів роботи над системою хмарного відеоспостереження ми зіткнулися з проблемою, без вирішення якої на 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
