Беспроводная передача видео в full HD
нужно алгоритм сжатия изобретать
Я столько физически не выпью
больший поток данных чем дает 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" телике 😃
Хочу на самолётике полетать с HD картинкой на 42" телике 😃
Это будет SP-2.0 - договорились 😉 ?
Это будет SP-2.0 - договорились 😉 ?
Эх, уговорили. Начнём с малого. Мож вообще ничего не получится 😃 Надо надеяться на худшее чтоб получилось хоть что-то.
Что-то мне подсказывает, что HDMI тут вообще будет ни к чему…
HDMI нужен на приемном конце. Надо же куда-то вывести картинку.
Нет, если WiFi хватит - я буду только за, тем более, что вторая плата при этом не нужна и ноут у меня уже есть. Но что-то мне слабо верится - иначе весь мир уже летал бы по WiFi. Не говоря о том, что в Москве WiFi роутер светит из каждой второй квартиры, и самолет увидит их все.
HDMI нужен на приемном конце. Надо же куда-то вывести картинку.
Согластен, этот конец я упустил 😉 …
в Москве WiFi роутер светит из каждой второй квартиры, и самолет увидит их все.
На 5 ГГц еще не из всякой. По крайней мере 5,47 — 5,725 ГГц и 5,725 — 5,875 ГГц. Иначе я бы видел их на своих аналоговых видеоприемниках.
Чем дальше, тем красивее. В этом DSP есть LCD контроллер.
Gol,
а прямое управление LCD матрицей через LDVS невозможно ? Потому что это получилось бы вообще лучшая в мире FPV железка, от самодельных очков на базе матрицы 7" 1280х720 до очень компактного и легкого телевизора на базе ноутбучной матрицы.
Чем дальше, тем красивее. В этом DSP есть LCD контроллер.
Gol,
а прямое управление LCD матрицей через LDVS невозможно ? Потому что это получилось бы вообще лучшая в мире FPV железка, от самодельных очков на базе матрицы 7" 1280х720 до очень компактного и легкого телевизора на базе ноутбучной матрицы.
Коллега-аппаратчик говорил что если добавить обвязку (мелкую платку всё на тот же разъём расширения) то можно подключать LCD матрицу. Узнаю у него его поподробнее.
Коллега-аппаратчик говорил что если добавить обвязку (мелкую платку всё на тот же разъём расширения) то можно подключать LCD матрицу. Узнаю у него его поподробнее.
Могу готову сборку подогнать матрица-dsp-369обвязка-блок интерфейсов SD Power USB audio 485
затянуть OSD по i2c на 36х
размер камеры с осд передатчиком и всем обвесом будет 50х50х40… заманчиво при цене в 7 рублей …
Gal,
еще вопрос - этот DSP не позволяет произвольно устанавливать разрешение и частоту кадров для видеовыхода/видеовхода ? Потому что картинка 1280Х720 11 к/с имеет ту же полосу, что и 720х576 25 к/с и в радиотракт пролезет. Если бы удалось такой видеосигнал вверху сформировать, а внизу принять и вывести на HDMI/матрицу - было бы очень здорово.
Пару плат на всякий случай предзаказал.
Как насчет процов Cavium PureVu? FullHD с задержкой меньше 1мс.