Беспроводная передача видео в full HD

pdv=

…если хотим качества, как ни крути от цифры нам не уйти! это факт!) …думаю это того стОит!

1 month later
amnesiax
Expert:

mjpeg без вариантов!, я писал уже наверное трижды
ниче страшного потерять 5-10 кадров из 25!

Какая-то патологическая страсть к mjpeg

Кодек h264 позволяет указать интервал между ключевыми кадрами, допустим, до приемлемой величины потерянных кадров в 15.
При этом общая занятая передачей видео полоса останется в 15-20 раз меньше,чем при использовании mjpeg (ссылку на статью об особенностях кодеков я ставил ранее)
Чтобы было понятно, для передачи картинки 720p с самолета (без учета среднестатистического кол-ва меняющихся блоков в кадре, передавать спортивный матч и статичную картинку из студии-огромная разница для h264) нужен канал в 3.8 мбит\сек.
По грубым прикидкам (на основе публично доступной статьи в вики) для передачи этого же видеосигнала потребуется 3.8*15 (минимум)=57 мбит\сек.
Здесь еще не учтен тот факт, что mjpeg, в отличии от h264,всегда требует постоянной устойчивой полосы не позволяет принципе экономить полосу.

Выигрыш по полосе у h264 позволяет, допустим, передавать на другой частоте синхронную копию видосигнала или использовать CRC для восстановления потерянных кадров. Но это уже не хоббийный уровень надежности. К слову, и резервирование канала передачи и CRC-алгоритмы успешно применяются в профессиональной технике.

baychi
amnesiax:

использовать CRC для восстановления потерянных кадров

Во первых не CRC, а ECC (Errors Corection Code), а во вторых корректирующие коды не используьются при передаче по радоканалу, так как бесполезны. Коды типа Рида-Соломона предназначены для восстановления нескольких бит в болке из сотен байт, а провалы радиосигнала, как правило давят сотни бит, если не весь пакет.

amnesiax:

Кодек h264 позволяет указать интервал между ключевыми кадрами, допустим, до приемлемой величины потерянных кадров в 15. При этом общая занятая передачей видео полоса останется в 15-20 раз меньше,чем при использовании mjpeg

Это да. Но на границе потери сигнала, будет задержка в 0.5 сек. А если довести количество ключевых до каждый 3-5, то разница будет уже меньше. Плюс задержка обработки, требующаяся H264 кодеку, для оптимального сжатия. Чем она меньше, тем хуже жмет.

Lazy
baychi:

Во первых не CRC, а ECC (Errors Corection Code), а во вторых корректирующие коды не используьются при передаче по радоканалу, так как бесполезны.

Вот засада, получается нас массово обманывают!

As mentioned above, the radios support a 12/24 Golay error correcting code…
This means that for every 12 bits of data the radio will send 24 bits, calculating the bits using Golay code lookup tables.
…allows the radio to correct bit errors of up to 3 bits in every 12 bits send…

amnesiax
baychi:

Плюс задержка обработки, требующаяся H264 кодеку, для оптимального сжатия. Чем она меньше, тем хуже жмет.

Задержка возникает только по одной причине-кодеку h264 нужно иметь в буфере весь набор от одного ключевого кадра, до другого.
Как раз h264 позволяет эту задержку минимизировать. Нужно просто передавать 60 кадров в сек. Overhead в канале передачи будет очень маленьким, задержка снизится абсолютно пропорционально.
Ну, и как вы понимаете, для профессиональных задач и больших скоростей, 60 fps гораздо нужнее, чем 25.

baychi:

провалы радиосигнала, как правило давят сотни бит, если не весь пакет.

с такими провалами (в сотни бит и выше) борятся резервированием передачи на другой частоте (по другому каналу). Понятно, что никакие crc\ecc помогут.
Небольшие потери\искажения восстанавливают благодаря применению алгоритмов контроля целостности и коррекции ошибок.

Вахтанг
Expert:

боюсь арма и дешевого кодера тут уже не хватит, тут уже надо какие то специализированные плисины, ну или в писюк пихать.

АРМ-а конечно не хватит, а ПС таскать на борту “немножко” накладно 😃
Существует куча DSP процессоров, специально заточенных под эти задачи. Я их не раз применял для задач на работе. Например у TI их целая серия, также у Freescale или Samsung. У Samsunga, правда, техподдержки никакой, если ты не купил процов >10000шт. А вот на первые 2, у меня даже готовые плати имеются, для начала тестирования, могу и немножко видоизменить плату, под наши нужды (потрачу на это время и деньги). Вот только у кого столько свободного времени и соответствующего знания найдется? да и не поднять эту задачу одному человеку, наверное. Если кто готов попробовать звоните, пишите - оборудование и среду программирования предоставлю, обеспечу и техподдержку. А еще лучше - возьму на работу!

MaF

Ребят,вопрос не совсем по теме.
Есть Sony Nex с miniHDMI.Реально ли снять с него сигнал и передать с борта на очки и т п?К качеству сигнала требования низкие - вполне устроит схожее с простыми FPV-камерами)
Собираю коптер под фотосъемку,городить огород со 2 FPV камерой как то не очень хочется.

