Reddit - трекери - Довідковий посібник для доброго початку x264

Взято з форумів tehconnection

x264 - жорстка коханка. Незважаючи на те, що він в основному використовується для стиснення фільмів, він чомусь дуже оптимізований для аніме-щупальцевого порно. На додачу до цього, немає вбудованого інтерфейсу для початківців, і, схоже, наявна документація існує лише для того, щоб вона могла насміхатись і принижувати пересічну людину. Ну не бійтеся! Незважаючи на те, що я нічого не кодував для сайту, мабуть, більше року, я тут, щоб провести вас через значущі параметри (більшості) x264, щоб ви могли краще кодувати. І як бонус, написання цього дозволить персоналу не понизити мене до класу користувачів, де проживають решта ваших брудних свиней. Отже, без зайвих слів.

Це безпроблемний параметр, який не вимагає тестування, але критично важливий для отримання максимально високої якості, не порушуючи відтворення автономного пристрою (Popcorn Hour, WDTV Live, Roku). Взято безпосередньо з посібника з кодування HD:

Після того, як ви обрізали своє джерело в AvsPmod або будь-якому іншому редакторі скриптів, який ви використовуєте, візьміть рівняння 8388608/(ширина після обрізання x висота після обрізання), ввівши ширину та висоту вашого джерела в те, що, як я сподіваюся, є достатньо очевидним заповнювачами. Візьміть результат і округніть його до найближчого цілого числа. Це номер, який ви повинні використовувати для налаштування --ref.

B-кадри мають достатній контроль над стисливістю (розміром) вашого кодування. Більше фреймів = довший час кодування, але також менший розмір файлу. Але ви не можете точно примусити більше bframes в кодування, якщо x264 вирішить, що вони йому не потрібні. ну, не без використання b-упередження та катастрофічно порушуючих ситуацій. У будь-якому випадку, ідеальну кількість b-кадрів, необхідних для кодування, можна визначити в одному тестовому кодуванні. І під "одиночним" я маю на увазі, що вам потрібно буде скористатися avisynth-фільтром SelectRangeEvery (), щоб захопити кілька тисяч кадрів для тестування за допомогою --bframes 16. x264 виплюне файл журналу, коли кодування тесту буде виконано. Десь у цьому журналі буде рядок, який виглядає так:

x264 [інфо]: послідовні B-кадри: 0,5% 1,1% 3,6% 24,0% 14,4% 43,3% 4,0% 3,4% 1,1% 1,4% 0,5% 0,9% 0,3% 0,3% 0,2% 0,9% 0,1%

Перераховано 17 значень. Кожен із них представляє певну кількість b-кадрів, від 0 до 16. Кожне значення показує відсоток від загальної кількості кадрів, які змогли використати цю кількість послідовних b-кадрів. З цих цифр я зазвичай вибираю найбільший ≥ 1,0%, але робив винятки для значень 0,9%.

Незалежно від того, чи ви вирішите кодувати crf або двопрохідний, цей параметр матиме найбільш значний вплив на загальну якість вашого кодування. З 2-прохідним ви вибираєте бітрейт. За допомогою crf ви вибираєте рівень якості у вигляді чисельного коефіцієнта. Бітрейт/якість буде змінюватися в залежності від того, що ви кодуєте, але в середньому буде дорівнювати вашому введеному для цього значення.

CRF та 2-х прохідні використовують абсолютно однаковий алгоритм, і тому буквально немає переваг у використанні одного над іншим. Якщо кодування crf 20 дає вам середній бітрейт 6000 кбіт/с, 2-прохідне кодування @ 6000 кбіт/с дасть точно таку ж якість. Крім того, журнал першого проходу 2-прохідного кодування дасть вам еквівалентний коефіцієнт швидкості, який можна використовувати для кодування crf.

