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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конечно, для записи экрана существует тонна различного софта — и платного, и бесплатного. FFmpeg уверенно держит свои позиции из-за кроссплатформенности, минимального интерфейса (которого нет совсем, все управляется через консоль операционной системы) и огромного количества функций. На базе FFmpeg сделано множество программ по конвертированию видео из одного формата в другой. FFmpeg абсолютно самодостаточен. Для того чтобы посмотреть фильм нет необходимости искать в сети, скачивать и устанавливать кодеки. Достаточно всего лишь одного файла (ffplay.exe), все кодеки содержатся внутри этого файла.

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

В путь!

И снова мы возвращаемся к теме разработки системы для проведения вебинаров. Онлайн-семинары, web-конференции, онлайн-встречи, разнообразные презентации и web-туры — все это, так или иначе, относится к вебинарам.

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

В этой статье мы разберем что же такое Canvas стриминг и какие есть подводные камни.