Беспроводная передача видео в full HD
а что мешает поставить модуль аирвейв , например у меня прастой изи кап в палах думаю поставит модуль на 5.8
Не понял. Предлагаете купить ( rcopen.com/forum/f90/topic116356/2246 ), выдернуть ( если получится ) 2,4 и воткнуть 5,8 ( который не влезет) ? Зачем такой мазохизм.
Не проще взять копеешный изи кап и прикрутить к нему 5.8 ?
Не проще взять копеешный изи кап и прикрутить к нему 5.8 ?
v planax imenno eto
например у меня прастой изи кап в планах думаю поставит модуль на 5.8
😉
Итак попробовал использовать выходной каскад передатчиков фокстеч =http://www.betatvcom.dn.ua/…/hmc408lp3.pdf
Выходной каскад усиливается, проверено, но результат нулевой 😦
При отключенных передатчиках дальность 10 метров, при включенных,
маскимальная дальность которая получилась в поле 30 метров.
Вывод не все так просто как казалось в начале.
а что усиливаем то? сам концепт озвучьте плз
продолжу разговор начатый в теме про выбор очков, здесь ему место получше будет
встал в очередь на заказ 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 компрессии. Возможно, что еще и клиентский софт притормаживал. Просто от меня реалтайма тогда не требовали, поэтому глубоко не копал