|
Кодеки и кодеры, кодирование и конвертация. Тут обсуждаются вопросы изменения формата видео, качество работы кодировщиков, а так-же известные проблемы и решения соответствующие тематике раздела. |
|
Опции темы |
13.07.2016, 16:53 | #1 |
Модератор
Регистрация: 15.07.2012
Адрес: Санкт-Петербург
Сообщений: 1,395
Сказал(а) спасибо: 344
Поблагодарили 539 раз(а) в 368 сообщениях
Вес репутации: 623 |
Сравнение кодеков XViD и h264
Эту тему можно также назвать "Качественное кодирование кодеком x264".
Скачиваем последнюю версию кодека x264.exe с авторского сайта. На день написания статьи это: [Для просмотра данной ссылки нужно зарегистрироваться] Программа x264.exe является самодостаточной DOS-программой. Для её запуска нужно написать "Блокнотом" bat-файл. Вначале пишем такой bat-файл: x264.exe --fullhelp pause Запустив этот файл, мы увидим полный список оригинальных опций, их краткое описание, а в квадратных скобках – значение по умолчанию. Если ты планируешь освоить кодирование в h264, то рекомендую откопировать всё это добро в Word-файл. Приступаем к сравнению. Для меня абсолютной истиной, не подлежащей никакому пересмотру, является кодирование на постоянном квантизёре, который должен быть одинаков для всех кадров: I, P и B. При таком подходе качество файлов h264 и XViD должно быть одинаковым (а так ли это на самом деле, мы посмотрим). Для оценки кодеков нужно сравнивать конечный объём файлов. В x264 есть, кроме кодирования чисто на постоянном квантизёре, ещё некоторая промежуточная возможность – CRF. Что переводится как "Качество, основанное на переменном битрейте". В этом режиме включается оценка скорости движения. Более быстрые и динамичные сцены будут кодироваться с меньшим качеством, чем медленные, потому что в быстрых сценах, по мнению разработчиков данной функции, будто бы качество кодирования не столь заметно, как в медленных сценах. Я сразу и бесповоротно отметаю CRF: качество – всё, мелочная экономия – на помойку. У меня ты найдёшь только QP. Кодированию могут предшествовать различные операции – деинтерлейсинг, обрезка, ресайз. Для меня также является непреложной истиной, что все эти операции нужно проводить какой-либо отличной от кодека программой, лучше всего Avisynth. На тяжкую долю кодека должен приходиться только собственно процесс кодирования, и ничего больше. Хотя бы потому, что в Avisynth мы можем выбирать и настраивать алгоритм всех этих операций. В качестве исходника для сравнения кодеков я использовал мульт "По следам бременских музыкантов" Full HD. Пишем скрипт: LoadPlugin("ffms2.dll") LoadPlugin("SplineResize.dll") LoadPlugin("YCbCrChannelMixer.dll") FFVideoSource("По следам.mkv", fpsnum=25000, fpsden=1000, seekmode=0) AssumeFPS(25) Spline144Resize(720, 576, 240, 0, -240, -0) YCbCrChannelMixer(1., 0.0993116622408317, 0.191699549740832, -37.2494351336529, 0.989853808245085, -0.110652512296676, 15.4622341186036, -0.0724529613336014, 0.983397823259837, 11.3990576734419, 0, 255, 0, 255) Про плагин YCbCrChannelMixer написано здесь: [Для просмотра данной ссылки нужно зарегистрироваться] Как видим, в этом скрипте есть обрезка чёрных полос слева и справа и ресайз до 720x576. При первом открытии этого скрипта будет произведена индексация файла-исходника, что займёт какое-то время. Поэтому первый раз я бы рекомендовал открывать скрипт Виртуал Дабом. Заодно и посмотреть, всё ли в порядке. Важно! Когда я писал о сжатии кодеком XViD, то я рекомендовал подавать на кодек видео в формате RGB. Мелочный покадровый просмотр показал, что XViD даёт более точное соответствие исходнику, если мы подадим на него RGB. С кодеком x264.exe всё обстоит с точностью до наоборот. Для получения наиболее точного соответствия оригиналу на вход x264.exe следует подавать видео именно в планарном формате YV12. Большинство исходников находятся в планарном формате YV12. Если нам нужно провести какие-либо операции, например, деинтерлейсинг, ресайз, обрезку, удаление шума и т.д., то нужно стремиться проводить эти операции именно в формате YV12, без преобразования формата. Подавляющее большинство плагинов Avisynth работают именно с планарными форматами. Но если всё-таки нам почему-либо потребовалось преобразовать планарный формат в RGB, то перед подачей на x264.exe я очень рекомендую преобразовать его в YV12. Немножко теории. Если подаваемое на x264.exe видео находится в формате, отличном от YV12, например, в RGB, то по умолчанию x264.exe вначале преобразует его в YV12 по алгоритму 601, потом будет сжимать. В процессе преобразования RGB в YV12 на некоторых участках изображения могут произойти искажения исходной геометрии. Незначительные, но всё-таки неприятно. Если мы подадим на вход YV12, то x264.exe сразу начнёт его сжимать. В этом случае никаких искажений геометрии не произойдёт. Мы можем определённой опцией заставить x264.exe кодировать в RGB, но тогда объём возрастёт иногда раза в 2, а качество практически не улучшится. Поэтому будем считать, что кодирование по умолчанию в YV12 есть наилучший вариант. Следует понимать, что если мы подали на вход кодера x264.exe изображение в формате YV12, то кодер будет его просто, не рассуждая, в упор, кодировать, не производя никаких преобразований форматов. Кодер не может знать, по какому алгоритму – 601 или 709 – закодирован пришедший к нему со стороны YV12. Он сразу же начнёт его, как он есть, сжимать в h264. Наш тестовый исходник после прохождения через YCbCrChannelMixer находится в 601. Поэтому при просмотре его нужно декодировать по 601. Если бы мы не вставили в скрипт YCbCrChannelMixer, то при просмотре нам нужно было бы декодировать по 709. Таким образом, в любом случае, каким бы способом и (или) какой бы программой ты ни сжимал, следует обстряпать дело так, чтобы на вход x264.exe изображение подавалось в формате YV12. Все мои разработки с этого форума по конвертированию можно применить, как они есть, к x264.exe, с одной существенной разницей: в скриптах не должно быть ConvertToRGB24, а заканчиваться скрипт должен YCbCrChannelMixer. Итак, предварительные операции завершены. Приступаем к кодированию. Кодировать в h264 будем таким bat-файлом: x264.exe -b 16 --b-adapt 2 --no-deblock -q 18 --ipratio 1 --pbratio 1 --no-psy --trellis 1 --no-fast-pskip --no-dct-decimate --deadzone-inter 0 --deadzone-intra 0 -m 9 --sar 4:3 -o wq.mkv ffmpeg.avs pause Объяснение опций: -b 16 – задаёт максимальное количество B-кадров, которое кодер может пустить подряд. Установлено максимально возможное значение для данной опции. "Может" здесь не означает "обязан": в зависимости от содержания кадров кодер может пустить подряд от 0 до 16 кадров. --b-adapt 2 – включение самого продвинутого алгоритма определения того, сколько же на самом деле нужно в каждом конкретном месте фильма пустить подряд B-кадров, чтобы получить наилучшее сжатие. Опции -b 16 и --b-adapt 2 в совокупности дают уменьшение объёма конечного файла где-то в районе 1%, а время кодирования увеличивают раза в два. На качество полученного изображения не влияют. Так что их, в принципе, можно опустить. --no-deblock – отключение деблокинга. Деблокинг мажет мелкие детали, и на этапе кодирования я рекомендую его всегда отключать. -q 18 – включение кодирования на постоянном квантизёре = 18. Квантизёр 18 в h264 соответствует квантизёру 2 в XViD-е. --ipratio 1 --pbratio 1 – заставляет кодировать P-кадры и B-кадры с тем же самым квантизёром, что и I-кадры. Одинаковый квантизёр для всех кадров – это для меня такая древнеегипетская святыня, которая не обсуждается. Очень рекомендую всегда делать именно так. --no-psy – отключение всех психо визуальных прибамбасов. Мой добрый жреческий совет: всегда отключай все психо визуальные алгоритмы, что бы по этому поводу кто ни гнусавил. Психо визуальные алгоритмы искажают оригинальное изображение в угоду мелочной битрейтной экономии. Например, потери чёткости тонких прожилок растений вызваны этим вредоносным алгоритмом. --trellis 1 – включение треллиса для макроблоков, как это и произошло бы по умолчанию. Макроблок – это кусок изображения размером 16x16 пикселей. Trellis равномерно размазывает имеющееся мелкое зерно и шумы по всему макроблоку. По сути, Trellis является, в некотором смысле слова, шумодавом. Притом весьма хорошим: не создаёт ни радужности, ни призраков. Особенно его действие заметно на тёмных зазернённых сценах. Исследуя эту функцию, я практически не нашёл таких полезных объектов, которые бы Trellis размазывал. Только зерно и шумы. Интересное наблюдение: с включённым Trellis размер тёмных средне зазернённых сцен получается раза в 2 меньше, чем без него. К слову, Trellis есть и в XViD. Но там он не работает с Custom-матрицами. --no-fast-pskip – отключение ускорителя для кодирования P-кадров. Все мерзости, которые хоть на долю процента ухудшают качество, должны быть безжалостно отключены! --no-dct-decimate – отключение коэффициента пороговой обработки для P-кадров. В руководствах пишется, что если эту функцию отключить, то увеличится размер конечного файла при незначительном улучшении видео. На каком месте растут глаза у тех, кто пишет о "незначительном улучшении"? Если эту функцию не отключать, то детализация ухудшится очень даже значительно. Это особенно заметно на чётких кадрах с большим разрешением. Однозначно отключаем. --deadzone-inter 0 --deadzone-intra 0 – отключение ещё одной мерзости. Мёртвые зоны экономят чуть-чуть битрейта на мало изменяемых участках, ухудшая тем самым качество. На помойку! -m 9 – улучшение полупиксельной точности. 9 означает продвинутый алгоритм для всех кадров. Включение этой опции слегка увеличивает соответствие закодированного кадра исходнику, в особенности на тёмных и туманных кадрах. --sar 4:3 – задание соотношения сторон для конечного видео, подобно тому, как мы это делали при кодировании XViD-ом. -o wq.mkv – имя выходного файла. И заканчиваются опции именем входного файла, который пишется без всяких знаков. В нашем примере это скрипт ffmpeg.avs. Есть ещё несколько опций, которые для процессора – надорвись, а реальное уменьшение объёма конечного файла от которых ничтожное. Например, -A all – разрешает кодеру производить дополнительный поиск всех допустимых размеров макроблоков, или --me esa – режим оценки движения "исчерпывающий". Я их не включил в командную строку, и тебе не рекомендую. Поехали. Запускаем bat-файл, и спокойно ждём. Вот сжатие завершено. Теперь нам для сравнения нужно этот же самый поток кадров, выходящий со скрипта и находящийся в формате YV12, напрямую подать на XViD. Делаем это так. Открываем этот же самый скрипт в Виртуал Дабе. "Video" – точка у "Fast recompress". Задаём все параметры XViD-а, как описано в моей статье про кодирование в XViD. Кодируем. Конечно, при таком подходе на XViD мы подаём не RGB, а планарный YV12, но для объективности сделаем именно так. Тем более что для XViD разница при подаче на него RGB и YV12 на самом деле очень незначительна. Сравниваем. Если за базу сравнения взять XViD, то получаем экономию объёма 27%. Если провести подобные исследования на фильмах, то получим экономию такого же порядка – 25-30%. Ух ты, как здорово! Теперь исследуем самый главный древнеегипетский параметр – качество, которое есть всё и по отношению к которому всё остальное есть ничто. Вначале определимся с термином "исходник". Под исходником я понимаю изображение, подаваемое со скрипта на кодер. А не что-то другое. Открываем скрипт в Виртуал Дабе. Выходим на интересующий нас кадр. Сохраняем его в формате bmp. Это будет "Исходник.bmp". Разжимаем полученный h264. Для получения объективной картины в декодере нужно отключить деблокинг и любую другую постобработку. В ffdshow это сделать элементарно. Получили кадр "h264 YV12.bmp". Разжимаем файл avi, сжатый кодеком XViD. Тоже отключаем в декодере деблокинг. Этот файл нужно декодировать до RGB по алгоритму 601. Потому что на вход XViD-а мы подали YV12, закодированный по 601. Получили кадр "XViD.bmp". Удалим из скрипта YCbCrChannelMixer, а на его место впишем ConvertToRGB24(matrix="rec709", interlaced=false) Снова запустим кодирующий bat-файл. Получим h264 файл, в котором при кодировании видео было подано на кодер в формате RGB. Разжав этот файл, получим кадр "h264 RGB.bmp". Начинаем сравнивать. Для получения объективного изображения в просмотровщике отключаем сглаживание. Начинаем с кадра 7650. Видим, что в "h264 RGB.bmp" контуры огня под котлом слегка играют по отношению к исходнику. В кадре 7680 такая игра особенно заметна на платье принцессы. Этого вполне достаточно для подтверждения выдвинутого в начале статьи тезиса о том, что не следует подавать на вход кодера x264.exe видео в формате RGB. Больше с RGB экспериментировать не будем. Сравниваем "h264 YV12.bmp" и "Исходник.bmp". У "h264 YV12.bmp" слегка меньше зерна на стенке котла, что даже лучше. Теперь сравним "h264 YV12.bmp" и "XViD.bmp". Разница почти не заметна. Всё-таки XViD со жреческими настройками хорошая штука. Но всё же приглядимся внимательно. На туманных частях кадра 7850 – это где поверхность холма, и на тёмных кадрах, некоторая разница имеется. "h264 YV12.bmp" точнее соответствует "Исходник.bmp", чем "XViD.bmp". Вот мы и получили долгожданный математически точный результат сравнения: при правильных – я подчёркиваю, при правильных! – настройках x264.exe получается видео, чуть более точно приближенное к исходнику, чем видео, сжатое XViD-ом. А объём h264-файла получается на 25-30% меньше, чем объём XViD-файла. Данную тему можно считать реквиемом XViD-у. Так помянем XViD: хорошая была софтинушка. Бесплатная. Свою статью про качественное кодирование в XViD я не буду убирать с этого форума: пусть висит, как памятник. В этой статье логически точно, без общих разглагольствований о "современном" и "устаревшем" софте было доказано превосходство одной программы над другой. Предвижу, сравнение кодеков заинтересует многих, и могут появиться альтернативные варианты исследований. Форум = демократия. Во избежание лишней переписи: лично я буду отвечать только на те посты, в которых рассматриваются способы, позволяющие добраться абсолютно до всех настроек кодера. С удовольствием обсужу иные опции bat-файла, позволяющие достигнуть ещё лучшего качества. Последний раз редактировалось Жрец Нефтиды; 17.08.2018 в 11:45. |
13.07.2016, 17:47 | #2 | |
Гуру
Регистрация: 05.09.2015
Сообщений: 230
Сказал(а) спасибо: 20
Поблагодарили 73 раз(а) в 60 сообщениях
Вес репутации: 375 |
Цитата:
Но. мое маленькое имхо - в современных реалиях оборудования оцифровать какой-нибудь архив домашнего видео с VHS, хоть иксвидом хоть 264 - это стоящее дело (хотя для качества vhs домашнего видео по моему без разницы чем кодировать), но зачем сейчас что то конвертировать при качестве разрешения современных форматом и всеядности средств просмотра - воткнул в любой современный TV флешку и все -enjoy, да хоть тот же DVD - лучше он не станет, хоть до 4К его разбухать тем же 264 современешим или старым софтом, хоть на ХР, хоть на 10, а если не нужна дивидишная "пена" - меню и пр, просто взять видео и нужный звук и в другой контейнер и не в наколенный не сертифицированный mkv, а в его родной контейнер m2ts. |
|
Пользователь сказал cпасибо: | rococo795 (14.07.2016) |
13.07.2016, 21:21 | #3 |
Модератор
Регистрация: 15.07.2012
Адрес: Санкт-Петербург
Сообщений: 1,395
Сказал(а) спасибо: 344
Поблагодарили 539 раз(а) в 368 сообщениях
Вес репутации: 623 |
Я давно уже не конвертирую, всё храню в исходном качестве. Данная же статья -- плацдарм для исследования опций кодека x264. Это нужно мне не для того, чтобы пережимать, а вот для чего:
[Для просмотра данной ссылки нужно зарегистрироваться] |
14.07.2016, 04:32 | #4 |
Мыслитель
Регистрация: 23.09.2012
Возраст: 43
Сообщений: 586
Сказал(а) спасибо: 50
Поблагодарили 141 раз(а) в 112 сообщениях
Вес репутации: 495 |
про математически - это сильно сказано.... этим тут и не пахнет.... я понимаю под "математически" - это когда ты взял строго ограниченное количество пикселей (часть кадра - слайс там или как его правильно кличут-давно интересовался, забыл)... показал числовую зависимость этого участка оригинальным кодером... потом ТОТ ЖЕ участок - показал зависимость в хвиде.... потом ТОТ ЖЕ участок - показал зависимость в 264..... обосновал что числовая зависимость (алгоритм сжатия) ближе к оригиналу у 264, чем числовая зависимость (описывающая цвет этого участка) у хвида.... ТОГДА можно говорить о математической точности..... а то что я увидел в этой статье - сравнение чисто "на глаз"....
|
14.07.2016, 15:07 | #5 |
Мыслитель
Регистрация: 23.09.2012
Возраст: 43
Сообщений: 586
Сказал(а) спасибо: 50
Поблагодарили 141 раз(а) в 112 сообщениях
Вес репутации: 495 |
Но труд не напрасен... И полезен...
|
15.07.2016, 16:10 | #6 |
Модератор
Регистрация: 15.07.2012
Адрес: Санкт-Петербург
Сообщений: 1,395
Сказал(а) спасибо: 344
Поблагодарили 539 раз(а) в 368 сообщениях
Вес репутации: 623 |
Вот размеры-то конечных файлов сравнены очень даже математически.
Что касается соответствия сжатого изображения исходнику. Да, есть программы числового сравнения. Вот только они не показывают, что именно различается. Если исчез шум и зерно, то это даже плюс. Если полезные детали -- то минус. Если исказилась геометрия, то это вообще безобразие. Утверждал и буду утверждать: сравнивать исходный и сжатый кадр следует только соколиным глазом. Что касается нужности этой темы. Вот тут [Для просмотра данной ссылки нужно зарегистрироваться] в посте №2 Алекс подкинул хорошую мысль. Буду подыскивать Панасоник рав или прорезь. И тогда по данным настройкам сжимать в h264 самое то, что надо. RAW ависинтом можно отрезать с точностью до кадра перед сжатием. |
16.07.2016, 06:08 | #7 | |
Мыслитель
Регистрация: 23.09.2012
Возраст: 43
Сообщений: 586
Сказал(а) спасибо: 50
Поблагодарили 141 раз(а) в 112 сообщениях
Вес репутации: 495 |
Этот аспект - да... Не спорю...
Цитата:
как сказать... частенько (особенно раньше) заходил на один форум в ветку про звук... так там аудиофилы - слышат явно разницу в двух файлах, которые абсолютно одинаковы..... на моё предложение проделать слепой тест (я нарежу куски из 2 файлов, перемешаю их, вылажу за 1 час на сервер - список, какой кусок какому файлу принадлежит, и вылажу сами куски....) Сравните говорю... и если вы их разложите по своим файлам (ведь явно всё слышат) - то обзову себя дураком... и напишу им какую нить маленькую но полезную прогу - в знак благодарности за их исключительный слух)... предлагал это год назад... и щас недавно.... - Не хотят... Вывод ясен... Они нулевые... Говорю для чего.... На глаз - можно и ошибиться... Глаз замыливается моментально... Когда ищешь параметры функций скрипта, для более качественной картинки - минут через 10-15... более качественное кажется худшим и наоборот.... - тем более в кадре надо сравнивать одинаковые места кадра во многих кадрах.... и тут думаю начнётся ералашь... не будет постоянной превалирующей во всех кадрах для одного кодера.... что то будет лучше там а что то здесь.... но это очень кропотливо...... когда то давно я сравнивал два кодировщика... CCE и ещё какой то (забыл).... так вот на общий взгляд ССЕ - был лучше и чётче.... на местах где быстрое движение - другой... а потом ваще хрень.... на быстрых местах - то там лучше то тут.... я плюнул на это дело (слабоват я для таких обоснований).... быстрое движение было - птицы взлетали с веток... Так что вот так ... думаю... |
|
16.07.2016, 06:11 | #8 |
Мыслитель
Регистрация: 23.09.2012
Возраст: 43
Сообщений: 586
Сказал(а) спасибо: 50
Поблагодарили 141 раз(а) в 112 сообщениях
Вес репутации: 495 |
ну наверно так можно отрезать всё что угодно, если данные лежат тупо в файле физически, а не образуются путём просчёта предыдущего и последующего кадров... вполне возможно я могу без всяких ависинтов вынуть любой кадр в таком именно случае... если я правильно понял смысл..
|
17.07.2016, 11:43 | #9 |
Модератор
Регистрация: 05.07.2010
Возраст: 57
Сообщений: 2,445
Сказал(а) спасибо: 722
Поблагодарили 1,039 раз(а) в 676 сообщениях
Вес репутации: 853 |
Вот тебе [Для просмотра данной ссылки нужно зарегистрироваться] 6К с камеры Red Dragon, попробуй
|
18.07.2016, 21:13 | #10 |
Модератор
Регистрация: 15.07.2012
Адрес: Санкт-Петербург
Сообщений: 1,395
Сказал(а) спасибо: 344
Поблагодарили 539 раз(а) в 368 сообщениях
Вес репутации: 623 |
Алекс, спасибо за файл: теперь я точно не буду покупать ред. Этот замороченный формат даже Super не жрёт.
|
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Метод объективной оценки качества аудио кодеков | Жрец Нефтиды | Кодеки и кодеры, кодирование и конвертация. | 6 | 02.02.2021 08:42 |
Качественное кодирование кодеком XViD | Жрец Нефтиды | Кодеки и кодеры, кодирование и конвертация. | 97 | 21.02.2019 11:25 |