Знову ж таки, жоден із методів НЕ має переваг. Багато людей віддають перевагу двопрохідності, оскільки не до кінця розуміють, як використовувати наступний параметр, який я перейду. Інші будуть виконувати тестові кодування як з CRF, так і з двома проходами, щоб досягти ідеальної якості. Моїми уподобаннями є CRF, але лише тому, що я вважаю, що бітрейт/розмір файлу повинні бути неактуальними, а якість зображення ніколи не повинна загрожувати. Знову ж таки, все, що я коли-небудь кодував, приблизно 400 Гб.

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

Поки crf та 2-прохідні впливають на загальну якість кодування, qcomp впливає на те, як застосовуються crf та 2-прохідні. Поряд із 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. Вони були визначені найкращим компромісом між якістю та часом кодування, і umh дуже здатний дати таку якість, до якої ви повинні прагнути . Однак для тих, хто має швидше апаратне забезпечення, яке хоче трохи більше якості: --me tesa --merange 16 - останнє слово тут.

aq-mode впливає на те, як застосовується наступний параметр, який ми обговоримо, aq-strength. Вам доступні три варіанти. --aq-mode 2 повинен був замінити режим 1, але це одна з речей, яка, як видається, хоча б трохи була оптимізована для аніме-порно щупалець. Режим 2 повинен краще працювати на джерелах низької якості або тих, у яких дуже мало зерна. Для всього іншого ви захочете використовувати --aq-mode 1. Це не ідеально, але на сьогоднішній день кращої альтернативи немає. Це працює досить добре. Зверніть увагу, що --aq-mode 0 повністю вимикає aq-міцність і ніколи не повинен використовуватися.

У будь-якому даному кадрі x264 надає пріоритет (більший бітрейт) високоякісним макроблокам. aq-сила визначає величину цього пріоритету. 1.00 - за замовчуванням. Все, що перевищує 1,00, все частіше надаватиме все більший пріоритет низькоякісним макроблокам. Нижче ніж 1,00 надасть більший пріоритет якіснішим макроблокам. Як правило, все, що ви кодуєте, повинне мати коефіцієнт aq між 0,50 і 1,30.

Хоча більшість із того, що x264 виконує обробку стиснення в межах даного кадру, mbtree намагається стиснути інформацію між кадрами. Ще один параметр x264, задуманий для покращення стиснення порно аніме щупалець, mbtree - це тверда ідея, яка насправді досить погано працює на більшості якісних джерел живої дії.

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

RC-Lookahead - це ще одна настройка x264, яка безпосередньо впливає на те, скільки кадрів mbtree враховує під час кодування. Це важливо, оскільки mbtree відомий тим, що погано виконує свої дії у зникаючих сценах (вицвітання до або від чорного). Щоб пом'якшити це, я рекомендую використовувати --rc-lookahead 250 буквально у кожному кодуванні, яке ви робите, яке використовує mbtree. Єдиним недоліком цього є те, що якщо ваш комп’ютер має 2 ГБ пам’яті або менше, він буде дещо непридатним під час процесу кодування.

Слід зазначити, що 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-RDO здебільшого стосується лише зіставлення зерна. Для більшості дій в реальному часі, як правило, буде достатньо значення від 0,90 до 1,30. Для більшості анімацій хороший діапазон тестування - від 0,50 до 0,90. Після того, як ви знайшли ідеальне значення пси-рдо вашого джерела, ви можете перевірити пси-решітку. Я рекомендую запустити 6 тестових кодувань з решіткою: 0,05, 0,10, 0,15, 0,20, 0,25 та 0,30. 6 тестових кодувань повинні мати довжину кілька тисяч кадрів, знову ж із використанням SelectRangeEvery (), і їх слід порівнювати з тестовим кодуванням із відключеною системою пси-решітки. Якщо одне з кодувань із увімкненою системою Psy-Trellis виглядає найкраще, залиште це значення Psy-Trellis, але зробіть кілька тестів із незначними змінами в Psy-Rdo.

Deblock згладжує блокування, яке може виникнути в джерелі низької якості або іноді в кодуванні x264 нижчої якості. Деблок складається з двох чисел. Перше число - це сила фільтра деблокування, а друге - поріг, при якому фільтр вирішує, чи є щось блоком або деталлю, яку потрібно зберегти. Як правило, ви повинні використовувати --deblock -3, -3 для всього, що не є джерелом жахливої якості. Ви можете опуститися нижче -3, -3 (до -6, -6), якщо хочете, але я б не рекомендував цього, якщо ви не шанувальник плацебо або ваше телебачення на сьогоднішній день найдорожче, що ви власний.

Додавання --ssim до параметрів x264 може бути корисним для тестових кодувань. Це дасть вам дані про ssim/db, що дасть вам досить точне числове подання вірності щодо вашого джерела. Це число стає більш корисним при порівнянні кількох тестових кодувань і набагато менш корисним, якщо коди (и) використовували psy-rdo якимось чином. Зверніть увагу, що намагаючись досягти візуальної прозорості, db є кращим вибором порівняно з ssim просто тим фактом, що він дотримується лінійної шкали, оскільки наближається до 100% прозорості, тоді як ssim дотримується логарифмічної шкали, яка за дизайном девальвує візуальне покращення, коли ви наближення прозорості.

--vf, також відомий як відеофільтр, - це рання спроба замінити основні avisynth-фільтри на вбудовані до x264 фільтри. Avisynth є важливою частиною кодування відео, але також є значним вузьким місцем з точки зору часу кодування і є єдиною реальною перешкодою, яка не дає кодуванню x264 бути життєздатною на платформах, не пов'язаних з Windows. З практичних цілей я лише обговорюватиму, як використання --vf покращить час кодування:

. дозволить обрізати та/або змінити розмір вихідного відео без необхідності використання сценарію AviSynth. Не використовуйте цей параметр у тестових кодуваннях, лише для повного кодування. Для повного кодування фільму ви скопіюєте будь-які номери обрізання та зміни розміру із тестового сценарію .avs до цього параметра. Обрізання завжди має бути перед зміною розміру. Все, що виходить за дужки, слід залишати незмінним. Значок/призначений для розділення фільтрів обрізання та зміни розміру. Якщо вам не потрібно змінювати розмір вихідного відео, опустіть/та все після нього.

Наведені нижче налаштування на даний момент, мабуть, не заслуговують на поглиблене пояснення, оскільки вони повинні залишатися однаковими для всього, що ви кодуєте:

--проаналізувати всі/--розділи всі Ці два параметри взаємозамінні. Багато веб-сайтів/посібників досі посилаються на цей параметр, згадуючи про сумісність L4.1 (автономний пристрій). І хоча це технічно частина стандарту L4.1, жоден окремий пристрій насправді не дотримується цієї його частини. Іншими словами, ви можете безпечно використовувати --analyse/partitions all на кожному кодуванні і при цьому жодним чином не порушувати відтворення автономного пристрою.

--no-weightb Може допомогти збереженню якості матеріалу CGI. В іншому випадку не використовуйте цей параметр.

Будь ласка, вважайте це (дуже) грубим проектом. Якщо я помилився або щось пропустив, дайте мені знати.

Існує багато параметрів, які ви могли бачити в інших кодуваннях. Більш ймовірно, це були спроби обмежити загальний бітрейт і не внести нічого вагомого в загальне кодування, крім того, щоб уникнути нижчих пристроїв подачі скарг на розмір файлу.

Деякі з запропонованих параметрів діапазонів тестування є досить великими. У більшості з них я вказав, де можна скоротити тестові коди, якщо ти знаєш достатньо про тип джерела, яке ти маєш. В інших я поки що навмисно залишив їх «відкритими». Я та декілька інших працюємо над задуманим проектом з автоматизації тестового кодування x264, і велика частина того, що ми будемо робити найближчим часом, буде спрямована на зменшення діапазону тестування і фактично усунення великої кількості тестових кодувань, необхідних для досягнення візуальної прозорості. Іншими словами, це ПРОЕКТ, тож поки не сукуйся про тестові діапазони.