EZ-WifiBroadcast DIY HD видео своими руками
Родизио писал о невозможности решить проблему с Датарейт. Опять же можно ещё регулировать через мощность передатчика.
Направленная антенна на самолёте наверное плохое решение. Для квадрика еще потянет. Хотя если использовать 5ГГц, то размер рефлектора будет приемлемым.
Можно и без вмешательства, антенным трекером. А для полётов вдаль две антенны вперед-назад.
Родизио писал о невозможности решить проблему с Датарейт.
Собственно, именно это и заставило меня смотреть в другую сторону. Ибо если негодна связка камера-модуль - малины можно выбрасывать. Pi3 + H264 USB Camera + WFBC tx == полный треш, похоже, не тянет USB (хард или софт - непонятно). Nano Pi neo в связке с той же камерой и адаптером дает вполне приличную картинку, надо только подкрутить параметры потока, ибо 14 Мбит/сек CBR многовато 😃
Nano Pi neo в связке с той же камерой и адаптером дает вполне приличную картинку
Значит ли это, что перейдя с классической Малины на этот компьютер на сборке WBC решаются проблемы с качеством видео?
Приёмная сторона в этом случае остаётся той же?
Есть ли у тебя в планах довести эту конфигурацию до законченного проекта?
User1321 created an image sometime back which worked with a IP camera pi camera.
If you contact him I’m sure he’ll share it with you. Here are a couple of his videos
на сборке WBC
Точно не на сборке WBC, тащить туда эту стройную систему костылей и подпорок я не буду. Совместимость с нижней частью я пока оставляю, дальше будет видно. Буду ли я доводить ЭТУ конфигурацию до законченного вида - пока не знаю, но какую-то - придется. Мой предыдущий пост был скорее про то, что малина относительно хороша только в связке со своей камерой и кодеком из-за простоты и доступности.
Может кому будет интересно: github.com/svpcom/wifibroadcast
Я написал свою версию wifibroadcast (из общего осталость только название). Из отличий:
- 1:1 отображение RTP потока в IEEE80211 пакеты для минимизации отклика (без сериализации в byte-stream как в оригинале)
- Более умный FEC
- Шифрование и контроль подлинности потока (libsodium)
- Распределенный сбор данных. Можно принимать данные с разных карточек на разных узлах и склеивать их вместе. Что снимает ограничение на пропускную способность USB2 шины и позволяет делать практически неограниченную diversity на приеме.
- Агрегация mavlink пакетов. То есть сбор их в пачку (в пределах временного окна или размера wifi пакета).
- Улучшенное OSD для Raspberry PI (потребляет не более 10% CPU на PI Zero)
Совместимо с любым разрешение экрана и поддерживет коррецию геометрии экрана.
github.com/svpcom/wifibroadcast/wiki
dev.px4.io/…/video_streaming_wifi_broadcast.html
Я написал свою версию wifibroadcast (из общего осталость только название). Из отличий:
Да-да, и MCS вместо OFDM ! 😉
Я написал свою версию wifibroadcast
Можно увидеть реализацию этого проекта? Как всё работает, примеры видео…
Опять всё на английском 😃
Готовые образы есть? Или всё собирается в Линуксе?
Мой setup выглядит примерно так: github.com/svpcom/wifibroadcast/…/Enhanced-setup
То есть 5 направленных антенн полукругом + одна всенаправленная на земле и одна всенаправленная в водухе.
Круговая поляризация. Настройки по умолчанию (ht-mcs-5 1 sgi-5 – QPSK 1/2 40MHz Short GI) дают канальную скорость до 30Мбит/с, куда h264 поток (1080p@30fps или 720p@49fps) + mavlink
отлично пролезают. Примеров видео нет (особого смысла сохранять видео на земле небыло), так как WFB это всего лишь транспорт для UDP пакетов и на качество видео не влияет.
Камеры использовались как Pi Camera + Pi Zero, так и USB камеры с аппаратным h264. Декодер видео на земле - pi zero (видео + osd).
Готовых образов нет (моя личная конфигурация довольно специфична и врядли подойдет для первого знакомства). Собрать образ довольно просто - инструкции и патчи к ядру в репозитории. Наример:
github.com/svpcom/wifibroadcast/issues/19 Собирается все в линуксе.
Можно увидеть реализацию этого проекта? Как всё работает, примеры видео…
Опять всё на английском 😃
Готовые образы есть? Или всё собирается в Линуксе?
фотку выложите интересно посмотреть на все это хозяйство.
- 1:1 отображение RTP потока в IEEE80211 пакеты для минимизации отклика (без сериализации в byte-stream как в оригинале)
Не совсем понял, а вот это
raspivid <....> | gst-launch-1.0 fdsrc ! h264parse ! rtph264pay ! udpsink host=127.0.0.1 port=5600
разве не та же самая сериализация, только c дополнительной оберткой в RTP ?
Направленная антенна на самолёте наверное плохое решение.
Yagi на 2.3 вполне компактная и плоская для расположении на крыле.
Приветствую. Потихоньку вхожу в тему. С малинками и камерами все более менее ясно - заказал. А вот с wifi - много противоречивой и не точной
информации.
Подскажите, какую дальность можно ориентировочно получить с wifi адаптерами на связке RT3070L + RTC6649E вроде этих:
ru.aliexpress.com/item/…/32863643206.html
ru.aliexpress.com/item/…/1734184546.html
Антенны - клевер в воздухе и хеликс на земле.
И подскажите, какой комплект адаптеров на 5 ггц даст дальность 3-4 км на высоте до 3-4 км. Антенны клевер или пагода в воздухе и хеликс или трипл патч на земле.
Эфир не загажен, на флайскае можно летать до 2.5-3 км в любую сторону.
разве не та же самая сериализация, только c дополнительной оберткой в RTP ?
Это как раз пакетизация стрима из камеры в пакеты rtp/udp.
Оригинальный WFB на вход получает pipe и читает из него по байтам и нарезает их в wifi пакеты не учитывая содержимого. h264 кодек имеет блочную структуру - то есть передает кусками (I, P и B фреймы). То есть для начала декодирования кадра он должен получить фрейм целиком. Если byte-stream режется на пакеты без учета этих данных, то вы получите дополнительное latency, так как кодек будет ждать очередного wifi пакета, чтобы завершить начатый фрейм. Для передачи видео по сети давно придуман и используется протокол RTP, который нарезает видео в поток udp пакетов с учетом структуры фреймов. Соответственно и передавать через wifi их нужно 1:1, чтобы прием/потеря одного wifi пакета приводила к приему/потере одного RTP пакета, а не к вырезанию куска данных в произвольном месте потока (или еще хуже вставки мусора, что делает оригинальный WFB, разрешает прием пакетов с битым CRC).
Не совсем понял, а вот это
raspivid <....> | gst-launch-1.0 fdsrc ! h264parse ! rtph264pay ! udpsink host=127.0.0.1 port=5600разве не та же самая сериализация, только c дополнительной оберткой в RTP ?
Подскажите, какую дальность можно ориентировочно получить с wifi адаптерами на связке RT3070L + RTC6649E вроде этих:
Сложно сказать. Для єтого нужно их попробовать. 3-4км с такими антеннами и такими вісотами - вообще не вопрос.
Только нужно что-то делать с аппой. Нужен ретранслятор. И понижать излучение аппы.
Мдя … вот что значит невнимательно читать … Я почему то был уверен, что радиоуправление тоже через этот линк работает, через уарты на воздушной и наземной стороне. Вроде впихнуть эти 128 kbit (или какой там поток у последовательных протоколов передачи sbus xbus ibus и т.д.) в этот поток 6-12 mbit не проблема …
Что ж, буду подбирать wifi адаптеры на 5.8 чтоб уйти от частоты 2.4 аппы. Большая дальность мне не нужна, 3((
А есть требования по классу к картам сд для малинок, или 6 класс пойдет? Есть две 4ГБ 6 класса.
Мдя … вот что значит невнимательно читать … Я почему то был уверен, что радиоуправление тоже через этот линк работает
Работает, не расстраивайся.
Но тогда нужно подумать о одинаковых передатчиках на земле и в воздухе, чтобы управление не отвалилось раньше видео.
Управление через этот линк пока ограничено 8-ю каналами.
Вот пример настройки через джойстик(аппу)
www.rcgroups.com/forums/showthread.php?2664393-EZ-…
А есть требования по классу к картам сд для малинок,
У меня 4 класса работали.
Другое дело, если на них видео писать.
Для передачи видео по сети давно придуман и используется протокол RTP, который нарезает видео в поток udp пакетов с учетом структуры фреймов.
Ясно, gstreamer использован как готовое и простое решение для парсинга потока и нарезания на кадры. Вопрос : а дополнительного overhead’а такая конструкция не создает ? Здесь gstreamer крутится еще одним параллельным процессом, плюс задействуется TCP/IP стек.
Судя по исходнику raspivid’а, он достает поток h264 из видеоподсистемы как раз по фреймам. Не даст ли выигрыша, если сразу в том же потоке отдавать их передатчику WFB, не задействуя ни pipes, ни TCP/IP ?
Для передачи видео по сети давно придуман и используется протокол RTP, который нарезает видео в поток udp пакетов с учетом структуры фреймов.
А нам-то RTP зачем ? Заголовки наверху добавлять, их передавать, внизу отрезать? Достаточно пакетизировать по границе NALU. И тут вариантов масса - и gstreamer, и raspivid с выводом в UDP, и еще масса способов.
И вообще, летали сегодня с USB-камерой, нанкой и 5 ГГц адаптером на 8812AU со встроенными антеннами и мощностью аж 18 dBm (ок. 60 мВт). Параллельно летал спарк от dji, дальность - 200-300м. Мы летим на 500 (дальность берется по 0 дропов), качество картинки ничуть не хуже (много разного народу смотрело и сравнивало). Ноут с писалкой был занят, посему кино нет.