Доброго дня.
Вообщем нужны идеи по поводу анализа качества видеопотока в unix системах... Смысл состоит в том, что бы анализировать на правильную картинку, на пропадание цвета-звука и т.д. Если по этой теме какие-нить разработки? Может что-то уже есть готовое? Есно, интересует свободные продукты....
>Доброго дня.
>Вообщем нужны идеи по поводу анализа качества видеопотока в unix системах... Смысл
>состоит в том, что бы анализировать на правильную картинку, на пропадание
>цвета-звука и т.д. Если по этой теме какие-нить разработки? Может что-то
>уже есть готовое? Есно, интересует свободные продукты....Я начинаю заниматься видео и, естественно, меня тоже интересуют подобные наработки. На данный момент ничего подобного не видел. Могу предложить свою техническую подготовленность для проработки вопроса (из всего вопроса плхо владею, пока что, только программированием - подтягиваю).
Наводящий вопрос, на каком этапе обработки видео необходимо проводить анализ?
1. Захват (формирование).
2. Предсжатие.
3. Распаковка.
4. Отображение.Я бы предположил, что:
1. Размер кадра должен быть кратным 16-ти... 720х576 например.
2. Суммарная дельта контрольных сумм соседних строк должна быть в каком-то пределе (если строки отличаются очень сильно - значит шум или помехи).
2а. Как вариант - деление строк на граммы и сравнение взвешенных сумм.
3. Вычисление гистограммы и пределов яркости.
4. Размер кадра в байтах в принципе может сказать, есть цвет или нету (в основной массе форматов передачи видео).
>>Доброго дня.
>>Вообщем нужны идеи по поводу анализа качества видеопотока в unix системах... Смысл
>>состоит в том, что бы анализировать на правильную картинку, на пропадание
>>цвета-звука и т.д. Если по этой теме какие-нить разработки? Может что-то
>>уже есть готовое? Есно, интересует свободные продукты....
>
>Я начинаю заниматься видео и, естественно, меня тоже интересуют подобные наработки. На
>данный момент ничего подобного не видел. Могу предложить свою техническую подготовленность
>для проработки вопросаОчень буду благодарен :)
(из всего вопроса плхо владею, пока что, только
>программированием - подтягиваю).
>
>Наводящий вопрос, на каком этапе обработки видео необходимо проводить анализ?
>1. Захват (формирование).
>2. Предсжатие.
>3. Распаковка.
>4. Отображение.Отображение....
>
>Я бы предположил, что:
>1. Размер кадра должен быть кратным 16-ти... 720х576 например.
>2. Суммарная дельта контрольных сумм соседних строк должна быть в каком-то пределе
>(если строки отличаются очень сильно - значит шум или помехи).
>2а. Как вариант - деление строк на граммы и сравнение взвешенных сумм.
>
>3. Вычисление гистограммы и пределов яркости.
>4. Размер кадра в байтах в принципе может сказать, есть цвет или
>нету (в основной массе форматов передачи видео).Смысл проги состоит в том, что надо контролировать качество потока со спутника, который уже поступил на комп (тв-тюнер).... Т.е., если нет звука-видео (подвисла картинка), то сообщить оператору....
Тогда действительно другого варианта я не вижу:1. Создать очередь кадров.
2. Вычислять сумму двух соседних строк в кадре.
3. Сохранять и сравнивать с подобным в следуюзем кадре.Дело в том, что если картинка "подвисла" то эти суммы будут одинаковы для всез последующих кадров подвисшей суммы. Если же картинка просто постоянная (заставка какая-нибудь) то колебания яркостной составляющей все-таки будут (хоть и в небольших пределах). Глаз этого не регистриреут (изменение яркости отдельных пикселей на единицу), а математика - да. Поетому подвисшую картинку вычислить легко.
Если же посмотреть со стороны реальных картинок, то дельта двух строк невелика, если соседние кадры принадлежат одной сцене (вероятность попадания двух абсолютно горизонтальных линий разной яркости в соседних строках лежит в пределах допустимой погрешности любого прибора).
Для избежания ложных срабатываний детектора по двум соседним кадрам, его (детектор) необходимо дополнить сравнением с третьим (например через 2 кадра до текущего). Таким образом мы сможем диагностировать появление шума/изменение сцены.Другой вопрос состоит в том, что это требует определенных вычислений (не таких маленьких, как может показаться).
>[оверквотинг удален]
>1. Создать очередь кадров.
>2. Вычислять сумму двух соседних строк в кадре.
>3. Сохранять и сравнивать с подобным в следуюзем кадре.
>
>Дело в том, что если картинка "подвисла" то эти суммы будут одинаковы
>для всез последующих кадров подвисшей суммы. Если же картинка просто постоянная
>(заставка какая-нибудь) то колебания яркостной составляющей все-таки будут (хоть и в
>небольших пределах). Глаз этого не регистриреут (изменение яркости отдельных пикселей на
>единицу), а математика - да. Поетому подвисшую картинку вычислить легко.
>Выглядит оптимистично и на первый взгляд просто :)
>Если же посмотреть со стороны реальных картинок, то дельта двух строк невелика,
>если соседние кадры принадлежат одной сцене (вероятность попадания двух абсолютно горизонтальных
>линий разной яркости в соседних строках лежит в пределах допустимой погрешности
>любого прибора).
>Для избежания ложных срабатываний детектора по двум соседним кадрам, его (детектор) необходимо
>дополнить сравнением с третьим (например через 2 кадра до текущего). Таким
>образом мы сможем диагностировать появление шума/изменение сцены.
>
>Другой вопрос состоит в том, что это требует определенных вычислений (не таких
>маленьких, как может показаться).этот вопрос конечно волнует, но машина будет заниматься только этим... можно QNX на нее водрузить...
а что делать со звуком?
вот мне написали:
>1. Пусть копает в сторону DirectShow SDK
>2. Вычитывать стрим напрямую, без всяких тулзов
>3. Задача может быть нерешима если в стриме в зонах "пропажи звука" звуковая дорожка на >самом деле не прерывается а всего лишь забита нулями, т.е. бок оцыфровки. Можно >ориентироваться на децибели, но тогда каждый момент тишины будет восприниматься как >пропажа звука.
>[оверквотинг удален]
>Если же посмотреть со стороны реальных картинок, то дельта двух строк невелика,
>если соседние кадры принадлежат одной сцене (вероятность попадания двух абсолютно горизонтальных
>линий разной яркости в соседних строках лежит в пределах допустимой погрешности
>любого прибора).
>Для избежания ложных срабатываний детектора по двум соседним кадрам, его (детектор) необходимо
>дополнить сравнением с третьим (например через 2 кадра до текущего). Таким
>образом мы сможем диагностировать появление шума/изменение сцены.
>
>Другой вопрос состоит в том, что это требует определенных вычислений (не таких
>маленьких, как может показаться).да, может не всем это интересно, тогда можем перейти в аську... если, конечно, у Вас есть время и желание...
не могу сказать, что со временем все просто, но уделять какое-то - могу, поетому 52995475.
>Доброго дня.
>Вообщем нужны идеи по поводу анализа качества видеопотока в unix системах... Смысл
>состоит в том, что бы анализировать на правильную картинку, на пропадание
>цвета-звука и т.д. Если по этой теме какие-нить разработки? Может что-то
>уже есть готовое? Есно, интересует свободные продукты....свободный видеокодек dirac и свободный формат хранения видео ogg.
> свободный видеокодек dirac и свободный формат хранения видео ogg.А что, видеокодек и формат хранения теперь уже стали анализом и диагностикой заниматься (может еще трекингом и детекцией движения)? Или ключевое слово _свободный_?
Или китайский детектор движения - это верх совершенства? (китайский детектор засунут во все аппаратные DVRы и выполняет функцию сравнения яркостного канала по двум соседним кадрам, если порог превышен - в кадре движение).Видеокодек, безусловно, анализирует видео. Но, увы, не в том ключе.
>> свободный видеокодек dirac и свободный формат хранения видео ogg.
>
>А что, видеокодек и формат хранения теперь уже стали анализом и диагностикой
>заниматься (может еще трекингом и детекцией движения)? Или ключевое слово _свободный_?
>
>Или китайский детектор движения - это верх совершенства? (китайский детектор засунут во
>все аппаратные DVRы и выполняет функцию сравнения яркостного канала по двум
>соседним кадрам, если порог превышен - в кадре движение).
>
>Видеокодек, безусловно, анализирует видео. Но, увы, не в том ключе.я про кодеки читал, тама много всяких нужных и приятных утилит есть, но это действительно не по задаче....
хотя их вполне можно использовать для подготовки кадров перед анализом :)