Русский
Русский
English
Статистика
Реклама

Video streaming

Самый простой (для знающих Linux) и дешевый способ разместить IP-камеру на сайте для небольшой аудитории

07.03.2021 12:13:35 | Автор: admin

В чем главная проблема современных недорогих IP-камер? Вы не можете просто так добавить их на свой сайт! Они выдают видео совсем не в том формате, который понимают браузеры. Да, конечно, можно зайти напрямую на камеру (и часто только с IE), и у многих моделей есть облако. Но проблема остается я не могу просто так взять и поместить камеру на сайт, как например, простую картинку!

Я рассмотрел множество решений для организации трансляций с IP-камер от разных поставщиков, в том числе и OpenSource решения. У большинства один недостаток, очень критичный для меня: система постоянно захватывает поток с камеры, даже если нет зрителей.

В моем случае нужно было вывести картинку на сайт с удаленных камер, подключенных по 4G каналу в глухом районе. Скорость на отдачу не поднималась выше 10 Мбит/с в лучшие времена, но обычно она была 2-3 Мбит/с. Трафик хоть и неограничен, но провайдер неофициально предупредил, что расход выше 200 ГБ трафика непременно скажется негативным образом, такой вот условный безлимит. Предполагаю, просто порежут скорость.

Некоторые решения, найденные на просторах GitHub, практически подходили, но не обладали хорошей документацией или казались просто сложными и громоздкими.

А была мне нужна система онлайн-трансляций с такими свойствами:

  1. не расходующая трафик в отсутствие зрителей;

  2. среднедневное одновременное число зрителей 1-3 человека;

  3. поддержка если не всех, то большинства популярных интернет-браузеров, в том числе мобильных;

  4. максимально простая и понятная;

  5. недорогая;

  6. желательно OpenSource.

Имея богатый опыт работы с программой FFMpeg, весь этот функционал я решил попробовать реализовать самостоятельно. В конце концов, чем плох велосипед, сделанный своими руками, если есть желание и время?

Но тут вы наверняка скажете зачем на свой сайт, ведь есть iVideon? и будете правы. Действительно, этот сервис практически не потребляет трафик, когда трансляция неактивна, очень простой в развертывании и вообще классный. А еще весьма дорогой, когда камер много и много зрителей, которым нужно передать права (никаких публичных ссылок). И забавно, зрителю тоже нужно оплачивать подключение каждой новой камеры сверх лимита (во всяком случае, год назад было именно так). Постепенно условия сервиса менялись, и вот теперь на бесплатном аккаунте можно разместить лишь одну камеру, и передать права лишь одному пользователю. И это уже не говоря о том, что в идеале потребуются камеры или видеорегистраторы с iVideon-овской прошивкой.

По моим наблюдениям, оказалось, что такие браузеры, как Google Chrome и Mozilla Firefox, спокойно воспроизводят правильно подготовленный H.264-поток с камеры. Под правильной подготовкой имеется ввиду переупаковка потока программой FFMpeg со следующими параметрами:

-movflags +frag_keyframe+separate_moof+omit_tfhd_offset+empty_moov

Эти опции подсказывают FFMpeg, что на выходе мы хотим получить фрагментированный MP4-файл с наличием атома moov в начале файла и последовательность атомов moof с интервалом в один ключевой кадр.

Из прочих параметров я задавал еще такие:

-c copy для копирования потока без перекодировки;

-an без аудио (почему-то всё ломается, если камера не передает аудиопоток, а таких камер много);

-t лимит для ограничения времени одного сеанса (конкретно у меня трафик ограничен, экономим на всём);

-rtsp_transport tcp проще тем, что не требуется пробрасывать RTP-порты, если камера находится за NAT (поддерживается практически всеми камерами);

-probesize 32 эта команда ускоряет воспроизведение видео;

-stimeout 5000000 тайм-аут чтения потока (5 секунд).

Хорошо, а причем тогда здесь PHP? А нужен он вот зачем. Посылаем необходимые заголовки:

header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");

