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

WebRTC в помощь

Да, верно — вам, скорее всего, понадобится использовать WebRTC на стороне сервера. Это единственное работающее и надежное решение. Вот краткий итог:

Преимущества:

  • Он автоматически обеспечивает стриминг с адаптивным битрейтом.
  • На самом деле это даже не хак — это СДЕЛАНО для отправки видео
  • На самом деле есть люди, которые знают, как ею пользоваться — это не нишевая технология.
  • Возможна запись

Недостатки

  • Несмотря на то, что это просто на стороне клиента, это не так уж просто на стороне сервера — вам нужно рассмотреть несколько сценариев.

Возможные архитектуры

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

Повторная трансляция WebRTC MediaStream Streamer

Идея проста — вы принимаете MediaStream Streamer и перераспределяете его каждому подключающемуся зрителю.

Преимущества

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

Недостатки

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

Что касается части масштабирования — вам нужно настроить пользовательский сервис для перераспределения MediaStream захваченных стримеров сначала между несколькими экземплярами вашего приложения, а затем среди зрителей.

Путь ЗОЖ

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

Преимущества

  • Сверхмасштабируемость
  • Запись включена
  • Очень гибкий с точки зрения кодеков, которые вы хотите поддерживать

Недостатки

  • Больше движущихся частей — это делает его менее устойчивым к ошибкам.
  • Сложнее реализовать
  • Может потребоваться размещение медиа-сервера (можно использовать бесплатный — их несколько)
  • Вам нужно самостоятельно реализовать адаптивный битрейт и другие оптимизации

Другие способы сделать это

В настоящее время WebRTC на стороне сервера является единственным жизнеспособным решением для 90% случаев использования. Однако есть некоторые обходные пути, которые могут вам подойти, если ваш проект находится в этих 10%:

  • Запись видео на фронтенд через MediaRecorder API и отправка чанков на сервер через WebSockets.

Это не позволяет переключаться между вкладками браузера — поток вкладок браузера перестает отправлять и записывать видео через несколько секунд после этого.

  • Одноранговый WebRTC

Это число не превышает ~10 зрителей и зависит исключительно от интернет-соединения стримера.

Первоначально опубликовано на https://www.antoniii.com.