samsung
MaF:

Есть Sony Nex с miniHDMI.Реально ли снять с него сигнал и передать с борта на очки и т п?

Да реально, для этого нужен HDMI-S-Video конвертер

Aleks65421
Вахтанг:

АРМ-а конечно не хватит, а ПС таскать на борту “немножко” накладно 😃
Существует куча DSP процессоров, специально заточенных под эти задачи. Я их не раз применял для задач на работе.

TI DM365\369 2потока один до FullHD тянет…
DSP-TI-транспорт
У панаса и сони неплохие DSP с прямым выводом цифрового потока.

amnesiax:

Какая-то патологическая страсть к mjpeg
Кодек h264 позволяет указать интервал между ключевыми кадрами, допустим, до приемлемой величины потерянных кадров в 15.
При этом общая занятая передачей видео полоса останется в 15-20 раз меньше,чем при использовании mjpeg (ссылку на статью об особенностях кодеков я ставил ранее)

Реальная задержка h.264 по IP стеку от 3-5сек до бесконечности, настройки кодека GOP или CRC особо не влияют. При очень хорошем транспорте можно получить меньше секунды.

MaF
samsung:

Да реально, для этого нужен HDMI-S-Video конвертер

А к нему уже прикручиваем обычный передатчик?
Не в курсе,оно в плане энергопотребления как?

Aleks65421
MaF:

А к нему уже прикручиваем обычный передатчик? Не в курсе,оно в плане энергопотребления как?

НЧ с конвертера на передатчик или OSD, 150-300мА

MaF

Понял,спасибо огромное.
Да,именно некс таким образом уже использовал кто-то?
В принципе не вижу препятствий,но тетка Сони та еще,кхм…

Вахтанг

Смотреть надо не только вес и цену. Приведенные приборы предназначены прямо для противоположного преобразования сигнала!
У Александра RCA->HDMI. У Михаила HDMI->RCA

Alex013

Согласен, бес попутал - но только по второй ссылке, которая на Алибабу - по первой всё правильно…
А вот и замена второй - уровень цены примерно тот же 😉

8 days later
Gol
Aleks65421:

TI DM365\369 2потока один до FullHD тянет… DSP-TI-транспорт

DM365 - максимум 720p 30fps. DM368 и свеженький DM369 да, могут 1080p кодировать, те же 30fps.

Aleks65421:

Реальная задержка h.264 по IP стеку от 3-5сек до бесконечности, настройки кодека GOP или CRC особо не влияют.

Нифига подобного. Наглядной демонстрашки с таймингами сейчас под рукой нету, есть недавнее видео с танчиками www.g0l.ru/blog/n3725 Задержка в районе 200-300мс. Камера OV7675, видео жмёт как раз DM365 на нашей железке (Виртурилка, может быть слышали). Разрешение 640х480х30fps. Кодек H264, протокол RTP, транспорт UDP, юникаст/мультикаст - пофиг, проверял и так и сяк. Мультикаст клёво ибо можно сразу на нескольких девайсах смотреть (и записывать если нужно). Коннект по вайфаю, 5ГГц. Кстати, коннект не точка-точка а через роутер (т.е. дополнительное звено, мааленькую но задержку тоже вносит).

Коллеги у меня вайфайщики, с RC темой не знакомы 😃 А я вот и там и сям, так что трезво оцениваю применение вайфая для FPV. На медленных скоростях движения и при небольшой дальности - вполне нормально, лично проверял. На багги или на самолёт - уже не пойдёт ибо 300мс задержки на скорости в 30 и более км/час это стрёмно. Увеличение дальности бустерами не прокатит из-за двунаправленной сущности вайфая. Тут только направленные антенны делать. Но если на земле можно поставить узконаправленную следящую антеннку, то на самолёт/машинку/коптер и т.д. - фиг там. Если где ошибаюсь - пните, плиз.

Aleks65421:

При очень хорошем транспорте можно получить меньше секунды.

И при TCP и при UDP меньше секунды, но UDP предпочтительнее - пусть лучше картинка ненадолго “рассыпется” чем фриз картинки будет.

Так, сначала ответил, потом только название темы увидел. Тема про FullHD, а я про 640х480 талдычу 😃 Сейчас у меня железка максимум 720p осилит, но сенсоры такие ещё не цепляли. Валяется пара пятимегапиксельных сенсоров OV5642 (как в вебках Logitech C910/B910), как подцеплю - опробую и тогда доложу. Но, сдаётся мне, так как DSP по барабану разрешение картинки если оно в рамках допустимого, всё упрётся в канал, т.е. в дальность уверенного вайфайного коннекта.

Была пьяная идея на грани бреда - каким-то макаром слать видео в вайфайный эфир в open mode без фактического коннекта, а на земле снифать и вычленять видеопоток. Но как такое опробовать пока не придумал. Видимо, на следующей пьянке придумаем 😃

Rabbit_Fly
Gol:

Увеличение дальности бустерами не прокатит из-за двунаправленной сущности вайфая.

так все усилки счас двух нарпавленные