header("Cache-Control: post-check=0, pre-check=0", false);

header("Pragma: no-cache");

header('Accept-Ranges:bytes');

header('Connection:keep-alive');

header('Content-type: video/mp4');

И средствами PHP запускаем FFMpeg с перенаправлением потока напрямую в браузер зрителя:

passthru("ffmpeg <параметры кодирования и ссылка на поток> -f mp4 pipe:");

И все было бы отлично, но видео грузится несколько секунд, и не воспроизводится в Safari на Mac и iOS. То ли особенность реализации кодека там такая, то ли просто фрагментированные MP4 толком не поддерживаются, не знаю перепробовал все варианты. Еще заметил, что видео начинает моргать в браузере Google Chrome, если не обождать пару секунд перед стартом воспроизведения.

Самый простой способ решения проблемы, который пришел мне в голову а почему бы не пустить сначала перекодированный в MJPEG поток, а после, когда прогрузится основной MP4, сделать замену? У этого формата масса плюсов простой, поддерживается наверно вообще всеми браузерами, очень нетребователен к ресурсам сервера, но очень прожорлив в плане размера выходного файла, и как следствие, расходуемого трафика. Поэтому по максимуму урежем качество картинки, лишь бы работало.

И знаете, получилось весьма сносно. Я доработал первоначальный скрипт, и теперь он:

  1. умеет выводить видео и в других форматах: OGV и WEBM;

  2. умеет выдавать по запросу статичную картинку (снимок);

  3. если видит, что вкладка с ранее открытым видео была в фоне при запуске браузера, то переадресует на указанный вами сайт (например, каталог камер), таким образом, экономя ресурсы;

  4. не стопорится в Яндекс-браузере на Mac. Там кодек тоже как-то хитро работает до второго ключевого кадра воспроизводит, а потом всё. Для него пришлось делать дополнительную проверку, вдруг видео сломалось. Safari поступает более мудро просто не воспроизводит и всё.

Кажется, получилось уже много текста, поэтому перейдем к самому интересному как его установить на свой сервер. Установка скрипта проста:

  1. берете сервер, например, с Debian, ставите Apache+PHP7 и FFMpeg;

  2. получаете SSL-сертификат для своего сервера;

  3. копируете файлы моего скрипта в любую доступную по www папку;

  4. открываете camera.php и указываете свой ключ (придумываете; допустима латиница и цифры) в переменной $key, а в $redirectToIfBackground указываете, куда переадресовывать из фоновых вкладок;

  5. размещаете на страницах своего сайта трансляций ссылки на camera.php в таком формате: camera.php?a=<rtsp-ссылка в base64>&b=<ключ>&c=<rtsp-ссылка на второй поток в base64>. При этом параметр c необязательный, но очень желательный.

Риску предположить, что на шаге 4 у вас могут возникнуть затруднения. Но здесь нет ничего сложного, можно взять любой онлайн base64 конвертер, например http://base64.ru/, и сконвертировать вашу ссылку на RTSP-поток.

И вроде бы на этом всё, но без одной маленькой детали рассказ был бы неполным. Если вы планируете сайт с камерами сделать на MODX Revolution, то используйте приложенный плагин, упрощающий работу по размещению ссылок. Инструкция по установке плагинов есть в документации к этой CMS. После установки плагина откройте его на редактирование и в начале файла подставьте свои значения в $key и $camera_server_url (иными словами замените текст, выделенный заглавными буквами, своим ключом и адресом сервера).

После его установки, в тексте ваших страниц ссылки на камеры теперь можно указывать в таком виде:

{camera*НАЗВАНИЕ*RTSP-ССЛКА*RTSP-ССЛКА НА ВТОРОЙ ПОТОК}

Название и RTSP-ссылки подставляете свои. Если нет ссылки на второй поток, то дублируете ссылку основного потока. Если есть затруднения с поиском RTSP-ссылок на вашу камеру, то можно использовать программу Onvif Device Manager. Она покажет ссылку снизу слева, по клику на Живое видео.

