Беспроводная передача видео в full HD
Что на этом можно получить в плане сжатия 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 мсек. Подозреваю что такой результат получен при самых лучших условиях тестов-видеопоток с минимальной динамикой в кадре, простой профиль компрессии.
в 10 раз дороже чем готов заплатить самый нетерпеливый из нас 😃
А зачем передавать full HD собственно? Недавно посмотрел фильм, записанный на ДВД, соединив ДВД проигрыватель с телеком который поддерживает full HD. Соединил телек и проигрыватель через обычные аналоговые выход и вход. Так вот качество картинки просто супер! Практически не отличимо от фул ХД. Ну естественно попробовал все тоже самое, только по радиоканалу, использовал сначала приемник и передатчик с беврц на 1,2ГГц. Результат превзошел все ожидания, качество картинки вообще на глаз не отличалось от того, что было по проводу. Потом подключил приемник от лавмейт, на него принималась картинка с сильными искажениями, все было в каких-то полосках. Видимо у более дорогого ловмейта полоса пропускания уже, а у китайца широкополосный фильтр и в него проходит весь спектр сигнала. Еще раз повторю, качество картинки было просто супер, почти не отличимо от фул хд. Хотелось бы полетать с такой картинкой. Сейчас думаю как бы скриншот сделать чтобы выложить сюда. Так что дело только в камере, в китайском радиоканале практически нет потерь по качеству. Как можно измерить параметры выходного видеосигнала с ДВДшника, например определить сколько там строк?
Правильно ставишь вопрос.
Сейчас не вопрос купить CCTV камеру, по сути это обычная камера с 750ТВЛ, весь сигнал нормально проходит через видеотракт и нормально воспроизводиться на земле ТВ с 800х600 и больше.
Но хочется большего!
Правильно ставишь вопрос.
Сейчас не вопрос купить CCTV камеру, по сути это обычная камера с 750ТВЛ, весь сигнал нормально проходит через видеотракт и нормально воспроизводиться на земле ТВ с 800х600 и больше.
Но хочется большего!
Если посмотреть качество картинки с тестовой флешки на хедплеях можно увидеть что ресурс 800х600 изображения куда больше чем мы думаем. Тоже не до конца понимаю где зарыта собака. Может все таки в камерах…?
В принципе камеры 700ТВЛ в цвете подходящего нам форм-фактора только появились. Т.е. я летом когда в Москве искал камеру с
матрицей Sony 1/3" SONY 960H EXview HAD / Effio-E 700/750 ТВЛ - было всего два предложения.
Т.е. это все же 700ТВЛ. И значит предел пропускания видеотракта не достигнут - но уже рядом. Но картинка с видеорегистратора 1080р лучше…
Вспомните, через сколько времени после остановки записи ГоПро подтверждает это писком.
Насчет скорости сжатия - посмотрите любой стандарт сжатия, что такое опорные кадры и кадры изменений и почему 90% канала занимают именно базовые кадры.Обычный алгоритм будет сжимать этот HD кадр 1920х1080х24 бит (это 6 Мбайт несжатых данных), как jpeg фотографию, то есть примерно в 10 раз до 0.6 Мбайт фотки (посмотрите раскадровку с ГоПро в jpeg, и Вы увидите те-же фотки размером от 0.4 до 0.7 Мбайт). Теперь главный вопрос: за сколько времени мы сможем передать 0.6 Мбайт данных (4.8 Мбит) через канал связи в 10-20 Мбит? Получается 250-500 мс. И только спустя это время на приемной стороне мы сможем разжать кадр и увидеть картинку.
Поэтому главный вопрос - есть ли такие алгоритмы, и можно ли ими воспользоваться на предлагаемой платформе, учитывая преимущественно аппаратные (то есть неизменяемые) алгоритмы сжатия?
Александр, я поизучал вопрос…
Опорный кадр 720p имеет примерно 90-100 кб, объема, 1080p - вдвое больше. Посему задержка его передачи примерно 150мс максимум. но опроный кадр не передается единовременно и целиком в H264. (зависит от профиля), поэтому теоретическая задержка может быть в пределах 100-200мс.
Но дело в том , что для эффективного сжатия необходима информация из будущего, и чем ее больше, тем эффективнее сжатие. И вся “красивость” картинки гоупро завязана на “психовидеовосприятие” , т.е ее кодек заточен не столько на сохранение информации в кадре, сколько на положительные эмоции зрителя 😃 . В общем что-то типа “теплого лампового звука” , только в видео варианте.