Беспроводная передача видео в full HD
Для передачи видео с NEX использую этот передатчик
По ссылке - преобразователь HDMI->AV. Вы ничего не перепутали?
По ссылке - преобразователь HDMI->AV. Вы ничего не перепутали?
Перепутал. 😃 Я использую именно этот конвертор, а уже с него вывожу AV сигнал на обычный передатчик. Кстати, при подсоединении конверторов начинает барахлить автофокусировка при управлении камерой через IR порт. Приходится переключаться на ручной фокус.
Для передачи видео с NEX использую этот передатчик.
Алексей, у вас на земле что, монитор или очки? (в очках разницы наверное не увидишь)
Я заметил что при просмотре HD записи полета через АV выход плеера картинка лучше чем сразу AV-AV. Интересно качество картинки у вас получается лучше чем еслибы использовать АV выход фотоаппарата? (Я знаю что в NEX нет AV, но в GOPRO есть возможность сделать и так и так)
У меня и очки и монитор 7". Не знаю где лучше качество, для FPV NEX 5N всё равно использовать я не буду. А для кадрирования мне качества достаточно.
Алексей, у вас на земле что, монитор или очки?
Я заметил что при просмотре HD записи полета через АV выход плеера картинка лучше чем сразу AV-AV.
На сколько я понял, речь о том, что преобразование в композит у Вашего плеера реализовано лучше, чем у GoPro? Легко в это верю - у моей Hero_3 аналоговый видеовыход весьма посредственный…
Но что Вы хотели узнать у AlexeiD - честно говоря, не осознал…
Но что Вы хотели узнать у AlexeiD - честно говоря, не осознал…
Наверное я выразился очень затейливо 😃
Но вопросс открыт.
Если вес не критичен то может быть лучше использовать этот конвертор HDMI-AV, на борту, и получим на земле картинку лучше чем AV-AV?
Была пьяная идея на грани бреда - каким-то макаром слать видео в вайфайный эфир в 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колько времени занимало восстановление картинки?