Беспроводная передача видео в full HD
Была пьяная идея на грани бреда - каким-то макаром слать видео в вайфайный эфир в open mode без фактического коннекта, а на земле снифать и вычленять видеопоток. Но как такое опробовать пока не придумал. Видимо, на следующей пьянке придумаем 😃
Ну самое просто маркировать пакеты.
Но как такое опробовать пока не придумал. Видимо, на следующей пьянке придумаем 😃
Если всё так просто, то готов предложить подходящие напитки 😃
На сколько человек надо накрыть стол?
Если вес не критичен то может быть лучше использовать этот конвертор HDMI-AV, на борту, и получим на земле картинку лучше чем AV-AV?
В теме про Хэды я описывал качество SD-видео, в т.ч. и от GoPro:
Поключал GoPro 3 Silver, KX-6 и Pixim. Получилось, что в качестве курсовой GoPro проигрывает … из-за картинки, которая без встроенных в аналоговые камеры подогнанных для работы в SD “улучшайзеров”, выглядит “мутновато”.
На мой взгляд, если Вам нужны HD-записи полётов, то есть смысл бороться с GoPro. А в качестве FPV-курсовой лучше себя показала аналоговая камера…
Если всё так просто, то готов предложить подходящие напитки 😃
На сколько человек надо накрыть стол?
Кстати да, для мозгового штурма чем больше народу тем лучше 😄 Тут бывают RCшные пьянки форумные на природе??? Я не алкаш, не подумайте, просто реально многие интересные штуки придумываются именно когда языки развязываются и фильтры в мозгах отключаются. Виртурилку мы именно так и придумали (малины ещё и в помине не было), а в итоге вон, тираж уж на подходе 😃
(Виртурилка, может быть слышали)
Слышали. Очень интересная железка.
А вы не думали для передачи цифрового видео вместо WiFi задействовать обычные видеопередатчики ? Ему же без разницы, что именно гнать - главное, чтобы амплитуда была до 1 вольта. Навскидку - 4 бита цифрового потока преобразуем в точку с 16 различными уровнями яркости. Выдаем все это на видеовыход и передаем на землю через обычный видеолинк. На земле второй вашей же платой этот сигнал демодулируем (на DSP же есть видеовход с АЦП ?), декодируем H.264 и выдаем на, например, HDMI. Если считать, что полоса видеолинка 6 МГц - получается 24 МБ/с. Если получится - покупатель на 2 платы у вас точно есть 😃
Слышали. Очень интересная железка.
Спасибо 😃
А вы не думали для передачи цифрового видео вместо WiFi задействовать обычные видеопередатчики ? Ему же без разницы, что именно гнать - главное, чтобы амплитуда была до 1 вольта. Навскидку - 4 бита цифрового потока преобразуем в точку с 16 различными уровнями яркости. Выдаем все это на видеовыход и передаем на землю через обычный видеолинк. На земле второй вашей же платой этот сигнал демодулируем (на DSP же есть видеовход с АЦП ?), декодируем H.264 и выдаем на, например, HDMI. Если считать, что полоса видеолинка 6 МГц - получается 24 МБ/с. Если получится - покупатель на 2 платы у вас точно есть 😃
Эхх, это ооочень насущный вопрос. Думали. Я тут всю ветку проштудировал, много интересного почерпнул. Но у нас в команде нет радистов, т.е. людей шарящих именно в эфирном вопросе. Передатчики, приёмники и т.д. для нас пока неизведанная область. Так что если кто-то в этом разбирается - готовы плотно сотрудничать.
Навскидку - 4 бита цифрового потока преобразуем в точку с 16 различными уровнями яркости.
Ну, я примерно о том же, но не так детально… Только с учётом помех, мне кажется, надо будет передавать сигнал избыточно, и останется максимум 4Мб/с - но для 720р этого вполне достаточно…
Бухать, к сожалению, не смогу в МСК приехать, но пару плат с такими возможностями - то же закажу 😉 …
для передачи цифрового видео вместо WiFi задействовать обычные видеопередатчики ?
А в чем смысл? Физические параметры радиотрактов аналогового видео и WiFi одинаковы. Чувствительность приемников и мощность передатчикв сопоставимы. И там и там полоса 20 МГц. Просто контроллеры Wifi автоматически кодируют и декодируют цифру в QAM16 или выше, а так Ваш процессор будет этим заниматься. Я так-же не уверен, что QAM кодирование и детектирование (типа детектора Виттерби) на таких скоростях доступна программно даже приличным DSP-шкам.
То есть больший поток данных чем дает WiFi, Вы на видео не получите, а все остальные проблеммы абсолютно те-же.
- Как передать картинку в H264 с минимальной задержкой?
- Как обеспечивать восстановление данных при однонаправленном канале с помехами?
- Как не терять всю картинку при частичном разрушении потока?
Александр, принимайте участие в брейнсторрме, причём лучше ответами 😉
принимайте участие в брейнсторрме,
В смысле в пьянке чтоль? 😃 Легко, только нужно будет кому-то все на видео писать, иначе никто ничего не вспомнит. 😃
причём лучше ответами
Отетов у меня нет, только совет: нужно алгоритм сжатия изобретать и затачивать под возможности канала связи, а не наоборот.
нужно алгоритм сжатия изобретать
Я столько физически не выпью
больший поток данных чем дает WiFi, Вы на видео не получите
Так не в этом и цель. Мы и на меньший согласны, но что бы можно было через привычный радиоканал слать…
Как передать картинку в H264 с минимальной задержкой?
Если я правильно понял, сейчас пара Виртурилок по WiFi дают задержку 0,2-0,3 секунды, причём какую-то задержку сюда вносит ещё и сам WiFi, т.к. пытается передать всё без потерь. А если удастся получить 0,2сек. и хотя бы 720р - то это уже закроет весьма весомую часть задачь.
…а вот что с остальным - не знаю 😦 …
А в чем смысл?
Нет накладных расходов на TCP/IP и сам протокол WiFi (кстати, он полудуплексный, при том, что обратный канал нам не нужен), т.е. минимизируем задержку. Имеем возможности играть с модуляцией, разменивая полосу на сигнал-шум. Имеем фиксированную скорость передачи, что исключает эффекты, если WiFi захочется скорость поменять. Применяем любые частоты вместо 2.4, давая возможность применять любые пульты, а не только LRS на 433.
Задержка здесь будет определяться только кодером и декодером H.264, поскольку затраты на модуляцию/демодуляцию смехотворны. Восстановление не нужно, просто выбрасываем битый кадр. Для того, чтобы не терять картинку из-за шумов, можно попробовать применять кодирование по Хеммингу, где за счет избыточности допустимо искажение в каких-то пределах. Но на первом этапе это необязательно.
Т.е. тут развязаны руки по сравнению с WiFi.
Но у нас в команде нет радистов, т.е. людей шарящих именно в эфирном вопросе. Передатчики, приёмники и т.д. для нас пока неизведанная область.
А тут и не надо. Передатчик-приемник работают из коробки. Если две ваших платы смогут передать цифровой сигнал по видеокабелю, с видеовыхода на видеовход - это будет уже гигантским шагом и две платы я тут же закажу.
Из того, что я не знаю про DSP, можно написать неплохой учебник 😃 Но по моим понятиям, DSP выдает на аналоговый выход содержимое своего буфера видеокадра. А приемный DSP, соответственно, захваченное аналоговое видео в свой буфер кладет. Т.е. приемный DSP бесплатно получает копию буфера передающего DSP, и в идеале, при нормальной синхронизации, они должны совпасть строка в строку.
Тогда берем произвольный цифровой поток, преобразуем по принципу “несколько бит в несколько градаций яркости”, кладем в буфер и надеемся, что на приемном конце этот буфер будет таким же (хотя для надежности я бы добавил номера строк к самим строкам). Еще очень неплохо бы добавить контрольные суммы к блокам какого-то размера (лучше всего к кадрам в потоке H.264). На приемном конце разбираем буфер обратно в поток и пытаемся его декодировать.
При стандартном PALовском разрешении 720х576, 25 к/сек, 16 градаций уровня получаем полосу в 41 Мбит/с, что даже слишком хорошо. Можно повышать помехоустойчивость, снижая количество градаций или применяя избыточное хемминговское кодирование.
Сообразил, что DSP у меня нет, но есть видеокарта с видеовыходом и ТВ-тюнер с видеозахватом. В принципе могу попробовать поиграться.
Если я правильно понял, сейчас пара Виртурилок по WiFi дают задержку 0,2-0,3 секунды, причём какую-то задержку сюда вносит ещё и сам WiFi, т.к. пытается передать всё без потерь. А если удастся получить 0,2сек. и хотя бы 720р - то это уже закроет весьма весомую часть задачь.
Насчёт пары виртурилок - не проверял. Я обычно видео отдавал да, виртурилкой, RTP (UDP), H264, а принимал на ноут/десктоп. У виртурилки сейчас нет цифрового видеовыхода (только композитный НЧ). Хотя можно и HDMI выход добавить, на крайний случай. Задержка да, в основном из-за канала связи.
Если что-то получится в этом плане замутить - HDMI выход добавим в экстренном порядке 😄 (основную плату изменять не надо, просто добавляется маленький мезонинчик на имеющиеся пины расширения)
Нет накладных расходов на TCP/IP
Не путайте WiFi c TCP/IP.
WiFi это радио Ethernet. Он ничего про TCP/IP не знает и недолжен. Все действия на нижнем уровне сводятся к отправке кадра и его получению. Причем все слышат всех, так как среда передачи одна.
что исключает эффекты, если WiFi захочется скорость поменять.
Скорость меняет не WiFi, а протокол управления каналом, который уже над WiFi-м. Не захотим не будет никакого протокола управления и изменения скорости (то есть вида модуляции).
Применяем любые частоты вместо 2.4,
В реальности у нас пока только 2 подходящих диапазона: 2.4 и 5.5-5.8 ГГц. И там есть WiFi.
Задержка здесь будет определяться только кодером и декодером H.264, поскольку затраты на модуляцию/демодуляцию смехотворны. Восстановление не нужно, просто выбрасываем битый кадр.
Не кадр а всю цепочку кадров от битой порции до следующего опорного кадра. Вы с H.264 точно знакомы?
Для того, чтобы не терять картинку из-за шумов, можно попробовать применять кодирование по Хеммингу
Сколько будете добавлять корректирующих бит на один исходный?
Из того, что я не знаю про DSP, можно написать неплохой учебник
Тогда тему DSP лучше обойти. 😃
Я обычно видео отдавал да, виртурилкой, RTP (UDP), H264, а принимал на ноут/десктоп.
Можно более точные цифры:
- Какой исходный видопоток сжимался?
- Какой получался поток на уровне канала связи?
- Менялась ли пропускная способность канала связи в процессе?
- Каков был режим кодирования H.264? Как часто шли опорные кадры?
- Какая была полная задержка передачи?
- Испытывали ли канал связи на дропы (полное пропадание связи)? Cколько времени занимало восстановление картинки?
Я не в коем случае не собираюсь кому-либо запретить пользоваться WiFi 😃
Кстати, что в передаче по видеотракту было бы очень полезно - возможность переключиться с цифрового “псевдовидеосигнала” на обычный аналоговый. Т.е. если все в шумах и картинка посыпалась - по команде с земли на передающем конце кодировать H.264 перестаем и просто масштабируем HD в низкое разрешение и выдаем на видеовыход, переходя на обычную аналоговую передачу. А на приемном, соответственно, перестаем раскодировать и выдаем на выход, что принято. Шумная картинка низкого разрешения значительно лучше, чем отсутствие высококачественной картинки вообще 😃
Можно более точные цифры:
- Какой исходный видопоток сжимался?
- Какой получался поток на уровне канала связи?
- Менялась ли пропускная способность канала связи в процессе?
- Каков был режим кодирования H.264? Как часто шил опорные кадры?
- Какая была полная задержка передачи?
- Испытывали ли канал связи на дропы (полное пропадание связи)? Cколько времени занимало восстановление картинки?
- Поток с сенсора камеры OV7675 (640x480x30fps). HD камеру ещё не подцепил, так что проверить HD поток пока не могу. Отдаётся гстримером на виртурилке, принимается на виндовый ноутбук (тоже гстримером).
- Поток выставляется в цепочке GStreamer, который за обработку видео отвечает с помощью имеющегося на борту DSP. Можно выставить хоть 100 кбит, хоть несколько мегабит в секунду. Я обычно 1 мегабит выставлял.
- Проверял обычно на ездящих девайсах (тележки, танчики). Качество приёма бывало ухудшалось, когда по квартире за три стены уедешь.
- Вот такая цепочка для видео, без особых оптимизаций
gst-launch v4l2src always-copy=false chain-ipipe=true ! video/x-raw-yuv,format='(fourcc)‘NV12, width=640, height=480, framerate=’(fraction)'30/1 ! dmaiaccel ! dmaienc_h264 encodingpreset=2 ratecontrol=1 intraframeinterval=10 idrinterval=46 targetbitrate=1000000 ! rtph264pay !udpsink port=3000 host=192.168.1.254 sync=false enable-last-buffer=false
- Полная задержка именно видео при коннекте именно по вай-фаю в районе 200-300мс. Фотография с секундомером на телефоне где-то валялась, но так сразу щас не найду. По проводной сетке получше, 100-200мс.
- Да, конечно. Так как передача по UDP, возобновление не требует заново приложение на ноуте запускать, как только появляется поток - тут же картинка возобновляется. Как проверить именно время возобновления - не знаю, но на взгляд очень быстро, идут дельты (пока опорный кадр не придёт) где-то 100-200мс. Когда проверяли передачу видео через 3G модем дропы были довольно часто, но всегда видео возобновлялось без проблем.
Ещё клевая тема (при наличии вайфая) - передача мультикастом. Одновременно видео принимать можно на несколько ноутов/компов/планшетов.
Кстати, что в передаче по видеотракту было бы очень полезно - возможность переключиться с цифрового “псевдовидеосигнала” на обычный аналоговый. Т.е. если все в шумах и картинка посыпалась - по команде с земли на передающем конце кодировать H.264 перестаем и просто масштабируем HD в низкое разрешение и выдаем на видеовыход, переходя на обычную аналоговую передачу. А на приемном, соответственно, перестаем раскодировать и выдаем на выход, что принято. Шумная картинка низкого разрешения значительно лучше, чем отсутствие высококачественной картинки вообще 😃
На виртурилке композитный НЧ видеовыход специально под это дело 😃 Т.е. можно одновременно и цифру отдавать и НЧ видеосигнал с одной камеры. А на НЧ видеосигнал ещё и OSD накладывать можно (обычный линуховый фреймбуфер) с 7 уровнями прозрачности 😃
Вот тут вроде видно чуточку (лого поверх видео)
Кстати на цифирьнуб картинку (которая по вифи передаётся) тоже инфу можно накладывать. Координаты, напряжение и прочие OSD прелести. На практике ещё не делал но возможность точно есть.
Ещё клевая тема (при наличии вайфая) - передача мультикастом.
Просто уберите UDP уровень. Сразу пакуйте данные в WiFi пакеты. Зачем лишние преобразования?
На этом уровне нет никаких IP и мультикастов, только MAC адреса и все могут слушать всех.
А виртурилка с каким видео реально cможет справиться?
Просто уберите UDP уровень. Сразу пакуйте данные в WiFi пакеты. Зачем лишние преобразования?
На этом уровне нет никаких IP и мультикастов, только MAC адреса и все могут слушать всех.А виртурилка с каким видео реально cможет справиться?
С тем процом который сейчас стоит (и в первом тираже будет) DM365 DSP поддерживает 720p 30fps с гарантированным временем преобразования <100ms. Процы постарше (DM368 и DM369) поддерживают 1080p 30fps. Процы полностью совместимы, т.е. для того чтоб поставить старшие процы не надо ничего переделывать, pin-to-pin совместимость. Так что можно будет потом и на них перейти. Или даже раньше, если потребность будет.
HDMI выход добавим в экстренном порядке
На виртурилке композитный НЧ видеовыход
Что-то мне подсказывает, что HDMI тут вообще будет ни к чему… Как раз на НЧ-видеовыход и надо выводить то, что собирамеся отправлять на передатчик. Тогда и эта идея становится реализуемой:
было бы очень полезно - возможность переключиться с цифрового “псевдовидеосигнала” на обычный аналоговый
Просто уберите UDP уровень. Сразу пакуйте данные в WiFi пакеты.
Заманчивая идея… А что с этим делать на стороне приёмника?
Что-то мне подсказывает, что HDMI тут вообще будет ни к чему… Как раз на НЧ-видеовыход и надо выводить то, что собирамеся отправлять на передатчик.
Хочу на самолётике полетать с HD картинкой на 42" телике 😃