LINUX.ORG.RU

Посоветуйте протокол

 , ,


0

1

Я всё дальше мусолю задачу стриминга по сети изображения с вебок/плат захвата с помощью одноплатника. Ресурсов мало, а ещё нужны маленькие задержки, поэтому так и не нашёл способа не пилить свои велосипеды. Сейчас у меня есть прога стриминга с V4L2 устройств, которая по-максимуму использует аппаратные энкодеры самих устройств захвата (если девайс умеет выдавать кадры в H264 всё совсем круто с битрейтом из коробки и нагрузка на проц минимальная, ибо только копирование, если девайс выдаёт MJPEG, то всё немного хуже - пришлось делать адаптивный алгоритм, который иногда пересылает неизменные кадры, а иногда пережимает существующие с большим сжатием, причём ещё и подбирая качество, чтобы более-менее соответствовать битрейту). А ещё многопоточность, да (то есть у меня одновременно несколько потоков теребят V4L2 устройство, параллельно пережимают JPEG-и, если надо, и только при отправке по сети есть небольшая синхронизация, чтобы фреймы шли в правильном порядке, выгода точно есть, ибо если создать только 1 поток, то всякие Orange Pi не тянут 30 fps пережатие JPEG, а с 2-4 потоками тянут).

ffmpeg не умеет в адаптивное пережатие (он может либо пережимать всегда, либо всегда копировать неизменный поток, а не выбирать действие в зависимости от того, насколько успешно справилась сама вебка с конкретным кадром, также не видел там подстройки качества сжатия JPEG для целевого битрейта, насколько я понял, такие функции доступны только для нормальных кодеков), mjpg-streamer не умеет пересылать неизменный H264 (а между тем если вебка его умеет, то это джекпот - битрейт даже на Full HD получается всего несколько мегабит и можно ничего не пережимать и просто копировать кадры из буферов сразу в сетевой сокет).

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

Посоветуйте сетевой протокол:

1) Должен уметь играться всякими VLC/MPlayer. Желательно, чтобы его поддерживал и стандартный класс MediaPlayer из Android SDK.

2) По нему должно быть можно посылать массив JPEG картинок, либо H264 поток (в рамках одного соединения формат сжатия не меняется, если начали слать JPEG, то всегда будем слать их, если H264, то всегда его).

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

★★★★★

ffmpeg не умеет

А взять libav не пробовал? Т.е. не сторонне использовать а в приложении и контролем всего и вся.

протокол

HTTP — все справятся.

deep-purple ★★★★★ ()

Плюсую RTSP/RTP.

Глянь, кстати, сюда:

http://www.live555.com/

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

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

ffmpeg/libav ей не нужен

Оно и понятно. Зачем транспорту глубокое знание о передаваемых данных? Он знает про пару меток в потоке, может что-то в блоках данных проверяет и этого достаточно.

deep-purple ★★★★★ ()