EZ-WifiBroadcast DIY HD видео своими руками
Но увы
Вот и сидите молча. 😃 И ждите, пока умные сделают и быть может поделятся.
Тем более что на моем веку были собранные мной специализироыанные дистры для медиабоксов
Ну а во всей этой бодяге ничего другого и не надо, софт весь написан, осталось собрать под нужный камень, написать тот самый скрипт на sh и запаковать в соответствии.
Вот и сидите молча. 😃 И ждите, пока умные сделают и быть может поделятся.
Ясно, я не ошибся в вас, и вашей ролью в этой теме. 😉
Подскажите, с Runcam split 2 можно вывести HD на данные передатчики?
я не ошибся в вас
Я очень редко разочаровываю ожидания определённой части публики…
Подскажите
Вполне.
RunCam по WiFi передаёт картинку, Малинка её по WiFi ловит, обрабатывает и отправляет на землю. 😃
Ну не знаю как RunCam, а вот например Xiaomi Yi выдавал через wifi картинку с жутким лагом (около секунды вроде).
Плюс он будет забивать эфир (в диапазоне 2.4 всего 3 непересекающихся частотных канала). Придется ставить usb hub (если нет встроенного) и ставить еще один wifi свисток на прием этого потока. Ну и у семейства RPI usb шина довольно тормозная.
RunCam по WiFi передаёт картинку, Малинка её по WiFi ловит, обрабатывает и отправляет на землю.
Плюс он будет забивать эфир
А самое главное - к обсуждаемому здесь проекту все это не имеет ни малейшего отношения 😦
А самое главное
А шо, здесь разве не марксистский творческий кружок по интересам?!
А вундервафли заведомо адски тормозящие предлагать - это внеклассная работа? 😃)
Вопрос знатокам задает мальчик Леша из Москвы: недостаток 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? Есть же этих камер, как цветов за баней…