По поводу безопасности. В принципе, если сервис будет непубличным, для чего и задумывался скрипт, то всё нормально. В противном случае, любой кто подсмотрит ссылку на camera.php, может вытащить исходную RTSP-ссылку, пароль на камеру (он прописывается в RTSP-ссылке), и сам секретный ключ $key. Пароль на камеру дает доступ к её админке, если вы пренебрегли созданием отдельной учетной записи на этой камере специально для RTSP. Секретный же ключ даст возможность через ваш сервер крутить сторонние камеры. Поэтому, данный скрипт только для частного доступа. Я мог бы реализовать шифрование параметров, но при размещении в публичный доступ ввиду отсутствия кэширования видеоряда интернет-канал быстро забьется, как и ресурсы на сервере.

Кстати, лично у меня все камеры посредством VPN (я люблю Wireguard) связаны в одну сеть, все ссылки я прописываю с серыми IP. Удобно, безопасно, радует.

Мой код публикуется под лицензией MIT.

В проекте используется библиотека ifvisible.js, разработанная Serkan Yeren, лицензия MIT.

Скачать, 14 кБ

Зеркало

Подробнее..

Как мы прошли путь от разработки прошивок для каждой камеры до создания универсального SDK для вендоров камер

05.11.2020 16:06:36 | Автор: admin

Привет, меня зовут Олег Герасимов, я директор центра компетенций IT-кластера Ростелекома. Наша команда среди многих задач разрабатывает прошивки камер видеонаблюдения для B2B и B2C-сервисов. В предыдущей статье я рассказывал, как мы научились самостоятельно разрабатывать софт и прошивки для IP-камер, в том числе и недорогих, и подключать их к облаку.


За прошедшее время камеры с нашей прошивкой уже появились на рынке, и, судя по данным Яндекс.Маркета, на полках магазинов цены на них начинаются от 1500 рублей. И это уже не дешевый ноунэйм, а качественные камеры ведущих мировых брендов: Hikvision, Dahua и Uniview. На мой взгляд, это отличный результат!



Когда мы начинали работать с прошивками, количество поддерживаемых моделей камер было небольшим. В процессе разработки общих компонентов мы самостоятельно реализовывали поддержку новых моделей камер.


Тогда у нас была возможность самим выбирать, какие модели интегрировать в первую очередь, а какие нет, исходя из технических соображений.


Например, если в камере используется сенсор, под который в SDK процессора нет драйвера, то драйвер сенсора придется разработать самим. Это очень трудоемкий процесс, требующий сложной разработки и отладки. Сенсор технически сложный компонент, и на одно изучение технического описания (Datasheet) сенсора могут уйти недели. Это, на секундочку, сотни страниц с описанием тысяч регистров, влияющих на работу сенсора, и логики взаимодействия с ними.


Первое время мы обходили стороной камеры с незнакомыми сенсорами, чтобы не застрять в деталях настройки конкретного железа, а сосредоточиться на разработке общих компонентов, которые будут использоваться в большинстве камер. Иногда нам удавалось найти уже готовые драйверы сенсора в оригинальной прошивке камеры, но это было скорее счастливым исключением из правил. Работая в таком режиме, мы поддержали около десятка моделей камер на нескольких наиболее популярных чипсетах, делая упор не на количество моделей, а на функциональность.


Следующий этап разработки прошивок для камер совпал с объявлением тендера на закупку камер. Это уже серьезное событие. Ростелеком закупал сотни тысяч камер на открытом тендере, в который могли войти любые вендоры камер, соответствующих по своим ТТХ продуктовым и техническим требованиям.


Одно из ключевых требований к поставщикам предоставление технической информации о схемотехнике камер, например, о GPIO-выводах, к которым подключены светодиоды, кнопки, ИК фильтры и т.д. Кроме этой информации, мы просили вендоров предоставить специфичные для оборудования патчи ядра/загрузчика и исходные тексты драйверов устройств, в первую очередь, сенсоров и WI-FI чипов.



Такой подход существенно облегчил нашу задачу по поддержке новых камер. Вместо данных, добытых реверс-инжинирингом, у нас появились официальные спецификации и исходники драйверов от вендоров.


Однако по-прежнему много времени уходило на подготовку прошивок, даже когда вендоры стали делиться информацией: данные в спецификациях были неточными, драйверы не хотели заводиться на железе, а то и вовсе отказывались собираться.


Самостоятельно найти ошибку в спецификациях или драйверах получалось не всегда, да и искать ошибки в стороннем коде небыстрое занятие. Поэтому чаще для решения проблемы приходилось обращаться к вендорам. Как правило разработчики, которые могут ответить на вопросы о схемотехнике, найти
и поправить ошибки в драйверах, находятся в Китае. А это сразу замедляет коммуникацию одна итерация вопрос-ответ может занимать несколько дней, а исправление ошибок и того дольше.
Пока поток новых камер был небольшим такой режим устраивал, но со временем запросы от маркетологов выросли. Возникла потребность в интеграции большего количества линеек: уличные камеры с Wi-Fi, домашние с PTZ, с сиреной и т.д. Но с другой стороны, по мере развития облачного видеонаблюдения увеличивалось количество вендоров, желающих работать с нами.


В этот момент мы поняли, что силами команды с возросшим в разы количеством новых камер уже не справиться. Всё время разработки
будет занимать исключительно интеграция новых камер, а на разработку новых фич и улучшения времени не останется. Нужно было найти новый подход.



Мы начали анализировать узкие места процесса. Они оказались на поверхности: больше всего времени уходило на итерации получения патчей и драйверов, багрепорты в сторону вендоров и ожидание исправлений.


Логичная мысль: дать вендорам возможность самим собирать нашу прошивку с драйверами их оборудования и конфигурациями, проверять результаты и отлаживать работу у себя, не тратя драгоценное время на переписку.


Техническое решение, с одной стороны, очевидное: сделать SDK для сборки нашей прошивки. Но есть ряд требований:


  • SDK должен уметь собирать прошивки под все типы поддерживаемых SoC. На сегодня это больше 10 чипсетов от Hisilicon, Ambarella, MStar и Fullhan.
  • Нельзя передавать компоненты прошивок от одного вендора другим, потому что это интеллектуальная собственность. Мы подписываем NDA, в котором обязуемся не раскрывать передаваемую информацию.
  • Результаты интеграции, полученные от вендора, нужно уметь замерджить в общее дерево исходников прошивки в нашем Git.
  • У вендора должна быть возможность вносить патчи и дополнения во все компоненты: ядро, загрузчик, SoC SDK и прочие.
  • Нужно иметь гибкую структуру настроек, в которой будут учитываться максимальное количество возможных конфигураций оборудования.
  • Для каждой пары вендор-SoC должна собираться универсальная прошивка, поддерживающая все камеры вендора на базе этого процессора.
  • Сборка должна работать автономно и не требовать доступа в Интернет. Да, большинство разработчиков ПО для камер в Китае не имеют доступа в Интернет на рабочих местах.


Структура системы сборки, в тот момент, была не готова к такому подходу. Например, в некоторых файлах конфигурации были совмещены настройки камер от нескольких вендоров, а для сборки прошивки и загрузки пакетов требовался доступ к нашим внутренним репозиториям. Да и некоторые места системы сборки (чего греха таить) не предполагали такого масштабирования: их разработали в то время, когда поддерживался один тип процессора и две модели камеры...


Другая проблема: под каждый процессор поставляется отдельный SDK от его производителя, с уникальным набором системных компонентов: своя версия и набор патчей ядра, toolchain, uboot, системная библиотека (где-то uclibc, а может быть glibc). Под эти факторы приходится подстраивать систему сборки, а местами и код приложений. Для наглядности масштабов фрагментации вот табличка со списком версий компонентов:


Процессор Версия Linux Версия gcc
Hisilicon 3516a/d 3.4.y gcc 4.9
Hisilicon 3518ev100 3.0.y gcc 4.4
Hisilicon 3518ev200 3.4.y gcc 4.9
Hisilicon 3516cv300 3.18.y gcc 4.9
Hisilicon 3518ev300/3516ev200/ev300 4.9.y gcc 6.3
Hisilicon 3516cv500/dv300 4.9.y gcc 6.3
mStar i3 3.18 gcc 4.8
mStar i6 4.9 gcc 8.2
Ambarella s2l 3.10 gcc 4.9
Ambarella s3l 3.10 gcc 5.2
Fullhan fh8632 3.0.y gcc 4.3

Как видно, разброс огромный: от легаси десятилетней давности до относительно свежих ревизий.


С такими вводными нам предстоял рефакторинг системы сборки прошивок: выделить общие патчи и драйвера, которые будут доступны для всех вендоров, повторить это для 10+ поддерживаемых моделей SoC, полностью переосмыслить систему конфигурации наших компонентов. Заодно выпилить специфичные для камер костыли из init-скриптов, сделав общие и универсальные решения.


В результате мы пришли к структуре, в которой все специфичные для конкретных моделей настройки/конфигурации/makefile/патчи собраны в папках, структурированную по иерархии "Вендор SoC Модель камеры". Такая иерархия позволила автоматизировать сборку SDK с разделением сборок по вендорам. Вот пример, драйверы и конфигурации для камер от выдуманного вендора Megatech на чипсете Hisilicon.


Структура каталогов

Драйверы


drivers + megatech/             -> драйвера и конфиги для вендора 'megatech'| + hi3518ev200/        -> чипсет hisilicon hi3518ev200| | + 1421              -> конфигурации модели камеры с кодом оборудования 1421| | | | + ipcdb.1421.yml -> общая конфигурация| | | | + mpi/entry.1421.yml -> конфигурация видеозахвата| | | | + ptz/entry.1421.yml -> конфигурация PTZ| | + motor             -> драйверы моторов управления PTZ| | | + bu24036_motor   -> драйвер шагового мотора на чипе bu24036| | | | gpio_motor      -> драйвер шагового мотора управляемый GPIO выводами| | + wlan              -> драйверы wi-fi чипов | | | + Makefile        -> скрипт сборки | | + sensor            -> драйверы сенсоров| | | + Makefile        -> скрипт сборки 

Патчи ядра


kernel+ megatech/| + hi3518ev200/| | + mmc_hotplug.patch| | + kernel-config.patch

Патчи uboot


uboot+ megatech/| + hi3518ev200/| | + uboot-mmc.patch| | + uboot-spi.patch

Все файлы конфигурации камер перевели в формат YAML, как самый удобный для ручного редактирования, и разделили по компонентам:


  • Настройки оборудования модели камеры (GPIO, наличие и тип Wi-Fi, сенсора, флаги наличия микрофонов, динамиков, дополнительные скрипты инициализации).

Пример yaml
1421:  vendor: megatech  model: Model A  soc: 3518ev2  ethernet: 0  wlan: rtl8188eu  sensor: ov9732  leds:                ir:                  gpio: 23      inverse: true    red:                 gpio: 10    power:      gpio: 10         green:      gpio: 2    net:      gpio: 2  keys:    wps:      gpio: 16    reset:      gpio: 16  peri-out:    pwdn:      gpio: 1      inverse: true    ircut.p:      gpio: 57    ircut.n:      gpio: 60    wifi_pwr:      gpio: 7  flash: spi  misc:    microphone: true    speaker: true    mic_hpf_level: 3    mic_anr_level: 4  scripts:    insert-sns:      - himm 0x200f0040 0x2; # I2C0_SCL      - himm 0x2003002c 0xc4001; # sensor unreset, clk 24MHz, VI 99MHz    init-wlan:      - insmod 8188eu.ko

  • Настройки видеоприложения для конкретной модели (тип сенсора, поддерживаемые разрешения, режимы синхронизации и видеозахвата, подстройки алгоритмов).

