Софт-Архив

X264vfw настройки

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

Описание

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

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

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

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

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

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

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

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

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

X264vfw настройки:

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

    Dxtory x86 x64 2013, ENG

    Dxtory 2.0.122 x86+x64 [2013, ENG]

    Dxtory 2.0.122

    Год/Дата Выпуска. 2012

    Версия. 2.0 Build 122

    Разработчик. ExKoder

    Разрядность. 32bit+64bit

    Совместимость с Vista. полная

    Совместимость с Windows 7. полная

    Язык интерфейса. Английский

    Таблэтка. Присутствует

    Системные требования. NET Framework 4.0

    Описание. Dxtory - это программа для записи видео с игр и прочих приложений поддерживающих DirectX и OpenGL. Dxtory является отличной альтернативой популярному Fraps`у - программа имеет в разы больше настроек записи и позволяет записывать видео с игр гораздо быстрее, чем ранее упомянутый Fraps.

    Доп. информация. Совместима с Windows 8

    Особенности программы:

    Наибыстрейшая запись видео. Dxtory является инструментом видеосъемки для DirextX / OpenGL приложений. Программа работает с очень высокой скоростью. Произвольная обрезка и свободное масштабирование поддерживается аппаратным обеспечением.

    Запись без потери качества. Кодек Dxtory может записывать исходные пиксельные данные, а выходное качество видео получается без ухудшения источника видеосигнала. Кроме того, также поддерживается VFW-кодек.

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

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

    Установка:

    • Устанавливаем программу (перед установкой снимаем галку с "Update check is at login" и ставим галку на "Cleanup before Install")
  • Блокируем программе доступ в интернет
  • Запускаем
  • Указываем файл лицензии
  • Настройки кодека () в 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 окна настроек видеокодека.

    X264 кодирование (настройка кодека, работа с megui)

    X264 кодирование (настройка кодека, работа с megui)

    Так уж повелось, что с приходом более ёмких носителей информации пришла и эра высокого разрешения, новомодного HD. Популярность торрентов открыла новый виток в погоне за сэкономленными компрессионными мегабайтами видео. Судя по статистике скачиваний, именно раздачи приставкой Rip, AVC - получают все большее народное признание, это и не мудрено, ведь возможность скачивать и сохранять десятки гигабайт в пересчете на один полуторачасовой фильм стала реальностью, но чрезвычайно расточительного свойства. На личном опыте, не перестаю удивляться как быстро возможно, в буквальном смысле проглотить, полутерабайтную связку RAID0 массива. Всему виной медиаконтент, пухнуший после перевода на рельсы "высокой четкости". В этом смысле, переход на новые алгоритмы сжатия видеопотока стал действительно назревающей проблемой. Не вдаваясь в исторический экскурс, отмечу, что в свое время с весомой долей скептицизма отнесся к появлению видеокодека h264. обусловленная очевидно сильной DivX привязанностью. Время как известно, не стоит на месте и вот уже просторы торрентов стали местами проглядывать полуторагигабайтными рипами весьма сносного качества. Как и полагается закоренелому консерватору, мне было чудовищно сложно отказаться от бытующих в моем сознании представлений компрессии видео, и сделать шаг по направлению к набирающему обороты h264. Свой негативный оттенок вносил контейнер mkv. в который, как правило, "запечатывался" видеоряд сжатый h264 и звуковая дорожка соответствующего качества. Популяризация матрешки, со скрипом, но все же подтолкнула меня к освоению последующей ревизии h264, а именно видеокодека x264. Многочисленные обзоры на просторах рунета, доносят довольно многообещающую информацию, характеризующую кодек x264/h264 как наиболее прогрессивное решение в области компрессии видеоинформации. Сравнительные тесты в режиме "покадровой развертки" демострируют впечатляющие результаты, игнорировать которые в настоящее время более не представляется возможным. Посему, забегая вперед отмечу, что знакомство оправдало мои ожидания и скорее всего будет иметь довольно длительную историю, при сопутствующем неизменном росте вычислительной мощности соврменных компьютеров. Итак приступим. Для работы нам потребуется следующее программное обеспечение:

    MeGUI+AviSynth

    MeGUI — GUI (графический пользовательский интерфейс) с открытым исходным кодом, ориентированный преимущественно на сжатие материала в формат ISO MPEG-4. Может также использоваться для создания скриптов AviSynth (AVS), объединения потоков мультимедиа и сжатия аудио.

    Входные форматы: любые, для которых установлен VfW или DirectShow декодер (используется AviSynth), AVI, D2V, VOB/TS/MPG/PVA

    Видеокодеки: x264, XviD, Libavcodec MPEG-4, Snow

    Аудиокодеки: AAC (FAAC, Nero Digital, Winamp), MP2, MP3 (LAME и Aud-X), AC-3, Ogg Vorbis.

    Поддерживаемые контейнеры: MP4, MKV, AVI. Доступно также сохранение в бесконтейнерном виде (raw stream) .

    AviSynth — средство для обработки, в частности линейного и нелинейного монтажа видеоматериалов. Работает как фрэймсервер, имеющий систему сценариев, редактирование которых позволяет осуществлять нелинейное редактирование любого уровня сложности с высоким уровнем воспроизводимости результатов.

    Сперва инсталлируем AviSynth, затем распаковываем MEGui, который не требует привычной установки. При первом запуске megui предложит обновить компоненты самой себя с чем незамедлительно соглашаемся.

    Обновляем.

    После поочередного обновления всех предложенных и доступных в настоящий момент частей программы, переходим к созданию скрипта процесса кодирования. В качестве источника я выбрал видеофайл "Битва титанов" объемом 9,6 гигабайта. Ставилась задача: получить существенно меньший по размеру видеоконтент с хорошим соотношением разрешение/объем. Первым этапом процедуры пережатия является процесс создания скрипта/алгоритма последовательных действий.

    Выбираем вкладку AVS Script Creator.

    Подгружаем исходный видеоматериал

    Как видно исходное видео высокого разрешения 1920 на 800 пикселей, aspect ratio или отношение сторон составляет 2,4, битрейт составляет 10772 Kbps; 23,976 fps; 0,293 bpp. Последняя величина есть ничто иное как плотность бит на пиксель, т.е (10772 Kbps)/(1920x800x23,976 fps)=0,293 bpp. Плотность информации на пиксель величина наиболее полно отражающая качество, исходя из понятий битрейта, разрешения картинки и плотности понимаем, что для получения меньшего размера при сохранении хорошего качества видеоматериала нам необходимо соразмерно уменьшить разрешение и битрейт при близкой к 0,2-0,3 плотности бит на пиксель. Приведу цитату википедии..

    "Самый оптимальный вариант - вычислить значение по формуле: ширина_кадра*высота_кадра*кадров_в_секунду*0,15/1024. Где 0,15 - количество бит на пиксель (можете варьировать это число в пределах от 0,05 до 0,2 по своему усмотрению). Если же вам надо получить определенный размер конечного файла, то воспользуйтесь встроенным калькулятором (Tools\Bitrate calculator) "

    Опустившись, до стандартного по горизонтали разрешения (DVD-Video, 720p) и сохраняя коэффициент плотности информации на пиксель 0,3, получим битрейт по видео равный - 1539Kb/s, а с учетом длительности фильма приблизительный размер видеодорожки составит 1,1-1,2Gb. Жмем SAVE.

    В разделе настроек кодера устанавливаем x264 *scratchpad*, жмем config, для установки параметров. Для достижения максимального качества выбираем трёх!проходное кодирование, и пресет PLACEBO - который является наиболее ресурсоёмким, битрейт задаем 1500Kb/s.

    Остается добавить задания в очередь нажав Enqueue.

    Перейдя на вкладку Queue видим поставленные в очередь 3 прохода сжатия видеоконтента. Статус каждого из проходов можем перевести в отложенный (postponed) выбирая таким образом подходящий момент для продолжения процедуры либо приостанавливая её. Остается нажать Start.

    Сразу после старта процесса кодинга наблюдаем довольно красноречивые промежуточные результаты, а именно: скорость пережатия на.

    составляет немногим более 2,5 кадров в секунду, время требуемое на один проход предварительно оценивается в 15 часов 45 минут, загрузка обоих ядер процессора стабильно очень близка к максимальной. А вот собственно говоря и результат.

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

    Артефакты кодирования наиболее явно проявляют себя в динамичных сценах при сжатии с малым битрейтом. Таким образом, новый алгоритм сжатия, заложенный в прогрессивном детище x264, уверенно опережает конкурентов, позволяя визуально оценить разницу в качестве полученного видеоматериала. Единственным минусом видеокодека x264. является его чрезвычайная ресурсоемкость на этапе сжатия видеоконтента.

    p.s: В настоящей статье я затронул исключительно процесс сжатия видеоматериала кодеком x264, таким образом, на выходе, мы получаем беззвучный видеофайл, вложенный в контейнер mp4. Логичным продолжением произведенной работы служит пережатие многоканальной аудиодорожки ac3 в ogg, с последующим муксом (сведением воедино) mp4-видео и ogg-многоканальной аудио дорожки в mkv контейнер. Так что продолжение следует.

    Маслёнков Андрей (8 сентября 2010г.)

    Сохранение рассчитанного видео

    С использованием Haali Muxer

    Потребуется: x264vfw. Haali Muxer (Program Files\Haali\MatroskaSplitter\gdsmux.exe) - устанавливается вместе с Haali Matroska Media splitter'ом, входит в состав дистрибутивов пакета SVP.

    Порядок действий:

    1. Сформировать скрипт: Запустить SVP менеджер; открыть требуемый видео-файл в плеере, выполнить необходимые настройки в профиле SVP; убедиться, что в иконке SVP менеджера появился зеленый треугольник; открыть созданный скрипт: Показать - AVS-скрипт; закрыть SVP и плеер (обновится файл AVS\ffdShow.avs в папке SVP).

    2. Активировать скрипт на время перекодирования: Открыть окно настроек декодера ffdShow: Пуск -> Программы -> K-Lite Codec Pack -> Configuration -> ffdshow video decoder (откроется окно "ffdshow. "); в нем зайти на вкладку AviSynth, скопировать скрипт целиком из открытого окна ffdshow.avs; включить галку "Buffer back/ahead", указать в полях: 0 - в первом, 5 (цифру числа потоков + 1, число потоков см. в строке "SetMTMode(5. )") - во втором поле, включить галку AviSynth (см. скриншот) - OK.

    3. Открыть видео в Haali Muxer'е: Пуск -> Программы -> K-Lite Codec Pack -> Tools -> Haali Muxer (откроется окно "DS Mux"); В нем открыть требуемый видео-файл: правой кнопкой по центру окна -> Add Source.

    3.1. Указать формат сжатия видео: Контекстное меню на видеодорожке: Encode -> x264vfw -> выбрать "Single pass - ratefactor-based (CRF)", указать Ratefactor:19 -> OK;

    3.2. Указать имя создаваемого файла: Нажать ". " -> указать путь, набрать имя, указать расширение mp4 (например, "video.mp4") -> Сохранить;

    3.3. Запустить процесс: Нажать кнопку Start.

    4. Деактивировать скрипт: Открыть окно настроек декодера ffdShow: Пуск -> Программы -> K-Lite Codec Pack -> Configuration -> ffdshow video decoder (откроется окно "ffdshow. "); в нем зайти на вкладку AviSynth, очистить текст скрипта, снять галку с AviSynth - OK.

    С использованием MediaCoder

    MediaCoder имеет больше настроек, чем DS Mux, в добавок, он при открытии не использует ffdShow. Порядок действий в MediaCoder'е:

    1. Сформировать скрипт: запустить SVP менеджер; открыть требуемый видео-файл в плеере, выполнить необходимые настройки в профиле SVP; убедиться, что в иконке SVP менеджера появился зеленый треугольник; закрыть SVP и плеер (обновится файл AVS\ffdShow.avs в папке SVP).

    2. Отредактировать скрипт: открыть AVS\ffdshow.avs в текстовом редакторе; заменить строку ffdShow_source() на строку DirectShowSource("[имя Вашего файла]"), указав полный путь и имя видеофайла.

    3. Открыть скрипт AVS\ffdshow.avs в MediaCoder'е.

    3.1. Настроить формат сжатия, выбрать параметры сжатия для видео и звука, выбрать контейнер, путь сохранения.

    3.2. Запустить процесс: Нажать кнопку Start.

    Замечания:

    1. Такой способ открытия видеофайла открывает и сразу распаковывает один видео- и один аудиопоток. Остальные данные исходного видеофайла, включая встроенные субтитры игнорируются.

    2. За один проход оставить звук без перекодирования невозможно. Тем более две дорожки, тем более с субтитрами. Поэтому при таком сохранении лучше отключить галку Enable Audio, и добавить к полученной видео-дорожке недостающие аудиодорожки и субтитры из исходного файла уже в муксере.

    1. avs-скрипт для Юшко - исправляем пути и открываем в VirtualDub через Ctrl+O (SVP должен быть выгружен)

    2. Video - Fast recompress, Audio - No audio

    3. Ctrl+P - меняем на x264vfw, в его настройках уменьшаем CRF с 26 до 19-20

    4. Video - Select Range - в столбце Frames ставим: 0, ниже: 1000 (кусочек, чтобы проверить)

    Работа с видеоматериалом (конвертация, обработка и пр

    Rost 3038

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

    Начну с конвертации несжатого материала (к примеру ваше видео из игр) для последующей публикации на сервисах видеохостинга с помощью кодека x264 (H264 ) и программы VirtualDub (freeware ).

    Подразумевается некоторый опыт работы с данным видеоредактором (если нет, не стесняйтесь спрашивайте).

    VirtualDub устанавливать не требуется, достаточно распаковать .zip -архив в удобное место. Установка кодека x264vfw обычная, прописка по адресу C:\Program Files (x86)\x264vfw и соответственно в реестре.

    Если время поджимает, то можно сжимать в один проход. В этом случае выбираем Single pass - ratefactor-based (CRF). он предпочтительнее CQP. т.к. больше сжимает области, потеря качества которых не заметна при просмотре, и размер не в пример меньше. Приведенное значение Ratefactor не показатель оптимального качества (зависит от исходника и желаемого размера & качества на выходе), но ниже 28 опускаться не советую (ниже значит выше ), оптимально 18-23 .

    Все прочие важные настройки я подчеркнул, level 3.1 в данном случае выбран для совместимости с мобильными гаджетами (к примеру, если выкладываете на "трубу") и из-за выбора рабочего разрешения (720p ) - это определяющий момент. если видео будет просматриваться на компьютере или (и) качество 1080p. то следует выбрать level 4.1 .

    Для удобства выбора нужного уровня можете использовать данную табличку (честно спионерил с wiki ):

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

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

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

    Первый проход делаем выбирая Multipass - 1st pass. значение Target bitrate = 800 опять же не показателено, было выбрано для ролика из игры (и оказалось вполне достаточным), экспериментируйте (к примеру - для видеоматериала снятого камерой в HD это непозволительно мало, тут уже ниже 8000, в зависимости от разрешения и количества кадров, опускаться нельзя). Прочие настройки одинаковы.

    Для второго и возможных следующих проходов выбираем Multipass - Nth pass. И вот тут есть нюансы - после первого прохода ничего заново в VirtualDub не открываем. Файл полученный после первого прохода содержит информацию для последующих, результат второго прохода (финальный файл) сохраняем под другим именем (не перезаписываем первый). После окончания процесса все ненужные файлы можно будет удалить.

    Также предложу выключать обработку звука, выбирая Audio - No audio для первого прохода, дабы не загружать машину ненужной обработкой, но для второго не забудь включить обратно .

    Звук рекомендую сжимать с помощью широко известного Lame mp3. сэкономите достаточно. Если кодек не установлен в системе и VirtualDub его автоматом не подхватил, пишите, я приложу здесь и поясню как его правильно установить.

    P.S. Почему именно VirtualDub  и x264 (H264 )? Во первых софт абсолютно бесплатен и доступен каждому, во вторых обладает определяющими достоинствами - скоростью, простотой освоения, качеством сжатия относительно сохранения качества материала. VirtualDub  в частности гибок и легко расширяется с помощью плагинов, фильров и кодеков.

    P.P.S. В дальнейшем, если будет интерес, готов обсудить работу с материалом снятым на цифровые видеокамеры - возможные прочие видеоредакторы (в зависимости от исходного формата), способы конвертации, подачи и оптимальный битрейт.

    Изменено 14 Июн 2014 пользователем Rost

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

    Некоторые советы настройки кодека 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 –желательно отключить.

    Особенность работы треллиса в том, что он может размазывать по ровным областям мусор. метрикой 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. Нет. Больше битрейта достается не "сложным сценам", а "полезным" макроблокам.

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

    Опция позволяет нам регулировать оптимизацию расходуемого на кодирование битрейта (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. "?

    Q. Что это за опции в логе: Matrix coefficients. BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

    A. Грубо говоря, информационные данные (на сам энкод никак не влияют), содержащие рекомендации декодеру по преобразованию цветового пространства, дабы он сам не строил предположений на этот счёт (предположения обычно строятся на основе разрешения, или не строятся вовсе). Далеко не все декодеры этими данными пользуются.

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

    --vbv-bufsize

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

    Q. Что значит: zones=116800,121753,q=35

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

    --subme 10 хорошо для 2 прохода.

    С точки зрения соответствия оригиналу subme 9, предпочтительнее.

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

    Q. Когда 9 лучше, чем 10?

    A. Таких примеров не скажу, а если они и есть, то вполне может оказаться что и 8 лучше чем 9 (вобщем, это только случаи когда меньше RD лучше, но это скорее всего может быть только когда как-то криво выкрутили --psy-rd).

    (максимальное количество итераций при поиске векторов движения) [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 - это объективный измеритель соответствия входящего сигнала выходящему. Считается что он ближе к человечьей субъективности.

    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]

    coded y,uvDC,uvAC intra:84.5% 77.7% 43.7% inter:46.2% 37.9% 2.7%

    Это статистика по ненулевым макроблокам (включая skip-блоки) в распределении по каналам и inter/intra фреймам

    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%

    Добавлены "закодированные блоки" в статистику вывода информации. Это позволяет измерять полный процент от блоков, внутренних и внешних, которые имеют коэффициенты отличные от нуля. "y, uvAC, uvDC" относятся к luma(яркости), сигналу цветности с DC и сигналу цветности с AC.

    Отметьте. что пропущенные блоки включены в эту статистику

    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%

    Это использование частиц

    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%

    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

    ffvideosource()

    DGMultiSource()

    Q. Что такое "фейды"

    A. Плавный переход тонов (затухание картинки и наоборот).

    Q. Что такое "Тип развёртки. MBAFF ?

    A. MBAFF попадает в выходной буфер декодера в виде гибридных полуполей и устранять чересстрочность нужно, но если для захвата сигнала был использован какой-нибудь dss(), то в синт попадает уже восстановленным в прогрессив средствами ds фильтров, установленных в vfw. Если есть уверенность в ds фильтрах в своей системе, то можно оставить как есть, если на борту nvidia, можно вытащить прогрессив из purevideo, если nvidia нет или чересстрочность кривая, то остаётся только вытаскивать сигнал из avcsource()/libavcodec и бороться с интерлейсом привычным синтовским инструментарием. На статичных фреймах чересстрочность не ловят, особенно MBAFF, - нужно внимательно изучить сцены с хорошим движением.

    Q. А есть возможность указать кодировщику границы фрагмента видео? Ну с какой по какую секунду (с какой по какой фрейм) брать исходник. Можно конечно сторонней программой вырезать нужный участок, но так было бы удобнее.

    Q. Если открыть 3-4-5 файликов то всеми встать одновременно на один кадр невозможно ?

    A. directshow не рассчитан на frame accurate seeking, чуть лучше позиционирование делает dss2() за счёт halli, но есть абсолютно frame accurate альтернатива - ffms2.

    code.google.com/p/ffmpegsource

    loadplugin ("c:\Program Files\megui\tools\ffms2-2.12\ffms2.dll")

    FFVideoSource("D:\Repack\Out_Usual\Обыкновенные подозреваемые.1.mkv")

    Скачиваете полный "боекомплект" 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 фильтр при невозможности использования других способов захвата сигнала на более надёжен