Запознаване с вашия x264

x264 е сурова любовница. Въпреки че се използва предимно за компресиране на филми, той по някаква причина е силно оптимизиран за аниме пипало порно. На всичкото отгоре няма вграден графичен интерфейс за начинаещи и наличната документация изглежда само съществува, за да може да се подиграва и унижава обикновения човек. Ами не се страхувайте! Въпреки че не съм кодирал нищо за сайта от вероятно повече от година, аз съм тук, за да ви преведа през значимите параметри на x264, за да можете да станете по-добри в кодирането. И като бонус, писането на това ще попречи на персонала да ме понижи до потребителски клас, където живеят останалите от вас мръсни свине. Така че, без повече подробности ...

разширено

Това е безпроблемен параметър, който не изисква тестване, но е от решаващо значение за постигане на възможно най-високо качество, без да се нарушава възпроизвеждането на самостоятелно устройство (Popcorn Hour, WDTV Live, Roku). Взето директно от ръководството за HD кодиране:

След като сте изрязали своя източник в AvsPmod или който и да е друг редактор на скриптове, който използвате, вземете уравнението 8388608/(ширина след изрязване x височина след изрязване), като въведете ширината и височината на вашия източник в това, което се надявам да са достатъчно очевидни заместители. Вземете резултата и го закръглете до най-близкото цяло число. Това е номерът, който трябва да използвате за настройката --ref.

Ако използвате число, по-голямо от това, което формулата дава за 720p или 1080p кодиране, то пак ще играе, но ще изглежда само малко по-добре и няма да играе на самостоятелни устройства.

Ако кодирате до стандартна разделителна способност (т.е. по-малка от 720p), можете да пропуснете математиката и просто да използвате 16 като свой номер.

Имайте предвид, че по дизайн тук не можете да използвате число, по-голямо от 16.

B-рамки

B-кадрите имат доста голям контрол върху свиваемостта (размера) на вашия код. Повече bframes = по-дълго време за кодиране, но също така и по-малки размери на файла. Но не можете точно да принудите повече bframes в кодиране, ако x264 реши, че не се нуждае от тях ... е, не без използване на b-bias и катастрофално разбиване на нещата. Както и да е, идеалният брой b-кадри, необходими за кодиране, може да бъде определен в едно тестово кодиране. И под „единичен“ имам предвид, че ще трябва да използвате avisynth филтър SelectRangeEvery (), за да вземете няколко хиляди кадъра, за да тествате с помощта на --bframes 16. x264 ще изплюе регистрационен файл, когато приключи тестовото кодиране. Някъде в този дневник ще има ред, който изглежда така:

Изброени са 17 стойности. Всеки един представлява определен брой b-кадри, от 0 до 16. Всяка стойност показва процента от общия брой кадри, които са успели да използват този брой последователни b-кадри. От тези числа обикновено избирам най-големия ≥ 1,0%, но съм направил изключения за стойности от 0,9%.

CRF и 2-Pass

Независимо дали сте избрали да кодирате crf или 2-pass, тази настройка ще окаже най-съществено влияние върху цялостното качество на кодирането ви. С 2-проход, вие избирате битрейт. С crf избирате ниво на качество под формата на коефициент на цифров процент. Скоростта на предаване/качеството ще варира в зависимост от обхвата на каквото и да е кодирането, но ще се усредни до каквото е било въведеното за тази стойност.

CRF и 2-pass използват абсолютно един и същ алгоритъм и следователно буквално няма предимство да се използва един над друг. Ако crf 20 кодирането ви дава средна битрейт от 6000 kbps, 2-проходното кодиране @ 6000 kbps ще даде точно същото качество. Освен това дневникът от първото преминаване на 2-проходно кодиране ще ви даде еквивалентния коефициент на скорост, който човек би използвал за crf кодиране.

Отново, НЯМА предимство и за двата метода. Много хора предпочитат двупроходни, защото не разбират напълно как да използвам следващата настройка, която ще прегледам. Други ще направят тестови кодове с crf и 2-pass, за да постигнат идеално качество. Предпочитанията ми са crf, но само защото смятам, че битрейтът/размерът на файла трябва да са без значение и качеството на картината никога не трябва да бъде нарушено. Тогава отново всичко, което някога съм кодирал, е като 400 GB ...

Разумните битрейтове за 2-pass/crf ще варират в зависимост от вашия източник и няколко други настройки. Не мога да кажа много за битрейт, но crf почти винаги трябва да е между 16 и 23.

QComp

Докато crf и 2-pass променят цялостното качество на кодирането, qcomp влияе върху начина на прилагане на crf и 2-pass. До crf/2-pass това е най-важният x264 параметър за повишаване на качеството на окончателното ви кодиране. qcomp винаги ще бъде число между 0.0 и 1.0. При 0.0, вашият CRF номер или двупосочен битрейт ще доведе до постоянен битрейт през цялото кодиране. При 1.0 вариацията на битрейт на кодирането е напълно неограничена и така ще се развява като пристрастена към предучилищна възраст.

По подразбиране е 0,6, но за действието на живо трябва да бъде наложено на 0,7 или 0,75 за източници с много зърно/шум. За източници с по-ниско качество с малко или никакво зърно, нискокачествена анимация или тъмни филми без много зърно, можете да опитате около 0,55 или 0,5. По същество жизнеспособният диапазон на qcomp за всеки източник ще бъде (приблизително) 0,45 - 0,75.

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

МЕН и МЕРАНЖ

ME (оценка на движението) и MERange (обхват на оценка на движението) помагат на x264 да предскаже движение през кадрите и да компресира на по-високо ниво на качество въз основа на информацията, която тези два параметъра му позволяват да събере. Колкото по-високо е качеството на алгоритъма за оценка на движението и колкото по-висок е обхватът за оценка на движението, толкова по-голямо е полученото качество. НО това също означава увеличено време за кодиране. Също така, както се очаква, ще започнете да виждате намаляваща възвръщаемост по отношение на качеството, докато увеличавате тези два параметъра.

За нашите цели обаче тези два параметъра са просто прости. Ако компютърът ви има по-стар/по-бавен процесор, използвайте --me umh --merange 24. Те бяха определени за най-добрия компромис между качеството и времето за кодиране и е много способен да даде качеството, към което трябва да се стремите. За тези от вас с по-бърз хардуер, които искат малко повече качество: --me tesa --merange 16 е последната дума тук.

AQ-режим

--aq-mode влияе върху това как се прилага следващата настройка, която ще обсъдим, --aq-сила. Налични са ви три опции. - aq-mode 2 трябваше да замени режим 1, но е едно от онези неща, които изглежда са оптимизирани поне леко за аниме пипало порно. Режим 2 трябва да работи по-добре при източници с по-ниско качество или такива, които имат много малко зърно. За всичко останало ще искате да използвате --aq-mode 1. Не е перфектно, но в момента няма по-добра алтернатива. Работи достатъчно добре. Моля, обърнете внимание, че --aq-mode 0 деактивира --aq-jakoстта изцяло и никога не трябва да се използва.

AQ-сила

Във всеки даден кадър x264 дава приоритет (по-голяма битрейт) на по-висококачествените макроблокове. -aq-сила определя величината на този приоритет. 1.00 е по подразбиране. Всичко над 1.00 все по-често ще дава все по-голям приоритет на по-нискокачествените макроблоки. По-ниско от 1,00 ще даде по-голям приоритет на по-висококачествените макроблоки. По принцип всичко, което кодирате, трябва да има --aq-сила между 0,50 и 1,30.

По-висококачествените източници и източниците с повече зърно/шум ще се възползват от по-ниските стойности на -q-якост.