Пример yaml
1421:  sensor:    type: ov9732    lib: libsns_ov9732.so  resolutions:    - targets:         - { width: 1280, height: 720, maxrate: 30 }        - { width: 640, height: 480, maxrate: 30 }        - { width: 640, height: 360, maxrate: 30 }        - { width: 320, height: 240, maxrate: 30 }      channels:        - main      source: { width: 1280, height: 720, rates: [30, 25] }  combo_dev_attr:    input_mode: CMOS_33V  vi_dev_attr:    interface_mode: DIGITAL_CAMERA    component_mask: [67043328, 0]    syn_cfg:      vsync: field      vsync_neg: high      hsync: valid_signal      hsync_neg: high      vsync_valid: valid_signal      vsync_valid_neg: high      timing_blank: [ 370, 1280, 0, 6, 720, 6, 0, 0, 0 ]  isp_image_attr:    bayer_format: BGGR

  • Настройки PTZ (тип чипа, тайминги работы шаговых драйверов).

Пример yaml
1421:  type: pan_controller_and_tilt_gpio_generic  interrupt_gpio: 50  absolute: true  pan:    park_ccw: false    continuous: [-20, 20]    relative: [-7.9, 7.9]    absolute: [0, 355]    channel: 0    min_wait: 100    max_step: 140    max_speed: 375    unity: 430  tilt:    park_ccw: true    continuous: [-20, 20]    relative: [-3.5, 3.5]    absolute: [0, 90]    max_step: 2000    unity: 157

Выбор способа сборки дистрибуции SDK был очевидным. Docker оказался вне конкуренции, с его помощью можно легко передать подготовленную среду.
Мы использовали Docker практически с самого начала разработки, как в CI, так и для локальной отладки на компьютерах разработчиков.


Процесс сборки полностью автоматизирован. Docker-образы с нашим SDK собираются в общем CI под матрицу сочетаний SoC-вендор.


Исходно у нас было два основных репозитория:


  • build-tools в нем хранятся Dockerfile, скрипты установки SoC SDK и скрипты сборки общих библиотек для поддерживаемых аппаратных платформ. В CI этого репозитория собираются Docker-образы со всем необходимым для сборки прошивки и софта под целевую платформу.
  • vc-firmware здесь хранится система сборки прошивки и компонент. К этому же репозиторию как git-submodule подключены репозитории с исходниками наших компонентов: видеоприложение, облачный агент, модуль обновления). Результатом работы CI в этом репозитории являются сами прошивки камер.

Для нового SDK добавили еще один репозиторий, vc-sdk, к которому подключили vc-firmware и build-tools как git-submodule. В CI этого репозитория сборка разделена на этапы:


  • подготовка базового Docker-образа по аналогии с репозиторием build-tools;
  • сборка пакетов с компонентами (видеоприложение, облачный агент, модуль обновления);
  • загрузка пакетов с общими компонентами (публичные библиотеки, драйверы Wi-Fi и т.д.)
  • копирование каталогов с драйверами и патчами, специфичными для вендора


В результате работы CI получается автономный Docker-образ, рассчитанный на сборку прошивок для камер на выбранном чипе вендором. Он загружался
в общий registry образов, из которого вендор может скачать свой образ.


