Способы стриминга видео/голоса с android клиента на сервер и наоборот?

Question

[ivanessence]

Стоит задача организовать стриминг видео и голоса с android клиента на сервер и наоборот, по аналогу Skype, Viber. Какие способы организации можно применить? WebRTC, websocket? Понятно, что можно нагуглить, но может быть есть у кого-нибудь реальный опыт, используемое API, технологии и т.д.

Answer 1

[Юрий Удовиченко]

С мобильных устройств передача потока на сервер идёт, как правило, или по RTMP, или по RTSP. Есть варианты для WebRTC, но и пока немного.

Передача на клиента может быть разной, в зависимости от сценария. Для передачи на большую аудиторию используют HLS - там будет задержка, но его проще раздавать через кеширующие сервера. Если нужно в реальном времени, то используют RTMP или WebRTC, а наши клиенты начинают всё больше использовать наш SLDP.

На рынке есть библиотеки, которые позволяют реализовать всё указанное в разном виде - например, наши мобильные SDK вещания и проигрывания.

Comments

[alexdora]

SLDP серверная база на чем. Вот мне нимбл не интересен, как например взять rtmp поток и в него пустить?

[Юрий Удовиченко]

Пустить RTMP в него - это в кого? С девайса на сервер вы можете отправить поток по RTMP или RTSP. С сервера на девайсы - всё тот же RTMP, если не хочется использовать SLDP. Если для получения на девайсы задержка в несколько секунд не критична, то можно использовать HLS, как наиболее поддерживаемый.

[alexdora]

Юрий Удовиченко, Нет я сейчас задаю вопрос по SLDP. Вот вы скидываете ссылку и я вижу доки только на принимающую сторону. Что на сервере должно стоять?
Сейчас у нас nginx + rtmp. И опять же повторюсь без nimble это возможно?

[Юрий Удовиченко]

Да, на сервере нужно ставить Nimble Streamer для передачи по SLDP. Прицепом, кроме SLDP, он умеет выдавать и все остальные протоколы.

[alexdora]

Юрий Удовиченко, Ясно. Мы как-то обкатывали демо-версию, ранее у вас они были. Все работает из коробки, действительно достойный сервис и я так понимаю разработан в России (что радует), но сейчас пользуемся логичным решением для вещания rtmp + nginx + ffmpeg и не находим применения и желания переставлять все на Nimble.
У меня есть ряд лайтовых "претензий" которые останавливают попытки воспользоваться и попробовать, а возможно и использовать в работе вас (я думаю вы не против если я напишу прямо сюда)
1. У вас есть в AppStore приложение Larix Broadcaster (вроде так называется). Я хотел бы чтобы вы как представитель разработчика скачали приложение Live: Solo от Teradek (напомню, это компания которая выпускает оборудование которая на всех съемках присутствует в принципе). Посмотреть не для того чтобы скопировать, а сравнить вещание. Когда мы пробовали Larix – это было небо и земля по качеству потоков. Я понимаю, что это лишь утилитка для того чтобы показать возможности, но по факту получилось так: Приложение на тот момент криво вещало (артефакты были, лаги на высоких разрешениях) и это приложение от разработчиков Нимбл. Логичный вопрос возник о том, если приложение кривое, а не кривой ли Nimble в целом. Я серьезно, без шуток. Помню это обсуждение на летучке

2. Хотелось бы на вебстраничке увидеть тесты как ваш SLDP кажется на айфонах в броузере. Это реально больше всего интересно. Тестов нет, а проводить тесты самим не хочется. Тем более у вас сейчас "условно" демо период отменен

3. Вы конечно должны на сайте были написать о том, что SLDP проприетарный протокол который идет в составе Nimble

Надеюсь ничем не обидел, лишь говорю свои мысли которые надеюсь услышат

[Юрий Удовиченко]

Спасибо за фидбек, нам это всегда интересно.

По вашим замечаниям могу сказать следующее.

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

По поводу "если приложение кривое, а не кривой ли Nimble в целом" - вы должны понимать, что это принципиально разные продукты и с совершенно разной кодовой базой. Нимбл пишется на С++ начиная с 2013 года, первый прототип Ларикса для Андроида (Java) появился в конце 2015 года, чуть позже поехал и Ларикс для iOS (ObjC). Повторю - это совершенно несвязанные продукты, их сравнивать некорректно.
Сейчас вот кстати SLDP Player добавили для Андроида и iOS - и это опять же совершенно новый продукт, не связанный с предыдущими, разве что часть алгоритмов протокола и техник обработки ABR обкатывалась на нашем HTML5 плеере веб-командой.

2. Тест SLDP на айфонах в браузере можно сделать на нашей тестовой странице плееров здесь - player.wmspanel.com/. Спасибо, что напомнили, надо бы добавить эту ссылку со всех страниц про SLDP.

Кстати, почему вы думаете, что "демо период отменен"? Две недели любой триальный аккаунт в панели будет работать, сможете всё проверить.

3. Мы выпустили протокол на широкую публику относительно недавно и пока до конца не отказались от мысли его открыть позже в виде спека. Но ваш пойнт валиден - стоит это пока явно прописать.

P.S. И да, вы правы, мы - российская компания. :)

[alexdora]

Юрий Удовиченко, По поводу приложения прошу обратить на это пристальное внимание. Я вам назвал приложение которое "просто работает" и рекомендую перед выпускам приложения самостоятельно проверить разницу с кодировании и разницу по лагам/артефактам. Опять же Терадек славится продуктами которые как эппл - работают без отказов, и стоят они всегда космических денег. И видите как получилось – мы задумали о том, что а может там тоже есть косяки раз приложение кривое. Не забывайте, что очень часто так бывает - два продукта от компании и один из них плохой. Отношение будет по плохому всегда.

[alexdora]

Юрий Удовиченко Есть у меня такое предложение. Мы сейчас глянем SLDP (давно искали реализацию) и если все ок что могу предложить: Мы клиент не денежный, у нас сейчас 2 сервера вещания всего на базе nginx. Но у нас "хулиард" специфических задач и когда мы ищем решение этих задач, то чаще всего мы находим что такая задача уже кому-то была нужна, но готового решения нет и приходится нанимать программистов чтоб писали пачку скриптов, которые потом на одном честном слове работают (к примеру стандартная задача которую мы решали в свое время и решили таким способом: поток RTMP рухнул входящий, резко включить заглушку или переключить на другой поток. Возможно она у вас уже решена, но на базе nginx - велосипед еще тот)
И было бы не плохо если была бы возможность делиться такими задачами с разработчиками и на эти запросы не забивали формата: Да интересно, но потом через годика два сделаем...а именно брали и ставили задачу в разработку.
Опять же говорю, мы для вас не можем стать денежным клиентом, но можем накидать вещей которые действительно нужны людям в вещании.

[alexdora]

Вот кстати недавний топик, опять велосипед строим: Как передать нажатие клавиши в фоновый процесс?

[alexdora]

И еще, зашел с айфона player.wmspanel.com и как запустить SLDP? Какую ссылку там указать?

[Юрий Удовиченко]

alexdora, Ссылка должна генериться Нимблом - это пока единственная серверная реализация, как вы правильно заметили.
Насчёт пожеланий отпользователей - у нас поход простой - мы принимаем все фичи, ставим в виш-лист и приоритизируем в зависимости от востребованности. При этом многие вещи из тех, что спрашивают, бывают уже реализованы - фич много и не все из них находятся с ходу в документации.
В частности, задача про "поток RTMP рухнул входящий, резко включить заглушку" - она нами решена с помощью наего транскодера, оно описано здесь: blog.wmspanel.com/2017/04/streams-failover-hot-swa... Кстати, решена и обратная задача - замена вещания срочным потоком на замену: blog.wmspanel.com/2017/04/emergency-streams-hot-sw...

[alexdora]

Юрий Удовиченко, Могу вам прям сюда интересную задачку закинуть, из-за которой нам пришлось потратить дохрена денег и все равно велосипед получился.

[Юрий Удовиченко]

alexdora, Давайте попробуем

[alexdora]

Юрий Удовиченко,
Задача наложить графику динамическую на видео которое приходит по RTMP и соотвественно объединить. Единственный дешевый вариант это сделать - купить отдельную машину хорошую (что важно с видяхой) поймать поток rtmp или камеры напрямую (у нас через rtmp) с помощью OBS или Vmix (он стоит 300 баксов лицензия) и в них активировать а-ля фильтр браузер с выходом на некий адрес где прозрачный фон и вся графика создается ajax запросами к серверу и в зависимости от того что по ajax приходит javascript + webgl это все рисует вебстраничку, а далее накладывается с помощью vmix или OBS на поток и дальше отправляется на nginx+rtmp для публикации.
Вот в этой всей схеме OBS и vMix используются по сути как браузер (один бесплатный, другой платный) и приходится ставить операционку с GUI ради этого, короче это костыльный костыль

