Беспроводная передача видео в full HD
А для радиолинка вифи?
А есть что-нить без приемопередачи и контроля пакетов?
Типа передал и фик с ним. 😃
Ну проц вроде как поддерживает аппаратно FullHD.
Вопрос не в том что потянет, вопрос где взять кодек с требуемыми параметрами? Настраиваемый H.264 или еще что?
Я просто не в курсе, что есть для этого проца/ОС потому и спрашиваю.
И передавать лучше стримом по UDP.
Лучше всего чистые Ethernet кадры. Нам же маршрутизация и прочие IP штучки не нужны.
А почему никто не рассматривает идею увеличить по крайней мере в двое, а лучше в трое разрешение картинки получая ее с двух или трех камер? камеры должны быть установлены таким образом что бы края изображения стыковались с минимальным зазором. на земле три монитора, перед и боковые как тут 
Объективы в этом случае нужно ставить не широкоугольные. Получиться вполне HD видео, ведь на угол зрения около 120гр мы подадим картинку не с одной камеры а с трех. Надеюсь моя идея понятна.
ЗЫ
Есть технология передачи 3Д видео 60 гц, для двух каналов придется делить пополам (по 30гц), автор 3Д контролера написал что можно вместо интерлейса 3Д выдавать сигнал с одного комплекта TX-RX на два монитора. На multicopter ру обсуждалась идея с дешифратором для похожих целей.
А есть что-нить без приемопередачи и контроля пакетов? Типа передал и фик с ним.
Ethernet и WiFi как его сын так и работают. 😃
Лучше всего чистые Ethernet кадры. Нам же маршрутизация и прочие IP штучки не нужны.
Ну это полная замена сетевой библиотеки. Это пипец. 😃
Может поверх ЮСБ проще поток передать?
типа ЮСБ радиолинк. 😃
Ну это полная замена сетевой библиотеки. Это пипец
Наоборот, чем ниже, тем проще. Засунули данные в Ethernet кадр и дали команду отправить.
На приеме проверяем, есть ли новые, если есть - получили. 2-3 подпрограммы всего.
Даже под Windows есть пакет winpcap, позволяющий работать с чистыми Ethernet кадрами, чем я послединий год и занимаюсь. 😃
Что на этом можно получить в плане сжатия HD? Есть ли готовые кодеки с выходом в H.264 или MPEG2
Видео кодеки аппаратные. Сжатие 720Р, распаковка Full HD. Уже получили следующий проц, 4 ядра, Full HD в обе стороны.
Хотя-бы порядок цены для такой партии?
Надо считать. Себестоимость деталей самой платы не превышает 4 тыс.р., А вот сборка обходится дороже. Одна компания вообще 17 тыс.р. запросила, я чуть со стула не упал! 😦
60% деталей типоразмер 0201, т.е. 0,5х0,25мм! и 5 BGA корпусов, руками тяжело паять.
HDMI вход можно сделать?
Если с приемника Wi Fi сигнал в езернет подать, то вот вам и HD на вход. Дальше его распаковать и на монитор видать не проблема. Но вопрос, а зачем вам в поле HD?, кто-ж такой монитор туда потащить? и чем его там запитать?
Сегодня правда доступны мониторы 10", с HD разрешением, но цена!
Может поверх ЮСБ проще поток передать? типа ЮСБ радиолинк.
Тут 2-й USB, думаю маловато будет. Вот в 3-й наверное прокатить. Как раз новый проц имеет 3-й.
Видео кодеки аппаратные. Сжатие 720Р, распаковка Full HD.
Основной вопрос можно ли получить задержку картинки в доли секунды, или нет?
Обычный H.264 для камкодеров - это секунды, если не десятки.
Если с приемника Wi Fi сигнал в езернет подать, то вот вам и HD на вход.
Не понял. Мы о каком конце речь ведем? Разве не о передающем?
У нас есть камера с HDMI выходом, например GoPro. Нам нужно взять этот поток, сжать и послать по WiFi.
С приемной стороной проблемм намного меньше, хоть ноут реальный, хоть смартфон…
Тут 2-й USB, думаю маловато будет
100-400 Мбит/сек мало? Что-же мы по WiFi гнать-то будем? Или Вы предлагаете USB WEB-камеры цеплять?
Тогда задержка еще возрастает…
Если с приемника Wi Fi сигнал в езернет подать, то вот вам и HD на вход. Дальше его распаковать и на монитор видать не проблема. Но вопрос, а зачем вам в поле HD?, кто-ж такой монитор туда потащить? и чем его там запитать?
Сегодня правда доступны мониторы 10", с HD разрешением, но цена!
Качественная картинка даже в хедплеях отлично смотрится, и монитор для этих целех можно примостырить. А вот ноут и программы это лишее в поле. Должно быть просто ХДМАЙ сигнал с камеры в коробочку > радиолинк > коробочка > хдмай выход. За такое устройство не то что 17 ну с прибылью производителя 25 но и 50 тыч одтал бы.!
производителя 25 но и 50 тыч одтал бы
да но не так много народу найдётся которые будут готовы заплатить столько
да но не так много народу найдётся которые будут готовы заплатить столько
Уж поверьте, такой девайс не только для нашего хобби пригодится.
А вот мысль- если сниферить сигнал с карточки того же гоупро? ведь он там уже сжатый…
А вот мысль- если сниферить сигнал с карточки того же гоупро? ведь он там уже сжатый…
там весь вопрос будет в задержке выдачи сигнала по wi-fi c гоупро
если сниферить сигнал с карточки того же гоупро? ведь он там уже сжатый…
Дык, много раз была мысля сия.
Но задержка там секундами измеряется. 😦
Но задержка там секундами измеряется.
Откуда такая инфа? Где эти данные шляются столько времени?
Проц либо успевает сжимать данные в реальном времени либо не успевает.
Вспомните, через сколько времени после остановки записи ГоПро подтверждает это писком.
Насчет скорости сжатия - посмотрите любой стандарт сжатия, что такое опорные кадры и кадры изменений и почему 90% канала занимают именно базовые кадры.
Что-бы стало понятнее основная проблема передачи картинки через узкий канал связи давайте рассмотрим идеальную ситуацию. На передающей стороне у нас есть процессор неограниченной мощности мнгновенно сжимающий любой поток, а на принимающей - соттветственно мнгнавенно разжимающий. Но при этом мы испльзуем классический MPEG2 или H.264. Вот мы получили от камеры первый кадр, который будет базовым и его надо передать целиком, что-бы было от чего отталкиваться дальше. Обычный алгоритм будет сжимать этот HD кадр 1920х1080х24 бит (это 6 Мбайт несжатых данных), как jpeg фотографию, то есть примерно в 10 раз до 0.6 Мбайт фотки (посмотрите раскадровку с ГоПро в jpeg, и Вы увидите те-же фотки размером от 0.4 до 0.7 Мбайт). Теперь главный вопрос: за сколько времени мы сможем передать 0.6 Мбайт данных (4.8 Мбит) через канал связи в 10-20 Мбит? Получается 250-500 мс. И только спустя это время на приемной стороне мы сможем разжать кадр и увидеть картинку. Остальные кадры, кадры изменений содержат в десятки раз меньше информации и передаются почти без задержки. Но так как базовый кадр уже дал задержку все остальные будет настолько-же задержано.
Разница в степени сжатия между MPEG2 и H.264 нам ничем не поможет в уменьшении задержки, так как бвзовые кадры и там и там сжимаются целиком, как jpeg фотка.
Для уменьшения времени задержки нужен специальный алгоритм, например сжимать базовые кадры с меньшим разрешением (например в 4 раза 720х520), и далее передавать их уточение чередуя с кадрами изменений. Тогда начальная картинка (еще не совсем четкая) поступит на выход в 4 раза быстрее, но через секунду уточнится до полного HD.
Поэтому главный вопрос - есть ли такие алгоритмы, и можно ли ими воспользоваться на предлагаемой платформе, учитывая преимущественно аппаратные (то есть неизменяемые) алгоритмы сжатия?
через канал связи в 10-20 Мбит
Ткните, пожалуйста, что это за канал? Где взять? Пожатое JPEGом видео с телематрицы - 50 Кбайт, 10-15 кадров/сек, устроило бы. Вопрос не по теме топика, сорри.
что это за канал? Где взять?
WiFi
Возможно это приблизит нас к цели www.ixbt.com/news/hard/index.shtml?16/37/70
Возможно это
Лет 15 назад самым популярным заклинанием было слово “фракталы” 😃
www.abonair.com/index.php?dir=site&page=catalog&op…
Performance
Low Delay mode: 90 msec
Ну и бонусы, вроде диверсити, AES-128 шифрования.
Честно говоря, очень скептически оцениваю 90 мсек. Подозреваю что такой результат получен при самых лучших условиях тестов-видеопоток с минимальной динамикой в кадре, простой профиль компрессии.