Източници с по-ниско качество, не-HD източници и т.н. трябва да се възползват повече от по-високите стойности.

MBTree

Докато по-голямата част от това, което x264 обработва компресирането в рамките на даден кадър, mbtree изглежда компресира информация в рамките на кадрите. Още един параметър x264, който е измислен, за да подобри компресията на аниме пипала, mbtree е солидна идея, която всъщност се представя доста зле при повечето по-висококачествени източници на живо.

Този параметър е активиран по подразбиране, но може да бъде изключен с --no-mbtree. MBTree трябва да бъде изключен за всеки източник с дори малко количество зърно/шум. Това ще помогне на източници с по-ниско качество, много DVD-та, всичко, заснето на цифров фотоапарат (социалната мрежа, област 9 и т.н.), но поради донякъде случайния характер на видео зърното, значително ще увеличи битрейта на кодиране, ако източникът е бил зърнест/шумен.

RC-Lookahead е друга настройка на x264, която пряко влияе върху броя кадри, които mbtree взема предвид по време на кодиране. Това е важно, тъй като mbtree е известно, че се представя зле при избледняване на сцената (избледняване към или от черно). За да смекчите това, препоръчвам да използвате --rc-lookahead 250 буквално на всяко кодиране, което правите, което използва mbtree. Единственият недостатък на това е, че ако компютърът ви има 2 GB памет или по-малко, той ще бъде малко неизползваем по време на процеса на кодиране.

Трябва да се отбележи, че qcomp влияе върху начина, по който се прилага mbtree, но не по начин, по който използването на mbtree трябва да повлияе по никакъв начин на решенията ви с qcomp.

Psy-RDO и Psy-Trellis

Тези две настройки се контролират от един параметър, във формата --psy-rd x.xx: y.yy. Psy-RDO е x.xx и Psy-Trellis е y.yy Psy-RDO трябва да се използва на всеки източник, който не е напълно лишен от зърно. Psy-Trellis е тромав гад, който може да спести разумно количество битрейт или да унищожи качеството на картината.

Технически, psy-rdo понижава качеството на картината на математическо ниво. Но той също така прилага слой шум към кодирането по начин, който увеличава възприеманата сложност на видеото. Като се има предвид, че шумът/зърното във всеки даден източник е някак случайно, това всъщност е нещо добро. Той увеличава нивото на визуално възприемано качество, като същевременно позволява да се намали общата скорост/размер на файла.

Psy-rdo също така предполага, че зърното е приложено равномерно през всеки кадър в източника. Psy-trellis не го прави и е полезен, ако имате източник, при който части от рамката са по-зърнести от другите. Ако можете да прегледате източник и да видите, че зърното е покрито равномерно през всеки кадър, вероятно е по-добре да запазите пси-решетката деактивирана. В противен случай трябва да тествате пси-решетка.

Psy-RDO е предимно само за съвпадение на зърната. За повечето действия на живо обикновено е достатъчна стойност между 0,90 и 1,30. За повечето анимации от 0,50 до 0,90 е добър диапазон на тестване. След като откриете идеалната стойност на psy-rdo на вашия източник, можете да тествате psy-trellis. Препоръчвам да изпълните 6 тестови кодирания с пси решетка: 0,05, 0,10, 0,15, 0,20, 0,25 и 0,30. Шестте тестови кодирания трябва да са с дължина няколко хиляди кадъра, като отново се използва SelectRangeEvery (), и трябва да се сравняват с тестови кодове с забранен пси-трелис. Ако един от кодовете с активиран psy-trellis изглежда най-добре, оставете тази стойност на psy-trellis, но направете няколко теста с леки промени в psy-rdo.

Деблокиране