Другой вариант дорогой - Blackmagic Studio. Цена вопроса взлетает до 1млн рублей, если делать все по человечески.

Вы не представляете сколько людей на форуме OBS используют такую же технику Камера + WebGL для графики и сколько людей поступили так же как и мы - купили отдельную машину. А когда потоков несколько надо обрабатывать – халлоу виртуализация с VGA со всеми вытекающими проблемами. Если бы вы сделали возможность на нимбл добавлять webgl маску на всё (а с учетом того что и vMix и OBS используют исходники хромиум движка, т.е они не придумывали велосипед, а взяли готовое) – вы бы просто спасли эту планету.

[alexdora]

Юрий Удовиченко, Юрий, я вот сейчас 10к$ отдал буквально вчера за сервак с двумя процами + 3 видео карты и бл**ство в том, что там должна из-за этого всего винда стоять и лес из OBS и Vmix.
Больше всего смущает именно то что там: Винда и то что приходится делать 3 виртуалки с пробросом не дешевых видях Nvidia для полноценной работы Vmix. Т.е мы будем следить за работой сразу 4 Win машин на базе одной и хрен его знает, будет это работать стабильно или нет. А бюджета на решение с блэкмэджик и нет, да и там такую задачу все равно не решить прямолинейно. И только из-за возможности webgl это все

[Юрий Удовиченко]

alexdora, Какого рода динамическую графику вы накладываете на изображение, можете пример привести? В нашем транскодере есть и graphics overlay для наложения статики, и картинка-в-картинке для наложения живого потока, и всё месте. Так что если вы дадите поток, где будет формироваться графика, то нашим транскодером вы сможете наложить одно на другое. Дайте пример, в общем.

[alexdora]

Юрий Удовиченко, Давайте простой пример. Дано: есть прямой эфир, люди его смотрят на вебстраничке (а-ля ютюб) и там есть чат (в ютюбе есть чат справа от ролика). Задача: Вывести этот чат не на вебстраничке, а прямо в видеопотоке. Т.е наложить чат на видеопоток. Ну к примеру сообщения которые ведущему понравились!
Чат в данном случае это и есть та графика. Сейчас эта задача решалась бы так:
Мы берем видеопоток (допустим с камеры) и накладываем с помощью OBS страничку в интернете которая постоянно обновляется по Ajax. По сути мы накладываем на видеопоток вебстраничку и все что на ней происходит. Красота решения в том, что webgl позволяет рисовать с нуля все что угодно, а javascript с помощью AJAX получать обновления.
Я попытаюсь сейчас объяснить еще раз на пальцах. Речь идет о том чтоб создать приложение некое на базе linux, которому передаются параметры:
Выходное разрешение / Количество кадров / Адрес странички / Цвет прозрачного фона
Приложение заходит по адресу страничке http/https и ведет себя как браузер, т.е загружаются все скрипты и рендерит её, и все что она рендерит превращается в видео формата Выходное разрешение / Количество кадров. И вот этот результат накладывается на видео уже. Т.е идет создание еще одного видеопотока на базе рендеринга. Притом сам рендеринг продолжает работать в режиме лайв. Т.е это не просто снэпшот страницы, это тоже самое что вы откроете какой-то сайт где реализован ajax...и допустим там приходит личное сообщение на каком-то форуме и у вас сразу без перезагрузки страницы отображается что новое личное сообщение. Я указал выше что есть входной параметр какой цвет считать прозрачным. Т.к вот допустим условно белый цвет на страничке == прозрачный. Т.е все белые пиксили при рендеренге вырезаются. В решении задачи выше получится например белая страница 1920x1080 где справа появляются блоки с чатом. А они появляются за счет запросов ajax с помощью javascript.

Сейчас есть только решения этой задачи на OBS/vMix, а сама задача очень востребована. Т.е если на базе нимбл появится приложение которое умеет делать webgl-поток с наложением, за него не стыдно заплатить. Во-первых оно будет более отказаустойчево, во-вторых оно будет ограничено только техническими лимитами конкретной машины. Чтоб запустить 5-10 потоков с webgl мне надо сейчас запустить 5-10 OBS. И поверьте на слово, это еще то приключение))

В плане зачем это для людей. Все просто: Чтобы накладывать в том же OBS тот самый webgl и графику у человека сразу возрастает требование к железке. Одно дело просто взять с камеры и воткнуть 1080p и опубликовать, другое дело когда надо взять с камеры 1080p наложить на неё графику и отправить дальше.
Там разница по загрузке процессора сразу примерно в 2 раза возрастает
А если решение будет от вас, получается человек может условно взять вещалку hw, заплатить вам 50 баксов в месяц + VPS и делать неплохие шоу с минимальными затратами. Конечно, вам надо немного будет маркетинг сделать всего этого и готовое решение для даунов (а-ля инструкция как сделать красиво за 10 движений)

[Юрий Удовиченко]

alexdora, Идея отличная и сложная в реализации. Подобные вещи штатно делаются в системах для клиентов уровня телестудии - и там ценники просто физически не могут быть небольшими, иначе невыгодно разрабатывать. Так что увы, у нас такого пока не предвидится, к сожалению.

[alexdora]

Юрий Удовиченко, Юрий, гляньте как будет время повнимательнее, дело в том, если бы реализации не существовало в принципе. Но по факту – OBS который является бесплатным это сделал и насколько я понимаю, они просто взяли готовый движок webgl. Я намекаю на то, что возможно это легче чем кажется на первый взгляд.

[Юрий Удовиченко]

alexdora, Идея интересная, будем посмотреть.

[alexdora]

Юрий Удовиченко, Если вдруг возьметесь за реализацию, можешь мне тут ответ с указанием ника нарисовать, чтоб я заметил.

[alexdora]

Юрий Удовиченко, А еще один момент, можете на своем плеере сделать SLDP тест как-то. Блин, получается мне надо сейчас установить нимбл чтобы посмотреть как работает SLDP на айфоше в браузере. Я тыкал протокол, но ссылка не меняется и ничего не грузит, что на маке, что на айос

[Юрий Удовиченко]

alexdora, Чтобы сделать тест потока SLDP, нужно дать какой-то поток на вход Нимблу, чтобы исходящий из него поток уже можно было проигрывать где нужно. Это значит установку публично доступного инстанса. Вместо этого мы предлагаем будущему клиенту самому попробовать всю цепочку и посмотреть насколько оно всё удобно работает (или не удобно - кому как) и сделать выводы по использованию у себя.
Что касается проигрывания в браузерах прямо сейчас - сильно зависит от того, какая версия ОСи установлена, оно работает в браузере только там, Где уже работает MSE.

[alexdora]

Юрий Удовиченко, Ну вы же понимаете, напрашивается домашние задание вам: Сделать Compabality table browser
Ваш подход ясен и очень хорошо, но я вам хочу другую сторону подсказать. Мы много времени тратим на техническое обеспечение трансляции и наверное наш коллектив я назову профессионалами интернет вещания. И нам чтоб попробовать не хватает готовых тестов и различных таких штук. Т.е когда человек впервые заморачивается трансляцией - возможно у него есть время тестить разные продукты. А у нас уже то состояние когда просто надоело тестить и любые продукты с хорошим описанием и тестами воспринимаются с большим желанием :)
Я надеюсь, что вы учтете это пожелание, даже если у вас позиция несколько иная. Вообще если уж быть совсем честными, то у вас сайт не самый понятный. Такое бывает когда документацию составляют программисты

Сейчас очень хотелось бы посмотреть как по ws видео шлется, есть ли лаги какие-то и рассинхрон звука. Я помню вашу статью когда WebRTC помоему делалось видео, но там звука не было. Я так понимаю SLDP это логичное его продолжение (может что-то путаю, но вроде ваша статья на хабре)

We are watching you ))

[Юрий Удовиченко]

alexdora, Насчёт "надоело тестить" - не соглашусь. Тестить нужно обязательно, особенно если речь идёт о работающей компании, которая хочет перейти с одного решения на другое.
Мы видим регулярно клиентов, которым надоело какое-то решение и которые хотят что-то поменять в лучшую сторону. Они начинают смотреть по сторонам и упираются в то е самое - гне хочется тестить, очется чтоб завёл и оно заработало. Так не получится, в любом случае нужно пройти определённую learning curve и сделать осознанный выбор.
У нас даже отдельная статья про это есть blog.wmspanel.com/2017/05/competition-manifesto.html

