x264 + VirtualDub vs XviD. Исследуем возможности, повышаем эффективность

  • Tutorial
В предыдущем посте я писал про разработку собственной матрицы под XviD. Той статьи не было бы, если б я сразу занялся x264. А занялся я им, потому что видел, что такие проблемы XviD, как квадратичность, искажение градиента цвета, ореол вокруг объектов, устраняются в x264.
Целью задачи стало выяснение этих возможностей кодека, а также скорости кодирования и размера файла. x264 успешно справился со всеми задачами и ниже вы узнаете, как это сделать легко и непринуждённо.

Краткая информация


Кодек x264 — очень успешная реализация стандарта H.264, созданная под крылом сообщества VideoLAN (автора VLC media player) со свободной лицензией. Обычно экспортируется консольный вариант, ориентированный в первую очередь на юниксоидов, под винды также есть варианты с графическим интерфесом. Собственно, недружественность опенсорсных разработчиков с рядовыми пользователями (вечные проблемы с документацией и графическим интерфейсом успешно и по сей день отделяют Microsoft от многих хороших и бесплатных проектов) и стала тормозным фактором на пути выхода кодека к широким массам и любителям видеоколлекций. Но, слава Всевышнему, не всё так уныло на сегодняшний день и есть достойные графические варианты. Теперь будьте внимательны, потому что речь пойдёт именно о релизе 2273 от Komisar (ссылка здесь). Сам файл, который установится в систему, это x264vfw.dll. Установить его можно на любой диск, а установщик позаботится, чтобы этот путь попал в реестр винды. Также вы можете иметь установленным этот кодек, если у вас есть полный K-Lite Codec Pack. Если там иная версия, установите 2273. Я пробовал версию 2274 с другим интерфейсом — категорически не советую, если только вы не собираетесь вникать в консольные команды. Чтобы вы не запутались, смотрите скриншоты.





Маркёром выделены ключи, которые мы будем разбирать и менять. Поехали.

Quantizer — квантизатор, который огрубляет итоговый сигнал, чем больше, тем хуже качество. Я кодирую только квантизатором и только в один проход, почему — смотрите предыдущий пост.
Здесь он отличается от того, что в XviD, поэтому я прикинул, что нужно брать значения кратные 4. Вот резюме:
4, 8 — рекомендуется только тем, кто занимается обработкой видео, так как качество идеальное, но большой размер файла;
12, 16 — для любителей качественных роликов небольшого размера в домашней коллекции;
20 — мой выбор, самый оптимальный квантизатор, подходит для фильмов;
24, 28 — компромиссный вариант, нормальное качество, подходит для большинства фильмов и сериалов, а также для загрузки роликов на ютуб;
32 и выше — бывают и такие случаи.

Во второй вкладке много интересных и полезных настроек.
Блок Analysis — разбивка блоков на части, фишка стандарта H.264, призвана обеспечить лучшее качество, но на поверку оказалась практически бесполезной — размер файла увеличивается, улучшение качества нужно искать с микроскопом, так что отключайте все «пташки».

Subpixel ME refinement — сложность оценки движения, значения от 1 до 11.
Чем больше, тем меньше размер и скорость. На самом деле размер уменьшался до 5, с цифры 6 размер стал расти, а скорость падать, видимо, это связано с Psy RDO, который до цифры 6 не работает. Так что вывод такой: если хотите максимальную скорость, то ставьте 1 и жертвуйте несколькими мегабайтами, если же не хотите жертвовать мегабайтами, а минутами, то ставьте 5.

Max GOP size — максимальный интервал между ключевыми кадрами, подробнее в предыдущем посте. Ставьте в пределах 200-300 и не партесь.

Max consecutive B-frames — максимальная последовательность B-кадров, чем их больше, тем меньше размер, но с этим нужно быть осторожней, могут быть проблемы с воспроизведением. Рекомендую 1 или 2.

Мы подошли к блоку Encoding и это, пожалуй, наиболее интересная часть настроек.
Deblocking filter (птичка и два числовых значения) — решает проблему квадратов, так ненавистных у XviD. По-умолчанию стоят значения 0, максимум 6. Мне 0 показалось мало и я попробовал 6 — понравилось. Теперь всегда буду ставить 6. Компромисс — 3.

Intra / Inter Deadzone — сглаживающий фильтр, работает по принципу Гаусса. Интересно, что в VirtualDub есть подобный фильтр и я им часто пользовался, но теперь он особого смысла не имеет. Дело в том, что при использовании его только в VirtualDub кодек в итоге всё равно оставляет шумы, а если использовать его только в кодеке — никаких проблем с шумами. Я выбрал максимум 32, потому что некоторые моменты просто восторгают — проезжающая машина даёт перламутровый блеск, море и небо просто загляденье. Некоторые заметят, что есть недостаток замыливания мелких деталей, тогда советую меньшие значения, кратные 4. Отключить совсем можно при квантизаторе меньше 16. На скорость не влияет.

Остальные ключи на этой вкладке объяснять не буду — просто поставьте, как на скриншоте.
Теперь третья вкладка, скриншота нет и не нужно. Там только нужно изменить два значения раз и навсегда. QP factor — выставьте оба в 1, если не хотите сюрпризов в виде неожиданного ухудшения качества.

Теперь важная инормация для тех, кто пользуется внешним плеером. Если есть проблемы с воспроизведением, сделайте следующие настройки:
Max frame refs = 1, Max consecutive B-frames = 0, CABAC = выкл.
Не все эти настройки одновременно влияют на совместимость, поэтому экспериментируйте.

На скорость могут влиять Subpixel ME refinement, Max frame refs, Max consecutive B-frames. За счёт использования многоядерности x264 оставляет позади XviD. С теми настройками, которые на скриншотах, размер файла сопоставим с XviD со средним квантизатором, но качество гораздо лучше. Так что прощай старый добрый XviD, ты много отнял у меня времени и нервов, а также дискового пространства, но тебе пора на заслуженный покой.

Кто любит паковать в mkv — юзайте MeGUI, инфы в инете достаточно. А если вам нравится в avi, то пожалуйте в VirtualDub. Кстати, как быстро открыть неавишный файл в VirtualDub? Легко. Ставите AviSynth, создаёте текстовый файл с расширением .avs и пишите строку
DirectShowSource("путь к фильму")
Если название кириллицей, не забудьте про кодировку Win. Потом открываете файл в VirtualDub. Рекомендации по звуку в предыдущем посте. Если делаете рипы в HD для заливки на ресурсы, можно вместо квантизатора 20 использовать 24 или 28, но обязательно с Deblocking filter и Intra / Inter Deadzone — получите нормальное качество с малым размером.

Для особо интересующихся здесь можно почитать о настройках x264 на русском.

Кодируйте на здоровье!

Комментарии 20

    +2
    В целом хорошая статья, но я бы поспорил много с чем… Начиная с того что деблок 6 это запредельная жестокость :) кроме очень специфических случаев я бы не стал использовать значения выше 1, а с квадратами бороться лучше или увеличивая битрейт или используя параметр --force-cfr (перевод в режим кодирования с постоянным качеством) с параметрами --crf 18 --crf-max 22. Ну и самое главное — где на этой картинке можно задать самое главное для тщательного кодирования значение --subme?
    И вообще Гуи — для слабаков и командной строки по-моему запускать честнее и правильнее :)
      0
      По поводу деблока я говорил, что по-умолчанию 0, компромисс 3, так что выбор есть. Особенно актуально на высоком квантизаторе.
      Ключ subme — это Subpixel ME refinement, я описал его достаточно подробно. Сразу видно, что вы привыкли к консольному варианту.
      И да, вы правы, GUI для тех, кто не хочет тратить время на изучение горы документации. И для них же мой пост. А насчёт честности спорный вопрос — поэтому юниксоиды и виндари совершенно из разных миров.
        0
        все-таки вряд ли Subpixel ME refinement это subme — там же всегда должны быть не менее 10?
          0
          там и есть 11, вы же читали, ну я надеюсь ;-)
      +4
      О боже, какая ересь. У меня нет слов.

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

      В статье же вредных советов примерно столько же, сколько и самих советов. Начиная от использования не-фреймаккуратного DirectShowSource (который вряд ли нужен с учетом того, что икс умеет открывать большинство файлов самостоятельно через ffms2), проходя через откровенно странную информацию (выставление QP Factor не имеет смысла с CQP ибо квантайзер и так постоянный) и заканчивая настройками, способными убить горы битрейта вникуда (CQP в x264 это маразм, ровно как и отключение анализа, такое мизерное количество B-кадров и т.д.).

      используя параметр --force-cfr (перевод в режим кодирования с постоянным качеством)

      cfr != crf. Cfr это постоянная частота кадров. --crf-max тоже в принципе бесполезен в абсолютном большинстве случаев, а кому полезен — сами знают об этом.

      Ребят, я вас умоляю — разберитесь в теме хоть немного, прежде чем давать советы.
        –1
        Весьма сумбурный комментарий, если я не прав, объясните толково, где, и почему правы вы.
        Мне показалось, что вы не вполне представляете себе, что такое CQP. CQP не может быть маразмом в принципе, ибо без него кодирование вообще невозможно, разве только вы придумаете и запатентируете иной принцип.
          +4
          CQP — один из нескольких алгоритмов рейтконтрола в x264. С чего вы решили, что кодирование без постоянного квантайзера невозможно?

          С чего вы решили, что при количестве B-кадров больше 1-2 будут проблемы с вопроизведением? Может, перепутали с рефами? А на каких устройствах?

          Почему вы решили, что значение --merange 8 будет оптимальным для всех источников? Это по меньшей мере в два раза меньше значения, используемого иксом по-умолчанию для всех пресетов.

          Почему вы решили, что использовать deadzones лучше, чем trellis? Почему вы называете его сглаживающим фильтром, работающим по принципу Гаусса, которым он не является?

          О части других ошибок я уже написал выше.

          У меня вопрос: вы пробовали смотреть в то, какие настройки получается при использовании обычного --preset veryslow? Они там совершенно отличные от ваших и на это есть причина. ;) Я советую вам всё же подумать, почему ваш гайд отличается от абсолютного большинства рекоммендаций, исходящих как от самих разработчиков энкодера, так и от просто опытных пользователей. Кстати, вы пробовали читать хоть какие-то полноценные гайды? Потому что у меня складывается впечатление, что нет.
            0
            Ну наконец-то я понял, что вы имели ввиду. Вы говорите о CRF, а я писал про CQP (Constant Rate Factor). Это не одно и то же. Да, CRF использует CQP, но на своё усмотрение, вы пребываете в некотором неведении относительно результата, когда кодируете через CRF, а с CQP такого казуса не произойдёт — он всегда даёт стабильный результат. Поэтому я новичкам советую именно его. А вам советую разобраться в определениях и не писать попусту. Кодирование без квантизатора вообще действительно невозможно, если говорить о ядре кодека.

            Насчёт B-кадров сложный вопрос — если вы проигрываете в том же месте, что и кодировали, то проблем быть не должно. К тому же блоки из таких кадров усложняют декодирование и ухудшают качество видео, так что новичкам опять же не рекомендуется. Выигрыш в размере можно получить и другим способом, а иной пользы от B-кадров просто нет.

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

            Deadzone лучше чем Trellis, потому что я протестировал результаты обоих. Trellis увеличивает размер и не всегда улучшает качество, а Deadzone всегда сглаживает в заданных пределах и всегда уменьшает размер. Deadzone точно по Гауссу, потому что я знаю, как выглядят картинки после такого фильтра — другим способом этого не достичь. Каким образом работает Trellis — не знаю, а потому резонно задаться вопросом: «на кой он такой кактус?»

            --preset veryslow. Я писал, что пробовал версию 2274 с другим интерфейсом, там была одна вкладка и выбор пресетов. Я попробовал некоторые и результат был отстойным. Далее пробовать не было желания. А заполнять команды вручную после выбора пресета — разве это не маразм? Уж лучше учится работать в консоли.

            Говорите про полноценные гайды? Если они доходчиво написаны и экспериментально подтверждены — киньте ссылку, буду благодарен.
              +3
              Нет, действительно, ересь. Статья про xvid у вас отличная, а эта — фигня. CQP в реальной жизни вообще не используется, все используют CRF вообще в любом случае. Неаккуратный DirectShowShource, как уже tp7 заметил, vfw, 1 bframe, 3 reframe, 6:6 deblock… Это действительно все чушь, вообще все.
              Пожалуйста, уделите изучению x264 больше времени, покрутите пресеты. Тут все не так, как вы привыкли в xvid.
                0
                Обычно критиканы так и говорят: «всё у вас фигня, идите учите матчасть». А обосновать свою критику не могут. Я же в статье написал, почему я выбрал такие значения, и пользователь всегда может выбрать свои. Эта статья писалась не для вас, не для гуру, не для тех, кто сидит часами у консоли — она для тех, кто хочет получить нормальный результат быстро и без напряга.

                CQP не может быть фигнёй в принципе — в данном случае это вам надо изучать матчасть, ибо вы, видимо, не знаете, зачем в x264 CQP, поэтому и говорите, что не используется.

                DirectShowShource возможно хуже FFMpeg, но это мне простительно, статья вообще не об этом. Кстати, лагает он в основном на mkv, так что обычный пользователь может и не заметить разницы.

                Вчера закодировал 100 минут фильм 1280х694 менее чем в 2 гига. Качество вполне пристойное. Если у вас получится лучше — скиньте настройки, буду благодарен.
                  0
                  Эта статья писалась не для вас, не для гуру, не для тех, кто сидит часами у консоли — она для тех, кто хочет получить нормальный результат быстро и без напряга.

                  Вы говорите так, будто я обычно все параметры выверяю. Я просто использую пресеты и tune, как правило. Конечно, когда релиз аниме делаю, что-то настраиваю, но это бывает редко.

                  CQP не может быть фигнёй в принципе — в данном случае это вам надо изучать матчасть, ибо вы, видимо, не знаете, зачем в x264 CQP, поэтому и говорите, что не используется.

                  Ну, возможно, я и не прав, это вполне вероятно, но я не видел ни одного человека, который бы использовал CQP, ведь CRF и придумали для того, чтобы управлять квантизатором в автоматическом режиме: на сложных сценах понижать значение, а на простых — повышать.
                  CQP можно использовать, например, если вам нужно передать видеоматериал, который в дальнейшем нужно редактировать, через интернет, но я даже в этом случае использую CRF.

                  DirectShowShource возможно хуже FFMpeg, но это мне простительно, статья вообще не об этом.

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

                  Вчера закодировал 100 минут фильм 1280х694 менее чем в 2 гига. Качество вполне пристойное. Если у вас получится лучше — скиньте настройки, буду благодарен.

                  Ну, вы, наверное, все еще живете в мире xvid 704×396 avi dvdrip мокрые письки скачать бесплатно, раз считаете такой результат чем-то невероятным.
                  serv.valdikss.org.ru/Downloads/zaletchiki-stream-v2.mp4
                  Это не лучший пример, но так я обычно кодирую видео для вещания по сети. 1 час 20 минут, размер — 743 мегабайта. Параметры кодирования вы можете посмотреть через mediainfo, например.
                    0
                    Про эксперимент с пресетами я писал в комменте выше.

                    Ссылка на стрим не работает у меня. Если найдёте приличные настройки — скиньте. А вообще сильно сжать не проблема. Я кодировал в HD и качество получилось неплохое, при тех же требованиях сжать ещё больше — вот интересная задачка.

                    Если многие не используют CQP — это меня заинтересовало. Неужели мало кто понимает, что это за штука?
                      0
                      Это FTP-ссылка, если вы ее выделяете.

                      Файл разрешением 1280×720, параметры такие:
                      cabac=1 / ref=8 / deblock=1:1:1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=26.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
                        0
                        Давайте устроим эксперимент просто. Я буду кодировать пресетами и тюнами, а вы — как хотите, один и тот же видеоматериал. Вот прямо сейчас такой эксперимент проведем.
                        Предлагаю кодировать вот это:
                        ftp://serv.valdikss.org.ru/Anime/K-ON!/K-ON!_OP1_%5B1080p,BluRay,x264%5D_-_THORA%20v2.mkv
                        Согласны?
                          0
                          Не имею доступа к серверу. Вы сначала объясните суть — какой размер и длительность, как проверять качество? Если длинный кусок, я не буду тратить время. Если вы с пресетами добавляете отдельные ключи — это уже другой разговор. Если диалог затягивается — пишите в лику.
                            0
                            Странно, у вас вообще не открывается FTP?
                            Файл размером 145МБ, 1 минуту 30 секунд идет.
                            Давайте в ЛС.
            0
            кстати да — торможу насчет crf и виноват — давно не кодировал и все позабылось…
            0
            Решил внять рекомендациям и попробовать закодировать в CRF. Подвох обнаружился, когда я смекнул, что значит «динамическая сцена» с точки зрения кодера. В VirtualDub я изменил частоту кадров и кодировал с теми же настройками CRF. В итоге стало ясно, что то же самое видео с меньшей частотой кадров воспринимается кодеком как slow-mo, а с большей частотой как «динамическая сцена». И естественно, что в первом случае размер файла стал больше, а во втором меньше. Такой фокус с CQP не проходит, поэтому это ещё одна причина не кодировать в CRF — слишком непредсказуемый результат.
              0
              Нашёл ещё один лёгкий способ открытия неавишных файлов в VirtualDub. Здесь есть ссылки на Virtualdub FFMpeg Input Plugin. Только подберите нужную версию, а то у меня v0.7 пошла, а v0.8 нет. Из архива файл FFInputDriver.vdplugin и папку ffdlls нужно положить в папку plugins Virtualdub'а и всё. Пробовал на mkv, mp4, mov, полный список форматов указан на сайте.
              Можно использовать способ FFMpeg через AviSynth, но новичкам придётся попотеть.
                0
                Собственная поправка. Дополнительные тесты показали, что блок Analysis с птичками frames partitions улучшает качество и даже уменьшает размер. Так что включайте все птички.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое