Haladó x264 kódolási útmutató

Az x264 megismerése

x264 durva úrnő. Annak ellenére, hogy főleg filmek tömörítésére használják, valamilyen oknál fogva nagyon optimalizálták az anime csáp pornó számára. Ráadásul a kezdőknek nincs beépített gui, és a rendelkezésre álló dokumentáció csak úgy tűnik, hogy megcsúfolja és megalázza az átlagembert. Hát ne félj! Annak ellenére, hogy valószínűleg több mint egy évig nem kódoltam semmit a webhelyhez, azért vagyok itt, hogy végigvezetjem az x264 értelmes paramétereinek (nagy részén) keresztül, hogy jobbá válhasson a kódolás terén. Bónuszként pedig ennek megírása megakadályozza, hogy a személyzet engem egy olyan usklassá léptetjen át, ahol a többiek, mocskos disznók laknak. Tehát minden további nélkül ...

Ez egy nem igénylő paraméter, amely nem igényel tesztelést, de kritikus fontosságú a lehető legjobb minőség eléréséhez anélkül, hogy megszakítaná az önálló eszköz lejátszását (Popcorn Hour, WDTV Live, Roku). Közvetlenül a HD kódolási útmutatóból:

Miután levágta a forrását az AvsPmod-ban vagy bármely más használt szkriptszerkesztőben, vegye be a 8388608/egyenletet ((szélesség levágás után x magasság levágás után), és írja be a forrás szélességét és magasságát - remélem, hogy ez elég nyilvánvaló helyőrző. Vegyük az eredményt, és kerekítsük lefelé a legközelebbi egész számra. Ezt a számot kell használni a --ref beállításhoz.

Ha nagyobb számot használ, mint amit a képlet eredményez egy 720p vagy 1080p kódoláshoz, akkor az továbbra is játszani fog, de csak kissé jobban fog kinézni, és önálló eszközökön nem fog lejátszani.

Ha szabványos felbontású (azaz 720p-nél kisebb) felbontásra kódol, kihagyhatja a matematikát, és egyszerűen használhatja a 16-ot a ref számként.

Ne feledje, hogy a kialakítás szerint itt 16-nál nagyobb számot nem használhat.

B-keretek

A B-keretek meglehetősen ellenőrzik a kódolás tömöríthetőségét (méretét). Több bframe = hosszabb kódolási idő, de kisebb fájlméretek is. De nem kényszeríthet pontosan több bframe-et egy kódba, ha az x264 úgy dönt, hogy nincs szüksége rájuk ... nos, anélkül, hogy b-torzítást használna és katasztrofálisan megtörné a dolgokat. Egyébként a kódoláshoz szükséges b-képkockák ideális száma egyetlen tesztkódban meghatározható. „Egyetlen” alatt azt értem, hogy a SelectRangeEvery () avisynth szűrőt kell használnia, hogy megragadjon néhány ezer keretet a --bframe 16 használatával történő teszteléshez. Az x264 kiköp egy naplófájlt, amikor a tesztkódolás elkészült. Valahol ebben a naplóban lesz egy ilyen kinézetű sor:

17 érték szerepel. Mindegyik egy meghatározott számú b-keretet jelent, 0-tól 16-ig. Mindegyik érték megmutatja az összes képkockák százalékos arányát, amelyek képesek voltak felhasználni az egymást követő b-keretek ennyi számát. Ezek közül a számok közül általában a legnagyobbat választom, amely ≥ 1,0%, de kivételt tettem a 0,9% -os értékek alól.

CRF és 2-pass

Akár a crf, akár a 2-pass kódolást választja, ez a beállítás lesz a legjelentősebb hatással a kódolás általános minőségére. A 2-pass-os bitrátát választja. A crf használatával a minőségi szintet számszerű aránytényező formájában választja meg. A bitráta/minőség a kódolás mértékétől függően változik, de átlagértéke a megadott érték értékétől függ.

A CRF és a 2-pass pontosan ugyanazt az algoritmust használja, és szó szerint nincs előnye az egyik használatának a másikkal szemben. Ha egy crf 20 kódolással átlagosan 6000 kbps bitrátát kapunk, akkor egy 2-pass kódolással (6000 kbps) pontosan ugyanolyan minőséget kapunk. Ezenkívül a kétutasos kódolás első lépéséből származó napló megadja az egyenértékű sebességtényezőt, amelyet egy crf kódoláshoz használna.

Ismét NINCS előnye egyik módszernek sem. Sokan a 2-pass-ot részesítik előnyben, mivel nem teljesen értik, hogyan kell használni a következő beállítást, amelyet átmegyek. Mások az ideális minőség elérése érdekében tesztkódolásokat végeznek mind a crf, mind a 2-pass segítségével. A preferenciám véletlenül crf, de csak azért, mert úgy érzem, hogy a bitrátának/fájlméretnek nem kell relevánsnak lennie, és a képminőséget soha nem szabad veszélyeztetni. Aztán megint minden, amit valaha kódoltam, olyan, mint 400 GB ...

A 2-pass/crf ésszerű bitrátája a forrástól és néhány egyéb beállítástól függ. Nem tudok sokat mondani a bitrátáról, de a crf-nek szinte mindig 16 és 23 között kell lennie.

QComp

Míg a crf és a 2-pass befolyásolja a kódolás általános minőségét, a qcomp befolyásolja a crf és a 2-pass alkalmazását. A crf/2-pass mellett ez a legfontosabb x264 paraméter az utolsó kódolás minőségének befolyásolásához. A qcomp mindig 0,0 és 1,0 közötti szám lesz. 0.0-nál a crf száma vagy a 2-pass bitráta állandó bitrátát eredményez az egész kódoláson. 1.0-nál a kódolás bitráta-szórása teljesen nincs korlátozva, így fog repülni, mint egy repedésfüggő óvodás.

Az alapértelmezett érték 0,6, de éles működés esetén 0,7-re, vagy sok gabona-/zajforrás esetén 0,75-re kell ütni. Gyengébb minőségű vagy kevés szemcséjű, rossz minőségű animációhoz vagy sötét filmekhez sok szemcséség nélkül 0,55 vagy 0,5 körüli értéket használhat. Lényegében az életképes qcomp tartomány bármely forrás esetében (nagyjából) 0,45 - 0,75 lesz.

Ez egy olyan beállítás, ahol több érték tesztelése mindenképpen megéri.

ÉN és MERange

A ME (Mozgásbecslés) és a MERange (Mozgásbecslési tartomány) segítenek az x264-nek megjósolni a mozgást a keretek között, és magasabb minőségi szinten tömörítik azon információk alapján, amelyeknek ez a két paraméter lehetővé teszi az összegyűjtését. Minél jobb a mozgásbecslési algoritmus minősége és minél magasabb a mozgásbecslési tartomány, annál nagyobb a minőség. DE ez megnövelt kódolási időt is jelent. Ez a két paraméter növelésével a várakozásoknak megfelelően csökkenő hozamot fog tapasztalni a minőség szempontjából.

Céljaink szempontjából azonban ez a két paraméter halványan egyszerű. Ha számítógépének régebbi/lassabb processzora van, használja a --me umh --merange 24 parancsot. Ezeket a minőség és a kódolási idő közötti legjobb kompromisszumként határozták meg, és az umh nagyon képes arra, hogy olyan minőséget nyújtson, amelyre törekednie kell. Azonban azoknak, akik gyorsabb hardverrel rendelkeznek, és valamivel több minőségre vágynak: --me tesa - merange 16 az utolsó szó itt.

AQ-mód

--Az aq-mód befolyásolja a következő megbeszélés, az aa-erősség alkalmazását. Három lehetőség áll rendelkezésére. Az - aq-mode 2 állítólag az 1. módot váltotta fel, de egyike azoknak a dolgoknak, amelyeket úgy tűnik, hogy legalább kissé optimalizáltak az anime csáp pornó számára. A 2. módnak jobban kell működnie gyengébb minőségű vagy nagyon kevés gabona tartalmú forrásoknál. Minden másra érdemes használni az --aq-mode 1-et. Nem tökéletes, de jelenleg nincs jobb alternatíva. Elég jól működik. Felhívjuk figyelmét, hogy az --aq-mode 0 teljesen letiltja az - aq-szilárdságot, és soha nem szabad használni.

AQ-erősség

Bármely adott keretben az x264 elsőbbséget (nagyobb bitrátát) ad a jobb minőségű makroblokkoknak. --aq-erő határozza meg ennek a prioritásnak a nagyságát. 1.00 az alapértelmezett. Bármi, ami meghaladja az 1,00-at, egyre nagyobb prioritást élvez az alacsonyabb minőségű makroblokkok számára. Az 1,00 alatti értéknél nagyobb prioritást élvez a jobb minőségű makroblokkok. Általában minden általad kódolt értéknek 0,50 és 1,30 közötti erősségűnek kell lennie.

A jobb minőségű és a nagyobb szemcsés/zajszintű források előnyeit élvezhetik az alacsonyabb -aq-szilárdsági értékek.

Az alacsonyabb minőségű forrásoknak, a nem HD forrásoknak stb. Többet kellene profitálniuk a magasabb értékekből.

MBTree

Míg az x264 legtöbbje kezeli a tömörítést egy adott kereten belül, addig az mbtree az információkat keretek között tömöríti. Még egy x264-es paraméter, amelyet az anime csáp pornó tömörítésének javításáról álmodtak meg, az mbtree szilárd ötlet, amely valójában meglehetősen gyengén teljesít a legtöbb kiváló minőségű élőszereplős forrásnál.

Ez a paraméter alapértelmezés szerint engedélyezve van, de a --no-mbtree kapcsolóval kikapcsolható. Az MBTree-t ki kell kapcsolni minden olyan forrásnál, ahol még a szerény mennyiségű gabona/zaj is van. Segíteni fog alacsonyabb minőségű forrásokon, sok DVD-n, minden digitális fényképezőgépen készített felvételen (The Social Network, 9. körzet stb.), De a videomag kissé véletlenszerű jellege miatt jelentősen megnöveli a kódolás bitrátáját, ha a forrás szemcsés/zajos.

Az RC-Lookahead egy másik x264 beállítás, amely közvetlenül befolyásolja, hogy az mbtree hány keretet vesz figyelembe egy kódolás során. Ez fontos, mivel az mbtree rosszul teljesít a jelenetek elhalványulásáról (feketére vagy feketére fakul). Ennek enyhítése érdekében javasoljuk az -rc-lookahead 250 használatát szó szerint minden olyan kódolásnál, amely mbtree-t használ. Ennek egyetlen hátránya, hogy ha számítógépének 2 GB vagy kevesebb memóriája van, akkor kissé használhatatlan lesz a kódolási folyamat során.

Meg kell jegyezni, hogy a qcomp befolyásolja az mbtree alkalmazását, de nem oly módon, hogy az mbtree használata bármilyen módon befolyásolja a qcomp használatával kapcsolatos döntéseit.

Psy-RDO és Psy-Trellis

Ezt a két beállítást egyetlen paraméter vezérli, --psy-rd x.xx: y.yy formátumban. A Psy-RDO x.xx és a Psy-Trellis y.yy A Psy-RDO-t minden olyan forrásnál fel kell használni, amely nem tartalmaz teljes szemcseméretet. A Psy-Trellis egy nehézkes gazember, amely vagy ésszerű bitrátát takaríthat meg, vagy ronthatja a képminőséget.

Technikailag a psy-rdo matematikai szinten csökkenti a képminőséget. De a kódolásra is alkalmaz egy zajszintet oly módon, hogy növelje a videó érzékelt komplexitását. Tekintettel arra, hogy a zaj/szemcsésség egy adott forrásnál kezdetben kissé véletlenszerű, ez valójában jó dolog. Növeli a vizuálisan érzékelt minőségi szintet, miközben lehetővé teszi az általános bitráta/fájlméret csökkentését.

A Psy-rdo azt is feltételezi, hogy a forrást a kép minden képkockáján egyenletesen alkalmazták. A Psy-trellis nem, és hasznos, ha van olyan forrás, ahol a keret részei szemcsésebbek, mint mások. Ha átnézhet egy forrást, és láthatja, hogy a szemcse egyenletesen van kitakarva az egyes képkockákon, akkor valószínűleg jobb, ha a psy-rácsokat kikapcsolja. Ellenkező esetben tesztelje a psy-rácsot.

A Psy-RDO többnyire csak a gabonaillesztésről szól. A legtöbb élő cselekvés esetén általában 0,90 és 1,30 közötti érték elegendő. A legtöbb animáció esetében a 0,50–0,90 jó tesztelési tartomány. Miután megtalálta a forrás ideális psy-rdo értékét, tesztelheti a psy-rácsot. Azt javaslom, hogy futtasson 6 tesztkódot psy rácsokkal: 0,05, 0,10, 0,15, 0,20, 0,25 és 0,30. A 6 tesztkódnak néhány ezer képkocka hosszúnak kell lennie, ismét a SelectRangeEvery () használatával, és össze kell hasonlítani a psy-trellis letiltott tesztkódolással. Ha az egyik kódolás, amelynek engedélyezve van a psy-trellis, a legjobban néz ki, hagyja meg ezt a psy-trellis értéket, de végezzen néhány tesztet a psy-rdo enyhe változtatásával.

Deblock

A Deblock kisimítja a blokkolást, amely egy alacsonyabb minőségű forrásnál vagy esetenként egy alacsonyabb minőségű x264 kódolásnál fordulhat elő. A Deblock két számból áll. Az első szám a blokkoló szűrő erőssége, a második pedig az a küszöb, amelynél a szűrő eldönti, hogy valami blokk vagy részlet-e, amelyet meg kell őrizni. Általában a -deblock -3, -3 parancsot kell használnia mindenre, ami nem egy szörnyű minőségű forrás. Ha akarod, mehetsz -3, -3 (akár -6, -6) alá is, de azt nem javasolnám, hacsak nem rajongsz a placebókért, vagy a televíziód messze a legdrágább dolog, amit saját.

A --ssim hozzáadása az x264 paraméterekhez hasznos lehet tesztkódokhoz. Ez adatokat szolgáltat az ssim/db-ról, amely a hűségnek meglehetősen pontos számszerű ábrázolását adja a forráshoz képest. Ez a szám több tesztkód összehasonlításakor válik hasznosabbá, és sokkal kevésbé hasznos, ha a kódolás (ok) bármilyen módon használta a psy-rdo-t. Kérjük, vegye figyelembe, hogy amikor vizuális átláthatóságot próbál elérni, a db jobb választás az ssim-mel szemben, csupán azért, mert lineáris skálát követ, amint közeledik a 100% -os átlátszósághoz, míg az ssim logaritmikus skálát követ, amely a tervezésével egyre jobban leértékeli a vizuális javulást megközelítés átláthatóság.

--A vf aka video filter egy korai kísérlet az alapvető avisynth szűrők kicserélésére az x264-re beépített szűrőkkel. Az Avisynth a videokódolás kritikus része, de a kódolási idő szempontjából is jelentős szűk keresztmetszetet jelent, és ez az egyetlen igazi akadály, amely megakadályozza az x264 kódolás életképességét a nem Windows platformokon. Gyakorlati célokból csak azt tárgyalom, hogy a --vf használata hogyan javíthatja a kódolási időt:

… Lehetővé teszi a forrásvideó kivágását és/vagy átméretezését AviSynth szkript használata nélkül. Ne használja ezt a paramétert a tesztkódjaiban, csak a teljes kódoláshoz. A teljes filmkódoláshoz az .avs tesztparancsfájlból átmásolhat minden vágási és átméretezési számot ebbe a paraméterbe. A vágásnak mindig átméretezés előtt kell lennie. A zárójeleken kívül bármit meg kell hagyni. A/a levágásra és a szűrők átméretezésére szolgál. Ha nem kell átméreteznie a forrásvideót, hagyja ki a/és mindent utána.

Kisebb beállítások

A következő beállítások egyelőre valószínűleg nem érdemelnek részletes magyarázatot, mivel minden kódolt esetben ugyanazoknak kell maradniuk:

--elemezze az összes/- partíciókat mind - Ez a két paraméter felcserélhető. Sok webhely/útmutató még mindig hivatkozik erre a paraméterre, amikor az L4.1 (önálló eszköz) kompatibilitást említi. És bár ez technikailag az L4.1 szabvány része, valójában egyetlen önálló eszköz sem ragaszkodik ennek a részéhez. Más szavakkal, biztonságosan használhatja az --analízise az összes/--partíciót minden kódolásnál, és még mindig nem szakíthatja meg az önálló eszköz lejátszását.

--no-weightb - Segíthet a CGI-anyagok minőségmegőrzésében. Ellenkező esetben ne használja ezt a paramétert.

Záró megjegyzések

Kérjük, tekintsék ezt (nagyon) durva tervezetnek. Ha hibáztam vagy valamit kihagytam, szólj. Sok olyan paraméter létezik, amelyet más kódokban használhat. Több mint valószínű, hogy megpróbálták korlátozni az általános bitsebességet, és semmi más értékkel nem járultak hozzá a teljes kódoláshoz, azon kívül, hogy megakadályozzák az alsó adagolókat a fájlméret miatt.

A paraméterek által javasolt tesztelési tartományok egy része meglehetősen nagy. Ezek többségében azt adtam meg, hogy hol lehet csökkenteni a tesztkódokat, ha eléggé tud a forrás típusáról. Másokban egyelőre szándékosan hagytam őket „nyitva”. Magam és még sokan egy halottnak gondolt projekten dolgoznak az x264 tesztkódolás automatizálásáért, és a közeljövőben végzett tevékenységeink nagy része a tesztelési tartomány csökkentésére és a nagyszámú szám megszüntetésére irányul. a vizuális átláthatóság eléréséhez szükséges tesztkódok száma. Más szóval, ez egy TERVEZET, ezért egyelőre ne kurva a teszttartományok miatt.