Беспроводная передача видео в full HD
а что усиливаем то? сам концепт озвучьте плз
продолжу разговор начатый в теме про выбор очков, здесь ему место получше будет
встал в очередь на заказ Raspberry Pi
жду приглашения на оплату, там все еще очередь.
Хорошая новость разработчики анонсировали камеру которая подключается напрямую к процессору, а значит USB остается свободным для линка.
hard.compulenta.ru/680989/
а раз разработчики анонсировали камеру, значит не за горами кодеки и дрова для сжатия видео.
Сомневаюсь, что на АРМе можно слепить софтовый кодек, обрабатывающий в реал-тайме HD…
там прогрессивное видеоядро имеющее аппаратный кодинг - декодинг FullHD, эта малышка крутит HD видео и игры на уровне кваки третьей в FullHD
Сомневаюсь, что на АРМе можно слепить софтовый кодек, обрабатывающий в реал-тайме HD.
И не надо! сейчас в продаже куча АРМ-ов, с аппаратным кодеком Н264, Full HD. На iMax53 сейчас как раз ваяем мини компьютер. Потребление 5Ватт, ни вентиляторов, ни других шумных устройств, размер в 2 сигаретные пачки. Частота 1ГГц, память до 2-х Гиг и т.д. Стандартный РС “делает” за просто! 2 входа для видео матриц. Скоро ждем выхода 6-го проца, 4 ядра на 1.2 Гига!
У Самсунга классный проц, еще лучше, чем Фрискейл, но с поддержкой беда.
вся фишка в том что такие аппаратные ресурсы и размеры вполне позволяют вывести электронную начинку летательного аппарата на качественно новый уровень, в рамках одной платы можно объединить все, начиная от автопилота и ОСД до систем телеметрии и видео.
… и все это на вполне комфортном уровне программинга и отладки, в отличие от всяких мег и кортексов
Максим, тссс, не бегите впереди паровоза 😃, никому не говорите, скоро будет!
Видел в сети один сайт, разрабы впихнули кодер DVB-T в плисину Spartan-3a, на выходе уже промежуточная частота для передатчика, за IPcore хотят порядка 30к евро, так что спецы по плисинам все в ваших руках )))
в воздухе получить стабильный вай-фай линк 10мбит/сек до 2 км вполне возможно без всяких усилителей. На земле, конечно, лучше иметь чтото направленное.
Практический результат:
Wi-Fi мост на двух точках доступа Bullet M2 HP 600мВт, на автомобиле антенна 8.5 дБи - штырь, на базе 27дБи направленная, следящая.
В динамике(скорость авто до 120км/ч) на дальности 5 км пропускная способность до 6 Мбит/c, на 2 км - до 20-30Мбит/c.
Цифры получены через внутреннюю программу диагностики точки доступа, так что реальная скорость примерно вдвое ниже.
Испытание проводились на границе города, так что эфир был “в меру засран” 😉
А потери линка происходили в процессе тестирования?
Как быстро линк восстанавливалося?
А потери линка происходили в процессе тестирования? Как быстро линк восстанавливалося?
Потерь в смысле полного разрыва соединения не было (потеря по пингам не более 1-2%), но возникали дополнительные временнЫе задержки и артефакты изображения. Возможно, так работало железо ip-видеосервера, через который и гнали изображение. Видео постоянно “запаздывало” на 0.3-0.5 с даже при 54 Мбит/c. При снижении уровня сигнала (за кустами, за домами) получалось примерно так:
видео будет запаздывать всегда это особенности алгоритма сжатия, ключевой кадр плюс к нему 10-20 вспомогательных, при таком раскладе получим 0.6 -0.8 сек задержку при 30 к/с.
Вывод: нужно либо применять альтернативные алгоритмы сжатия, без участия ключевых кадров, либо передавать сырой поток от камеры, но там ширина канала нужна большая
я тут встречал USB радиоудлинители, если взять вебкамеру и заменить на радиоканал не IP участок путем трансляции потока от IP сурвера, а сам USB, приемопередатчики соответственно забустить для увеличения дальности
Не спец в кодировании видео, но вроде при однопроходном кодировании каждый дельта-кадр рассчитывается на основе пред.истории а не пост. Поэтому не очень понятно зачем тянуть с его отправкой. Тем более для ключевого кадра…
не важно пред или пост, ведь отправляем мы не исходный кадр а результат кодирования, в результате результирующий набор кадров мы сможем рассчитать только приняв всю последовательность необходимую для создания выходного набора ключевой и вспомогательные, в итоге ждем.
Хотя я то же не спец могу и ошибаться, но опыт и логическое мышление меня редко подводит…
Тогда на уровне логики докажите, что задержка необходима… 😃
Закодировали K1-кадр -> передали
Закодировали D11-кадр -> передали
…
Закодировали D1n-кадр -> передали
Закодировали K2-кадр -> передали
Закодировали D21-кадр -> передали
…
Закодировали D2n-кадр -> передали
итп…
На приеме все абсолютно симметрично, задержка 1кадр…ну может + время кодирования+время передачи+ время декодирования.
При кодировании аудио, насколько помню, латентность определяется необходимостью буфера для хранения пред. истории, а здесь вроде все детерминировано размером кадра.
Тогда на уровне логики докажите, что задержка необходима
Сергей, Ваш пример для теоретического кодека, кодирующего только опорные кадры и кадры отличия от них (предсказание) на канале с неограниченой полосой… В реальности даже MPEG2 кодирует три типа кадров: базовые, отличия и двунаправленные, для которых нужен буфер.
Плюс к этому задержка возникает при упихивании базовых кадров в реальный канал с ограниченной пропускной способностью. Например, если передавать только базовые кадры (jpeg фотки), то это можно делать без задержки на канале в 20-30 Мбит, а когда мы сжимаем поток в 5-10 раз,это означает что базовый кадр занимает 80-90% объема всего потока, поэтому никак не может передаться за свои штатные 30 или 40 мс. Типичный mPEG2 поток это один опорный кадр на 15 предсказаний, то есть задержка на 0.4 сек уже гарантированна.
Поэтому не очень понятно зачем тянуть с его отправкой. Тем более для ключевого кадра
Нужно рассматривать задержки не только при формировании кадра, но и при передаче его через стек TCP/IP. У меня время пинга с одной AP на другую по радиоканалу варьировалось от 10 мс до 800мс! Т.е. повтор кадров TCP, сам протокол обмена и т.п. тоже вносят свою лепту. Кстати, видеосервер, что был у меня, давал задержку даже при проводном подключении 100 Мбит и MJPEG компрессии. Возможно, что еще и клиентский софт притормаживал. Просто от меня реалтайма тогда не требовали, поэтому глубоко не копал
Итак попробовал использовать выходной каскад передатчиков фокстеч =http://www.betatvcom.dn.ua/…/hmc408lp3.pdf
Выходной каскад усиливается, проверено, но результат нулевой 😦
При отключенных передатчиках дальность 10 метров, при включенных,
маскимальная дальность которая получилась в поле 30 метров.
Вывод не все так просто как казалось в начале.
посмотрел еще раз внимательно
неправильно сделано было просто
- Внешние уселки нужно кидать не на выход штатных (там уже 19 дбм) а на вход, разорвать цепь (отпаять согласующий резистор или кондер там обычно) и подкинуть внешний усь
- Система передачи дуплексная! Там есть пятый канал это приемник
1-4 передача, 5 прием
Соответственно нужно бустить еще и в приемнике 1 канал.
Что бы не обрастать кучей уселков лучше взять комплект
www.aliexpress.com/item/…/564523540.html
там передатчик имеет всего два канала один прием второй передача.
Соответственно понадобится два бустера, один на приемнике второй на передатчике.
Что бы ослабить взаимное влияние передающей части на приемную еще не плохо бы антенны разной поляризации поставить, например пару клеверов противоположного вращения, а на земле сдвоенный хеликс разного направления.
Аслан тестовый комплект еще жив?
Попробуйте сделать по уму, не обязательно бустить все 4 передающих, для теста достаточно будет одного уселка на передающей и одного на приемной части
Что бы ослабить взаимное влияние передающей части на приемную
Там скорее всего не дуплекс, а полудуплекс и пока идет прием передачи нет.
Коль уж использовать протокол с подтверждениеми и перепосылкой потеряных кадров, так значительно проще.
А еще лучше чисто симплексная передача, ИМХО…
Нужно рассматривать задержки не только при формировании кадра, но и при передаче его через стек TCP/IP
Зачем здесь нужен TCP/IP вообще непонятно. Да и нет его там. Прямая связь точка-точка, никакой маршрутизации. Обычный радио-Ethernet, в кадры которого напрямую упакованы видеоданные.
Там скорее всего не дуплекс, а полудуплекс и пока идет прием передачи нет.
полу или полный в данном аспекте не важно, ибо для того что бы инициировать процесс приема и отключить передатчик нет другого пути кроме как постоянно слушать эфир и ждать кодовую посылку от приемника на земле. Если при этом местный бустер будет заваливать приемник борта то мы в принципе в режим приема не перейдем.
Главная проблема таких систем отсутствие синхронизации, в итоге всегда идут по схеме мастер-слэйв, слэйв слушает эфир постоянно и по сигналу от мастера рулит процессами приема и передачи. Чисто же полудуплекс только в радиостанциях возможен, когда все больше слушают чем говорят.