Дизайн субъективного теста качества видео (P.910)

Кратко

Субъективный тест качества видео имеет смысл проводить, только если его результат выдержит совещание, где кто-то его оспорит, – а эта устойчивость закладывается на этапе дизайна, не на этапе анализа. Пять решений, которые делают или ломают тест: набор источников, который вы выбираете; матрица искажений, которую вы строите; условия просмотра, которые вы контролируете; порядок показа клипов; и длина сессии, которую вы допускаете до того, как усталость испортит голоса. ITU-T P.910 (10/2023) и ITU-R BT.500-15 (05/2023) задают каждое из этих решений – вплоть до метрики отбора источников на фильтре Собеля, пяти отбрасываемых «стабилизирующих» клипов в начале сессии и получасового лимита сессии. Статья проходит всю сборку с рабочим примером, который оценивает реальную матрицу теста и показывает, где именно она упирается в потолок усталости.

Почему это важно

Самый дорогой провал в субъективном тестировании – это тест, который прошёл чисто, выдал аккуратные числа, а затем был разобран первым же человеком, спросившим «но какой контент вы тестировали и на каком экране?» – потому что к этому моменту панель уже разошлась, а деньги потрачены. Статья – для видеоинженера, QA-лида или оценщика кодеков, кому нужно спроектировать тест, на который будут ссылаться другие, или прочитать чужое исследование качества и понять, поддерживает ли дизайн заявленный вывод. Это статья о сборке в нашем блоке субъективного тестирования: предыдущая, методологии тестирования: ACR, DCR, PC и рекомендации ITU, объясняла, какой вопрос задать зрителям; эта – всё вокруг этого вопроса, а следующая, проведение теста: участники, скрининг и среда, – про исполнение. Короткая версия для оператора энкодера – в обзоре субъективного тестирования раздела Video Encoding; всё здесь – глубокая проработка за ней.

Что значит «выдержать проверку»

Субъективный тест выдаёт число – Mean Opinion Score, среднюю оценку, которую панель зрителей дала клипу, подробно разобранную в MOS, DMOS и шкалы оценки. Это число пойдёт в решение: выпустить этот энкодер, отклонить ту лестницу битрейтов, доверять этой метрике. И раз оно ведёт к решению, кто-то его в итоге оспорит.

«Выдержать проверку» значит, что дизайн отвечает на каждый вызов до того, как его бросят. Дело не в том, чтобы потом применить более хитрую статистику; плохой дизайн не спасти хорошей арифметикой. Если вы тестировали только медленные «говорящие головы», никакой доверительный интервал не скажет, как энкодер справляется со спортом. Если половина зрителей смотрела на калиброванном мониторе, а половина – на телефоне под солнцем, никакое отсеивание выбросов не отделит эффект кодека от эффекта освещения.

ITU-T P.910 делает это конкретным в своём финальном разделе. Раздел 14, «Обязательная информация для отчёта по субъективному тесту», перечисляет, что защищаемый тест обязан задокументировать: исходный контент, условия обработки, среду, субъектов и как их отсеивали, метод и анализ (ITU-T P.910 §14). Хитрая инверсия – прочитать этот список до проектирования. Каждый пункт, который P.910 требует включить в отчёт, – это решение по дизайну, которое нужно принять осознанно. Если вы не можете заполнить отчёт, тест незащищаем – поэтому проектируйте тест так, чтобы отчёт можно было написать.

Остальная часть статьи – этот список, в порядке сборки.

Словарь: SRC, HRC, PVS

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

Источник – это чистый, оригинальный клип до любой обработки, эталон. В литературе это SRC (source reference). Это лучшее, как контент когда-либо будет выглядеть; всё, что вы с ним делаете, может только вычесть качество.

Условие – это конкретный рецепт обработки, который вы хотите оценить: кодек на битрейте, разрешение, шаг упаковки, сетевое искажение. Стандартное имя – HRC (hypothetical reference circuit, гипотетическая эталонная цепь): «фиксированная комбинация видеоэнкодера на заданном битрейте, сетевого условия и декодера». HRC – это то, что под тестом.

