Кейс: как настроили прямые трансляции на видеопортале

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

Чтобы портал работал стабильно и быстро, мы изменили архитектуру проекта, оптимизировали базы данных, полностью переписали бэкенд, фронтенд и мобильное приложение. Подробнее про проект и технологии, которые мы использовали, рассказали в статье «OrbitSoft починил: как мы переписали медицинский видеопортал с нуля».

Для организации прямых трансляций на видеопортале заказчик уже много лет пользуется стриминговым сервисом Wowza Streaming Engine. Когда мы стали настраивать интеграцию обновленного портала с этим сервисом, возникла неожиданная проблема: SDK был только на Java, а REST API не позволял подписываться на события. В этой статье расскажем, как настроили интеграцию и повысили стабильность работы портала во время стримов.

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

Часть событий компания транслирует в прямом эфире — например, мастер-классы, вебинары. Это позволяет зрителям видеть процесс вживую, задавать вопросы и сразу получать комментарии экспертов.

Для организации стримов компания пользуется платформой Wowza Streaming Engine. Это система передачи и записи потокового видео.

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

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

1. Обработка видеозаписей:

• Модуль конвертировал видео из MP4 в веб-формат Apple HLS, чтобы эффективно отдавать файлы по несколько гигабайт через интернет. Формат Apple HLS подразумевает разбивку видео на мелкие части: так оно проигрывается без задержек, даже если у пользователя медленное соединение.
• Транскодировал видео под разные разрешения: для просмотра на мониторе Full HD нужно разрешение 1080р, а для смартфона вполне достаточно 720p.

2. Общение с Wowza во время прямой трансляции:

• Модуль сообщал всем остальным частям системы, когда трансляция началась и когда закончилась.
• Собирал промежуточные кадры для обложки прямого эфира. Если пользователь заходил на сайт, когда трансляция уже началась, он видел превью еще до того, как запускал видео. Для этого модуль каждые 10 секунд брал кадр из трансляции и обновлял обложку на портале.

У заказчика было две проблемы с прямыми трансляциями на портале:

1. Модуль на Java работал плохо: потреблял много ресурсов, не чистил место при удалении видео, выдавал ошибки.
2. Все компоненты системы стояли на одном сервере: и бэкенд, и фронтенд, и база данных, и Wowza. Когда запускалась трансляция, Wowza забирала ресурсы себе, а другие компоненты системы начинали тормозить. Если стрим набирал несколько тысяч зрителей, трансляция и вовсе прерывалась.

Мы переписали модуль-транскодер на Go. Использовать Java для его задач — это избыточно, она потребляет несоразмерно много ресурсов. Go быстрее, проще и покрывает все задачи проекта. Это повысило стабильность и ускорило работу модуля.

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

Мы стали искать другой способ фиксировать события. И нашли: пустили трафик через модуль RTMP прокси-сервера Nginx. Он понимает, когда началась и закончилась трансляция, и рапортует транскодеру на Go, а тот общается с Wowza через API.

Цепочка интеграции следующая:

Прямой эфир:

1. Заказчик на своем оборудовании создает новую трансляцию, указывает ссылку на сервер Nginx RTMP и автоматически сгенерированный для этой трансляции Event ID.

2. Трафик идет на RTMP-модуль, он отправляет ID бэкенду и спрашивает: «Для этого ID разрешена трансляция?» Бэкенд проверяет, все ли в порядке, и возвращает ответ: «Все хорошо».

3. Модуль RTMP пропускает трафик на Wowza.

4. Wowza в реальном времени конвертирует RTMP-трафик в потоковый формат. В клиентской части появляется прямой эфир, который могут смотреть зрители.

Видеозапись трансляции:

5. Когда эфир заканчивается, заказчик нажимает «Стоп». RTMP-модуль рапортует транскодеру о завершении трансляции.

6. Транскодер забирает из Wowza файл MP4 и начинает его транскодировать в HLS для просмотра на портале.

7. Пользователи могут смотреть запись трансляции.

Так как во время прямых трансляций Wowza отбирала ресурсы у других компонентов системы, мы решили вывести ее на отдельный сервер. Теперь компоненты портала разделены на 4 сервера и систему хранения данных (СХД):

1. Фронтенд и часть бэкенда.
2. База данных.
3. Wowza.
4. Модуль транскодирования.
5. СХД для хранения медиафайлов.

• Переписали модуль транскодирования с Java на Go, улучшили его работу.
• Заново настроили связь с Wowza. Наша цепочка интеграции выполняет весь объем задач, работает быстро и без ошибок.
• Стримы могут смотреть более 10 тысяч зрителей — трансляция не прерывается.
• Во время прямых эфиров можно продолжать пользоваться клиентской частью портала, например смотреть записи уроков или читать новости, — сайт не тормозит.