Беспроводная передача видео в full HD
если сниферить сигнал с карточки того же гоупро? ведь он там уже сжатый…
Дык, много раз была мысля сия.
Но задержка там секундами измеряется. 😦
Но задержка там секундами измеряется.
Откуда такая инфа? Где эти данные шляются столько времени?
Проц либо успевает сжимать данные в реальном времени либо не успевает.
Вспомните, через сколько времени после остановки записи ГоПро подтверждает это писком.
Насчет скорости сжатия - посмотрите любой стандарт сжатия, что такое опорные кадры и кадры изменений и почему 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мс.
Но дело в том , что для эффективного сжатия необходима информация из будущего, и чем ее больше, тем эффективнее сжатие. И вся “красивость” картинки гоупро завязана на “психовидеовосприятие” , т.е ее кодек заточен не столько на сохранение информации в кадре, сколько на положительные эмоции зрителя 😃 . В общем что-то типа “теплого лампового звука” , только в видео варианте.
На самом деле, мы можем каждый кадр сделать ключевым, кодер H264 это позволяет делать.
но нам от этого лучше не будет- битрейт будет зашкаливать и получим уже mjpeg
и во всех новых кодеках идут уже B кадры, соответственно не получив оба ключевых кадра мы не сможем воссоздать картинку. а для двух ключевых кадров уже нужно время на два.
т.е. Если Каждую секунду делая ключи мы получим 2 секунды задержки.
Ну и не забываем, что у нас очень динамические сцены, на них H264 почти бесполезен, каждый кадр у нас “новый”.
т.ч. по любому нам нужен MJPEG как не крути.
Абсолютно верно Дмитрий! вы меня опередили.
Надо учитывать, что опорный кадр для стационарно закрепленного на столбе камеры видео наблюдения одно дело а для установленного на боту подвижного аппарата совсем другое дело. Он практический каждый раз новый! причем, чем больше горизонтальная скорость и ниже высота полета, тем чаще!
Соединил телек и проигрыватель через обычные аналоговые выход и вход
Вот в этом и кроется секрет.
Если бы вы соединили устройства с помощью HDMI щнура, тогда бы разницу и увидели бы.
Ну и не забываем, что у нас очень динамические сцены
Как раз таки сцены у нас разные, взлёт, посадка, низко, близко - динамические, но если набрать высоту 100м, где не колбасит, то наоборот, так вот нет ли алгоритма, который адаптируется под эту “динамичность”: на взлёте минимум разрешения и сжатия => задержка меньше, а на высоте HD, пусть с задержкой, не все пилотаж крутят.
нужен MJPEG как не крути
Интересное обсуждение, респект участникам.
Ну и не забываем, что у нас очень динамические сцены, на них H264 почти бесполезен, каждый кадр у нас “новый”.
h265 примерно в 2 раза лучше жмет, чем h264.
Правда и требования к аппаратной части пропорционально вырастают.
Чтобы два раза не ходить:
“M-JPEG is an intraframe-only compression scheme (compared with the more computationally intensive technique of interframe prediction). Whereas modern interframe video formats, such as MPEG1, MPEG2 and H.264/MPEG-4 AVC, achieve real-world compression-ratios of 1:50 or better, M-JPEG’s lack of interframe prediction limits its efficiency to 1:20 or lower, depending on the tolerance to spatial artifacting in the compressed output. Because frames are compressed independently of one another, M-JPEG imposes lower processing and memory requirements on hardware devices.”
неплохо, на какое расстояние оно интересно передаёт