Следующий объемный фронт работ разработка документации. Документацию мы писали поэтапно, собирая обратную связь от вендоров и учитывая замечания. Кстати, для документации использовался наш инструмент Foliant. Про него наши ребята уже рассказывали на митапе Write the Docs Moscow (http://personeltest.ru/aways/habr.com/ru/post/431210/).


Заключение


За этот год уже 8 вендоров освоило использование нашего SDK, с его помощью добавили поддержку работы с видеонаблюдением Ростелекома в нескольких десятков новых моделей камер. Некоторые из этих камер уже продаются.


Важно, что выбранный подход разработка собственной прошивки на базе SDK работает на потребителей: интеграция камер таким способом позволила организовать честную конкуренцию при тендере на закупку камер. Победители выявляются по объективным показателям: качеству оборудования и наименьшей стоимости.


Наконец, если раньше количество поддерживаемых моделей камер было ограничено силами и ресурсами команды, то сегодня эта проблема ушла в прошлое. Теперь вендоры камер могут сами добавлять поддержку новых моделей через облако РТК.

Подробнее..

Серверный WebRTC в 2020 году обзор возможностей

26.07.2020 06:16:13 | Автор: admin
1. Кому нужен серверный WebRTC?

Как все мы знаем, WebRTC это peer-to-peer технология, реализующая канал коммуникации между двумя браузерами, для передачи аудио, видео и любых других данных с низкой задержкой. Технология совершенно бесплатная, и если вашему приложению нужно наладить общение в браузерах для двух удаленных участников, то вы можете добавить соответствующий javascript код на веб страницы и задача решена. Браузеры будут общаться напрямую, никакого сервера не требуется.

Серверный WebRTC выходит на сцену тогда, когда нужно чтобы участников было больше чем два, и данные от одного участника передавались сразу нескольким другим участникам.
В этом случае одним из участников может выступить сервер, который наладит общение один на один с первым участником, получит от него данные, затем наладит общение, тоже в режиме
один на один с другими участниками и перешлет им эти данные. Т.е. сервер держит множество peer-to-peer каналов связи и просто копирует данные во все эти каналы. В терминологии WebRTC такой сервер служит как Selective Forwarding Unit (SFU).
image
Однако, коммуникация в группе возможна не только с помощью SFU. Вы можете спросить почему каждый не может посылать данные каждому, без всякого сервера, и будете совешенно правы. Это называется MESH коммуникация.

Здесь есть два ключевых момента:

  1. В MESH схеме каждый из участников посылает и получает N-1 потоков данных, где N размер группы. Т.е. требования на upload speed для каждого участника в MESH схеме увеличиваются с ростом группы. Тогда как в SFU схеме каждый участник всегда посылает только один поток. Не у каждого участника скорость соединения с сетью потянет посылку N-1 потоков.
  2. К сожалению, в MESH схеме браузер делает аудио-видео сжатие на каждый посылаемый поток. А это, как мы знаем, самы ресурсо-затратный процесс. В MESH схеме, приведенной выше, браузер каждого участника будеть сжимать видео VP8/VP9/H264 кодеком 4 раза. Это вызвано требованием WebRTC к адаптации качества данных к качеству канала если связь не очень, то компрессия станет посильнее. Что есть хорошо, но влечет необходимость сжимать независимо на каждый канал (PeerConnection). Увы, на обычной машине браузер при сжатии 720p видео уже занимает 30% процессора, т.е больше трех каналов не потянет.

Из-за этих двух ключевых моментов MESH схема становится плохо реализуемой при растущем числе участников и приходится применять SFU схему.

Итак, при большом количестве участников коммуникации необходим сервер (SFU).
Давайте приведем примеры таких приложений, где сервер необходим:

  • Видео конференции с множеством участников (всеми горячо любимый Zoom использует WebRTC сервер, как и все подобные сервисы).
  • Видео наблюдение в реальном времени, когда от одной камеры видео посылается нескольким зрителям и записывающим устройствам. Системы безопасности, мониторинга.
  • Интерактивные системы, такие как: интернет-аукционы, обучающие и другие веб-приложения, где требуется низкая задержка аудио/видео.


2. Если вам нужен-таки серверный WebRTC, что можно использовать в 2020 году?

Облачный сервис или своими силами?

Здесь вначале обычные для IT аргументы в пользу того либо другого: облако обеспечит и сэкономит IT-затраты на сервера, конфигурацию, масштабируемость. Но своими силами, если все получится (нет гарантии), то выйдет гораздо дешевле. Ведь за облачный сервис нужно помесячно платить.

Теперь к аргументам специфичным к описанным выше приложениям. Если у вас глобальная, огромная аудитория, в разных странах и регионах, то своими силами вам будет сложно все собрать вместе. К примеру, для аукциона Sotheby's подойдет облачный сервис. Но если у вас 2-3 отделения компании в разных городах, 200-500 юзеров, и для них нужно организовать вебинар/конференции/обучение и т.п., то вы можете сами рентовать несколько серверов на AWS или подобных хостинг платформах, установить там софтверный WebRTC сервер, и все получится. Сервера могут даже быть у вас в компании, если скорость интернет-подключения позволяет. Ну и для всех решений меньших по масштабам, все можно сделать своими силами.

На текущий момент хорошо известны и проверены два облачных WebRTC сервиса: Millicast и Phenix. У обоих глобальное покрытие, хорошая связь между серверами на разных континентах (оно вам надо?) и действительно задержка видео (latency) на уровне пол-секунды и ниже.

Теперь поговорим про своими силами.

Здесь вам понадобится WebRTC server software. Существуют 3 способа получить такой сервер.

  1. Сделать его самим, пользуясь открытым API. Самый известный из них это Google c++ WebRTC API. Также можно использовать GStreamer API. Интересна имплементация на Go: Pion WebRTC. Вам понадобятся квалифицированные c++ программисты и очень много терпения и времени на отладку. Про трудности этого подхода я подробно писал в своей предыдущей статье.
  2. Взять уже готовый бесплатный сервер с открытым кодом. Заслуживают упоминания Ant Media Server, Kurento, Janus, Jitsi. Эти сервера вполне подойдут для небольших проектов, хотя код там не оптимизирован, не оттестирован, встречаются баги. На github есть множество других проектов, еще более экспериментальных и сырых. Чтобы оптимизировать, заточить и починить баги, нужны, см. выше, собственные квалифицированные c++ программисты. Или нужно просить разработчиков этих продуктов все для вас заточить. Что делает продукт уже не бесплатным, а весьма дорогостоящим.
  3. Купить лицензию на платный сервер. Как правило, более законченный, надежный продукт и бесплатная поддержка. В этой категории следует отметить Red5 Pro, Flashphoner и Unreal Media Server.

Интеграция WebRTC сервера в ваши существующие продукты и решения.

Это самая проблематичная тема. Предположим, ваша компания выпускает софтверный продукт, в который надо внедрить WebRTC сервер. Пусть это система видеозаписи и наблюдения для терминалов аэропортов, вокзалов, транспортных узлов. Или медицинское оборудование с уже существующим сопровождающим софтом для трансляции и записи видео от эндоскопов, который нужно расширить до трансляции этого видео в браузер. Или система симуляции полетов, в которую надо внедрить возможность визуализации в браузере и/или интеракции с удаленным юзером. Мы постоянно сталкиваемся с подобными требованиями. У вашей существующей системы множество ограничений. Может не быть доступа в интернет. Никаких облаков. Нельзя на сервере открывать порты. Только Windows или только Linux. Иногда даже только определенная версия Windows, ведь существующий продукт заточен под нее. WebRTC сервер, добавляющийся в такую систему, должен быть подстроен под все эти ограничения.

Здесь, возможно, у вас нет иного выхода, чем брать открытый код сервера, такого как Ant Media Server или Janus, и менять его. Такова ситуация на Linux. Для Windows подойдет Unreal Media Server это софт написанный и оптимизированный только для Windows OS.

WebRTC сервер очень ресурсо-затратный.

Помните об этом, когда планируете ваши ресурсы. Причины такой ресурсо-затратности описаны мной в предыдущей статье, но вывод такой масштабируемость достигается очень сильным процессором или добавлением физических серверов.

Привожу диаграмму тестов произведенных с Unreal Media Server v13.0 на AWS EC2 m4.2xlarge instance: Intel Xeon 8 cores CPU E5-2686 v4 @ 2.30 GHz, 32 Gb RAM, Windows Server 2016.
image
Как видно из диаграммы, при 1000 одновременных веб плеерах вот этой IP камеры загрузка процессора составляет 5% при RTMP протоколе, и 75% при WebRTC протоколе, т.е. WebRTC более чем в 10 раз ресурсо-затратнее чем RTMP.
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru