Как найти оптимальные настройки кодирования для ультра-динамичных видео и музыкальных клипов. Мой метод.

Забыли добавить "всё тлен". Не смешите мои тапки. Так что же --tune animation не использует никто из известных риперов, чьи BD-рипы наиболее популярны в HD разделе аниме? Все повально идиоты? Или просто пасаны то и не знают про такую замечательную вещь как --tune animation? Открыл такой Xvid4PSP 5, выбрал --tune animation и готово? По детски наивно полагать, что о вас кто-то печётся, как например аптекари, реклама, правительство и авторы tune у x264.

DFM515, суть в том, что в моей статье описан метод и комбинация настроек, которая на реально сложных видео выжимает максимум качества с наименьшим артефактным мусором. Все настройки покручены по сотне раз и то что описано в статье - это результат именно сотен экспериментов на действительно сложном видео. Я понимаю, что люди зачастую кодируют видео с большим кол-вом статичных сцен и результат от кручения тех или иных настроек на 99% видео не ощущается, а артефакты зачастую могут быть ошибочно восприняты как улучшение детализации.
Исходя из чего моя позиция такова, что мой метод и настройки хоть и не самые быстрые, но самые универсальные. Т.е. лучше чем с такими объективно выжать качество сильнее просто не получится из любого видео, можно лишь выкрутить те или иные настройки в сторону артефактов, которые будут имитировать шум и детализацию, или получить нечто очень похожее менее радикальными методами и чем проще будет видео, тем менее радикальны будут эти методы, а в каких-то случаях и правда будет достаточным просто использовать шаблоны. Но в том то вся и фишка, что "в отдельных случаях" и "будет достаточно" - это как раз причины всех разногласий в настройках и делений видео на различные типы, а учитывая банальное незнание куда и на что смотреть, выцветший ЖК-монитор десятилетней давности, зрения -5 в одном глазу и +5 в другом, наставлений самназванных ПРО, неверной трактовке и глухим телефонам, а также с потолка взятой веры в то что чем быстрее кодирование, тем лучше - разногласий становится только больше. И ещё больше их стало с появлением и культивацией шаблонов, tune и субъективной метрики SSIM. Одно на другое накладывается и в итоге мы имеем кучу "ПРО", которые расходятся друг с другом во мнениях в половине аспектов, но в тоже время дружно смотрят как на говно на любого кто с ними не согласен. Как результат: у меня есть комбинация и целая система по подбору настроек с заявкой на универсальность, но никто не хочет её даже просто протестировать и сравнить, просто потому что вот тут и там что-то не соответствует представлениям и "богатому" опыту местных "ПРО", да и опускаться до таких никому ненужных мелочей как тесты, сравнения, аргументы и доказательства их самомнение не позволяет, что, собственно, весьма характерно для любого более-менее долго существующего форума, и армия школотроллей к этому набору прилагается.

Это видно. Видно что вам ничего на самом деле не нужно. Вы пришли самоутвердиться. Вот он я - спаситель сообщества риперов. Ща вытащу из широких штанин панацею и будет всем счастье. Но мир устроен несколько иначе. Критику вы не воспринимаете. Никто вам ничего не должен, чтобы объяснять и разжёвывать каждый косяк. В дополнение картину портят явные промахи в основах.
Нравится вам ваш метод - так в чем проблема? Пользуйтесь на здоровье. Или хочется обязательно нести в массы "светлое, доброе, вечное"? Если последнее, то просто не будет. Придется самому доказывать свою правоту, долго и нудно, а не ждать, что все метнутся строчить опровержения с практическими выкладками. Знаете сколько таких прометеев тут постоянно пробегает... Это уже явный перегиб. Это где такая ересь описана? O_o. Чем же вам не нравятся шаблоны, которые придуманы мало того что авторами кодека, но так же и энтузиастами куда более искушенными в вопросах сжатия чем вы. Идем дальше - чем не угодила метрика? Любая метрика по сути субъективна, т.к. нет четких критериев для идеального сравнения даже двух кадров, не то что видео. И уж тем более критиковать метрику стоит хотя бы имея математическое образование чтобы - та-дам!!! - предоставить факты, а не голословные утверждения. Если в основе системы наблюдаются явные косяки, то уже только поэтому ни у кого не возникает желания тратить свое время. И вот этого уже не можете понять как раз вы. Это как верить прыщавому и толстому диетологу.

