LINUX.ORG.RU

Передача видео по сети с низкой задержкой

 , , ,


2

3

Имеется вебкамера, одноплатник orange pi (сначала был raspberry pi, но один аппаратный USB на всё приводит к куче проблем) и wifi-свисток. Требуется передавать видео 640х480 30fps на смартфон под управлением ОС Android. Важный момент - минимальная задержка (не больше 200 миллисекунд), пока это физически возможно (потом можно терять кадры). Со стороны одноплатника может быть как стандартное ПО (какой-нибудь ffmpeg), так и самописное, со стороны Android самописное (передача видео не единственная функция), но, конечно же, можно использовать библиотеки.

В какую сторону копать?

Пока сделал свой велосипед - захватываю кадры с камеры с помощью V4L2, жму с помощью libjpeg-turbo, разбиваю на части по несколько сотен байт, шлю по UDP (при этом шлю куски JPEG по мере их появления по мере сжатия). С другого конца принимаю пакеты, собираю JPEG (в каждом пакете передаётся его порядковый номер, полный размер JPEG и смещение - каждый кадр собирается в независимом буфере, как только собирается целый кадр, он отображается, а все несобранные кадры с меньшим порядковым номером отбрасываются и в будущем игнорируются), распаковываю и вывожу через OpenGL.

Между одноплатником и ноутбуком работает отлично и задержка низкая. А вот между одноплатником и смартфоном работает очень нестабильно. Изредка бывает 30fps, но обычно чуть ли не половина кадров теряется. Пробовал как подключать одноплатник и смартфон к готовой точке доступа (и даже подключать одноплатник к точке доступа по кабелю), так и делать точку доступа из одноплатника. Смартфон спокойно играет через Интернет Full HD YouTube, так что ресурсов у него и сети хватает (конечно, YouTube пожат лучше, чем JPEG, но сильно большее разрешение компенсирует и битрейт должен быть не меньше).

Почему JPEG? Потому что я наученный горьким опытом сжатия видео на одноплатников - это единственный известный мне «кодек», который приемлемо грузит ARM-одноплатники. На всё остальное просто не хватает ресурсов на сжатие.

Как измеряю задержку? Навожу вебку на запущенный секундомер, фотографирую всё это хозяйство другим девайсом так, чтобы в кадре одновременно был экран с видео и реальный секундомер. Смотрю на разницу в показаниях на фоточке.

Я не прошу готового решения, только направление.

★★★★★

А мерял сколько времени уходит на подготовку, отправку и прием одного кадра? Понатыкай мерялки, посмотри на авераж. Может всплывёт где именно засада. И почему UDP?

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

Мерил, всё хорошо. Сжатие и отправка в user space отнимает менее 50 мс. Смартфон по идее мощнее одноплатника (Snapdragon 820), так что разжатие точно должно быть не медленнее. К тому же потери кадров имеют сильно переменный характер, что говорит, что всё упирается в радиоканал. Возможно, я его неправильно использую.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от KivApple

Сколько времени проходит между отправкой и приёмом?

разжатие точно должно быть не медленнее

Вот когда померяешь, тогда и утверждай.

сильно переменный характер

UDP же, там и от пука рыбки в аквариуме может зависеть.

Ну допустим радио канал. Может быть засран этот диапазон. Надо бы посмотреть. Поставь другой, но, в многоквартирном улье они могут быть все засраны.

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

deep-purple ★★★★★
()

Почему JPEG? Потому что я наученный горьким опытом сжатия видео на одноплатников - это единственный известный мне «кодек», который приемлемо грузит ARM-одноплатники. На всё остальное просто не хватает ресурсов на сжатие.

ffmpeg -c:v libx264 -preset ultrafast -tune zerolatency не вытягивает?

Singularity ★★★★★
()

SO_TIMESTAMPING + libpcap для замеров можно, только не уверен насчёт того сумеет ли в такое андроид. В любом случае твой метод крайне не точен.

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

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

А задержка при использовании TCP не будет выше и при неблагоприятном раскладе накапливаться?

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

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

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

Как я буду отбрасывать кадры в TCP? Там же гарантированная доставка и порядок следования. Там уже нечего отбрасывать.

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

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

deep-purple ★★★★★
()
Ответ на: комментарий от anonymous

Зато у неё нет двух 2 USB портов (при этом сеть тоже висит на USB). Всё через хаб. А моей задаче требуется одновременная нагрузка на сеть и на USB-вебкамеру. В итоге всё глючит и в конце-концов рушится.

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

Попробовал на ноутбуке. Так оно мой Core i7 нагружает на 50%, какой одноплатник тут...

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

поэтому вы вместо частичной загрузки этого пути потоком h264, грузите полными картинками jpg

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

Так от вебки вообще YUV без сжатия кадры идут (она не умеет MJPEG). На их фоне хоть h264, хоть mjpeg особой погоды не делает. Предполагаю, что у вебки просто нет нормальных внутренних буферов и поэтому она плохо делит пропоскную полосу с другими девайсами.

KivApple ★★★★★
() автор топика
Ответ на: комментарий от deep-purple

Интересно, померил iperf скорость передачи от ноута к смартфону. По TCP 58 МБит/сек, по UDP 1.05 МБит/сек. Почему такая большая разница? Казалось бы эфир один, у TCP тоже должны быть потери пакетов и перепосылки. Где почитать какую-нибудь теорию на этот счёт?

«UDP создан специально для риалтаймовых приложений и минимальных задержек», говорили они...

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от Anoxemian

У меня только 1 девайс с Ethernet. Можно спойлер? И вообще, где можно про это почитать подробнее, чтобы в будущем не допускать ошибок?

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

Однозначно сложно сказать. Почти всегда проблема в udp over wifi - размер datagram относительно буферов. Скорее всего у тебя дикая фрагментация и соответствующий data loss. Фиксить или переходить на tcp - тебе решать.

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

Нет, я не в курсе где читать. Вскользь замечал что да, UDP оказался швахом в современном мире вифи и тыдытыпы. Не знаю как там пацаны в КС рубятся с такими задержками, но это у игроделов там видимо всё уже обкатано и пофикшено.

deep-purple ★★★★★
()
Ответ на: комментарий от KivApple

видимо я плохо объясняю, один поток h264 занимает меньше полосы в сеть, чем ваши полные картинки jpeg, почему думаю объяснять не надо
вообще вы пытаетесь решать проблемы которые уже в voip уже давно решены, h264,packetizaton,rtp,nack как минимум

anonymous
()
Ответ на: комментарий от Harald

не потеряли в одном, потеряли в другом, или теряем на цпу или теряем на доставке по сети
но у rpi есть аппаратный кодек как я помню, может разве что в не в каждой ревизии

anonymous
()
Ответ на: комментарий от Harald

На самом деле у меня не вебка, а китайская плата видеозахвата аналогового сигнала. И если я её и могу заменить, то только на что-то аналогичное по функционалу. А она умеет исключительно выдавать несжатые кадры в YUYV.

KivApple ★★★★★
() автор топика
Последнее исправление: KivApple (всего исправлений: 1)
Ответ на: комментарий от anonymous

Я на dir320 с openwrt гонял онлайн видео, без ощутимой задержки, а тут целая мощный одноплатник.

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

В iperf для UDP чтоб нормальные тесты получить ЕМНИП надо буфер крутить самому, потому что в отличие от TCP тут не завезли «скользящее окно»

Pinkbyte ★★★★★
()

всё равно попробуй ffmpeg и какой-нибудь кодек с настройками малой нагрузки на CPU, в реалтайм режиме

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