Вы помните Историю о развитии форматов видеосжатия (вот эту)?
А со сколькими из описанных там кодеков вы знакомы лично? А какие пробовали писать сами? Какие алгоритмы сжатия наиболее эффективны?
Эти и другие вопосы НЕ будут освещаться в этой статье.
Часть нулевая, знакомство
Добрый день, уважаемое сообщество!
Меня зовут Андрей, работаю в компании Intel. В нескольких статьях планирую рассказать о том, какие подходы мы используем при тестировании видеокодеков в проекте Intel® Media SDK.
Часть первая, вводная
Не так давно мой коллега, Дмитрий Серкин, написал статью про оценку качества видеокодеков (ссылка на ISN). Там он вскользь упомянул про валидационный процесс. Цель данной статьи — пролить немного света на эту активность.
Intel® Media SDK предоставляет программистам возможность использовать мультимедиа возможности современных процессоров (Sandy Bridge, Ivy Bridge) для выполнения декодирования (H.264 (AVC, MVC), MPEG2, VC1, JPEG/MJPEG), кодирования (H.264 (AVC, MVC), MPEG2) и некоторых операций препроцессинга (например, изменение размеров или удаление черезстрочной развертки). Но самое главное, что все эти действия могут быть объединены для построения транскодерной цепочки (преобразование одного формата в другой, без промежуточных стадий). А это позволит ускорить передачу Full HD видео (1920х1080, High Definition) на телефон, поддерживающий, к примеру, не более SD разрешения (720x576, Standard Definition).
А теперь посмотрим на это все с точки зрения тестирования: 5 декодеров (decoders), 3 энкодера (encoders), операции препроцессинга и плюс к этому варианты их объединения. Не забудем добавить, что для всех компонент важен еще и контент — разрешение видеопоследовательности, параметры закодированного потока (для декодеров) и параметры, которые мы хотим использовать (для энкодеров). Получаем множество вариантов для проверок. Огромное множество. Вот откуда берутся те дни для прохождения валидации на далеко не самых слабых машинах, о которых говорил Дмитрий.
Да, еще один момент. У библиотеки две реализации: одна «железная», которая использует возможности процессора и вторая “софтверная”, для случаев, когда у вас железки нет, а потренироваться уже хочется. Поэтому все те переборы, что мы насчитали в предыдущем случае, смело умножаем на два. Естественно, разнятся и операционные системы: Win 7 (x86 и x64) и еще те, о которых мы говорить не будем ;)
У страха глаза велики, но дело делать надо. Для начала немного упорядочим тот хаос возможных тестовых сценариев. В первую очередь отделим компоненты SDK друг от друга: есть декодеры, есть энкодеры и есть операции препроцессинга. Теперь каждую часть покрываем максимальным количеством осмысленных тестов. А затем вновь собираем все в единое целое – транскодерную цепочку – и повторяем ту часть тестов, где взаимодействие компонент имеет значение (определение таких тестов есть отдельная и весьма сложная задача). Теперь рассмотрим все подробнее. Начнем с декодеров.
Декодеры
Здесь все относительно просто: существует некий набор (conformance set) закодированных видеопоследовательностей, которые наша реализация кодека должна декодировать корректно, раз уж мы заявляем о его поддержке. Но сложность в том, что набор этот не всегда велик, а вариантов, которые можно встретить в реальности, гораздо больше.
ничто не может помешать нам создать множество тестовых последовательностей самостоятельно — используя подходящий энкодер, оказавшийся под рукой
При этом проигрывать целый фильм не стоит.
математическая индукция в действии
Хотя убедиться, что декодер в состоянии проработать не 3-10 сек, а 1.5-3 часа тоже имеет смысл, конечно.
Но мы проверяем не только соответствие кодеков стандарту. У нас же SDK! А он позволяет нам декодировать используя как системную память, так и d3d, например. Да еще и асинхронность различная поддерживается.
в данном случае это “дальний синоним” многопоточности: несколько задачек обработки могут выполняться одновременно (кто-то декодируется, кто-то препроцессится, а кого-то уже кодируют)
Есть еще несколько различных режимов, относящихся к деталям реализации библиотеки. И вот мы снова получаем много-много вариантов.
После декодирования мы имеем разжатую видеопоследовательность, которую бы неплохо оценить на качество. Но как? Тот самый PSNR (Peak Signal to Noise Ratio, wiki)? Вычислительно более тяжелый SSIM (Structural Similarity, wiki)?
Лирическое отступление про метрики: провести субъективный анализ для каждой декодируемой последовательности весьма затруднительно — глаза замыливаются, видят по-разному, да и где столько глаз найти? Потому применяют метрики объективные, т.е. привлекающие математику. Но хоть эти метрики и носят такое громкое название, бывают случаи, что метрика говорит одно, а глаза — совсем другое.
Что же касается PSNR’а с SSIM’ом, то это самые распространенные (читай, простые и удобные) метрики для оценки качества, которые позволяют оценить степень похожести двух декодированных изображений
Хорошо, а с чем сравнить? Кого считать эталоном? К счастью, не все кодеки одинаково погрешны.
речь про погрешность вычислений — кодеки, содержащие нецелочисленные вычисления могут давать разный результат от запуска к запуску
Так, например, H.264AVC является целочисленным стандартом, что гарантирует один и тот же результат декодирования последовательности вне зависимости от чего бы то ни было. Это же прекрасно! Декодируем последовательность эталонным декодером (если его нет, то эталон придется назначить), считаем, что он правильный (в данном случае нужно посмотреть глазами весь стрим), и сохраняем.
хранить всю разжатую последовательность затратно — занимает слишком много места. Поэтому можно посчитать его контрольную сумму, например, CRC32
При следующем прогоне просто сравниваем текущий результат с эталоном. Совпали — все хорошо, нет — хм, что-то пошло не так.
Если же стандарт не целочисленный, процедура чуть сложнее: выбираем эталонный декодер, а для сравнения используем PSNR метрику, чтобы оценить, насколько все хорошо (или плохо). Когда декодер стабилизирован, повторяем процедуру, описанную выше.
ибо если выход получился немного другим, то что-то в декодере поменялось, значит. И это проблемой может быть :)
Вот и все, про декодеры закончили мы.
Автор: amaslenn