Ах-хах, простите, что? Эка ловко вы из жертвы меня превратили в льва. Я пришёл чтобы меня рожей ткнули туда где я не прав, подкрепив это всеми необходимыми доказательствами, к чему я уже задолбался призывать. Но кроме "ты не прав, иди помолись на Шикари и Ноубади, да почитай сеттингзы" больше ничего, пусто. Так что не я тут самоутверждаюсь, а каждый второй самоутверждается на мне и вы не исключение. Ещё тысячу раз повторить что мне не нужна голословная критика? Ещё тысячу раз повторить что мне не нужна голословная критика? 2 Почему? Ах, да, забыл, потому что вы просто так считаете! А я просто должен взять и поверить господину на слово. А как должно быть, сравнения, тесты, доказательства? Господину же негоже до такого опускаться. Доказывать? Я уже пытался год назад, давал лосслесс, тыкал пальцем на тот артефакт который появляется при кодировании, просил закодить лучше чем я, а толку? Правильно, 0. Одни нападки, троллинг и обмен мнениями. В конечном итоге когда я уже психанул и ушёл один единственный человек нашёл меня на другом ресурсе и дал свою версию кодирования куда я его ткнул в те самые артефакты, с которыми я справился лучше чем он. И что он ответил? "Да всё равно никто не заметит." И после этого он остался при мнении, что просто, ну, видео нехарактерное попалось, чё уж там. :facepalm: Почему? Ах, да, забыл, потому что вы просто так считаете! А я просто должен взять и поверить господину на слово. А как должно быть, сравнения, тесты, доказательства? Господину же негоже до такого опускаться. 2 Часто сталкиваюсь с таким мнением на разных ресурсах. Не поверите, но подавляющее большинство правда рассматривает высокую скорость кодирования как один из параметров хорошего кодирования. Уже объяснял в своём первом посте на этой странице, читать надо было. Как минимум потому, что mbtree крайне значительно улучшает её показатель, а учитывая что я далеко не фанат mbtree, даже бы сказал, что антифанат, то не вижу и вообще какого-либо смысла опираться на SSIM. Аналогично кодирование с фиксированным битрейтом значительно повышает SSIM - да как после этого можно серьёзно воспринимать такую метрику? Вы серьёзно полагаете, что в ней есть смысл? И при этом отписавшие тут SSIM-филы крутят qcomp не в сторону фиксированного битрейта, т.е. ближе к 0.00, а в сторону фиксированного qp, т.е. ближе к 1.00. Да какой в этом, чёрт подери, смысл то? Какой смысл крутить одни настройки в сторону SSIM, а другие в обратную, а потом меряться этим самым SSIM? Вы когда-нибудь над этим задумывались? И опять же я это уже тут объяснял, читать надо было. Почему? Ах, да, забыл, потому что вы просто так считаете! А я просто должен взять и поверить господину на слово. А как должно быть, сравнения, тесты, доказательства? Господину же негоже до такого опускаться. 3
Я пришёл чтобы меня рожей ткнули туда где я не прав, подкрепив это всеми необходимыми доказательствами, к чему я уже задолбался призывать. 2 А вы никак не можете понять, что у меня тут нет авторитетов, которые бы мне просто говорили что у меня всё не так и всё не эдак, а я бы просто брал и верил этим господам на слово. Вы тут прям в очередь встали чтобы мнения свои драгоценные оставить и я каждому в отдельности объясняю что без аргументов и доказательств они мне не интересны. А с чего вы взяли что чем-то лучше этого диетолога? Вот я всех здешних "ПРО" как раз именно такими диетологами и представляю.
P.S. Знаете в чём между нами принципиальное отличие? Я ставлю свою точку зрения под сомнение, а вы - нет. Вы боитесь как огня, что можете оказаться не правы, а я не боюсь, потому что мне тут нечего терять. И поэтому вы можете только пустозвонить и ссылаться на кого-то за зря тратя моё и своё время. Я волен говорить как что я думаю, так и почему я так думаю, а вы дальше чем кидаться ничем не подкрепляемой фразой "ты не прав" пойти не можете, поэтому и ищете до чего докапаться просто чтобы вставить очередное очень ценное "ты не прав", ведь если попытаетесь хоть раз аргументировать, то докапаться уже могут до вас и статус ПРО будет подорван. Но является ли такой диалог конструктивным? Или всё-таки это не более чем банальное пустозвонство и напрасная трата времени, которая ни к чему не приведёт? В общем проходите мимо.
Ну и небольшое сравнение:
Как задумывали авторы тюнов x264

Как делаю я

http://www.youtube.com/watch?v=pzMLYJ0aDyU&list=UUE9NNgIyaGOsm9lU3wmPu-Q&...detailpage#t=107

Bill Ein
Хочешь сравнения, а не языком болтать (что ты делаешь в этой теме больше всех), тогда берем один любой семпл из: park_joy, parkrun или любой другой HD-семпл из коллекции.
и ты нам говоришь свои настройки x264 под этот семпл, а то вдруг мы еще неправильно твою инструкцию по выбору настроек поняли (а потом претензии будут, что мол не то выбрали).
А так же настройки для семплов LosslessAzumanga.mkv и LosslessTouhou.mkv. Здесь уже без выбора, оба семпла.
И вот в итоге по этим трем семплам будем проверять насколько универсальна твоя инструкция.

Вам про Фому, а Вы про Eрему. Зачем требовать от людей внимания к Вашим опусам, если сами не желаете слышать и понимать, того, что пишут Вам.
Для того, чтобы задуматься:
Аналоговые измерительные приборы постоянно требовали настройки при поверке, неблагодарная скажем работа. При появлении цифровых приборов стало проще, т.к. уже схемотехнически в них была заложена определенная точность, не требующая настроек. Всегда основной задачей схемотехника являлось получение решения схемотехнически обеспечивающего заданную точность. А мы все стираем, ой извините настраиваем. Начните хотя бы с этого. В чем и где? Глядишь, что и получиться.

