Показано с 1 по 5 из 5

Тема: кодек h.264

  1. #1
    Администратор Reputation: 810 [+/-] Аватар для Veselchak


    1 из 1 Этот пост был полезным.

    кодек h.264

    Алгоритмы кодирования видео играют важную роль в современном мире. Они применяются для цифрового представления, сжатия, хранения, передачи и обработки видео-информации в самых различных системах.
    Кодер формата H.264 способен уменьшить размер файла, содержащего цифровое видео, более чем на 80% по сравнению с сигналом, сжатым по алгоритму формата Motion JPEG, при аналогичных показателях визуального качества. В сравнении с наиболее "ходовой" разновидностью формата MPEG-4 -- MPEG-4 Part 2 Simple Profile (SP) -- кодек H.264 обычно выигрывает 40-50 процентов от объема видеофайлов.
    Сектор мегапиксельных камер растет, и до недавнего времени основным сдерживающим его рост фактором считались повышенные требования к объемам хранения данных, генерируемых камерами высокого разрешения. Использование кодека H.264 способно значительно ускорить процесс внедрения мегапиксельных камер.
    Очевидно, что формат H.264 почти окончательно вытеснит MPEG-4 (Part 2) в течение буквально нескольких лет.

    Ложка дегтя
    Есть, однако, и факторы, сдерживающие восторг от новинки ведь, по сути, разработка находится еще в самом начале пути. Да, кодек позволяет снизить нагрузку на сети передачи данных и сэкономить на приобретении средств хранения видеоинформации. Но его использование возможно только в условиях применения высокопроизводительных камер. Новый алгоритм сжатия использует значительно более сложную математику, чем предыдущие стандарты скажем, процедура декодирования примерно вдвое превосходит аналогичную процедуру у MPEG-4 Part 2 SP по объемам вычислений соответственно этому растет и запрос к вычислительной мощности систем. При этом собственно стандартом H.264 стал относительно давно, около пяти лет назад, и в некоторых отраслях исключая нашу с вами уже взят на вооружение. Скажем, он используется в новом поколении потребительских DVD-дисков высокого разрешения (формат Blu-ray).

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

    Существует два основных метода промежуточного предсказания -- основанное на одном ссылочном кадре (макроблоки типа P) и двунаправленное (макроблоки типа В), где используется комбинация двух ссылочных кадров. Чтобы обеспечить доступ к произвольным участкам видеоизображения и повысить степень защищенности от ошибок, стандартом также предусмотрено так называемое инфракодирование, при котором кодированные данные не зависят от характера и содержания каких-либо сторонних изображений, как это происходит в случае применения промежуточного предсказания.
    Стандартом H.264 предусматривается разбиение изображения на макроблоки размером до 16х16 пикселов каждый. Макроблоки объединяются в группы -- одну или несколько -- обычно в порядке сканирования. Таким образом, отдельное изображение может быть закодировано как одна или несколько групп. Использование группирования макроблоков позволяет применять различные методы коррекции ошибок, различные типы кодирования макроблоков, а также такие инструменты, как раздельное кодирование полукадров (на правах групп) при чересстрочной развертке.
    В цветных видеоизображениях кодирование яркостной составляющей происходит отдельно от цветовой; учитывая особенности человеческого зрения, при этом, как правило, используется поддискретизация цветового сигнала относительно яркостного. По большому счету, фундаментальных отличий нового формата от предыдущих стандартов кодирования видеосигнала (включая MPEG-4 Part 2) нет: все они так или иначе основаны на разбиении на блоки и являются гибридными.

    Новые средства
    Помимо улучшений, которым подверглись уже существующие средства кодирования, формат H.264 предусматривает и ряд новых инструментов. Наиболее важными из них являются встроенный адаптивный деблокирующий фильтр, позволяющий существенно снизить блокинг-искажения изображения, запись более чем двух ссылочных кадров для более точного предсказания, деление макроблоков на блоки меньшего размера (вплоть до 4х4 пиксела), предсказание в инфракодировании, а также применение целочисленного преобразования взамен применявшегося в более ранних стандартах дискретного косинусного преобразования (DCT).

    В формат H.264 входит принципиальное решение сетевого интерфейса передачи видеоданных (network abstraction layer, NAL), который, будучи установлен поверх программного механизма кодирования видеосигнала (video coding layer, VCL), берет на себя функцию эффективного представления цифрового видео в формате, обеспечивающем легкую интеграцию с целым набором различных протоколов и механизмов передачи данных -- это весьма привлекательно для сетей, работающих на основе Интернет-протокола (IP).

    Что в итоге?

    Главный результат всех усовершенствований технологии кодирования, воплощенных в стандарте H.264, состоит в том, что новый формат действительно превосходит по своим характеристикам все предыдущие алгоритмы сжатия цифрового видеосигнала -- и потому на сегодняшний день может считаться высшим достижением в области кодирования цифрового видео.
    Итак, стоит ли Н.264 всей медиа-шумихи, развернутой вокруг него? Стандарты видеокомпрессии с приходом нового формата стали стремительно меняться -- и сегодня они уже способны сохранить либо даже снизить нагрузку на пропускную способность сетей передачи данных при переходе на видео высокого разрешения. И это является весьма ценным.
    Однако же, будем помнить, что все прелести новой технологии кодирования и хлынувших на рынок все более мощных мегапиксельных камер могут быть реализованы лишь при использовании крепкой управляющей платформы, на базе которой формируются решения видеофиксации.

    По материалам
    Security News

  2. #2
    Администратор Reputation: 810 [+/-] Аватар для Veselchak


    1 из 1 Этот пост был полезным.

    Воспроизведение Hi10P

    Зачем нам вообще нужен Hi10P?

    По сути, Hi10P (или high10) - это еще один профиль кодирование видео, наряду с уже привычными baseline, main и high. Разница лишь в том, что он использует 10 бит для передачи цвета, что помогает избежать сегментации изображения (ступенчатые градиенты, бандинг и тд.).

    Что же мы получаем при использовании Hi10P?



    • Увеличение степени сжатия, вплоть до 40% (зависит от исходного материала).
    • Меньший уровень бандинга, лучшие темные кадры и тд.
    • Более точная передача исходного изображения (с которого делался рип).


    Но, на данный момент, у Hi10P имеются и серьезные недостатки:



    • Отсутствие поддержки аппаратных декодеров, таких как DXVA и CUDA(в том числе и использующих его, к примеру CoreAVC), так как они разрабатывались только для 8-и битного видео.
    • Невозможность воспроизведения на чем либо, кроме ПК. Вы не сможете запустить 10-и битное видео на PS3, XBox или на "железном" плеере. В том числе и на портативных устройствах.
    • Большее время кодирование и декодирования, из-за увеличения потребления ресурсов. Воспроизведение 10-и битного видео будет медленнее, чем аналогичного 8-и битного.
    • Проблемы с отображением субтитров некоторыми фильтрами.
    • Нет х64 (64-х битных) декодеров (на момент написания статьи).


    Как же его смотреть?

    Все зависит от плеера, который вы используете. Далее будет описан процесс установки и настройки поддержки Hi10P в разных, популярных плеерах: UMPlayer, VLC, PotPlayer, MPC-HC, и для Linux.
    Прежде всего: постарайтесь удалить все установленные плееры и кодеки, а затем уже следовать инструкциям приведенным ниже.
    И да, вам не нужен специальный монитор (10-и битный), и на обычном видно улучшение качества, по сравнению с 8-ю битами. Также, мы получаем видео с большим качеством и меньшим размером, нежели 8-и битное.

    UMPlayer

    UMPlayer (или SMPlayer) - который является графическим интерфейсом для консольного мультимедийного плеера MPlayer (и его форка - MPlayer2).
    Заметьте, что UMPlayer (далее UMP) не отображает настоящие 10 бит, а переводит их в YV12. Тем не менее, большинству, это не важно.
    Начнем же:

    1. Скачиваем и устанавливаем UMPlayer.
    2. Пробуем воспроизвести 10-и битное видео. Если все удачно, то выполняем следующие пункты, если нет, то ставим mplayer2:
      1. Скачиваем mplayer2.
      2. Распаковываем архив и переносим mplayer2-20111005.exe(20111005 - дата сборки, 05.10.2011) в папку с UMP. У меня это: C:\Program Files\UMPlayer\mplayer
      3. Теперь можете переименовать перенесенный mplayer2-20111005.exe в mplayer.exe. Также можно изменить путь к mplayer в настройках UMP: перейдите в Настройки -> Основные -> Путь к mplayer и задайте путь к mplayer2-20111005.exe

    3. Если у видео не хватает плавности, то в Настройка -> Быстродействие отключите "выпадение кадров" и выберите "количество потоков декодирования" равным количеству ядер вашего процессора.

    VLC
    Последняя (на момент написания статьи) версия 1.1.12 не поддерживает воспроизведение Hi10P. Но вы можете скачатьтестовую версию, в которой уже добавлена поддержка Hi10P, но с переводом в 8бит.

    PotPlayer

    Последний PotPlayer (1.5.29601) отображает 10бит, но с переводом в 8бит.

    Media Player Classic - Home Cinema


    1. Скачиваем и устанавливаем 32-х битный MPC-HC (64-х битный не поддерживается madVR'ом).
    2. Скачиваем и устанавливаем Haali's Media Splitter.
    3. Скачиваем madVR, распаковываем в любую папку (желательно в папку Program Files).
    4. Зайдите в систему от имени Администратора и запустите файл install.bat (не путайте с "Запустить от имени администратора").
    5. Открываем MPC-HC и переходим в настройки.
    6. Выбираем вкладку "Встроенные фильтры" и выставляем галочки как на скриншоте:
    7. Затем переходим на вкладку "Вывод", и выбираем madVR:
    8. Теперь нужно настроить madVR. Для этого откроем какое нибудь видео в MPC-HC и в контекстном меню иконки madVR в трее, выберем "Edit madVR Settings":
    9. В настройках переходим на вкладку processing -> decoding и отмечаем пункты как на скриншоте:
    10. Теперь перезапускаем MPC-HC и открываем в нем какое нибудь 10-и битное видео. Если видео появилось - уже хорошо. Теперь нажимаем Ctrl+J, для вывода дополнительной информации. И ищем строку вида: libav, h264, 10 bit, 4:2:0. У меня она была:
    11. Все готово. Но если вы не видите данной строки, а видите что-то на подобии: h264, 8 bit, 4:2:0 -> YV12, 8 bit, 4:2:0 - значит вы где-то ошиблись. Попробуйте выполнить все пункты заново.

    Воспроизведение на Linux

    ArchLinux
    Достаточно установить mplayer из репозитория:
    Код:
    pacman -S mplayer
    Он прекрасно воспроизводит 10бит, но конечно же с трансформацией как и на Windows:
    Код:
    VO: [xv] 1920x1080 => 1920x1080 Planar YV12
    В то время, как mplayer2(2.0-14) из репозитория вообще не поддерживает 10 бит:
    Код:
    Unsupported PixelFormat 72
    Could not find matching colorspace - retrying with -vf scale...
    По этому, можно просто установить mplayer2-git из AUR, который уже поддерживает 10 бит:
    Код:
    yaourt -S mplayer2-git

    Ubuntu

    В Ubuntu 11.04, все в точности наоборот, стандартный mplayer(1.0rc4-4.5.2) не воспроизводит 10 бит, по этому необходимо установить mplayer2:
    Код:
    sudo apt-add-repository ppa:ripps818/coreavc
    sudo apt-get update
    sudo apt-get install mplayer
    либо mplayer-svn:
    Код:
    sudo apt-add-repository ppa:motumedia/mplayer-daily
    sudo apt-get update
    sudo apt-get install mplayer
    Разница лишь в способе отображения:
    Код:
    mplayer (SVN-r34182-4.5.2) - VO: [x11] 1920x1080 => 1920x1080 BGRA
    mplayer2                   - VO: [x11] 1920x1080 => 1920x1080 Planar YV12
    Сравнения 10 бит и 8 бит

    Сравнения на screenshotcomparison:
    Stains;Gate
    Clannad After Story
    Denpa Onna

    Сравнение на Elephants Dream.
    Как видно из сравнений, 10-и битное видео в большинстве случаев дает ощутимый прирост качества при том же битрейте.
    Тестовый компьютер

    Ноутбук Asus F3ka с AMD Turion 2x1.9Ghz.
    Быстрее всего себя показал mplayer. На нем 1080р практически не подтормаживает (но и правильного 10 бит нет).
    На VLC совершенно не возможно смотреть.
    MPC-HC ощутимо подвисает, но является самым предпочтительным вариантом.

    Источник http://www.videorip.info/x264

  3. #3
    Администратор Reputation: 810 [+/-] Аватар для Veselchak


    1 из 1 Этот пост был полезным.

    Аналоги ключей кодирования x264 для ffmpeg

    FFmpeg - это свободный, кроссплатформенный, мультиформатный энкодер аудио/видео. Он позволяет работать с большинством популярных форматов и кодеков.
    В данной статье будут рассмотрены аналоги ключей кодирования x264 в ffmpeg. Суть в том, что FFmpeg содержит большинство ключей, которые имеет x264, но большинство из них имеют другие названия или параметры, а некоторых и вовсе нет.

    x264 ffmpeg Примечание
    --keyint -g
    --min-keyint -keyint_min
    --scenecut -sc_threshold
    --bframes -bf
    --b-adapt -b_strategy
    --b-bias -bframebias
    --b-pyramid -flags2 +bpyramid Значение отключено, аналогично none.
    Значение включено, аналогично normal.
    --no-cabac -coder <0,1> 0 - отключено, 1 - включено
    --ref -refs
    --no-deblock -flags -loop
    --deblock -deblockalpha
    -deblockbeta
    --tff -flags +ildct
    --qp -cqp
    --bitrate -b
    --crf -crf
    --vbv-maxrate -maxrate
    --vbv-bufsize -bufsize
    --vbv-init -rc_init_occupancy
    --qpmin -qmin
    --qpmax -qmax
    --qpstep -qdiff
    --ratetol -bt
    --ipratio -i_qfactor
    --pbratio -b_qfactor
    --chroma-qp-offset -chromaoffset
    --aq-strength отсутствует
    --pass -pass
    --stats отсутствует
    --qcomp -qcomp
    --cplxblur -complexityblur
    --qblur -qblur
    --zones отсутствует
    --qpfile отсутствует
    --partitions -partitions p8x8 (x264) = +partp8x8 (FFmpeg)
    p4x4 (x264) = +partp4x4 (FFmpeg)
    b8x8 (x264) = +partb8x8 (FFmpeg)
    i8x8 (x264) = +parti8x8 (FFmpeg)
    i4x4 (x264) = +parti4x4 (FFmpeg)
    --direct -directpred
    --no-weightb -flags2 +wpred
    --me -me_method dia (x264) = epzs (FFmpeg)
    hex (x264) = hex (FFmpeg)
    umh (x264) = umh (FFmpeg)
    esa (x264) = full (FFmpeg)
    --merange -me_range
    --mvrange отсутствует
    --subme <1-10> -subq <1-9>
    --psy-rd : отсутствует
    --no-mixed-refs -flags2 +mixed_refs
    --no-chroma-me отсутствует
    --8x8dct -flags2 +dct8x8
    --trellis <0,1,2> -trellis <0,1,2>
    --no-fast-pskip -flags2 -fastpskip
    --no-dct-decimate отсутствует
    --nr отсутствует
    --deadzone-inter отсутствует
    --deadzone-intra отсутствует
    --cqm отсутствует
    --cqpfile отсутствует
    * Значения по умолчанию теже что и у x264.
    * Для опций идущих после -flag/-flag2, "-" (минус) означает что данная оцпия отключена, а "+" (плюс) включена.
    Пример использования:
    Код:
    ffmpeg.exe -y -i "in.mkv" -vcodec libx264 -crf 22 -partitions +parti4x4+parti8x8+partp4x4+partp8x8+partb8x8 -me_method umh -sc_threshold 40 -b_strategy 2 -bframebias 0 -subq 9 -trellis 2 -refs 8 -bf 6 -coder 1 -g 250 -me_range 24 -qmin 10 -qmax 69 -flags -loop -flags2 +bpyramid+wpred+mixed_refs+dct8x8 -deblockalpha 1 -deblockbeta 1 -threads 2 -acodec flac -aq 100 "out.avi"
    
    Данная статья представляет исправленный перевод данной статьи, с обновлениями и дополнениями.

    Источник
    http://www.videorip.info/x264

  4. #4
    Администратор Reputation: 810 [+/-] Аватар для Veselchak


    1 из 1 Этот пост был полезным.

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

    Данная статья представляет собой описание всех настроек x264 в MeGUI. С рекомендациями и примечаниями.
    Новичкам хватит и первой вкладки, с основными настройками, а более продвинутым пользователям понадобится описание всех остальных параметров кодирования.
    Дополнительные вкладки доступны только после включения опции: Advanced Settings.
    Статья актуальна для MeGUI версии 2028.



    Если нашли ошибку или неточность в описании - сообщите администрации. Контакты внизу страницы.

    Encoding Mode - Режим кодирования:

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

    Доступные режимы:
    ABR - кодирование с переменным битрейтом
    Const. Quantizer - кодирование с постоянным квантизером (QP)
    2pass - 1st pass - кодирование в два прохода, настройка первого прохода
    2pass - 2nd pass - кодирование в два прохода, настройка второго прохода
    Automated 2pass - кодирование в два прохода, автоматический режим
    3pass - 1st pass - кодирование в три прохода, настройка первого прохода
    3pass - 2nd pass - кодирование в три прохода, настройка второго прохода
    3pass - 3rd pass - кодирование в три прохода, настройка третьего прохода
    Automated 3pass - кодирование в три прохода, автоматический режим
    Const. Quality - кодированеи с постоянным качеством (CRF)

    Preset - Пресет:

    Система, добавленная с ревизии r1177, спроектирована на уменьшение работы, необходимой для формирования сценария, который дает ту степень качества, которая Вам нужна.
    Presets (пресеты, изменения обеспечиваются передвижением ползунка)
    Варианты изменений опций позволяют добиться соответствующей эффективности сжатия и качества. Если Вы определите заданный пресет, то изменения, которые он делает, будут применены прежде, чем применены все другие параметры.
    Ultrafast (ультра-быстрый):
    no-8x8dct, aq-mode 0, b-adapt 0, bframes 0, no-cabac, no-deblock, no-mbtree, me dia, no-mixed-refs, partitions none, rc-lookahead 0, ref 1, scenecut 0, subme 0, trellis 0, no-weightb, weightp 0

    Superfast (супер-быстрый):
    no-mbtree, me dia, no-mixed-refs, partitions i8x8,i4x4, rc-lookahead 0, ref 1 subme 1, trellis 0, weightp 1

    Veryfast (очень быстрый):
    no-mixed-refs, rc-lookahead 10, ref 1, subme 2, trellis 0, weightp 1

    Faster (еще быстрее):
    no-mixed-refs, rc-lookahead 20, ref 2, subme 4, weightp 1

    Fast (быстрый):
    rc-lookahead 30, ref 2, subme 6, weightp 1

    Medium (средний):
    нет изменений по сравнению с теми, что выставлены первоначально.

    Slow (медленный):
    b-adapt 2, direct auto, me umh, rc-lookahead 50, ref 5, subme 8

    Slower (медленнее):
    b-adapt 2, direct auto, me umh, partitions all, rc-lookahead 60, ref 8, subme 9, trellis 2

    Veryslow (очень медленный):
    b-adapt 2, bframes 8, direct auto, me umh, merange 24, partitions all, ref 16, subme 10, trellis 2, rc-lookahead 60

    Placebo (плацебо):
    bframes 16, b-adapt 2, direct auto, slow-firstpass, no-fast-pskip, me tesa, merange 24, partitions all, rc-lookahead 60, ref 16, subme 10, trellis 2

    В консоли: --preset
    По умолчанию: Medium
    Tune - Тонкие настройки (тюнинг):

    Опции тюнинга далее оптимизируют настройки вашего входного источника видео. Если Вы определите настройку, то изменения будут применены после того, что было задано пресетами, но перед всеми другими параметрами
    film:
    оптимизация установок для кодирования фильмов:
    deblock -1:-1, psy-rd 1:0.15

    animation:
    оптимизация установок для кодирования аниме:
    ref (удваивает базовое значение reference, если оно больше чем 1Гб в противном случае выставляет 1), deblock 1:1, psy-rd0.4:0, aq-strength 0.6, bframes (добавляет 2 bframes к значению по умолчанию)

    grain:
    Оптимизация для зернистого изображения с повышенной детализацией:
    deblock -2:-2, psy-rd 1:0.25, no-dct-decimate, ipratio 1.1, pbratio 1.1, aq-strength 0.5, deadzone-intra 6, deadzone-inter 6, qcomp 0.8

    psnr:
    оптимизация для PSNR:
    aq-mode 0, no-psy

    ssim:
    оптимизация для SSIM:
    aq-mode 2, no-psy

    fastdecode:
    оптимизация для быстрого декодирования содержания:
    no-deblock, no-cabac, no-weightb, weightp 0

    zerolatency:
    оптимизация для потокового видео, такого как IPTV:
    bframes 0, force-cfr, no-mbtree, sync-lookahead 0, sliced-threads, rc-lookahead 0

    Рекомендация: Согласно вашему исходнику. Не определяйте, если ваш исходник не соответствует ни одной из опций.
    В консоли: --tune
    По умолчанию: не установлен
    AVC Profiles - Профили:

    Устанавливает порог профиля на выходной поток. Эта опция отменяет все другие установки, так что, если вы используете эту опцию, то вам будет гарантирован совместимый поток. Если вы установите эту опцию, то вы не сможете применить кодирование в режиме без потерь lossless encoding (--qp 0 или --crf 0).
    Доступные варианты опций профиля имеют:
    Baseline - Устанавливает no-8x8dct, no-cabac, cqm flat, bframes 0, weightp 0. Можно получить на выходе файл с ошибками, если используется интреляция.
    Main - Устанавливает no-8x8dct и cqm flat.
    High - Нет ограничений.
    High10 - Тоже что и High, но с поддержкой глубины изображения в 10bit. (экспериментальная опция)

    В консоли: --profile
    Рекомендации: High, если ваше устройство воспроизведения может поддерживать не только профили Main или Baseline.
    AVC Level - Уровни:

    Устанавливаем уровень выходного потока (определено стандартом H.264).
    Уровень влияет на поддержку оборудованием. В спецефикации к вашему устройству должен быть указан максимальный поддерживаемый уровень.
    Target Playback Device - Конечное устройство воспроизвидения:

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


    Frame-Type

    Frame-Type

    H.264 Features:

    Deblocking

    Использование фильтра подавления блоков с параметрами - alpha (сила подавления блоков):beta (точность определения блоков). При кодировании изображение разбивается на блоки размерами 8х8 пикселей и каждый такой блок кодируется отдельно. При недостаточном битрейте, эти блоки становятся заметными. Включение данной опции поможет решить проблему.
    Рекомендации: Параметр "alpha" рекомендуется выбрать от -3 до 3. Большее значение увеличивает силу подавления блоков, но картинка становится немного размытой (используйте при низких битрейтах или при кодировании мультипликации). Меньшее значение уменьшает силу, зато картинка остается достаточно чёткой (используйте при высоких битрейтах). Если не знаете, что выбрать, то оставьте 0 - подходит для большинства случаев.
    Параметр "beta" рекомендуется выбирать от -2 до 2. При больших значениях, кодек может распознать некоторые детали за блок и применить к ним фильтр подавления блоков. При меньших значениях, деталей сохранится больше, но некоторые блоки могут быть приняты за деталь (используйте меньшие значения при кодировании мультипликации - в ней четкие контуры, поэтому кодек не ошибется). Желательно чтобы этот параметр отличался не больше, чем на единицу от предыдущего. Если не знаете, что выбрать, то оставьте 0 - подходит для большинства случаев.
    Сила деблокинга вычисляется для каждого макроблока, исходя из квантизера для него и близлежащих макроблоков. Альфа определяет: является ли приграничный квадрат блочным или же на самом деле это деталь. Это похоже на порог. Бета так же похожа на порог, но используется для того, чтобы убедиться в однородности картинки с обеих приграничных сторон и, тем самым, отделить детали от блочности. Когда определена блочность, альфа решает, какую силу использовать (максимально допустимое изменение пикселя). Бета немного изменяет силу, если блок однородный. Сила деблокинга: Порог деблокинга. Порог деблокинга устанавливает жёсткость отбора блочности фильтром. Сила деблокинга регулирует, как сильно определённые блоки будут смягчены. Значения по умолчанию сочетают аккуратность удаления блочности и сохранение деталей. Значения должны лежать в диапазоне от -3 до 3 (чем ниже значения, тем меньше устраняется блочность. Отрицательные значения не означают, что блочность оставляется).
    Примечание: Слишком высокие значения дадут потерю многих деталей и текстур или смазывание. Установка слишком низких значений оставит резкие края и "москитный шум" (mosquito noise). Должна быть положительная взаимосвязь между двумя коэффициентами деблокинга (желательно, чтобы обе цифры были отрицательными или положительными). Если Вы увеличиваете силу, то должны увеличить и порог
    В MediaInfo: deblock=1::

    Deblocking Strength

    Сила подавления блоков, параметр альфа. Описание выше.
    Deblocking Threshold

    Точность определения блоков, параметр бета. Описание выше.
    CABAC

    CABAC (Context-Adaptive Binary Arithmetic Coding / Контекстно-Адаптивное Двоичное Арифметическое Кодирование) - это умная техника сжатия без потерь. Если эту опцию отключить - энкодер начнет использовать CAVLC (Контекстно-Адаптивное Неравномерное Кодирование).
    Рекомендации: Для карманных устройств(КПК, КМК и смартфонов) лучше использовать CAVLC. Так как их мощности не хватит что бы справится с CABAC.
    Примечание: CABAC дает сжатие, приблизительно, на 10-20% больше, по сравнению с CAVLC.
    CABAC использует больше процессорного времени для кодирования и декодирования.
    В MediaInfo: cabac=0..1

    GOP Size:

    Maximum GOP Size

    Максимальный интервал между ключевыми/IDR кадрами. Этот параметр контролирует количество кадров между ключевыми, и если по достижению придела ключевой кадр не наступил - принудительно его ставит. Стандартный размер GOP'а динамически вычисляется во время кодирования для максимального сжатия.
    IDR(ключевые) кадры - это так называемые кадры-разделители. Кадры, находящиеся в промежутке между двумя ключевыми кадрами не могут ссылаться на кадры, вне этого промежутка. Также, сами ключевые кадры являются I-кадрами, так что они не могу использоваться как референсные. По этому они могут использоваться в качестве контрольных точек в видеопотоке.

    Примечание: Влияет на перемотку видео в плеере. Если значения очень большие, то при перемотке(прокрутке), не по ключевым кадрам, видео в плеере будет немного притормаживать. Так как декодеру придется отрендерить все кадры начиная с ближайшего ключевого и до выбранного пользователем. Перемотка не по ключевым кадрам поддерживается на уровне плеера, кодека.
    Рекомендации
    : Значение по умолчанию применимо в большинстве случаев. Если Вы хотите использовать собственное значение, используйте следующую формулу: fps*10 (значение должно быть целым числом, кратным 10-и). Если Вы кодируете для Blu-ray или потокового видео, то возможно, Вам придется использовать значения, равные частоте кадров итогового видео. Большие значения полезны только для статичного видео.
    То есть для частоты кадров в 25 нужно выбирать 250, для 23,976 - 240 и для 29,970 - 300.
    В MediaInfo: keyint=

    Minimum GOP Size

    Минимальное расстояние между ключевыми (I) кадрами. Минимальный размер группы.
    Устанавливает минимальный размер группы картинок - GOP'а. Макроблоки в картинке одного GOP'а не могут быть связанными (референсами) с макроблоками картинки из другого GOP'а, с помощью начального кадра этой группы (IDR кадров) выполняется поиск по фильму. Размер GOP'а динамически вычисляется во время кодирования для максимального сжатия, хотя маленький GOP может обеспечить лучшую передачу динамичных сцен, но это приведёт к излишней трате битрейта.
    Максимально значение не должно превышать: keyint/2+1.

    Open GOP

    Open-GOP(Group Of Pictures) - техника увеличивающая эффективность кодирования. По сути, open-gop запрещает трансформацию B-кадра в P-кадр, если текущий кадр должен быть ключевым, исходя из значения --keyint, но новая сцена еще не началась. Это позволяет уменьшить излишне большое количество ключевых кадров и дает меньший битрейт, и соответственно более высокую степень сжатия.
    Рекомендации: Полезно, если Вы используете низкие значения --keyint.
    Примечание
    : Некоторые декодеры не поддерживают open-gop, по этому эта опция не включена по умолчанию.
    В MediaInfo: open_gop=

    Slicing:

    Nb of slices by Frame

    Указываем количество частей (квадратов), на которые будет разбит кадр.
    Рекомендации: Если Вы кодируете Blu-ray - используйте значение 4. В противном случае вообще не используйте эту опцию. Разве что Вы точно знаете что она вам нужна.
    Max size (in bytes)

    Задаем максимальное размер slice в байтах.
    Примечание: На данные момент конфликтует с --tff, --bff.
    Max size (in mbs)

    Задаем максимальный размер slice в макроблоках.
    Примечание: На данные момент конфликтует с --tff, --bff.
    B-Frames:

    Weighted Prediction for B-Frames

    Позволяет "взвешивать" ссылки на B-кадры. Управляя, таким образом, тем, на сколько каждая ссылка будет влиять на предполагаемое изображение. Эта опция отключает данную возможность.
    В MediaInfo: weightb=
    Number of B-frames

    Количество последовательных B-кадров между I- и P- кадрами. B-кадры – это кадры, в которых закодированы изменения не только от предыдущих кадров, но и от последующих. Имеют еще большую степень сжатия, чем P-кадры, но также и наихудшее качество. B-кадры подобны P-кадрам, кроме того, они могут использовать предсказание движения от будущих кадров также. Это может привести к значительному улучшению степени сжатия.
    Рекомендации: Оптимальные значения: 2..6.
    Если Вы используете --b-adapt 2, то можно смело задавать --bframes 16. Это самый простой способ, так как выбор оптимального значения падает на енкодер.
    Оптимальное значение для конкретного видео можно получить путем чтения статистики первого прохода.
    Примечание: При высоких значениях, больших чем необходимо, кодирование может быть значительно замедленно, без выйграша в качестве. Также большое количество В-кадров затрудняет декодирование.
    В MediaInfo: bframes=

    B-frames bias

    Контролирует количество B-кадров, которые будут использованы вместо P-кадров.
    Рекомендации: Используйте, только если считаете что сможете добиться лучшего контроля битрейта, чем сам x264.
    Примечание: Значения выше 0 увеличивают вероятность использования В-кадров, а значения ниже 0 - уменьшают. Значения равные 100/-100 гарантируют/не гарантируют что каждый Р-кадр будет преобразован. Для этого используйте --b-adapt 0.
    В MediaInfo: b_bias=

    Adaptive B-Frames

    Позволяет x264 адаптивно решать, где будут использоваться B-кадры, уменьшая количество B-кадров там, где это не нужно.
    Рекомендации: При высоком значении --bframes лучше задавать значение 2.
    Настройки
    :
    0 - полностью отключить
    1 - "быстрый" алгоритм. Этот метод позволяет использовать --bframes 16
    2 - оптимальный алгоритм, медленнее предыдущего
    Примечание: В многопроходном кодировании эта опция необходима только для первого прохода, где типы кадров определены.
    В MediaInfo: b_adapt=

    B-Pyramid

    Позволяет B-кадрам ссылаться на другие В-кадры, тем самым увеличивая эффективность использования 2-х или более B-кадров.
    Типы:
    none - запрещает использовать В-кадры как референсные.
    strict - разрешают по 1-му референсному В-кадру на каждый minigop (соблюдает ограничения стандарта Blu-ray).
    normal - разрешает множественное использование референсных В-каров на каждый minigop.
    Примечание: Без этого параметра, В-кадры могут ссылаться только на I- или P-кадры. Хотя I/P-кадры и более ценны, из-за их более высокого качества, B-кадры также могут быть полезными.
    Необходимо значение --bframes выше 2-х. Немного замедляет кодирование. При кодировании для Blu-ray не используйте normal.
    В MediaInfo: b_pyramid=

    Other:

    Number of Reference Frames

    Параметр задает количество используемых рефернсных кадров. Определяет, сколько предыдущих кадров может быть связано (заимствование макроблоков) с P- или B-кадрами.
    Рекомендации: Приблизительно 4-6. Большие значения могут быть полезны для анимации, аниме, скринкастов и другого "статичного" видео.
    Примечание: При 5-ти и более референсных кадрах, качество, обычно, повышается незначительно.
    Кроме того, 4 - максимальное значение для 1080p, а 9 - максимальное для 720p, придерживаясь спецификации Level 4.1. Это самый высокий уровень, поддерживаемый в большинстве бытовой электроники, которая поддерживают воспроизведение H.264, включая также Xbox 360 и Playstation 3.
    Чем больше референсных кадров, тем медленнее кодирование.
    В MediaInfo: ref=

    Number of Extra I-Frames

    Этот параметр определяет на сколько часто будут использоваться дополнительные I-кадры. x264 высчитывает метрику каждого кадра, что бы определить насколько он отличается от предыдущего. Если полученное значение меньше чем установлено для scenecut, то энкодер помещает в этом месте I-кадр, но только если последний ключевой кадр был не раньше чем --min-keyint. Если значение выше, то вставляет ключевой/IDR кадр. Полезность определения смены сцен заключается в оптимальной расстановке I-кадров в местах резкой смены сцен. Это повышает качество, но слишком частая смена приведёт к напрасной трате битрейта.
    Примечание: Значение "0" соответствует отключению опции Adaptive I-Frame Decision.
    В MediaInfo: scenecut=

    P-frame Weighted Prediration

    Взвешенное предсказание яркости для P-кадров, которое улучшает затухания и градиенты цвета (небо и т. п.).
    Варианты:
    Disabled - отключено
    Blind - оценка затуханий
    Smart - оценка затуханий и поиск референсных дубликатов
    В MediaInfo: weightp=

    Interlaced Mode

    Включаем череcстрочное кодирование.
    Варианты:
    none - отключено
    TFF - включено, первое поле - верхнее
    BFF - включено, перове поле - нижнее

    Рекомендации: Чересстрочное кодирование необходимо только для чересстрочных дисплеев.
    Примечание: x264 использует для череcстрочного кодирования MBAFF, и это намного хуже прогрессивного кодирования.
    В MediaInfo: interlaced=1

    Pulldown

    Выбираем пресет софт-телесина для входного видео. Телесин - это способ преобразования видео в телевизионный формат. То есть частота исходного видео подгоняется под частоту телевещания (50Гц - PAL, 60Гц - NTSC), при этом возможно незначительное ускорение видео. Данный параметр задает тип исходного преобразования, для выполнения обратного.
    Пресеты: none, 22, 32, 64, double, triple, euro (требует crf входное видео).
    Примечание: использование любого пресета, кроме none, подразумевает использование --pic-struct.
    В MediaInfo: Неизвестно

    Adaptive I-Frame Decision

    Полное отключение адаптивных I-кадров

    [свернуть]

    Rate Control

    Rate Control




    Quantizers:

    Min/Max/Delta

    Определяет минимальный квантизатор, который x264 будет когда-либо использовать. Чем ниже квантизатор, тем ближе будет выходное видео к входному по качеству.
    Рекомендации: Значение по умолчанию оптимально в большинстве случаев. Но если вы считаете что энкодер тратит часть битрейта в пустую, то можете поднять значение где то до 16-и. Это практически не повлияет на визуальное качество, зато уменьшит битрейт, а в следствии и размер.
    Примечание: Что бы узнать насколько эффективно используется данный квантизер, посмотрите лог кодирования.
    В MediaInfo: qpmin=

    Устанавливаем максимальное значение квантизера. Это не даёт кодеру слишком сильно сжимать кадры, тем самым ухудшая качество.
    Рекомендации: Устанавливать значения ниже стандартного нужно только если Вы считаете что некоторые кадры сжаты слишком сильно.
    В MediaInfo: qpmax=

    Устанавливает, как сильно может изменяться квантизер между последовательными кадрами, придерживаясь одного уровня качества.
    То есть, при --qpstep=4 если кадр будет закодирован с QP=20, то квантизатор следующего кадра не будет, ниже 16 или больше 24.

    Рекомендации: Можно повысить для очень динамичного видео.
    В MediaInfo: qpstep=

    Quantizers Ratio (I:P)

    Устанавливает уровень среднего прироста качества I-кадров, по сравнению с Р-кадрами.
    Примечание: Чем выше значение, тем выше качество I-кадров.
    В MediaInfo: ip_ratio=

    Quantizers Ratio (P:B)

    Устанавливает средний уровень снижения качества для B-кадров, по сравнению с P-кадрами.
    Примечание: Чем выше значение, тем ниже качество В-кадров. Не используется с mbtree(включен по умолчанию), который сам высчитывает оптимальное значение.
    В MediaInfo: pb_ratio=

    Deadzones (Inter)

    Установит inter (внешний) размер luma-квантизеру deadzone.
    В MediaInfo: deadzone=
    Deadzones (Intra)

    Установит intra (внутренний) размер luma-квантизеру deadzone.
    В MediaInfo: deadzone=
    Chroma QP Offset

    Устанавливает уровень снижения качества между яркостной и цветовой составляющими. Человеческий глаз более чувствителен к изменению яркости, чем цвета. Понизив цветовую детализацию можно повысить уровень сжимаемости. Обычно, x264 кодирует все три цветовых составляющих (luma-яркость, U -1-й цветоразностный сигнал, V -2-й цветоразностный сигнал) с тем же самым квантизатором. Это значение будет добавлено к квантизаторам для U и V составляющих. Это позволяет Вам смещать x264 в пользу яркости (luma), устанавливая положительные значения, сигналы цветности будут иметь более высокие квантизаторы, или в пользу цвета (сигнал цветности), устанавливая отрицательные значения. Помните, что x264 кодирует видео, как YV12, что означает, что сигнал цветности поднимает только половину цветового пространства, а luma делает так или иначе.
    Рекомендации: Лучше не изменять значение по умолчанию, так как его может изменять сам x264. К примеру psy-RD снижает его на 2-а.
    Примечание
    : x264 кодирует luma и chroma с одинаковым квантизиром только до Q=29.
    В MediaInfo: chroma_qp_offset=

    Credits Quantizer

    Нет описания.
    Adaptive Quantizers:

    Mode

    Без AQ, x264, как правило, не производит перераспределение битрейта для снижения или повышения детализации сцен. AQ лучше перераспределяет битрейт между всеми макроблоками в видео.
    Режимы:
    Disabled - Не использовать AQ вообще.
    Variance AQ (complexity mask) - Разрешает AQ для перераспределения битов в каждом кадре.
    Auto-Variance AQ (still experimental) - Авто-инвариантность AQ (экспериментальная) позволяет перераспределять биты по всему видео.
    В MediaInfo: aq=

    Strenght

    Устанавливает силу AQ, для подавления блочности и размытия на "плоских" и текстурированных областях.
    Рекомендации: Применяйте в диапазоне от 0.7 (большая детализация изображения, но и больше артефактов) до 1.5 (меньшая детализация, но значительное снижение вероятности появления артефактов). Всё зависти от качества источника изображения.
    Примечание: Отрицательные значения не допускаются. Значения больше/меньше чем на 100% от стандартного скорее всего приведут к полному искажению идео.
    В MediaInfo: aq=

    Quantizers Matrices

    Позволяет использовать заранее заданные матрицы квантования. В последних версиях кодека х264 категорически запрещено применять матрицы квантования, поскольку данная функция обеспечивается функцией адаптивного квантования --aq-mode.
    Варианты:
    Flat (none)
    JVT
    Собственная матрица

    Rate Control:

    VBV Buffer Size

    Устанавливаем размер VBV(Video Buffer Verifier) буфера в килобайтах.
    Рекомендации: Значение по умолчанию оптимально. Другие значения могут привести к снижению качества.
    В MediaInfo: Не отображается

    VBV Maximum Bitrate

    Дополнительный параметр управления битрейтом. Устанавливает максимальный битрейт, разрешённый в видео-буфере.
    Рекомендации: Значение по умолчанию оптимально. Другие значения могут привести к снижению качества.
    В MediaInfo: Не отображается

    VBV Initial Buffer

    Задаем размер VBV буфера, каким он должен быть перед началом воспроизведения.
    В MediaInfo: Не отображается
    Bitrate Variance

    Регулирует, как сильно будет колебаться битрейт относительно установленного среднего битрейта.
    Рекомендации: Низкие значения ограничивают изменение битрейта, создавая выходной файл, хорошо попадающий в итоговый размер, исходя из установленного битрейта, но ухудшают способность кодека адаптироваться к изменению сложных сцен. Высокие значения увеличивают изменения (скачки) битрейта, которые ухудшают возможность потоковой передачи и делают размер непредсказуемым, но улучшают способность кодека адаптироваться к изменению сложных сцен. Установка значения в 0% даст в результате работу в режиме постоянного битрейта. Установив 100%, Вы получите изменения битрейта в зависимости от сложности кодируемой сцены. (Установив 100% Вы получите сжатие в режиме постоянного квантизера - CQ).
    Примечание
    : Задается в процентах. То есть 1.0 соответствует 1.0%.
    В MediaInfo: Не отображается

    Quantizer Compression

    Регулирует, насколько сильно может колебаться качество в пределах установленного среднего битрейта. Низкие значения уменьшают область колебания битрейта, производя файлы предсказуемого размера, но ухудшают способность кодека адаптироваться к изменению сложных сцен, где потеря деталей может быть не так важна. Высокие значения увеличивают разброс качества, который может улучшить визуальное качество путём уменьшения качества на малозаметных деталях и увеличивая там, где детали более заметны. Значение 0 даст в результате постоянное качество. Установив 1, Вы получите значительные изменения качества на разных участках клипа. Позволяет изменяться среднему квантизеру (т.е. качеству). Низкие значения означают меньшую изменчивость, высокие - большую.
    Примечание: 0 означает постоянное качество, 1 означает максимальные колебания.
    В MediaInfo: qcomp=

    Temp. Blur of est. Frame complexity

    Временное сглаживание оценки сложности сцены (кадров). Более низкие значения этого параметра позволяют квантизерам более резко изменяться при усложнении или упрощении сцены. Более высокие значения заставляют квантизеры меняться более плавно. Cplxblur гарантирует, что каждый опорный I-кадр сопоставим по качеству со следующим P-кадров. Также эта опция позволяет не тратить впустую биты при кодировании чередующихся сложных и простых сцен, во время которых происходят флуктуации квантизеров. Имеет смысл поэкспериментировать с этим параметром при кодировании анимации.
    Примечание: Задействуется только при двухпроходном кодировании.
    В MediaInfo: cplxblur=

    Temp. Blur of Quant after CC

    Временное сглаживание параметров квантизации. Похоже на --cplxblur, только используется не до, а после curve compression (--qcomp).
    Примечание: Данный параметр задействуется только при двухпроходном кодировании.
    В MediaInfo: qblur=

    Nb of Frames for Lookahead

    Устанавливает число кадров, используемых в mb-tree ratecontrol и vbv-lookahead. Большие значения улучшают результаты mb-tree, но замедляют кодирование. Для vbv-lookahead большие значения дадут большую точность и стабильность
    Рекомендации: 40..60
    Примечание: Не может быть больше --keyint. Если будет задано больше чем --keyint, то x264 автоматически уменьшит его до значения --keyint.
    Использует очень много оперативной памяти. Значения больше 100, при размере ОЗУ меньше 2Gb могут привести к падению(экстренное завершение) x264.
    В MediaInfo: Не отображается

    Use MB-Tree

    Эта опция передаёт информацию от следующих блоков к предыдущим блокам поперек векторов движения. Эту опцию можно было описать, как ограничение --qcomp, чтобы воздействовать на индивидуальные блоки вместо целых сцен. Таким образом, вместо того, чтобы понижать качество в сценах высокой сложности (как x264 в настоящее время делает), эта опция понизит качество только на сложной части сцены, в то время, как например, статический фон останется высококачественным. Эта опция также имеет много других более тонких эффектов, некоторые дают потенциально отрицательный результат, но во многих случаях MB-Tree Rate Control даёт положительный результат. Применение его помогает при всех битрейтах, и может даже помочь при феноменально низких битрейтах, где видео иначе развалилось бы полностью на блоки...
    В MediaInfo: mbtree=0..1
    [свернуть]

    Analysis - Анализ

    Analysis - Анализ


    Motion Estimation:

    Chroma M.E.

    Обычно, оценка движения производится, как для яркостного так и для цветоразностных сигналов. Данная опция позволяет отключить оценку движения сигнала цветности для небольшого увеличения скорости кодирования.
    В MediaInfo: chroma_me=
    M.E. Range

    Определяет максимальное количество попыток (с измененными данными) нахождения оптимального варианта при поиске вектора движения макроблока. Чем больше, тем лучше качество.
    Рекомендации: Стандартное значение для SD видео и 24 для HD видео. Падение скорости не стоит выигрыша в качестве, времени кодирования уже после 32.
    Желательно использовать значения кратные 4-м.
    Примечание: Для umh, esa и tesa, увеличение merange значительно замедлит кодирование.
    Для dia и hex диапазон значений: 4..16.
    В MediaInfo: me_range=

    M.E. Algorithm

    Устанавливаем метод оценки движения полного пикселя.
    Методы:
    Diamond (ромб) - простейший поиск, начиная с одного пикселя одного кадра, начинают просматриваться соседние пиксели на соседнем кадре, на один пиксель выше, правее, ниже и левее. Выбирается наиболее вероятно сдвинувшийся пиксель и процесс повторяется до тех пор, пока не будет найден лучший пиксель или пока не будет достигнут предел диапазона поиска движения
    Hexagon (шестиугольник) - состоит из подобной стратегии, но использует для поиска 6 окружающих точек, отсюда и название - шестиугольник. Значительно эффективней, чем dia, но немного медленнее. Оптимален для повседневного кодирования.
    Multi hex (неравный мультишестиугольник) - значительно медленнее, чем hex, но ищет используя сложную модель мультишестиугольника. Лучше предыдущего, способен найти сложные векторы движения, ценой потери скорости кодирования. В отличие от предыдущих алгоритмов, в этом, и во всех последующих, опция --merange задает не количество итераций, а радиус, в пределах которого будет искаться пиксель.
    Exhaustive (исчерпывающий) - высокооптимизированный интеллектуальный поиск на всей области поиска векторов движения, в пределах лучшего merange предсказания. Это математически эквивалентно методу поиска перебором, для каждого вектора движения в этой области, но быстрее. Этот метод значительно медленнее чем umh, но не дает значительного повышения качества, поэтому не рекомендован для повседневного кодирования.
    SATD Exhausive (преобразовано-исчерпывающий) - алгоритм, который пытается улучшить эффект Hadamard преобразования, сравнивая с каждым вектором движения. Похож на esa, но немного лучше и немного медленнее.
    Рекомендации: umh
    В MediaInfo: me=

    Subpixel Refinement

    Задаем сложность оценки подпикселя. Уровни 1-5 просто управляют силой обработки подпикселя. Уровень 6 допускает RDO для режима предсказания, и уровень 8 допускает RDO для векторов движения и intra режимов предсказания.
    Уровни:
    00 - fullpel only (не рекомендуется)
    01 - метод предсказания SAD, одна QPel итерация
    02 - метод предсказания SADT
    03 - постепенное увеличение QPel
    04 - постоянный QPel
    05 - QPel и Bidir ME
    06 - метод предсказания RD для I-/P- кадров
    07 - метод предсказания RD для всех типов кадров
    08 - RD обработка для I-/P- кадров
    09 - RD обработка для всех типов кадров
    10 - QP-RD (требует: --trellis 2 и --aq-mode >0)
    Рекомендации: Стандартное значение или выше
    Примечание: Чем выше уровень, тем ниже скорость кодирования.
    В MediaInfo: subme=

    Extra:

    MV Prediraction mod

    Определяет метод нахождения векторов движения.
    Доступные методы:
    None - отключает поиск векторов движения.
    Spatial - использует для поиска соседние блоки одного кадра. Может повысить PSNR.
    Temporal - использует для поиска блоки соседних кадров. Немного лучше предыдущего.
    Auto - сам выбирает какие блоки использовать.
    Примечание: auto лучше всего подходит для двухпроходного режима, но так же может использоваться и при однопроходном.auto нужно задавать во время обоих проходов, иначе второй проход будет автоматически использовать temporal.
    Использовать none крайне не рекомендуется.
    Рекомендации
    : auto – для двухпроходного режима, и spatial - при кодировании с CRF
    В MediaInfo: direct=

    Trellis

    Выполняет треллис квантование для повышения эффективности сжатия. На всех решениях, кроме 0, скорость падает очень сильно.
    Варианты:
    0 - отключено
    1 - только на макроблоках
    2 - везде
    Рекомендации: 2, но при условии совместной работы с psy-trellis, иначе происходит незначительное замыливание мелких деталей. Требует включенного CABAC.
    Примечание: Вариант 1 - хороший компромисс между падением скорости и повышением эффективности.
    В MediaInfo: trellis=

    Psy-RD Strength и Psy-Trellis Strength

    Psy-RDO позволяет экономно, с точки зрения битрейта, закодировать шумы видеоряда и значительно повысить детализацию изображения. Зернистость большинства видеоматериалов создаёт эффект большей детализации изображения, но после воздействия шумоподавляющих фильтров происходит замыливание изображения. Psy-RDO позволяет регулировать силу психовизуальной адаптации высокочастотных деталей изображения по следующему сценарию: вместо кодирования мелких деталей максимально приближенными к исходному материалу, Psy-RDO кодирует их максимально похожими на источник удобным с точки зрения битрейта способом, повышая таким образом детализацию изображения и несколько завышая показатели шума в PSNR. При этом мелкие детали не замыливаються, а заменяются похожими и выгодными кодеку структурами. Этот метод требует дополнительного битрейта в меньших объёмах при значительном повышении детализации изображения.
    Рекомендации: оставьте всё по умолчанию, хотя для многих исходных материалов вполне приемлемы значения 1.0:0.15 при условии установки --aq-strength 0.7..1.2 и --trellis 2
    Примечание: Психовизуальный метод имеет два параметра настройки:
    Первый параметр - сила психовизуальной адаптации PSY-RDO (требует активации, чтобы --subme >-6). При PSY-RDO = 0 кодек отключает специфическую психовизуальную адаптацию вовсе. При этом кодек использует старую ssd метрику, которая стремится к большей точности, но не похожести мелкой детализации. Увеличение параметра PSY-RDO повышает детализацию и зернистость изображения, уменьшение наоборот их снижает. Следите за этим параметром внимательно, не допуская перешарпности изображения и таким образом ещё и экономя битрейт.
    Второй параметр - сила Psy-Trellis. Чтобы использовать требуется --trellis >=1. Отметьте, что Psy-Trellis всё еще считают 'экспериментальной', и не рекомендуется, чтобы Вы использовали для реального кодирования, хотя кодирует всё же. При этом не повышайте величину Psy-Trellis более 0.5, хотя бы в начале.
    В MediaInfo: psy_rd=:

    No Mixed Reference frames

    Позволяет каждой 8x8 частице, в макроблоке, независимо выбирать связанный (референсный) кадр, в отличие от обычного метода, где только один референсный вектор на макроблок. Немного снижает скорость кодирования. Эта опция отключает эту возможность.
    В MediaInfo: mixed_ref=
    No Dct Decimation

    Кодер пишет видеопотоку все анализируемые блоки DCT. В результате на следующий этап компрессии подаётся оптимизированный сигнал. Если эту трансформацию отключить, то можно выиграть в детализации при двухпроходном кодировании, поскольку у кодека за 2 прохода появляется возможность оценить весь видеоряд.
    Рекомендации: Используйте (то есть отключайте) при кодировании в --crf.
    Примечание: Эта опция отключает данную функцию.
    В MediaInfo: Не отображается

    No Fast P-Skip

    Быстрый пропуск определения P-кадров повышает скорость, но может вызвать небольшую блочность в местах, где есть непрерывная цветовая гамма или лёгкий градиент (тёмные сцены или небо).
    Рекомендации: Используйте (то есть отключайте) при кодировании в --crf
    Примечание: На низких битрейтах даст небольшое улучшение качества, ценой сильного падения скорость кодирования. На высоких битрейтах, незначительно влияет как на качество, так и на скорость кодирования.
    Включение этой опции отключит быстрый пропуск.
    В MediaInfo: fast_pskip=

    No Psychovisual Enhancements

    Отключаем все психовизуальные методы.
    Примечание: Это снизит PSNR и SSIM.
    В MediaInfo: Не отображается

    Noise Reduction

    Оценивает шумность фильма и, основываясь на этом значении, пытается удалить шум с минимальными потерями деталей перед квантованием. Это далеко не лучший способ удаления шума (внешние фильтры дают лучшее качество), зато очень быстрый.
    Рекомендации: По умолчанию или (100..1000 для шумоподавления)
    В MediaInfo: nr=

    Macroblocks:

    Partitions

    x264 разбивает каждый кадр на части(макроблоки), и кодирует каждую отдельно. Этот параметр позволяет задать дополнительные параметры разбиения для каждого типа кадров.
    Доступные partitions: p8x8(включает в себя p16x8/p8x16), p4x4(включает в себя p8x4/p4x8), b8x8(включает в себя b16x8/b8x16), i8x8, i4x4
    Вы можете также установить none(отключить все) или all(включить все).
    Рекомендации: Значение по умолчанию - оптимально. Для получения максимально качества можно использовать all, но скорее всего будет не лучше чем используя значение по умолчанию.
    Примечание: p4x4 вообще то не очень полезен и его применение значительно снижает скорость кодирования при незначительном повышении качества изображения. Для HD видео лучше вообще не использовать.
    i8x8 может использоваться только в High Profile
    В MediaInfo: analyse=

    Bly-Ray:

    HRD Info

    Задаем HDR информацию. Необходимо для Blu-ray, телевизионных потоках и в некоторых других специализированных областях.
    Рекомендации: Не использовать, разве что вам нужна эта информация.
    Допустимые значения:
    none - не записывать HDR информацию
    vbr - записывать HDR информацию
    cbr - записывать HDR информацию и запаковывать видеопоток в битрейт, указанный в --bitrate. Только при кодировании в постоянный битрейт.
    Примечание: Требует включенного --vbv-bufsize
    В MediaInfo: Не отображается

    Use Access Unit Delimiters

    Используется для совместимости, когда AVC помещают в транспортные потоки (включая MPEG-2 TS).
    В MediaInfo: Не отображается
    Face Interlaced

    Обозначает видеопоток как чересстрочный, даже если он таковым не является. Позволяет кодировать видео для Blu-ray с частотой кадров в 25 и 30 в секунду.
    В MediaInfo: Неизвестно (обычно отображает как прогрессивное)
    Enable Bly-ray compatibility

    Включаем совместимость с Blu-ray.
    В MediaInfo: bluray_compat=
    [свернуть]

    Misc

    Misc


    Custom Command Line:

    Сюда вы можете ввести любые команды x264. Все введенные тут команды перезапишут выбранные в предыдущих меню.
    Полный список команд можете посмотреть тут.

    Files:

    Logfile

    Этот файл создается при первом проходе, и используется в последующих. Хранит информацию о всех кадрах.
    Use qp File

    Ручная отмена стандартного ratecontrol. Просто указываем на файл, который содержит значения квантизера и frametype для каждого кадра.
    Формат: "framenum frametype quantizer".
    Например:
    0 I 18 < IDR (key) I-frame
    1 P 20 < P-frame
    2 B 22 < Referenced B-frame
    3 i 21 < Non-IDR (non-key) I-frame
    4 b 18 < Non-referenced B-frame
    5 k 18 Kayframe
    В MediaInfo: Не отображается

    V.U.I.:

    Full Range

    Указывает на принудительное использование полного спектра яркости(luma) и цветности(chroma). Если off, то будет использоваться только ограниченный диапазон.
    Допустимые значения: on, off
    Рекомендации
    : Если ваше видео оцифровка аналогового, то установите этот параметр в off. В остальных случаях выставляйтеon.
    В MediaInfo: Не отображается

    Force pic_struct

    Force sending pic_struct in Picture Timing SEI.
    Примечание: Подразумевает использование --pulldown или --tff/--bff.
    В MediaInfo: Не отображается

    Color Primaries

    Задаем исходную цветовую модель для конвертирования ее в RGB.
    Рекомендации: По умолчанию, разве что вы знаете какое было использовано во входном видео.
    Доступные значения:
    undef
    bt709
    bt470m
    bt470bg
    smpte170m
    smpte240m
    film
    В MediaInfo: Не отображается

    Transfer

    Устанавливает какую оптико-электронную передачу использовать.
    Рекомендации: По умолчанию, разве что вы знаете какое было использовано во входном видео.
    Примечание:
    undef
    bt709
    bt470m
    bt470bg
    linear
    log100
    log316
    smpte170m
    smpte240m
    В MediaInfo: Не отображается

    Color Matrix

    Устанавливаем коэффициенты матриц, использующиеся при выводе яркости и цветности из RGB.
    Рекомендации: По умолчанию, разве что вы знаете какое было использовано во входном видео.
    Примечание:
    undef
    bt709
    fcc
    bt470bg
    smpte170m
    smpte240m
    GBR
    YCgCo
    В MediaInfo: Не отображается

    Input/Output:

    PSNR calculation

    Включаем расчёт PSNR.
    В MediaInfo: Не отображается
    SSIM calculation

    Включаем расчёт SSIM.
    В MediaInfo: Не отображается
    Force SAR

    Записывает размер не квадратного пикселя в видео потоке, который будет использоваться при дальнейшем проигрывании. Это позволяет производить анаморфное кодирование. Человеческий глаз в большей степени чувствителен к вертикальному разрешению, чем к горизонтальному, когда кодируют MPEG2-поток из DVD, этим пользуются и, сохраняя вертикальное разрешение, интерполируют горизонтальное. В этом и суть анаморфного разрешения при кодировании видео: вместо того, чтобы тратить битрейт на горизонтальные пиксели, риппер устанавливает вертикальное разрешение 1:1, а на горизонтальном экономит за счёт анаморфной интерполяции. Человеческому глазу сложно с расстояния отличить "честные" 1024x576 от тех же 1024x576 интерполированных из 720x576. Если рип был сделан с DVD, то вместо того, чтобы делать масштабирование с потерей части информации по вертикали, AVC поток можно кодировать и хранить в контейнере в том разрешении, которое было на DVD, а в самом контейнере с фильмом устанавливается флаг, который точно указывает в каких пропорциях необходимо конкретный фильм воспроизводить. Например, вы хотите создать анаморфный клип с разрешением по вертикали 480. Аспект разрешения у фильма 16:9. Тогда 480х16/9=853.44. В таком случае получим: --sar 853:720.
    Примечание: В данном примере не учтены данные Crop. Например, обрезаем слева и справа по 4 пикселя, сверху и снизу по 2. Тогда вместо коэффициента (16/9) получим (712/476)/(720/480)*(16/9).
    В MediaInfo: Не отображается

    Other:

    Threads

    Задаем количество потоков кодирования.
    Рекомендации: Для увеличения скорости кодирования - это число должно быть равно числу виртуальных или физических ядер процессора; т.е. нужно устанавливать --threads 2 на одноядерном процессоре с hyper-threading (HT), или на двух ядерном процессоре. На данный момент, максимальное количество потоков ограничено 128-и.
    Примечание: это значительно уменьшит скорость кодирования, если число потоков выбрано больше, чем количество имеющихся ядер процессора. В некоторых случаях, HT, также может уменьшить скорость кодирования. Наравне с увеличением скорости, использование нескольких потоков может незначительно уменьшить качество кодирования. Так как, кадр разбивается на слайсы, которые кодируются независимо и поэтому могут не иметь референсных связей.
    В MediaInfo: threads=

    Non Deterministic

    Немного увеличивает качество при многопоточном кодировании, ценой использования недетерминированного кодирования. Используются многопоточные векторы движения и полностью используется буфер lookahead.
    В MediaInfo: Не отображается
    Thread-Input

    Запускает Avisynth в отдельном потоке.
    Рекомендации: Включайте, если количество ядер у вашего процессора больше 1-го.
    Примечание
    : Декодирует входное видео в отдельном потоке.
    В MediaInfo: Не отображается

    Slow first pass

    Включаем "медленный" первый проход.
    Рекомендации: Только при первом проходе и если нужно получить максимальное качество. Очень замедляет кодирование.
    Примечание: Эта опция включает в себя следующие ключи:
    --no-8x8dct --me dia --partitions none --ref 1 --subme 2 --trellis 0 --fast-pskip
    В MediaInfo: Не отображается
    [свернуть]

  5. #5
    Администратор Reputation: 810 [+/-] Аватар для Veselchak


    Некоторые советы настройки кодека x264 от пользователей

    --partitions
    Для разрешения выше SD толк от p4x4 весьма сомнителен, можно смело отключать.


    --aq-mode
    [MasterNobody, @lolkin@]
    AQ работает следующим образом (по крайней мере все варианты сейчас реализованные в иксе): определяется дисперсия макроблока (пикселей в макроблоке 16x16) и в зависимости от ее значения по функции (функции различны для разных режимов AQ) макроблоку назначается отклонение от базового кванта кадра (обычно чем меньше дисперсия тем меньше делается квант, а чем больше дисперсия тем соответственно больше квант). Это приводит к тому что качество "плоских" макроблоков (где дисперсия меньше) увеличивается за счет более "энергетичных" макроблоков (с большей дисперсией). А так как обычно снижение качества "энергетичных" макроблоков заметно меньше, чем повышение качества "плоских" макроблоков, то общее визуальное качество увеличивается. Но здесь нужно учитывать, что если основная задача сохранить зерно/шумы и используемый битрейт достаточно высок (что качество "плоских" макроблоков и так достаточно), то есть смысл понизить силу AQ, чтобы он не увеличивал кванты из-за зерна/шумов. Также иногда полезно снижение AQ на исходниках типа аниме, если его сила кажется слишком большой (порча резких контуров или ringing).
    + Добавка по поводу работы с mbtree: текущий вариант --aq-mode 2 лучше не использовать вместе с mbtree, так как он плохо с ним работает.
    aqmode2 c mb-tree наверно не стоит, он разрабатывался когда дерева не было, можно пробовать --aq-mode 2 --aq-strength 1.0:1.0 представляет собой модифицированный aqmode2, попытка "вытащить" части видео ,где обычный aqmode2 не справлялся, введением qp-offset. показывал интересные результаты(иногда)
    Про aqmode3 особо сказать нечего, вроде косячный.


    --weightp
    [MasterNobody, shellgen]
    Сам по себе weightp 2 никак в негативном смысле себя нигде не проявляет, только плюсы. weightp дает более эффективное сжатие переходов (fade in / fade out). Противопоказаний никаких особых нет. Артефактов не замечено с нормальными декодерами (но могут быть проблемы с декодерами несоответствующими стандарту H.264, такими как CoreAVC 1.x или некоторыми железными плейерами). Здесь речь именно о --weightp 2. --weightp 1 тоже полезен, но уже не так эффективен для сжатия переходов (fade in / fade out).
    Насчет подбора me по логу, это мне кажется какой-то извините ахинеей. me выбирается не по логам, а исходя из того насколько дольше вы готовы ждать при соответствующем повышении качества (выше umh ИМХО не стоит).


    --no-fast-pskip

    (запрет быстрого пропуска определения P-кадров)
    Быстрый пропуск определения P-кадров повышает скорость, но может вызвать небольшую блочность в местах, где непрерывная цветовая гамма или лёгкий градиент (тёмные сцены или небо). Включение этой опции ОТКЛЮЧИТ быстрый пропуск.
    Рекомендации: Включено при 2-х проходном кодировании, при CRF –желательно отключить.


    --trellis

    Особенность работы треллиса в том, что он может размазывать по ровным областям мусор , метрикой psy-trellis устанавливается коэффициент этой самой мазни. Если сигнал чистый, фон ровный и не имеет ярко выраженной шумовой структуры, то отключив треллис, можно предотвратить "мазню" в фоне, но вместе с тем можно потерять на резкости других деталей, поэтому для их сохранения может понадобиться доп. битрейт, который можно было сэкономить за счёт треллиса. С другой стороны, поднимая дэдзоны есть шанс уложиться и в меньший битрейт за счёт отсечения низкоквантовых деталей, в этом случае доп. битрейт не потребуется. Всё очень сильно зависит от сигнала, к каждому нужен свой подход, но как правило включенный треллис позволяет передать больше деталей в аналогичный битрейт. trellis дает субъективный результат. А на мультиках его рекомендуется отключать.


    --deadzone-inter xx
    [MasterNobody]
    --deadzone-intra xx
    Q: deadzone ставить по 6 как рекомендуют, чтобы сохранить зерно или оставить можно по умолчанию 11-21 ?
    A: Это в зависимости от, того, какие задачи ставить. Если это анимация, да еще такая, в которой нет мелких деталей, то можно и дефолтные 11, 21, а если высокодетализированный источник и нужно сохранить даже мелкий шум, то уменьшаем вплоть 6,4. В любом случае по скриншотам придется смотреть и экспериментировать. Задает пороги для мелких деталей в пределах которых x264 будет их выкидывать не пытаясь сохранить. Наверно при deadzone-intra 6, deadzone-inter 6 стоит задуматься о хорошем запасе битрейта. Чем ниже значение, тем более мелкие детали по яркости будет стремиться сохранить кодек, но тем больше естественно понадобится битрейта для их сохранения.
    Лучше придерживаться золотого правила: "Не знаешь - не крути". А вообще если используется --trellis 2, то deadzones уже практически ни на что не влияют. С другими же режимами trellis их иногда можно уменьшить для сохранения зерна/шумов. Так раньше (а может и сейчас) можно было часто увидеть --deadzone-inter 6 --deadzone-intra 6 именно для целей сохранения зерна/шумов (опять же нужно учитывать, что это повышает битрейт, так что имеет смысл при достаточно высоких битрейтах).


    -mbtree
    [shellgen]
    Грубо говоря, опускает кванты макроблокам, на которые часто ссылаются близлежащие в радиусе --rc-lookahead фреймы и vice versa. Чем ниже --qcomp, тем больше эффект от mbtree. В мультипроходе эффективнее срабатывает.
    На SSIM и прочих попугаях всегда сказывается положительно, чего не скажешь о визуальном восприятии. На анимации наверное хорошо, на живом видео субъективно пока не очень. Более эффективно работает в мультипроходе, в crf тоже судя по результатам неплохо, но теоретически менее эффективно.
    Опыт использования MBtree на средних и высоких битрейтах и высоко детальном видео Для анимации и битрейтодефицитных пережаток возможно всё и хорошо, но в остальном ничего хорошего не замечено пока... Особенно на динамике и с зерном вообще IMHO плохо, для себя остановился пока на --no-mbtree.
    mbtree хорош для чистой картинки с повторяющимися кадрами. Это не только новое аниме, но и прочая 2D мультипликация.
    Q: Простым сценам в результате достается меньше, а сложным битрейта больше, чем раньше, когда мы не использовали mbtree ?
    A: Нет. Больше битрейта достается не "сложным сценам", а "полезным" макроблокам.


    --bframes

    Нет ограничений на b-фреймы по Levels


    --psy-rd

    Опция позволяет нам регулировать оптимизацию расходуемого на кодирование битрейта (rate-distortion optimization, RDO). Оптимизация предполагает максимально эффективное использование битрейта с точки зрения восприятия картинки человеком. Чем большие значения мы выставляем в этой опции, тем больше мы отдаем предпочтение детализации перед битрейтом. Но... Эти процедуры/методики ориентированы на получение не "такого же" (подобного) изображения, а визуально похожего ("психовизуальные показатели"). Они не делают картинку "более четкой" (более, чем что?), а сохраняют (пытаются сохранить) детализацию за счет битрейта крупных объектов (использование psy-rd понижает PSNR/SSIM). Это приводит к появлению артефактов (части крупных объектов распознаются кодеком как отдельные объекты), что особенно критично при некачественных исходниках.


    --colormatrix
    [MaLLIeHbKa]
    Правильней указать цветовой диапазон исходника в настройках x264 следующим ключом: "--colormatrix xxx". Где xxx - BT.709, BT.601 и т.д.
    --colormatrix "bt470bg" например если DGIndex показывает 470. Еще варианты: undef, bt709, fcc, bt470bg, smpte170m, smpte240m, GBR, YCgCo
    Q: Что значат 625 и 525 в "ITU-R..."?
    A: Число линий для PAL (625) и NTSC (525)
    Q: Что это за опции в логе: Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177
    A: Грубо говоря, информационные данные (на сам энкод никак не влияют), содержащие рекомендации декодеру по преобразованию цветового пространства, дабы он сам не строил предположений на этот счёт (предположения обычно строятся на основе разрешения, или не строятся вовсе). Далеко не все декодеры этими данными пользуются.


    --cqm

    Совместно с psy их использование в 99% случаев нецелесообразно.


    --vbv-bufsize

    bufsize — это размер промежуточного буфера перед декодером. maxrate — скорость, с которой этот буфер заполняется. "Пик" — максимальный объём информации, который декодер может получить в единицу времени. Если буфер заполнен, то за одну секунду декодер может получить не больше (maxrate+bufsize). За две секунды не более (2*maxrate+bufsize) и т.д. Аналогично работает -m limit в iptables, если это о чём-то говорит.
    Buffer underflow будет, если параметры VBV неправильно подобраны. Очевидно, что сами по себе "пики" не являются ограничением.


    --zones

    Q: Что значит: zones=116800,121753,q=35
    A: Кадры с 116800 по 121753 кодируются с постоянным квантизером 35. Занижение качества на титрах с целью выиграть битрейта на основной видеоряд.


    --subme

    --subme 10 хорошо для 2 прохода.
    С точки зрения соответствия оригиналу subme 9, предпочтительнее.
    Есть такое дело. Когда битрейта более чем достаточно, есть смысл на него опускаться; если имеет место быть даже самую малость битодефицит, QPRD здорово вытягивает.
    Q: Когда 9 лучше, чем 10?
    A: Таких примеров не скажу, а если они и есть, то вполне может оказаться что и 8 лучше чем 9 (вобщем, это только случаи когда меньше RD лучше, но это скорее всего может быть только когда как-то криво выкрутили --psy-rd).


    --merange

    (максимальное количество итераций при поиске векторов движения) [komisar666]
    Определяет максимальное количество попыток (с измененными данными) нахождения оптимального варианта при поиске вектора движения макроблока. Чем больше, тем лучше качество. Но падение скорости не стоит выигрыша уже после 12.
    Отметьте, что для umh, esa и tesa, увеличение merange значительно замедлит кодирование.
    hex –> umh разница в размере большая, в скорости не очень существенная
    umh –> esa –> tesa разница в размере минимальная (причём иногда в "странную" сторону, как ни удивительно), а время вырастает очень существенно, чуть ли не "в разы" (tesa), что уж очень печально
    16 –> 24 разница есть, но не очень большая и в размере и в скорости
    24 –> 32 тоже есть, но уже незначительная в размере >32 – практически пустая трата времени
    umh – по-моему самый оптимальный алгоритм, с точки зрения соотношения производительность/качество. Всё, что "ниже его" – несколько быстрее и ощутимо хуже. Всё что выше – ощутимо медленнее и незначительно лучше
    На счёт merange при umh: разницы между всеми значениям "16 и выше" вижу немного. Меньше 16 ставить не стОит. Можно поднять до 24-32.
    Алгоритмы esa и tesa – медленные, дающие небольшой прирост в качестве, логично их использовать, когда скорость энкода совсем не важна, а +капельку улучшения получить хочется. Логично что в таком случае поставить merange можно и побольше (раз времени то совсем не жалко). Но всё равно не думаю, что в значениях больше 32 есть хоть какой-то смысл.
    Алгоритмы "меньше umh" – быстрые алгоритмы, позволяющие получить "максимум" fps энкода.
    Логично, что если стремимся именно к этому, то ставить большие значения merange нелогично, т.к. скорость "уйдёт", а качество "не придёт"... Иными словами больше 16 ставить смысла не вижу.
    Такое лучше все же смотреть по SSIM. Улучшение точности M.E. в принципе ведь не всегда должно приводить именно к уменьшению размера. Но так конечно tesa+32 это плацебо которое на качество влияет очень слабо.
    merange в некоторых кругах "рекомендуют" FrameWidth/16(именно на 16 делят -на размер макроблока) Увеличивать его полезно при кодировании динамичного исходника... т.е. чтобы алгоритму поиска движения дать возможность найти макроблок с выпущенной пулей, "улетевшей" во втором кадре на расстояние, большее, чем merange...
    За МЕ Range в логе отвечает параметр direct, и как я понимаю, чем он ниже, тем менее востребованы высокие значения МЕ Range.


    --no-dct-decimate
    [shellgen]
    У нас есть блок. У этого блока есть dct коэффициенты. Если коэффициент меньше порога X, то его можно обнулить. А можно оставить на второй проход, вдруг битрейта хватит и на его сохранение. Ключ --no-dct-decimate отвечает, грубо говоря, за опцию предварительной DCT трансформации сигнала перед непосредственно кодированием, как результат - сигнал на следующий этап компрессии подаётся уже немного оптимизированный. Если ключом эту трансформацию отключить, то есть вероятность немного выиграть в детальности в мультипроходе, т.к. за несколько проходов у кодека есть возможность оценить полную версию сигнала, НО категорически не стоит выключать DCT оптимизацию при однопроходном кодировании, только навредит по очевидным причинам.


    --rc-lookahead

    Памяти много - выкручивайте побольше. На что на практике влияет rc-lookahead ?
    На количество фреймов, используемых mb-tree (mb-tree ratecontrol) и vbv (vbv-lookahead).
    - Если задействуете mb-tree, то значение rc-lookahead должно быть меньше или равно keyint.
    - Если используете vbv, то значение rc-lookahead должно быть меньше или равно max( keyint, max( vbv-maxrate, bitrate ) / vbv-bufsize * fps ))


    --deblock
    [@lolkin@]
    Чем выше квант тем больше сила деблокинга, и наоборот. соотв при низких квантах деблок практически не задействован.
    Q: Подскажите, есть ли еще какие-либо методы борьбы с квадратами на участках с равномерными цветами (в мультфильмах), кроме деблока и значительного повышения битрейта?
    A: Если исходник mpeg, то в строке загрузки указать cpu=4 (для борьбы с блочностью).


    --ssim

    --psnr
    SSIM - это объективный измеритель соответствия входящего сигнала выходящему. Считается что он ближе к человечьей субъективности.
    Q: Какое значение SSIM считается достаточно хорошим?
    A: Для живого видео цифра пригодна больше для сравнения эффективности различных синтетических настроек на одном и том же подопытном. Хоть SSIM в отличие от PSNR и заточено в некоторой степени на восприятие, но psy портит его почём зря, часто заметно прибавляя визуального комфорта, так что обращать избыточное внимание на этого попугая не стоит.
    Q: Скажите пожалуйста, насколько важны параметры SSIM и PSNR? Кто-то включает их в выкладываемый лог, кто-то нет.
    И значения того же SSIM: ~0.96 можно считать неудачным результатом и искать лучшие решения?
    A: ssim/psnr считают, в данном случае, соответствие выходящего сигнала из кодека входящему сигналу B в кодек. Если мы отфильтруем то кодек на вход получит сигнал с лучшей сжимаемостью и увеличится ssim. Чтобы посчитать реальный ssim надо взять сигнал до кодека и без фильтров и сигнал после кодека. Только смысла такого сравнения мало. Тот же фильтр сложного деинтерлейса уронит тебе тот ssim до невозможности.


    --fullrange

    У нас есть в видео три сигнала. Они могут быть от 0 до 255. Это fullrange он же PC. Они могут быть в диапазоне ТВ ( 16-235 яркость и 16-240 цветность). При работе с промышленными непержатыми енкодами с оптических носителей в 99.9% случаев специально указывать fullrange не нужно. ))


    CRF
    (pass) [k0stix, @lolkin@, komisar666]
    Constant Rate Factor есть модель, ориентированная в отличие от битрейта не на биты и байты, а на оптимизированные исходя из психовизуальных выкладок потери lossy кодирования, чем ниже, тем. меньше потери. Пропорциональная зависимость CRF от битрейта лишь следствие этого.
    Есть общая тенденция, при подборе битрейта как правило близким к оптимальному будет битрейт при том значении CRF, при котором кванты I фреймов не упадут ниже 16-17 (более низкие значения обычно сигналят об откровенном перерасходе), а B-фреймов не подскочат выше 25-25.5 (более высокие значения как правило вызывают явно различимые артефакты). Всё что находится в промежутке между этими значениями - надо сравнивать глазами, чтобы оценить возможность/необходимость поднять кванты повыше/пониже. В большинстве случаев комбинация близкая к qi18-qp20-qb23 даст результат, максимально приближенный к оптимальному.
    Если нужно выжать из объёма максимум, попав при этом в точный размер, не выходя за пределы левелов аппаратной поддержки, не жалея времени, то целесообразно делать мультипроходный CRF
    Первый проход: --crf ??.? --pass 1 --stats "stats.txt"
    Второй проход: --bitrate < битрейт, полученный на первом проходе, скорректированный под целевой > --pass 3 --stats "stats.txt" --vbv-...
    Если аппаратная совместимость не актуальна (для SD разрешения она в том числе неактуальна), то тратить время на мультипроход из соображений часы/"выигрыш в качестве" не вполне целесообразно.
    Если судить по квантам, уже 2-проходный на основе crf выигрывает в сравнении с однопроходным, даже без mbtree. Точно так же и на глаз.
    crf никак не привязан к какому-то определенному битрейту, он дает битрейта ровно столько, сколько надо на данный отрезок видео. Т.е. надо, чтоб битрейт подскочил на 420 кбпс и сохранялся таким в течение 5 минут, crf столько и выделит. С кодированием в битрейт все вертится вокруг заданного битрейта, грубо говоря, на графике это выглядело б как кривая, постоянно ходящая вокруг оси координат (заданного битрейта), постоянно пытаясь вернуться к заданному значению. Помимо того, это и разные алгоритмы сжатия. crf, опять-таки, как я понял, больше внимания уделяет не слишком динамичным сценам, т.е. там, где действительно можно глазом уловить разницу во время просмотра. На ядреной такой динамике может что и пропустить.
    При одинаковом битрейте 2-ой проход на основе статистики с crf дает ощутимое преимущество в сравнении с просто crf-ом, как по попугайчикам, так и визуально
    1. Для quality-based кодирования вполне достаточно 1-Pass CRF. Нужно вписаться в ограничения хардварных декодеров?, CRF+VBV сейчас прекрасно работает.
    2. Есть острая необходимость вписаться в конкретный битрейт/размер файла - 2-pass CRF. Причем первый с --slow-firstpass, вторым тюним если промахнулись.
    Q: Есть ли ещё какие-либо критические моменты или рекомендации к CRF энкоду, в плане настроек, кроме --no-dct-decimate --no-fast-pskip --direct spatial ?
    A: В остальном от мультипрохода твикинг однопроходного CRF'а не отличается, за исключением того, что при кодировании HD сигнала лучше делать тот же CRF, но в два прохода, чтобы не вылезти за пределы допустимого с точки зрения хардварных чипов VBV, особенно 1080p касается. )
    Q: Если выбран crf 20, 20 это средний квант для P ?
    A: Это значение RateFactor в понятии кодека, при котором получается некое "постоянное качество", но никак не квант.


    Чтение лога
    [shellgen]
    {codecitation}

    coded y,uvDC,uvAC intra:84.5% 77.7% 43.7% inter:46.2% 37.9% 2.7%
    {/codecitation} Это статистика по ненулевым макроблокам (включая skip-блоки) в распределении по каналам и inter/intra фреймам
    {codecitation}

    x264 [info]: coded y,uvDC,uvAC intrA: 93.2% 0.0% 0.0% inter: 24.8% 0.0% 0.0%
    x264 [info]: i16 v,h,dc,p: 30% 18% 8% 44%
    x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 17% 10% 7% 8% 11% 12% 11% 11% 11%
    x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 13% 10% 2% 10% 15% 15% 13% 12% 11%
    {/codecitation} Добавлены "закодированные блоки" в статистику вывода информации. Это позволяет измерять полный процент от блоков, внутренних и внешних, которые имеют коэффициенты отличные от нуля. "y, uvAC, uvDC" относятся к luma(яркости), сигналу цветности с DC и сигналу цветности с AC.
    Отметьте, что пропущенные блоки включены в эту статистику {codecitation}

    x264 [info]: mb B I16..4: 0.0% 1.2% 0.4% B16..8: 29.3% 2.1% 2.9% direct: 4.4% skip:59.7% L0:43.5% L1:34.6% BI:21.8%
    {/codecitation} Это использование частиц {codecitation}
    x264 [info]: mb P I16..4: 0.6% 12.4% 0.9% P16..4: 45.9% 23.0% 12.1% 0.2% 0.0% skip: 5.0%
    x264 [info]: mb B I16..4: 0.0% 1.4% 0.2% B16..8: 57.4% 1.8% 2.3% direct: 5.7% skip:31.2% L0:40.8% L1:55.4% BI: 3.8%
    {/codecitation} 1 : неизменные субблоки перешедшие от интра фреймов в P-фреймы
    2 : direct: скомпенсированные по движению неперекодированные субблоки, skip: неизменные субблоки, L0: субблоки с вперёд-направленным предсказанием, L1: аналогично, но назад-направленно, BI: двунаправленно-предсказанные субблоки. Оставшаяся выделенная часть лога читается по аналогии с приведенным описанием

    Q: Я бы тоже хотел научиться правильно читать места лога, которые shellgen не объяснил.
    A: direct: блоки, скомпенсированные по остаточной разнице после предсказания с нулевым вектором skip: неизменные блоки проскочившие от intra фреймов, L0: вперёд-направленное предсказание, L1: назад-направленное, BI: двунаправленно-предсказанные блоки. Лог периодически терпит косметические и функциональные изменения, это как правило освещается в истории ревизий. ))
    Для direct prediction макроблоков вектор движения (MV) не кодируется (так же как и для skipped макроблоков).
    Anime [k0stix]
    Общие рекомендации - в пресетах MeGUI. А точнее --aq-mode 0, ну и psy-rdo можно малость вниз крутануть. Остальное - по обстоятельствам, как обычно.
    Довольно стандартный анимэшный пресет - psy в ноль и aq-strength где-нибудь ближе к 0.6 или 0.5, можно попробовать.
    На анимации о ssim можно забыть, не под то затачивался. Деблок можно вырубить. Динамичные сцены хорошо вытягивает tesa, хотя на 720p это хорошенько займет времени. psy можно немного снизить, скажем, 0.6, но тут - поле для экспериментов, aq можно в районе 0.7 или ниже, как будет смотреться.
    Шумы в DVD Source [Pustovetov, gjiAm]
    Q: Кодирую с помощью Avidemux DVD9 в AVC рип. Использую crf режим - никак не могу добиться детализации как на исходнике. Шумы и мелкие детали все равно замыливаются. Какие настройки кодека можно подкрутить?
    A: Шумы чтоб оставались попробуй psy_rd 1.1 и выше. пси треллис покрути. типа 1.2:0.2 но это не глядя. фик знает что там
    --b-pyramid, --no-mbtree, subme 10 тоже бы поставил deblock=1:-3:-3, trellis=2, aq=1:0.75. С целью сохранения зерна кстати можно еще пощупать нежно ip_ratio= / pb_ratio= В preset'е для зернистых источников присутствует такой ключ, как qcomp 0.8, aq-strength, deadzone.
    Q: Сорец немного шумноват и староват. Для сглаживания зерна использую --deblock 2:2 , для деталей --psy-rd 1.20:0. Что еще покрутить для сглаживания мушек, т.е вылизать картинку ?
    A: Использовать для сглаживания шумка не деблокинг, а нормальный темпоральный шумодав с настройкой sigma? К примеру dfttest. Можно еще попробовать DeGrainMedian - настроек маловато, но работает на удивление эффективно. Для небольшой фильтрации - DeGrainMedian(limitY=5,limitUV=5,mode=3)
    Разное [gjiAm, shellgen]
    Q: Вопрос про тулзу которая показывает реальный битрейт фильма в силе. Ну не ужто нет такой ?
    A: DGAVCIndex посчитает пик, avinaptic строит примитивный график для avi и mp4, больше вроде ничем.
    Q: Подскажите фреймсервер для mkv на input
    A: dss2()
    ffvideosource()
    DGMultiSource()
    Q: Что такое "фейды"
    A: Плавный переход тонов (затухание картинки и наоборот).
    Q: Что такое "Тип развёртки : MBAFF ?
    A: MBAFF попадает в выходной буфер декодера в виде гибридных полуполей и устранять чересстрочность нужно, но если для захвата сигнала был использован какой-нибудь dss(), то в синт попадает уже восстановленным в прогрессив средствами ds фильтров, установленных в vfw. Если есть уверенность в ds фильтрах в своей системе, то можно оставить как есть, если на борту nvidia, можно вытащить прогрессив из purevideo, если nvidia нет или чересстрочность кривая, то остаётся только вытаскивать сигнал из avcsource()/libavcodec и бороться с интерлейсом привычным синтовским инструментарием. На статичных фреймах чересстрочность не ловят, особенно MBAFF, - нужно внимательно изучить сцены с хорошим движением.
    Q: А есть возможность указать кодировщику границы фрагмента видео? Ну с какой по какую секунду (с какой по какой фрейм) брать исходник. Можно конечно сторонней программой вырезать нужный участок, но так было бы удобнее.
    A: Trim(x,y)
    Q: Если открыть 3-4-5 файликов то всеми встать одновременно на один кадр невозможно ?
    A: directshow не рассчитан на frame accurate seeking, чуть лучше позиционирование делает dss2() за счёт halli, но есть абсолютно frame accurate альтернатива - ffms2.
    code.google.com/p/ffmpegsource
    {codecitation}

    loadplugin ("c:\Program Files\megui\tools\ffms2-2.12\ffms2.dll")
    FFVideoSource("D:\Repack\Out_Usual\Обыкновенные подозреваемые.1.mkv")
    {/codecitation} Скачиваете полный "боекомплект" FFmpegSource. Все распаковываете и в паку плагинов AviSynth. Есть в нем (в "боекомплекте") такая штука - FFMS2.avsi, содержащая функцию: function FFInfo(clip c, bool "framenum", bool "frametype", bool "cfrtime", bool "vfrtime") По умолчанию все булевы параметры установлены в "true". Т.е. достаточно в скрипте после FFхххSource указать FFInfo() и получите информацию о текущем фрейме, его типе и т.д. Ничего подгружать не надо ( .avsi самозагружаемые).
    Q: А имеет ли смысл рипать интерлесный исходник в прогрессив ?
    A: В идеале "настоящий" интерлейс надо оставлять интерлейсом. Проблема в том кто сможет такой идеал отдеинтерлейсить на лету при просмотре
    ffdshow теряет фреймы. Рекомендуется строить граф через MS-декодер (или индексировать).
    Если видеокодек VC1, то индексируем в DGAVCDecNV, или создаем Граф.
    Q: Индексировать лучше сам видепоток (.vc1, .264) или в контейнере (m2ts, mkv) ?
    A: Индексировать лучше поток с помощью DGAVCDecNV и открывать через DGMultiSource (без CUVID-сервера).

    DirectShowsource(), будучи не frame-accurate сервером, может терять фреймы, если во время его работы на занятое декодированием ядро упадёт дополнительная значительная нагрузка - фреймы, на декодирование которых не хватило мощности, просто будут заменены на предыдущий

    dss2(), декодируя через тот же DirectShow через haali, не может теоретически гарантировать frame-accurate потока, но на практике жалоб на ошибки позиционирования и сбои не поступало. при условии ненагрузки тяжёлыми задачами занятого енкодом ПК надёжность такого метода захвата фреймов должна быть достаточно высокая

    ffvideоsource() имеет ряд проблем всплывающих при попытке извлечения сигнала из транспортных и сырых потоков. мультиплексирование видеопотока в матрёшку подобные проблемы решает, плагин в этом случае использует haali

    DirectShow фильтр - ffdshow, часто и подло сбоит на декодировании VC1, особенно на позиционировании. граф через родной DMO фильтр при невозможности использования других способов захвата сигнала на более надёжен

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •  
          
Рейтинг@Mail.ru Яндекс.Метрика Бесплатный анализ сайта Индекс цитирования.