Поточното предаване на живо не е толкова рядка функция, която се изисква в софтуерен проект. За вашите стриймъри обаче е наистина неудобно да изтегляте 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.