Обработанный клип, который зритель реально смотрит и оценивает, – это PVS (processed video sequence), результат прогона одного SRC через один HRC. Каждый клип в тесте – это PVS.

Поэтому весь тест – это сетка: каждый источник скрещён с каждым условием и даёт один обработанный клип. Протестируйте шесть источников против восьми условий – и у вас сетка 6 × 8 из сорока восьми клипов на оценку. Эта матрица SRC-на-HRC – скелет дизайна, и почти каждое решение касается выбора её строк, столбцов и того, как зрители движутся по её ячейкам.

Нажмите, чтобы увеличить

Выбор набора источников: потолок, который уже не поднять

Исходные клипы задают потолок того, что тест способен увидеть, и смещённый набор источников – самый частый способ незаметно провалить тест. ITU-T P.910 посвящает источникам весь Раздел 7, и руководство сводится к одной идее: источники должны представлять контент, который система реально понесёт, и быть достаточно разнообразными, чтобы вскрыть слабые места системы.

Начните с разнообразия контента. P.910 предостерегает от слишком узкого по тематике набора источников (§7.2.3) и явно предупреждает о выборке по удобству – берёте то, что под рукой, потому что так проще (§7.2.7). Ловушка конкретна: кодек видеоконференций, протестированный только на одной «говорящей голове», будет выглядеть отлично, а потом развалится в продакшене, как только кто-то расшарит быстро скроллящийся экран или встанет на фоне движущегося заднего плана. Вы не тестировали трудный случай – значит, и не увидели провал.

Затем сложность кодирования. P.910 отмечает, что источники различаются по тому, насколько их трудно сжать (§7.2.2). Статичное интервью сжимается почти в ничто; трава на ветру, конфетти, вода и быстрые панорамы – убийцы для любого энкодера. Набор источников, который опускает трудный контент, отчитывается о качестве энкодера, которого продакшен никогда не увидит.

P.910 превращает «разнообразный» в нечто измеримое. Раздел 7.8 определяет два числа, размещающих любой клип на карте сложности. Spatial Information (SI) измеряет, сколько мелкой детали несёт кадр: яркостный канал каждого кадра прогоняется через фильтр Собеля – детектор краёв, – и разброс результата и есть SI. Больше краёв и текстуры – выше SI. Temporal Information (TI) измеряет, насколько картинка меняется от кадра к кадру: это разброс попиксельной разности соседних кадров, поэтому быстрое движение и склейки толкают TI вверх (ITU-T P.910 §7.8, Приложение B).

Нанесите каждый кандидат-источник точкой на график с TI по одной оси и SI по другой – и вы увидите своё покрытие с первого взгляда. Хороший набор источников растянут по плоскости: низкая и высокая детализация, медленное и быстрое движение. Плохой – слипается в одном углу, обычно в low-SI, low-TI (лёгкий контент), потому что именно его было удобно снять. Лекарство – выбирать источники, заполняющие плоскость, намеренно включая угол высокого движения и высокой детали, где энкодеры мучаются.

Нажмите, чтобы увеличить

Ещё два правила по источникам закрывают раздел. Клипы должны быть короткими – руководство P.910 по длительности центрируется примерно на десяти секундах на стимул (§7.6): достаточно, чтобы оценить, достаточно коротко, чтобы тест шёл бодро. И источник должен быть по-настоящему чистым: любое сжатие, масштабирование или шум, уже впечённые в «оригинал», становятся невидимой частью каждой оценки, ведь зритель сравнивает с эталоном, который уже был повреждён. Число различных источников тоже важно (§7.7); горстки достаточно для обобщения, только если они хорошо растянуты, – ровно для этого и нужна карта SI/TI.

Построение матрицы искажений: охватите диапазон, сбалансируйте ячейки

Выбрав источники, вы выбираете условия – HRC – и то, как скрестить их с источниками. Два решения определяют, состоятельна ли матрица.