А зачем Вы этот бред пишите тут, а не на каких-то "разных ресурсах"? Прошу прощения но тут что не утверждение, то ерунда. Начните с того что расскажите нам что такое SSIM и почему Вам не нравятся математические методы сравнения качества (при всей их понятной ущербности). Ну и дальше продолжайте про кодирование с "фиксированным битрейтом" (для справки у x264 нет кодирования с "фиксированным битрейтом" ну т.е. СBR когда на каждый кадр приходится одинаковое количество бит. В норме у x264 - VBR. А чтобы сделать более менее реальный CBR нужно устроить танцы с бубном). Очевидно что qcomp=1.00 это не в "сторону фиксированного битрейта", а просто в "огороде бузина, а в Киеве дядька". QP это не битрейт, а Quantization Parameter (параметр ухудшения). Меряются SSIM умные люди в каких-то специфических сравнениях. Обычные риперы этим не занимаются.

Bill Ein
Посоветуйте пожалуйста настройки для кодирования игрового видео из FRAPS. Кодирую в XviD4PSP 5.
Почитал статью и получил следующие настройки(2 прохода CRF): А вот такими настройками пользовался до этого(2 прохода CRF): Исходное видео обладает приблизительно следующими харрактеристиками: Разбираюсь очень слабо, может и напутал что-то.

Вот этого я и ждал.
В течении недели постараюсь сделать. Ну как можно было так умудриться в корне переврать то что я написал? :facepalm: Я, честно говоря никогда не кодировал в 2 прохода по CRF, но знаю что так делают. Всё-таки кое-чем помочь могу:
1) --no-fast-pskip - честно говоря весьма субъективная настройка, т.е. хоть в сеттингзах и написано что на пониженных битрейтах может улучшить качество, но реального эффекта в моих экспериментах оно не произвело, даже бы сказал, что лишь усилило артефакты
2) --psy-rd 0.90:0.00 - для откровенно заниженных битрейтов в psy-rd нет нужды, а CRF23 даёт именно откровенно заниженые битрейты, так что шумок psy-rd не только адекватно не сохранится, но ещё и даст только артефакты с практически в пустую повышенным весом файла, так что тут только --no-psy
3) --deblock -1:-1 - для таких CRF как в примере и без psy-rd лучше изменить на 0:0
4) --me umh - ну если уж изменили subme на 11, то и me на tesa тогда уж поменяйте
5) --preset medium - если вы вручную задаёте fast-pskip, b-adapt, direct, merange, subme, me, trellis, partitions, ref и bframes, то в указании "preset" нужда отпадает, а в medium и вовсе нет никакого смысла, т.к. в нём используются те же настройки, которые итак уже стоят по умолчанию
6) с учётом изменений в пункте 2 и 3 ref и bframes лучше сменить по таблице либо на 7 и 7 соответственно, либо на 2 и 2, вообще можно закодировать 2 варианта по 1 или 5 минут и посмотреть какой будет лучше по весу и по качеству.

Мне не совсем понятны условия этого абстрактного конкурса. Чем мы конкретно должны тягаться? Ну, хорошо, если вы не можете сформулировать правил, то их сформулирую я:
1) Кодируем в 8бит.
2) Кодируем в один проход по CRF, при этом я указываю CRF.
3) Все сравнения должны опираться НА РАВНЫЙ ВЕС, А НЕ CRF моего и вашего вариантов настроек по отношению к конкретному видео. Т.е. я задаю CRF, а вы подгоняете свой вариант более-менее точно под вес моего используя десятичные деления CRF.
4) Моя задача предоставить мои настройки, ваша задача предоставить свои и наглядные сравнения со своими не нарушая условий 1, 2 и 3, обязательно подкрепляя файлами инкода.
Поехали:

Условия в целом нормальные, единственное не совсем согласен с пунктом 2 в плане фиксации CRF, так как выбраны слишком малый значения (особенно для touhou) и поиск разницы будет полнейшим пиксель хантерством. И чтобы соблюсти это условие, тогда еще прошу предоставить версию для настроек под crf +6, а лучше все +12 (а для touhou можно и побольше плюс) относительно уже выбранных. С уже выбранными сравнение тоже будет, но просто оно не наглядно.

Какие ваши предложения?
Суть ведь в том кто лучше закодирует и тут важно соотношение веса на качество. У кого при одинаковом весе будет качество очевидно лучше, тот и победил.
Если хотите сделать дополнительно сравнение на CRF12 или 6 или том, который сочтёте нужным, то я не против. Мне интересны результаты как на завышенных CRF так и на заниженных. Главное чтобы при сравнении соблюдалось равенство веса сравниваемых вариантов.

Ну к примеру. Размер файлов 7141430 vs 7189896 байт. У меня меньше. Кодировал я специально по "рекомендациям производителя" т.е. --tune animation ... едем далее. HD vs размеры файлов 8657477 vs 6622728
Скриншотики. Отгадаете где чей? Совершенно правильно. Вон то мыло мыльное и на 2 мегабайта больше это Ваши оптимальные настройки.

