EZ-WifiBroadcast DIY HD видео своими руками
А самое главное
А шо, здесь разве не марксистский творческий кружок по интересам?!
А вундервафли заведомо адски тормозящие предлагать - это внеклассная работа? 😃)
Вопрос знатокам задает мальчик Леша из Москвы: недостаток FEC-пакетов абсолютно фатален для восстановления блока или есть какие-то нюансы?
И да, в коде wifibroadcast присутствует почти в 100% случаев задержка на 1 кадр, а это от 16 до 33 мс.
Если это стандартный Рид-Соломон (n, k), то можно потерять любые n - k пакетов и декодировать блок. В данном случае можно потерять все fec пакеты так как их как раз n - k.
За ez-wifibroadcast не скажу, но я у меня кодируются так: k пакетов с данными и следом n - k с FEC’ом.
Вопрос знатокам задает мальчик Леша из Москвы: недостаток FEC-пакетов 100% фатален для восстановления блока или есть какие-то нюансы?
Ну вот поэтом я и написал свою реализацию 😃
У меня если пакеты идут без дырок, то они сразу отправляются на выход. А конца блока дожидается если только кто-то по пути потерялся.
И да, в коде wifibroadcast присутствует почти в 100% случаев задержка на 1 кадр, а это от 16 до 33 мс.
Я как бы про Рида с Соломоном слышал. Просто в случае wifibroadcast используются и битые (с плохим crc) fec-пакеты в том числе, что меня смутило. Про задержку: передатчик ждет заполния входного буфера и в случае конца кадра не на его границе будет ждать начала следующего (те самые 1000/fps мсек).
Как уже говорилось - оригинальный wifibroadcast имеет кучу спорных решений в своей архитектуре. Зачем получать битые пакеты и в потом пихать их в FEC (если fec всеравно починит блок если есть k пакетов), а вот проблем с целым блоком мусора (если получено ровно k пакетов и один из них битый) оно доставит. Равно как и шифровать такой поток не имеет смысла.
Про задержки: если получать на вход не byte-stream, а udp пакеты, при передаче пакет сразу уходит в эфир без задержек. При приеме пакета, входящего в блок FEC, его можно сразу же передать видео кодеку не дожидаясь конца блока, если до него (с начала блока) были получены все предыдущие пакеты. Так что тут задержка будет не нулевой, если только произошла потеря пакетов в блоке.
Я как бы про Рида с Соломоном слышал. Просто в случае wifibroadcast используются и битые (с плохим crc) fec-пакеты в том числе, что меня смутило. Про задержку: передатчик ждет заполния входного буфера и в случае конца кадра не на его границе будет ждать начала следующего (те самые 1000/fps мсек).
имеет кучу спорных решений в своей архитектуре
Там куча костылей, написанных ногами, а не спорных архитектурных решений.
Зачем получать битые пакеты
Ну, принять все пакеты ты обязан и никак по другому. В оригинальном коде (даже не бортека, а бенефитива) в случае необходимости коррекции используются fec-и с невалидной CRC. Какой в этом смысл - я не понимаю.
Использование UDP - на любителя, можно захватывать кадр через V4L и оперировать уже им, но необходимость ухода от потока к кадрам - факт.
но необходимость ухода от потока к кадрам - факт.
Надо порыться в доках и откопать спеку на патент Siemens - у них было очень интересное предложение по передаче опорных кадров.
Чё отрезали?
thepihut.com/…/raspberry-pi-3-model-a-plus?mc_cid=…
За такую цену (еще и за доставку возьмут столько же) и с такими характеристиками у него покупателей не будет:
- 512 памяти
- нет 64bit режима (привет video core iv)
- одна убогая usb шина
- один уарт
Семейство allwinner H5 его рвет как тузик грелку
Чё отрезали?
thepihut.com/…/raspberry-pi-3-model-a-plus?mc_cid=…
- одна убогая usb шина
Да, вот если бы хотя бы две - на борт вместо Зеро хорошая альтернатива.
А доставка из Англии совсем недорогая, я Зеро там покупаю.
Если бы у бабушки был ***, то она была бы дедушкой 😃
А если по теме, то я для себя решил, что теперь только usb h264 камера (курокеса например) и нормальный арм типа nanopi neo2. И никакого больше гемороя с малинами
Да, вот если бы хотя бы две - на борт вместо Зеро хорошая альтернатива. А доставка из Англии совсем недорогая, я Зеро там покупаю.
К сожалению твоё решение только для тебя 😃
только usb h264 камера
А почему тогда не GigE? Есть же этих камер, как цветов за баней…
Ну почему только для меня? 😃 Код под GPLv3 и работает с любым mavlink-совместимым автопилотом и камерами, которые понимает gstreamer.
Документации, конечно не так много (dev.px4.io/…/video_streaming_wifi_broadcast.html и wiki на гитхабе), но pull requests с дополнениями are welcome 😃
К сожалению твоё решение только для тебя 😃
Можно и их. Только они обычно тяжелые для пенопластовых самолетов. Плюс надо править их прошивку чтобы выдавать RTP с минимальными задержками
А почему тогда не GigE? Есть же этих камер, как цветов за баней…
Никто случаем не сталкивался с тем, что AWUS1900 (RTL8814AU) теряет пакеты при слишком сильном сигнале?
Я сталкивался на исходном WFB 15-го года, с Ubiquity WifiStation. Заворачивал приемник в фольгу.
Особенно контроллер матрицы 😃
Тут чуть другой подход. Поскольку в городской парк на машине не въедешь, то задачей было убрать в этот ящик вообще все, что нужно на поле. Добавится ещё штатив и антенная мачта.
А почему тогда не GigE? Есть же этих камер, как цветов за баней…
Потому что IP-камера - это с вероятностью 99% RTSP с его неустранимой задержкой на хендшейке и старте потока плюс два никому не нужных IP-стека. Да и гигабит для наших целей - перебор, там от силы десяток мегабит всего потока, обычной сотки за глаза.
Не, GiE это немного другое - это такой стандарт для промышленных камер (проприетарный кстати). Там внутри может быть что угодно (как раз этим стандартом и описывается - от raw, jpeg, mjpeg до h264). Вроде как есть github.com/AravisProject/aravis и даже какая-то поддержка gstreamer. Но я эти камеры в руках не держал (они большие и оочень дорогие) и мой ответ сугубо теоретический.
Потому что IP-камера - это с вероятностью 99% RTSP с его неустранимой задержкой на хендшейке и старте потока плюс два никому не нужных IP-стека. Да и гигабит для наших целей - перебор, там от силы десяток мегабит всего потока, обычной сотки за глаза.