Первое – охват диапазона качества. Частая ошибка – слепить все условия у верхушки, потому что команде важно только высокое качество. Но панель калибрует использование шкалы под диапазон качества, который видит. Если каждый клип между «хорошо» и «отлично», зрители сжимают голоса в верх шкалы, и интересующие вас различия тонут в округлении. Включайте условия от явно плохого до почти прозрачного, даже если вам важен только верх, чтобы шкала оставалась растянутой, а различия наверху – видимыми. Якорные условия на обоих концах диапазона – нарочно ужасный энкод и почти чистый – дают панели то, относительно чего калиброваться.

Второе – баланс. Чистый дизайн полнофакторный: каждый источник проходит через каждое условие, поэтому каждый HRC судят на том же контенте, что и любой другой, и ни одно условие не получает несправедливого преимущества от лёгкой картинки. Матрица на Рис. 1 полнофакторная. Когда полная сетка слишком велика для прогона – реальный риск, как покажет следующий раздел, – вы переходите к дробному дизайну, где не каждый источник встречает каждое условие, и это надо отчитать и рандомизировать, чтобы не сместить ни один HRC. P.910 описывает и дизайн с неповторяемыми сценами (§11.2), где каждый источник появляется лишь раз за весь тест, меняя внутриисточниковое сравнение на куда более широкое покрытие контента; это законный выбор, но другой, и его надо задекларировать.

Рабочий пример: размер матрицы против потолка усталости

Вот арифметика, превращающая матрицу в расписание, и это самый полезный расчёт в дизайне теста. Допустим, вы хотите сравнить два энкодера на четырёх битрейтах каждый – восемь условий – и выбираете шесть исходных клипов, растянутых по плоскости SI/TI.

Матрица – шесть источников на восемь условий:

PVS = SRC × HRC = 6 × 8 = 48 обработанных клипов

Вы берёте Absolute Category Rating (ACR), одностимульный метод из статьи о методах: один клип, один голос. Каждый клип идёт около десяти секунд, и зрителю нужно примерно пять секунд, чтобы зафиксировать голос, поэтому каждая оценка съедает около пятнадцати секунд:

время голосования = 48 клипов × 15 с = 720 с = 12 минут

Двенадцать минут голосования помещаются в одну сессию. Но сессия – это не только голосование. ITU-R BT.500-15 ограничивает сессию примерно тридцатью минутами ради контроля усталости и требует около пяти «холостых» стабилизирующих клипов в начале первой сессии, чьи голоса отбрасываются (ITU-R BT.500-15). Добавьте короткие инструкции и фазу тренировки, пять стабилизирующих клипов и передышку в середине – и двенадцать минут голосования становятся примерно двадцатью–двадцатью двумя минутами сессии, с запасом под потолком. Одна сессия работает.

Теперь смотрите, как приближается потолок. Допустим, сравнение растёт: ещё два кодека и более дробная лестница битрейтов доводят вас до шестнадцати условий на тех же шести источниках.

PVS = 6 × 16 = 96 клипов
время голосования = 96 × 15 с = 1 440 с = 24 минуты

Двадцать четыре минуты голосования плюс накладные на тренировку и стабилизацию выходят к примерно двадцати семи минутам – всё ещё одна сессия, но почти без места под перерыв. Сделайте ещё шаг и расширьте контент до восьми источников:

PVS = 8 × 16 = 128 клипов
время голосования = 128 × 15 с = 1 920 с = 32 минуты

Тридцать две минуты одного только голосования перебивают тридцатиминутный потолок ещё до единственного тренировочного клипа. Теперь нужно разбить тест на две сбалансированные сессии с перерывом между ними – и пере-заякорить в начале второй, ведь свежей сессии нужна свежая калибровка. Метод важен не меньше матрицы: двухстимульный метод показывает два клипа на одно суждение и занимает примерно вдвое дольше, поэтому даже исходная матрица из сорока восьми клипов вышла бы к примерно двадцати минутам голосования, а эта из 128 – почти к часу. Метод, матрица и лимит сессии – одно связанное решение, а не три отдельных.

Условия просмотра: контролируйте комнату или измеряете комнату

Если зрители смотрят в разных условиях, вы измерили условия, а не видео. ITU-T P.910 §9 и ITU-R BT.500-15 задают среду точно, и точность – это и есть суть: контролируемая среда – то, что позволяет приписать разницу оценок кодеку, а не освещению.

Первое решение – контролируемая или неконтролируемая среда (P.910 §9.1). Контролируемая (лабораторная) среда фиксирует дисплей, освещение и дистанцию просмотра для каждого субъекта. Неконтролируемая – собственное устройство зрителя, где он есть, – меняет этот контроль на реализм и масштаб и относится к краудсорсинговому тестированию по ITU-T P.808 (разобрано в краудсорсинговом субъективном тестировании). Это не взаимозаменяемо: лабораторный тест отвечает «какой энкод лучше при идеальном просмотре», краудтест – «какой энкод лучше в реальном мире», и вы обязаны сказать, какой вопрос задавали.

Для контролируемого теста BT.500-15 фиксирует комнату. Пиковая яркость дисплея – между 70 и 500 кд/м². Отношение фона за экраном к пиковой яркости экрана – около 0,15, а освещённость экрана в домашней среде – около 200 люкс (ITU-R BT.500-15). Дисплей должен быть калиброван, а не на заводских настройках, потому что некалиброванный экран гнёт каждое суждение о цвете и контрасте.

Дистанция просмотра – отдельное решение (P.910 §9.3). BT.500 задаёт дистанцию как кратное высоты картинки и позволяет выбрать между preferred viewing distance (PVD) – где зритель садится естественно – и design viewing distance (DVD), геометрической дистанцией, на которой глаз едва различает пиксельную сетку. Выбор зависит от вопроса: PVD для «как это испытает реальный зритель», DVD для «как хорошо это может выглядеть на пределе остроты зрения». Что бы вы ни выбрали, зафиксируйте это для всех и отчитайте; дистанция меняет, какие искажения видны, поэтому плавающая дистанция тихо добавляет шум в каждую оценку.

Нажмите, чтобы увеличить

Рандомизация и порядок: победить эффект якоря

Покажите средний клип сразу после ужасного – и он выглядит лучше, чем есть; покажите его сразу после безупречного – и он выглядит хуже. Это контекстный, или якорный, эффект, и он силён настолько, что затопит разницу между двумя энкодерами, если позволить порядку показа совпасть с условием. Рандомизация – защита.

ITU-T P.910 §12.7.4 требует, чтобы порядок показа был рандомизирован, а рандомизация – снята при анализе, чтобы дизайн оставался сбалансированным. Стандартная практика, применяемая в тест-планах VQEG, – упорядочивание латинским квадратом (или греко-латинским): структурированная рандомизация, гарантирующая, что каждое условие появляется в каждой порядковой позиции примерно поровну по субъектам, так что ни одно условие систематически не выигрывает оттого, что всегда идёт после лёгкого или трудного клипа. Создаётся как минимум два разных рандомизированных порядка показа, и субъекты делятся между ними примерно поровну, чтобы любой остаточный эффект порядка взаимно гасился.

Из этого выпадают два практических правила. Первое: никогда не показывайте один источник дважды подряд, даже под разными условиями, – зритель помнит контент и оценивает сравнение, а не клип. Второе: рандомизируйте по субъекту или по малой группе, а не один раз на всю панель, чтобы единственный неудачный порядок не сместил весь результат. Рандомизация – это учёт, который надо хранить, ведь при анализе вы отображаете каждый голос обратно на его истинные SRC и HRC; зритель видел хаос, таблица видит чистую матрицу.

Тренировка, якоря и стабилизация: калибруйтесь до того, как считать

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

Тренировка идёт первой (P.910 §12.5). До любого оцениваемого клипа зрителю показывают инструкции, демонстрацию механизма голосования и набор тренировочных клипов, охватывающих весь диапазон качества – от худшего, что покажет тест, до лучшего, – чтобы он откалибровал внутреннюю шкалу до того, как она начнёт считаться. Критическое правило: тренировочные клипы должны использовать другой исходный контент, не из теста, иначе зритель приходит к реальным клипам уже подготовленным на этой картинке, протекая информацию в оценки. В приложениях P.910 даже даны образцы инструкций и форма согласия для стандартизации этой фазы.