Pustovetov, без файлов это всё просто никчёмное сотрясание воздуха, т.к. можно же просто нап****ть. Да и ещё меня интересует разница в скорости, так, просто для галочки. Ну попробуйте из моего варианта убрать --qcomp 1.00 ещё и понизить CRF до 22 например, будете крайне неприятно удивлены.
Ну и я догадываюсь почему вы не выкладываете сравнение Тохо. Тюны и пресеты на нём не канают.
Ещё хочу разобрать вот этот жуткий бред: --thread-input --threads 1 - это немного перебор, посмотрел бы я на таких риперов, которые покупают 12-ядерник, чтобы кодить рип в один поток.
--merange 32 - опять же перебор кодить SD и HD с таким значением, а учитывая вышеупомянутые --thread-input --threads 1 всё вместе это снижает скорость кодирования до уровня неоправданно-абсурдного.
Да, и к вашему сведению:
preset 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 11 --trellis 2
Грубо говоря, если вы ставите preset placebo, то вписывать повторно эти настройки уже смысла нет: --bframes 16 --rc-lookahead 60.
--direct auto - хорошо подходит для 2-проходки, но для CRF не имеет смысла, куда больше смысла использовать только --direct spatiel
А ещё мне интересно что у вас победило: ref=16 из плацебо или заданный вручную ref=8; partitions all из плацебо или заданные вручную partitions p8x8,b8x8,p4x4,i8x8; me=tesa из плацебо или заданный вручную me=umh; merange=24 из плацебо или заданный вручную merange=32? Правильный ответ: вручную заданные.
Идём дальше.
tune film: --deblock -1:-1 --psy-rd <не задано>:0.15
Грубо говоря, если вы задали деблок вручную 0:0, то вам фактически остаётся только задать psy-rd=1.00:0.15. А ещё мне интересно какой же deblock всё-таки в конечном итоге у вас получился: из тюна (-1:-1) или заданный вручную (0:0)?
Вы ставите тюны и пресеты, но в тоже время больше половины настроек перезадаёте вручную другими или точно такими же. Признайтесь, вы ведь вообще не понимаете что крутите и тычите, ведь правда?
Ну и давайте подведём небольшие итоги:
1) вы кодируете в 3 раза дольше ради весьма сомнительного профита
2) вы как и я использовали --b-adapt 2 --trellis 2 --deblock 0:0 --aq-mode 2 --subme 11, но в отличии от меня везде ставили --thread-input --threads 1 --bframes 16 и --me umh --merange 32 --no-fast-pskip и не отключали mbtree с decimate, значит можно сказать, что для вас универсальные настройки: а теперь сравните с теми которые использовал я во всех случаях: Всё это значит, что у вас тоже есть свой набор универсальных настроек, которые вы также считаете оптимальными, ведь единственное что вы меняли это vbv-maxrate, vbv-bufsize, ref, psy, partitions (и то не факт что при этом что-то изменилось), qcomp и aq-strenght (в tune animation) - всего 7 настроек, а я всего одну - qcomp, да и то в примере с парком вы это сочли за дурость. Если бы я в правилах ещё и указал, что кодируем без psy (как хотел изначально), то у вас бы осталось всего 6 настроек для кручения.
Теперь сравним расхождения:
про direct и threads, уже было сказано выше
fast-pskip - на x264 settings написано, что данная настройка имеет крайне незначительный эффект, так что можно даже за отличие не считать
merange - на x264 settings написано, что при повышении от 16 крайне незначительно сокращает вес, но значительно снижает скорость кодирования и может давать артефакты. Так что лучше? 16 или 32?
decimate - на x264 settings написано, что отключение данной опции немного улучшает качество и немного повышает вес. Так что лучше? 0 или 1?
aq-strenght - на x264 settings написано, что регулирует баланс битрейта в пользу простых сцен, при повышении и в пользу сложных при понижении.
qcomp - тоже самое, только другим методом и наоборот: при повышении в пользу сложных, при понижении в пользу простых.
mbtree - на x264 settings написано, что эта функция повышает скорость кодирования, снижает качество на сложных сценах и повышает на простых. Вы же этому препятствуете через aq-strenght и qcomp, но в тоже время диаметрально противоположно при повышении rc-lookahead. Так что же лучше? Не использовать mbtree или использовать и при этом глушить через aq-strenght и qcomp?
partitions - не знаю какой профит там у вас от отключения i4х4, информации по этому поводу никакой не нашёл, но догадываюсь что опять связано с гадской SSIM.
Выводы делайте сами.
MasterNobody, вы тогда для примера с парком у меня тоже попробуйте вариант без --qcomp 1.00 и с CRF22, если не лень.

Ну я же не Вы, право. Любой желающий может получить эти файлы самостоятельно запустив несколько раз x264 с предложенными настройками. 1.2 fps vs 1.01 fps например. Причем у меня шло в один тред и соответственно можно еще проц нагружать и нагружать заданиями. Зачем? Вы привели свои оптимальные настройки. Теперь они оказались не очень оптимальными? Бывает Не догадываетесь. Я ее просто не качал Ну и где разбор? Не осилили? Бывает Читайте инструкцию, пытайтесь думать. Увы, но я же не Вы. Я то понимаю что кручу и тычу. По этому у меня и качество лучше при меньшем весе (на ~25%) и большей скорости кодирования (в ~2 раза). Вас бы сразу послали лесом и полем. Потому что отключать главную фишку кодека может только идиот.

А вы чего-то боитесь? К сведению --qcomp в статье не упоминается, а я считаю что в примере с парком равномерная мазня выглядит намного лучше, нежели неравномерная. Читайте инструкцию, пытайтесь думать. (с) Увы, но дублирование настроек из плацебо подтверждает обратное, так что давайте не играть в эти детсадовские переводы стрел. Большей скорости? Вот сейчас кодирую и не вижу чёт этой большей скорости, а глядишь когда докодирую, то и качество тоже окажется не таким как на словах. После этого с вами у меня разговор закончен.

Вот еще скриншот от файла с более равным весом (8527241 vs 8657477 у Вас)
--crf 25.7 Нет. Просто подбирать за Вас Ваши оптимальные настройки по Вашему методу как то странно. Увы, но Вам не дошло что я просто вставил это самое плацебо в готовую настройку, а все дубли поленился вычистить. Уж извините но в 4 часа ночи немного было лень. Благо что это ни на что не влияло. В два раза. На моем процессоре и компьютере конечно... А что у Вас там за железка мне не известно. Неприятно ощущать себя дураком? Бывает.

Bill Ein
Подскажите: кодирование со всеми этими тонкими настройками разве можно увидеть путём сравнения скриншотов? просто если нет, то почему не кодировать по умолчанию через однокнопочные программы с автоматическим выбором настроек, ведь человеческому глазу нужна картинка, а не цифры во фреймах я понимаю что от фреймов пляшет картинка, но увидеть её можно? Также я не говорю про минимальные настройки где видео пережимается до состояния пикселей.

Ton-ik

Pustovetov, ок-ок, если вам не хватает знаний и усердия чтобы прочесть мою статью, понять её и понять в чём суть моей системы, то специально для вас сокращённая версия:
1) неизменяемые универсальные настройки: Эти настройки я считаю и заявляю универсальными и наилучшими, которые в моей системе не поддаются изменению ни в каком случае (кроме редких случаев, где имеет место попробовать b-adapt 1, но тут я этого делать не буду).
2) deblock, CRF/битрейт, ref, bframes и psy-rd - являются основными изменяемыми настройками
3) ref и bframes
а) если не лень, то подбираются по логу как это описано хоть в моей статье, хоть тут
б) если лень, то ref берётся из таблицы относительно выбранного deblock, а bframes к нему приравнивается
4) psy-rd
а) если не лень, то подбирается на глаз
б) если лень, то берётся из таблицы относительно выбранного deblock
5) прочие настройки крутить не рекомендуется, но в принципе допустимо если иначе никак (в частности те же qcomp и aq-strength)
6) при кодировании по CRF direct=1, при кодировании в 2 или 3 прохода direct=3
7) при кодировании для онлайн и для PSP при очевидном недостатке битрейта ref=2 bframes=2
Надеюсь теперь понятно? Нет? Попробуйте ещё раз. Всё равно нет? Проспитесь и попробуйте снова. И всё равно нет? Проходите мимо. Разобрались? Тогда читайте ниже.
Хотите psy-rd? Тот артефактный трындец по вашему качественный инкод и высокая детализация? Хорошо, будет вам psy-rd. Я нигде не писал, что не имею права на ответный инкод. Вот вам psy-rd и это никак не противоречит моей системе, которую мы сейчас проверяем на прочность и универсальность.
Берём мои универсальные настройки: 1) добавляем deblock 0:0
2) добавляем к ним psy-rd, пох, пусть хотя бы даже тупо как у вас 1.00:0.15
3) берём из таблицы ref=5 и подбираем bframes, я с первого раза попал на 9
4) бёрем CRF 23.9, чтобы более-менее попасть в вес вашего примера
объединяем всё вместе и получаем Как видите, от настроек Азуманги отличается только ref, bframes и psy-rd и я менял при этом только основные изменяемые настройки, которые предусматривает и позволяет менять моя система в первую очередь.
Время инкода по вашим настройкам ~18мин
вес 6 604 136 байт
файл
Время инкода по моим настройкам ~15мин
вес 6 547 233 байт
файл
скрины (найдите 10 отличий): Итоги: вы при кодировании 2-х разных файлов задействовали разные настройки и вертели в 2 раза больше ключей чем я, при этом в результатах нет явных и очевидных различий, а скорость инкода у меня оказалась выше.
Вывод: при весьма смутной и субъективной разнице в качестве мои настройки выиграли по скорости инкода и лишь подтвердили свою универсальность.

