>[оверквотинг удален]
>1. Создать очередь кадров.
>2. Вычислять сумму двух соседних строк в кадре.
>3. Сохранять и сравнивать с подобным в следуюзем кадре.
>
>Дело в том, что если картинка "подвисла" то эти суммы будут одинаковы
>для всез последующих кадров подвисшей суммы. Если же картинка просто постоянная
>(заставка какая-нибудь) то колебания яркостной составляющей все-таки будут (хоть и в
>небольших пределах). Глаз этого не регистриреут (изменение яркости отдельных пикселей на
>единицу), а математика - да. Поетому подвисшую картинку вычислить легко.
>Выглядит оптимистично и на первый взгляд просто :)
>Если же посмотреть со стороны реальных картинок, то дельта двух строк невелика,
>если соседние кадры принадлежат одной сцене (вероятность попадания двух абсолютно горизонтальных
>линий разной яркости в соседних строках лежит в пределах допустимой погрешности
>любого прибора).
>Для избежания ложных срабатываний детектора по двум соседним кадрам, его (детектор) необходимо
>дополнить сравнением с третьим (например через 2 кадра до текущего). Таким
>образом мы сможем диагностировать появление шума/изменение сцены.
>
>Другой вопрос состоит в том, что это требует определенных вычислений (не таких
>маленьких, как может показаться).
этот вопрос конечно волнует, но машина будет заниматься только этим... можно QNX на нее водрузить...
а что делать со звуком?
вот мне написали:
>1. Пусть копает в сторону DirectShow SDK
>2. Вычитывать стрим напрямую, без всяких тулзов
>3. Задача может быть нерешима если в стриме в зонах "пропажи звука" звуковая дорожка на >самом деле не прерывается а всего лишь забита нулями, т.е. бок оцыфровки. Можно >ориентироваться на децибели, но тогда каждый момент тишины будет восприниматься как >пропажа звука.
Вариант для распечатки
Программирование под UNIX (Public)
(ok) on 24-Мрт-08, 13:33 
