LINUX.ORG.RU

Какой лучший вариант ре-стрима rtsp на андроид/иос без перекодирования?

 ,


0

1

Сабж. Перед выпуском бесплатной версии софтинки хотелось бы отвязать трафик между клиентами и серверами от промежуточного (нашего) сервера.
Задача следующая:

  • есть rtsp потоки от камер
  • есть сервер который их собирает через ffmpeg и хранит в озу несколько фрагментов пакуя их в мп4, по нужде сливая их на диск
  • параллельно ffmpeg шлёт поток в nginx, который организует hls или dash (временный костыль для проверки - логичней формировать список самостоятельно для фрагментов из озу)
  • есть десктопный клиент который может напрямую подцеплять rtsp, выдергивать фрагменты с диска сервера через https в мп4 или выдергивать m3u/m4v который организовал nginx (последнее - на пробу)

Основной нюанс - это всё работает без транскодирования и соотв. не грузит процы, позволяя держать сервер на чахлом арме и иметь много камер (основное ограничение - пропускная способность дисков)

Собственно хотелка - организовать приложение под андроид, с возможностью смотреть камерки в живом времени с минимальным лагом.
С выгрузкой готовых мп4 проблем нет - exoplayer нормально принимает и распаковывает
Через dash то-же всё работает но лаг получается 5-6 секунд при крайне оптимистичных настройках (фрагменты по 3 секунды, 3 фрагмента в цикле, куски по 256кб)
На прямки rtsp ессно не работает, но как не странно не взлетело и rtp по tcp

Вопрос - как более оптимально завернуть rtsp в андроид (с прицелом на совместимость с ios) не разбивая это на куски, а нормальным потоком через tcp с общим лагом в 1-2 секунды?
Ну и по возможности прикрыть это шифровалкой встроенной дабы не городить велосипед

★★★★

ну ты конечно вопрос задал.

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

Мы в флюссонике разные методы используем, в зависимости от платформы: вебсокет, просто сокет и webrtc.

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

Мало того, что ты диски юзаешь, которые вообще для лайва нельзя грузить

ramfs

так ещё и фрагментный стриминг для лайва.

он просто уже реализован для не лайва, где он как-раз прям нужен :-)

вебсокет, просто сокет и webrtc.

главный цимус что надо без транскодинга, максимум аудио пережать с G в aac:

  • rtmp в exo с расширением тупо не работает, в низком разрешении бесконечно кэширует, в высоком тупо падает
  • rtsp в exo тупо не работает - падает в setup 401 хотя данные идут и авторизация проходит нормально, форки для старых версий правда пока не пробовал

webrtc пробую сейчас но надежды большой нет :-)

я чот надеялся что есть серебряная пуля чтоб сразу и ведроид и иос и вэб застрелить одним потоком :-)

rukez ★★★★
() автор топика
Ответ на: комментарий от rukez

оки, ffmpeg -> HLS с настройками -hls_list_size 2 -hls_time 3 даёт итоговые 3-4 секунды задержки в 1080p@6mbit между камерой и плеерами (ffplay@десктоп; exoplayer@ведроид; браузер@ios) без отключения буферов, что, будем считать приемлемо с учётом времени попутной обработки событий в 5 секунд
бонус приз - не нужен rtmp транслятор (и соотв. в моём случае nginx), достаточно раздавать обычный http(s)

rukez ★★★★
() автор топика
Ответ на: комментарий от rukez

я не очень понял термины, что именно такое «rtmp в exo с расширением тупо не работает» можно догадываться, но гадать не буду.

RTMP конечно не надо пользоваться никак, это прям харам.

Если exo — это exoplayer, то он прекрасно жует простой рабочеколхозный http mpegts, хотя со всеми минусами этой старой штуки.

Но для «посмотреть 10 секунд» сойдет.

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

rtmp в exo с расширением

exo = exoplayer
расширение = расширение для поддержки rtmp в exoplayer, не помню как точно называется

прекрасно жует простой рабочеколхозный http mpegts

битый на куски да, но с общей задержкой в 3-4 секунды

Но для «посмотреть 10 секунд» сойдет.

смотреть то надо долго, 10 секунд надо брать из буфера
логика простая - приходит событие, включается просмотр потока.
поток может быть либо начиная с события (и тогда лаг с реалтаймом важен) либо начиная с 10 секунд ДО наступления события (тогда лаг скорее в помощь, но эти данные один фиг лежат файлом в озу сервера)
учитывая что время генерации самого события лежит в пределах 1-5 секунд, лаг в 3-4 секунды допустим хотя и неприятен, начну пока так, потом может чего получше накостыляю

RTMP конечно не надо пользоваться никак, это прям харам.

почему? у нас отлично работает в продакшене, правда в продакшене есть закрытый туннель через промежуточный сервер, от которого сильно хотелось бы уйти ибо в проде клиент косвенно оплачивает все накладные, а в бесплатной версии всё пойдёт в убыток :-)

rukez ★★★★
() автор топика
Ответ на: комментарий от rukez

битый на куски да, но с общей задержкой в 3-4 секунды

вы путаете http mpegts и HLS и последнее сообщение явно относится к http mpegts.

Дальнейшее мне прям сложно в формате форума объяснять, потому что я даже не знаю с кем говорю и чего мы обсуждаем.

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

вы путаете http mpegts и HLS и последнее сообщение явно относится к http mpegts.

А как в чистый mpegts писать rtsp и одновременно его раздавать? Там же вроде итоговый объём данных нужен, не?
Я пробовал голый ts давно, с ffplay оно работало отлично, с libvlc через опу ибо она забирала файл кусками, но при отдаче именно запрошенных кусков регулярно сбивалась и падала (http сервер самописанный поверх jdk’шного)

rukez ★★★★
() автор топика

DASH

Немонстроузный web-проигрыватель бесконечного DASH потока с IP камеры.

На ведроидах и прочих иосах работает.

Если поток с камеры идёт в понятном мобильному броузеру формате, то перекодирование не нужно, оно просто режет на кусочки поток и выкладывает.

Stanson ★★★★★
()
Ответ на: комментарий от max_lapshin

принять rtsp, распаковать его до кадров, запаковать его в mpegts, пихнуть в http chunked

Так а клиенту как понять что chunk а) не последний б) сколько запрашивать chunk’ов в буфер если они короткие?
В стандартном кусковом хттп же в первом ответе указывается именно полный размер файла, который не определён для потока

DASH

Да! я в итоге почти пришёл к нему. Осталось только понять как одним процессом ffmpeg собирать два потока (с одной камеры с разным битрейтом) и сразу пихать их в один mpd - тогда получается мультибитрейт с нулевым транскодингом и мизерными (для лоуреза) накладными

rukez ★★★★
() автор топика
Ответ на: комментарий от rukez

как одним процессом ffmpeg собирать два потока (с одной камеры с разным битрейтом) и сразу пихать их в один mpd

успехов =)

Не будет работать мультибитрейт напрямую с камеры в деше.

В стандартном кусковом хттп же в первом ответе указывается именно полный размер файла

нет, посмотрите на transfer-encoding

max_lapshin ★★★★★
()
Ответ на: комментарий от max_lapshin

Не будет работать мультибитрейт напрямую с камеры в деше.

а какая разница перекодирует один входящий поток ffmpeg в два исходящих куска или кодер на камере сразу кодирует два потока а ffmpeg их собирает в два куска?

rukez ★★★★
() автор топика
Ответ на: комментарий от rukez

разница в размере гопов, таймстемпах кадров.

Деш очень хрупкий к разного размера гопам на разных качествах.

max_lapshin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.