Да куда уж, нам, серым и убогим до Вас батюшко... Про mbtree Вы уже ранее бредили, а после врали. Что такое merange? Внятно и желательно описательно алгоритмов tesa и umh... Ну что Вы, батюшко, размылить все что можно по глупости, а потом облажавшись нести дальше гордо бред это по Вашему. =) Уж не обессудьте Вы наверно и должны были начать с примеров своего энкода. Прямо в начале данной темы. Чтобы интересующимся времени не терять... А не требовать от других чтобы они кодили по Вашим настройкам для Вас? Упс...
А после драки поздно кулаками махать. Вы не перепутали скрины? Иначе я поглочу Вашу раздачу на данном трекере 1) Я всегда при кодировании разных файлов задействую разные настройки. 2) Сейчас я не кручу ничего, практически ваще. Возможно Вы под ключами понимаете что-то типа "--partitions p8x8,b8x8,p4x4,i8x8 --vbv-maxrate 50000 --vbv-bufsize 62500 --level 4.1"? Так это для совместимости с железяками ухудшалки качества и флажки. Их крутить не надо. Они по умолчанию. =) Скорость и качество вашего инкода можно посмотреть выше. Они тупо хуже дефолтных настроек кодека минимум в 2 раза и на 25% соответственно... А то что Вы, после того как Вас ткнули в глупость, соизволили что-то закодить и поменять свою "систему" на более адекватную. Ну дык понятно же... дрессировка. И зайца можно на барабане научить играть. Вот Вы уже используете вместо --qp 26 аж --crf 23.9 --qcomp 0.6. И психовизуальную подстройку ошибок включили
Едем далее... Тохо Вот попробовал тохо с тюнами и пресетом. тупо --preset placebo --tune animation --crf 12.0 --aq-mode 2 --merange 32 --me umh
Да, конечно хуже получилась снежинка слева внизу. И размер на ~4 мега больше. Не спорю... но наверно я выбрал самый поганый кадр для кодирования пресетом из этого видео. И мне не нужно было никаких особых методов. Просто выбрал настройки кодека по умолчанию в заданный Вами размер
Уж извините, но ставить меньше --merange 32 лень, а более --me umh не имеет особого смысла. p.s. Риперы аниме отличаются от просто риперов тем что они активно используют сложные скрипты и плагины. В частности тут я бы применил кое что. Но мы же о настройках кодека, а не о фильтрации нейросетями.

Наверное, будь возможность, кодил бы и на 100-ядернике.

Как написано на x264 settings так и говорил, это вы уже бредите. А вот тут я немного приврал, но на практике в моих экспериментах повышение merange выше 16-и действительно лишь добавляло артефактов, нецелесообразно повышая время инкода будь то хоть umh, хоть tesa. Драки? Это вы тут самоутверждаетесь и сыпите оскорблениями в каждом втором предложении, а я занимаюсь проверкой моей системы и комбинации настроек для доработки статьи под частные случаи. Вот частный случай, я использовал полностью стандартный набор и изменил в нём предусмотренный системой основной параметр, получив при этом почти аутентичную картинку с вашей за меньшее время, а вы загалдели "Аз-за-за, нищетова, позняк метаца! " Ей богу, ведёте себя как самоутверждающийся школьник, впрочем так было изначально и ничего не изменилось. Если бы всё кодировали только для железяк, то не было бы и 10bit рипов. :facepalm: В 2 раза? На 25%? Вы у офтальмолога давно проверялись? Советую сходить. Боже, да что за херню вы несёте? Тот случай, когда скрины одного рандомновзятого кадра говорят чуть более чем ничего. Тут нужно смотреть видео целиком из-за особенностей сорца. У вас размер на 4МБ больше? Это как бэ уже существенная разница в весе для столь не очевидной по скринам разницы, не считаете, нет? Тут мне не придётся даже делать ответного инкода. Ах, да, чуть не забыл: ваш инкод "тупо хуже минимум в 2 раза и на 25% соответственно..." Риперы аниме как раз почти не сталкиваются с такими вещами как ультраперенасыщенная детализация и последующая её имитация через ультраартефактизацию (как вы любите и считаете истинно верным), да и навряд ли кто-то вообще фильтрует аниме на BD и современных DVD. Единственная реальная проблема - это олдскульные DVD с букетом соответствующих артефактов, но тут все методы их решения точно такие же как и для любого другого видео на таких DVD, т.к. проблемы по сути одни и те же, хотя уже никто за такие не берётся просто ввиду бессмысленности этого процесса, т.к. всё по тихоньку переиздаётся в более качественном варианте, где максимум что остаётся фиксить, так только рингинг. И уж тем более ни один нормальный аниме-BDрипер не использует mbtree и ни одной настройки в тех значениях, что указаны в --tune animation, равно как и bframes 16, например, а это должно бы было вас заставить хотя бы призадуматься. Как и призадуматься над тем, что я во всех трёх примерах в отличии от вас ворочал только CRF, ref, bframes, psy-rd и qcomp, при этом в первых двух случаях без какой-то очевидной разницы с вашим инкодом, а в третьем так и вовсе утёр вам нос, особенно учитывая что у меня инкод быстрее во всех трёх случаях, более того в двух случаях из трёх я вообще не использовал то, что вы называете "главной фишкой x264, которой не пользуется только идиот", но всё тщетно, вы слишком бронелобы. Собственно, во всех трёх примерах я также могу улучшить свой инкод кодированием в один поток и тогда результаты станут ещё лучше, чем были, при этом это опять же никак не будет противоречить системе - а это ещё один повод вам призадуматься.
Pustovetov, при том что вы ещё ничего не успели доказать уже неоднократно успели повести себя как самоутверждающийся чудак с большой буквы М, неоднократно перешедший как на косвенные так и на прямые оскорбления на пустом месте и продолжающий в том же духе, в связи с чем не вижу смысла продолжать с вами спорить, ибо мы в любом случае оба останемся при своём мнении.
P.S. Таки из этого состязания я сделал вывод, что в статью ещё стоит добавить пару слов о qcomp, aq-strength и threads, за что вам спасибо, но всё равно продолжать общение с вами нет никакого желания.

