Комментарии 11
rtmp? хм. удивили. Почему не webrtc?
Раз уж вы платите за sdk, есть, например, православный voximplant. Тоже с русской поддержкой относительно адекватной, довольно быстро дали разраба на мое issue.
Не хотите, поднимайте webrtc на своих мощностях на беслатных либах. Никогда бы в сторону rtmp не глянул бы. Он же в браузерах был жив вместе с флешем. Как вы решаете вопрос звонка с компа в приложение?
Мне довольно просто удалось реализовать звонок с браузера на браузер, с поддержкой адаптивности верстки для мобильных устройств. А уж если свое приложение, то с наличием доп либ совместимость протокола вообше не стоит.
Вы не написали самое главное, какая задержка сигнала вас устраивает? Это кардинально меняет выбор решений. rtmp на память около 3 секунд задерживает сигнал. Если живое общение с менеджером, то webrtc может дать ее в пол секунды. Правда слабовата картинка будет, лучше 2, а если и 10 секунд устраивает, а в обратку менеджеру только чат от клиента, то можно пойти проще и вещать на http протоколах по dash low latency. Задержка 3 секунды.
Посоветую свою статью про стриминг habr.com/ru/post/532424
Раз уж вы платите за sdk, есть, например, православный voximplant. Тоже с русской поддержкой относительно адекватной, довольно быстро дали разраба на мое issue.
Не хотите, поднимайте webrtc на своих мощностях на беслатных либах. Никогда бы в сторону rtmp не глянул бы. Он же в браузерах был жив вместе с флешем. Как вы решаете вопрос звонка с компа в приложение?
Мне довольно просто удалось реализовать звонок с браузера на браузер, с поддержкой адаптивности верстки для мобильных устройств. А уж если свое приложение, то с наличием доп либ совместимость протокола вообше не стоит.
Вы не написали самое главное, какая задержка сигнала вас устраивает? Это кардинально меняет выбор решений. rtmp на память около 3 секунд задерживает сигнал. Если живое общение с менеджером, то webrtc может дать ее в пол секунды. Правда слабовата картинка будет, лучше 2, а если и 10 секунд устраивает, а в обратку менеджеру только чат от клиента, то можно пойти проще и вещать на http протоколах по dash low latency. Задержка 3 секунды.
Посоветую свою статью про стриминг habr.com/ru/post/532424
В статье, которую вы скинули стриминг из OBS идет по RTMP или я что-то неправильно понял?
Предполагаю что Вы о доставке видео до зрителей? Но это тогда не связано с тем как реализована доставка контента до серверов.
да, до сервера стрим идет по rtmp, но как я понимаю, в вашем решении rtmp используется для раздачи и до клиентов? В этом случае невозможно использовать это решение в браузерах. Я не знаю специфику вашего проекта, может быть нужно обязательно загонять людей в приложение, но браузеры я бы точно не обделял вниманием.
Адаптивного кодека, снижающего битрейт при плохом коннекте я как-то не видел. сдается мне простая вещь — это нереально масштабировать. Лучше стримить на три урла с разным битрейтом.
Адаптивного кодека, снижающего битрейт при плохом коннекте я как-то не видел. сдается мне простая вещь — это нереально масштабировать. Лучше стримить на три урла с разным битрейтом.
Не, rtmp для раздачи не используется.
Для доставки контента используем решения от Mux «We use RTMP for accepting live broadcasts, and HLS for output streams. This gives your application the ability to stream from a mobile app, broadcast software, or hardware encoder and broadcast to any device.»
значит задержка секунд в 20. А вот low latency HLS не так давно появился. Позволяет сократить до 3.
LL HLS пока ещё на ранней стадии. Его на проигрывание поддерживает только платформы от Apple плюс THEO Player. На стороне серверов и сервисов оно только начинает добавляться.
У нас LL HLS реализован в Nimble Streamer, а большинство вендоров к нему только присматриваются — технология не самая тривиальная в реализации.
У нас LL HLS реализован в Nimble Streamer, а большинство вендоров к нему только присматриваются — технология не самая тривиальная в реализации.
WebRTC очень хорош для видеозвонков, чатов, отдачи потока из браузера, но в данном случае юзкейс — это вещание «в одну сторону», задержка там важна не настолько, как возможность сформировать хорошую картинку с мобильного устройства (на них сейчас камеры приближаются по качеству к профессиональным) и раздать её большому числу зрителей (на самых разных устройствах).
Поэтому пайплайн автора — на базе RTMP с отдачей в облако и раздачей по HLS — отлично отработанный подход, я бы даже сказал — классика.
Поэтому пайплайн автора — на базе RTMP с отдачей в облако и раздачей по HLS — отлично отработанный подход, я бы даже сказал — классика.
Картинка страдает при полусекундной задержке, по моим тестам задержка энкодера более чем в 3 секунды не дает выигрыша в качестве. В случае hls задержка в 20 секунд вызвана скорее необходимостью кеширования из-за транспортного протокола. По мне 20 секунд очень не удобно для общения с чатом. Я бы выбрал ll-dash-js (под него есть онлайн) и webrtc — это покрывает массу платформ.
Настройки энкодера (key frame interval, например), размер буфера энкодера, величина чанков, размер буфера плеера и отставание при проигрывании — взаимосвязанные вещи, но это не одно и то же. Картинка может страдать от проблем с потерей пакетов, и чем больше буфер, тем проще это митигиролвать. 20 секунд — да, это большая задержка, но таков формат HLS. Нужно больше интерактива — да, можно взять WebRTC, или технологии вроде нашего SLDP для доставки с низкой задежки.
WebRTC — отличная технология, но она — не панацея для всех юзкейсов, как и LL DASH.
WebRTC — отличная технология, но она — не панацея для всех юзкейсов, как и LL DASH.
Добрейшего дня. Спасибо за статью, вопросы подняты интересные и правильные, есть что обсудить.
По поводу изменения разрешения. Если коротко — думали над этим, всё сводится к бэкенду, никто на том конце провода не любит изменение разрешения, переподключения и прочее подобное. Основные стримиговые сервисы максимально ужесточают требования по входу, чтобы проще было работать. Кто делает кастомные разработки, уже могут позволить себе более интенсивные упражнения для улучшения user experience клиентов. AFAIK, за 6 лет существования SDK только один клиент SDK подобное у себя реализовал успешно, с интенсивным прогнраммированием на бэкенде и в приложении.
По поводу открытия логики, вместо закрытия в вызовы: собственно, реализация ABR — хороший пример. В Haishin вам дали наружу константы для управления, и этого явно недостаточно. Если бы вы остались на нём, вам всё так же пришлось бы лезть в его исходники, чтобы исправить алгоритм, всё как в Larix.
Disconnect: его мы явно получаем от iOS только в случае, если принимающая сторона разорвала соединение или отвалилась сеть. Всё остальное время мы пытаемся держать связь и проталкивать данные. Не в последннюю очередь потому, что многие бэкенды стриминговых сервисов не любят разрыва соединений. И да, мы добавим позже опцию разрыва соединения при увеличении непрошедших данных.
При этом нельзя забывать и о проблемах, которые привносит сама iOS — они в последнних версиях ОСи имеют обыкновение копить буфер, если данные не шлются, и наш алгоритм просто не знает, что ушло, а что — нет. Чуть позже мы это попробуем переработать.
Кстати, а Android работа с сетью чуть лучше, там нет буфера, накапливаемого ОСью — и ABR в Лариксе работает бодрее. Хотя там пока нет гибридного решима, руки ещё не дошли.
Далее, publish vs. connect. Во-первых, снова бэкенд. Открытие соединения для большинства их сервисов — это, как правило, и есть начало вещания. Во-вторых, вы не сможете понять качество соединения, пока не начнете слать данные, причем именно видео (только оно даст аутентичную нагрузку). А это уже точно publish, без вариантов.
А для того, чтобы поправить прическу перед началом стрима, мы сделали режим stand by в свежей версии Larix Broadcaster для iOS. Можно начать вещание без звука и картинки, но с вашей заставкой или просто с черным экраном. Это как режим паузы, только пауза идёт перед основным стримом.
Отдельно хочу сказать про альтернативу RTMP — протокол SRT. Его точно стоит попробовать для вещания из мобильных сетей, т.к. он изначально создавался для передачи медиа по сетям без гарантированного качества доставки. Там, где из-за потерянных по RTMP пакетов пропадают ключевые кадры и рассыпается картинка, потоки SRT делают ретрансмиты и нормально доставляют поток. В общем, стоит на него посмотреть тоже.
По поводу изменения разрешения. Если коротко — думали над этим, всё сводится к бэкенду, никто на том конце провода не любит изменение разрешения, переподключения и прочее подобное. Основные стримиговые сервисы максимально ужесточают требования по входу, чтобы проще было работать. Кто делает кастомные разработки, уже могут позволить себе более интенсивные упражнения для улучшения user experience клиентов. AFAIK, за 6 лет существования SDK только один клиент SDK подобное у себя реализовал успешно, с интенсивным прогнраммированием на бэкенде и в приложении.
По поводу открытия логики, вместо закрытия в вызовы: собственно, реализация ABR — хороший пример. В Haishin вам дали наружу константы для управления, и этого явно недостаточно. Если бы вы остались на нём, вам всё так же пришлось бы лезть в его исходники, чтобы исправить алгоритм, всё как в Larix.
Disconnect: его мы явно получаем от iOS только в случае, если принимающая сторона разорвала соединение или отвалилась сеть. Всё остальное время мы пытаемся держать связь и проталкивать данные. Не в последннюю очередь потому, что многие бэкенды стриминговых сервисов не любят разрыва соединений. И да, мы добавим позже опцию разрыва соединения при увеличении непрошедших данных.
При этом нельзя забывать и о проблемах, которые привносит сама iOS — они в последнних версиях ОСи имеют обыкновение копить буфер, если данные не шлются, и наш алгоритм просто не знает, что ушло, а что — нет. Чуть позже мы это попробуем переработать.
Кстати, а Android работа с сетью чуть лучше, там нет буфера, накапливаемого ОСью — и ABR в Лариксе работает бодрее. Хотя там пока нет гибридного решима, руки ещё не дошли.
Далее, publish vs. connect. Во-первых, снова бэкенд. Открытие соединения для большинства их сервисов — это, как правило, и есть начало вещания. Во-вторых, вы не сможете понять качество соединения, пока не начнете слать данные, причем именно видео (только оно даст аутентичную нагрузку). А это уже точно publish, без вариантов.
А для того, чтобы поправить прическу перед началом стрима, мы сделали режим stand by в свежей версии Larix Broadcaster для iOS. Можно начать вещание без звука и картинки, но с вашей заставкой или просто с черным экраном. Это как режим паузы, только пауза идёт перед основным стримом.
Отдельно хочу сказать про альтернативу RTMP — протокол SRT. Его точно стоит попробовать для вещания из мобильных сетей, т.к. он изначально создавался для передачи медиа по сетям без гарантированного качества доставки. Там, где из-за потерянных по RTMP пакетов пропадают ключевые кадры и рассыпается картинка, потоки SRT делают ретрансмиты и нормально доставляют поток. В общем, стоит на него посмотреть тоже.
Ещё две копейки:
У нас на этот случай сделан Larix Grove — формат раздачи настроек на девайсы через спецссылку и QR-код.
Для начала стрима, стримеру нужно зайти в админку, скопировать ссылку, а дальше в приложении LarixBroadcaster зайти в настройки соединений, и добавить эту ссылку. Стоит понимать, что стримеры это люди, которые не хотят лазить в настройки, предпочтительно нажать одну кнопку и стартовать стрим.
У нас на этот случай сделан Larix Grove — формат раздачи настроек на девайсы через спецссылку и QR-код.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Видео-стриминг на iOS по RTMP