Что до WebRTC - у нас его нет, мы за него даже не брались пока. У него были определённые ограничения, которые нас останавливали, в итоге мы сделали свой SLDP, который тоже на вебсокетах, но даёт несколько другие возможности.

[alexdora]

Юрий Удовиченко, Юрий не так меня поняли немного. Тут ввиду разной специфики нашей жизни пропасть небольшая. Сейчас у нас есть сервис который работает и очень много времени тратится в разработку. Если бы я вас тут не встретил, даже не поднялся бы вопрос тестирования. Почему? Потому что скорее всего на ваш протокол SLDP (нам нужна low latency) наткнулся бы мой программист (мы мониторим вашу компанию, это правда) и пришел бы ко мне с вопросом: Вот есть такая херня. Первый мой вопрос покажи мне пример как это работает. А примера то нет. И тут я должен принять решение выделять время на тестирование или нет. Не встретив вас тут – скорее принял бы решения на текущие время в сторону Нет. Это мой не основной бизнес, да я и не технарь. Я управляющее звено которое должно принимать решение, куда будет оплачиваемое время уходить. И с точки зрения управляющего я буду прав, на кота в мешке выделять время которого сейчас нет и когда все и так работает пусть и через кучу велосипедо...поступок не оптимальный.
И как управляющий рекомендую предоставить на SLDP тесты у себя на сайте, а в идеале еще C. browser table. Если бы программист пришел бы и сказал: Вот есть SLDP и вот у них на сайте тесты и все вот так работает, вопросов и сомнений бы не было. Было бы с моей стороны: Хочу! Сейчас выделите время и начинайте тесты. Вот как это работает.
Мы конечно сейчас обсудили уже, чтобы прогнать свои тесты и принять какое-то решение нам нужно выделить 3-4 часа рабочих одного человека и мы выделим. И только потому что я встретил вас тут и мне показалось что вряд ли вы выкатили бы протокол который работает с косяками (сужу по тому как вы отвечаете)

[Юрий Удовиченко]

alexdora, Я думаю, рассмотрение альтернатив и выбор новых технологий - это ответственность CTO организации или техлида команды, которая эту технологию будет использовать. Этот человек должен руководить выбором или же тестировать самостоятельно прежде чем предлагать решение руководству по оплате или перераспределении ресурсов. У вас есть ваш конкретный проект и никакие дистиллированные демки не смогут показать как оно будет работать конкретно у вас. ОК - мы например сделаем публичную точку входа для публикации потока и дадим плеер. А кто даст гарантию, что в вашей более сложной инфраструктуре оно будет работать именно так и что вам не потребуется вносить дорогостоящие изменения в работу системы?
Я - за осознанный выбор, об этом и статья в моём предыдущем ответе.

[alexdora]

Юрий Удовиченко, речь идет не про публичную точку доступа куда стримиш и смотришь результат. Если вы просто пустите циклично один видеофайл и люди смогут с айфона глянуть: оп, SLDP работает – будет вам большой бонус. Те кто шарит в теме и кто не одну сотню часов потратил на поиск решения: работает почти в любом браузере с задержкой меньше <3 секунд натыкались на различные вариации, включая WebRTC. И там даже по цикличному ролику было понятно: Либо звук уходит, либо лаги жесткие и прочие болезни. Такой продукт в продакшен не нужен.
А если сделать вывод циклично файла и наложения текущего времени с секундами – это еще круче. Можно сразу и задержку оценить, но это не обязательно. Куда важнее как оно играется, а задержку уже в любом случае на тестах смотреть. Вы же сами знаете что zero latency это перспективная вещь, но очень сложная. Ведь по сути всегда упиралось в то, что минимальная задержка на RTMP выдавала 1-2 секунды, но для проигрывания на тех же айфонах – отдельное приложение. Поэтому и прижился HLS, он играется в HTML5 от слова "ВЕЗДЕ"

[Юрий Удовиченко]

alexdora, Мы подумаем, что можно сделать для лучшей демонстрации технологии. Спасибо за весь фидбек!

Answer 2

[Viktor]

Рабочий примет
https://www.loowid.com/