Естественно, что с развитием продукта возрастает и внимание к его качеству.
И не только с точки зрения функциональности, но и с точки зрения пользовательской эстетики.
Несколько лет и версий назад мы столкнулись с недостаточным качеством отображения видео в Macroscop. Были некоторые «рывки», которые влияли на плавность отображения, в конечном итоге ухудшая общее визуальное впечатление.
Когда пользователь видит, что изображение на экране «дергается», его не особо волнует, что является причиной этого.
Причин этому может быть множество, поскольку видеосистема состоит из множества компонентов, а программное обеспечение – лишь один из них.
Но нам нужно было сделать все, чтобы Macroscop отображался максимально плавно.
А для этого разработчикам нужно было четко понимать задачу с измеримыми требованиями, а команде качества — иметь инструмент для оценки.
В этой статье мы расскажем вам, какую метрику мы используем для измерения гладкости и какой инструмент используем для ее оценки.
#спойлер 
Итак, как определить, плавное или нет видео?
Что сразу приходит на ум? — сравниваем то, что мы видим в клиентском приложении, с «родным» дисплеем IP-камеры.
И первое решение — оценка группой экспертов: выбираем нескольких человек, показываем им видео и просим оценить его на предмет придурков.
Это решение в лоб.
В определенной степени эффективен, но очень трудоемок и слишком субъективен для практического использования.
Совершенно нецелесообразно собирать экспертов каждый раз, когда группа качества получает от разработчиков очередной прототип.
Вместо субъективной оценки «нравится или нет» необходимо было найти критерий плавности или ожидаемого поведения продукта, который можно записать.
Этот критерий был сформулирован следующим образом: Для плавного отображения достаточно, чтобы каждый кадр отображался на экране монитора.
В соответствии с ним оказалось второе решение .
Новый метод измерения «негладкости» заключался в следующем: создаем и отображаем на мониторе видео с последовательностью цифр (каждое число в отведенной для него части кадра) или секундомера, снимаем отображаемое видео на IP-камеру, запустите ее через Macroscop, снова отобразите и снова снимите, используя другую камеру (камеру смартфона, Go Pro и т. д.).
Ожидание.
Анализируем полученное видео покадрово: считаем количество задержанных или пропущенных кадров (цифр) и получаем, сколько было рывков.
Способ трудоемкий (попробуйте покадрово разбирать видео со стандартной для IP-камеры частотой 25 кадров в секунду! Это почти 1500 кадров в минуту), но казалось бы объективный.
Реальность.
На практике все сложилось не совсем так.
Стандартная IP-камера выдает поток с частотой ~25 кадров в секунду, монитор ~60 кадров в секунду, камера смартфона ~30 кадров в секунду.
Оказалось, что помимо того, что частота кадров не кратна, камеры и мониторы работают не синхронно.
Поэтому иногда в момент чтения видео любой из камер на мониторе происходило изменение кадра.
В результате оно «размылось» и номер на изображении невозможно было разобрать.
Таким образом, второй способ тоже не сработал.
Были еще варианты программного захвата или сбора статистики самим клиентским приложением, отображающим видеопоток, но мы от них тоже отказались.
Я хотел оценить только внешнюю составляющую — именно то, что видит пользователь, для которого вся система — «черный ящик».
Результатом наших поисков стал аппаратное решение — стенд на базе микроконтроллера.
Он включает в себя полотно с 12 светодиодами, которое фиксируется видеокамерой, и полотно с 12 фотодатчиками, которые накладываются на монитор, отображающий видеопоток с этой камеры и записывающие световые сигналы.
Все устройство помещено в светонепроницаемый короб, чтобы исключить влияние внешних источников света.
Устройство отображает на светодиодах определенную последовательность рисунков, считывает результат и записывает его в отдельную строку отчета.
Светодиоды отображают определенный образец световых сигналов с определенной частотой.
Так, например, для камеры с частотой 25 кадров в секунду смена происходила раз в 1 кадр или 40 мс (на 20 мс загорался узор, на 20 мс гас, затем загорался следующий и т.д.) .
) Мы ожидали, что камера захватит именно то, что видит глаз, или даже собственные фотодатчики стенда.
Вот как мы ожидали, что записанная последовательность из 8 паттернов будет выглядеть так: 
Каждый раз светодиоды воспроизводили одну и ту же последовательность сигналов, но в отчетах эта последовательность иногда нарушалась: появлялись кадры, которых там не должно было быть (в них были активны светодиоды из двух соседних паттернов).
Мы экспериментировали с разными IP-видеокамерами и оказалось, что наиболее четкие кадры дает камера 25 кадров в секунду с прогрессивной разверткой (в отличие, например, от версии 50 кадров в секунду с чересстрочной разверткой), при этом она минимально нарушает последовательность кадров при передаче.
по сети.
Так или иначе, полностью избавиться от артефактов нам не удалось; некоторые кадры приходили с опозданием или сливались с другими, но на самом деле это были не рывки.
На помощь пришла теорема Котельникова, согласно которой для восстановления аналогового сигнала частоты f необходима частота дискретизации не менее 2f. То есть в нашем случае достоверно восстановить сигнал со светодиодов можно только на частоте 12,5 кадров в секунду, что соответствует 80мс.
Как результат В результате реализованное нами аппаратное решение позволило зафиксировать рывки, соответствующие задержкам кадров 80 мс и выше, которые существенно ухудшают восприятие отображаемого видео.
Метод эффективен, решает проблему выявления рывков, а благодаря автоматизации требует минимум времени и усилий от команды качества.
По сей день мы регулярно используем его при регрессионном тестировании каждого нового релиза.
В результате (правда, потратив немало времени) по субъективным критериям плавности/негладкости мы получили вполне объективный метод измерения.
Собранный стенд позволил быстро оценить плавность отображения при любых параметрах системы (разная пропускная способность сети, разная производительность оборудования обработки и отображения).
Кроме того, он не привязан к приложению Macroscop, поэтому мы используем его для тестирования десктопных, мобильных и веб-клиентов.
Теги: #Работа с видео #тестирование #тестирование ИТ-систем #тестирование с использованием #видеонаблюдения #регрессионное тестирование #макроскоп #макроскоп #видеоотображение
-
Проблемы Внедрения Erp В Сегменте Мсб
19 Oct, 24 -
Как Восстановить Фотографии Google
19 Oct, 24 -
Нужен Совет По Хабре
19 Oct, 24
