Софт-Архив

X264

Рейтинг: 4.1/5.0 (74 проголосовавших)

Описание

Как выбрать оптимальный битрейт и ключевые параметры для рипа в x264

Как выбрать оптимальный битрейт и ключевые параметры для рипа в x264

В связи с тем, что многие при выборе битрейта ошибочно полагаются лишь на показатель b-p/f. который иногда помогает, а иногда оказывается совершенно бесполезной цифрой, привожу на мой взгляд более правильную методику подсчёта целевого битрейта. Каждый видеоряд обладает разной сжимаемостью, для некоторых 0.1 пресловутого b-p/f достаточно, чтобы прозрачно без артефактов закодироваться в компактный размер. Бывают же сложные видеопоследовательности, которые не помещаются и в .25 b-p/f. Намётанный глаз сразу распознает приблизительную сложность видоряда для кодека, но более-менее достоверно оценить сжимаемость можно нижеописанным способом (занимает не более 5-10 минут с учётом времени на енкод, если только не использован тормозной скрипт). Имеет смысл при подготовке основательного рипа с упором на размер-качество.

Задача: Сжать распределённую выборку из целевой видеопоследовательности с заданным коэффициентом качества и оценить полученный результат.

2550 фреймов, составленный из равномерно выдернутых из видеоряда кусков по 50 фреймов. Обычно этого достаточно, чтобы оценить сжимаемость более-менее равномерного видео длительностью до 1.5-2 часов.

Три строки:

selectTotal1=framecount()/100

X264:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    X264 VFW Codec 2538

    Another project alternative is x264vfw by masternobody, has a GUI simplified (I love her) and seemingly more actively developed than Komisar's version.

    NEW SOFTWARE = New tool since your last visit

    NEW VERSION = New version since your last visit

    NEW COMMENT = New comment since your last visit

    Type and download

    NO MORE UPDATES? = The software hasn't been updated in over 2 years.

    NO LONGER DEVELOPED = The software hasn't been updated in over 3 years.

    RECENTLY UPDATED = The software has been updated the last 31 days.

    Freeware = Free software.

    Free software = Free software and also open source code.

    Freeware/Ads = Free software but supported by advertising, usually with a included browser toolbar. It may be disabled when installing or after installation.

    Free software/Ads = Free software and open source code but supported by advertising, usually with a included browser toolbar. It may be disabled when installing or after installation.

    Trialware = Also called shareware or demo. Trial version available for download and testing with usually a time limit or limited functions.

    Payware = No demo or trial available.

    Portable version = A portable/standalone version is available. No installation is required.

    v1.0.1 = Latest version available.

    Download beta = It could be a BETA, RC(Release Candidate) and even a ALPHA version of the software.

    Download (direct link) = A direct link to the software download.

    Download (developer's site) = A link to the software developer site.

    Download (mirror link) = A mirror link to the software download. It may not contain the latest versions.

    Download old versions = Free downloads of previous versions of the program.

    Download 64-bit version = If you have a 64bit operating system you can download this version.

    Download portable version = Portable/Standalone version meaning that no installation is required, just extract the files to a folder and run directly.

    = Windows version available.

    = Mac OS version available.

    = Linux version available.

    Our hosted tools are virus and malware scanned with several antivirus programs using www.virustotal.com .

    X264

    Это руководство рассматривает две главные категории опций кодирования:

    Опции, в основном влияющие на соотношение скорость-качество.

    Опции, которые могут быть полезны для удовлетворения различных пользовательский предпочтений и специальных требований.

    В конце концов, только Вы можете решать какие опции являются лучшими для Ваших целей. Решение для первого класса опций очень простое: надо только определить, считаете ли Вы, что разница в качестве оправдывает разницу в скорости. Для второго класса опций предпочтения могут быть значительно более субъективными и зависеть от большего числа факторов. Имейте в виду, что некоторые из опций категории "пользовательских предпочтений и специальных требований" могут все же иметь большое влияние на скорость или качество, но это не основное их предназначение. Часть опций из "пользовательских предпочтений" могут даже привести к изменениям, которые выглядят лучше для одних людей и хуже — для других.

    Перед тем как продолжить, Вам придется понять, что это руководство использует только одну метрику качества: глобальный PSNR. Краткое описание того, что такое PSNR, смотрите в статье Википедии о PSNR. Глобальный PSNR — это последнее значение PSNR, выводимое на консоль, когда в x264encopts включена опция psnr. Каждый раз, когда Вы читаете утверждения о PSNR, за ними скрывается предположение, что используются одинаковые значения битпотока.

    Почти все комментарии этого руководства предполагают, что Вы используете два прохода. Есть две основные причины использовать двухпроходное кодирование при сравнении опций. Во-первых, использование двух проходов увеличивает PSNR примерно на 1дБ, что является очень хорошим значением. Во-вторых, тестирование опций прямым сравнением качества при однопроходном кодировании вводит основной сбивающий фактор: зачастую битпоток значительно меняется при каждом кодировании. Не всегда можно с легкостью сказать, изменилось ли качество в основном за счет изменения опций, или оно по большей части отражает случайные изменения в полученном битпотоке.

    7.5.1.2. Опции, затрагивающие, в основном, скорость и качество

    subq. Из всех опций, позволяющих выбирать между скоростью и качеством, subq и frameref (смотрите ниже), пожалуй, самые важные. Если Вы заинтересованы в тонкой настройке либо скорости, либо качества, эти две — первое, с чего Вам стоит начать. С точки зрения скорости, опции frameref и subq очень жестко взаимодействуют друг с другом. Опыт показывает, что с одним ссылочным кадром subq=5 (настройка по умолчанию) расходует на 35% больше времени, чем subq=1. С 6 ссылочными кадрами эта величина достигает 60%. Эффект subq на PSNR выглядит довольно постоянным, в отличие от количества ссылочных кадров. Как правило, subq=5 достигает значения глобального PSNR на 0.2-0.5 дБ большего, чем при subq=1. Обычно этого достаточно, чтобы заметить.

    subq=6 — медленнее и дает лучшее качество при разумной цене. Если сравнивать с subq=5. он обычно дает на 0.1-0.4 дБ больший глобальный PSNR ценой потери 25%-100% скорости. В отличие от остальных уровней subq. поведение subq=6 не так сильно зависит от frameref и me. Вместо этого, эффективность subq=6 по большей части зависит от количества используемых B-кадров. При обычном использовании это означает, что subq=6 в сложных, высокодинамичных сценах имеет большое влияние как на скорость, так и на качество, но в сценах с малым количествах движения она не имеет такого эффекта. Имейте в виду, что по-прежнему рекомендуется всегда устанавливать bframes в значение, отличное от нуля (смотрите далее).

    subq=7 — самый медленный режим с наилучшим качеством. По сравнению с subq=6 он, обычно, улучшает общий PSNR на 0.01-0.05 дБ ценой потери 15%-30% скорости. Поскольку соотношение качества и времени кодирования очень невелико, Вам следует использовать этот режим, только если боретесь за каждый бит, и время кодирования Вас не волнует.

    frameref. frameref по умолчанию установлена в 1, но это не значит, что ее стоит устанавливать в 1. Только увеличение frameref до 2 дает прирост PSNR примерно на 0.15дБ за счет уменьшения скорости на 5-10%; похоже, что это неплохая цена. frameref=3 дает примерно 0.25дБ PSNR сверх frameref=1. что должно быть видимой разницей. frameref=3 медленнее примерно на 15%, чем frameref=1. К сожалению, улучшение очень быстро сходит на нет. От frameref=6 можно ожидать прироста PSNR лишь на 0.05-0.1 дБ по сравнению с frameref=3 с дополнительной потерей 15% скорости. Выше frameref=6 качество обычно увеличивается очень незначительно (хотя на всем протяжении этой дискуссии Вам следует иметь в виду, оно может значительно изменяться в зависимости от исходного материала). В довольно типичном случае frameref=12 улучшит глобальный PSNR всего на 0.02дБ по сравнению с frameref=6. ценой 15%-20% скорости. При таких высоких значениях frameref. единственная действительно хорошая вешь, о которой может быть сказано, состоит в том, что дальнейшее ее увеличение почти никогда не будет вредить PSNR, но увеличение качества будет трудно даже измерить, не говоря уже о его заметности.

    Замечание:

    Увеличение frameref до чрезмерно высоких значений может и обычно наносит вред эффективности кодирования, если CABAC отключен. С задействованным CABAC (настройка по умолчанию), возможность установки frameref "слишком высоким" на данный момент выглядит слишком далекой, чтобы об этом беспокоиться, а в будущем оптимизации могут вообще убрать такую возможность.

    Если Вас заботит скорость, разумным компромиссом будет использовать низкие значения subq и frameref в первом проходе, а затем увеличить их во втором. Обычно, это обладает ничтожным отрицательным эффектом на конечное качество: Вы, возможно, потеряете вплоть до 0.1дБ PSNR, что должно быть слишком малой разницей, чтобы её заметить. Однако, различные значения frameref могут иногда повлиять на решение о выборе типа кадра. Скорее всего, это довольно редкие крайние случаи, но если Вы хотите быть точно уверенными, посмотрите, содержит ли Ваше видео полноэкранные периодически вспыхивающие изображения или очень большие паузы, которые могут стать причиной принудительной вставки I-кадра. Настройте frameref в первом проходе так, чтобы она была достаточно большой для содержания длительности цикла вспыхивания (или паузы). Например, если сцены вспыхивают и гаснут между двумя изображениями в течении трёх кадров, установите frameref равным 3 или выше. Эта проблема, возможно, очень редко появляется для живой съемки, но она иногда возникает при записи видео игр.

    me. Эта опция используется для выбора метода оценки движения. Изменение этой опции оказывает прямое влияние на соотношение скорость-качество. me=dia лишь на несколько процентов быстрее, чем поиск по умолчанию, ценой не больше 0.1дБ глобального PSNR. Значение по умолчанию (me=hex ) — разумный выбор между скоростью и качеством. me=umh немного, вплоть до 0.1дБ, улучшает глобальный PSNR, соответствующее падение скорости меняется в зависимости от frameref. С высокими значениями frameref (например, 12 или около того), me=umh примерно на 40% медленнее, чем настройка по умолчанию me=hex. С frameref=3. падение скорости уменьшается до 25%-30%.

    me=esa использует исчерпывающий поиск, который работает слишком медленно для практического применения.

    partitions=all. Эта опция задействует использование сегментов 8x4, 4x8 и 4x4 в предсказанных макроблоках (в дополнение к стандартным). Ее включение приведет к довольно постоянной 10%-15% потере в скорости. Эта опция практически бесполезна для исходного материала, содержащего только небольшое движение, тем не менее, для некоторого высокодинамичного материала, особенно с большим количеством мелких движущихся объектов, следует ожидать прироста около 0.1дБ.

    bframes. Если Вы занимались кодированием с другими кодеками, то могли заметить, что B-кадры не всегда полезны. В H.264 это изменилось: есть новые техники и типы блоков, возможные в B-кадрах. Обычно, даже примитивный алгоритм выбора B-кадров может дать значимую выгоду для PSNR. Интересно заметить, что использование B-кадров обычно отчасти ускоряет второй проход, а также может ускорить однопроходное кодирование, если отключено адаптивное принятие решения о B-кадрах.

    С отключенным адаптивным принятием решения о B-кадрах (nob_adapt в x264encopts ), оптимальное значение этой опции обычно не превышает bframes=1. иначе могут пострадать высокодинамичные сцены. С включенным адаптивным принятием решения о B-кадрах (поведение по умолчанию), можно безопасно использовать более высокие значения; кодировщик уменьшит количество B-кадров в сценах, где они повредят сжатию. Кодировщик редко решает использовать больше, чем 3 или 4 B-кадра; установка этой опции в любое более высокое значение не будет иметь большого эффекта.

    b_adapt. Заметьте: она включена по умолчанию.

    Когда эта опция включена, кодировщик будет использовать разумно быстрый процесс принятия решения для уменьшения количества B-кадров, используемых в сценах, которые от этого не сильно выиграют. Вы можете использовать b_bias для тонкой настройки того, насколько "счастлив" будет кодировщик использованию B-кадров. Потеря в скорости при использовании адаптивных B-кадров на данный момент весьма невелика, но таково же и потенциальное улучшение качества. Тем не менее, хуже от этого обычно не становится. Заметьте, что эта опция влияет на скорость и решение о типе кадра только в первом проходе. b_adapt и b_bias не имеют эффекта в последующих проходах.

    b_pyramid. С тем же успехом Вы можете включить эту опцию, если используете >=2 B-кадров; Вы получите небольшое улучшение качества без потери в скорости, как и говорит man руководство. Имейте в виду, что такое видео не может быть прочитано основанными на libavcodec декодерами, созданными ранее, чем примерно 5 Марта 2005.

    weight_b. В обычных случаях эта опция не дает большого улучшения. Однако, в проявляющихся или затухающих сценах взвешенное предсказание дает довольно большую экономию битпотока. В MPEG-4 ASP затухание обычно лучше кодируется последовательностью дорогих I-кадров; использование взвешенного предсказания в B-кадрах делает возможным преобразовать хотя бы часть из них в значительно более меньшие B-кадры. Потери в скорости кодирования минимальны, поскольку не требуется делать дополнительные принятия решений. Вдобавок, вопреки расхожему мнению, взвешенное предсказание не сильно влияет на требования декодера к CPU при прочих равных условиях.

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

    threads Эта опция позволяет породить потоки для параллельного кодирования на нескольких CPU. Вы можете вручную выбрать количество создаваемых потоков или, что лучше, установить threads=auto и позволить x264 определить количество доступных CPU и выбрать соответствующее количество потоков. Если у Вас многопроцессорная машина, Вам следует всерьез задуматься об использовании этой опции, так как она может увеличить скорость кодирования линейно в зависимости от числа CPU ядер (около 94% на ядро), незначительно уменьшая PSNR (примерно 0.005 дБ для двухпроцессорной, 0.01 дБ — для четырехпроцессорной машины).

    7.5.1.3. Опции, относящиеся к различным предпочтениям

    Двухпроходное кодирование. Выше советовалось всегда использовать кодирование в два прохода, но все же существуют причины этого не делать. Например, если Вы захватываете TV трансляцию и кодируете в реальном времени, придется использовать однопроходный режим. К тому же один проход очевидно быстрее, чем два; если Вы используете точно такой же набор опций в обоих случаях, двухпроходной режим медленнее почти вдвое.

    Все же существует очень хорошие причины использовать кодирование в два прохода. Во-первых, управление битпотоком однопроходного режима не является телепатом и часто делает необоснованный выбор, потому что не может видеть общую картину. Например, предположим, что Вы имеете двухминутное видео, состоящее из двух независимых частей. Первая половина — очень динамичная сцена, продолжающаяся 60 секунд и требующая сама по себе битпоток примерно 2500 кбит/сек, чтобы прилично выглядеть. Сразу за ней следует гораздо менее требовательная 60-секундная сцена, которая хорошо выглядит при 300 кбит/сек. Предположим, Вы запросили битпоток 1400 кбит/сек; в теории этого достаточно для удовлетворения потребностей обеих сцен. В этом случае управление битпотоком в однопроходном режиме сделает пару "ошибок". Во-первых, оно установит битпоток в 1400 кбит/сек для обеих частей. Первая часть может оказаться чрезмерно квантованной, что приведет к недопустимо выглядящему и неоправданно блочному изображению. Вторая часть будет существенно недостаточно квантованной; она может выглядеть отлично, но цена битпотока для этого качества будет полностью неоправданной. Чего намного труднее избежать, так это проблемы перехода между двумя сценами. В первых секундах малодинамичной части квантователь будет чрезвычайно превышен, потому что управление битпотоком все еще ожидает встретить такие же требования к битпотоку как и в первой части. Этот "ошибочный период" с чрезвычайно превышенным квантованием будет выглядеть раздражающе неприятно и использовать на самом деле меньше, чем 300 кбит/сек, требуемых ему для того, чтобы прилично выглядеть. Существуют способы смягчить эффект от подобных подводных камней однопроходного режима, но они могут иметь склонность к усилению неверного предсказания битпотока.

    Многопроходное кодирование может предложить огромные преимущества по сравнению с однопроходным. Используя статистику, собранную при первом проходе, кодировщик может оценить, с разумной точностью, "стоимость" (в битах) кодирования любого заданного кадра при любом заданном квантователе. Это делает возможным намного более рациональное, лучше спланированное распределение битов между дорогими (высокодинамичными) и дешевыми (малодинамичными) сценами. Смотрите qcomp ниже, чтобы узнать некоторые идеи о том, как можно это распределение настроить по Вашему вкусу.

    Более того, два прохода занимают не двойное время по сравнению с одним. Вы можете настроить опции первого прохода на более быструю скорость и низкое качество. Если хорошо выберете опции, Вы получите очень быстрый первый проход. Полученное качество во втором проходе будет несколько ниже, потому что предсказание размера менее точно, но разница в качестве обычно слишком мала, чтобы быть заметной. Попробуйте, например, добавить subq=1:frameref=1 в x264encopts первого прохода. Затем, при втором проходе, используйте более медленные, с лучшим качеством опции: subq=6:frameref=15:partitions=all:me=umh

    Кодирование в три прохода. x264 предоставляет возможность делать желаемое количество последовательных проходов. Если Вы указали pass=1 при первом проходе, используйте затем pass=3 в последующем проходе, этот проход будет одновременно читать статистику предыдущего прохода и записывать свою собственную. Дополнительный проход, следующий за этим, будет иметь очень хорошую основу для осуществления очень точных предсказаний размеров кадров при выбранном квантователе. На практике, общее улучшение качества от использования этого режима близко к нулю и, вполне возможно, третий проход приведет к немного худшему глобальному PSNR, чем у предыдущего прохода. При обычном использовании три прохода помогают, если Вы при двух проходах получаете либо плохое предсказание битпотока, либо плохо выглядящие переходы между сценами. Это отчасти то, что наверняка будет происходить на очень коротких клипах. Существуют также особые случаи, когда три (или более) проходом удобны для продвинутых пользователей, но, для краткости, это руководство не включает в себя описание этих особых случаев.

    qcomp. qcomp управляет соотношением количества бит, отданных "дорогим" высокодинамичным и "дешевым" малодинамичным кадрам. Один крайний случай: qcomp=0. предназначен для истинно постоянного битпотока. Обычно это сделает высокодинамичные сцены выглядящими просто ужасно, в то время как малодинамичные сцены будут, возможно, выглядеть абсолютно великолепно, но при этом будут использовать во много раз больший битпоток, чем им необходимо, чтобы выглядеть лишь превосходно. Другая крайность: qcomp=1. добивается примерно одинакового параметра квантования (QP). Постоянный QP не выглядит плохо, но большинство людей думают, что более разумно частично снизить битпоток в сильно дорогих сценах (где потеря качества не очень заметна) и перераспределить их в сцены, которые легче закодировать с отличным качеством. qcomp по умолчанию установлена в 0.6, что по мнению многих людей может быть несколько мало (также часто используется 0.7-0.8).

    keyint. keyint — единственная возможность выбора между удобством перемещения по файлу и эффективностью кодирования. По-умолчанию keyint установлена в 250. В материале с 25fps это гарантирует возможность перемещения с точностью до 10 секунд. Если Вы считаете, что более важным и полезным будет перемещение с точностью до 5 секунд, установите keyint=125 ; это немного ухудшит качество/битпоток. Если Вы заботитесь только о качестве, но не о перемещаемости, Вы можете установить значение этой опции в более высокое значение (понимая, что улучшение будет убывающим, вплоть до исчезающе малого или даже нулевого). Видео поток по-прежнему будет иметь точки перемещения, пока в нем есть какие-то изменения сцен.

    deblock. Этот раздел может быть несколько спорным.

    H.264 определяет простую процедуру удаления блочности в I-блоках, которая использует предустановленные степени обработки и пороговые значения в зависимости от QP рассматриваемого блока. По-умолчанию, блоки с высоким QP обрабатываются сильнее, а в блоках с низким QP удаление блочности вообще не производится. Предустановленые степени обработки, определенные стандартом, тщательно подобраны и имеют хорошие шансы быть PSNR-оптимальными для любого видео, которое Вы пытаетесь кодировать. Опция deblock позволяет указать смещения предустановленных пороговых значений деблокинга.

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

    Первая и самая важная вещь, которую нужно знать о in-loop фильтре удаления блочности состоит в том, что пороговые значения по умолчанию практически всегда PSNR-оптимальны. В редких случаях, где они неоптимальны, идеальное смещение будет плюс минус 1. Изменение параметров деблокинга на большие значения фактически гарантирует ухудшение PSNR. Усиление фильтра размажет больше деталей; ослабление — оставит больше квадратиков.

    По определению плохая идея уменьшать пороги деблокинга, если Ваш исходный материал в основном имеет небольшую пространственную сложность (т.е. не имеет множества деталей или шума). In-loop фильтр делает весьма неплохую работу по сокрытию появляющихся артефактов. Однако, если исходный материал имеет высокую пространственную сложность, артефакты будут практически незаметны. Это происходит потому, что ореолы имеют склонность выглядеть как детали или шум. Зрительное восприятие легко замечает отсутствие деталей, но ему не так легко обратить внимание на неверно изображенный шум. Когда речь идет о субъективном качестве, шум и детали в некоторой степени взаимозаменяемы. Уменьшая силу фильтра удаления блочности, Вы, скорее всего, увеличиваете ошибку, добавляя ореолы, но глаз этого не замечает, поскольку он путает артефакты с деталями.

    Однако, это по-прежнему не оправдывает уменьшение силы фильтра. Вы в большинстве случаев можете получить более качественный шум при помощи постобработки. Если результат кодирования при помощи H.264 выглядит слишком смазанным или размытым, попробуйте поиграть с -vf noise. при воспроизведении закодированного фильма. -vf noise=8a:4a должна скрыть большинство мелких артефактов. Ее результат почти наверняка будет выглядеть лучше, чем полученный при помощи махинаций с фильтром удаления блочности.

    7.5.2. Примеры настроек кодирования

    Описание настроек x264 через программу MeGui - Форум Кинозал

    Настройки кодека x264 в MeGUI

    Вкладки настроек x264:

    Этот метод относительный! При таком способе я заметил, может показать очень высокий битрейт в зависимости от исходника, но задача рипования допустим для выкладывания на сайт это сжать файл для меньшего размера и хорошего качества. что нам и позволяет сделать H.264 даже при не больших битрейтах! Совсем не обязательно ставить большой битрейт думая, что при этом визуальное качество возрастет в разы, совсем нет, оно не будет заметно даже при небольших допустимых, это просто заблуждение, а главное бессмысленное раздутие размера, что я и замечаю от риперов на различных трекерах, но при нормальных настройках кодека! В общем будь то 720p либо 1080p в среднем 0,2-0,25 Бит/(Пиксели*Кадры) дает прекрасное качество, это можно высчитать по калькулятору через MeGUI Tools -> Bitrate Calculator. там это значение обозначено Bits Per Pixel. там также можно подогнать битрейт для того чтобы например фильм вместился на болванку с звуковыми дорожками или определенного размера, размер она показывает примерный, зависит какими настройками кодировать будете, 2 прохода при - Bitrate Variance = 1 даст наиболее приближенный размер к выщитанному! Удачи в риповании видео-файлов!

    Есть настройки зависящие друг от друга, обращаем внимание на это

    На скриншотах визуального примера все настройки сброшены по умолчанию.

    Актуальная версия на содержание статьи MeGUI 2286 от 17 февраля 2013 г (x264 core 129 r2245)

    Выбор оптимального битрейта и настройка кодера х264

    Выбор оптимального битрейта и настройка кодера х264

    Инструкция по выбору битрейта для рипа и настройка кодека x264.

    1. Немного демагогии .

    Очень часто люди делают рипы, выбирая битрейт "на глазок". Причем срабатывает правило "чем больше, тем лучше". Однако это правило не совсем верно. Битрейт видео зависит прежде всего от динамичности видеоряда, а в этом плане все фильмы отличаются друг от друга. Поэтому для одного фильма битрейта в 4,500 kb/s будет более чем достаточно, а для другого и 8000 kb/s мало. Очень легко самому убедиться в том, что битрейт - это не панацея от всех бед. Если не лень, скачайте блю-рей фильма "Мгла". Посмотрите на это качество и гляньте битрейт видео. Очень много, да? Сделайте рип с битрейтом в два раза ниже и сравните его с блюриком. Ухудшилось качество? Нет. А если в 3 раза ниже? Опять не ухудшилось.

    Когда я впервые попал на этот трекер, меня несколько удивило строгое деление качества фильмов именно по битрейту. Но в чужой монастырь со своим уставом не ходят, тем более есть раздел HD*Rip/LQ, где я и размещаю большинство своих рипов именно из-за того, что дальнейшее увеличение битрейта к увеличению качества не приведет. На этом закончу сие лирическое отступление и перейду к делу.

    В первую очередь вам необходимо выяснить версию вашего кодека. Для чего, будет понятно ниже. Обновить кодек всегда можно здесь .

    Независимо от того, какой программой вы пользуетесь для создания рипов (XviD4PSP или MeGui), в первую очередь необходимо сделать распределённую выборку из исходника. В XviD4PSP это делается в меню AviSynth -> Применить тест-скрипт. В MeGui придется добавить в конец .avs скрипта три строки и на выходе получить ряд продолжительностью

    2550 фреймов, составленный из равномерно выдернутых из видеоряда кусков по 50 фреймов.

    Установка последних версий FFmpeg и x264 (на примере Ubuntu)

    Установка последних версий FFmpeg и x264 (на примере Ubuntu)

    Пятница, 29 октября 2010 г.

    Просмотров: 41622

    FFmpeg - это универсальный инструмент для кодирования и декодирования множества видео и аудио форматов, хотя FFmpeg и x264 есть в официальных репозитариях различных дистрибутивов, иногда возникает необходимость собирать эти пакеты самостоятельно. Дело в том, что FFmpeg из Ubuntu не имеет некоторых кодеков, декодеров и не поддерживает некоторые форматы. К тому же, сами вы соберёте более свежую версию, где будут доступны последние наработки программистов.

    Данная инструкция подразумевает, что у вас Ubuntu LTS (10.04) или 10.10.

    Подготовительный этап

    Для начала потребуется удалить некоторые установленные пакеты и установить необходимые зависимости.

    Первым делом удаляем x264, libx264-dev и ffmpeg, если таковые установлены:

    Затем, устанавливаем необходимые для последующей сборки зависимости. Репозитарии universe и multiverse должны быть подключены!

    Установка x264

    Создаём в домашней директории каталог src :

    И выполняем следующее :

    После этих действий будет собран и установлен пакет x264. который можно будет удалить/обновить в будущем.

    Установка FFmpeg

    Получив исходные коды FFmpeg команда "./configure --help" позволит увидеть опции, которые можно включить или выключить. Итак, собираем и устанавливаем пакет:

    Примеры использования FFmpeg и x264 Обновление FFmpeg и x264

    Кодирование видео в H264 (часть 3): zoltan0

    Кодирование видео в H264 (часть 3)

    Here is how it works, and how to use it:

    The first pass (pass=1) collects statistics on the video and writes them to a file. You might want to deactivate some CPU-hungry options, apart from the ones that are on by default.

    In two pass mode, the second pass (pass=2) reads the statistics file and bases ratecontrol decisions on it.

    In three pass mode, the second pass (pass=3, that is not a typo) does both: It first reads the statistics, then overwrites them. You can use all encoding options, except very CPU-hungry options.

    The third pass (pass=3) is the same as the second pass, except that it has the second pass’ statistics to work from. You can use all encoding options, including CPU-hungry ones.

    The first pass may use either average bitrate or constant quantizer. ABR is recommended, since it does not require guessing a quantizer. Subsequent passes are ABR, and must specify bitrate.

    Многопроходное кодирование. Вещь необходимая для создания качественного результата. Как я уже писал, в 1-проходном случае encoder не может оптимально перераспределить биты в потоке для сцен с большим движением и деталями, и для сцен, где движения мало, и деталей меньше. Поэтому он будет пытаться держать битрейт всегда одинаковым, а основной "ручкой" регулирования битрейта является фактор квантизации. Если вдруг encoder наткнётся на сцену с большим и сложным движением, он значительно "отквантизирует" её так что качество будет ниже чем в других сценах. Правда, считается что человек всё равно не заметит если в кадре всё быстро мелькает и дрыгается, но тем не менее артифакты сильного сжатия будут более заметными.

    2-проходного сжатия обычно хватает, так как encoder на первом проходе просчитывает типы кадров и примерный размер кадра. Но это всё немного приблизительно так как реальное кодирование на первом проходе обычно бывает не в самом высоком качестве. Поэтому для перфекционистов есть 3-й проход, где после 2-го уже качественного прохода информация известна вся. После 3-го прохода остальные смысла не имеют.

    Настройки кодека () в Avidemux для получения наилучшего качества

    Настройки кодека h.264 (x.264) в Avidemux для получения наилучшего качества.

    2. B-Frames = 2 или 4.

    3. Reference Frames = 8.

    4. Motion Estimation Method = Umh или Tesa (Tesa - очень медленно кодирует

    5. Subpixel Motion Estimation = максимальный

    9. Mixed References = On

    10. DCT Decimations = On

    11. Chroma Motion Estimation = On

    Замечание по использованию предустановок в Avidemux:

    При использовании программы Avidemux у пользователя есть возможность создавать, загружать и сохранять текущие настройки кодека h.264 в виде файла проекта. Проект – это файл в формате ECMAScript (JavaScript), содержащий не только текущие настройки (пресеты), но и имена обрабатываемых файлов. Для различных версий программы Avidemux структура проекта, состав настроек и месторасположение файла проекта отличаются.

    Для того, чтобы использовать пресеты в Avidemux версии 2.4.3 - файл проекта, содержащий последовательность команд, должен иметь расширение .js и располагаться в поддиректории «custom» дирректории расположения программы Avidemux, (например, для Windows 2000 and XP: \Documents and Settings\$USER$\Local Settings\Application Data\avidemux\custom).

    Необходимо учитывать, что при загрузке (открытии) нового файла-источника в предустановках «слетают» настройки видеофильтров.

    Для создания скрипта, который бы содержал только настройки кодеков без имени исходного файла, см. инструкцию на - http://www.avidemux.org/admWiki/doku.php?id=tutorial:presets.

    В Avidemux, начиная с версии 2.5.4 настройки хранятся в XML файлах в соответствующей поддиректории директории «videoEncoder», (например, для кодеков h.264 в - \Documents and Settings\$USER$\Local Settings\Application Data\avidemux\plugins\videoEncoder\x264). И вызываются из выпадающего списка Configuration окна настроек видеокодека.