Deblock изглажда блокирането, което може да възникне в източник с по-ниско качество или понякога в кодиране x264 с по-ниско качество. Deblock се състои от две числа. Първото число е силата на деблокиращия филтър, а второто е прагът, при който филтърът решава дали нещо е блок или детайл, който трябва да бъде запазен. Като цяло трябва да използвате --deblock -3, -3 за всичко, което не е източник на ужасно качество. Можете да отидете под -3, -3 (до -6, -6), ако искате, но не бих препоръчал това, освен ако не сте голям фен на плацебо или телевизорът ви е най-скъпото нещо, което собствен.

Добавянето на --ssim към вашите параметри x264 може да бъде полезно за тестови кодирания. Той ще ви даде данни за ssim/db, което ще ви даде доста точно числово представяне на верността по отношение на вашия източник. Този номер става по-полезен при сравняване на множество тестови кодове и много по-малко полезен, ако кодировката (ите) използва пси-рдо по някакъв начин. Моля, обърнете внимание, че когато се опитвате да постигнете визуална прозрачност, db е по-добър избор пред ssim, просто поради факта, че следва линейна скала, тъй като се доближава до 100% прозрачност, докато ssim следва логаритмична скала, която по дизайн обезценява визуалното подобрение все повече, докато вие подход към прозрачността.

--vf, известен още като видео филтър, е ранен опит за подмяна на основните avisynth филтри с филтри, вградени в x264. Avisynth е критична част от видео кодирането, но също така и значителна пречка по отношение на времето за кодиране и е единственото истинско препятствие, което предотвратява жизнеспособността на x264 кодирането на не-Windows платформи. За практически цели ще обсъдя само как използването на --vf ще подобри времето за кодиране:

ще ви позволи да изрежете и/или да преоразмерите изходния си видеоклип, без да е необходимо да използвате скрипт AviSynth. Не използвайте този параметър в тестовите кодове, само за пълното кодиране. За пълното кодиране на филм ще копирате всички числа за изрязване и преоразмеряване от тестовия скрипт .avs в този параметър. Подрязването винаги трябва да бъде преди преоразмеряване. Всичко извън скобите трябва да остане същото./Е за разделяне на филтрите за изрязване и преоразмеряване. Ако не е необходимо да преоразмерявате изходния видеоклип, пропуснете/и всичко след него.

Незначителни настройки

Засега следните настройки вероятно не заслужават задълбочено обяснение, тъй като те трябва да останат същите за всичко, което кодирате:

--анализира всички/--разделя всички - Тези два параметъра са взаимозаменяеми. Много сайтове/ръководства все още се позовават на този параметър, когато споменават съвместимостта на L4.1 (самостоятелно устройство). И докато технически е част от стандарта L4.1, нито едно самостоятелно устройство всъщност не се придържа към тази част от него. С други думи, можете безопасно да използвате --analyse all/--partitions all на всяко кодиране и пак да не нарушавате възпроизвеждането на самостоятелно устройство по никакъв начин.

--no-weightb - Може да помогне за запазване на качеството на CGI материал. В противен случай не използвайте този параметър.

Заключителни бележки

Моля, считайте това за (много) груба чернова. Ако съм сгрешил или съм пропуснал нещо, уведомете ме. Има много параметри, които може да сте виждали използвани в други кодове. Повече от вероятно това бяха опити за ограничаване на общия битрейт и не допринесоха нищо ценно за цялостното кодиране, освен да не позволят на долните подавачи да се оплакват от размера на файла.

Някои от препоръчваните от параметрите диапазони на тестване са доста големи. В повечето от тях съм посочил къде можете да намалите тестовите кодове, ако знаете достатъчно за вида източник, който имате. В други умишлено съм ги оставил за момента „отворени“. Аз и няколко други работим по проект, който трябва да умрем, за да автоматизираме тестовото кодиране x264 и голяма част от това, което ще правим в близко бъдеще, ще бъде насочено към намаляване на обхвата на тестване и на практика елиминиране на голям брой на тестови кодове, необходими за постигане на визуална прозрачност. С други думи, това е ПРОЕКТ, така че все още не се занимавайте с тестовите диапазони.