Как стать автором
Обновить
105
0
Юрий Удовиченко @Aquary

softvelum.com

Отправить сообщение

Ясно, спасибо.

Мы пошли по способу реализации 2. А именно - сделали свой Larix Player для iOS и Android и предлагаем соответствующие платные SDK :)

Что касается протокола SRT - это отличная технология, мы её взяли в работу ещё в 2017, когда Хайвижен её заопенсорсил. Работает отлично в нестабильных сетях. Мы его применяем успешно в приложениях Larix Broadcaster, на сервере Nimble Streamer, ну и в Larix Player.

Про Pixel 6 не скажу, их ещё только начнут продавать, у самих руки чешутся попробовать.

Однако Pixel 5 умеет давать 60fps, один из диапазонов fps у камеры там как раз (60..60), если ничего не путаю. Пятый Пиксель вообще эталонный по части реализации фич последних Андроидов - например, там доступна concurrent camera (снимать с передней и задней камеры одновременно). Это мы в данный момент и допиливаем у себя, скоро зарелизим. Собственно, ради этой эталонности в фичасете мы Pixel 5 и покупали прямиком из Японии - тут у нас рядом, а в России его просто не продавали.

Большое спасибо за статью от всего коллектива разработчиков Larix Broadcaster :) Не так давно опубликовали статью с советами про мобильное живое вещание, где вскользь коснулись части проблем, которые вы описываете здесь, с точки зрения пользователя. Однако вы отлично разложили с максимальными подробностями с точки зрения разработчика.

Зоопарк устройств Андроида действительно создает проблемы не столько наличием разнообразия, сколько тем, что каждый трактует спеки Гугла на свой лад и просто не открывает возможности сторонним разработчикам.

У нас один из самых частых вопросов, например, про 60FPS и про то, почему мы не поддерживаем его на устройствах. "Ведь в нативном приложении всё работает!" Непросто объяснить, что не мы такие, платформа вендора такая.

Отдельная песня - работа с источником изображения, идущего со стороннего устройства по USB. Только на Андроиде 10 появилось что-то в АПИ, однако, по традиции, вендоры не стали утруждать себя поддержкой и всё работает как у прежде - то есть почти не работает. Пришлось писать disclaimer по этому поводу.

В общем, спасибо за статью, будем рады увидеть и другие материалы на эту же тему.

Настройки энкодера (key frame interval, например), размер буфера энкодера, величина чанков, размер буфера плеера и отставание при проигрывании — взаимосвязанные вещи, но это не одно и то же. Картинка может страдать от проблем с потерей пакетов, и чем больше буфер, тем проще это митигиролвать. 20 секунд — да, это большая задержка, но таков формат HLS. Нужно больше интерактива — да, можно взять WebRTC, или технологии вроде нашего SLDP для доставки с низкой задежки.
WebRTC — отличная технология, но она — не панацея для всех юзкейсов, как и LL DASH.
Ещё две копейки:
Для начала стрима, стримеру нужно зайти в админку, скопировать ссылку, а дальше в приложении LarixBroadcaster зайти в настройки соединений, и добавить эту ссылку. Стоит понимать, что стримеры это люди, которые не хотят лазить в настройки, предпочтительно нажать одну кнопку и стартовать стрим.

У нас на этот случай сделан Larix Grove — формат раздачи настроек на девайсы через спецссылку и QR-код.
WebRTC очень хорош для видеозвонков, чатов, отдачи потока из браузера, но в данном случае юзкейс — это вещание «в одну сторону», задержка там важна не настолько, как возможность сформировать хорошую картинку с мобильного устройства (на них сейчас камеры приближаются по качеству к профессиональным) и раздать её большому числу зрителей (на самых разных устройствах).

Поэтому пайплайн автора — на базе RTMP с отдачей в облако и раздачей по HLS — отлично отработанный подход, я бы даже сказал — классика.
LL HLS пока ещё на ранней стадии. Его на проигрывание поддерживает только платформы от Apple плюс THEO Player. На стороне серверов и сервисов оно только начинает добавляться.

У нас LL HLS реализован в Nimble Streamer, а большинство вендоров к нему только присматриваются — технология не самая тривиальная в реализации.
Добрейшего дня. Спасибо за статью, вопросы подняты интересные и правильные, есть что обсудить.

По поводу изменения разрешения. Если коротко — думали над этим, всё сводится к бэкенду, никто на том конце провода не любит изменение разрешения, переподключения и прочее подобное. Основные стримиговые сервисы максимально ужесточают требования по входу, чтобы проще было работать. Кто делает кастомные разработки, уже могут позволить себе более интенсивные упражнения для улучшения 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 делают ретрансмиты и нормально доставляют поток. В общем, стоит на него посмотреть тоже.
Они самые.
Ну мы работали только через command line, нам UX был неведом :) На момент, когда мы его начали использовать, git-ом даже близко не пахло и для своего времени ClearCase был очень продвинут. Сама концепция config spec сильно недооценена до сих пор.
Автор забыл упомянуть о таких промышленных монстрах как ClearCase и Perforce. Довелось с ними работать несколько лет — очень мощные инструменты для работы больших команд, со своими плюсами и минусами.

Советую также посмотреть мои статьи на Хабре про управление версиями и конфигурацией
habr.com/ru/post/67751
habr.com/ru/post/67839
habr.com/ru/post/68932
habr.com/ru/post/72370
Кстати, вот пара недавних статьей про состояние AV1: номер 1 и далее номер 2.

Отличная цитата:
However, encoding time for AV1 was five hours per second at that resolution. Yes, you read that correctly, five hours per second.

Состав участников Альянса — это единственное, что даёт хоть какую-то уверенность в его будущем. Осталось подождать лет 5, а пока — будем использовать проверенный H.264/AVC :)
В теории это будет отличный кодек. На практике в данный момент есть ряд сложностей.

1. > Формат AV1 свободен от любых роялти и всегда останется таковым
Игроки рынка высказывают сомнения — есть веротность, что будут задеты патенты из пулов MPEG-LA. Когда кодек выйдет в массы, мы ещё увидим судебные иски по этому поводу

2. Кодирование AV1 будет процессом очень ресурсоемким. Значит, на стороне энкодеров потребуется новое поколение железа, которое будет уметь его кодировать. Представителя AOM говорят, что реализации «в кремнии» мы увидим в лучшем случае через пару лет. О софтовой реализацию можно пока только мечтать. Причем если для VOD он уже вроде как есть в прототипе, то для живого транскодинга его даже в планах пока, вероятно, нет.

3. Поддержка на декодирование. Аналогично пункту 2 — нужна поддержка на платформах пользователей — iOS и Android.

В общем, у AV1 будут те же детские болезни, что были и пока ещё есть у HEVC/H.265. Только HEVC уже постепенно начинает поддерживаться на разном железе. Также постепенно обустраивается его правовой статус, хотя тоже с оговорками — есть 2 патентных пула и масса независимых держателей патентов, что откладывает проблемы патентной чистоты на будущее. Как с этими же болячками будет обстоять дело у AV1 — вопрос пока широко открытый.
В случае живых потоков исходные данные «ближе», т.к. идёт преобразование на первом энкодере от камеры и дальше — нередко уже только транскодер для работы на конечную аудиторию.
При нашем тестировании подобного эффекта не обнаружилось.
Нужно разбираться в конкретном случае с конкретным чипом и ещё лучше конкретной картой, смотреть настройки. Ну и пробовать на картах разного уровня, чтобы понять, что подойдёт для конкретной задачи.
У таких карт производительность всё-таки значительно меньше и, кроме того, есть ограничение на число кодируемых потоков. Так что если нужно кодировать много — выгоднее будет взять «большую» карту.
По поводу хостеров. Во-первых, они ориентируются на разные классы задач, не только живое видео. Там и транскодинг VOD, и всякие приложения и сервисы с супер-фильтрами (типа Prism), и чисто математические задачи вроде обсчёта блокчейна.
Во-вторых, бывают случаи, когда с помощью поломаных драйверов обходится ограничение на одновременное число кодируемых потоков — так его можно немного увеличить. Мы слишком серьёзно относимся к вопросам лицензирования (вот здесь написано всё по этому поводу), чтобы воспринимать всерьёз такой подход.
В этом случае обычная карта вам наверняка подойдёт. Возможно даже вам она будет не нужна и справитесь только с помощью CPU. Надо проверять, теория тут плохой помощник.
Я могу отвечать только за то, что сделано конкретно нами :) Проблемы других приложений я не могу комментировать. Конкретно у нас артефактов иображения не было, мы это проверяли.

Информация

В рейтинге
Не участвует
Откуда
Бишкек, Кыргызстан, Кыргызстан
Дата рождения
Зарегистрирован
Активность