Якоря – это явные примеры лучшего и худшего внутри тренировочного набора. Показав нарочно ужасный энкод и почти чистый и назвав их концами шкалы, вы даёте каждому зрителю одни и те же опорные точки для «1» и «5», что повышает согласие между субъектами и делает итоговый MOS сопоставимым по панели.

Стабилизирующие показы разбираются с остаточным оседанием даже после тренировки. ITU-R BT.500-15 требует около пяти «холостых» клипов в самом начале первой сессии, охватывающих диапазон качества, чьи голоса собирают ради реализма, но отбрасывают из результатов (ITU-R BT.500-15). Они впитывают последний дрейф оседающей шкалы, так что первый засчитанный голос уже стабилен. Когда тест разбит по сессиям, пере-заякоривайте в начале каждой – вернувшийся с перерыва зритель потерял часть калибровки.

Нажмите, чтобы увеличить

Длина сессии и усталость: тридцатиминутный потолок

Усталые зрители дают худшие данные – более разбросанные и смещённые вниз по мере угасания внимания. Оба стандарта трактуют усталость как жёсткое проектное ограничение, не как вопрос комфорта. ITU-R BT.500-15 ограничивает одну сессию примерно тридцатью минутами, а ITU-T P.910 §11.1 явно формулирует размер эксперимента через усталость субъекта, а §12.6 покрывает структуру сессий и перерывов.

Практических следствий три. Матрицу, чьё время голосования переваливает за лимит сессии, нужно разбить на несколько сбалансированных сессий, разложив каждое условие поровну по сессиям, чтобы ни один HRC не сконцентрировался в усталом хвосте сессии. Каждой сессии после первой нужно собственное пере-заякоривание, ведь калибровка распадается за перерыв. А допущения о времени на клип – десять секунд контента, пять на голос – следует подтвердить пилотным исследованием (P.910 §11.8) до набора панели, ведь реальное время на клип зависит от контента, инструкций и платформы, и ошибка в оценке – это как тест, выглядевший одной сессией, становится двумя на полпути.

Субъекты: сколько и как отсеивать

Размер панели и скрининг – последние решения дизайна, и соблазн подогнать их задним числом силён – устойте.

ITU-T P.910 §10.1 задаёт пол: минимум 15 валидных субъектов на условие в контролируемом тесте. Больше субъектов сужают доверительный интервал; статья о методах отмечала, что наименьшая надёжно различимая разница MOS у ACR ужимается с примерно 1,5 балла при шести субъектах до примерно 0,5 при двадцати четырёх (P.910 §8.1.1), поэтому 24 – частая цель, когда различия малы. В неконтролируемой или публичной среде, отмечает P.910, нужно примерно тридцать пять субъектов, чтобы достичь той же статистической чувствительности, что и пятнадцать контролируемых, ведь лишний средовой шум приходится усреднять.

Скрининг идёт в две стадии. Пред-скрининг проверяет зрение каждого субъекта до старта – остроту (таблица типа Снеллена) и цветовосприятие (тест типа Исихары), – чтобы зритель, не различающий тестируемую деталь, тихо не добавлял шум (P.910 §12.2–12.3). Пост-скрининг идёт после сбора данных, отбраковывая субъектов, чьи оценки слишком несогласованны с панелью; P.910 Приложение A даёт метод на основе корреляции Пирсона между каждым субъектом и средним панели, а §13.6 описывает уточнение со снятием смещения и взвешиванием по согласованности. Важна дисциплина: решите правила скрининга и целевое число субъектов до того, как увидите оценки. Выбор размера панели или порога отбраковки после взгляда на данные, чтобы протолкнуть результат за линию значимости, – это разница между измерением и самооправданием. Статистика всего этого – доверительные интервалы, отсев выбросов, проверка значимости – тема статистики субъективных данных.

Чек-лист дизайна: P.910 §14 наоборот

