Видеозахват и штатный монитор
 

Добрый день,
Хотелось бы узнать мнение специалистов по поводу следующей идеи.

В автомобиле есть штатный монитор, на который головное устройство передаёт различные картинки (климат контроль и т.п.). Почитав форумы, обнаружил, что обычно подключая компьютер к штатному монитору делают аппаратное переключение видео сигнала между головным устройством и компьютером.

А можно ли попробовать ввести изображение от головного устройства в компьютер через плату видеозахвата*)? Зачем... Ну, хотя бы, чтобы выводить эти картинки от головного устройства куда-нибудь в окно в уменьшенном размере (а не вместо изображения от компа), или вообще заменить монитор на другой, или как-то процессить их, если захочется. Несколько фпс вполне хватило бы для этой задачи.

Но поскольку с видеозахватом я пока еще не сталкивался, вот и решил вопросить...

вот небольшой анализ ситуации, как я представляю...


Поскольку мы имеем дело с видео высокого качества и разрешения (предположим 800 на 400), естественно в формате RGB, ну точно не RCA, то во-1х нужна плата, которая умеет вводить компоненты по отдельности, а во-2х возникает вопрос с кодеками.

Платы на чипсете Коннексант вроде имеются: http://www.bvm-store.com/ProductDeta...dProductId=593 (~$50), есть и на ЮСБ, есть на ЮСБ вообще за $15 и вроде с компонентными входами, но что-то там должно быть не так.. Интересно, эта плата сильно будет искажать видеоизображение от головного устройства? ИЛи это кодек.. насчёт кодеков не всё понятно...

В идеале, если я получаю картинки с головного устройства, хотелось бы их получать с максимальным качеством, без сжатия и соответственно потери качества. Хотелось бы, чтобы пиксели как они отображаются головным устройством, так и я их мог получить программно, ну допускаю небольшое отклонение по цвету, но не по качеству картинки. Эти картинки чаще всего статические, и в этом случае не хотелось бы тратить ресурсы на МПЕГ4-вание этих картинок (карты с аппаратным сжатием не рассматриваем по причине их хайендовости, да и не хочется сжатие). Есть интересные кодеки для таких целей e.g.: http://www.compression.ru/video/ls-codec/index_en.html - специально созданные для кодирования видео с монитора.

Всё бы хорошо, но возникает вопрос - а если головное устройство "вздумает" показывать картинку с камеры ЗХ, или там еще что-то не статическое, этот кодек как будет работать? Было бы интересно, чтобы кодек умел в этом случае начать кодировать с сжатием, к примеру, если картинка меняется слишком часто. Есть ли такие кодеки?

И те кто писал программы видеорегистрации и иже с ними.. Как работать с видео потоком из С++, какой лучше всего библиотека/интерфейс использовать? Он же не зависит от кодека, правильно? Допустим мне хотелось бы проверять, что изображение не меняется (фоновая картинка головного устройства), но как только она поменялась, скажем с задержкой в 200мс начать отображать картинку в окне? Как примерно это делается программно в винде (я в Линуксе работаю уже несколько лет) - я так понимаю, должен быть доступ к байтам видео стрима в буффере кадров на Н? Алгоритмы анализа видеоизображения я представляю, вопрос скорее как с этим стримом работать..

Идея пока что только идея, так что если грамотно аргументируете ее несостоятельность, то с благодарностью приму такой совет и сделаю как все - аппаратный коммутатор видео входов. Но хотелось бы рассмотреть варианты. Я еще даже мат.плату не выбрал, проекта как такового еще нет, пока изучаю опыт других. Заранее благодарен за ответы!

Нужно не забывать, что изначально родные головы транслируют видео убогое, типа 240p. И только в последние годы автопроизводители "доросли" до 480p :)

Вообще, новички часто задавая вопрос задают его где-то из середины, а то и с конца :)
Что конкретно хочется получить, т.е. задачу опиши полностью.
А то пока это похоже на прикручивание синхрофазатрона к сковородке для того, чтобы банально разбить яйцо и приготовить завтрак.

Зачем вообще кодеки? Что ты кодировать/сжимать собрался? :) Или планируешь поток с родной головы записывать на носители информации? :)

Спасибо, Вы правы, пока еще сам плохо разобрался в теме. Сейчас попробую сформулировать...

Задача: хотелось бы выводить на штатный*) монитор в окне программы обработанную видео-информацию от головного устройства (ГУ). Обработка видео следующая:
- открытие окна с видео от ГУ, если изображение от ГУ поменялось с "основного", сворачивание, если опять основное.
- возможность масштабирования этого изображения под фиксированный размер окна, замена цвета по маске.
- Pattern match изображения с ГУ по маске, и запуск определяемых пользователем действий. То есть типа "если картинка - данные климат контроля (проверяем по предопределенным ключевым пикселям), то развернуть окно до размер Хэ на У и показать". Более сложный пример - "показать другую картинку с наложением части исходной".
*) Штатный монитор возможно захочется заменить на другой более высокого разрешения с тач скрин, который влезет в нишу от существующего (присматриваюсь к pixelqi матрицам).

Записывать видео с ГУ вроде не нужно. Я просто думал, без кодеков вообще не завести видео в комп, оно же большое - никогда с этим не сталкивался. Вот стал изучать, наверное не с того конца:( Подскажите, куда посмотреть!

Это одна из основных задач компа, другие вполне стандартные вроде бы. Имеет смысл их озвучить так же? А то вдруг тоже синхрофазатрон ни с того конца :shame:

Ага, мысль в принципе понятна. Не понятно ее жизненное применение, ну да ладно :)

Чего там масштабировать на штатном монике с разрешением типа 400х240?
И так в винде не увидишь ничего :)
Моник менять однозначно.

Ну, оперативная память в современных компах тоже не маленькая :)
400х240х24бит = 281 килоБайт. 24 бит наверное даже сильно дофига для штатной картинки, там 256 цветов за глаза, тогда снимок будет 94 килоБайта.

По сути - тебе нужно сделать motion detect и выводить картинку по обнаружению этого "движения". Для програмера задачка простенькая, тем более что по motion detect есть куча библиотек под разные платформы.

Вы путаетесь в определениях:
1. штатный монитор, это сама матрица. А где она будет, хоть в багажнике лежать, она все равно останется штатным монитором.
2. монитор карпса(от слова CarPC), это матрица, железяка, которая подключена каким то образом к компу.
3. Штатное место - это та дырка, в которой с завода стоит монитор.
4. Штатная рамка - часть декора, в которую вставлялся штатный монитор.

Я надеюсь эти знания позволят вам задать правильный вопрос.
А согласно тому, что я понял, у меня сть вопрос. Вы знаете каким образом, технически, подключается штатная матрица к системе?

Hamster,
Жизненное применение, думалось, удобное отображение информации от ГУ внутри оболочки карписи по необходимости. Вместо переключения кнопкой/коммутатором на ГУ. Поскольку всё в ГУ управляется кнопками на панели, то переключение кнопкой кажется не удобным. С другой стороны показывать информацию от ГУ постоянно тоже не хочется, ибо там лого ниссана в основном:), вот и идеи с открытием окна и т.п. А как бы ВЫ сделали?

Вы скорее всего правы насчёт маленького разрешения штатной матрицы. Я еще не проверял, какое разрешение у меня, потому что не могу никак понять, как разобрать этот монитор или консоль:((

kostya740, спасибо, матчасть буду учить. Идея была попробовать использовать штатную матрицу, и если она слабовата, заменить её на более путёвую.
Вот примерно как выглядит всё штатное:
http://img03.carview.co.jp/trade/img...1372572/18.jpg
Внутренний размер штатной рамки 234 на 128 мм.
Штатная матрица имеет видимый размер 178 на 100 (т.е. там еще чёрная рамка внутри)
Подключается по LVDS к контроллеру, который имеет композитный (RGB) u RCA входы, которые уходят в ГУ.

Более глобально, мой план действий был бы следующий:

1. Разобрать это штатное место, или консоль, чтобы найти видео входы (с этим и застрял). По инфе с форумов, там должен быть композитный вход со смешанной синхронизацией.
2. Померить сигнал на видео входах осциллографом для определения параметров (нужен осцилограф однако)
3. С помощью утилиты павер стрип (и возможно схемы смеси синхросигналов) подключить свой настольный комп к монитору, определить разрешение и пригодность его для карписёвых целей.
4. Если нужна замена монитора, искать замену в виде карписьного или индустриального монитора без корпуса с тачем, который влез бы в штатное место. При этом вся логика с камерой ЗХ уже есть в ГУ, нужен обычный VGA видео вход. Иначе искать тач скрин под штатное место только.
5. Определиться с вводом видео от ГУ (что и пытаюсь сейчас). Зная какой видео сигнал от ГУ подобрать плату видео ввода чтобы с минимальными доработками завести видео сигнал от ГУ в комп. Определиться с софтом - вряд ли есть готовое решение. Протестить простой ввод и обработку изображение, померить ресурсы процессора настольного компа.
6. Хотелось бы использовать второй монитор под крышей для видео, просмотра фоток - определиться надо ли оно через комп. Если да, искать видео карту с двумя видео выходами и программку, чтобы легко перетаскивать на второй монитор приложения.
7. Остальный фичи кар писи вполне стандартные: навигация еще не знаю какая- местная нужна, "звонилка" дла хэндс фри телефона, прослушивание аудиокниг (никакого навороченного карзвука), изредка фильмы на двд, хотелось бы уметь показать изображение со стационарых камер в гараже во время парковки (узкий гараж), диагностика по OBDII (не во время движения), просмотр фоток с путешествий с флешки, интернет можно через мобильник, вроде бы и всё.
8. Теперь зная результаты 5,6 подобрать мат плату, проц и комплектующие для кар писи.
Место для корпуса карписи вроде есть под консолью под радио. Как разберу, замеряю пространство. Куда-то надо будет юсб вытащить еще. Температурный режим здесь от 0 до +50, так что охлаждение важно., но может куда и в -10 выберусь И вообще хотелось бы как можно более экономичный конфиг.

Подскажите, если ошибаюсь в чём.

Лучше на "ты" :)
Как я уже сделал можно посмотреть в проекте по Acura MDX в подписи.
Я исходил из того, что нет необходимости часто смотреть на инфу со штатного компа, ибо инфа с климата дублируется на маленьком дисплейчике. Соответственно для того, чтобы увидеть штатный комп надо нажать кнопку на пульте.
Преимущества такого решения - оно "железное", т.е. для его работы не нужен комп вообще. Коммутация сигнала с ГУ осуществляется отдельной железкой напрямую в монитор. Ну и сильно дешевле и проще варианта с программной обработкой видео от штатной головы :)

Это я тебе и так скажу :)
Судя по дизайну машина старше 2010 года (я подозреваю 2002-2004). С вероятностью 99% там стоит матрица с низким разрешением.
Учитывая подключение к ней по композитному входу (который не добавит четкости мягко говоря :) ) использовать ее есть насилие над организмом.
В винде стандартный текст прочитать не получится.
Если использовать фронтенд - в принципе потянет, ибо кнопки и шрифты там крупные.
Но, учитывая стоимость современных матриц (от $50-60 за TN 800х480 с тачем) проще поменять :)

Логику КЗХ из ГУ не использовать :) Взять только сам сигнал REVERSE. В контроллере матрицы карписишного монитора такая логика тоже есть. И тоже, в таком случае будет работать самостоятельно, без компа.

Все же я за "железное" решение. Потому что оно простое, надежное и оно есть :)

Вот это как раз более надо, чем софтовая обработка сигнала от ГУ :)
Учитывая, что на потолочном мониторе разрешение тоже низкое - вполне достаточно иметь на материнской плате выход TV-OUT. Ибо если будет вторая видеокарта - все равно придется конвертировать VGA в композитный сигнал, на потолочном мониторе VGA нет :)
Для фоток и фильмов пойдет.
Поддержка второго монитора есть в винде, никаких программок не надо.

Плохой вариант для новичка. Дело в том, что даже если ты 100 раз все проверишь и потестируешь дома - велик шанс, что комп придется снимать/разбирать/уносить домой и т.п.
Поэтому лучше иметь к нему простой доступ - иначе задолбаешься консоль разбирать постоянно :)

Привет, спасибо за развернутый ответ! Начал читать о твоем проекте!
Полностью согласен! Сам люблю простое решение. Действительно, смотреть на эту штатную инфу часто не приходится. Но есть пару нерешенных вопросов... 1. ГУ иногда само по себе выдает инфу (без нажатия на кнопки), чаще всего, если проблема, ну или сервис интервал, если им пользуешься. Бывает она потом пропадает через несколько секунд, а между тем, сообщение может быть важным (такое действительно наблюдалось). Ну и тот же климат контроль другого экрана не имеет, появляется по кнопке, исчезает по таймеру.
2. Всё это - на родном самурайском языке! Перепрошивать ГУ пока еще не научились по ряду причин. А если научатся, то будет вряд ли бюджетно.

Вот и зародилась идея иметь такой фунционал: по смене картинки от ГУ показать её. Более того, если такой картинки нет в базе, и она висит более Х мс и не меняется, записать скриншот на диск. Это чтобы не постить на форум эльграндов сообщения типа "мужики помогите что у меня за %%%% вот на мобильник сфоткал но ничего не видно, она пропала". Далее в свободное время переводим картинку на родной язык и добавляем пэттерн распознавания её (благо пиксели одни и те же за исключением там часов всяких, которые по коорд маске выкидываем). В след раз картинку видим на родном языке. Делимся базой картинок с другими сумасшедшими эльграндоводами, кто поставит себе такой же софт, получаем коллективную руси/англо/***фикацию ГУ, со временем полную. Прога может быть полезна для других авто. Добавляя алгоритмы распознавания, можно распознавать картинки с камер, направленных на спрятанные монохромные дисплеи (кто-то из ветеранов форума так делал где-то) или приборы.

Может оно и не стоит заморачиваться, но как-то обидно иметь комп и ничего не сделать с этими ёроглифами. А может разветвить сигнал от ГУ на прямой к второму видео входу монитора и на плату видеозахвата, только наверное схемка нужна будет. Так что если комп не работает, то ГУ можно посмотреть кнопкой переключения видео входа монитора всегда? Или вообще пока без видеозахвата сделать первый этап, но заложить под него ресурсы на второй этап...?