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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В путь!

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

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

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