Соберите всё вместе – и проверка на «выдержать» становится механической: можете ли вы написать отчёт, который требует ITU-T P.910 §14? Каждая строка – решение по дизайну, принятое нарочно.

Нажмите, чтобы увеличить

Семь решений, с вопросом, на который отвечает каждое, и пунктом за ним:

Если у каждой строки есть осознанный ответ, который вы можете защитить, тест выдерживает. Если хоть одна строка отдана на волю случая или удобства – именно там его и разберут.

Частые ошибки

Эти шесть повторяются достаточно часто, чтобы их назвать, и каждая ложится на строку выше.

«Ошибка 1 – набор источников по удобству. Тест только на той картинке, что было легко достать (обычно низкое движение, низкая деталь), отчитывает качество, которого продакшен не видит. Растяните источники по плоскости SI/TI (P.910 §7.8) и намеренно включите трудный контент.»

«Ошибка 2 – слипание всех условий у верхушки. Когда каждый клип «хорошо–отлично», зрители сжимают голоса, и различия наверху исчезают. Охватите весь диапазон и заякорите оба конца, даже если важен только верх.»

«Ошибка 3 – неконтролируемые или смешанные условия просмотра. Половина панели на калиброванном мониторе, половина на ноутбуке под солнцем – это измерение комнаты, не кодека. Зафиксируйте дисплей, освещение и дистанцию (BT.500-15) или проведите явный краудтест по P.808 и назовите его так.»

«Ошибка 4 – фиксированный порядок показа. Если условие и порядок совпадают, якорный эффект притворяется разницей качества. Рандомизируйте по субъекту латинским квадратом и сбалансируйте по минимум двум порядкам (P.910 §12.7.4).»

«Ошибка 5 – выбор числа субъектов после взгляда на данные. Подгонка N или порога отбраковки, чтобы протолкнуть результат за значимость, – это самооправдание, не измерение. Зафиксируйте число (≥15 валидных, P.910 §10.1) и правило скрининга до того, как смотреть.»

«Ошибка 6 – тренировка на тестовом контенте. Повторное использование исходных клипов в тренировке протекает информацию в оценки. Тренируйте на другом контенте, охватывающем тот же диапазон качества (P.910 §12.5).»

Где здесь Фора Софт

Фора Софт строит видеософт с 2005 года – стриминг, WebRTC-конференции, OTT, e-learning, телемедицину и видеонаблюдение, – и дисциплина из этой статьи – то, что мы прогоняем, прежде чем пустить субъективное число в клиентское решение. Оценивая энкодер для конференц-продукта, мы строим набор источников намеренно по плоскости SI/TI, ведь панель только из «говорящих голов» спрятала бы ровно те случаи расшаренного экрана и движения, что ломают конференц-видео. Тестируя пайплайн видеонаблюдения, мы фиксируем дистанцию просмотра и освещение под реальность операторской, а не под идеализированную лабораторию, ведь именно там реально судят картинку. А публикуя результат по качеству, мы отчитываем полный дизайн по §14 – источники, условия, среду, панель, скрининг и доверительные интервалы – так же, как документируем нашу методологию бенчмарков, чтобы число устояло на совещании, где оно важно.

Главное

• Тест выдерживает проверку за счёт дизайна, не за счёт пост-фактум статистики; плохой дизайн не спасти хорошей арифметикой.
• Тест – это матрица SRC × HRC; источники задают потолок качества, условия задают диапазон.
• Растяните источники по плоскости SI/TI (P.910 §7.8) и охватите весь диапазон качества, заякорив оба конца.
• Контролируйте комнату – дисплей, ~200 люкс, фиксированная дистанция – или вы измеряете комнату (BT.500-15).
• Рандомизируйте порядок по субъекту (латинский квадрат), тренируйте на другом контенте и отбрасывайте ~5 стабилизирующих клипов.
• Держите сессии короче ~30 минут, отсейте ≥15 валидных субъектов и зафиксируйте каждое правило до того, как увидеть данные.

Что почитать дальше

• Методологии тестирования: ACR, DCR, PC и рекомендации ITU
• Проведение теста: участники, скрининг и среда
• Статистика субъективных данных