Закономерно, что с развитием продукта повышается и внимание к его качеству. Причем не только по части функционирования, но и в отношении пользовательской эстетики.
Несколько лет и версий назад мы столкнулись с недостаточным качеством отображения видео в 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 с чересстрочной разверткой), при этом она минимально нарушала последовательность кадров при передаче по сети.
Так или иначе, избавиться от артефактов полностью нам не удалось- часть кадров приходила с запозданием или сливалась с другими, но на самом деле рывками это не являлось.
На помощь пришла теорема Котельникова, согласно которой для восстановления аналогового сигнала частоты f требуется частота отсчета не менее 2f. То есть восстановить сигнал со светодиодов в нашем случае можно надёжно только для частоты 12,5 fps, что соответствует 80мс.
В результате
В результате реализованное нами аппаратное решение позволило фиксировать рывки, соответствующие задержке кадров от 80мс и выше, которые как раз существенно ухудшают восприятие отображаемого видео.
Метод результативен, решает задачу обнаружения рывков, а также благодаря автоматизации он требует минимальных затрат времени и сил группы качества. По настоящий момент мы регулярно применяем его при регрессионном тестировании каждого нового релиза.
В итоге (хоть и потратив много времени) для субъективных критериев плавности/неплавности мы получили вполне объективный метод измерения. Собранный стенд позволил быстро оценивать плавность отображения при любых параметрах системы (разной пропускной способности сети, разной производительности оборудования для обработки и отображения). К тому же, он не имеет привязки к приложению Macroscop, поэтому с его помощью мы тестируем и десктопный, и мобильный, и веб — клиенты.
Несколько лет и версий назад мы столкнулись с недостаточным качеством отображения видео в 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 с чересстрочной разверткой), при этом она минимально нарушала последовательность кадров при передаче по сети.
Так или иначе, избавиться от артефактов полностью нам не удалось- часть кадров приходила с запозданием или сливалась с другими, но на самом деле рывками это не являлось.
На помощь пришла теорема Котельникова, согласно которой для восстановления аналогового сигнала частоты f требуется частота отсчета не менее 2f. То есть восстановить сигнал со светодиодов в нашем случае можно надёжно только для частоты 12,5 fps, что соответствует 80мс.
В результате
В результате реализованное нами аппаратное решение позволило фиксировать рывки, соответствующие задержке кадров от 80мс и выше, которые как раз существенно ухудшают восприятие отображаемого видео.
Метод результативен, решает задачу обнаружения рывков, а также благодаря автоматизации он требует минимальных затрат времени и сил группы качества. По настоящий момент мы регулярно применяем его при регрессионном тестировании каждого нового релиза.
В итоге (хоть и потратив много времени) для субъективных критериев плавности/неплавности мы получили вполне объективный метод измерения. Собранный стенд позволил быстро оценивать плавность отображения при любых параметрах системы (разной пропускной способности сети, разной производительности оборудования для обработки и отображения). К тому же, он не имеет привязки к приложению Macroscop, поэтому с его помощью мы тестируем и десктопный, и мобильный, и веб — клиенты.