Хабрахабр

Борьба за плавность отображения в системе видеонаблюдения: найти рывки и обезвредить

Закономерно, что с развитием продукта повышается и внимание к его качеству. Причем не только по части функционирования, но и в отношении пользовательской эстетики.

Присутствовали “рывки”, из-за которых страдала плавность отображения, что в итоге ухудшало общее визуальное восприятие. Несколько лет и версий назад мы столкнулись с недостаточным качеством отображения видео в Macroscop.

Причин же тому может быть много, так как видеосистема состоит из многих компонент, и софт — лишь одна из них. Когда пользователь видит, что изображение не экране “дергается”, его мало волнует, чем это обусловлено. Но мы должны были сделать все, чтобы Macroscop со своей стороны отображал максимально плавно.

В этой статье мы расскажем, какую метрику используем для измерения плавности и с помощью какого инструмента ее оцениваем. А для этого разработчикам необходимо было четко понимать задачу с измеряемыми требованиями, а группе качества — иметь инструмент для оценки.

#спойлер

Итак, как определить, плавно отображается видео или неплавно?

— сравнить то, что мы видим в клиентском приложении с “родным” отображением ip-камеры. Что сходу приходит в голову?

И первое решение — оценка группой экспертов: выбираем несколько человек, показываем им видео и просим оценить его на предмет рывков.

В определенной степени действенное, но очень времязатраное и слишком субъективное для практического использования. Это решение “в лоб”. Собирать экспертов каждый раз, когда группа качества получает от разработчиков очередной прототип, совершенно нецелесообразно.

Вместо субъективной оценки “нравится- не нравится” надо было найти критерий плавности или ожидаемое поведение продукта, которое можно зафиксировать.

Этот критерий был сформулирован так: для плавного отображения достаточно, чтобы каждый кадр выводился на экран монитора.

Новый метод измерения “неплавности” состоял в следующем: создаем и выводим на монитор видеоролик с последовательностью цифр (каждая цифра в отведенной для нее части кадра) или секундомером, снимаем отображаемое видео на IP-камеру, прогоняем через Macroscop, снова отображаем и снова снимаем уже с помощью другой камеры (камеры смартфона, go pro и т.д.). В соответствии с ним появилось второе решение.

Способ трудозатратный (попробуйте покадрово разобрать ролик со стандартной для IP-камеры частотой в 25 fps! Ожидание. Результирующее видео покадрово разбираем: считаем количество задержавшихся или пропущенных кадров (цифр) и получаем, сколько было рывков. за минуту это без малого 1500 кадров), но, казалось бы, объективный.

Стандартная ip-камера выдает поток с частотой ~25fps, монитор ~60fps, камера смартфона ~30fps. Реальность. На практике все получилось не совсем так. Поэтому иногда в момент считывания видео любой из камер на мониторе происходила смена кадра. Оказалось, что кроме того что частоты кадров не кратны, камеры и мониторы не работают синхронно. В результате он “смазывался” и цифру на изображении было невозможно разобрать.
Таким образом, второй метод тоже не подошел.

Хотелось оценивать только внешнюю составляющую — ровно то что видит пользователь, для которого вся система является “чёрным ящиком”. Были еще варианты программного захвата или сбора статистики самим клиентским приложением, которое отображает видеопоток, но и их мы отбросили.

Итогом наших поисков стало аппаратное решение — стенд на основе микроконтроллера.

Все устройство помещено в светонепроницаемый короб, чтобы исключить влияние внешних источников света. Он включает в себя полотно с 12 светодиодами, которое снимает видеокамера, и полотно с 12 фотодатчиками, которые накладываются на монитор, отображающий видеопоток с этой камеры, и фиксируют световые сигналы.

Устройство выводит на светодиоды определенную последовательность паттернов, считывает результат и записывает его в отдельную строку отчёта.

Так, например, для камеры с частотой 25 fps смена происходила раз в 1 кадр или в 40 мc (на 20 мс загорался паттерн, на 20 мс потухал, затем загорался следующий и т.д.) Светодиоды отображают определенный узор световых сигналов с некоторой частотой.

Вот как, по нашим ожиданиям, должна была выглядеть зафиксированная последовательность из 8 паттернов: Мы ожидали, что камера захватит именно то, что видит глаз, или даже собственные фотодатчики стенда.

Каждый раз светодиоды воспроизводили одну и ту же последовательность сигналов, но в отчетах эта последовательность иногда нарушалась: присутствовали кадры, которых не должны было быть (на них активными были светодиоды из двух соседних паттернов).

Мы экспериментировали с разными IP-видеокамерами и оказалось, что наиболее четкие кадры давала камера 25 fps с прогрессивной разверткой (в отличие, например, от варианта с 50 fps с чересстрочной разверткой), при этом она минимально нарушала последовательность кадров при передаче по сети.

Так или иначе, избавиться от артефактов полностью нам не удалось- часть кадров приходила с запозданием или сливалась с другими, но на самом деле рывками это не являлось.

То есть восстановить сигнал со светодиодов в нашем случае можно надёжно только для частоты 12,5 fps, что соответствует 80мс. На помощь пришла теорема Котельникова, согласно которой для восстановления аналогового сигнала частоты f требуется частота отсчета не менее 2f.

В результате

В результате реализованное нами аппаратное решение позволило фиксировать рывки, соответствующие задержке кадров от 80мс и выше, которые как раз существенно ухудшают восприятие отображаемого видео.

По настоящий момент мы регулярно применяем его при регрессионном тестировании каждого нового релиза. Метод результативен, решает задачу обнаружения рывков, а также благодаря автоматизации он требует минимальных затрат времени и сил группы качества.

Собранный стенд позволил быстро оценивать плавность отображения при любых параметрах системы (разной пропускной способности сети, разной производительности оборудования для обработки и отображения). В итоге (хоть и потратив много времени) для субъективных критериев плавности/неплавности мы получили вполне объективный метод измерения. К тому же, он не имеет привязки к приложению Macroscop, поэтому с его помощью мы тестируем и десктопный, и мобильный, и веб — клиенты.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть