Тестирование Видеокодеков. Эпизод Ii: Атака Кодировщиков

Продолжаем узнавать секреты тестирования видеокодеков.

На этот раз мы поговорим о кодировщиках.

Связь для первой части.

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

Но есть общеупотребительные, которые обычно используются для доказательства превосходства одних кодеков (или их реализаций) над другими.

Замечательные сравнения делают ребята из МГУ, посмотреть их можно здесь: компрессия.
ру

Если говорить о сравнении, то можно выделить два критерия: качество (субъективное или объективное) и продуктивность.

Это редкий кодек, который может победить сразу в обеих категориях.

Однако мы поговорим о тестировании энкодеров.

Итак, на входе у нас распакованное видео и реализация какого-то кодека (сам кодировщик), а на выходе — сжатый клип.

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

Те.

Вы всегда можете сделать видео самостоятельно и потом использовать его для издевательства над декодером/кодировщиком, а скачать фильм из интернета для тех же целей не всегда возможно.

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

Он содержит практически все, что было в исходных данных (речь идет о сжатии с потерями).

Именно этот файл нам и предстоит изучить.

И пока мы говорим о спецификациях, одной из важных проверок будет проверка соответствия нашего зажима стандарту.

Лучше это делать с помощью сторонних инструментов – так уверенность в оценке будет выше у сторонних пользователей.

Но инициатива не всегда наказуема: если есть желание, можно самому разобрать файл на составляющие и все перепроверить.

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

Конечно, в данном случае мы ограничиваемся «ручками», которые можем «подкрутить» в настройках кодировщика.

Поклонникам x264 придется мириться с меньшим количеством переключателей

Но вернемся к нашему закодированному файлу.

Как оценить качество картинки, которую увидит пользователь? Все очень похоже на то, что было в первой части: нам нужен декодер,

желательно сторонний эталонный, чтобы избежать двойных ошибок

с помощью которого мы получим распакованный видеоряд, который сможем сравнить с исходным, используя уже знакомые нам метрики — PSNR и SSIM. Однако здесь мы подходим к важному вопросу: каковы должны быть пороги «похожести» видео? Другими словами, какие значения PSNR/SSIM нас удовлетворят, а какие нет? В общем, хорошо – это когда не плохо, т. е.

нет артефактов, искажений и всего остального, что так неприятно глазу.

И хорошо, если наши метрики это уловили.

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

Но «сломаться» он может по-разному.

Итак, допустим, вчера наш кодер выдал X дБ при битрейте Y (мы будем кодировать с постоянным битрейтом)

Все остальные параметры учитывать не будем, оставим их фиксированными.

сегодня наш кодер выдает X1 дБ при том же битрейте.

В чем дело? Бьем тревогу? Минута, а Х1 больше Х? Если да, то все в порядке, энкодер стал работать лучше! Или нет? Не все так просто, как хотелось бы: при использовании постоянного битрейта нет гарантии, что он действительно будет постоянным — возможны небольшие отклонения (в обе стороны).

Теперь представим, что якобы возросшее качество объясняется возросшим битрейтом.

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

Аналогично, уменьшение значения X1 по сравнению с X не говорит об ухудшении работы энкодера — возможно, это сэкономило нам какие-то биты.

Мораль: больше не значит лучше, меньше не значит хуже.

Тестирование видеокодеков.
</p><p>
Эпизод II: Атака кодировщиков

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

Кодер заложил в поток все необходимые параметры? Правильно ли он их разместил? Вы выполнили все требования и требования, описанные в стандарте?

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

И вроде бы всё, на этом можно закончить, но есть одно но: у нас есть SDK! Это означает, что должны быть проверены все параметры работы с памятью, потоками и всем остальным, что может быть изменено пользователем.

Теоретически в большинстве случаев любое использование SDK должно давать один и тот же результат.

Действительно, почему должно страдать качество, если пользователь использует память D3D вместо системной памяти? Или глубина асинхронности была изменена.
Или они решили использовать больше (или меньше) потоков.

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

Так будет быстрее, потому что операции декодирования (для получения сырого видео) и расчета метрик (на основе сырых файлов) дешевыми назвать нельзя.

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

Да и сами проверки во втором случае должны быть более интеллектуальными.

УПД Статью с обзором подходов к тестированию предварительной обработки видео можно прочитать на сайте ISN Теги: #Intel #mediasdk #тестирование #видеокодеки #тестирование ИТ-систем