Кодек или параметры кодирования на точках разреза не совпадают
В октябре 2015 был выпущен очередной отчет сравнения кодеков в ВМиК МГУ, на этот раз туда вошло несколько кодеков формата HEVC.
Исходной точкой к исследованию стало то, что мы заметили разницу в пресетах в тестах для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный с несколькими GOP. При этом для единственного описанного в открытом отчете файла “Apple Tree” кодер x264 оказался лучше x265 при быстром перекодированим на графиках зависимости SSIM от битрейта без учета скорости кодирования. Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить указанную картину.
В отчете сравниваются пресеты, но не даются рекомендации по их исправлению. В данной статье мы провели аналогичное сравнение и привели рекомендации по модификации пресетов кодера х265. Для видеопоследовательности, аналогичной исследуемой в бесплатной версии отчета, предлагаемые изменения параметров кодирования позволяют повысить эффективность сжатия, при этом они реабилитируют кодер x265 при построении графиков отчета.
Измененные пресеты не претендуют на универсальность, тестирование на большом количестве видеопоследовательностей выходит за рамки данного исследования. Однако их можно рекомендовать как отправную точку при поиске возможностей увеличения эффективности кодирования x265.
О проекте
Задача кодирования видео при обработке мультимедиа, будь то передача, монтаж или редактирование, хранение, возникает постоянно как при разработке приложений и сервисов, так и при их настройке в момент использования. В силу большого количества популярных видеокодеков, даже зачастую одного типа, выбрать из них оптимальный, а затем задать правильные настройки, непросто. Вероятно, руководствуясь подобными соображениями, в лаборатории компьютерной графики и мультимедиа при факультете вычислительной математики и кибернетики (ВМиК) МГУ с 2000х ведется работа над проектом сравнения видеокодеков.
В октябре 2015 года был опубликован отчет сравнения кодеков, в котором участвуют некоторые кодеки формата HEVC, а так же несколько других, активно разрабатываемых в настоящее время. В качестве «эталонного» принят компрессор x264. Одним из интересных в отчете является компрессор x265, именно его изучением и займемся.
В качестве инструмента для анализа будем использовать SolveigMM Zond 265, анализатор файлов HEVC/H.265 и AVC/H.264.
Вводная часть: профили
Настроек и параметров у H264 такое количество, что сами разработчики для того, чтобы в них не запутаться, решили сделать список профилей — «хороших» конфигураций для разных целей. Стандартных профилей определили много; дополнительно, устанавливая собственные параметры кодирования, вы, фактически, создаёте собственный профиль, запутывая всех окончательно. Так что, к сожалению, получилось как всегда.
Изначально профили создавались для определения, будет ли проигрываться итоговое видео на нужном типе устройств, однако сейчас какого-то однозначного разделения проигрывателей по типам устройств и профилям нет.
На практике я бы выделил, по уровню ресурсоёмкости декодирования, три группы параметров:
Теперь к отдельным параметрам.
10 Новых статей
• Мыльные пузыри в After Effects | (Добавлено: 18.02.10) |
• Простой DVD-Video авторинг на материале восстановленном с поврежденного диска | (Добавлено: 15.04.09) |
• Имитация дождевых капель на стекле в Adobe After Effects | (Добавлено: 22.04.08) |
• Создание динамичной среды DVD проекта HDV с кнопками видеоменю в Adobe After Effects | (Добавлено: 07.04.08) |
• Создание видеоменю HDV с видеокнопками в Adobe Encore DVD | (Добавлено: 07.04.08) |
• "Огненные буквы" в After Effects | (Добавлено: 28.03.08) |
• Применение плагина Trapcode Particular для размножения трехмерного объекта | (Добавлено: 28.03.08) |
• Использование модели кисточки, импортируемой в After Effects | (Добавлено: 25.03.08) |
• Сердце из роз – динамическое сердце из трехмерной модели бутона | (Добавлено: 24.03.08) |
• Знакомство с программой Vasco da gamma | (Добавлено: 15.03.08) |
Гостей: 0
Пользователей: 0
Продолжаю раскрывать особенности работы видео сервисов. Сегодня заметки про параметры кодирования и их выбор.
Большинство кодеков предлагают достаточно сбалансированные значения по умолчанию, позволяя получить нормальный результат без долгого подбора параметров. Однако, когда речь идёт о большом архиве видеоматериала, об ограничениях на битрейт, соображениях совместимости с оборудованием клиента и разумном желании сохранить качество оригинала, всё становится интереснее.
К сожалению, волшебной кнопки «скодировать совсем хорошо» не предусмотрено. Как и аналога caniuse для параметров кодирования. Придётся разбираться в особенностях работы кодеков.
Slices
Для ускорения декодирования (и кодирования) видео можно разделить на части более низкого разрешения. Идея в том, что обработать четыре видео с разрешением, например, 1280x720 проще, чем одно, но 2560x1440. Имеет смысл при разрешениях выше FHD. Чем больше частей, тем ниже эффективность кодека. Также, использование такого разделения упрощает многопоточную обработку.
Качество сжатия конкретного фильма может сильно зависеть от параметров кодирования
Большинство об этом не задумывается (должны же были авторы кодеков ВСЕ предусмотреть! :), но у кодеков, как правило, есть достаточно много параметров, позволяющих при том же размере файла заметно (а то и кардинально) изменить качество. В первую очередь это параметры стратегии битрейта, особенно режимы "quality - based" & "bitrate - based". Потом параметры префильтрации. В частности, deinterlacing, ибо встречаются фильмы, которые сжимали в чересстрочной развертке в MPEG-4 (и, видимо, удивлялись слабому качеству :), denoising (подавление шумов), deflicking (подавление мерцания) и т.д. Существуют параметры управления частотой ключевых кадров, маской использования B-frames, управление зависимости префильтра от фильма и т.д. Это означает, что имея кодеки А и Б (примерно равного качества), можно легко установить один кодек в режим Maximum Perfomance (все ручки сдвинуть до предела в сторону скорости сжатия), а другой в режим 2-pass Maximum Quality (все ручки до предела в сторону максимального качества), можно получить 2 фильма одного размера, но существенно разного качества. Можно даже эти фильмы на сайт выложить и предложить убедиться! :) Что с успехом многие компании и делают. При этом душераздирающие подробности того, что один кодек работал в 10 раз меньше другого, предпочитают оставлять за кадром. Зачем людям (тем более журналистам) знать лишнее? :) При этом исходный несжатый файл никто не кладет, обосновывая это его большим размером. А почему не кладут параметры сжатия - вы теперь знаете.
В этом кодеке из-за ошибки в rate control на одном из битрейтов резко падает качество (да, ошибки в кодеках тоже бывают :). Для этого кодека данный битрейт будет весьма неудачным параметром.
На самом деле существуют и другие, более тонкие способы получать как реальное преимущество, так и "преимущество". (Например, не существует методик, определяющих, насколько пропуск кадров критичен для восприятия и т.д.) Но эти - основные. Итак! Если хорошо вникнуть в методы "надувательства" при сравнении 2 кодеков, то становится понятно, что для корректного сравнения необходимо достаточно глобальное тестирование. Т.е., как минимум, нужно сравнивать разные по характеру фильмы с разными битрейтами, причем с использованием интегральных (средних) характеристик качества по всему фильму. Именно для этого и было проведено настоящее сравнение. Всего было протестировано 32 доступных кодека. В качестве тестовых были выбраны 9 последовательностей разного характера. Для того, чтобы проверить все кодеки на разных битрейтах, пришлось прогнать их более 2400 раз с разными параметрами (и то фактически тестировались только параметры по умолчанию)! Суммарное время счета составило больше 11 суток, причем реальное время было больше, поскольку из-за ошибок (в т.ч. ошибок в кодеках) часть последовательностей приходилось пересчитывать.Часть 1: Методология тестирования
Чересстрочность
Чересстрочность придумали для удвоения воспринимаемой частоты кадров минимальными затратами — битрейт и разрешение те же, а частота выше. Однако, при быстром движении становятся заметны зубцы — строки предыдущего кадра. Избавиться от эффекта, не отбрасывая кадры и не уменьшая вертикальное разрешение, можно фильтрами, но они уменьшат чёткость. Если видео будет проигрываться в браузере, чересстрочность лучше отфильтровать при кодировании, т.к. реалтайм-фильтрация на клиенте даст не лучшие визуальные результаты.
10 Популярных статей
Анаморфные пиксели
Прямоугольные пиксели появляются тогда, когда соотношение сторон и отношение пиксельной ширины к высоте отличаются — широкоформатные DVD, где 16:9 видео имеет разрешение 704×480 (3:2 с аналоговым НДС и поправкой на ветер). Проигрывание таких видео проблем не вызовет, однако при кодировании нужно учитывать одновременно и разрешение и соотношение сторон, иначе легко преобразовать анаморфные либо в стандартные квадратные пиксели с потерей эффективности (до ~35%!), либо вообще получить что-то сплющенное по горизонтали.
О проекте
Задача кодирования видео при обработке мультимедиа, будь то передача, монтаж или редактирование, хранение, возникает постоянно как при разработке приложений и сервисов, так и при их настройке в момент использования. В силу большого количества популярных видеокодеков, даже зачастую одного типа, выбрать из них оптимальный, а затем задать правильные настройки, непросто. Вероятно, руководствуясь подобными соображениями, в лаборатории компьютерной графики и мультимедиа при факультете вычислительной математики и кибернетики (ВМиК) МГУ с 2000х ведется работа над проектом сравнения видеокодеков.
В октябре 2015 года был опубликован отчет сравнения кодеков, в котором участвуют некоторые кодеки формата HEVC, а так же несколько других, активно разрабатываемых в настоящее время. В качестве «эталонного» принят компрессор x264. Одним из интересных в отчете является компрессор x265, именно его изучением и займемся.
В качестве инструмента для анализа будем использовать SolveigMM Zond 265, анализатор файлов HEVC/H.265 и AVC/H.264.
Тестирование
Ссылка для скачивания тестовой последовательности «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. Отчет о модификации пресета быстрого перекодирования
Таблица 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%, при этом скорость кодирования изменилась несущественно. Т.к. тестирование проведено для каждой опции отдельно, то на практике можно выбирать и использовать лишь некоторые удобные опции, а не весь предложенный список.
Формат файлов с расширением .avi известен как медиаконтейнер, это формат файлов, так же как MP3 или JPG. Но, в отличие от этих форматов, AVI — это формат-контейнер. Это означает, что он может содержать видео/аудио данные, сжатые с использованием разных комбинаций кодеков, что позволяет синхронно воспроизводить видео со звуком. Так, если MP3 и JPG файлы построены на использовании только основного вида компрессии данных (MPEG Audio Layer 3 и JPEG), AVI файл может содержать различные виды компрессированных данных (например, DivX — видео + WMA — аудио или Indeo — видео + PCM — аудио) , в зависимости от того, какой кодек используется для кодирования/декодирования. Как и DVD, AVI файлы поддерживают многопотоковое аудиовидео. AVI-файлы могут содержать различные виды сжатых данных, к примеру DivX для видеоинформации и MP3 для аудио. Все AVI файлы выглядят одинаково «снаружи» (имеют расширение .AVI), но «внутри» они могут отличаться очень сильно.
Кодек-устройство или программа, способная выполнять преобразование данных или сигнала.
AVI (Audio-Video Interleaved) разработан Microsoft для хранения и воспроизведения видеороликов, представляет собой контейнер, в котором может быть что угодно, начиная от MPEG1 и заканчивая MPEG4. Он может содержать в себе потоки 4 типов - Video, Audio, MIDI, Text. Причем видеопоток может быть только один, тогда как аудио - несколько. В частности, AVI может содержать и только один поток - либо видео, либо аудио. Сам формат AVI не накладывает совершенно никаких ограничений на тип используемого кодека, ни для видео, ни для аудио - они могут быть любыми. Таким образом, в AVI файлах могут совершенно спокойно сочетаться любые видео- и аудиокодеки.
Если коротенько, то собственно формат и кодек, это практически одно и тоже. А вот AVI форматом видео никогда не являлся. Это аудио-видео контейнер, в нём может располагаться как видео так и аудио различных форматов. То есть файлы закодированные с помощью различных кодеков.
Кодеки - это программы для чтения и проделывания каких либо операций с видео файлами. AVI один из форматов видео файлов (от формата зависит качество "картинки").
Любой файл состоит из данных. Эти данные должны иметь определённую структуру, чтобы машина (программа) поняла их и правильно обработала. Формат файла это и есть спецификация их структуры. То есть определённые законы, по которым надо эти данные обрабатывать и понимать. Может ли формат файла сжимать и упаковывать данные? Да может. Это бывает не всегда, но встречается очень часто. Например, формат .txt показывает, что это текстовый файл, что его надо обрабатывать как текст и позволяет это выполнять тем программам, которые работают с текстовыми файлами. Но этот формат ничего не сжимает. А вот формат .jpg показывает, что данный файл надо понимать и обрабатывать как растровое графическое изображение, но, кроме этого, он так структурировал исходный графический файл, что сжал изображение, отбросив часть первоначальных данных, то есть часть информации, и сделал файл меньше, легче. В последнем случае, формат файла (спецификация его структуры) выполнила сразу две задачи.
Кодек (применительно к Вашему вопросу) это специальная программа, которая кодирует данные для удобного их хранения и передачи. Как правило, это кодирование направленно на сжатие и упаковку потока данных, но это бывает не всегда, иногда кодеки выполняют другие ункции.
Любой видеофайл обязательно имеет свой формат, в противном случае машина вообще не поймёт, что это за «кусок» данных предлагается ей для обработки. Кроме этого, информация в файле может быть закодирована каким-то кодеком и им же раскодирована при воспроизведении (т. е. при превращении нулей и единиц в реальное изображение). Кодек и формат файла – это вещи принципиально разные, хотя иногда выполняют одну схожую функцию: сжатие данных файла.
Это связано со многими факторами. Во-первых, в кодеке работает такой механизм как управление битрейтом, которое дает колебания качества даже у хороших кодеков. Во-вторых, сам пользователь выбирает разные стратегии битрейта, и в случае выбора CBR (или постоянный битрейт) на медленных сценах качество будет высоким, а на быстрых - низким. В-третьих, у кодеков есть т.н. ключевые кадры, качество которых обычно изменяется отдельно, и отличается от качества остальных кадров. В-четвертых, на качество влияет префильтрация (которая есть у всех современных кодеков). В-пятых. В-шестых. В-седьмых. :)
Это означает, что на любом достаточно длинном фильме (а средний фильм это 150000-200000 кадров) можно подобрать как достаточно хорошие, так и достаточно плохие кадры. Особенно если использовалось однопроходное CBR сжатие на достаточно динамичном фильме.
Статьи
Всего 89 Статей в 7 Категориях
• РЕДАКТИРОВАНИЕ DVD (25) |
- Простой DVD-Video авторинг на материале восстановленном с поврежденного диска |
- Как убрать ненужные кнопки из анимированного меню DVD. |
- Пережимаем MJPEG в MPEG2 |
- Настройка оптимальных параметров кодирования CinemaCraft Encoder |
- Как правильно выбрать поля при кодировании в MPEG 2 |
- Описание програмы MenuEdit |
- Руководство по DVD Decrypter |
- Руководство по DVD2AVI |
- Руководство по работе с Vobedit часть 3 |
- Руководство по работе с Vobedit часть 2 |
- Руководство по работе с Vobedit часть 1 |
- 5. Реавторинг DVD с использованием CCE и IfoEdit - часть 3 |
- 5. Реавторинг DVD с использованием CCE и IfoEdit - часть 2 |
- 5. Реавторинг DVD с использованием CCE и IfoEdit - часть 1 |
- 4. DVD-Видео: Глобальный стандарт |
- 3. FAQ по редактированию DVD |
- 2. Структура DVD и термины |
- 1.2.2. HeadAC3he, Sonic Foundry Soft Encode, Steinberg Nuendo |
- 1.2.1. Chopper XP, TMPG Encoder, M2-edit Pro |
- 1.2. Редактирование |
- 1.1.3 TMPG Encoder |
- 1.1.2 MpegUtils, Vstrip, DVD2AVI |
- 1.1.1 VobRator, VobEdit, Smartripper |
- 1.1 Демультиплексирование |
- 1. Введение и схема процесса |
• РЕДАКТИРОВАНИЕ ЗВУКА (6) |
- Библиотеки Smartsound и их использование |
- Преобразования формата DTS в WAV |
- "Перемонтаж" DVD диска |
- Создание и редактирование объемного 5.1 звука для DVD |
- Переводим звуковую дорожку в DVD |
- Русскоязычная озвучка фильма |
• ПЕРЕЖАТИЕ DVD9>DVD5 (5) |
- Сравнение DVD2ONE и DVD Shrink |
- Руководство по DVD Shrink версии 3.1 |
- Использование DVD Shrink для пережатия диска DVD9 |
- Как оставить на DVD только основной фильм |
- Руководство по копированию DVD9 на DVD5 |
• АВТОРИНГ DVD (9) |
- Руководство по DVD Menu Studio - часть 3 |
- Руководство по DVD Menu Studio - часть 2 |
- Руководство по DVD Menu Studio - часть 1 |
- Описание программы DVD Reauthor |
- Перевод руководства по программе DVD Lab и DVD LAB PRO |
- Описание DVD Lab PRO |
- Описание Adobe Encore DVD - часть 3 |
- Описание Adobe Encore DVD - часть 2 |
- Описание Adobe Encore DVD - часть 1 |
• ЖЕЛЕЗО (6) |
- "Пиратский" принтер |
- Пишем DVD на два слоя с помощью. LiteOn 451S и 851S! |
- Доработка miroVIDEO Capture |
- Разблокировка DVin входа в видеокамерах Panasonic MiniDV |
- Камера Hitachi DZ-350 |
- TВ тюнер с аппаратным захватом MPEG2 |
• РАЗНОЕ (24) |
- Знакомство с программой Vasco da gamma |
- Сокращенный перевод некоторых глав руководства по фильтру Neat Video |
- Создание анимированного пути на карте с помощью программы Curious World Maps 5.5 |
- Принципы работы инструментов Histogram (Levels) и Curves |
- СРАВНИТЕЛЬНЫЙ АНАЛИЗ ПРОГРАММ EDIT* И LIQUID CHROME - часть 2 |
- СРАВНИТЕЛЬНЫЙ АНАЛИЗ ПРОГРАММ EDIT* И LIQUID CHROME - часть 1 |
- Базовые методы цветокоррекции в пакете Liquid Edition 5.5 - тоновый баланс |
- Перевод руководства по PINNACLE EDITION |
- Keing в программе Combustion - часть 2 |
- Keing в программе Combustion - часть 1 |
- Инструмент COLOR CORRECTOR и COLOR MATCH в ADOBE PREMIERE PRO - часть 3 |
- Инструмент COLOR CORRECTOR и COLOR MATCH в ADOBE PREMIERE PRO - часть 2 |
- Инструмент COLOR CORRECTOR и COLOR MATCH в ADOBE PREMIERE PRO - часть 1 |
- Базовые методы цветокоррекции в пакете Liquid Edition 5.5 - баланс серого |
- Модуль захвата программы Liquid 5.5, особенности и возможности. |
- Интервью с "Пиратом" |
- Руководство по работе с программой Particle Illusion v.3.0 - часть 4 |
- Руководство по работе с программой Particle Illusion v.3.0 - часть 3 |
- Руководство по работе с программой Particle Illusion v.3.0 - часть 2 |
- Руководство по работе с программой Particle Illusion v.3.0 - часть 1 |
- Как заставиь Premiere правильно отображать шрифт |
- Перевод руководства по программе Title Motion Pro "Основы Title Motion Pro " |
- Как установить TitleMotion Pro 5.0, не имея TitleMotion 4.2.1 в качестве базы для апдейта? |
- Перевод руководства по программе Title Motion |
• Уроки (14) |
- Мыльные пузыри в After Effects |
- Имитация дождевых капель на стекле в Adobe After Effects |
- Создание динамичной среды DVD проекта HDV с кнопками видеоменю в Adobe After Effects |
- Создание видеоменю HDV с видеокнопками в Adobe Encore DVD |
- "Огненные буквы" в After Effects |
- Применение плагина Trapcode Particular для размножения трехмерного объекта |
- Использование модели кисточки, импортируемой в After Effects |
- Сердце из роз – динамическое сердце из трехмерной модели бутона |
- FAQ по EDITION |
- Перевод Read Me по Pinnacle Liquid 6.1 |
- Подготовка меню выбора сцен для DVD видео диска в Liquid Edition 5.5 |
- Подготовка и кодирование в MPEG2 анимированного (Motion) меню выбора сцен для DVD-видео диска с использованием пакета Liquid |
- Создание рукописной надписи в AE - другой способ |
- Создание рукописной надписи в AE |
Контроль битрейта
Есть три основных режима работы кодеков, связанных с битрейтом:
- постоянный битрейт, CBR, когда качество падает пропорционально сложности сцены;
- постоянное качество, const Q VBR, когда пропорционально сложности сцены растёт битрейт;
- ограниченные битрейт и качество — классический VBR.
Для онлайн проигрывания (да и для стриминга) хорошо подходит constrained VBR, т.к. он даёт лучшее, чем CBR, качество и позволяет уместить поток в интернет-канал.
Выбор maxrate/minrate зависит от канала клиента, разброс больше 20% лучше не делать.
Цветовое пространство
Выбор цветового пространства практически не влияет на эффективность кодирования; этот параметр можно было бы оставить на выбор кодека (он важен при обработке сырых, некодированных данных), если бы не одна особенность: многие плееры весьма специфически обрабатывают информацию о цветовом пространстве, так что у большой части пользователей видео может отображаться с искажениями цвета (в основном зелёного).
Чтобы сохранить цвета для большинства плееров, разные H264 видео нужно кодировать в разных пространствах:
Многопроходное кодирование
Распределение данных по файлу в VBR-режиме предсказать сложно, кодекам приходится угадывать, что получается не всегда. В многопроходном режиме кодек сперва составляет карту требующегося битрейта, а потом кодирует. Таким способом улучшается качество видео в сложных и динамических сценах (пример. Обратите внимание на количество «муарных» элементов и количество переходов между сценами). Так как при первом проходе кодек только анализирует исходный файл, вопреки распространённому мнению, обработка в таком режиме требует времени больше не в два раза, а только на 10-15%.
Для разных типов исходного материала подготовлено несколько пресетов, подстраивающих некоторые базовые параметры кодирования — такие, как уровни деблокинг-филитра, параметры психовизуальной оптимизации. Использование этих пресетов улучшает восприятие видео и хорошо работает, если вы заранее знаете тип источника, или у вас структурированный набор видео (в случае массовой обработки).
- film — для фильмов и всего со сложной структурой кадра. Это — однозначно film;
- animation — для видео с большими однотонными областями. То есть, это лучше кодировать с пресетом animation, а это — film, несмотря на то, что анимация;
- stillimage — для видео, где почти нет движения; хорошая оптимизация для тех песен в формате mp4, где в течение всего видео фоном — обложка альбома (кто-нибудь, скажите им, что даже flac на 10 минут не может весить 300MB!);
- grain — для кодирования «шумных» источников, вроде камер наблюдения;
- psnr/ssim — для оценки эффективности остальных параметров кодека;
- fastdecode — форсированный main-профиль для слабых устройств;
- zerolatency — как и следует из названия, для стриминга с низкой задержкой.
Методика тестирования
Последовательность действий
В тестировании участвует девять фильмов (см. ниже). Каждый фильм сжимается десять раз с разными битрейтами (кбит/с.): 100, 225, 340, 460, 700, 938, 1140, 1340, 1840, 2340. Для компрессии фильмов используется программа VirtualDub 1.4.13. Таким образом, для каждого кодека генерируется 90 фильмов. Затем для каждого фильма вычисляется метрика PSNR и количество drop-фреймов. Причем указанная метрика вычисляется как для каждого кадра, так и для всей последовательности – среднее значение по всем кадрам. Далее для построения графика используются соответствующие числа, в зависимости от типа графика.
Разные кодеки "затачиваются" под разные типы фильмов
Межкадровая разница показывает, насколько сильно отличаются кадры. Черный цвет свидетельствует о том, что разницы нет; синий, зеленый и красный по возрастающей показывают различия, имеющиеся в изображениях. Если привести эти кадры в качестве сравнения, то Divx 3.1 будет лучше Divx 5.1.
GOP size
Группы изображений — блоки, в пределах которых одни изображения могут ссылаться на данные других. Увеличение размера GOP повышает эффективность кодека в обмен на повышение требований к памяти. Большие значения особо эффективны для файлов с однотипными, циклическими движениями (вы же понимаете, о чём я). Также, при больших значениях могут возникнуть проблемы с перемоткой видео, т.к. нужно будет восстановить больший объём данных.
Название параметра, также, как и единицы измерения, могут отличаться от кодека к кодеку — смотрите документацию.
Фреймрейт
Если ваш источник — не стримы игр или экшн-видео, то имеет смысл ограничить верхнее значение фреймрейта 25-30 кадрами — чем их меньше, тем больше остаётся данных для описания отдельного кадра. Уменьшать это значение лучше кратно — так, чтобы пропуск кадров был равномерным, иначе от видео может возникнуть ощущение подтормаживания.
Есть ещё такая вещь, как переменная частота кадров. Работать с VFR неудобно по двум причинам: во-первых, это даёт пики битрейта на участках с высокой частотой, которые мгновенно опустошают буфер; во-вторых, VFR усложняет составление плана конвертации, заставляя использовать Q-параметры (о них я писал в первой статье).
Собираем всё вместе
Пример для x264:
Разумеется, в одной статье всё охватить не получилось, но уверен, этого материала будет достаточно для улучшения качества многих видео.
Читайте документацию и экспериментируйте.
В дополнение к примеру из прошлой статьи, я узнал о ещё одной инсталяции моего кода — клик. Примеры в статье постарался брать с этих сайтов, но не смотря на это:
*Я не имею прямого отношения к авторам упоминаемых сайтов и могу не разделять их взгляды и мнение. Решения о том, кому и как предоставляется доступ к коду я комментировать не могу.
Готов ответить на вопросы.
Станете ли вы платить за хостинг вашего видеоматериала при наличии там инструментов управления качеством и доступом к видео?
Формат пикселей
Формат и битность сильно влияют на то, как сжимаются и разжимаются файлы, в каком виде теряется качество. Основные параметры, которые описывает пиксельный формат:
- способ разложения цвета на компоненты — YUV, RGB;
- параметры цветовой субдискретизации (о как! chroma subsampling привычнее), когда некоторые цветовые компоненты сохраняются с меньшим разрешением;
- глубина цветовых компонентов в битах.
- не все кодеки (и, главное, декодеры) поддерживают возможные форматы;
- работа с некоторыми форматами требовательнее к ресурсам — Hi10P отличается от просто high-профиля именно этим;
- работа с субдискретизированными форматами может дать заметное повышение эффективности сжатия, однако регулировать потери качества сложнее.
Методика сравнения кодеков и подбора параметров
Опишем методику. Сравнение в отчете проводится по критериям битрейт-качество (SSIM, PSNR)-скорость.Описанная в отчете методика для сравнения соотношения битрейт/метрика качества (пункт C.4) следующая.
Выбираем несколько значений битрейта (например, 7 значений: 1, 2, 4, 6, 8, 10 и 12 Mbps), для них считаем необходимые метрики качества для каждого кодека.
Отмечаем полученные значения на графике: метрика качества (ось абсцисс) – битрейт (ось ординат).
- Линейно интерполируем.
- Выбираем максимально большой диапазон, на котором все графики определены, и находим площади под всеми графиками на нем.
- В качестве меры качества определенного кодека (или пресета) берем отношение его площади к площади для эталонного кодека. Чем меньше полученное число, тем эффективнее кодек.
Риппинг | 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, выбираем параметры, которые можно использовать для улучшения пресетов.
Метрика PSNR
Описание метрики
В рамках данного тестирования критерием оценки качества сжатия служит метрика PSNR (peak signal to noise ratio/пиковое отношение сигнала к шуму, измеряется в дБ). Использование именно этой метрики обусловлено ее популярностью, ее используют во многих научных статьях и сравнениях в качестве меры потерь качества. Как и все существующие метрики, она не идеальна и имеет свои достоинства и недостатки. Для понимания приведенных ниже цифр, необходимо знать лишь то, что значение метрики тем больше, чем больше разница между сравниваемыми изображениями. Программу для PSNR-анализа можно загрузить здесь.
Смысл графиков PSNR/Frame size
На графике изображена зависимость показателя метрики от среднего размера кадра. Каждая ветвь соответствует определенному кодеку. Ветви построены на опорных точках, каждая из которых соответствует конкретному битрейту. Очевидно, на каждой ветви находится по десять точек (каждая последовательность сжимается на 10 настройках битрейта). Бывает, что кодек не удерживает битрейт и с разными настройками битрейта сжимает одинаково. В таких случаях, очевидно, на ветви кодека расположено менее десяти опорных точек. Для сравнения кодеков на этих графиках следует обращать внимание на то, как высоко расположены ветви кодеков. Чем выше находится ветвь – тем выше качество последовательности, сжатой данным кодеком. На приведенном рисунке видно, что на низком битрейте качество последовательности, сжатой кодеком Morgan Multimedia JPEG 2000, выше, чем у последовательности другого кодека. Однако на высоком битрейте Visicron J сжал последовательность с меньшими потерями качества по сравнению с кодеком MM JPEG2000.
Смысл графиков PSNR/Frame size (with drop frames)
Drop-фреймами называются кадры, которые кодек пропускает; на их место в видеопоследовательности подставляется последний сжатый кадр. Drop-фреймы являются средством понижения битрейта сжимаемой последовательности. Однако при большом количестве drop-фреймов в последовательности наблюдается эффект «слайд-шоу» - вместо динамической сцены кодируется лишь один кадр, который и будет показан в нужный интервал времени при проигрывании сжатого видео. Графики этого вида позволяют оценить количество реальных кадров в видеопоследовательности.
При сравнении кодеков на данных графиках следует обращать внимание на то, как близко к оси ординат расположены ветви на графике, отражающем использование drop-фреймов. Чем левее находится ветвь кодека, тем меньшие средние размеры кадров характерны для соответствующей сжатой последовательности. И следовательно, тем больше FPS на выходе. Таким образом, кодеки, чьи ветви расположены левее, дают на выходе больше FPS при том же качестве.
Читайте также: