EZ-WifiBroadcast DIY HD видео своими руками
Я пробовал заставить xiaomi yi отдавать видео через usb. Без sdk это сделать не получается. В линуксе там невозможно сделать даже usbnet.
Это потому, наверное, что в Амбрелла ковырять нужно rtOS,. Там rtOS всем этим заведует, а на линукс только вебморда вращается и остальное по мелочи.
Да, с опен морсом я погорячился. Кинулся искать и не нашел.
У всех камер на Амбрелла есть потоковое видео по вифи. Может есть вариант его принять на один свисток, а вторым снова в эфир отправить, в таком же режиме как сабж темы делает?
Очень уж мне сабж интересен, но с пи камерой интерес уходит в ноль. Мне хорошая съёмочная камера нужна в 4К желательно.
А Hisilicon? Разве там не опенсорс?
_______
Не заметил пост Лелика.
Очень уж мне сабж интересен, но с пи камерой интерес уходит в ноль.
Никто єтим заниматься не будет.
И что получилось?
Как у них с латентностью видео?
Как там сделан автофокус для варифокальных объективов (в примерах SDK я не нашел)?
Посмотрел я их SDK (sourceforge.net/projects/hisi/files/SDK/Hi3516/). Ядро там к сожалению старое (3.4) - придется сильно патчить wifi-стек либо использовать только как камеру.
Про USB-OTG (чтобы подключить к другой машине через usbnet) я в документации не увидел. Остается только ethernet (4 провода + 2 питания) для соединения с внешним миром.
Если напрямую в камере цеплять wifi карту (там вроде есть usb host), то наверное будет работать, но проводов (с учетом телеметрии и RC-out) нужно будет вести целый жгут (для стационарной камеры подойдет, а для карданного подвеса уже многовато)
Oops, я его даже не глядел. Попробую сегодня.
Я ковырялся в прошивке IP-камеры на Hi3516, это arm, тулчейн к нему есть, спеки есть, открытый SDK с примерами использования энкодера есть. На плате разведено все, что надо - uart для телеметрии, usb для свистка. Простор для творчества.
Ну если цель снимать на флешку внутри камеры, то подойдет любая (хоть зеркалка) с avout или hdmi + конвертер в h264 (бывают, правда я не видел сильно компактных).
Ну а если надо гнать видео на землю в realtime, то тут без вариантов - надо делать свою камеру. Но это уже требует не любительских бюджетов.
Очень уж мне сабж интересен, но с пи камерой интерес уходит в ноль. Мне хорошая съёмочная камера нужна в 4К желательно.
И что получилось?
Да ничего пока не получилось. Прицепил uart, увидел u-boot, отложил на долгие зимние вечера (да и то если будет нужда).
Я пробовал заставить xiaomi yi отдавать видео через usb. Без sdk это сделать не получается. В линуксе там невозможно сделать даже usbnet.
Хорошо, а как на счёт novatek?www.goprawn.com/forum/…/2878-novatek-sdk
Хорошо, а как на счёт novatek?
Займитесь, сделайте, опубликуйте результаты. В чём проблема?
Займитесь, сделайте, опубликуйте результаты. В чём проблема?
А вы, батенька, смотрю так по теме, местный тролль?
Был бы я программистом, так бы и сделал. Тем более что на моем веку были собранные мной специализироыанные дистры для медиабоксов. Но увы, мое программирование заканчивается на простенький скрипт для sh, или ардуинкой светодиоды позажигать (утрирую конечно, но реальность не далека).
Но увы
Вот и сидите молча. 😃 И ждите, пока умные сделают и быть может поделятся.
Тем более что на моем веку были собранные мной специализироыанные дистры для медиабоксов
Ну а во всей этой бодяге ничего другого и не надо, софт весь написан, осталось собрать под нужный камень, написать тот самый скрипт на 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 мсек).