Поточното предаване на живо не е толкова рядка функция, която се изисква в софтуерен проект. За вашите стриймъри обаче е наистина неудобно да изтегляте OBS или друг софтуер, за да го пуснат на живо. Браузърът обикновено е единствената програма, която се използва на компютър в днешно време. Вашите потребители трябва да предоставите цялостно решение за браузър. Въз основа на моя опит ще споделя подходите към този проблем, които намерих за работа. Нека се потопим в решението:

WebRTC идва на помощ

Да, точно така – най-вероятно ще трябва да използвате WebRTC от страната на сървъра. Това е единственото работещо и сигурно решение, което съществува. Ето кратко обобщение:

Предимства:

  • Той автоматично осигурява адаптивно поточно предаване.
  • Всъщност дори не е хакване — то е НАПРАВЕНО за изпращане на видео
  • Всъщност има хора, които знаят как да я използват — това не е ниша технология
  • Възможно е записване

Недостатъци

  • Въпреки че е лесен от страната на клиента, той не е твърде ясен от страната на сървъра - трябва да вземете предвид няколко сценария.

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

На тази диаграма представям възможните архитектури на крайното решение. Както можете да видите, има 2 основни пътя, по които можете да поемете:

Повторно поточно предаване на WebRTC MediaStream на Streamer

Идеята е ясна — приемате MediaStream на Streamer и го разпространявате отново до всеки зрител, който се свърже.

Предимства

  • Това е по-лесният начин
  • Той е по-малко склонен към грешки поради по-малко елементи, включени във веригата
  • Изключително ниска латентност: това е буквално мигновено (е, не буквално - има шепа милисекунди забавяне)
  • Включен е адаптивен битрейт - той е възможно най-оптимизиран от кутията

Недостатъци

  • Записването не е включено и може да е малко по-трудно за прилагане - почти сигурно ще изберете HLS пътя само за внедряване на запис.
  • Много по-трудно е да се мащабира

Що се отнася до частта за мащабиране — ще трябва да настроите персонализирана услуга за преразпределяне на заснетия Streamer MediaStream първо в множество екземпляри на вашето приложение, а след това към зрителите.

Начинът на HLS

Това е малко по-сложен път, но ви дава неограничена мащабируемост на ниво. Всъщност това е толкова просто, колкото мащабирането на хостинг на статични файлове. Визуализаторът просто ще изтегли куп файлове. Това е основната идея зад HLS.

Предимства

  • Ултра мащабируем
  • Включен е запис
  • Много гъвкав по отношение на кодеците, които искате да поддържате

Недостатъци

  • Повече движещи се части — това го прави по-малко устойчив на грешки
  • По-трудно за изпълнение
  • Може да изисква хостване на медиен сървър (можете да използвате безплатен - има няколко от тях)
  • Трябва сами да приложите адаптивен битрейт и други оптимизации

Други начини за това

В момента WebRTC от страната на сървъра е единственото жизнеспособно решение за 90% от случаите на употреба. Въпреки това, има някои заобикалящи решения, които може да работят за вас, ако вашият проект е в тези 10%:

  • Запис на видеото в предния край чрез MediaRecorder API и изпращане на парчета към сървъра чрез WebSockets.

Това не позволява превключване на раздели на браузъра — нишката на раздела на браузъра спира да изпраща и записва видеоклипа няколко секунди след това

  • Peer-to-peer WebRTC

Това не надхвърля ~10 зрители — и разчита единствено на интернет връзката на Streamer.

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