| Объявление форума |
Если пользуетесь личными сообщениями и получили по электронной почте оповещение о новом письме, не отвечайте, пожалуйста, почтой. Зайдите на форум и ответьте отправителю через ЛС. |
Полигон-2 » Прочее » Видеозахват на тройке |
 |
Видеозахват на тройке
Собственно
| <<Назад Вперед>> | Страницы: 1 2 3 * 4 5 | Печать |
| mb
Newbie
Откуда: Kostroma Всего сообщений: 123 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 28 сен. 2006 |
Ну типа из 5 бит сигнала яркости делает 3 бита...По принципу типа звука PCM>ADPCM? Не помню что бы видео так сжимали, будут сильные артефакты на контрастных переходах. |
| fmulder007
Full Member
Откуда: Хабаровск Всего сообщений: 272 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 1 мар. 2006 |
mb Я понятия не имею, как там звук сжимали... Можно вычислить несколько контрольных сумм видеопотока и передавать только их... А потом по ним восстанавливать... А вообще вчера посчитал скорость потока для полосы в 4 мегагерца при 25 кадрах в секунду(качество vhs) и получилось около 1015 килобит в секунду. Такую скорость порт обеспечивает без проблемм! И ещё... Где есть нормальный мануал по VGA видеоадаптеру... Видеорежим переключать буду через биос (int 10h) - так прощще. Только у меня нормальная дока по EGA. Я пробовал на её основе сделать прогу - не рисует она точки... Если найду нормальное описание VGA адаптера с портами, регистрами... Geners Схема уже лежит... АЦП таким и будет. В Data посылается цифровой код яркости (0 соответствует чёрному, 10000 соответствует белому) в параллельном виде. На любые другие входы порта подаётся 1 в момент начала новой строки и 1 в момент начала нового кадра. Прога должна [B]сама просчитывать количество элементов изображения в строке! Соответственно нужно чтобы прога точно генерировала задержку времени, а затем опрашивала байт яркости и выводила его на место следующего элемента.[/B] То есть - в pal и secam длительность одной строки равна 64 микросекунды! Если мы хотим использовать 320 на 200 точек на экране - надо 64 микросекунды разделить на 320 точек в строке = 200 наносекунд. Эта задержка должна быть постоянной и точной! Видимо придётся использовать какой-то таймер... Как это делать - я не представляю... 1:перевести дисплей в видеорежим 2:проверить сигнала нового кадра Если да - присвоить y = 0 3:ждать сигнала новой строки 4: for Х = 0 to 320 считать байт яркости Привести байт яркости к виду вывода в видеопамять Записать байт яркости в видеопамять по позиции Х подождать 200 наносекунд повторить X увеличит У на 1 Повторить со строки 2 Должно получиться примерно такое. Для облегчения процесса, можно подавать байт яркости на LPT сразу в виде байта для записи в видеопамять... Переделать схему можно легко! Зато избавим проц от лишних преобразований... Остаётся найти мануал по VGA... |
| Geners |
NEW! Сообщение отправлено: 24 сентября 2007 16:57
fmulder007 знаешь что , наверно я таки сделаю другу схему АЦП , мож выйдет подороже НО эффективней ... а также начну работу над шинным вариантом А вообще уже закинул АСМ на ноут и начал ковыряться (Сообщение отредактировал Geners 24 сен. 2007 15:59) |
| Сейчас на форуме |
| Geners |
NEW! Сообщение отправлено: 24 сентября 2007 17:36
или я че недогоняю или ..... но На любые другие входы порта подаётся 1 в момент начала новой строки и 1 в момент начала нового кадра.А следом Прога должна сама просчитывать количество элементов изображения в строке!???? если мы сигналим когда строка законцена зачем еще доролнительно считать ??? считать надо в том случаи если нам не сигналит или мы проверяем ..... Потом если ты решил писать на уровне биоса , то хочу сказать что это наоборот медленней ..... Тогда надо писать на уровне железа и выводить прямо в видео память раскидывая сразу яркость по страницам |
| Сейчас на форуме |
| fmulder007
Full Member
Откуда: Хабаровск Всего сообщений: 272 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 1 мар. 2006 |
Geners Когда прога видит строчный синхроимпульс она должна начать выводить на экран биты яркости в одну строку. И до наступления следующего синхроимпульса есть всего 64 микросекунды! За это время прога должна опросить порт 320 раз! И сделать это должна точно! То есть если бы у нас были такты каждого пиксела... Появилась проблемма: На входах порта в режиме input напряжение равно 1! И чтобы записать туда 0 надо закорачивать их на землю! А в схеме моего АЦП подразумевалось что на входах всегда 0... Сегодня попробую пошунтировать каждый вход резюком. Может смогу сделать там 0. Это чтобы ты знал!!! То есть если к этим входам подрубить TTL выход, не факт, что при 0 удастся перевести вход в 0. Кстати почти все траблы с софтом решил.. Прога почти готова... Загвоздка тока в том, что надо организовать точную задержку перед выводом следующего пиксела, и в том, что цикл у меня пока организован ПАСКАЛЕМ! Пока на асме цикл сделать не хватает мануалов... Остаётся ещё трабла, не главная пока... Как видео сохранить на винт?! Geners Поделись своими соображениями по поводу АЦП? Если будешь делать вариант на шине, можно вообще юзать VESA... Ну или если ISA 8 или 16 бит, то можно обойтись вообще без преобразования... Раскладываешь сигнал на уровни, и подаёшь каждый на бит данных... Там скорость хорошая и можно декодировать сигнал процом. Можно даже на плату прототипа запихать 512 метровый модуль памяти от флешки и микроконтроллер... Вариантов куча... Но не забывай : Собранный на кп350 логический элепент или триггер будет работать спокойно на частоте до 800 мегагерц!!! А вот микросхемы дохнут намного раньше!!! При наличии у меня сотни резисторов на 1 кОм я лучше собрал бы свой АЦП на дискретных элементах. А щас сижу и гадаю, справится ли ЛП5 с частотой 4,5 мегагерца... Или нет... |
| Teodor
Гость
Старый опытный камикадзе Откуда: Николаев, Украина Всего сообщений: 4022 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 16 янв. 2006 |
fmulder007, а почему X от 0 до 320? Если хватаем PAL625, то четверть кадра - это 384 x 288. Если с кропом - 360 x 270 и нужно 12 элементов пропустить, потом 360 захватить и снова 12 пропустить. А разрешение 320 x 240 - это NTSC без кропа. |
| mb
Newbie
Откуда: Kostroma Всего сообщений: 123 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 28 сен. 2006 |
fmulder007 Звук сжимали с 16 бит до 4 бит упрощенно говоря путем вычисления разницы между уровнями соседних остчетов (добавлялось по 4 бит за отсчет, поскольку синусоиды наростают чаще всего плавно, а общий диапазон оставался 16 бит), но на участках с резким изменением уровня не хватало 4 бит для передачи фронта импульса без искажений, но поток сжимался в 4 раза без сильной загрузки процессора. Формат ADPCM использовался до появления mp3 А вообще вчера посчитал скорость потока для полосы в 4 мегагерца при 25 кадрах в секунду(качество vhs) и получилось около 1015 килобит в секунду.И как это расчитывалось? У меня получается расчет без сжатия при четверти полного кадра - 384х288х25х5бит=13824 килобит в секунду (это средний, а реально ещё в 2 раза выше в момент захвата полукадра, а потом пауза на следующий полукадр) (0 соответствует чёрному, 10000 соответствует белому)А почему не 11111? в pal и secam длительность одной строки равна 64 микросекунды!60 мкс изображение + 4 мкс синхроимпульс Ещё надо обдумывать моменты: Как 288 строк полукадра PAL выводить на 200 сторк монитора |
| Geners |
NEW! Сообщение отправлено: 26 сентября 2007 15:39
fmulder007 я предлагаю использовать 1 - место всей твоей монструозности CA33306Ce (чатота преобразования 15 мгц , точность 6 бит , 64 кормпаратора ) схема включения очень простоая и требует только 241 логики , в количестве 1 корпуса 2 - если изготовлять для шины то разумней взять Icl7109 , тк она имеет 12 бит на выходе , соответвенно полностю реализует возможности иса .... но тут есть одно но , 7.5 преобразований в секунду нам не хватит  ((поэтому предлагаю посикать микруху из первого варинта .. да и выигрышь в размерах и энергопотреблении будеть шикартный , не говоря уже о том что у тебя возникли сомнения на счет ЛП5 |
| Сейчас на форуме |
| fmulder007
Full Member
Откуда: Хабаровск Всего сообщений: 272 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 1 мар. 2006 |
Teodor Размер по горизонтали - не так важен... А вот по вертикали, можно кропить... Бегущую строку видно не будет!!!! Она так раздражает! Это пока не важно... mb Просто распаять 4 корпуса lm339 намного прощще, а второе - для совместимости со старыми LPT портами.. В них только 4 вывода работают на вход. Да и в палитре цветов режима 19(dec) цвета с 16 идут градиентом серого (кажется вплоть до 80) Поэтому переназначать палитру не придётся... Кстати ! Вчера разработал алгоритм архивации. Черезвычайно прост в аппаратной реализации и черезвычайно удобно выполняется восстановление в ассемблере. Teodor По горизонтали будем не кропить! Незачем! В строке видео нет жёстко ограниченных элементов. Дискретны только строки по отдельности! А вот по горизонтали можно растягивать сроку хоть на десять, хоть на 10000 элементов... Вопрос в удобстве восприятия. По вертикали можно в конце концов взять другой видеорежим Тока по моему в биосе нет поддержки 640х480х256 цветов из 256к Надо видюху напрямую заставлять работать в таком режиме... А для старых компов (386 и так с трудом даёт 15 раз в секунду перерисовать видеопамять!) |
| mb
Newbie
Откуда: Kostroma Всего сообщений: 123 Рейтинг пользователя: 0 Ссылка Дата регистрации на форуме: 28 сен. 2006 |
Ещё проблема: сразу передать с порта в видеопамять вряд ли получится, не совпадают частоты разверток. Нужно писать фрейм (кадр) в память, а в это время 2-3 раза (70гц/25гц=2,8) передать на экран предыдущий кадр. И вообще прямая запись в видеопамять это не есть режим "оверлей" случайно? Так у ISA карт оверлея не было, да и у первых PCI карт тоже. |
| <<Назад Вперед>> | Страницы: 1 2 3 * 4 5 | Печать |
Полигон-2 » Прочее » Видеозахват на тройке |
|
| 1 посетитель просмотрел эту тему за последние 15 минут |
| В том числе: 1 гость, 0 скрытых пользователей |
| Последние |
|
| [Москва] LIQUID-Акция. Сливаются разъемы CF МС7004 и 7004А на AT и XT Пайка термотрубок Проммать s478 PEAK 715VL2-HT ( Full-Size SBC) Подскажите по 386 материке по джамперам. | |
| Самые активные 5 тем |
|