В октябре 2015 был выпущен очередной отчет сравнения кодеков в ВМиК МГУ, на этот раз туда вошло несколько кодеков формата HEVC.
Рядовые пользователи не могут тратить недели на изучение всех настроек кодеров, поэтому пресеты, поставляемые разработчиками, должны быть настроены идеально. В отчете сравниваются пресеты, но не даются рекомендации по их исправлению. В данной статье мы провели аналогичное сравнение и разработали рекомендации по модификации пресетов кодера х265. Показано, что для видеопоследовательности, исследуемой в бесплатной версии отчета, предлагаемые изменения параметров кодирования позволяют существенно повысить эффективность сжатия.
Задача кодирования видео при обработке мультимедиа, будь то передача, монтаж или редактирование, хранение, возникает постоянно как при разработке приложений и сервисов, так и при их настройке в момент использования. В силу большого количества популярных видеокодеков, даже зачастую одного типа, выбрать из них оптимальный, а затем задать правильные настройки, непросто. Вероятно, руководствуясь подобными соображениями, в лаборатории компьютерной графики и мультимедиа при факультете вычислительной математики и кибернетики (ВМиК) МГУ с 2000х ведется работа над проектом сравнения видеокодеков.
В октябре 2015 года был опубликован отчет сравнения кодеков, в котором участвуют некоторые кодеки формата HEVC, а так же несколько других, активно разрабатываемых в настоящее время. В качестве «эталонного» принят компрессор x264. Одним из интересных в отчете является компрессор x265, именно его изучением и займемся.
В качестве инструмента для анализа будем использовать SolveigMM Zond 265, анализатор файлов HEVC/H.265 и AVC/H.264.
Опишем методику. Сравнение в отчете проводится по критериям битрейт-качество (SSIM, PSNR)-скорость.Описанная в отчете методика для сравнения соотношения битрейт/метрика качества (пункт C.4) следующая.
Выбираем несколько значений битрейта (например, 7 значений: 1, 2, 4, 6, 8, 10 и 12 Mbps), для них считаем необходимые метрики качества для каждого кодека.
Отмечаем полученные значения на графике: метрика качества (ось абсцисс) – битрейт (ось ординат).
За эталонный выберем x265 с пресетом, выбранным в отчете (таблица 1). В отчете используется не последняя версия компрессора, ее можно найти здесь: x265 1.5+460-ac85c775620f. Однако при использовании последней версии принципиально ничего не меняется.
Используемые пресеты компрессоров указаны в таблице 1 (для платформы desktop).
Таблица 1. Настройки компрессора x265 отчета «MSU HEVC Video Codec Comparison»
Для получения рекомендаций модификации пресетов проводим тестирование всех настроек, из которых они состоят – какой вклад в качество и скорость вносит каждая составляющая. План здесь следующий.
Ограничимся параметрами пресетов для универсального кодирования и для «риппинга» (табл. 2), раскрывая параметры «-p medium» и «-p ultrafast». Добавим к ним еще два, упущенные в отчете: «--keyint -1 --tune ssim». Перечисленными параметрами будем дополнять пресеты для быстрого и универсального перекодирования соответственно.
Таблица 2. Параметры-кандидаты на модификацию пресетов отчета «MSU HEVC Video Codec Comparison»
Ссылка для скачивания тестовой последовательности «Apple Tree» (рис. 1), используемой в бесплатной версии отчета, не указана. Выберем аналогичную, используя ее ключевую особенность – крупный план, большое количество мелких деталей. Например «big_buck_bunny_1080p_h264.mov», интервал в 338 кадров с 24 секунды:
ffmpeg -i big_buck_bunny_1080p_h264.mov -ss 00:00:24 -frames:v 338 -c:v rawvideo -pix_fmt yuv420p sample.yuv
Рисунок 1. Характеристика последовательности «Apple Tree»
Для того чтобы при реализации трех шагов плана, указанного выше, не тратить много времени на выписывание необходимых чисел из интерфейса Zond 265, удобно использовать его возможность работы в командной строке (таблица 3):
zond265_x64 %COMPRESSED_FILE% -iref %REFERENCE_420P_FILE% -nowait -report t=quality,statstream qm=SSIM o=%TARGET_CSV_FILE%
Список всех параметров, а также их подробное описание можно посмотреть на странице документации Zond 265.
Таблица 3. Параметры Zond 265 командной строки, необходимые для составления скрипта
Вот два скрипта для Python 2.7: один для кодирования 266 файлов (20 настроек для первого, 18 настроек для второго пресета, для 7 значений битрейта: 1, 2, 4, 6, 8, 10, 12 Mbps), второй для составления отчета в формате CSV (файл – отношение FPS кодирования к эталонной конфигурации – отношение метрики SSIM к эталонной конфигурации).
Как видно из таблиц отчетов для фрагмента файла «big_buck_bunny_1080p_h264.mov» (таблицы 5 и 6), модифицировать конфигурации можно, например, так, как указано в таблице 4. Напомним, для улучшения эффективности значение «Мера качества» должно быть меньше единицы, а значение «Относительное время кодирования» – больше единицы.
Тест выполнен на компьютере следующей конфигурации: Intel Core i7-2600@3.4 GHz, 16 GB RAM. Наибольшее улучшение качества дает параметр «--min-cu-size 8» для конфигурации быстрого кодирования, для универсального кодирования – параметр «--rdoq-level 2» (но он же более всего замедляет кодирование).
Таблица 4. Модификация пресетов отчета «MSU HEVC Video Codec Comparison» для увеличения эффективности кодирования при той же скорости кодирования
Правильность выбора опций легко проверить, запустив скрипт кодирования с измененными пресетами (таблица 7).
Таблица 7. Эффективность кодирования с использованием измененных пресетов относительно пресетов отчета «MSU HEVC Video Codec Comparison»
Попробуем взглянуть, на что повлияло изменение опций – откроем в Zond 265 файл, закодированный измененным пресетом при быстром перекодировании для битрейта 8 Mbps и сравним его с файлом, закодированным неизмененным пресетом. Размер максимального блока кодирования остался прежним, и равен 32x32 (область «--ctu 32»). Но размер минимального блока уменьшился с 16 до 8 (область «--min-cu-size 8»), именно этот параметр дал наибольшее увеличение качества. Увеличилось число B-кадров с 3 до 4 (область «--bframes 4»), но при этом увеличилось и максимальное число «референсных» кадров (область «--ref 4»). Областью «SSIM» выделены максимальные значения графиков SSIM/PSNR для трех компонент: яркости (Luma) и двух компонент цветности (Cb, Cr). Они увеличились с 0.9623-0.9966 до 0.9771-0.9991. Оставшиеся дополнительные параметры (--rc-lookahead 20 --early-skip --cutree) влияют на алгоритм кодирования, а не на тип получившегося видео, это отражается, главным образом, на скорости кодирования (см. табл. 5). Надо отметить, визуально картинка декодированного кадра изменилась – артефакты кодирования теперь не видно.
Рисунок 2. Скриншот Zond 265 файла, закодированным с использованием исправленной конфигурацией быстрого кодирования
Аналогично можно проверить параметры закодированного файла с измененным и неизмененным пресетом универсального кодирования (рисунок 3). Размер минимальных разбиений TU не изменился и остался равным 4x4 (область «--tu-intra-depth 3»), количество B-кадров осталось неизменным и равно 3 (область «--bframes 3»). SSIM увеличился с 0.9789-0.9994 до 0.9811-0.9992. По сравнению с конфигурацией быстрого перекодирования увеличился размер максимального блока, стал равным 64x64 (область «--ctu 64»), добавился SAO фильтр (область «--sao»).
Рисунок 3. Скриншот Zond 265 файла, закодированным с использованием исправленной конфигурацией универсального кодирования
Таким образом, на основе проведенного тестирования предложен список опций для улучшения эффективности кодирования (улучшение значения метрики SSIM при том же битрейте и скорости кодирования) для конфигураций быстрого и универсального кодирования. С использованием предложенных изменений для файла с большим количеством мелких деталей, значение интегральной «меры качества» отчета «MSU HEVC Video Codec Comparison» при быстром перекидировании улучшилось на 31%, а при универсальном – на 15%, при этом скорость кодирования изменилась несущественно. Т.к. тестирование проведено для каждой опции отдельно, то на практике можно выбирать и использовать лишь некоторые удобные опции, а не весь предложенный список.
Рядовые пользователи не могут тратить недели на изучение всех настроек кодеров, поэтому пресеты, поставляемые разработчиками, должны быть настроены идеально. В отчете сравниваются пресеты, но не даются рекомендации по их исправлению. В данной статье мы провели аналогичное сравнение и разработали рекомендации по модификации пресетов кодера х265. Показано, что для видеопоследовательности, исследуемой в бесплатной версии отчета, предлагаемые изменения параметров кодирования позволяют существенно повысить эффективность сжатия.
О проекте
Задача кодирования видео при обработке мультимедиа, будь то передача, монтаж или редактирование, хранение, возникает постоянно как при разработке приложений и сервисов, так и при их настройке в момент использования. В силу большого количества популярных видеокодеков, даже зачастую одного типа, выбрать из них оптимальный, а затем задать правильные настройки, непросто. Вероятно, руководствуясь подобными соображениями, в лаборатории компьютерной графики и мультимедиа при факультете вычислительной математики и кибернетики (ВМиК) МГУ с 2000х ведется работа над проектом сравнения видеокодеков.
В октябре 2015 года был опубликован отчет сравнения кодеков, в котором участвуют некоторые кодеки формата HEVC, а так же несколько других, активно разрабатываемых в настоящее время. В качестве «эталонного» принят компрессор x264. Одним из интересных в отчете является компрессор x265, именно его изучением и займемся.
В качестве инструмента для анализа будем использовать SolveigMM Zond 265, анализатор файлов HEVC/H.265 и AVC/H.264.
Методика сравнения кодеков и подбора параметров
Опишем методику. Сравнение в отчете проводится по критериям битрейт-качество (SSIM, PSNR)-скорость.Описанная в отчете методика для сравнения соотношения битрейт/метрика качества (пункт C.4) следующая.
Выбираем несколько значений битрейта (например, 7 значений: 1, 2, 4, 6, 8, 10 и 12 Mbps), для них считаем необходимые метрики качества для каждого кодека.
Отмечаем полученные значения на графике: метрика качества (ось абсцисс) – битрейт (ось ординат).
- Линейно интерполируем.
- Выбираем максимально большой диапазон, на котором все графики определены, и находим площади под всеми графиками на нем.
- В качестве меры качества определенного кодека (или пресета) берем отношение его площади к площади для эталонного кодека. Чем меньше полученное число, тем эффективнее кодек.
За эталонный выберем x265 с пресетом, выбранным в отчете (таблица 1). В отчете используется не последняя версия компрессора, ее можно найти здесь: x265 1.5+460-ac85c775620f. Однако при использовании последней версии принципиально ничего не меняется.
Используемые пресеты компрессоров указаны в таблице 1 (для платформы desktop).
| Риппинг |
x265 -p veryslow --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
| Универсальное кодирование |
x265 -p medium --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
| Быстрое перекодирование |
x265 -p ultrafast --ref 3 --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
Для получения рекомендаций модификации пресетов проводим тестирование всех настроек, из которых они состоят – какой вклад в качество и скорость вносит каждая составляющая. План здесь следующий.
- Кодируем файл, меняя каждый параметр пресета: от быстрого перекодирования к универсальному, от универсального к «риппингу». При этом сохраняем время кодирования.
- Вычисляем меру качества (как площадь, указанную выше) и относительное время кодирования (минимальное значение FPS кодирования для файла «пресет-измененный параметр» относительно всех выбранных значений битрейта).
- Из таблицы, состоящей из изменяемого параметра, меры качества, минимального FPS, выбираем параметры, которые можно использовать для улучшения пресетов.
Ограничимся параметрами пресетов для универсального кодирования и для «риппинга» (табл. 2), раскрывая параметры «-p medium» и «-p ultrafast». Добавим к ним еще два, упущенные в отчете: «--keyint -1 --tune ssim». Перечисленными параметрами будем дополнять пресеты для быстрого и универсального перекодирования соответственно.
| Универсальное кодирование |
--rc-lookahead 20 --scenecut 40 --ctu 64 --min-cu-size 8 --bframes 4 --b-adapt 2 --subme 1 --me hex --early-skip --sao --signhide --weightp --rd 3 --aq-strength 1.0 --aq-mode 1 --cutree --no-fast-intra |
| «Риппинг» |
--weightb --amp --rect --rc-lookahead 40 --bframes 8 --tu-inter-depth 3 --tu-intra-depth 3 --rd 6 --rdoq 2 --psy-rdoq 1.0 --subme 4 --max-merge 4 --me star --ref 5 --b-intra --lookahead-slices 0 |
Тестирование
Ссылка для скачивания тестовой последовательности «Apple Tree» (рис. 1), используемой в бесплатной версии отчета, не указана. Выберем аналогичную, используя ее ключевую особенность – крупный план, большое количество мелких деталей. Например «big_buck_bunny_1080p_h264.mov», интервал в 338 кадров с 24 секунды:
ffmpeg -i big_buck_bunny_1080p_h264.mov -ss 00:00:24 -frames:v 338 -c:v rawvideo -pix_fmt yuv420p sample.yuv
Рисунок 1. Характеристика последовательности «Apple Tree»
Для того чтобы при реализации трех шагов плана, указанного выше, не тратить много времени на выписывание необходимых чисел из интерфейса Zond 265, удобно использовать его возможность работы в командной строке (таблица 3):
zond265_x64 %COMPRESSED_FILE% -iref %REFERENCE_420P_FILE% -nowait -report t=quality,statstream qm=SSIM o=%TARGET_CSV_FILE%
Список всех параметров, а также их подробное описание можно посмотреть на странице документации Zond 265.
| Параметр |
Описание |
| -iref |
Задание референсного YUV файла |
| -report |
Указание режима работы Zond 265 в командной строке |
| t=quality,statstream |
Здесь выбрана генерация двух отчетов: качества и статистики о видеопотоке |
| qm=SSIM |
Метрика качества для вычисления |
| o |
Путь до файла отчета в формате CSV |
| -nowait |
Без пауз, Zond 265 должен сам переходить от файла к файлу без задержек |
Вот два скрипта для Python 2.7: один для кодирования 266 файлов (20 настроек для первого, 18 настроек для второго пресета, для 7 значений битрейта: 1, 2, 4, 6, 8, 10, 12 Mbps), второй для составления отчета в формате CSV (файл – отношение FPS кодирования к эталонной конфигурации – отношение метрики SSIM к эталонной конфигурации).
Как видно из таблиц отчетов для фрагмента файла «big_buck_bunny_1080p_h264.mov» (таблицы 5 и 6), модифицировать конфигурации можно, например, так, как указано в таблице 4. Напомним, для улучшения эффективности значение «Мера качества» должно быть меньше единицы, а значение «Относительное время кодирования» – больше единицы.
Тест выполнен на компьютере следующей конфигурации: Intel Core i7-2600@3.4 GHz, 16 GB RAM. Наибольшее улучшение качества дает параметр «--min-cu-size 8» для конфигурации быстрого кодирования, для универсального кодирования – параметр «--rdoq-level 2» (но он же более всего замедляет кодирование).
| Быстрое перекодирование |
x265 -p ultrafast --ref 3 --rc-lookahead 20 --min-cu-size 8 --bframes 4 --early-skip --cutree --tune ssim --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
| Универсальное кодирование |
x265 -p medium --weightb --bframes 8 --tu-intra-depth 3 --psy-rdoq 1.0 --b-intra --lookahead-slices 0 --tune ssim --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
Таблица 5. Отчет о модификации пресета быстрого перекодирования
Таблица 5. Отчет о модификации пресета быстрого перекодирования
Таблица 5. Отчет о модификации пресета быстрого перекодирования
Таблица 6. Отчет о модификации пресета универсального кодирования
Таблица 6. Отчет о модификации пресета универсального кодирования
Таблица 6. Отчет о модификации пресета универсального кодирования
Правильность выбора опций легко проверить, запустив скрипт кодирования с измененными пресетами (таблица 7).
| Конфигурация |
Мера качества |
Относительное время кодирования |
| Быстрое перекодирование (эталон) |
1 |
1 |
| Быстрое перекодирование, модифицированное |
0.69 |
0.97 |
| Универсальное перекодирование (эталон) |
1 |
1 |
| Универсальное перекодирование, модифицированное |
0.85 |
0.94 |
Попробуем взглянуть, на что повлияло изменение опций – откроем в Zond 265 файл, закодированный измененным пресетом при быстром перекодировании для битрейта 8 Mbps и сравним его с файлом, закодированным неизмененным пресетом. Размер максимального блока кодирования остался прежним, и равен 32x32 (область «--ctu 32»). Но размер минимального блока уменьшился с 16 до 8 (область «--min-cu-size 8»), именно этот параметр дал наибольшее увеличение качества. Увеличилось число B-кадров с 3 до 4 (область «--bframes 4»), но при этом увеличилось и максимальное число «референсных» кадров (область «--ref 4»). Областью «SSIM» выделены максимальные значения графиков SSIM/PSNR для трех компонент: яркости (Luma) и двух компонент цветности (Cb, Cr). Они увеличились с 0.9623-0.9966 до 0.9771-0.9991. Оставшиеся дополнительные параметры (--rc-lookahead 20 --early-skip --cutree) влияют на алгоритм кодирования, а не на тип получившегося видео, это отражается, главным образом, на скорости кодирования (см. табл. 5). Надо отметить, визуально картинка декодированного кадра изменилась – артефакты кодирования теперь не видно.
Рисунок 2. Скриншот Zond 265 файла, закодированным с использованием исправленной конфигурацией быстрого кодирования
Аналогично можно проверить параметры закодированного файла с измененным и неизмененным пресетом универсального кодирования (рисунок 3). Размер минимальных разбиений TU не изменился и остался равным 4x4 (область «--tu-intra-depth 3»), количество B-кадров осталось неизменным и равно 3 (область «--bframes 3»). SSIM увеличился с 0.9789-0.9994 до 0.9811-0.9992. По сравнению с конфигурацией быстрого перекодирования увеличился размер максимального блока, стал равным 64x64 (область «--ctu 64»), добавился SAO фильтр (область «--sao»).
Рисунок 3. Скриншот Zond 265 файла, закодированным с использованием исправленной конфигурацией универсального кодирования
Таким образом, на основе проведенного тестирования предложен список опций для улучшения эффективности кодирования (улучшение значения метрики SSIM при том же битрейте и скорости кодирования) для конфигураций быстрого и универсального кодирования. С использованием предложенных изменений для файла с большим количеством мелких деталей, значение интегральной «меры качества» отчета «MSU HEVC Video Codec Comparison» при быстром перекидировании улучшилось на 31%, а при универсальном – на 15%, при этом скорость кодирования изменилась несущественно. Т.к. тестирование проведено для каждой опции отдельно, то на практике можно выбирать и использовать лишь некоторые удобные опции, а не весь предложенный список.
Ссылки
Комментарии (6)
3Dvideo
12.01.2016 15:28+1Коллеги!
Наверное все-таки не очень корректно так сравнивать.
У MSU:
- Все пресеты предоставляют авторы кодеков, все кодеки выравниваются по скорости на заранее заявленном железе.
- Всего используется 21 последовательность.
- Сравнение проводится больше 10 лет и основная интрига в том, что часть последовательностей меняется с прошлого года, причем новые последовательности неизвестны авторам кодеков, т.е. принимаются меры, чтобы авторы не затачивали пресеты под конкретные последовательности
У вас одна последовательность, на которой вы руками подобрали лучшие параметры.
Для тех, кто не в курсе, может и интересно, но те, кто в теме знают, что возможное улучшение на одной последовательности в два раза — совершенно реальный результат (тем более на рендеринге). На то она и заточка.
А теперь внимание, вопрос: А можете продемонстрировать авторам кодеков, что вы на разнородном наборе 20 разных последовательностей найдете параметры лучшие, чем знают авторы кодека?
Ибо вот это реально будет интересно и полезно! ) И авторы спасибо скажут. Даже если 3-5% будет — это будет круто.
Привет Элекарду и Томску! )
DmitryVergeles
15.01.2016 15:36Здравствуйте 3Dvideo,
Прошу прощения за медленный ответ.
Выравнивание по скорости мы учли. Относительно того, что использовали одну последовательность, исходной точкой к исследованию было то, что мы заметили разницу в профилях для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный и с двумя GOP.
Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить картину, указанную в открытом отчете для исследуемого файла (несколько удивило, что при быстром перекодировании x264 оказался лучше x265 — на графике в открытом отчете для зависимости SSIM от битрейта без учета времени). Выбранный нами фрагмент похож (как нам кажется) на описание файла открытого отчета, и графики для него получаются похожими на те, что указаны, поэтому можно считать аналогом.
Результат для совокупности файлов может оказаться другим, но, как минимум, для этого файла указание нескольких упомянутых опций (типа «keyint» и «tunessim») способно реабилитировать x265.
К сожалению у нас не было доступа к последовательностям из тестов3Dvideo
16.01.2016 00:23Похоже я плохо пояснил.
Представьте себя автором кодека. В принципе можно заточиться под последовательности этого года, но в следующем они сменятся, причем неизвестным образом. Может слабо, как в прошлом году, а может сильно как в поза-позапрошлом. И вам нужно выдать пресет не зная, какие последовательности будут в тесте.
А идут авторы кодеков на это, поскольку такой тест очень близок к тестам, которые все равно (пусть часто менее масштабно, чем мы) делают те, кто кодеки покупает (оптом и дорого ;). И в реальной работе критично, чтобы кодек (в отведенных рамках) быстро и эффективно адаптировался под неизвестные последовательности. Т.е. слепой тест ближе к реальности и реально стимулирует улучшение кодека. Тем более, что оно реально всегда возможно.
А заточиться под известную последовательность, да еще одну, да еще специфическую… Именно поэтому безмерно актуален заданный выше вопрос: можете продемонстрировать авторам кодеков, что вы на разнородном наборе 20 разных последовательностей найдете параметры лучшие, чем знают авторы кодека?
И это будет интересно всем, именно если последовательности будут достаточно разнородны, настолько, что результат будет воспроизведется на другом (неизвестном вам) наборе последовательностей. И в такой постановке даже 3-5% стабильного улучшения — это очень круто. И это путь, по которому ежегодно улучшают работу кодеков (ускоряя куски кода, улучшая адаптивность rate control и т.д.).
P.S. И к слову о последовательности. Почему вы ссылаетесь на А.1 «Apple Tree», вам последовательность A.2 “Bunny” ничего не напоминает? :))) compression.ru/video/codec_comparison/hevc_2015/MSU_HEVC_comparison_2015_free.pdf#subsection.a.A.2 Из каких соображений вы взяли как аналог самую короткую последовательность отчета, при том, что следующая за ней — фактически та самая?
stepik777
ultrafast.265: https://habrastorage.org/files/882/274/084/8822740841fb44d9946d200e41a0e851.png
ultrafast_corrected.265: https://habrastorage.org/files/fc7/2d2/0c4/fc72d20c49cc4e97922a97451534e223.png
Главное всё-таки это не SSIM, а визуальное качество.
DmitryVergeles
Здравствуйте stepik777б
Спасибо за комментарий. Здесь, похоже, еще играет роль удаленность кадра от ключевого (указанный Вами кадр где-то около второй сотни).
Для кадров недалеко от ключевого скорректированный профиль дает более четкую картинку:
dl.dropboxusercontent.com/u/102689788/original-ultrafast-8MBit-frame3.png
dl.dropboxusercontent.com/u/102689788/corrected-ultrafast-8MBit-frame3.png
Относительно SSIM, мы придерживались методики, указанной в открытом отчете, а там все опирается на вычисление этой метрики.
3Dvideo
Когда-то давно — больше 10 лет назад — было очень модно показывать пары кадров в качестве аргумента, что один кодек лучше другого. При этом в подавляющем большинстве кодеков по целому ряду причин в смысле качества идут колебательные процессы и найти пары кадров, где кодек А лучше кодека Б (и наоборот, особенно если они примерно равны) обычно не очень сложно даже вручную.
В итоге мы просто включили в качестве стандартной опции в наш MSU Video Quality Measurement Tool сравнительный анализ двух файлов с оригиналом, который позволял автоматически выдавать на двух сжатых последовательностях 10 кадров, на которых кодек А, сильнее всего выигрывает у кодека Б (и наоборот).
Народ тогда вволю повеселился, помнится )))
При этом субъективные тесты (когда, например, люди вслепую голосуют какая последовательность лучше) MSU (как и многие) также уже много лет проводит. Просто они сложнее, дороже и меньше последовательность аккуратно сравнить позволяют.