при синхронизации по VBlank, ScanLine используется как таймер с частотой FPS * DisplayMode.Height для прогнозирования времени которое осталось до VBlank. Когда время вычислено, если его достаточно, то делается Thread.Sleep
Кроме того момент VBlank засекается по системному таймеру и если на следующем ожидании кадра окажется что прошло время равное или большее чем frequency / FPS, то обновляется время последнего VBlank и производится немедленный возврат, чтобы попытаться успеть.
Идея с прогнозированием времени для Thread.Sleep подсмотрена в unrealТолько в unreal для прогнозирования используется ненадежный RDTSC. А у меня системный таймер.
Может возникнуть проблема, если DirectX говорит одну частоту FPS, а на самом деле другая. Или если реальный FPS сильно отличается от той, которую дает DirectX. Тогда время неточно прогнозироваться будет. Думаю можно сделать адаптивный алгоритм для коррекции реального fps путем замера реального времени между VBlank.
Кстати интересный вопрос - можно как-то узнать количество ScanLines для текущего режима? Я сейчас тупо беру Height дисплея, что естественно не очень правильно, т.к. реальное число ScanLines больше Height, т.е. частота ScanLines вычисляется меньше реальной.
---------- Post added at 14:55 ---------- Previous post was at 14:45 ----------
я именно на ffmpeg и сделал, с помощью AForge.Videoприкручивание заняло минут 15-20, включая загрузку библиотек
Проблемное место с видео - как писать видео, если меняется разрешение экрана. На лету разрешение видеофайла не поменяешь. Думаю в таких случаях можно начинать писать следующий файл после каждой смены разрешения, например test.mp4, test.1.mp4, test.2.mp4, test.3.mp4 и т.д. Или просто прекращать запись.






Только в unreal для прогнозирования используется ненадежный RDTSC. А у меня системный таймер.
Ответить с цитированием