По-техническим причинам, мы временно не принимаем платежи по картам.

Для прямых платежей через Wire-Transfer или USDT, пожалуйста свяжитесь с нами по адресу:
sales@flashphoner.com

Приносим извинения за доставленные неудобства.
Мы проинформируем вас как только платежи заработают. Следите за новостями на нашем сайте.

Представим ситуацию: Олег — fullstack разработчик, работающий на Windows, и его новая задача — разработать клиент-серверное приложение для стриминга. Если быть точнее, то для захвата RTSP-камер. Можно, конечно, поднять сервер в облаке, но тогда к дебагу возможных проблем с клиентским кодом или настройкам сервера добавляется дебаг проблем с каналом, поэтому тестирование в локальной сети удобнее, в том числе, потому что это бесплатно. Или можно использовать Docker, но тогда добавляются другие сложности: из-за проблем с сетью, Docker на Windows непригоден к использованию, а обходной путь — запуск Docker в виртуальной машине — слишком усложняет работу.

Что делать в таком случае? Оптимальный вариант — использовать WSL, а вот как именно, мы расскажем (и покажем) на примере Web Call Server (WCS), который поможет нам при конвертации RTSP-потоков в WebRTC.

Использование контейнеров Docker для тестового ландшафта — это без сомнений быстро, просто и удобно. Но если развернуть с помощью контейнеров более нагруженную систему? Как в таком случае будет все работать? Действительно ли можно использовать Docker в продакшене?

С системами видеонаблюдения мы сталкиваемся в самых разных местах — это магазины, торговые центры, банки, гостиницы, здания офисов, коттеджи и квартиры, автостоянки и оживлённые перекрёстки — трудно перечислить все возможные варианты установки камер. Так же существует великое множество различных аппаратных и программных решений по организации видеонаблюдения: аналоговые камеры и «железные» регистраторы всех сортов и расцветок, софтовые решения, облачные решения, IP камеры, которые могут работать как сами по себе, так и с серверными или софтовыми решениями и т.п. Из всего многообразия нас будут интересовать те экземпляры, которые отдают видеопотоки по протоколу RTSP.

Сложно представить видеостриминг без записи. Запись видеопотоков — одна из самых востребованных функций, которая может использоваться в различных сценариях работы, например, запись видео сообщений, архив видеонаблюдения, запись интервью, съемка на улице и многие другие.

Последнее время в нашем блоге мы рассматриваем всевозможные варианты нагрузочных тестов. В одной из предыдущих статей мы тестировали один из распространённых сценариев работы сервера — «Один поток, много зрителей». В этом сценарии на сервере публикуется один WebRTC видеопоток и большое количество зрителей подключается для просмотра этого потока. Таким образом работает, например, трансляция соревнований: трансляция идет, пользователи смотрят. Но достаточно часто требуется реализовать другой подход — «Много потоков, много зрителей» — когда на сервере одновременно публикуется много WebRTC потоков и у каждого опубликованного потока есть один зритель. Такой вариант может использоваться для организации простого видеочата один на один без использования микшера или MCU.

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

Микширование видеопотоков — достаточно популярный инструмент для разных стримеров.

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

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

Тестирование получилось несколько «сферическое в вакууме». Мы публиковали на одном WCS поток, который потом забирали энное количество раз при помощи второго WCS, и, на основе результатов этих тестов, делали выводы о работособности железа.

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

Самый простой и логичный вариант тестирования: провести ручной тест — открыть браузер, открыть вкладку с плеером, указать имя потока и нажать кнопку «Play». Повторить 1000 раз.

И вот с этим возникает загвоздка. Во-первых, надо повторить запуск плеера 1000 раз. Сомневаюсь, что это будет просто! Во-вторых, надо подготовить кластер из нескольких мощных серверов для запуска браузера с тысячей вкладок на которых будет проигрываться видео. В-третьих, ручной тест при таких условиях займет достаточно продолжительное время. По этим причинам ручной тест не стоит рассматривать как один из способов нагрузочного тестирования.

В этой статье мы разберем еще один способ тестирования — с использованием Нeadless-браузера и сравним результаты такого тестирования с тестированием на основе захвата потоков.

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

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

«Подключиться к трансляции смогли только половина зрителей!» — услышал программист в телефонной трубке.

Печально вздохнув, он открыл ноутбук и начал изучать логи.

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

Среди частых обращений в нашу поддержку есть вопросы об организации мониторинга для стриминга WebRTC. Как правило, стримеру важно знать, что происходит по «другую сторону» — оценивать качество потока, количество зрителей и другие параметры. Качество потока, как уже неоднократно обсуждалось, величина не постоянная и зависит от многих факторов: это и нагрузка на сервер при наличии или отсутствии транскодинга, и использование TCP или UDP протоколов транспорта, и наличие потерь пакетов и/или NACK фидбеков и др. Все эти данные, для оценки качества потока, можно получать вручную из различных источников.

Деградация стрима — это такое состояние видео-аудиопотока, при котором качество картинки и звука не удовлетворительно. Наблюдаются артефакты, фризы, заикания или рассинхронизация звука.