Неправда. В реальности Вы писали что "mbtree придуман исключительно для оптимизации скорости кодирования, естественно за счёт качества".(c) Хотя в действительности mbtree придуман для улучшения качества, естественно в ущерб скорости кодирования. О чем Вам сообщил, с моей помощью, прямо автор данного алгоритма. Я бы, так облажавшись, во первых бы извинился, признал ошибку; во вторых задумался бы, раз авторы кодека которым я пользуюсь считают что данный алгоритм полезен, то может быть хотя бы иногда он действительно полезен, а не "придуман исключительно для скорости кодирования". Вы же конечно публично врете про "Как написано на x264 settings так и говорил" и продолжаете маниакально выключать mbtree там где надо и не надо. Раз он "для скорости кодирования" то почему бы и не выключать, действительно...
Ровно так же обстоит дело с "при кодировании без mbtree бессмысленно повышать qcomp" и "qcomp - это настройка эффективности mbtree". Вот в результате у Вас получаются "оптимальные настройки" для одного и того же видео то --crf 28 --qcomp 1.00, то --crf 23.9 --qcomp 0.6
Ровно так же обстоит дело с psy-rd. Вы придумали что это "это систематизированный повторяющийся шум, служащий для исправления градиентов и имитации детализированности изображения". И с маниакальным упорством его отключаете. Хотя это НЕ "систематизированный повторяющийся шум".
Ровно так же обстоит дело с "если мы не юзаем psy-rd, то и нет смысла поднимать ref и bframes выше 3/3"(с)
Ровно так же с " --partitions all - актуальная настройка для SD и HD, которая полностью отменяет всякую необходимость в жёстком указании --level 4.1". Это просто шизофазия.
Ровно так же с "ref - настройка, чьё оптимальное значение зависит только от deblock и не зависит от разрешения, фпс или CRF"
и т.п. и т.д. Предсказуемо Вы ничего не смогли написать что такое merange в tesa... Я вполне допускаю что Вы действительно видели "в моих экспериментах... лишь добавляло артефактов". Большинство настроек кодека как-то влияют на распределение ограниченного битрейта т.е. по определению где-то появляются, а где то исчезают артефакты. А далее вопрос интерпретации наблюдаемых изменений. Подобные Вам экспериментаторы шаманят с настройками, но обычно не задаются вопросами - а) что это за настройка, к какому алгоритму она? б) может быть появившийся артефакт это следствие работы другого алгоритма? в) если все же этого, то может быть на других видео будет не так? мое видео чем-то отличается от среднего? г) каков баланс ошибок и профитов? Вы меня раскусили. Это же я писал - "ещё один балабол?", "спорить с упоротыми", "на кую вертел мнение", "человек... не знает ровным счётом ничего", "кроме флуда вы на что-то способны?", "Очередной тупой", "каждый ваш пост от и до - это просто троллинг", "для особо одарённых", "самоутверждающийся чудак с большой буквы М"... Да. Но раз кодируем в 8 бит, то странно не обеспечивать совместимости с железками. В 2 раза. На 25%
Размеры файлов 8657477 vs 6622728. Скриншотики Как хорошо Вам живется в стране эльфов... Единственное что Вы верно написали так это то что действительно обычно риперы отключают mbtree. Потому что при низких квантах профит от него не слишком очевиден и бывают косяки. А с высокими квантами риперы редко кодят.

Pustovetov
Зря вы с ним спорите и тратите время - это бесполезно. Тем более каждый второй, отписавшийся в этой теме, указал на очевидные недостатки его настроек. А он знай свое...
Больше всего улыбныло, что авторитеты и разработчики икса ему ни по чем. Поверхностных знаний нахватался, а что к чему так и не понял...

Уважаемый Bill Ein !
По Вашей методике я получил очень достойные результаты, большое спасибо.
Правда кодирую я ДВД с фильмами 60х-80х годов, а то и 50х, но все равно результат отличный !
По крайней мере теперь можно опираться на какой-то математический критерий, а не на "...рефов много не бывает...".
У меня вопрос. Есть несколько фильмов, которые я бы хотел перевести в 10 бит (из 1080 в 720). Ваша методика так же отработает на 10 битовом х264 ? или есть какие-то скрытые возможности у 10 битов ?
Спасибо.

Подписка

nikolai.zobnin
Тоже интересно познать новую методику, а то я действую по-старинке. Может, что-то новое появилось...

Решил сделать небольшое дополнение к этой статье от Bill Ein после проведения своих экспериментов.
Начну пожалуй с описания настройки ключа --ref
01. Для начала советую изучить эту тему. Теперь разъясню всё конкретно из той темы более подробно. Советую многим пользоваться этой формулой, ведь ref высчитывается по сути для конечного разрешения видео на выходе, а не как пишет автор этой темы Откуда взялась цифра 8388608 в формуле спросите Вы? Дело в том, что эта цифра приведена конкретно для уровня 4 (4.1). Так как же получили эту цифру?
Заходим на следующую страницу, где Вы увидите количество макроблоков для каждого уровня, которые имеют размер 16x16. Так вот, берём цифру 32768 из уровня 4 (4.1) и умножаем на размер макроблоков 16x16, и того получаем 8388608.
Далее мы хотим высчитать ref, допустим, для конечного разрешения 640x480. Сразу скажу, что для такого конечного разрешения уровень 4.1 даст в результате много ref'ов, поэтому из своих подсчётов сразу скажу, что стоит брать расчёт ref'ов для уровня 3.0, в котором количество макроблоков 8.100. Умножаем это количество для начала на размер макроблоков 16x16, и того получаем 2073600. Теперь в нашу формулу вместо 8388608 ставим значение 2073600. Теперь давайте высчитаем ref для конечного разрешения:
2073600 / (640 x 480) = 6,75
Округляем в меньшую сторону и получаем того ref 6.
При кодировании видео уровень 3.0 при ref 6 у меня определился автоматически благодаря настройке --partitions all.
02. Теперь, когда мы высчитали ref, смотрим это:
ТАБЛИЦА РЕКОМЕНДУЕМЫХ ЗНАЧЕНИЙ ОТНОСИТЕЛЬНО ВЫБРАННОГО ПАРАМЕТРА DEBLOCK
Находим в таблице нужное нам количество ref'ов и смотрим соответствующие параметры остальных ключей x264 для него. Меня интересовали значения с применением psy для 8bit, возможно для Вашего видео вовсе и не нужно применять psy, а может даже Вам нужны значения для выходного видео в 10bit, тут уже дело Ваше. Про это уже читайте в шапке этой темы. Только вот crf не обязательно брать такое, как указано в таблице, например для ref 6 в таблице используется crf 16.0 относительно моих выбранных параметров, но я всё же взял значение crf 17.0, как написал автор этой темы про параметр deblock: В данном случае я поднял crf до 17.0 по рекомендации автора темы, которую также подчеркнул в цитате.
03. Про --bframes читайте в шапке этой темы.
04. Скажу теперь про такой ключ x264, как --rc-lookahead. Этот ключ желательно применять при кодировании видео в следующих значениях:
Для выходного видео NTSC - rc-lookahead 60;
Для выходного видео PAL - rc-lookahead 50.
Также для выходного видео NTSC желательно применять ключ --keyint 240. Для выходного видео PAL применять ключ --keyint 250. Для выходного видео PAL настройку --keyint 250 можно не прописывать в параметры кодирования, т.к. это стандартное значение x264.
Также в некоторых случаях полезно применять ключ --qcomp.
05. В итоге я получил такие настройки для видео NTSC: У Вас они могут быть совсем иными.
06. После кодирования видео изучаем его лог. Из лога кодирования нас интересует это: Значение I-фреймов должно быть по правилам не ниже 16.00 согласно этой статье. Но у нас это значение равно 15.80, в итоге скажу, если значение у Вас получилось ниже 16.00, то оно должно быть как можно ближе к значению 16.00, иначе это будет перерасход битрейта. Поэтому, если бы я применил значение crf 16.0 исходя из вышеуказанной таблицы, то значение I-фреймов ещё дальше бы ушло от значения 16.00, примерно могу сказать, что оно было бы где-то в пределах 14.00-15.00. В итоге я остановился на более высокой рекомендации crf 17.0 из приведённой выше цитаты. Значение B-фреймов не должно быть выше 25.00, у нас оно равно 20.02, что соответствует рекомендациям. Тут я уже немного поправлю слова автора темы своими наблюдениями. Бывает так, что такие значения, которые указал автор темы, могут вовсе и не получится. Тогда возникает вопрос "Так как же тогда я найду оптимальные значения?". Вывод совсем прост. У меня минимальным значением оказалось 0.2. После чего я решил прибавить ref и bframes на 1. Но уже с вышеуказанными значениями ref и bframes значения стали увеличиваться. Теперь поясню более детально.
Всё же нам нужна первая строка ref: Смотрим на последнее значение в этой строке, в данном случае 0.2. Но давайте попробуем закодить видео со значениями ref и bframes повыше, у нас может выйти, например, следующее: Как видим, последняя цифра стала выше по значению, чем предыдущая. Поэтому от себя скажу лично, что нужно оставлять такие значения ref и bframes, при которых у Вас окажется так, что одно из значений, будь то в первой строке ref, либо в строке bframes, не будет равным предыдущему значению, либо выше его. Иначе говоря, смело снижайте значения ключей ref и bframes.
Скажу сразу, что подсчёт оптимального значения ref по формуле у меня совпал с подсчётом оптимального значения ref по методу Bill Ein, поэтому ref всё же лучше высчитывать по формуле и не нужно гадать, а вот с bframes всё же придётся потрудиться с подбором по методу Bill Ein.
На этом я закончил свой рассказ. Про остальную информацию, в том числе про 2- и 3-проходное кодирование, читайте в шапке этой темы.