Драйвер управляет pci-девайсом с собственным чипом, осуществляющим обработку входного потока данных(tv-сигнал). Как чип обрабатывает данные мне не подходит. При дизасс. драйвера нашел точку вида mov eax,[указ.на буфер] с входными данными. Задача: использовать этот буфер в моём приложении (самому обрабат. эти данные), в реал. времени. Прошу подсказать о возможности решения задачи, и , если да, то в каком направлении рыть
Нужно установить железный бряк на чтение из этого буфера. Для этого нужно запустить первичный процесс с параметром DEBUG_PROCESS. Типа так: Код (Text): invoke CreateProcess, offset sProc1, 0, 0, 0, 1, DEBUG_PROCESS, 0, 0, offset StartupInfo, offset ProcessInfo Потом устанавливаем железный бряк на чтение из этого буфера. И ловим отладочные события. это мое имхо.
Наверно, неточно сформулировал, уточню : Упрощеная блок-схема: Win-интерфейс <--- Чип+микроконтроллер ^A<--- Dig-тюнер < ^ --- упр.драйвер--^ В sdk для девайса нет метода получения всего потока в (.) А, только после обработки в чипе. Есть подозрения, что возникают ошибки ( теряются пакеты ) из-за недостаточного быстродеиствия чипа ( при большой скорости вх. потока). При увеличении частоты шины pci ошибки пропадают (up to 38-40 MHz). Есть исходники драйвера другого автора.Не смог определить , где учитывается clk шины. Точно известно, что основная синхронизация обработки осущ. по входному сигналу. Поэтому для проверки хотел бы получить поток в точке А, в реале, параллельно с драйвером в своё приложение для дальнейшей обработки по своему алгоритму.
Теперь уже я нефкурил, чем же тебе такой способ не нравится. Твоя программа будет являться отладчиком для "упр.драйвера", тоесть "упр.драйвер" и дернуться без твоего разрешения не сможет. Ты ставишь железный бряк на этот буферок и при каждой попытке чтения из него, будет происходить отладочное событие, и управление будет передаваться твоей проге. Ты данные из буфера прочитал, обработал и отдал управление "упр.драйверу" и он покатил себе дальше, пока снова не обратится за данными в буфер. Одно меня смущает - слово "драйвер". Если это действительно ринг0 драйвер, тогда Debug API отдыхает.
1.Упр.драйвер - управляет драйвер(чипом и интерфейсом, ну там DShow) 2.В том то и смысл, присосаться к процессу в ринг 0, что-то типа ReadProccessMemory
