Egy gyakran feltett kérdés: "Hogyan készíthetem el a legjobb minőségű DVD rip-et egy adott méretben?" Vagy: "Hogyan készíthetem el a lehető legjobb minőségű DVD rip-et? Nem érdekel a fájl méret, csak a legjobb minőséget akarom." Az utóbbi kérdés talán kicsit rosszul van megfogalmazva. Hiszen ha nem érdekel a fájl méret, akkor miért nem másolod át az egész MPEG-2 videó stream-et a DVD-ről egy az egyben? Az AVI fájlod 5GB körül fogja végezni, fogd és vidd, de ha a legjobb minőséget akarod és nem érdekel a méret, akkor biztos, hogy ez lesz a legjobb lehetőséged. Valójában egy DVD MPEG-4-be történő átkódolásának az oka pont az, hogy érdekel a fájl mérete. Nehéz egy általános receptet adni a jó minőségű DVD rip-ek készítéséhez. Számos szempontot figyelembe kell venni és meg kell értened ezeket a részleteket, különben elégedetlen leszel a végeredménnyel. Kicsit körbejárjuk ezen dolgok közül néhányat és utána példát is adunk. Feltételezzük, hogy a libavcodec-et használod a videó kódolásához, habár az elmélet bármilyen codec-kel használható. Ha ez túl sok neked, akkor talán jobb, ha a sok nagyszerű frontend valamelyikét használod, amik fel vannak sorolva a kapcsolódó projektek oldalán a MEncoder részben. Így nagyon jó minőségű rip-eket készíthetsz túl sok gondolkodás nélkül, mert ezen eszközök legtöbbje úgy lett megtervezve, hogy jó döntéseket hozzon. Mielőtt eszedbe jutna bármiféle film átkódolása, meg kell tenned pár előkészületi lépést. Az első és legfontosabb lépés a kódolás előtt annak megállapítása, hogy miféle anyaggal van egyáltalán dolgod. Ha a forrás anyagod DVD-ről származik vagy sugárzott/kábeles/műholdas TV, a következő két formátum valamelyikében tárolódik: NTSC Észak Amerikában és Japánban, PAL Európában. Fontos tudatosítani, hogy ez csak a televízión történő megjelenítés formátuma és gyakran nincs összhangban a film eredeti formátumával. A tapasztalatok szerint az NTSC tartalmat sokkal nehezebb elkódolni, mert több elemet kell azonosítani a forrásban. Ahhoz, hogy megfelelő legyen a kódolás, ismerned kell az eredeti formátumot. Ennek elmulasztása esetén különböző hibák lesznek a kódolásodban, csúnya törési (átlapolás) mellékhatások, duplázott vagy akár elveszett képkockák. Mindamellett, hogy csúnya, a mellékhatások rontják a kódolási hatékonyságot is: rosszabb minőség per bitráta egység arányt kapsz. Itt van egy lista a forrás anyagok által általában használt típusokról, ebben valószínűleg megtalálod a tiédet és annak jellemzőit: Szabványos film: Moziban történő vetítéshez rögzítették 24 fps-sel. PAL videó: PAL videókamerával rögzítették 50 mező per másodperc sebességgel. Egy mező csak a képkocka páros vagy páratlan sorszámú sorait tartalmazza. A televíziót úgy tervezték meg, hogy ilyen arányban frissítsen, az analóg tömörítés egy olcsó formájaként. Az emberi szemnek ezt kompenzálnia kellene, de ha egyszer megérted az átlapolást, meg fogod látni a TV-n és soha többé nem fogod élvezni a TV adást. Két mező még nem alkot egy teljes képkockát, mert 1/50 másodpercnyire vannak egymástól időben és így csak mozgásnál igazodnak össze. NTSC Videó: NTSC kamerával felvett, 60000/1001 mező per másodperc vagy a színek előtti időben 60 mező per másodperc sebességű film. Egyébként hasonló a PAL-hoz. Animáció: Általában 24fps-sel rajzolják, de található kevert-framerátás változat is. Számítógépes grafika (CG): Bármilyen framerátával mehet, de van pár, ami gyakoribb a többinél; 24 és 30 képkocka per másodpercesek a tipikusak NTSC-nél és 25fps PAL-nál. Régi film: Különböző alacsony frameráták. A képkockákból álló filmekre progresszívként szoktak hivatkozni, míg az egymástól független mezőkből állóakra vagy átlapoltként vagy videóként - bár ez utóbbi félreérthető. További bonyolításként néhány film a fenti kettő keveréke. A legfontosabb különbség, amit észre kell venni a két formátum között, hogy van, amelyik képkocka-alapú míg mások mező alapúak. Bármikor, ha egy filmet televíziós megjelenítésre készítenek elő (beleértve a DVD-t is), átkonvertálják mező-alapú formába. A különböző módszereket, amikkel ez végrehajtható, gyűjtőnéven "telecine"-nek hívjuk, ennek egyik változata a hírhedt NTSC-s "3:2 pulldown". Hacsak nem volt az eredeti anyag is mező-alapú (és megegyező mező rátájú), más formátumbú lesz a filmed, mint az eredeti. PAL 2:2 pulldown: Az összes közül a legjobb. Minden képkocka két mező idejéig látszódik, úgy, hogy a páros és páratlan sorokat kinyeri belőlük és váltakozva mutatja őket. Ha az eredeti anyag 24fps-es, ez az eljárás felgyorsítja a filmet 4%-kal. PAL 2:2:2:2:2:2:2:2:2:2:2:3 pulldown: Minden 12. kockát három mező hosszan mutat kettő helyett. Ezzel elkerüli a 4%-os gyorsulást, de sokkal nehezebben megfordíthatóvá teszi a folyamatot. Általában musical készítésénél használják, ahol a 4%-os sebességmódosulás komolyan rontaná a zenei jelet. NTSC 3:2 telecine: A kockák felváltva 3 vagy 2 mezőnyi ideig látszódnak. Ezáltal a mező ráta 2.5-szöröse lesz az eredeti framerátának. Az eredmény nagyon kis mértékben lelassul, 60 mező per másodpercről 59.94 mező per másodpercre, az NTSC mező ráta megtartása miatt. NTSC 2:2 pulldown: A 30fps-es anyagok NTSC-n történő megjelenítéséhez használják. Szép, csakúgy, mint a 2:2 PAL pulldown. Vannak még egyéb módszerek az NTSC és a PAL videó közötti konvertáláshoz, de ez a téma meghaladja ezen leírás célkitűzéseit. Ha ilyen filmbe futsz bele és el szeretnéd kódolni, a legjobb, ha keresel egy másolatot az eredeti formátumban. A két formátum közötti konvertálás nagyon romboló hatású és nem lehet teljesen visszafordítani, így a kódolt adatod nagyon megszenvedi, ha már konvertált forrásból készül. Ha a videó DVD-n van, az egymást követő mezők képkockává csoportosíthatóak, még akkor is, ha nem egyidejű megjelenítésre tervezték őket. A DVD-n és digitális TV-n használt MPEG-2 szabvány lehetőséget nyújt mind az eredeti progresszív kockák elkódolására, mind pedig arra, hogy azon mezők számát, amelyhez egy képkockát meg kell jeleníteni, az adott képkocka fejlécében tárolhassuk. Ha ezt a módszert használják, a filmet gyakran "soft-telecined"-ként jellemzik, mert ez az eljárás csak utasítja a DVD lejátszót a pulldown alkalmazására a film tényleges megváltoztatása helyett. Ez a lehetőség nagyon preferált, mert könnyen visszafordítható (tulajdonképpen kihagyható) a kódoló által és megtartja a maximális minőséget. Bár sok DVD és műsorszóró stúdió nem használ megfelelő kódolási technikát, hanem inkább "hard telecine"-es filmeket alkalmaznak, ahol a mezők tulajdonképpen duplázva vannak az elkódolt MPEG-2-ben. Az eljárás, ahogy ezeket az eseteket kezelni kell, később kerül leírásra ebben az útmutatóban. Most következzék pár tanács, amik segítségével eldöntheted, hogy milyen anyaggal van dolgod: Ha az MPlayer azt írja ki, hogy a frameráta megváltozott 24000/1001-re a film nézése közben, és soha nem vált vissza, akkor majdnem biztosan progresszív tartalomról van szó, amit "soft telecine" eljárásnak vetettek alá. Ha az MPlayer a frameráta oda-vissza váltakozását mutatja 24000/1001 és 30000/1001 között és "hullámzást" látsz ilyenkor, akkor több lehetőség is van. A 24000/1001 fps-es részek majdnem biztosan progresszív tartalmak, "soft telecine"-ltek, de a 30000/1001 fps-es részek lehetnek vagy hard-telecine-lt 24000/1001 fps-esek vagy 60000/1001 mező per másodperces NTSC videók. Kövesd a következő két esetben leírt irányelveket, hogy el tudd dönteni, valójában melyik formátummal van dolgod. Ha az MPlayer soha nem mutatja a frameráta változást és minden egyes mozgást tartalmazó kocka hullámosnak tűnik, akkor a filmed NTSC videó 60000/1001 mező per másodperc sebességgel. Ha az MPlayer soha nem mutatja a frameráta változást és minden ötből két kocka hullámosnak tűnik, akkor a filmed "hard telecine"-s 24000/1001fps-es formátumú. Ha sosem látsz hullámzást, akkor a filmed 2:2 pulldown-os. Ha hullámzást látsz váltakozóan ki-be minden fél másodpercben, akkor a filmed 2:2:2:2:2:2:2:2:2:2:2:3 pulldown-os. Ha mindig látsz hullámzást a mozgás közben, akkor a filmed PAL videó 50 mező per másodperces sebességgel. Az MPlayer le tudja lassítani a lejátszást a -speed kapcsolóval vagy a kockáról-kockára történő lejátszással. Próbáld meg használni a -speed 0.2-t, hogy nagyon lassan nézhesd a filmet vagy nyomogasd a "." gombot a kockáról kockára történő lejátszáshoz és azonosítsd a mintákat, ha nem látod meg teljes sebességnél. Nagyon sokféle minőségben tudod elkódolni a filmedet. A modern videó kódolókkal és egy kis pre-codec tömörítéssel (leméretezés és zajcsökkentés), lehetséges nagyon jó minőség elérése 700 MB-on, egy 90-110 perces szélesvásznú filmnél. Továbbá minden, kivéve a leghosszabb filmeket, elkódolható majdnem tökéletes minőséggel 1400 MB-ba. Három féle megközelítése van egy videó kódolásának: konstans bitráta (CBR), konstans kvantálás, és többmenetes (ABR vagy átlagos bitráta). Egy film képkockáinak komplexitása és így a tömörítéshez szükséges bitek száma nagy mértékben változhat jelentről jelenetre. A modern videó kódolók már alkalmazkodnak az igényekhez a bitráta variálásával. Az egyszerű módokban, mint pl. a CBR, a kódolók nem ismerik az elkövetkező jelenetek bitráta igényét és így nem tudják átlépni az igényelt átlagos bitrátát hosszabb időre. A fejlettebb módokban, mint pl. a több lépéses kódolásnál, már figyelembe lehet venni az előző lépés statisztikáját; ez megoldja a fent említett problémát. A legtöbb ABR kódolást támogató codec csak a két lépéses kódolást támogatja, míg néhány másik, mint pl. az x264, az Xvid és a libavcodec támogatják a többmenetest, ami kissé javít a minőségen minden lépésben, bár ez a javulás nem mérhető és nem is észrevehető a 4. lépés után. Ezért, ebben a részben a két lépéses és a többmenetes felváltva értelmezhető. Ezen módok mindegyikében a videó codec (mint pl. a libavcodec) a videó képkockákat 16x16 pixel nagyságú macroblock-okra osztja, majd egy kvantálást végez mindegyik macroblock-on. Minél alacsonyabb a kvantálás, annál jobb a minőség és nagyobb a bitráta. A film kódolók által egy adott macroblockhoz a megfelelő kvantáló kiválasztására használt módszer változó és nagymértékben tuningolható. (Ez egy extrém túl-egyszerűsítése a tulajdonképpeni folyamatnak, de az alap koncepciót hasznos megérteni.) Ha előírsz egy konstans bitrátát, a videó codec elkódolja a videót, figyelmen kívül hagyva a részleteket amennyire csak lehetséges és a legkisebb mértékben, amennyire szükséges, hogy a megadott bitrátánál alacsonyabban maradjon. Ha tényleg nem érdekel a fájl méret, használhatsz CBR-t és megadhatsz egy bitrátát vagy hagyhatod határozatlanul. (A gyakorlatban ez egy kellően magas értéket jelent, ami nem szab gátat, pl. 10000Kbit.) Ha nincs különösebb megkötés a bitrátára vonatkozóan, az eredmény az lesz, hogy a codec a lehető legalacsonyabb kvantálást fogja használni minden egyes macroblock-hoz (amint ez a vqmin-ben meg van adva a libavcodecnél, alapértelmezésként 2). Amint előírsz egy megfelelően alacsony bitrátát, ami a codecet magasabb kvantálás használatára kényszeríti, majdnem biztos, hogy rontod a videód minőségét. Ahhoz, hogy ezt elkerüld, valószínűleg downscale-t kell végrehajtani a videón, az alábbiakban szereplő módszernek megfelelően. Általában igaz, hogy jobb ha kerülöd a CBR-t, ha számít a minőség. Konstans kvantálással a codec ugyan azt a kvantálót használja, amit a vqscale kapcsolóval megadtál (a libavcodecnek), minden macroblock-nál. Ha a lehető legjobb minőségű rip-et szeretnéd, szintén a bitráta kihagyásával, használhatod a vqscale=2 kapcsolót. Ez ugyan azt a bitrátát és PSNR-t (peak signal-to-noise ratio) szolgáltatja, mint a CBR a vbitrate=végtelen kapcsolóval és a alapértelmezett 2-es vqmin-nal. A konstans kvantálás problémája, hogy a megadott kvantálót alkalmazza, akár szükséges a macroblock-hoz, akár nem. Lehet, hogy használható lenne egy nagyobb kvantálás is a mackroblock-on a vizuális minőség feláldozása nélkül is. Miért pazarolnánk a biteket szükségtelenül alacsony kvantálóra? A CPU-d annyi ciklusa lehet, amennyi időd csak van, de a merevlemezed véges. Két lépéses kódolásban az első lépés úgy rip-eli a filmet, mintha CBR lenne, de megtartja a tulajdonságok listáját minden egyes képkockánál. Ezeket az adatokat használja fel aztán a második lépésben a használni kívánt kvantálót meghatározó intelligens döntésekben. Gyors akciónál vagy nagyon részletes jeleneteknél magasabb kvantálót használ, lassú mozgásnál vagy kevésbé részletes jeleneteknél alacsonyabbat. Általában a mozgás mennyisége sokkal fontosabb, mint a részletesség. Ha használod a vqscale=2 kapcsolót, akkor biteket pazarolsz. Ha a vqscale=3 kapcsolót adod meg, akkor nem a legjobb minőségű rip-et kapod. Tegyük fel, hogy egy DVD-t rip-elsz vqscale=3-mal, és az eredmény 1800Kbit. Ha két lépéses kódolást csinálsz vbitrate=1800 kapcsolóval, az kimeneti videó jobb minőségű lesz ugyanolyan bitrátával. Mivel most meggyőződtél róla, hogy a két lépéses kódolás a megfelelő módszer, az igazi kérdés az, hogy milyen bitrátát ajánlott használni? A válasz az, hogy nincs egyszerű válasz. Valószínűleg olyan bitrátát akarsz választani, ami a legjobb egyensúlyt biztosítja a minőség és a fájl méret között. Ez viszont a forrás videótól függően változik. Ha a méret nem számít, egy jó kiindulási pont minden nagyon jó minőségű rip-hez egy 2000Kbit körüli érték, plusz-mínusz 200Kbit. A gyors akciókhoz és a nagy részletességű videókhoz vagy ha sas szemed van, akkor választhatsz 2400-at vagy 2600-at. Néhány DVD-nél nem fogsz különbséget felfedezni 1400Kbit-en sem. Jó ötlet az egyes fejezeteket különböző bitrátával megnézni, hogy meglásd a különbséget. Ha egy bizonyos méretet céloztál be, valahogy ki kell számítanod a bitrátát. De ezelőtt azt kell megtudnod, hogy mennyi helyet kell fenntartanod az audió sáv(ok)nak, így először ezeket kell lerippelned. A következő egyenlettel tudod kiszámítani a bitrátát: bitráta = (cél_méret_Mbyteokban - hang_mérete_Mbyteokban) * 1024 * 1024 / hossz_másodpercben * 8 / 1000 Például egy két órás film 702 Mbájtos CD-re való összenyomásához, 60 Mbájtnyi hang sávval, a videó bitrátájának (702 - 60) * 1024 * 1024 / (120*60) * 8 / 1000 = 740kbps-nek kell lennie. Az MPEG-típusú tömörítés természetéből adódóan számos megszorítás van, amit követned kell a maximális minőség érdekében. Az MPEG 16x16 makroblokknak nevezett négyzetre osztja fel a videót, mindegyik 4 darab 8x8 blokk luma (intenzitás) információt és két fél-felbontású 8x8 chroma (szín) blokkot tartalmaz (egy a vörös-világoskék tengelyen, a másik a kék-sárga tengelyen). Ha a film szélessége és magassága nem 16 többszöröse, a kódoló akkor is elegendő 16x16-os makroblokkot fog használni, hogy lefedje a teljes képet, a maradék hely veszendőbe megy. Így ha a minőség maximalizálása a cél egy fix fájl mérettel, akkor eléggé rossz ötlet nem 16 valamelyik többszörösét használni méretként. A legtöbb DVD-n van valamekkora fekete sáv a sarkokban. Ha ezeket békén hagyod, akkor több módon is nagyon rontják a minőséget. Az MPEG-típusú tömörítés nagyban függ a frekvencia tartományok transzformálásától is, általában a Diszkrét Koszinusz Transzformációt (DCT) használják, ami hasonló a Fourier transzformációhoz. Ez a fajta kódolás hatékony a minták és a sima átmenetek átalakításához, de nehezen bírkózik meg az éles élekkel. Ezek elkódolásához sokkal több bitre van szüksége, különben egy gyűrűsödésnek nevezett mellékhatás jelenik meg. A frekvencia transzformáció (DCT) külön hajtódik végre minden egyes makroblokkon (tulajdonképpen minden blokkon), így ez a probléma csak akkor jelentkezik, ha az éles él a blokkon belül van. Ha a fekete határ épp olyan pixel határon kezdődik, ami 16 többszöröse, akkor nincs probléma. Habár a fekete határok a DVD-ken ritkán vannak szépen eligazítva, így a gyakorlatban majdnem mindig vágni kell, hogy elkerüld ez a büntetést. A frekvencia tartományok kódolása mellett az MPEG-típusú tömörítés mozgó vektorokat használ a képkockák közötti változások ábrázolásához. A mozgó vektorok természetesen kevésbé hatékonyak a sarkokból érkező új tartalomnál, mert az még nincs jelen az előző képkockán. Amíg a tartalom a sarkok felé terjed ki, a mozgó vektoroknak nincs problémájuk a tartalom kifelé mozgásával. Habár a fekete határok megjelenésekor lehetnek gondok: Minden egyes makroblokknál az MPEG-típusú kódolás egy vektort is eltárol, mely azt mondja meg, hogy az előző képkocka melyik részét kell átmásolni ebbe a makroblokkba a következő kocka megbecsléséhez. Csak a megmaradt különbséget kell elkódolni. Ha a makroblokkot kettéosztja a kép széle és a fekete sáv, akkor a kép többi részének mozgó vektorai felül fogják írni a fekete sávot. Ez azt jelenti, hogy sok bitet kell elpazarolni vagy a határ felülírt részének újrafeketítéséhez vagy (inkább) a mozgó vektor nem kerül felhasználásra és így a makroblokk összes változását expliciten el kell kódolni. Mindkét esetben jelentősen romlik a kódolás hatékonysága. Ez a probléma szintén csak akkor jelentkezik, ha a fekete sáv nem 16 többszörösű pixel-határon van. Végül tegyük fel, hogy van egy makroblokkunk a kép belsejében és egy objektum mozog be ebbe a blokkba a kép sarka felől. Az MPEG-típusú kódolás nem tudja azt mondani, hogy "másold át azt a részt, ami a kép belsejében van, de a fekete sávot ne". Így a fekete sáv is átmásolódik és így rengeteg bitet kell feláldozni a kép ott lévő részének újrakódolásához. Ha a kép tovább fut az elkódolt terület sarka felé, az MPEG-nek speciális optimalizációi vannak az kép szélén lévő pixelek ismétlődő másolására, ha a mozgó vektorok a kódolt területen kívülről jönnek. Ez a tulajdonság haszontalanná válik, ha a filmen fekete sávok vannak. Az első két problémával ellentétben itt nem segít a 16 többszörösére való igazítás. Habár a sávok teljesen feketék és soha nem változnak, mindenképpen egy kis plusz munkát igényelnek, mivel több macroblokk van. A fenti okok miatt javasolt, hogy teljesen vágd le a fekete sávokat. Továbbá ha a kép sarkainál zaros/torz rész van, ennek a levágása is javít a kódolási hatékonyságon. A keményvonalas videósok, akik az eredeti tartalmat akarják megtartani, amennyire csak lehet, biztos tiltakozni fognak ez ellen, de ha nem tervezed konstant kvantálás használatát, akkor a vágás miatt nyert minőségjavulás jelentősen nagyobb lesz, mint a sarkok levágása miatti információvesztés. Emlékezz rá az előző fejezetből, hogy a végső képméret, amibe kódolsz, 16 többszöröse ajánlott, hogy legyen (mind szélességben, mind magasságban). Ezt vágással, méretezéssel vagy ezek kombinációjával érheted el. Vágásnál van egy pár ökölszabály, amit jó ha betartasz, ha nem akarsz kárt tenni a filmben. A normál YUV formátum 4:2:0, a chroma (szín) információkat almintaként tárolja, pl. a chroma csak fele annyiszor kerül mintázásra minden irányban, mint a luma (intenzítás) információk. Tanulmányozd ezt a diagramot, ahol L jelenti a luma mintázási pontokat és C a chroma-kat! L L L L L L L L C C C C L L L L L L L L L L L L L L L L C C C C L L L L L L L L Amint láthatod, a kép sorai és oszlopai természetszerűleg párokba rendeződnek. Így a vágási eltolásodnak és a méreteidnek páros számoknak kell lenniük. Ha nem, akkor a chroma nem fog rendes sort alkotni a luma-val. Elméletben lehetséges a vágás páratlan eltolással, de ehhez a chroma újramintázása szükséges, ami egy veszteséges művelet és nem is támogatja a vágó szűrő. Továbbá az átlapolt videót a következőképpen mintázzák: Top field Bottom field L L L L L L L L C C C C L L L L L L L L L L L L L L L L C C C C L L L L L L L L L L L L L L L L C C C C L L L L L L L L L L L L L L L L C C C C L L L L L L L L Amint láthatod a minták nem ismétlődnek meg a 4 sor után. Így az átlapolt videóhoz a vágás y-eltolásának és a magasságának 4 többszörösének kell lennie. A natív DVD felbontás 720x480 NTSC-vel és 720x576 PAL-lal, de van egy arányjelző is, ami megmutatja, hogy teljes képernyős (4:3) vagy széles vásznú (16:9). Sok (ha nem az összes) széles képernyős DVD nem szigorúan 16:9-es, vagy 1.85:1-hez vagy 2.35:1-hez (cinescope). Ez azt jelenti, hogy fekete sávok lesznek a videón, amit le kell vágni. Az MPlayer rendelkezik egy crop detection szűrővel, ami megállapítja a levágandó téglalapot (-vf cropdetect). Futtasd az MPlayert a -vf cropdetect kapcsolóval és kiírja a vágási beállításokat a határok eltávolításához. A filmet elegendő ideig kell engedned futni ahhoz, hogy legyen teljesen lefedett kép és helyes vágási eredményeket kapj. Ezután teszteld le a kapott értékeket az MPlayerrel, felhasználva a cropdetect által kiírt parancssort és állíts a téglalapon, ha szükséges. A téglalap szűrő segít neked a vágási téglalap filmen való, interaktív módon történő elhelyezésében. Emlékezz, és kövesd a fenti oszthatósági ökölszabályokat, nehogy félreigazítsd a chroma plane-eket. Bizonyos esetekben a méretezés nem kívánatos. A méretezés függőleges irányban nehéz átlapolt videónál és ha meg akarod őrizni az átlapoltságot, tartózkodnod kell a méretezéstől. Ha nem fogsz méretezni, de 16 többszörösét akarod használni képméretként, túl kell vágnod a filmet. Ne vágj kisebbet, mert a fekete szélek nagyon rosszak kódoláskor! Mivel az MPEG-4 16x16-os macroblock-okat használ, meg kell győződnöd róla, hogy a kódolt videó mindegyik dimenziója 16 többszöröse-e, különben rontod a minőséget, különösen alacsony bitrátánál. Ezt megteheted a levágandó terület szélességének és magasságának 16 legközelebbi többszörösére való kerekítésével. Amint az már szerepelt korábban, vágásnál növelni szeretnéd az y-offszetet a régi és az új magasság közötti különbség felével, így a keletkező videó elmozdul a kép középpontjából. A DVD videó mintavételezési módja miatt meg kell győződnöd róla, hogy az offszet páros szám-e. (Valójában íratlan szabály, hogy soha ne használj páratlan értékeket semmilyen paraméternek se, ha vágsz vagy méretezel egy videót.) Ha nem akarsz pár extra pixelt eldobni, akkor a videó méretezését kell megfontolnod inkább. Ezt nézzük meg a következő példánkban. Tulajdonképpen engedélyezheted a cropdetect szűrőnek, hogy ezt az egészet megcsinálja helyetted, mivel van egy opcionális kerekítési paramétere, ami alapértelmezésként 16. Szintén figyelned kell a "félfekete" pixelekre a sarkokban. Győződj meg róla, hogy ezeket szintén levágtad, különben olyan biteket pazarolsz el ott, amiket máshoz jobban felhasználhatnál. Miután mindent elmondtunk és kész, valószínűleg olyan videót kapsz, aminek a pixeljei nem éppen 1.85:1 vagy 2.35:1 arányúak, de legalább valami hasonló. Az új képarányt kiszámíthatod kézzel is, de a MEncoder rendelkezik egy kapcsolóval a libavcodechez, amit autoaspect-nek hívnak, ami megcsinálja ezt neked. Ne méretezd át ezt a videót a pixelek négyszögletesítéséhez, hacsak nem akarod pazarolni a helyet a merevlemezeden. A méretezés történhet lejátszáskor, és a lejátszó az AVI-ban tárolt arányt fogja használni a megfelelő felbontás megállapításához. Sajnos nem minden lejátszó teszi kötelezővé ezt az auto-méretezési információt, ezért lehet, hogy mégis átméretezésre kényszerülsz. Ha nem konstans kvantálási módban fogsz kódolni, akkor meg kell adnod a bitrátát. A bitráta koncepciója elég egyszerű. A filmed tárolására másodpercenként felhasznált bitek (átlagos) száma. Normális esetben a bitrátát kilobit (1000 bit) per másodpercben mérik. A filmed mérete a lemezen egyenlő a bitráta és a film hosszának szorzatával, plusz egy kis "túlterheléssel" (lásd az AVI konténert például). Az egyéb paraméterek, mint a méretezés, vágás, stb. nem változtatják meg a fájl méretét, amíg nem változtatsz a bitrátán is. A bitráta nem aránylik a felbontáshoz. Ezért mondhatjuk, hogy egy 320x240-es fájl 200 kbit/sec-kel nem lesz ugyan olyan minőségű, mint ugyan az a film 640x480-ban, 800 kbit/sec-kel! Ennek két oka van: Érzékelhető: Jobban észreveszed az MPEG hibáit ha fel vannak nagyítva! A hibák a blokkok (8x8) méretezéséből adódnak. A szemed nem látja meg a hibát 4800 kicsi blokkban olyan könnyen, mint 1200 nagy blokkban (feltételezve, hogy mindkettőt teljes képernyőre nagyítod). Elméleti: Ha egy képet leméretezel, de ugyan akkora méretű (8x8) blokkokat használsz a frekvenciatartomány transzformálásához, több adatot mozgatsz a magasabb frekvenciatartományokba. Egyszerűen fogalmazva, minden pixel több részletet fog tartalmazni, mint előtte. Így habár a leméretezett képed kiterjedésében az információ 1/4-edét tartalmazza csak, mégis az információ nagy részét tartalmazhatja a frekvenciatartományban (feltéve, hogy a magas frekvenciák nincsenek kellőképpen kihasználva az eredeti 640x480-as képen). A régi leírások egy "bit per pixel" megközelítés szerint javasolták a bitráta és a felbontás megválasztását, ez azonban általában nem helyes a fentiek miatt. A legjobb becslésnek az tűnik, ha a bitráta léptéke a felbontás négyzetgyökével arányos, így a 320x240 és 400 kbit/sec összehasonlítható a 640x480 és 800 kbit/sec-kel. Azonban ez még nem lett bizonyítva sem elméleti sem gyakorlati törvénnyel. Továbbá, tekintve, hogy a filmek nagyon változatosak a zajtól, részletességtől, a mozgás szögétől, és a többitől függően, haszontalan általános tanácsokat adni bit per átló hosszára vonatkozóan (a bit per pixel analógiája, a négyzetgyök felhasználásával). Eddig csak a felbontás és a bitráta kiválasztás nehézségeiről beszéltünk. A következő képések segítenek a kódolásod felbontásának kiszámításában, a videód túlzott mértékben történő torzítása nélkül, a forrás videó számos tulajdonságának figyelembe vételével. Először, ki kell számítanod az elkódolt képarányt: ARc = (Wc x (ARa / PRdvd )) / Hc Wc és Hc a vágott videó szélessége és a magassága, ARa a megjelenített kép aránya, ami általában 4/3 vagy 16/9, PRdvd a DVD pixel rátája, ami PAL DVD-k esetén 1.25=(720/576) és 1.5=(720/480) NTSC DVD-knél. Ezután, kiszámíthatod az X és Y felbontást, egy bizonyos Tömörítési Minőség (Compression Quality, CQ) faktornak megfelelően: ResY = INT(SQRT( 1000*Bitrate/25/ARc/CQ )/16) * 16 és ResX = INT( ResY * ARc / 16) * 16 Oké, de mi az a CQ? A CQ reprezentálja a kódolás pixelenkénti és képkockánkénti bitszükségletét. Nagy vonalakban minél nagyobb a CQ, annál kisebb a valószínűsége, hogy kódolási hibát fog látni. Bár ha van cél méret a filmedhez (1 vagy 2 CD például), akkor korlátozott a felhasználható bitek száma; ezért szükséges, hogy megfelelő arányt találj a tömörség és a minőség között. A CQ függ a bitrátától, a videó codec hatékonyságától és a film felbontásától. Ha növelni akarod a CQ-t, általában leméretezést kell végezned a filmen, mivel a bitráta a cél méret és a film hosszából számítódik, ami konstans. Az MPEG-4 ASP codec-ekkel, mint pl. az Xvid és a libavcodec, egy 0,18 alatti CQ általában nagyon kockás képet eredményez, mert nincs elég bit minden egyes makroblokk információinak eltárolásához. (Az MPEG4, mint sok más codec, csoportokba gyűjti a pixeleket a kép tömörítéséhez; ha nincs elég bit, láthatóvá válik ezen blokkok széle.) Ezért ésszerű a CQ-t a 0,20-0,22-es tartományból választani 1 CD-s rip esetén, és 0,26-0,28-ból a 2 CD-snél a szabványos kódolási opciókkal. A libavcodec-hez és az Xvid-hez itt felsoroltaknál fejlettebb kódolási opciók segítségével lehetséges ugyan ilyen minőség elérése 0,18-0,20-as CQ mellett egy 1 CD-s rip esetén és 0,24-0,26-ossal 2 CD-s rip-nél. Az MPEG-4 AVC codec-eknél, mint pl. az x264, használhatsz 0,14-0,16-os CQ tartományt a szabványos kódolási opciókkal és lemehetsz akár 0,10-0,12-ig is az x264 fejlett kódolási beállításaival. Kérlek figyelj rá, hogy a CQ csak egy mutató, mely az elkódolt tartalomtól függ, egy 0,18-as CQ-val jól nézhet ki egy Bergman, szemben az olyan filmekkel, mint például a Mátrix, ami sok gyors-mozgású részt tartalmaz. Másrészt nem éri meg növelni a CQ-t 0,30-nál magasabbra, mert csak pazarolni fogod a biteket észrevehető minőségi nyereség nélkül. Vedd figyelembe, amint azt már korábban is említettük, hogy az alacsony felbontású videókhoz nagyobb CQ kell (összehasonlítva pl. a DVD felbontással), hogy jól nézzen ki. A MEncoder videó szűrői használatának ismerete alapvető fontosságú a jó kódoláshoz. Az összes videó feldolgozás a szűrőkön keresztül történik -- vágás, méretezés, szín állítás, zajszűrés, élesítés, deinterlacing, telecine, inverz telecine és deblocking, csak hogy néhányat megemlítsünk. A támogatott formátumok sokaságával együtt a MEncoder szűrőinek változatossága a fő előnye a hasonló programokkal szemben. A szűrők láncban töltődnek be a -vf kapcsoló használatával: -vf szuro1=opciok,szuro2=opciok,... A legtöbb szűrő több numerikus opciót vár, kettőspontokkal elválasztva, de igazából a szintaxis szűrőről szűrőre változik, ezért olvasd el a man oldal általad használni kívánt szűrőhöz tartozó részét! A szűrők olyan sorrendben módosítják a videót, ahogy be lettek töltve. Például a következő lánc: -vf crop=688:464:12:4,scale=640:464 először kivágja a 688x464 területű régiót (12,4)-es bal felső sarokkal, majd az eredményt leméretezi 640x464-re. Bizonyos szűrőket a szűrő lánc elején, vagy ahhoz közel kell betölteni, ahhoz, hogy a videó dekódolótól érkező információkat megkapja, azok ne vesszenek el vagy változzanak meg másik szűrő miatt. A legjobb példa erre a pp (utófeldolgozás, csak ha deblock vagy dering műveleteket hajt végre), az spp (másik utófeldolgozó az MPEG mellékhatások eltávolítására), a pullup (inverz telecine) és a softpulldown (a soft telecine hard telecine-re történő konvertálása). Általában olyan kevés szűrést szeretnél, amennyit csak lehet, hogy az eredeti DVD forráshoz hű maradj. A vágás gyakran elkerülhetetlen (amint azt fentebb leírtuk), de ne méretezd a videót. Noha a kicsinyítés néha előnyben részesül a magas kvantálóknál, mi szeretnénk elkerülni mindkét dolgot: emlékezz, hogy mit határoztunk el kezdetben a bitek minőségért történő feláldozásáról. Szintén hagyd békén a gamma, kontraszt, fényerő, stb. beállításokat. Ami jól néz ki a monitorodon nem biztos, hogy másnál is szép lesz. Ezeket a beállításokat lejátszáskor kell elvégezni. Az egyetlen dolog, amit szeretnél, a videó nagyon könnyű zajszűrőn történő áteresztése, mint pl. -vf hqdn3d=2:1:2. Ismételten, ezen bitek jobb felhasználásáról van szó: miért vesztegessük el őket a zaj kódolására, ha ezt a zajt lejátszás közben is hozzá tudod adni? A hqdn3d paramétereinek növelésével még jobb tömörítettséget érhetsz el, de ha túl magasra állítod az értékeket, akkor láthatóan rontod a kép minőségét. A fent javasolt értékek (2:1:2) eléggé konzervatívak; kísérletezz szabadon nagyobb értékekkel és ellenőrizd az eredményeket magad. Majdnem minden filmet 24 fps-sel fényképeznek. Mivel az NTSC 30000/1001 fps-es, némi átdolgozás szükséges ezen a 24 fps-es videón, hogy a megfelelő NTSC framerátával menjen. Ez az eljárást 3:2 pulldown-nak hívják, de általában csak telecine néven hivatkoznak rá (mivel a pulldownt gyakran használják a telecine eljárás során), ami egyszerűen leírva lelassítja a filmet 24000/1001 fps-re és megismétel minden negyedik képkockát. Ez nem speciális feldolgozás, habár minden PAL DVD esetében megcsinálják, ami 25 fps-sel megy. (Műszaki szempontból a PAL-t lehet telecine-elni, ezt 2:2 pulldown-nak hívják, de ez nem terjedt el a gyakorlatban.) A 24 fps-es filmet egyszerűen 25 fps-sel játszák le. Az eredmény az, hogy a film kissé gyorsabban megy, de ha nem vagy egy földönkívüli, valószínűleg nem fogod észrevenni a különbséget. A legtöbb PAL DVD zajszint-javított audiót tartalmaz, így amikor 25 fps-sel játszák le őket, a hangok jól hangzanak, még akkor is, ha az audió sáv (és ebből adódóan az egész film) az NTSC DVD-kénél 4%-kal lassabb futási idővel megy. Mivel a PAL DVD-ben a videót nem változtatták meg, nem kell aggódnod a frameráta miatt. A forrás 25 fps-es és a rip-ed is 25 fps-es lesz. De ha egy NTSC DVD filmet rippelsz, fordított telecine-t kell alkalmaznod. A 24 fps-sel felvett filmeknél az NTSC DVD-n lévő videó vagy telecine-elt 30000/1001 fps-re vagy pedig progresszív 24000/1001 fps-es és szándék szerint a DVD lejátszó végzi a telecine-t lejátszás közben. Másrészről a TV sorozatok általában csak átlapoltak, nem telecine-ltek. Ez azonban nem ökölszabály: néhány TV sorozat átlapolt (mint a Buffy a Vámpír gyilkos) míg másik a progresszív és az átlapolt keverékei (mint pl. az Angyal vagy a 24). Javasoljuk, hogy olvasd el a mit kezdjünk a telecine-nel és az átlapolással NTSC DVD-ken részt, hogy kezelni tudd a különböző lehetőségeket. Bár ha legtöbbször csak filmeket rippelsz, valószínűleg vagy 24 fps-es progresszív vagy telecine-lt videóval lesz dolgod, ezekben az esetekben használhatod a pullup szűrőt a -vf pullup,softskip kapcsolóval. Ha az általad elkódolni kívánt film átlapolt (NTSC videó vagy PAL videó), el kell döntened, hogy akarsz-e deinterlacing-et vagy sem. A deinterlacing használhatóvá teszi a filmed progresszív scan-es megjelenítőkön, mint pl. a számítógép monitorok vagy a projektorok, van ára is: az 50 vagy 60000/1001-es mezőráta feleződik 25 vagy 30000/1001 képkocka per másodpercre és így a filmedben tárolt információk durván fele elveszik a jelentős mozgást tartalmazó részekben. Így hát ha archiválási okokból jó minőség kell, akkor kerüld el a deinterlace-t. Bármikor deinterlace-lheted a filmet lejátszás közben is, ha progresszív scan-es megjelenítőd van. A jelenleg kapható számítógépek teljesítménye deinterlacing szűrő használatára kényszerítik a lejátszókat, ami egy kis mértékű képminőség romlást okoz. Azonban a jövő lejátszói képesek lesznek az átlapolt képernyő TV-vé történő átváltoztatására, teljes mezőrátás deinterlacing-re és az átlapolt videó 50 vagy 60000/1001 teljes képkocka per másodpercre interpolálására. Fokozott figyelemmel kell eljárni, ha átlapolt videóval dolgozol: A vágási magasság és y-offszet 4 többszöröse kell, hogy legyen. Bármilyen függőleges átméretezést átlapolt módban kell elvégezni. Az utófeldolgozó és a zajcsökkentő szűrők nem az elvártnak megfelelően működnek, ha nem gondoskodsz róla, hogy egyszerre csak egy mezővel dolgozzanak, különben a nem megfelelő használat miatt sérülhet a videó. Mindezt észben tartva, itt az első példánk: mencoder capture.avi -mc 0 -oac lavc -ovc lavc -lavcopts \ vcodec=mpeg2video:vbitrate=6000:ilme:ildct:acodec=mp2:abitrate=224 Figyelj az ilme és az ildct kapcsolókra. A MEncoder audió/videó szinkronizáló algoritmusai azzal a szándékkal lettek megtervezve, hogy képesek legyenek a sérült szinkronú filmek megjavítására. De néhány esetben a képkockáknál szükségtelen kihagyásokat és duplikálásokat valamint kis mértékben A/V deszinkronizációt okozhatnak, ha megfelelő bementük van (természetesen az A/V szinkron dolgok csak akkor érvényesek, ha feldolgozod vagy másolod az audió sávot a videó átkódolása közben, ami nagyon javasolt). Ezért lehet, hogy az alapértelmezett A/V szinkronizációra kell váltanod a -mc 0 opcióval, vagy írd ezt bele a ~/.mplayer/mencoder konfigurációs fájlodba, feltéve, hogy csak hibátlan anyaggal dolgozol (DVD, TV mentés, nagyon jó minőségű MPEG-4 rip, stb.) és nem hibás ASF/RM/MOV fájlokkal. Ha még további különös képkocka kihagyásokat és duplázásokat akarsz elkerülni, használhatod az -mc 0 és -noskip kapcsolókat együtt is. Ez megakadályoz mindenféle A/V szinkronizációt és egy az egyben másolja a képkockákat, így nem használhatod olyan szűrőkkel, melyek megjósolhatatlanul hozzáadnak vagy elvesznek képkockákat, vagy ha a bemeneti fájlodnak változó framerátája van! Ezért a -noskip használata általában nem javasolt. A MEncoder által támogatott, úgy nevezett "három lépéses" audió kódolás a visszajelzések szerint A/V deszinkronizációt okoz. Ez különösen akkor történik, ha bizonyos szűrőkkel együtt használják, így jelenleg nem javasolt a három lépéses audió mód használata. Ez a képesség csak kompatibilítási okok miatt maradt meg és a haladó felhasználóknak, akik tudják, hogy mikor lehet használni és mikor nem. Ha ezelőtt még soha nem hallottál a három lépéses módról, felejtsd el azt is, hogy megemlítettük! Érkeztek jelentések A/V deszinkronizációról MEncoderrel stdin-ről történő kódolás esetén is. Ne tedd ezt! Mindig használj fájlt vagy CD/DVD/stb. eszközt forrásként. A használandó videó codec kiválasztása több dologtól függ, mint például a méret, minőség, stream-elhetőség, használhatóság és elterjedtség, melyeket a személyes igények és a technikai korlátok határoznak meg. Tömörítési hatékonyság: Érthető módon a legtöbb új generációs codec a minőség és a tömörítés javítására íródott. Ezért ezen leírás szerzői és még sok más szerint sem tudsz rosszat választani, Azonban légy óvatos: A DVD felbontású MPEG-4 AVC videó dekódolása gyors gépet igényel (pl. egy 1,5 GHz feletti Pentium 4 vagy egy 1 GHz feletti Pentium M). akár MPEG-4 AVC codec-et választasz, mint például az x264, akár egy MPEG-4 ASP codec-et, mint pl. a libavcodec MPEG-4 vagy az Xvid. (A haladóbb codec fejlesztőket talán érdekelheti Michael Niedermayer véleménye, a "miért utáljuk az MPEG4-et".) Valószínűleg az MPEG-4 ASP-vel jobb minőséget érhetsz el, mint az MPEG-2 codec-ekkel. Bár az új codec-ek, melyek még erőteljes fejlesztés alatt állnak, tartalmazhatnak hibákat, amiket még nem fedeztek fel és amik tönkretehetnek egy kódolást. Ez a hátránya az új dolgok használatának. Mint ahogy az is, hogy amikor új codec-et kezdesz használni, időt kell szánnod az opcióinak a megismerésére, hogy tudd, miket kell beállítanod a kívánt képminőség eléréséhez. Hardveres kompatibilítás: Általában sok idő kell, míg az asztali lejátszók elkezdenek támogatni egy új codec-et. Ennek eredménye, hogy a legtöbb csak MPEG-1 (mint a VCD, XVCD és KVCD), MPEG-2 (mint a DVD, SVCD és KVCD) és MPEG-4 ASP (mint a DivX, a libavcodec LMP4-e és az Xvid) lejátszására képes (Vigyázz: Legtöbbször nem ismerik az MPEG-4 ASP összes képességét). Nézd meg a lejátszód technikai specifikációját (ha van) vagy google-ozz körbe további információért. Legjobb minőség kontra kódolási idő: A már jó ideje létező codec-ek (mint pl. a libavcodec MPEG-4-e és az Xvid) általában nagyon jól optimalizáltak mindenféle okos algoritmussal és SIMD assembly kóddal. Ezért a legjobb minőség per kódolási idő arány felé tartanak. Azonban van néhány nagyon fejlett opció, amit ha engedélyezel, nagyon nagy mértékben lelassítják a kódolást csekély javulást produkálva. Ha a fantasztikus sebességet keresed, a codec alapértelmezett beállításai körül nézelődj (azonban így is ajánlott kipróbálni egyéb opciókat, amiket ezen leírás más fejezetei említenek). Megfontolandó olyan codec-et választani, ami több-szálas módban dolgozza fel a forrást, azonban ez csak a több processzoros géppel rendelkezőknek jelent előnyt. A libavcodec MPEG-4 tudja ezt, de a sebességnövekedés eléggé korlátolt és egy kis negatív hatása van a képminőségre. Az Xvid több-szálas kódolása, melyet a threads opció kapcsol be, használható a kódolási sebesség — átlagban kb. 40-60%-os — növelésére, nagyon csekély vagy semmilyen képromlással. Az x264 is tudja a több-szálas kódolást, ami jelenleg CPU magonként 94%-kal gyorsítja fel a kódolást míg a PSNR-t kb. 0.005dB és 0.01dB közötti értékkel csökkenti. Egyéni igények: Itt válik a dolog a legirrálisabbá: ugyan azért, amiért sokan leragadtak a DivX 3-nál évekig, miközben az új codec-ek már csodákat műveltek, néhányan az Xvid-et vagy a libavcodec MPEG-4-ét részesítik előnyben az x264-hez képest. A döntést magadnak kell meghoznod; ne hallgass azokra, akik egy codec-re esküsznek. Vegyél pár példa klippet nyers forrásokból és hasonlítsd össze a különböző kódolási opciókat és codec-eket, hogy megtudd, melyik a legjobb neked. A legjobb codec mindig az, amelyikhez a legjobban értesz, amelyik a legjobban néz ki szerinted a monitorodon. Ugyan az a kódolás nem biztos, hogy ugyan úgy néz ki valaki másnak a monitorán vagy ha más dekódolóval játszák le, ezért ellenőrizd a kódolásaidat különböző beállítások mellett történő lejátszással! ! Kérjük, nézd meg a codec-ek és konténer formátumok kiválasztásáról szóló fejezetet a támogatott codec-ek listájához. Az audió egy sokkal könnyebben megoldható probléma: ha számít a minőség, akkor egyszerűen hagyd úgy, ahogy van. Még az AC-3 5.1 stream-ek is leginkább 448Kbit/s-osak és minden bitet megérnek. Csábító lehet az audió jó minőségű Vorbis-ba történő konvertálása, de az, hogy ma nincs egy A/V receiver-ed az AC-3 áteresztéshez, nem jelenti azt, hogy holnap sem lesz. Készíts a jövőben is használható DVD rip-eket az AC-3 stream megtartásával. Megtarthatod az AC-3 stream-et a kódolás közben a videó stream-be történő közvetlen átmásolással. Vagy ki is szedheted az AC-3 stream-et, hogy elkeverd valamilyen konténer formátumba, mint pl. a NUT vagy a Matroska. mplayer forras_fajl.vob -aid 129 -dumpaudio -dumpfile hang.ac3 a 129-es audió sávot kiszedi a sound.ac3 nevű fájlba a source_file.vob-ból (NB: a DVD VOB fájlok általában különböző audió számozást használnak, ami azt jelenti, hogy a 129-es VOB audio sáv a 2. audió sáv a fájlban). De néha tényleg nincs más választásod, mint tovább tömöríteni a hangot így több bit jut a videóra. A legtöbb ember vagy MP3-at vagy Vorbis-t választ az audió tömörítéséhez. Míg az utóbbi nagyon hely-takarékos codec, az MP3-nak jobb a hardveres lejátszók terén a támogatottsága, bár ez a trend változóban van. Ne használd a -nosound-ot ha audióval rendelkező fájlt kódolsz, akkor se, ha az audiót később, elkülönítve kódolod és kevered. Bár ideális esetben működik, a -nosound opció okozhat némi problémát a parancssori kódolási beállításaidban. Más szavakkal, a zene sáv megléte biztosítja a Too many audio packets in the buffer (Túl sok audió csomag a bufferban) és hasonló üzenetek elkerülését és a megfelelő szinkront. Fel kell dolgoznod a MEncoderrel a hangot. Például az -oac copy-val átmásolhatod az eredeti hangsávot a kódolás közben vagy átkonvertálhatod "könnyű" 4 kHz-es mono WAV PCM-be a -oac pcm -channels 1 -srate 4000 kapcsolóval. Különben bizonyos esetekben olyan videó fájlt fog létrehozni, amiben nem lesz szinkronban az audió. Akkor fordulhat elő ilyen eset, ha a videó kockák száma a forrás fájlban nem egyezik meg az audió keretek teljes hosszával vagy folyamatossági hiba/szakadás miatt hiányzó vagy extra audió keretek vannak a fájlban. A helyes megoldás ezen típusú problémák kezelésére csend beillesztése vagy az audió keretek vágása ezeken a pontokon. Azonban a MPlayer ezt nem tudja megtenni, így ha az AC-3-at demuxálod és egy másik alkalmazással kódolod (vagy kimented PCM-be az MPlayerrel), a szeletek hibásan maradnak benne és csak képkocka eldobással/duplázással lehet javítani. Amíg a MEncoder látja az audiót a videó kódolása közben, meg tudja csinálni ezt az eldobást/duplázást (ami általában rendben van, mert teljesen sötét/jelentet váltásos helyeken történik), de ha a MEncoder nem látja az audiót, csak feldolgoz minden képkockát úgy ahogy van és nem fog illeszkedni a végső audió folyamhoz ha például összeilleszted az audió és a videó sávodat egy Matroska fájlba. Mindenek előtt át kell konvertálnod a DVD hangját WAV fájlba, hogy az audió codec használhassa bemenetként. Például: mplayer forras_fajl.vob -ao pcm:file=cel_hang.wav \ -vc dummy -aid 1 -vo null ki fogja szedni a második audió sávot a source_file.vob fájlból a destination_sound.wav fájlba. Kódolás előtt valószínűleg normalizálni akarod a hangot, mivel a DVD audió sávjait legtöbbször alacsony hangerővel rögzítik. Használhatod a normalize eszközt, ami megtalálható a legtöbb disztribúcióban. Ha Windows-t használsz, egy eszköz, mint pl. a BeSweet megcsinálja ezt neked. Vagy Vorbis-ba vagy MP3-ba kódolsz. Például: oggenc -q1 cel_hang.wav elkódolja a destination_sound.wav-ot az 1-es kódolási minsőséggel, ami nagyjából megfelel 80Kb/s-nak és annak a minimum minőségnek, amit legalább használnod kell, ha érdekel a minőség. Kérlek jegyezd meg, hogy a MEncoder jelenleg nem tud Ogg Vorbis sávokat belekeverni a kimeneti fájlba, mert csak AVI és MPEG konténereket támogat kimenetként és mindkettőnél audió/videó lejátszási szinkronizációs problémákat okozhat néhány lejátszóval, ha az AVI fájl VBR-es audió stream-et tartalmaz, mint pl. a Vorbis. De ne aggódj, ez a dokumentáció megmutatja, hogy hogy tudod ezt megcsinálni egyéb programokkal. Most, hogy elkódoltad a videódat, valószínűleg szeretnéd elkeverni egy vagy több audió sávval együtt egy film konténerbe, mint pl. az AVI, MPEG, Matroska vagy a NUT. A MEncoder jelenleg csak MPEG és AVI konténer formátumokba tud natív audió és videó kimenetet készíteni. Például: mencoder -oac copy -ovc copy -o kimenet_film.avi \ -audiofile bemenet_audio.mp2 bemenet_video.avi Ez a bemenet_video.avi videó fájlból és a bemenet_audio.mp2 audió fájlból elkészíti a kimenet_film.avi fájlt. Ez a parancs működik MPEG-1 layer I, II és III (ismertebb nevén MP3) audióval, WAV és egy pár más audió formátummal. A MEncoderben kísérleti jelleggel van libavformat támogatás, ami az FFmpeg projektből egy függvénykönyvtár, ami számos konténer keverését és demux-álását támogatja. Például: mencoder -oac copy -ovc copy -o kimenet_film.asf -audiofile bemenet_audio.mp2 \ bemenet_video.avi -of lavf -lavfopts format=asf Ez ugyan azt csinálja, mint az előbbi példa, de a kimeneti konténer ASF lesz. Kérlek figyelj, hogy ez a támogatás még nagyon kísérleti (de minden nap egyre jobb lesz) és csak akkor működik, ha az MPlayert a libavformat támogatás bekapcsolásával fordítottad (ami azt jelenti, hogy az előre csomagolt binárisok a legtöbb esetben nem fognak működni). Néhány súlyos A/V szinkron problémát tapasztalhatsz, ha a videódat valamilyen audió sávval akarod összekeverni, mégpedig azt, hogy akár hogyan állítod az audió késleltetést, soha nem lesz megfelelő a szinkron. Ez akkor történhet meg, ha olyan videó szűrőt használsz, ami eldob vagy megdupláz képkockákat, mint pl. az inverz telecine szűrők. Javasolt a harddup videű szűrő hozzáillesztése a szűrő lánc végéhez ezen problémák elkerülése érdekében. A harddup nélkül ha a MEncoder meg akar duplázni egy képkockát, a keverőre bízza a jelölés konténerbe helyezését, hogy az utolsó képkocka még egyszer megjelenjen a szinkron megtartása végett, aktuális képkocka írása nélkül. A harddup-pal a MEncoder ehelyett egyszerűen csak újra átküldi a szűrő láncon az utolsó megjelenített képkockát. Ez azt jelenti, hogy a kódoló pontosan ugyan azt a képkockát kapja meg kétszer és tömöríti be. Ez kicsit nagyobb fájlt eredményez, de nem okoz problémát demuxálásnál vagy másik konténer formátumba történő újrakeverésnél. Nincs más választásod, mint a harddup használata az olyan konténer formátumokkal, amelyek nincsenek szoros összefüggésben a MEncoderrel. Ezek pl. azok, amelyeket a libavformat-on keresztül támogat, ami nem támogatja a képkocka duplázást konténer szinten. Habár a legszélesebb körben támogatott konténer formátum az MPEG-1 után, az AVI-nak is van néhány nagy hátránya. Talán a legnyilvánvalóbb a túlterhelés. Az AVi fájl minden egyes chunk-ja 24 bájtot pazarol a fejlécekre és az indexre. Ez egy kicsit több mint 5 MB óránként vagy 1-2,5% plusz egy 700 MB-os filmnél. Ez nem tűnik soknak, de eldöntheti, hogy 700 kbit/sec-os videót tudsz csak használni vagy 714 kbit/sec-osat, ahol minden bit a minőségre megy. Ezen hatalmas hátrány mellett az AVI-nak a következő fő korlátai vannak: Csak fix-fps-ű tartalmat tud tárolni. Ez különleges korlátozás, ha az eredeti anyag, amit el akarsz kódolni, kevert tartalom, például NTSC videó és film anyag keveréke. Már vannak olyan hack-ek, amivel kevert framerátás tartalmat lehetne AVI-ba tenni, de ötszörös vagy még nagyobb mértékben növelik a (már amúgy is nagy) túlterhelést, így nem praktikusak. Az AVI fájlokban az audiónak vagy konstans-bitrátásnak (CBR) vagy konstans-képkocka méretűnek (pl. minden képkocka ugyan annyi számú mintát dekódol) kell lennie. Sajnos a leghatékonyabb codec, a Vorbis, egyik kívánalomnak sem felel meg. Ezért ha AVI-ban tárolod a filmjeidet, egy kevésbé hatékony codec-et kell használnod, mint pl. az MP3 vagy az AC-3. A fentiek miatt a MEncoder jelenleg nem támogatja a változó-fps-es kimenetet vagy a Vorbis kódolást. Így ezeket nem korlátozásként fogod fel, ha a MEncoder az egyetlen eszköz, mellyel kódolsz. Azonban lehetséges a MEncodert csak a videó kódolására használni és valamilyen egyéb eszközzel elkódolni az audiót majd összekeverni őket egy konténer formátumba. A Matroska szabad, nyílt szabványú konténer formátum, melynek célja, hogy rengeteg továbbfejlesztett képességet biztosítson, amit a régebbi konténerek, mint pl. az AVI nem tud kezelni. például a Matroska támogatja a változó bitrátás audió tartalmat (VBR), változó framerátát (VFR), fejezeteket, fájl csatolásokat, hiba kereső kódot (EDC) és a modern A/V codec-eket, mint az "Advanced Audio Coding" (AAC), "Vorbis" vagy "MPEG-4 AVC" (H.264), szemben az AVI-val, amelyik egyiket sem. A Matroska fájlok készítéséhez szükséges eszközöket együtt mkvtoolnix-nek hívják és elérhetőek a legtöbb Unix platformon, akárcsak Windowson. Mivel a Matroska nyílt szabványú, találhatsz más eszközöket is, amik jobban megfelelnek neked, de mivel az mkvtoolnix a leggyakrabban használt, és maga a Matroska csapat támogatja, csak ennek a használatát mutatjuk be. Talán a legegyszerűbb módszer, hogy elindulj a Matroska-val, az MMG használata, az mkvtoolnix-szel szállított grafikus frontend és kövesd a mkvmerge GUI (mmg) leírást. A parancssor segítségével is összekverheted az audió és videó fájlokat: mkvmerge -o kimenet.mkv bemenet_video.avi bemenet_audio1.mp3 bemenet_audio2.ac3 Ez a bemenet_video.avi fájlt és a két audió fájlt, a bemenet_audio1.mp3-at és a bemenet_audio2.ac3-at összefűzi a kimenet.mkv Matroska fájlba. A Matroska, mint ahogy azt már megemlítettem, ennél sokkal többre képes, mint pl. több audió sáv használatára (beleértve az audió/videó szinkronizáció finom-hangolását), fejezetek, feliratok, vágás, stb... Kérlek olvasd el ezen alkalmazások dokumentációit a részletekért. Ha nem érted teljesen, ami ebben a dokumentumban le van írva, olvasd el a Wikipedia telecine szócikkét. Ez egy érthető és meglehetősen átfogó leírás arról, hogy mi is az a telecine. Sok dokumentáció, beleértve a fent belinkelt cikket is, az NTSC videó mező per másodperc értékét 59.94-ként határozza meg, és a megfelelő képkocka per másodperc értéket 29.97-nek (telecine-s és átlapolt) és 23.976-nak írja (progresszív). Az egyszerűség kedvéért sok dokumentáció még ezeket a számokat is lekerekíti 60-ra, 30-ra és 24-re. Pontosan fogalmazva az összes szám csak közelítés. A fekete-fehér NTSC videó pontosan 60 mező per másodperces volt, de később 60000/1001-et választottak, hogy a szín adatokat hozzáigazítsák, de kompatibilisek maradjanak a kortárs fekete-fehér televíziókkal. A digitális NTSC videó (mint ami a DVD-n van) is 60000/1001 mező per másodperces. Ebből származik, hogy az átlapolt és telecine-lt videó 30000/1001 képkocka per másodperces; a progresszív videó 24000/1001 képkocka per másodperces. A MEncoder dokumentációjának régebbi változatai és számos archivált levelezési listára küldött levél az 59.94-re, 29.97-re és a 23.976-ra hivatkozik. Az összes MEncoder dokumentáció frissítve lett a tört számokra és neked is ajánlatos ezeket használni. -ofps 23.976 helytelen. -ofps 24000/1001 használandó helyette. Az összes videónak, amit NTSC televízión szándékoznak megjeleníteni, 60000/1001 mező per másodperc sebességűnek kell lennie. A TV-nek készített filmeket és show-kat gyakran direkt 60000/1001 mező per másodperces sebességgel fényképezik, de a mozifilmek nagy része 24 vagy 24000/1001 képkocka per másodperccel készül. Amikor a mozis film DVD-jét készítik, a videót egy telecine-nek nevezett eljárás keretében televíziós formátumra konvertálják. Egy DVD-n a videót tulajdonképpen soha sem 60000/1001 mező per másodperccel tárolják. Abban a videóban, ami eredetileg 60000/1001-es volt, egy pár mező alkot egy képkockát, 30000/1001 képkocka per másodperces sebességet eredményezve. A hardveres DVD lejátszók ezután beolvasnak egy, a videó folyamban benne lévő jelzőt, hogy megállapítsák, hogy a páros vagy páratlan sorszámú sorok alkotják-e az első mezőt. Általában a 24000/1001 képkocka per másodperces tartalom változatlan marad, ha DVD-re kódolják és a DVD lejátszónak kell telecine-t végezni menet közben. De néha a videót a DVD-re mentés előtt telecine-lik, akkor is, ha eredetileg 24000/1001 képkocka per másodperces volt, így 60000/1001 mező per másodperces lesz, és a lemezen 30000/1001 képkocka per másodpercesként tárolódik. Ha megnézed az egyes képkockákat a 60000/1001 mező per másodperces videóban, telecine-lt vagy sem, az átlapolás tisztán látható bármilyen mozgásnál, mert az egyik mező (mondjuk a páros sorszámú sorok) időben 1/(60000/1001) másodperccel későbbi történést reprezentál, mint a másik. Átlapolt videó számítógépen történő lejátszáskor rondán néz ki, mert egyrészt a monitornak nagyobb a felbontása, másrészt mert a videót kockáról kockára mutatja meg, mezőről mezőre történő lejátszás helyett. Ez a rész csak NTSC DVD-re vonatkozik, nem a PAL-ra. A MEncoder példa sorok a dokumentumban nem hétköznapi felhasználásra lettek írva. Csak a legalapvetőbb dolgokat mutatják, ami a megfelelő kategóriába tartozó videók kódolásához szükséges. A jó DVD rip-ek készítése vagy a libavcodec finomhangolása a maximális minőség eléréséhez nem tartozik ezen fejezet célkitűzései közé, nézd meg a MEncoder kódolási útmutató többi részét. Sok megjegyzés vonatkozik erre a leírásra, melyek így vannak jelölve: [1] A progresszív videót eredetileg 24000/1001 fps-sel rögzítették és változtatás nélkül tárolják a DVD-n. Ha egy progressive DVD-t az MPlayerrel játszasz le, az MPlayer a következő sort fogja kiírni, amint a film lejátszása megkezdődik: demux_mpg: 24000/1001 fps progressive NTSC content detected, switching framerate. magyarul: demux_mpg: 24000/1001 fps progresszív NTSC formátumot találtam, frameráta váltás. Ettől a ponttól kezdve a demux_mpg soha sem mondhatja azt, hogy "30000/1001 fps NTSC formátumot" talált. Ha progresszív videót nézel, soha nem láthatod meg az átlapolást. De vigyázz, néha pár telecine-s bit belekeveredik oda, ahol nem számítasz rá. Én DVD-n lévő TV műsoroknál láttam egy másodpercnyi telecine-t minden jelenet váltáskor vagy véletlen helyeken történő belenézéskor. Egyszer láttam olyan DVD-t is, aminek az első fele progresszív volt, a második fele pedig telecine-s. Ha tényleg biztosra akarsz menni, átvizsgálhatod az egész filmet: mplayer dvd://1 -nosound -vo null -benchmark A -benchmark kapcsoló határása az MPlayer olyan gyorsan játsza le a filmet, amennyire csak lehetséges; a hardveredtől függően sokáig is eltarthat. Minden esetben, ha a demux_mpg frameráta váltást észlel, a fenti sor azonnal megmutatja neked a váltás idejét. Néha a progresszív videóra "soft-telecine"-ként hivatkoznak, mert a DVD lejátszónak kell ezt telecine-elnie. A telecine-lt videót eredetileg 24000/1001 fps-sel vették fel, de telecine-lve lett a DVD-re írás előtt. Az MPlayer nem ír semmilyen frameráta változást, ha telecine-lt videót játszik le. Egy telecine-lt videó nézésekor átlapolási hibákat láthatsz, amik miatt "villoghat" a kép: ismétlődően megjelennek majd eltűnnek. Ezt jobban megfigyelheted így: mplayer dvd://1 Menj egy mozgást ábrázoló részhez. Használd a . gombot az egy képkockával történő előreléptetéshez. Nézd meg az átlapoltnak látszó és a progresszívnak látszó képkockák mintáját. Ha a minta, amit látsz PPPII, PPPII, PPPII,... akkor a videó telecine-lt. Ha valami más mintát látsz, akkor a videót lehet, hogy egy másik, nem szabványos módszerrel telecine-lték; a MEncoder nem tudja veszteségmentesen átkonvertálni a nem-sabványos telecine-t progresszívba. Ha egyáltalán nem látsz semmilyen mintát, akkor valószínűleg átlapolt. Néha a DVD-ken lévő telecine-lt videót "hard-telecine"-nek is hívják. Mivel a hard-telecine már 60000/1001 mező per másodperces, a DVD lejátszó mindenféle manipulálás nélkül játsza le a videót. A másik módszer a telecine-lt forrás felismerésére a forrás megtekintése a -vf pullup és -v kapcsolók parancssorhoz történő hozzáadásával. Így megnézheted, hogy a pullup hogyan illeszkedik a képkockákhoz. Ha a forrás telecine-s, a konzolon egy 3:2-es mintát kell látnod, melyben 0+.1.+2 és 0++1 váltakozik. Ennek a technikának megvan az az előnye, hogy nem kell a forrást nézned az azonosításhoz, ami akkor jó, ha automatizálni szeretnéd a kódolási folyamatot vagy távolról, lassú kapcsolaton keresztül szeretnéd megcsinálni. Az átlapolt videót eredetileg 60000/1001 mező per másodperc sebességgel filmezték és 30000/1001 képkocka per másodperccel került fel a DVD-re. Az átlapolási effektus (gyakran "combing"-nak hívják) a mező párok képkockává történő egyesítésének eredménye. Minden mezőnek 1/(60000/1001) másodpercnyire kellene lennie egymástól, megjelenítésnél a különbség szemmel látható. Akár csak a telecine-s videóknál, az MPlayernek a nem kell semmiféle frameráta változásról értesítenie átlapolt videók lejátszásakor. Ha egy átlapolt videót közelebbről megnézel képkocka-léptetéssel a . gombot nyomogatva, megláthatod, hogy minden egyes képkocka átlapolt. Az összes "kevert progresszív és telecine" videót eredetileg 24000/1001 képkocka per másodperccel rögzítették, de egyes részei utólag telecine-lve lettek. Ha az MPlayer ilyen videót játszik le, (sokszor ismétlődően) oda-vissza vált "30000/1001 fps NTSC" és "24000/1001 fps progresszív NTSC" között. Figyeld az MPlayer kimenetének alját, ott megláthatod az üzeneteket. Nézd meg a "30000/1001 fps NTSC" részeket, és meggyőződhetsz róla, hogy telecine-ltek, nem csak átlapoltak. "Kevert progresszív és átlapolt" tartalomnál a progresszív és az átlapolt videót összeillesztették. Ez a kategória ugyan úgy viselkedik, mint a "kevert progresszív és telecine", egészen addig, amíg meg nem vizsgálod a 30000/1001 fps-es részeket és észre nem veszed, hogy nincs bennük telecine minta. Ahogy említettem az elején, például a MEncoder alábbi parancssorai nem igazán használhatóak; csak demonstrálják a minimum paramétereket az egyes kategóriák megfelelő kódolásához. A progresszív videóhoz nem kell semmilyen különleges szűrés. Az egyetlen paraméterm, amit biztosan használnod kell, az a -ofps 24000/1001. Egyébként a MEncoder 30000/1001 fps-sel és duplikált képkockákkal próbál kódolni. mencoder dvd://1 -oac copy -ovc lavc -ofps 24000/1001 Gyakran az az eset áll fenn, hogy a videó progresszívnek tűnik, de valójában nagyon rövid telecine-s részek vannak belekeverve. Ha nem vagy biztos a dolgodban, a legbiztonságosabb, ha kevert progresszív és telecine-lt videóként kezeled. A teljesítményvesztés kicsi [3]. A telecine visszafordítható, hogy megkapd az eredeti 24000/1001-es tartalmat, egy inverz-telecine-nek nevezett eljárással. Az MPlayer számos szűrővel rendelkezik ennek az elvégzéséhez; a legjobb szűrő a pullup le van írva a kevert progresszív és telecine részben. A legtöbb gyakorlati esetben nem lehetséges a teljes progresszív videó visszanyerése az átlapolt tartalomból. Az egyetlen út ehhez a függőleges felbontás felének elvesztése nélkül a frameráta megduplázása és "megtippelni", hogy mi kellene minden egyes mező megfelelő sorainak felépítéséhez (ennek vannak hátrányai - lásd a 3. módszert). Kódold el a videót átlapolt formában. Normális esetben az átlapolás eléggé odavág a kódoló tömörítési képességeinek, de a libavcodecnek van két paramétere speciálisan az átlapolt videó tárolásának egy kicsit jobb kezeléséhez: ildct és ilme. Az mbd=2 használata is javasolt [2] , mert ez a makroblokkokat nem-átlapoltként fogja elkódolni azokon a helyeken, ahol nincs mozgás. Ügyelj rá, hogy itt a -ofps NEM kell. mencoder dvd://1 -oac copy -ovc lavc -lavcopts ildct:ilme:mbd=2 Használj deinterlacing szűrőt a kódolás előtt. Számos közül választhatsz, mindegyiknek megvan a maga előnye és hátránya. Lásd az mplayer -pphelp és az mplayer -vf help kimenetét, hogy megtudd, mit használhatsz (grep-pelj a "deint"-re), olvasd el Michael Niedermayer Deinterlacing szűrő összehasonlítását, és keress az MPlayer levelezési listáin a sok beszélgetés között, ami a különböző szűrőkről szól. A frameráta itt sem változik, így nem kell a -ofps. A deinterlacing-et a vágás után [1] és a méretezés előtt kell elvégezni. mencoder dvd://1 -oac copy -vf yadif -ovc lavc Sajnos ez a kapcsoló hibás a MEncoderben; talán a MEncoder G2-vel működni fog, de itt most még nem. Fagyásokat tapasztalhatsz. Egyébként a -vf tfields célja az lenne, hogy teljes képkockát készít mindegyik mezőből, ami miatt a frameráta 60000/1001 lesz. Ennek a megközelítésnek az az előnye, hogy soha nincs adatvesztés; habár mivel minden egyes kocka csak egy mezőből keletkezik, a hiányzó sorokat valahogy interpolálni kell. Igazából nincs jó módszer a hiányzó adat összegyűjtésére és így az eredmény kicsit úgy fog kinézni, mint amikor valamilyen deinterlacing szűrőt használsz. A hiányzó sorok generálása egyéb dolgokat idéz elő, egyszerűen mivel az adat mennyisége megduplázódik. Így, nagyobb kódolási bitráták szükségesek a minőség megtartásához, és nagyobb CPU teljesítmény mind a kódoláshoz, mind a dekódoláshoz. A tfield-eknek számos különböző opciójuk van az egyes képkockákban hiányzó sorok előállításához. Ha ezt a módszert használod, akkor nézd meg a manual-t és válassz, hogy melyik opcióval néz ki legjobban az anyagod. Figyelj rá, hogy ha tfield-eket használsz, mind a -fps-nek, mind a -ofps-nek az eredeti forrásod framerátájának kétszeresét kell megadnod. mencoder dvd://1 -oac copy -vf tfields=2 -ovc lavc \ -fps 60000/1001 -ofps 60000/1001 Ha drasztikus downscaling-et tervezel, kiszedhetsz és elkódolhatsz egy mezőt is a kettő helyett. Természetesen így elveszíted a függőleges felbontás felét, de ha downscaling-et tervezel legfeljebb az eredeti 1/2-ével, a veszteség nem számottevő. Az eredmény egy progresszív 30000/1001 képkocka per másodperces fájl lesz. A helyes eljárás a -vf field használata, majd vágás [1] és megfelelő méretezés. Emlékezz, hogy be kell állítanod a méretarányt a felezett függőleges felbontásnak megfelelően. mencoder dvd://1 -oac copy -vf field=0 -ovc lavc Ahhoz, hogy egy kevert, progresszív és telecine-s videót teljesen progresszív videóvá konvertálj, a telecine-lt részeket inverz-telecine-elni kell. Ez háromféle képpen végezhető el, mint ahogy az lejjebb látható. Figyelj rá, hogy mindig az inverse-telecine legyen meg bármilyen átméretezés előtt; hacsak nem vagy teljesen biztos a dolgodban, és az inverse-telecine legyen a vágás előtt is [1]. A -ofps 24000/1001 kell ide, mert a kimeneti videó 24000/1001 képkocka per másodperc sebességű lesz. A -vf pullup a telecine-s részek inverz-telecine-léséhez lett tervezve úgy, hogy a progresszív adatokat érintetlenül hagyja. A helyes működéshez a pullup-ot a softskip szűrőnek kell követnie, különben a MEncoder összeomlik. Ennek ellenére a pullup a legtisztább és legjobb módszer mind a telecine-s, mind a "kevert progresszív és telecine-s" videók elkódolásához. mencoder dvd://1 -oac copy -vf pullup,softskip -ovc lavc -ofps 24000/1001 A -vf filmdint hasonló a -vf pullup-hoz: mindkét szűrő megpróbálja egyeztetni a mezőpárokat, hogy azok egy komplett képkockát adjanak. A filmdint deinterlace-lni fogja az egyedi mezőket, amelyeket nem tud egyeztetni, míg a pullup egyszerűen csak eldobja őket. A két szűrő különböző detektáló kódot alkalmaz és a filmdint néha túl kevés mezőt egyeztet. Az, hogy melyik szűrő a jobb, a bemeneti videótól és az egyéni ízléstől függ; kísérletezz szabadon a szűrők opcióinak finomhangolásával, ha valamelyikkel problémád van (lásd a man oldalt a részletekért). A legtöbb jól elkészített bemeneti videónál mindkettő eléggé jól működik, így bármelyik jó választás lehet a kezdéshez. mencoder dvd://1 -oac copy -vf filmdint -ovc lavc -ofps 24000/1001 A régebbi módszer, a telecine-s részek inverz-telecine-lése helyett a nem-telecine-s részek telecine-lése majd a teljes videó inverz-telecine-lése. Zavarosan hangzik? A softpulldown egy olyan szűrő, ami végigmegy a videón és a teljes fájlt telecine-li. Ha a softpulldown-t vagy detc vagy ivtc követi, a végső eredmény teljesen progresszív lesz. A -ofps 24000/1001 kapcsolót meg kell adni. mencoder dvd://1 -oac copy -vf softpulldown,ivtc=1 -ovc lavc -ofps 24000/1001 Két módon kezelheted ezt a kategóriát, mindkettő kompromisszum. Az időtartam/hely alapján kell döntened. Kezeld úgy, mintha progresszív lenne. Az átlapolt részek átlapoltnak látszanak és néhány átlapolt mezőt el kell dobni, ami egyenletlen ugrásokat eredményez. Használhatsz utófeldolgozó szűrőt, ha akarsz, de ez kissé rontja a progresszív részeket. Ez az opció használhatatlan akkor, ha a videót egy átlapolt eszközön akarod megjeleníteni (TV kártyával például). Ha átlapolt képkockáid vannak 24000/1001 képkocka per másodperces videóban, telecine-lve lesznek a progresszív képkockákkal együtt. Az átlapolt "képkockák" fele három mező hosszon lesz látható (3/(60000/1001) másodperc), ami ugráló "visszaugrás az időben" effektust hoz létre, ami nagyon rosszul néz ki. Ha mégis kísérletezel ezzel, használnod kell egy deinterlacing szűrőt, mint pl. az lb vagy az l5. Rossz ötlet a progresszív megjelenítéshez is. Eldobja az egymást követő átlapolt mezőpárokat, megszakítva ezzel a folyamatosságot, ami sokkal szembetűnőbb, mint a második módszer, ami néhány progresszív képkockát duplán mutat. A 30000/1001 képkocka per másodperces átlapolt videó amúgy is egy kicsit fodrozódó mert igazából 60000/1001 mező per másodperc sebességgel kellene megjeleníteni, így a duplikált képkockák nem látszanak annyira. Mindkét esetben érdemes megnézni a tartalmat és eldönteni, hogy hogyan szeretnéd megjeleníteni. Ha a videó 90%-ban progresszív és soha nem akarod TV-n lejátszani, akkor a progresszív megközelítést fogod előnyben részesíteni. Ha csak félig progresszív, akkor valószínűleg átlapoltként akarod elkódolni az egészet. Kezeld teljesen átlapoltként. A progresszív részekben néhány képkockát meg kell duplázni, ami egyenlőtlen ugrásokat eredményez. De hangsúlyozom, a deinterlacing szűrők rontják a progresszív részeket. A videó adatot a DVD-ken egy úgynevezett YUV 4:2:0 formátumban tárolják. A YUV videóban a luma ("fényerő") és a chroma ("szín") külön tárolódik. Mivel az emberi szem valamivel érzéketlenebb a színre, mint a fényerőre, a YUV 4:2:0 képen csak egy chroma pixel jut minden négy luma pixelre. Egy progresszív képen minden négy luma pixel által alkotott négyzetben (kettő mindkét oldalon) egy közös chroma pixel van. A progresszív YUV 4:2:0-t le kell vágnod páros felbontásúra és páros offszetet kell használnod. Például a crop=716:380:2:26 jó de a crop=716:380:3:26 nem. Ha átlapolt YUV 4:2:0-lal van dolgod, a szituáció egy kicsit bonyolódik. Ahelyett, hogy az egy képkockában lévő mind a négy luma pixel osztozna egy chroma pixelen, a mezőben lévő négy luma osztozik egy chroma pixelen. Ha a mezők át vannak lapolva egy képkocka felépítéséhez, minden egyes scanline egy pixel magas. Nos, ahelyett, hogy a négy luma pixel egy négyszögben lenne, két pixel van egymás mellett, a másik kettő két scanline-nal lejjebb van egymás mellett. A két luma pixel a közbeeső scanline-on a másik mezőből van és így egy másik chroma pixel tartozik hozzájuk és két darab, két scanline távolságra lévő luma pixel. Mindezen keverés teszi szükségessé azt, hogy a függőleges vágási dimenzióknak és az offszeteknek néggyel oszthatóaknak kell lenniük. A vízszintes maradhat páros. A telecine-lt videóknál javaslom, hogy a vágást az inverz telecine után ejtsd meg. Ha a videó már progresszív, csak páros számokkal el kell vágnod. Ha ki akarod használni azt a sebességnövekedést, amit a vágás rejteget magában, akkor függőlegesen négy többszörösével kell vágnod, különben az inverz-telecine szűrő nem kap megfelelő adatokat. Az átlapolt (nem telecine-lt) videónál függőlegesen mindig négy többszörösével kell vágnod, hacsak nem használod a -vf field-et a vágás előtt. Csak mert itt javasoltam az mbd=2-t, nem jelenti azt, hogy máshol ne lehetne használni. A trell-lel együtt az mbd=2 egyike a két libavcodec kapcsolóknak, amik legjobban növelik a minőséget és igazából mindig ajánlott ezt a kettőt használni, kivéve ha tilos a kódolási sebesség rontása (pl. valós idejű kódolás). Még számos egyéb opciója van a libavcodec-nek, ami növeli a kódolás minőségét (és csökkenti a kódolás sebességét) de az már túlmutat ezen dokumentum célkitűzésein. Bátran használhatod a pullup-ot (a softskippel együtt) a progresszív videókon és ez általában jó ötlet, hacsak a forrás nem egyértelműen teljesen progresszív. A teljesítmény veszteség kicsi az esetek többségében. Nagyon ritka kódolási esetekben a pullup a MEncoder 50%-os lassulását okozhatja. A zenefeldolgozás hozzáadása és a fejlett lavcopts háttérbe szorítja ezt a különbséget, a pullup miatti teljesítményromlást 2%-ra csökkentve. A libavcodec számos érdekes videó és audió formátumba történő egyszerű kódolást biztosít. A következő codec-ekbe kódolhatsz (többé-kevésbé friss lista): Videó codec neveLeírás mjpeg Motion JPEG ljpeg veszteségmentes JPEG jpegls JPEG LS targa Targa kép gif GIF kép bmp BMP kép png PNG kép h261 H.261 h263 H.263 h263p H.263+ mpeg4 ISO szabvány MPEG-4 (DivX, Xvid kompatibilis) msmpeg4 szabvány előtti MPEG-4 variáns az MS-től, v3 (AKA DivX3) msmpeg4v2 szabvány előtti MPEG-4 az MS-től, v2 (régi ASF fájlokban használják) wmv1 Windows Media Video, 1-es verzió (AKA WMV7) wmv2 Windows Media Video, 2-es verzió (AKA WMV8) rv10 RealVideo 1.0 rv20 RealVideo 2.0 mpeg1video MPEG-1 videó mpeg2video MPEG-2 videó huffyuv veszteségmentes tömörítés ffvhuff FFmpeg által módosított veszteségmentes huffyuv asv1 ASUS Video v1 asv2 ASUS Video v2 ffv1 az FFmpeg veszteségmentes videó codec-je svq1 Sorenson video 1 flv Flash Videókban használt Sorenson H.263 flashsv Flash Screen Video dvvideo Sony Digital Video snow az FFmpeg kísérleti wavelet-alapú codecja zmbv Zip Motion Blocks Video dnxhd AVID DNxHD Az első oszlop a codec neveket tartalmazza, amit a vcodec opció után kell megadni, például: -lavcopts vcodec=msmpeg4 Egy példa MJPEG tömörítéssel: mencoder dvd://2 -o title2.avi -ovc lavc -lavcopts vcodec=mjpeg -oac copy Audió codec neveLeírás ac3 Dolby Digital (AC-3) adpcm_* Adaptív PCM formátumok - lásd a mellékelt táblázatot flac Free Lossless Audio Codec (FLAC) g726 G.726 ADPCM libamr_nb 3GPP Adaptive Multi-Rate (AMR) narrow-band libamr_wb 3GPP Adaptive Multi-Rate (AMR) wide-band libfaac Advanced Audio Coding (AAC) - FAAC használatával libgsm ETSI GSM 06.10 full rate libgsm_ms Microsoft GSM libmp3lame MPEG-1 audio layer 3 (MP3) - LAME használatával mp2 MPEG-1 audio layer 2 (MP2) pcm_* PCM formats - lásd a mellékelt táblázatot roq_dpcm Id Software RoQ DPCM sonic kísérleti FFmpeg veszteséges codec sonicls kísérleti FFmpeg veszteségmentes codec vorbis Xiph Ogg Vorbis codec wmav1 Windows Media Audio v1 wmav2 Windows Media Audio v2 Az első oszlop a codec neveket tartalmazza, amit az acodec opció után kell megadni, például: -lavcopts acodec=ac3 Egy példa AC-3 tömörítéssel: mencoder dvd://2 -o title2.avi -oac lavc -lavcopts acodec=ac3 -ovc copy Ellentétben a libavcodec videó codec-jeivel, az audió codec-jei nem használnak el annyi bit-et, amennyit szánsz nekik, mivel hiányzik belőlük némi minimális pszichoakusztikus modell (ha van egyáltalán), ami a legtöbb egyéb codec implementációban benne van. Azonban vedd figyelembe, hogy ezek az audió codec-ek nagyon gyorsak és azonnal használhatóak bárhol, ahol a MEncodert a libavcodec-kel együtt fordították le (ami a legtöbb esetben így van), és nem függ külső függvénykönyvtáraktól. PCM/ADPCM codec neveLeírás pcm_s32le előjeles 32-bit-es little-endian pcm_s32be előjeles 32-bit-es big-endian pcm_u32le előjel nélküli 32-bit-es little-endian pcm_u32be előjel nélküli 32-bit-es big-endian pcm_s24le előjeles 24-bit-es little-endian pcm_s24be előjeles 24-bit-es big-endian pcm_u24le előjel nélküli 24-bit-es little-endian pcm_u24be előjel nélküli 24-bit-es big-endian pcm_s16le előjeles 16-bit-es little-endian pcm_s16be előjeles 16-bit-es big-endian pcm_u16le előjel nélküli 16-bit-es little-endian pcm_u16be előjel nélküli 16-bit-es big-endian pcm_s8 előjeles 8-bit-es pcm_u8 előjel nélküli 8-bit-es pcm_alaw G.711 A-LAW pcm_mulaw G.711 μ-LAW pcm_s24daud előjeles 24-bit-es D-Cinema Audio formátum pcm_zork Activision Zork Nemesis adpcm_ima_qt Apple QuickTime adpcm_ima_wav Microsoft/IBM WAVE adpcm_ima_dk3 Duck DK3 adpcm_ima_dk4 Duck DK4 adpcm_ima_ws Westwood Studios adpcm_ima_smjpeg SDL Motion JPEG adpcm_ms Microsoft adpcm_4xm 4X Technologies adpcm_xa Phillips Yellow Book CD-ROM eXtended Architecture adpcm_ea Electronic Arts adpcm_ct Creative 16->4-bit adpcm_swf Adobe Shockwave Flash adpcm_yamaha Yamaha adpcm_sbpro_4 Creative VOC SoundBlaster Pro 8->4-bit adpcm_sbpro_3 Creative VOC SoundBlaster Pro 8->2.6-bit adpcm_sbpro_2 Creative VOC SoundBlaster Pro 8->2-bit adpcm_thp Nintendo GameCube FMV THP adpcm_adx Sega/CRI ADX Ideális esetben szeretnéd, ha csak azt kellene mondani a kódolónak, hogy váltson "jobb minőségre" és kész. Ez szép is lenne, de sajnos nehezen megvalósítható, mert a különböző kódolási opciók különböző minőséget eredményeznek, mely függ a forrás anyagtól is. Ez azért van, mert a tömörítés függ a szóbanforgó videó vizuális tulajdonságaitól. Például az Anime és az élő felvétel két nagyon különböző anyag és így különböző opciókat követelnek meg az optimális kódoláshoz. A jó hír, hogy néhány opciót soha sem lehet elhagyni, mint például az mbd=2, trell és v4mv. Olvass tovább a gyakori kódolási opciók leírásához. vmax_b_frames: 1 vagy 2 a jó, a filmtől függően. Figyelj rá, hogy úgy kell kódolnod, hogy DivX5-tel dekódolható legyen az eredmény, aktiválnod kell a zárt GOP támogatást a libavcodec cgop opciójával, de ki kell kapcsolnod a jelenet detektálást, ami nem túl jó ötlet, mivel rontja a kódolási hatékonyságot egy kicsit. vb_strategy=1: segít a gyors mozgású jeleneteknél. Néhány videónál a vmax_b_frames rontja a minőséget, de a vmax_b_frames=2 a vb_strategy=1-gyel együtt segít. dia: mozgás kereső tartomány. A nagyobb a jobb és a lassabb. Negatív értékek teljesen más skálát adnak. A jó értékek -1 a gyors kódoláshoz vagy 2-4 a lassabbhoz. predia: mozgás kereső előre-lépés. Nem olyan fontos, mint a dia. Jó értékek 1-től (alapértelmezett) 4-ig. preme=2 kell hozzá, hogy igazán hasznos legyen. cmp, subcmp, precmp: Összehasonlító funkciók a mozgás becsléshez. Kísérletezz a 0 (alapértelmezett), 2 (hadamard), 3 (dct) és 6 (ráta torzítás) értékekkel! 0 a leggyorsabb és és elegendő a precmp-hez. A cmp-hez és subcmp-hez 2 jó, ha Anime és 3 ha élő akció. A 6 vagy jobb vagy nem, de mindenképpen lassabb. last_pred: Az előző képkockából megjósolandó mozgások száma. 1-3 vagy hasonló segít egy kis sebességcsökkenés árán. A magasabb értékek lassúak, de igazi hasznuk nincs. cbp, mv0: A makroblokkok kiválasztását irányítja. Egy kis sebességcsökkenés egy kis minőségjavulásért. qprd: adaptív kvantálás, mely a makroblokk komplexitásán alapul. Vagy segít vagy nem, a videó és egyéb opciók függvényében. Ennek lehetnek mellékhatásai, hacsak nem állítod be a vqmax-ot valami ésszerűen alacsony értékre (a 6 jó, talán minimum 4); a vqmin=1 is segíthet. qns: nagyon lassú, különösen ha a qprd-vel kombinálod. Ezen opció hatására a kódoló minimalizálja a zajt tömörítési mellékhatásokkal, ahelyett, hogy a szigorúan a forráshoz próbálna igazodni. Ne használd ezt, csak ha már minden mást kipróbáltál és az eredmény még mindig nem elég jó. vqcomp: Rátaírányítás beállítása. Hogy milyen értékek jók, az a filmtől függ. Nyugodtan elhagyhatod ezt, ha akarod. A vqcomp csökkentése több bitet engedélyez az alacsony komplexitású részeknél, a növelése a nagy komplexitású részekre teszi őket (alapértelmezés: 0.5, tartomány: 0-1, javasolt tartomány: 0.5-0.7). vlelim, vcelim: Beállítja a szimpla együttható eliminációs küszöböt a fényerősséghez és a chroma plane-khez. Ezt elkülönítve kódolja le minden MPEG-szerű algorítmus. Az ötlet emögött az opció mögött az, hogy egy jó heurisztikát használnak annak megállapítására, hogy a blokkban történt változás kisebb-e, mint az általad megadott küszöb és ebben az esetben egyszerűen "változtatás nélkül" kerül elkódolásra a blokk. Ez biteket ment meg és talán gyorsít is a kódoláson. A vlelim=-4 és vcelim=9 látszólag jók az élő filmekhez, de nem segítenek az Anime-nál; ha animációt kódolsz, inkább hagyd őket változatlanul. qpel: Negyed pixel mozgás becslés. Az MPEG-4 fél pixeles precíziót használ a mozgáskereséshez alapértelmezésként, ezért ez az opció plusz terhelést hoz, mivel több információ tárolódik az elkódolt fájlban. A tömörítési nyereség/veszteség a filmtől függ, de általában nem hatékony Anime-oknál. A qpel mindig jelentős dekódolási CPU idő igénnyel jár (+25% a gyakorlatban). psnr: nem érinti az aktuális kódolást, de készít egy log fájlt, mely megadja minden képkocka típusát/méretét/minőségét és a végére odaírja a PSNR-t (Peak Signal to Noise Ratio, Zajarány csúcspontja). vme: Az alapértelmezett a legjobb. lumi_mask, dark_mask: Pszichovizuális adaptív kvantálás. Ne játszadozz ezekkel az opciókkal, ha számít a minőség. Az ésszerű értékek jók lehetnek a te esetedben, de vigyázz, ez nagyon szubjektív. scplx_mask: Megpróbálja megelőzni a blokkos mellékhatásokat, de az utófeldolgozás jobb. A következő beállítások példák különböző kódolási opciók kombinációjára, amik a sebesség vs minőség kérdést döntően befolyásolják ugyanazon cél bitráta mellett. Az összes kódolási beállítást egy 720x448 @30000/1001 fps-es példa videón teszteltük, a cél bitráta 900kbps volt, a gép pedig egy AMD-64 3400+ 2400 MHz-en 64 bites módban. Mindegyik kódolási beállítás tartalmazza a kódolási sebességet (képkocka per másodpercben) és a PSNR veszteséget (dB-ben) a "nagyon jó minőséghez" viszonyítva. Kérlek vedd figyelembe, hogy a forrásanyagodtól, a géped típusától és a fejlesztésektől függően különböző eredményeket kaphatsz. Leírás Kódolási opciók sebesség (fps-ben) Relatív PSNR veszteség (dB-ben) Nagyon jó minőség vcodec=mpeg4:mbd=2:mv0:trell:v4mv:cbp:last_pred=3:predia=2:dia=2:vmax_b_frames=2:vb_strategy=1:precmp=2:cmp=2:subcmp=2:preme=2:qns=2 6fps 0dB Jó minőség vcodec=mpeg4:mbd=2:trell:v4mv:last_pred=2:dia=-1:vmax_b_frames=2:vb_strategy=1:cmp=3:subcmp=3:precmp=0:vqcomp=0.6:turbo 15fps -0.5dB Gyors vcodec=mpeg4:mbd=2:trell:v4mv:turbo 42fps -0.74dB Valós idejű vcodec=mpeg4:mbd=2:turbo 54fps -1.21dB A libavcodec ezen képességével egyedi inter (I-frame/kulcs frame) és intra (P-frame/jósolt frame) matricákat állíthatsz be. Több codec támogatja ezt: az mpeg1video és mpeg2video a jelentések szerint működik. Ennek egy tipikus felhasználása a KVCD által javasolt matricák beállítása. Egy KVCD "Notch" Kvantálási Mátrix: Intra: 8 9 12 22 26 27 29 34 9 10 14 26 27 29 34 37 12 14 18 27 29 34 37 38 22 26 27 31 36 37 38 40 26 27 29 36 39 38 40 48 27 29 34 37 38 40 48 58 29 34 37 38 40 48 58 69 34 37 38 40 48 58 69 79 Inter: 16 18 20 22 24 26 28 30 18 20 22 24 26 28 30 32 20 22 24 26 28 30 32 34 22 24 26 30 32 32 34 36 24 26 28 32 34 34 36 38 26 28 30 32 34 36 38 40 28 30 32 34 36 38 42 42 30 32 34 36 38 40 42 44 Használat: mencoder input.avi -o output.avi -oac copy -ovc lavc \ -lavcopts inter_matrix=...:intra_matrix=... mencoder input.avi -ovc lavc -lavcopts \ vcodec=mpeg2video:intra_matrix=8,9,12,22,26,27,29,34,9,10,14,26,27,29,34,37,\ 12,14,18,27,29,34,37,38,22,26,27,31,36,37,38,40,26,27,29,36,39,38,40,48,27,\ 29,34,37,38,40,48,58,29,34,37,38,40,48,58,69,34,37,38,40,48,58,69,79\ :inter_matrix=16,18,20,22,24,26,28,30,18,20,22,24,26,28,30,32,20,22,24,26,\ 28,30,32,34,22,24,26,30,32,32,34,36,24,26,28,32,34,34,36,38,26,28,30,32,34,\ 36,38,40,28,30,32,34,36,38,42,42,30,32,34,36,38,40,42,44 -oac copy -o svcd.mpg Nos hát, éppen most vetted meg a Harry Potter és a titkok kamrája gyönyörű új példányát (widescreen edition természetesen) és le akarod rip-pelni ezt a DVD-t, hogy hozzáadhasd a PC-s házimozidhoz. Ez egy régió 1-es DVD, így NTSC-s. Az alábbi példa egyszerűen alkalmazható PAL-ra is, a -ofps 24000/1001 kapcsoló elhagyásával (mert a kimeneti frameráta ugyan annyi, mint a bemeneti) és természetesen a vágás méretei is mások lesznek. Miután lefuttattad az mplayer dvd://1 parancsot, kövesd a mit kezdjünk a telecine-nel és az átlapolással NTSC DVD-ken részben leírt utasításokat és fedezd fel, hogy ez egy 24000/1001 fps-es progresszív videó, ami azt jelenti, hogy nem kell inverz telecine szűrőt használnod, mint pl. a pullup vagy a filmdint. Következőnek megállapítjuk a megfelelő vágási téglalapot, így használjuk a cropdetect szűrőt: mplayer dvd://1 -vf cropdetect Győződj meg róla, hogy egy teljesen kitöltött képkockán állsz (pl. egy világos jelenet a nyitó képek és logók után), ezt fogod látni az MPlayer konzol kimenetén: crop area: X: 0..719 Y: 57..419 (-vf crop=720:362:0:58) Ezután lejátszuk a filmet ezzel a szűrővel a számok ellenérzéséhez: mplayer dvd://1 -vf crop=720:362:0:58 És azt látjuk, hogy tökéletesen megfelel. Majd meggyőződünk, hogy a szélesség és a magasság osztható 16-tal. A szélesség jó, de a magasság nem. Mivel nem buktunk hetedik osztályban matekból, tudjuk, hogy a 16 legközelebbi többszöröse, ami kisebb, mint 362, a 352. Így egyszerűen használhatjuk a crop=720:352:0:58 opciót, de jó lenne egy kicsit lecsípni a telejéből és az aljából, hogy középen maradjunk. Összehúzzuk a magasságot 10 pixellel, de nem akarjuk növelni az y-offszetet 5 pixellel, mert az páratlan szám és rontja a minőséget. Helyette inkább 4 pixellel növeljük az y-offszetet: mplayer dvd://1 -vf crop=720:352:0:62 A másik ok, hogy lecsípjünk pixeleket mid fent, mint lent, hogy biztosak legyünk, hogy a fél-fekete pixeleket is levágtuk, amennyiben vannak. Figyelj rá, hogy ha a videó telecine-lt, a pullup szűrő (vagy bármelyik inverz telecine szűrő, amit használsz) a vágás előtt szerepeljen a szűrők láncában. Ha átlapolt, végezz deinterlace-t a vágás előtt. (Ha úgy döntesz, hogy megtartod az átlapolt videót, győződj meg róla, hogy a függőleges vágási offszet 4 többszöröse.) Ha érdekel annak a 10 pixelnek az elvesztése, inkább a méretek 16 legközelebbi többszörösére való kicsinyítése érdekelhet. A szűrő lánc ez esetben: -vf crop=720:362:0:58,scale=720:352 A videó ilyen módon történő lekicsinyítése azt jelenti, hogy néhány apró részlet elveszik, de ez valószínűleg nem lesz észrevehető. A nagyítás rosszabb minőséget eredményez (hacsak nem növeled a bitrátát). A vágás az összes ilyen pixeltől megszabadít. Ez egy üzlet, amit minden esetben meg kell fontolnod. például ha a DVD videó televízióra készült, ajánlott elkerülni a függőleges méretezést, mert a sor mintázás az eredeti felvételhez igazodik. Megtekintés után azt látjuk, hogy a filmünk eléggé eseménydús és nagyon részletes, így 2400Kbit-et választunk bitrátának. Most már készen vagyunk a két lépéses kódoláshoz. Első lépés: mencoder dvd://1 -ofps 24000/1001 -oac copy -o Harry_Potter_2.avi -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:autoaspect:vpass=1 \ -vf pullup,softskip,crop=720:352:0:62,hqdn3d=2:1:2 A második lépés ugyan ez, csak megadjuk a vpass=2-t: mencoder dvd://1 -ofps 24000/1001 -oac copy -o Harry_Potter_2.avi -ovc lavc \ -lavcopts vcodec=mpeg4:vbitrate=2400:v4mv:mbd=2:trell:cmp=3:subcmp=3:autoaspect:vpass=2 \ -vf pullup,softskip,crop=720:352:0:62,hqdn3d=2:1:2 A v4mv:mbd=2:trell kapcsolók nagyban javítják a minőséget a kódolási idő rovására. Nem ajánlott ezen opciók elhagyása, ha a fő cél a jó minőség. A cmp=3:subcmp=3 opciók egy összehasonlító függvényt választanak ki, ami jobb minőséget biztosít, mint az alapértelmezettek. Ezzel a paraméterrel is kísérletezhetsz (lásd a man oldalt a lehetséges értékekért), mivel a különböző függvények nagyban befolyásolják a minőséget a forrás anyagtól függően. Például ha úgy találod, hogy a libavcodec túl kockás eredményt ad, megpróbálhatod a kísérleti NSSE összehasonlító függvény használatát a *cmp=10 opcióval. Ennél a filmnél a keletkező AVI 138 perc hosszú lesz és közel 3 GB-os. És mivel azt mondtuk, hogy a fájl méret nem számít, ez egy tökéletesen megfelelő méret. De ha kisebbet szeretnél, próbálj ki egy alacsonyabb bitrátát. A bitráták növelése csökkenő mértékű javulást hoz, így pl. tisztán kivehető a különbség az 1800Kbit és a 2000Kbit között, szinte észrevehetetlen 2000Kbit felett. Nyugodtan kísérletezz, amíg csak kedved tartja. Mivel a forrás videót áteresztettük a zajeltávolító szűrőn, talán egy picit vissza akarsz tenni a lejátszás közben. Ez, az spp utófeldolgozó szűrővel drasztikusan javítja a felfogható minőséget és segít a segít a videó kockásodásának megszüntetésében. Az MPlayer autoq opciójával szabályozhatod az spp szűrő utófeldolgozásának mértékét a CPU-tól függően. Emellett valószínűleg gamma és/vagy szín korrekciót is szeretnél csinálni, hogy jobban illeszkedjen a monitorodhoz. Például: mplayer Harry_Potter_2.avi -vf spp,noise=9ah:5ah,eq2=1.2 -autoq 3 Az Xvid egy szabad függvénykönyvtár MPEG-4 ASP videó stream-ek elkódolásához. A kódolás megkezdése előtt be kell állítanod a MEncoderben a támogatását. Ez a leírás főként hasonló információkat szeretne nyújtani, mint az x264 kódolási leírás. Ezért, kérlek kezdd azzal, hogy elolvasod azon leírásnak az első részét. Kezdésként nézd át az MPlayer man oldalának Xvid részét! Ez a rész csak a man oldal kiegészítéseként használható. Az Xvid alapértelmezett beállításai egyensúlyt teremtenek a sebesség és a minőség között, így nyugodtan használhatod azokat, ha a következő rész túl zavarosnak tűnik. vhq Ez a beállítás a makroblokk döntési algoritmust érinti, minél nagyobb a beállítás, annál okosabb a döntés. Az alapértelmezett érték bátran használható minden kódoláshoz, míg a nagyobb értékek segítik a PSNR-t de jelentősen lassabbak. Kérlek vedd figyelembe, hogy a jobb PSNR nem feltétlenül jelenti azt, hogy a kép jobban fog kinézni, de közelebb lesz az eredetihez. A kikapcsolása észrevehetően felgyorsítja a kódolást; ha a sebesség kritikus számodra, megéri a cserét. bvhq Ez ugyan azt csinálja, mint a vhq, de a B-kockákon. Elhanyagolható a hatása a sebességre és kismértékben javít a minőségen (+0.1dB PSNR körül). max_bframes Az egymás után engedélyezett több B-kocka általában javítja a tömöríthetőséget, de több blokkosodási mellékhatást okoz. Az alapértelmezett beállítás jó kompromisszum a tömöríthetőség és a minőség között, de növelheted 3-ig ha ki vagy éhezve a bitrátára. Csökkentheted 1-re vagy 0-ra ha a tökéletes minőséget céloztad meg, de ekkor biztosan tudnod kell, hogy a forrásod bitrátája elég nagy ahhoz, hogy a kódolónak nem kell növelni a kvantálást, hogy elére ezt. bf_threshold Ez a kódoló B-kocka érzékenységét szabályozza, a nagyobb érték hatására több B-kockát használ (és fordítva). Ez a beállítás a max_bframes-szel együtt használható; ha bitráta éhségben szenvedsz, növelned kell mind a max_bframes, mind a bf_threshold értékét, míg ha növeled a max_bframes-t és csökkented a bf_threshold-ot, akkor a kódoló több B-kockát fog használni, de csak azokon a helyeken, ahol tényleg szükséges. A max_bframes alacsony értéke és a bf_threshold magas értéke nem túl bölcs döntés, mert ez arra kényszeríti a kódolót, hogy olyan helyekre is tegyen B-kockát, ahol nincs rájuk szükség, így csökkenti a vizuális minőséget. De ha kompatibilis akarsz maradni az egyedi lejátszókkal, amik csak a régi DivX profilokat támogatják (amik csak legfeljebb 1 B-kockát támogatnak sorban), ez az egyetlen lehetőséged a tömöríthetőség növelésére a B-kockák használatával. trellis Optimalizálja a kvantálási eljárást, hogy optimális arányt találjon a PSNR és a bitráta között, ami jelentős bitmegtakarítást engedélyez. Cserébe ezek a bitek a videóban máshol kerülnek felhasználásra, növelve az össz minőséget. Mindig ajánlott bekapcsolva hagyni, mert jelentősen befolyásolja a minőséget. Még ha neked a sebesség számít, akkor is ne kapcsold ki, amíg nem kapcsoltad ki a vhq-t és a többi CPU-éhes opciót nem állítottad a minimumra. hq_ac Bekapcsol egy jobb együttható kölcségbecslő módszert, ami kissé csökkenti a fájl méretet, kb. 0,15-0,19% között (ami kevesebb, mint 0,01dB-es PSNR növekedésnek felel meg), miközben jelentéktelen hatása van a sebességre. Ezért ajánlott mindig bekapcsolva hagyni. cartoon A rajzfilm tartalom jobb kódolására lett kitalálva és nincs hatása a sebességre, mivel csak a döntési heurisztikát tuningolja az ilyen típusú tartalomnál. me_quality Ez a beállítás a mozgás előrejelzés pontosságát vezérli. Minél nagyobb a me_quality érték, annál pontosabb lesz az eredeti mozgás előrejelzése és minél pontosabb ez, annál jobban közelíti majd az eredmény az eredeti mozgást. Az alapértelmezett érték jó a legtöbb esetben; így nem javasolt a változtatása, csak ha tényleg a sebesség számít, mivel minden a mozgás becslésével megmentett bit másra lesz felhasználva, növelve az össz minőséget. Ezért ne menj 5 alá és ezt is csak végszükség esetén állítsd be. chroma_me Javítja a mozgás előrejelzést úgy, hogy a számításba beleveszi a chroma (szín) információkat is, míg a me_quality csak a luma-t (grayscale) használja. Ez 5-10%-kal lassítja a kódolást, de eléggé javítja a vizuális minőséget a blokkosodási effektusok csökkentésével és csökkenti a fájl méretet kb. 1,3%-kal. Ha a sebesség érdekel, kapcsold ki ezt az opciót, mielőtt elkezdenél töprengeni a me_quality csökkentésén. chroma_opt A chroma képek minőségének javítása a célja az egyszerű fehér/fekete sarkoknál a tömörítés javítása helyett. Ezzel csökkentheted a "red stairs" effektust. lumi_mask Megpróbál kevesebb bitrátát adni a kép azon részeinek, amiket az emberi szem nem lát olyan jól, így a kódolónak lehetősége van a megspórolt biteket a kép sokkal fontosabb részeinél felhasználni. Ezen opció nyeresége a kódolás minőségének szempontjából erősen függ az egyéni beállításoktól és a megtekintéshez használt monitor típusától és beállításaitól (tipikusan egy világosabb vagy TFT monitoron nem fog olyan jól kinézni). qpel Növeli a várható mozgásvektorok számát a mozgás előrejelzés pontosságának növelésével halfpel-ről quarterpel-re. Az ötlet annyi, hogy a jobb mozgásvektorokért cserébe csökken a bitráta (ezért nő a minőség). Habár a quarterpel pontosságú mozgásvektorok kódolásához egy kicsivel több bit kell, a várható vektorok nem mindig adnak (sokkal) jobb minőséget. Elég gyakran a codec még mindig biteket biztosít az extra pontossághoz, de csak kicsi vagy semmilyen minőségi nyereség nincs cserében. Sajnos, nem lehet előre megmondani a qpel lehetséges nyereségeit, így kódolnod kell vele is és nélküle is, hogy biztosan tudd. A qpel majdnem dupla kódolási időt jelent és 25%-kal több feldolgozási erőforrást igényel a dekódolása. Nem minden asztali lejátszó támogatja. gmc Biteket próbál megspórolni bizonyos jeleneteknél úgy, hogy egy mozgásvektort használ az egész kockához. Ez majdnem mindig növeli a PSNR-t, de jelentősen lelassítja a kódolást (és a dekódolást is). Ezért csak akkor ajánlott használnod, ha a vhq a maximumra állítottad. Az Xvid GMC-je sokkal kifinomultabb, mint a DivX-é, de csak kevés lejátszó támogatja. Az Xvid támogatja a kódolási profilokat a profile opción keresztül, amivel az XVid videó folyam tulajdonságaiban olyan megszorításokat lehet előírni, amikkel az lejátszható marad az összes eszközön, ami támogatja a választott profilt. A megkötések a felbontásra, a bitrátára és bizonyos MPEG-4-es funkciókra vonatkoznak. A következő táblázat megmutatja, hogy melyik profil mit támogat. Szimpla Fejlett szimpla DivX Profil neve 0 1 2 3 0 1 2 3 4 5 Handheld Hordozható NTSC Hordozható PAL NTSC házimozi PAL házimozi HDTV Szélesség [pixelben] 176 176 352 352 176 176 352 352 352 720 176 352 352 720 720 1280 Magasság [pixelben] 144 144 288 288 144 144 288 288 576 576 144 240 288 480 576 720 Frame ráta [fps] 15 15 15 15 30 30 15 30 30 30 15 30 25 30 25 30 Max átlagos bitráta [kbps] 64 64 128 384 128 128 384 768 3000 8000 537.6 4854 4854 4854 4854 9708.4 Átlagos csúcs bitráta 3 mp-n keresztül [kbps] 800 8000 8000 8000 8000 16000 Max. B-frame 0 0 0 0 0 1 1 1 1 2 MPEG kvantálás X X X X X X Adaptív kvantálás X X X X X X X X X X X X Átlapolt kódolás X X X X X X X X X Quarterpixel X X X X X X Globális mozgás-kompenzáció X X X X X X A következő beállítások példák különböző kódolási opciók kombinációjára, amik a sebesség vs minőség kérdést döntően befolyásolják ugyanazon cél bitráta mellett. Az összes kódolási beállítást egy 720x448 @30000/1001 fps-es példa videón teszteltük, a cél bitráta 900kbps volt, a gép pedig egy AMD-64 3400+ 2400 MHz-en 64 bites módban. Mindegyik kódolási beállítás tartalmazza a kódolási sebességet (képkocka per másodpercben) és a PSNR veszteséget (dB-ben) a "nagyon jó minőséghez" viszonyítva. Kérlek vedd figyelembe, hogy a forrásanyagodtól, a géped típusától és a fejlesztésektől függően különböző eredményeket kaphatsz. LeírásKódolási opcióksebesség (fps-ben)Relatív PSNR veszteség (dB-ben) Nagyon jó minőség chroma_opt:vhq=4:bvhq=1:quant_type=mpeg 16fps 0dB Jó minőség vhq=2:bvhq=1:chroma_opt:quant_type=mpeg 18fps -0.1dB Gyors turbo:vhq=0 28fps -0.69dB Valós idejű turbo:nochroma_me:notrellis:max_bframes=0:vhq=0 38fps -1.48dB Az x264 egy szabad függvénykönyvtár a H.264/AVC videó folyamok kódolásához. Mielőtt elkezdenél kódolni, be kell állítanod a MEncoderben a támogatását. Kérlek kezd az olvasást az MPlayer man oldalának x264 részével. Ez a rész a man oldal kiegészítésének lett szánva. Itt csak rövid tanácsokat találhatsz, hogy mely opciók érdekelhetik a letöbb embert. A man oldal tömörebb, de ugyanakkor kimerítőbb is és esetenként több technikai információval szolgál. Ez a leírás a kódolási opciók két fő kategóriáját tárgyalja: Opciók, melyekkel a kódolási idő vs. minőség arány szabályozható Opciók, melyek a különböző egyéni érdekeknek és speciális igényeknek próbálnak eleget tenni Igazából csak te tudod, hogy mely opciók a legjobbak neked. Az első csoportba tartozó opcióknál könnyű dönteni: csak azt kell megfontolnod, hogy a minőségi különbség megéri-e a sebességbeli különbséget. A másik csoport már sokkal szubjektívebb és több szempontot kell figyelembe venni. Tartsd észben, hogy az "egyéni érdekek és speciális igényeknek" eleget tevő opciók jelentősen befolyásolják a sebességet vagy a minőséget, de elsősorban nem ezért használják őket. Az "egyéni érdekek" opciói közül több olyan változásokat idézhet elő, ami néhány embernek tetszhet, míg másoknak nem. Mielőtt folytatnád, meg kell értened, hogy ez a leírás csak egy minőségi mércét használ: a globális PSNR-t. A PSNR rövid leírása megtalálható a Wikipedia PSNR-ről szóló cikkében. A globális PSNR az utolsó PSNR szám, amit kiír az x264encopts, ha megadod neki a psnr opciót. Bármikor, amikor egy kijelentést olvasol a PSNR-ről, él az a feltételezés, hogy azonos bitrátát használsz. Ezen leírás majdnem teljesen egészében feltételezi, hogy két lépéses kódolást használsz. Az opciók összehasonlításánál két fő érv szól a kétlépéses kódolás mellett. Az egyik, hogy a két lépés alkalmazása kb. 1dB PSNR-t jelent pluszban, ami nagyon nagy különbség. A másik, hogy az opciók tesztelésénél a direkt minőség-összehasonlítás az egy lépéses kódolásokkal behoz egy zavaró tényezőt: a bitráta gyakran jelentősen változik a kódolások között. Nem minden esetben könnyű megmondani, hogy a minőségi változás a megváltozott opciók miatt következett-e be vagy a főként véletlenül elért bitráta különbségből adódik. subq: Azon opciók közül, amik segítségével a sebesség és minőség közötti arányt befolyásolhatod, a subq és a frameref (lásd lejjebb) a legfontosabbak általában. Ha érdekel akár a sebesség, akár a minőség tuningolása, akkor ezt a két opciót kell először megvizsgálnod. Sebesség szempontjából a frameref és a subq opciók elég erőteljes kölcsönhatásban vannak. A tapasztalatok szerint egy referencia kockával a subq=5 (alapértelmezett érték) kb. 35%-kal több időt kíván, mint a subq=1. 6 referencia kockával az igény 60% fölé megy. A subq hatása a PSNR-re elég egyenletes, a referencia kockák számától függetlenül. Általában a subq=5 0.2-0.5 dB-vel magasabb globális PSNR-t biztosít a subq=1-gyel összehasonlítva. Általában ez már látható különbség. A subq=6 lassabb, de jobb minőséget ad elfogadható áron. A subq=5-tel összehasonlítva általában 0.1-0.4 dB nyereséget jelent a globális PSNR-ben, 25%-100% között változó sebességveszteség árán. A subq egyéb értékeitől eltérően a subq=6 viselkedése nem függ olyan nagy mértékben a frameref és a me opcióktól. A subq=6 hatékonysága inkább a használt B-kockák számától függ. Normális használat esetén ez azt jelenti, hogy a subq=6-nak nagy hatása van mind a sebességre, mint a minőségre az összetett, sok mozgást tartalmazó jelenetek esetében, de sokkal kevesebb a kevés mozgást rögzítő részeknél. Jegyezd meg, hogy még mindig javasoljuk a bframes értékének valamilyen nullától különböző értékre történő állítását (lásd lejjebb). subq=7 a leglassabb, legjobb minőséget nyújtó mód. A subq=6-tal összehasonlítva általában 0.01-0.05 dB globális PSNR növelést jelent, változó 15%-33%-os sebességveszteség árán. Mivel a kódolási idő vs. minőség arány eléggé rossz, csak akkor ajánlott használni, ha minden egyes bit fontos és a kódolási idő nem számít. frameref: A frameref alapértéke 1, de ez nem jelenti azt, hogy jó dolog 1-re állítani. Pusztán a frameref növelése 2-re kb. 0.15dB PSNR nyereséget jelent 5-10%-os sebességcsökkenéssel; ez így még jó üzletnek tűnik. A frameref=3 0.25dB PSNR-t hoz a frameref=1-hez képest, ami látható különbség. A frameref=3 kb. 15%-kal lassabb a frameref=1-nél. Ezután sajnos gyorsan jön a csökkenés. A frameref=6 valószínűleg csak 0.05-0.1 dB pluszt jelent a frameref=3-hoz képest, további 15% sebességveszteség mellett. frameref=6 felett a minőségjavulás általában nagyon kicsi (bár vedd figyelembe az egész rész olvasása közben, hogy ez nagymértékben változhat a forrásodtól függően). Egy átlagos esetben a frameref=12 a globális PSNR-t csekély 0.02dB-vel javítja a frameref=6-hoz képest, 15%-20% sebességveszteség árán. Az ilyen magas frameref értékeknél az egyedüli igazán jó dolog, amit mondhatunk, hogy a további növelés szinte soha sem árt a PSNR-nek, de a minőségi javulás szinte alig mérhető és nem is észrevehető. A frameref növelése szükségtelenül magas értékekre ronthatja és általában rontja is a kódolási hatékonyságot, ha kikapcsolod a CABAC-ot. Bekapcsolt CABAC-kal (alapértelmezett), a frameref "túl magas" értékre történő beállítása jelenleg nagyon távolinak tűnik ahhoz, hogy aggódjunk miatta és a jövőben az optimalizációk lehet, hogy meg is szüntetik ennek lehetőségét. Ha számít a sebesség, akkor megfontolandó, hogy alacsony subq és frameref értékeket használj az első lépésben és majd a második lépésben emeld. Általában ez jelentéktelen negatív hatással van a végső minőségre: valószínűleg jóval kevesebb, mint 0.1dB PSNR-t veszítesz, ami túl kicsi különbség ahhoz, hogy észrevedd. Bár a frameref különböző értékei alkalmanként befolyásolhatják a képkocka típus döntéseket. Ezek legtöbbször ritka, szélsőséges esetek, de ha teljesen biztos akarsz lenni, gondolkozz el rajta, hogy van-e a videódban teljes képernyős ismétlődő, csillogó minta vagy nagyon nagy ideiglenes elzáródás, ami kikényszeríthet egy I-kockát. Az első lépés frameref-jét úgy állítsd be, hogy elég nagy legyen ahhoz, hogy tartalmazza a villódzási ciklust (vagy az elzárást). Például ha a jelenet oda-vissza ugrál két kép között három keret idejéig, állítsd be az első lépés frameref-jét 3-ra vagy magasabbra. Ez a dolog eléggé ritka az élő akciót tartalmazó videóanyagokban, de néha előjön videójátékok képének mentésekor. me: Ez az opció a mozgásbecsléshez használt keresés módszerét választja ki. Ezen opció megváltoztatása természetesen magával hozza a minőség-vs-sebesség arány változását. A me=dia csak kis mértékben gyorsabb, mint az alapértelmezett keresés, kevesebb, mint 0.1dB globális PSNR árán. Az alapértelmezett beállítás (me=hex) egy ésszerű kompromisszum a sebesség és a minőség között. A me=umh kicsivel kevesebb, mint 0.1dB globális PSNR-t jelent, amiért változó árat kell fizetni a sebességben a frameref-től függően. Ha a frameref értéke nagy (pl. 12 vagy hasonló), a me=umh kb. 40%-kal lassabb, mint az alapértelmezett me=hex. frameref=3-mal a sebességbeli veszteség visszaesik 25%-30%-ra. A me=esa egy nagyon alapos keresést használ, ami túl lassú a gyakorlati alkalmazáshoz. partitions=all: Ez az opció engedélyezi a 8x4-es, 4x8-as és 4x4-es alpartíciók használatát a megjósolt makroblokkokban (az alapértelmezett partíciók mellett). A bekapcsolása viszonylag egyenletes 10%-15%-os sebességveszteséget jelent. Ez az opció eléggé hasztalan a kevés mozgást tartalmazó videókban, bár néhány gyors mozgású forrás, tipikusan a sok apró mozgó objektumot tartalmazó, várhatóan kb. 0.1dB-t javul. bframes: Ha kódoltál már más codec-kel, rájöhettél, hogy a B-kockák nem mindig hasznosak. A H.264-nél ez megváltozott: új technikák és blokk típusok lehetnek a B-kockákban. Általában még a naív B-kocka választó algoritmus is jelentős PSNR hasznot hozhat. Azt is érdemes megjegyezni, hogy a B-kockák használata általában egy kicsit gyorsít a második lépésen és talán az egy lépéses kódolást is gyorsítja kicsit, ha az adaptív B-kocka döntés ki van kapcsolva. Az adaptív B-kocka döntés kikapcsolásával (x264encopts nob_adapt opciója) ezen beállítás optimális értéke általában nem több, mint bframes=1, különben a gyors mozgású részek romolhatnak. Bekapcsolt adaptív B-kocka döntéssel (alapértelmezett tulajdonság) nyugodtan használhatsz magasabb értéket; a kódoló csökkenti a B-kockák használatát azokban a részekben, ahol amiatt sérülne a tömörítés. A kódoló ritkán választ 3 vagy 4 B-kockánál többet; ezen opció magasabb értékre állítása nagyon kicsi különbséget eredményez. b_adapt: Megjegyzés: Ez alapértelmezetten be van kapcsolva. Ezzel az opcióval a kódoló egy eléggé gyors döntési eljárást fog használni a B-kockák számának csökkentésére az olyan jelenetekben, amelyek nem profitálnak belőlük. Használhatod a b_bias-t a kódoló B-kocka-használatának nyomonkövetésére. Az adaptív B-kockák sebességbeli hátránya jelenleg elég szerény, de ilyen a potenciális minőségbeli javulás is. De általában nem árt. Jegyezd meg, hogy ez csak az első lépésben érinti a sebességet és a képkocka típus döntéseket. A b_adapt-nak és a b_bias-nak nincs hatása a következő lépésekre. b_pyramid: Jó ha engedélyezed ezt az opciót, ha >=2 B-kockát használsz; ahogy a man oldal is írja, egy kicsi minőségi javulást kapsz sebességcsökkenés nélkül. Jegyezd meg, hogy ezen videók nem olvashatóak a 2005. március 5-nél korábbi libavcodec-alapú dekódolókkal. weight_b: Általános esetekben ez az opció nem hoz sokat a konyhára. Bár az át- és az elsötétülő jeleneteknél, a súlyozott jóslás jelentős bitráta spórolást hoz. Az MPEG-4 ASP-ben az elsötétülés általában drága I-kockák sorozatával kerül legjobban elkódolásra; a B-kockákban használt súlyozott jóslással lehetséges ezek legalább részben a sokkal kisebb B-kockákkal történő lecserélése. A kódolási időben jelentkező plusz ráfordítás minimális, mivel nem kell külön döntéseket hozni. Ellentétben azzal, amire pár ember gondol, a dekódoló CPU igényét nem érinti jelentősen a súlyozott jóslás. Sajnos a jelenlegi adaptív B-kocka döntési algoritmusnak van egy olayn érdekes tulajdonsága, hogy kerüli a B-kockákat az elsötétedéseknél. Amíg ez nem változik meg, jó ötlet lehet a nob_adapt opció hozzáadása az x264encopts-hoz, ha arra számítasz, hogy sötétedések jelentősen befolyásolják a videódat. threads: Ez az opció szálak segítségével párhuzamos kódolást tesz lehetővé több CPU-n. A létrejövő szálak száma kézzel is beállítható, de jobb a threads=auto és rábízni az x264-re a használható CPU-k felderítését és a szálak optimális számának megállapítását. Ha több processzoros géped van, nem árt fontolóra venni ennek a használatát, mivel a CPU magokkal arányosan megnövelheti a kódolási sebességet (kb. 94% CPU magonként), nagyon kicsi minőségromlással (kb. 0.005dB dual processzornál, 0.01dB quad processzoros gépnél). Két lépéses kódolás: Fentebb azt javasoltuk, hogy mindig használj két lépéses kódolást, azonban vannak indokok az elkerülése mellett is. Például ha élő TV adást mentesz és kódolsz valós időben, kénytelen vagy egy lépést használni. Az egy lépés nyilvánvalóan gyorsabb, mint a két lépéses; ha teljesen ugyan azokkal az opciókat használod mind a két lépésben, a két lépéses kódolás majdnem kétszer olyan lassú. Mégis van pár nagyon jó indok a két lépéses kódolás használatára. Az egyik, hogy az egy lépés rátakontollja nem pszichikai, így gyakran ésszerűtlen döntéseket hoz, mert nem látja a nagy képet. Például tegyük fel, hogy van egy két perces videód, mely két eltérő félből áll. Az első fele nagyon gyors mozgású, 60 másodperces jelenet, ami magában kb. 2500kbps-t igényel, hogy megfelelően nézzen ki. Majd rögtön ez után egy sokkal kisebb igényű 60 másodperces jelenet jön, ami 300 kbps-sel is jól néz ki. Tegyük fel, hogy 1400kbps-t kérsz, ami elméletileg elég mind a két jelenethez. Az egy lépéses rátakontroll rengeteg "hibát" ejt egy ilyen esetben. Mindenek előtt az 1400kbps-t célozza meg mind a két szegmensben. Az első rész erőteljesen túl lesz kvantálva, emiatt elfogadhatatlan és túlzottan blokkos képet kapsz. A második szegmens pedig erőteljesen alul lesz kvantálva; tökéletesen néz ki, de az ezzel járó bitráta többlet teljesen ésszerűtlen. Amit még nehezebb elkerülni, az a két jelenet közötti átmenet problémája. A lassú mozgású rész első pár másodperce túlságosan túl lesz kvantálva, mert a rátakontroll még a videó első feléből származó bitráta igényre számít. Ez a túlkvantálási "hiba periódus" a kevés mozgást tartalmazó részt szörnyen rosszá teszi, tulajdonképpen kevesebb, mint 300kbps-t fog használni, ami a megfelelő kinézethez kellene. Több lehetőség is van az egy lépéses kódolás buktatóiból származó hibák csökkentésére, de összességében mégis növelik a bitráta félrebecslésének esélyét. A többlépéses rátakontrollnak több előnye is van az egylépésessel szemben. Az első lépésből nyert statisztikai adatokból a kódoló egész jó pontossággal meg tudja jósolni egy bármilyen adott kocka bármilyen adott kvantálás melletti kódolásának "költségét" (bitekben). Ez a bitek sokkal ésszerűbb, jobban megtervezett elosztását eredményezi a drága (sok mozgású) és az olcsó (kevés mozgású) jelenetek között. Lásd a qcomp opciót lejjebb néhány ötletért, hogy hogyan tudod ezt a felosztást kedvedre változtatni. Továbbá a két lépés nem tart kétszer annyi ideig, mint az egy. Az első lépés opcióit rá lehet hangolni a nagyobb sebességre és a gyengébb minőségre. Ha jól választod meg az opciókat, egy nagyon gyors első lépésed lehet. Az eredmény minősége a második lépésben kicsit alacsonyabb lesz mert a méret becslés kevésbé pontos, de a minőségi különbség normális esetben túl kicsi ahhoz, hogy észrevedd. Például próbáld meg a subq=1:frameref=1 opció hozzáadását a x264encopts első lépéséhez. Majd, a második lépésben használj lassabb, jobb minőséget biztosító opciókat: subq=6:frameref=15:partitions=all:me=umh Három lépéses kódolás? Az x264 lehetőséget nyújt tetszőleges számú egymás utáni lépések elvégzésére. Ha megadod a pass=1 opciót az első lépésben, majd pass=3-at használsz az egyik következő lépésben, a következő lépés beolvassa az előző statisztikáját és megírja a sajátját. Egy ezt követő lépésnek már nagyon jó alapjai lesznek, nagyon pontos döntéseket tud hozni a képkocka méretre vonatkozóan a választott kvantálás mellett. A gyakorlatban az össz minőségi nyereség ebből közel van a nullához és lehetséges, hogy egy harmadik lépés kissé még rontja is a globális PSNR-t az előző lépéshez képest. Az átlagos felhasználásban a három lépés akkor segít, ha két lépéssel rossz bitráta jóslást kaptál vagy ronda átmeneteket a jelenetek között. Ilyen dolog csak a nagyon rövid klippeknél fordulhat elő. Van még pár speciális eset is, amikor a három (vagy több) lépés jól jöhet a haladó felhasználóknak, de a rövidítés végett ezeket az eseteket nem tárgyaljuk ebben a leírásban. qcomp: A qcomp a "drága", sok mozgást és az "olcsó", kevés mozgást tartalmazó jelenetekhez használt bitek arányát szabályozza. Extrém esetben a qcomp=0 az igazi konstans bitrátát célozza meg. Ezzel a sok mozgású részek borzasztóan fognak kinézni, míg a kevés mozgást tartalmazó részek valószínűleg tökéletesen fognak kinézni, de a hasonló kinézethez szükséges bitráta többszörösét fogják felhasználni. A másik extrém véglet a qcomp=1 majdnem konstans kvantálási paramétert ér el (QP). A konstans QP nem néz ki rosszul, de a legtöbb ember úgy gondolja, hogy ésszerűbb egy kis bitrátát feláldozni a roppant drága jeleneteknél (ahol a minőségromlás nem olyan észrevehető) és felhasználni őket a kitűnő minőségben is könnyebben kódolható jeleneteknél. A qcomp alapértelmezett értéke 0.6, ami eléggé alacsony sok ember ízléséhez képest (0.7-0.8 a leggyakrabban használt). keyint: A keyint kizárólag a a fájlon belüli keresést rontja a kódolási hatékonyság javára. Alapértelmezésként a keyint 250-re van állítva. Egy 25fps-es anyagnál ez garantálja a 10 másodpercen belüli pontossággal történő ugrást. Ha úgy gondolod, hogy fontos és hasznos lenne az 5 másodperces pontosság, állítsd be a keyint=125 értéket; ez egy kissé rontja a minőséget/bitrátát. Ha csak a minőség érdekel és a kereshetőség nem, beállíthatod magasabb értékre (észben tartva azt, hogy egyre csökkenő hasznot hoz, mely végül szinte észrevehetetlenül kicsi vagy akár nulla lesz). A videó folyam még így is fog tartalmazni kereshető pontokat, amíg van benne jelenet váltás. deblock: Ez a rész egy kicsit vitatható lesz. A H.264 egy egyszerű deblocking eljárást definiál az I-blokkokra, ami előre beállított erősséget és áteresztést használ a szóbanforgó blokk QP-je alapján. Alapértelmezettként a nagy QP blokkok erős szűrön mennek át, az alacsony QP blokkok nem kerülnek deblock-olásra semennyire sem. Az alapértelmezett értékek szerint előre beállított erősség jól megválasztott és jó eséllyel PSNR-optimális bármilyen videóhoz, amit csak próbálsz elkódolni. A deblock paraméterrel megadhatod az előre beállított deblocking áteresztés eltolását. Sokan úgy gondolják, hogy jó ötlet nagy mértékben csökkenteni a deblocking szűrő erősségét (mondjuk -3-ra). Ez valójában szinte soha sem jó ötlet és a legtöbb esetben azok az emberek, akik ezt csinálják, nem is értik igazán, hogy hogyan működik a deblocking alapból. Az első és legfontosabb dolog azt tudni a beépített deblocking szűrőről, hogy az alapértelmezett áteresztés majdnem mindig PSNR-optimális. Ritkább esetben nem optimális, az ideális eltolás plusz vagy mínusz 1. A deblocking paramétereinek nagy mértékben történő megváltoztatása majdnem garantáltan rontja a PSNR-t. A szűrő erősítése elmaszatol néhány részletet; a szűrő gyengítése a kockásodás láthatóságát növeli. Tipikusan rossz ötlet a deblocking áteresztés csökkentése, ha a forrásod térbeli komplexitása alacsony (pl. nem túl részletes vagy zajos). A beépített szűrő remek munkát végez a felbukkanó mellékhatások elrejtése érdekében. Ha a forrásban térbeli komplexitása nagy, a mellékhatások még kevésbé láthatóak. Ez azért van, mert a gyűrűs haladás részletnek vagy zajnak látszik. Az emberi szem könnyen meglátja, ha egy részlet elmozdul, de nem olyan könnyű észrevenni, ha a zaj rosszul van reprezentálva. Ha szubjektív minőséghez ér, a zaj és a részletesség valamennyire felcserélhető. A deblocking szűrő erősségének csökkentésével a legvalószínűbb, hogy növeled a hibákat a gyűrűs mellékhatások hozzáadásával, de a szem nem veszi észre, mert összekeveri a mellékhatásokat és a részleteket. Ez még nem igazolja a deblocking szűrő erősségének csökkentését. Általában jobb zajminőséget érhetsz el az utófeldolgozással. Ha a H.264 kódolásod túl foltos vagy maszatos, próbáld meg lejátszani a -vf noise kapcsolóval. A -vf noise=8a:4a-nak a gyenge mellékhatásokat el kell tüntetnie. Majdnem biztos, hogy jobb eredményt kapsz, mint a deblocking szűrővel való pepecseléssel. A következő beállítások példák a különböző kódolási opciók kombinációjára, amik érintik a sebességet vagy a minőséget ugyan annál a cél bitrátánál. Az összes kódolási beállítást egy 720x448 @30000/1001 fps-es minta videón teszteltük, a cél bitráta 900kbps volt, a gép pedig egy AMD-64 3400+ 2400 MHz-en, 64 bit-es módban. Mindegyik kódolási beállítás tartalmazza a kódolási sebességet (képkocka per másodpercben) és a PSNR veszteséget (dB-ben) a "nagyon jó minőséghez" viszonyítva. Kérlek vedd figyelembe, hogy a forrásanyagodtól, a géped típusától és a fejlesztésektől függően különböző eredményeket kaphatsz. Leírás Kódolási opciók sebesség (fps-ben) relatív PSNR veszteség (dB-ben) Nagyon jó minőség subq=6:partitions=all:8x8dct:me=umh:frameref=5:bframes=3:b_pyramid:weight_b 6fps 0dB Jó minőség subq=5:partitions=all:8x8dct:frameref=2:bframes=3:b_pyramid:weight_b 13fps -0.89dB Gyors subq=4:bframes=2:b_pyramid:weight_b 17fps -1.48dB A Video for Windows egyszerű kódolást biztosít bináris videó codec-ekkel. A következő codec-ekkel kódolhatsz (ha több is van, kérjük áruld el!) Tartsd észben, hogy ez nagyon kísérleti támogatás és néhány codec hibásan működhet. Néhány codec csak bizonyos színterekben működik jól, próbáld ki a -vf format=bgr24 és -vf format=yuy2 opciókat, ha a codec hibázik vagy rossz kimenetet ad. Videó codec fájl név Leírás md5sum Megjegyzés aslcodec_vfw.dll Alparysoft veszteségmentes codec vfw (ASLC) 608af234a6ea4d90cdc7246af5f3f29a avimszh.dll AVImszh (MSZH) 253118fe1eedea04a95ed6e5f4c28878 -vf format kell hozzá avizlib.dll AVIzlib (ZLIB) 2f1cc76bbcf6d77d40d0e23392fa8eda divx.dll DivX4Windows-VFW acf35b2fc004a89c829531555d73f1e6 huffyuv.dll HuffYUV (veszteségmentes) (HFYU) b74695b50230be4a6ef2c4293a58ac3b iccvid.dll Cinepak Video (cvid) cb3b7ee47ba7dbb3d23d34e274895133 icmw_32.dll Motion Wavelets (MWV1) c9618a8fc73ce219ba918e3e09e227f2 jp2avi.dll ImagePower MJPEG2000 (IPJ2) d860a11766da0d0ea064672c6833768b -vf flip m3jp2k32.dll Morgan MJPEG2000 (MJ2C) f3c174edcbaef7cb947d6357cdfde7ff m3jpeg32.dll Morgan Motion JPEG Codec (MJPEG) 1cd13fff5960aa2aae43790242c323b1 mpg4c32.dll Microsoft MPEG-4 v1/v2 b5791ea23f33010d37ab8314681f1256 tsccvid.dll TechSmith Camtasia Screen Codec (TSCC) 8230d8560c41d444f249802a2700d1d5 shareware hiba windows-on vp31vfw.dll On2 Open Source VP3 Codec (VP31) 845f3590ea489e2e45e876ab107ee7d2 vp4vfw.dll On2 VP4 Personal Codec (VP40) fc5480a482ccc594c2898dcc4188b58f vp6vfw.dll On2 VP6 Personal Codec (VP60) 04d635a364243013898fd09484f913fb vp7vfw.dll On2 VP7 Personal Codec (VP70) cb4cc3d4ea7c94a35f1d81c3d750bc8d -ffourcc VP70 ViVD2.dll SoftMedia ViVD V2 codec VfW (GXVE) a7b4bf5cac630bb9262c3f80d8a773a1 msulvc06.DLL MSU Lossless codec (MSUD) 294bf9288f2f127bb86f00bfcc9ccdda Dekódolható a Window Media Playerrel, de az MPlayerrel nem (még). camcodec.dll CamStudio veszteségmentes videó codec (CSCD) 0efe97ce08bb0e40162ab15ef3b45615 sf.net/projects/camstudio Az első oszlop a codec nevét tartalmazza, amit a codec paraméter után kell megadni, így: -xvfcopts codec=divx.dll Az egyes codec-ek által használt FourCC kód zárójelben látható. Egy példa egy ISO DVD ajánló VP6 flash videó fájlba történő átalakítására a compdata bitráta beállításaival: mencoder -dvd-device zeiram.iso dvd://7 -o trailer.flv \ -ovc vfw -xvfwopts codec=vp6vfw.dll:compdata=onepass.mcf -oac mp3lame \ -lameopts cbr:br=64 -af lavcresample=22050 -vf yadif,scale=320:240,flip \ -of lavf A Video for Windows codec-ekkel történő kódoláshoz be kell állítanod a bitrátát és egyéb opciókat. x86-on ez működik mind *NIX, mind Windows alatt. Először is le kell fordítanod a vfw2menc programot. A TOOLS alkönyvtárban található az MPlayer forrásában. A Linux alatti elkészítéséhez a Wine-t kell használni: winegcc vfw2menc.c -o vfw2menc -lwinmm -lole32 Windows alatt MinGW vagy Cygwin használatával: gcc vfw2menc.c -o vfw2menc.exe -lwinmm -lole32 Az MSVC-vel történő fordításhoz szükséges a getopt. A getopt megtalálható az eredeti vfw2menc archivban itt: The MPlayer win32 alatt projekt. Az alábbi példa VP6 codec-kel működik. vfw2menc -f VP62 -d vp6vfw.dll -s firstpass.mcf Ez megnyitja a VP6 codec dialógus ablakot. Ismételd meg ezt a második lépéshez is és használd a -s secondpass.mcf kapcsolót. A Windows használók a -xvfwopts codec=vp6vfw.dll:compdata=dialog kapcsolóval a kódolás megkezdése előtt jeleníthetik meg a codec dialógust. Több oka is van annak, hogy kívánatos lehet QuickTime-kompatibilis fájlok készítése. Azt szertnéd, hogy minden gép le tudja játszani a kódolásod bármelyik fő platformon (Windows, Mac OS X, Unices …). A QuickTime több hardveres és szoftveres gyorsítást ki tud használni Mac OS X-en, mint a platform-független lejátszók, mint például az MPlayer vagy a VLC. Ez azt jelenti, hogy a kódolásaid jó eséllyel szebben mennek majd egy régi G4-alapú gépen. A QuickTime 7 támogatja a következő generációs H.264 codec-et, ami sokkal jobb képminőséget biztosít, mint az előző codec generációk (MPEG-2, MPEG-4 …). A QuickTime 7 támogatja a H.264 videót és az AAC audiót, de nem támogatja ezek AVI konténer formátumba történő keverését. Mindamellett használhatod a MEncodert a videó és az audió kódolásához, és utána egy külső programmal, mint pl. az mp4creator (az MPEG4IP suite része) újrakevered a videó és audió sávokat egy MP4 konténerbe. A QuickTime H.264 támogatása korlátolt, így néhány fejlett funkció nem lesz elérhető. Ha olyan funkciókkal kódolod el a videódat, amiket a QuickTime 7 nem támogat, a QuickTime-alapú lejátszók egy csodás fehér képet fognak mutatni neked a várt videó helyett. B-frame-k: A QuickTime 7 maximum 1 B-frame-t támogat, pl. -x264encopts bframes=1. Ez azt jelenti, hogy a b_pyramid-nek és a weight_b-nek nem lesz hatása, mivel 1-nél több bframe kell nekik. Makroblokkok: A QuickTime 7 nem támogatja a 8x8 DCT makroblokkokat. Ez az opció (8x8dct) ki van kapcsolva alapértelmezésben, ezért győződj meg, hogy még véletlenül sem engedélyezed. Ez azt is jelenti, hogy a i8x8-nak nem lesz hatása, mivel ahhoz a 8x8dct szükséges. Méret arány: A QuickTime 7 nem támogatja a SAR (sample aspect ratio) információkat az MPEG-4 fájlokban; feltételezi, hogy a SAR=1. Olvasd el a méretezés részt a tüneti kezeléshez. Tegyük fel, hogy rip-pelni szeretnéd a "Narnia krónikái" frissen vásárolt másolatát. A DVD-d régió 1-es, ami azt jelenti, hogy NTSC. Az alábbi példa működik PAL-ra is, feltéve, hogy elhagyod a -ofps 24000/1001-et és kicsit más crop és scale méreteket adsz meg. Miután lefuttattad az mplayer dvd://1-et, kövesd a Mit kezdjünk a telecine-nel és az átlapolással NTSC DVD-ken részben leírtakat, és rájössz, hogy ez egy 24000/1001 fps-es progresszív videó. Ez kicsit leegyszerűsíti a folyamatot, mivel nem kell inverz telecine szűrőt használnod, mint a pullup vagy deinterlacing szűrőt, mint a yadif. Ezután le kell vágnod a fekete sávokat a videó tetején és alján, ahogy az ebben az előző részben le van írva. A következő lépés szívszaggató. A QuickTime 7 nem támogatja azon MPEG-4 videókat, melyekben a sample aspect ratio 1-től különböző, így vagy fel kell méretezned (ami rengeteg lemezterületet elvisz) vagy le kell méretezned (ami miatt elveszik a forrás pár részlete) a videót négyzetes pixelekre. Bárhogy is csinálod, ez nagyon nem jó, de nem kerülheted ki, ha QuickTime 7 által lejátszható videót akarsz. A MEncoder végre tudja hajtani a megfelelő fel- illetve leméretezést megfelelően a -vf scale=-10:-1 vagy a -vf scale=-1:-10 megadásával. Ez a videódat a vágott magasságnak megfelelő szélességűre méretezi, 16 legközelebbi többszörösére kerekítve az optimális tömörítéshez. Emlékezz rá, hogy ha vágsz, először vágnod kell, utána méretezni: -vf crop=720:352:0:62,scale=-10:-1 Mivel egy másik konténerbe keversz, mindig ajánlott a harddup opció használata annak biztosítására, hogy a duplikált kockák a kimeneti videóban is duplikálva lesznek. Ezen opció nélkül a MEncoder egyszerűen csak egy jelet tesz a videó folyamba a képkocka duplikálásának helyére és innentől a kliens szoftveren műlik, hogy kétszer mutatja-e az adott kockát. Sajnos ez a "szoft duplikálás" nem éli túl az újrakeverést, így az audió lassan elveszíti a szinkront a videóval. A végleges szűrőlánc így néz ki: -vf crop=720:352:0:62,scale=-10:-1,harddup Mint mindig, a bitráta megválasztása a forrás technikai tulajdonságaitól függ, ahogy az itt le van írva, valamint az egyéni ízlésedttől is. Ebben a filmben sok akció van nagy részletességgel, de a H.264 videó sokkal kisebb bitrátán is jobban néz ki, mint az XviD vagy más MPEG-4 codec-ek. Hosszas kísérletezés után ezen leírás szerzője úgy döntött, hogy 900kbps-en kódolja el ezt a filmet és úgy hiszi, hogy nagyon jól néz ki. Csökkentheted a bitrátát, ha több helyet kell megspórolnod vagy növelheted, ha javítanod kell a minőséget. Készen állsz a videó elkódolására. Mivel érdekel a minőség, természetesen két-lépéses kódolást futtatsz le. Hogy megspóroljunk némi kódolási időt, megadhatod a turbo opciót az első lépésben; ez lecsökkenti a subq-t és a frameref-et 1-re. Némi lemezterület megspórolása érdekében használhatod az ss opciót a videó első pár másodpercének levágásához. (Úgy tűnik, hogy a konkrét film 32 másodpercnyi stáblistát és logót tartalmaz.) A bframes lehet 0 vagy 1. A többi opció a Kódolás az x264 codec-kel részben és a man oldalon van leírva. mencoder dvd://1 -o /dev/null -ss 32 -ovc x264 \ -x264encopts pass=1:turbo:bitrate=900:bframes=1:\ me=umh:partitions=all:trellis=1:qp_step=4:qcomp=0.7:direct_pred=auto:keyint=300 \ -vf crop=720:352:0:62,scale=-10:-1,harddup \ -oac faac -faacopts br=192:mpeg=4:object=2 -channels 2 -srate 48000 \ -ofps 24000/1001 Ha több processzoros géped van, ne hagy ki a kódolás drasztikus módon történő gyorsításának a lehetőségét, melyet az x264 több-processzoros módja nyújt a threads=auto x264encopts-ban történő megadásával a parancssorban. A második lépés ugyan ez, kivéve, hogy meg kell adni a kimeneti fájlt és a pass=2-őt. mencoder dvd://1 -o narnia.avi -ss 32 -ovc x264 \ -x264encopts pass=2:turbo:bitrate=900:frameref=5:bframes=1:\ me=umh:partitions=all:trellis=1:qp_step=4:qcomp=0.7:direct_pred=auto:keyint=300 \ -vf crop=720:352:0:62,scale=-10:-1,harddup \ -oac faac -faacopts br=192:mpeg=4:object=2 -channels 2 -srate 48000 \ -ofps 24000/1001 Az eredmény AVI tökéletesen lejátszható az MPlayer-rel, de természetesen a QuickTime nem játsza le, mivel nem támogatja az AVI-ba kevert H.264-et. Ezért a következő lépés a videó MP4 konténerbe történő keverése. Több mód is van az AVI MP4-be történő újrakeverésére. Használhatod az mp4creator-t, ami az MPEG4IP suite része. Először az AVI-ból különálló audió és videó folyamokat kell készíteni az MPlayerrel. mplayer narnia.avi -dumpaudio -dumpfile narnia.aac mplayer narnia.avi -dumpvideo -dumpfile narnia.h264 A fájl nevek fontosak; az mp4creator .aac kiterjesztésű AAC audió folyamot és .h264 kiterjesztésű H.264 videó folyamot vár. Ezután használd az mp4creator-t egy új MP4 fájl létrehozásához az audió és videó folyamból. mp4creator -create=narnia.aac narnia.mp4 mp4creator -create=narnia.h264 -rate=23.976 narnia.mp4 A kódolási lépéstől eltérően itt a framerátát decimálisként (23.976) kell megadni, nem törtként (24000/1001). Ennek a narnia.mp4 fájlnak már bármilyen QuickTime 7 alkalmazással lejátszhatónak kell lennie, mint például a QuickTime Player vagy az iTunes. Ha a videót böngészőben szeretnéd megnézni a QuickTime plugin-nel, utasítanod kell a QuickTime plugin-t, hogy kezdje meg a lejátszást, miközben még tart a letöltés. Az mp4creator bele tudja tenni a videóba az ehhez szükséges utasító sávokat: mp4creator -hint=1 narnia.mp4 mp4creator -hint=2 narnia.mp4 mp4creator -optimize narnia.mp4 Ellenőrizheted a végső eredményt, hogy meggyőződj róla, hogy az utasító sávok rendben elkészültek: mp4creator -list narnia.mp4 Látnod kell a sávok listáját: 1 audió, 1 videó és 2 hint sáv. Track Type Info 1 audio MPEG-4 AAC LC, 8548.714 secs, 190 kbps, 48000 Hz 2 video H264 Main@5.1, 8549.132 secs, 899 kbps, 848x352 @ 23.976001 fps 3 hint Payload mpeg4-generic for track 1 4 hint Payload H264 for track 2 Ha tag-eket akarsz hozzáfűzni a videódhoz, amiket az iTunes megjelnít, használhatod az AtomicParsley-t. AtomicParsley narnia.mp4 --metaEnema --title "The Chronicles of Narnia" --year 2005 --stik Movie --freefree --overWrite A --metaEnema opció eltávolít minden meglévő metadata-t (mp4creator beszúrja a saját nevét az "encoding tool" tag-be), a --freefree pedig visszaszerzi a törölt metadata által elfoglalt helyet. A --stik opció beállítja a videó típusát (mint pl. Movie vagy TV Show), aminek a segítségével az iTunes csoportosítani tudja a fájlokat. A --overWrite opció felülírja az eredeti fájlt; ennélkül az AtomicParsley egy új, automatikusan elnevezett fájlt hoz létre ugyan abban a könyvtárban és érintetlenül hagyja az eredeti fájlt. A MEncoder képes VCD, SCVD és DVD formátumú MPEG fájlok létrehozására a libavcodec könyvtár segítségével. Ezek a fájlok a vcdimager-rel vagy a dvdauthor-ral együttműködve felhasználhatók szabványos lejátszókban lejátszható lemezek készítéséhez. A DVD, SVCD és VCD formátumok súlyos korlátokkal rendelkeznek. A kódolt képméretekből és a képarányokból csak nagyon kevés áll rendelkezésre. Ha a filmed nem felel meg ezeknek a követelményeknek, méretezned, vágnod vagy fekete keretet kell hozzáadnod a képhez, hogy kompatibilis legyen. Formátum Felbontás V. Codec V. Bitráta Mintavételi ráta A. Codec A. Bitráta FPS Arány NTSC DVD 720x480, 704x480, 352x480, 352x240 MPEG-2 9800 kbps 48000 Hz AC-3,PCM 1536 kbps (max) 30000/1001, 24000/1001 4:3, 16:9 (csak 720x480-nál) NTSC DVD 352x240 Ezek a felbontások ritkán használatosak a DVD-ken, mert elég alacsony minőségűek. MPEG-1 1856 kbps 48000 Hz AC-3,PCM 1536 kbps (max) 30000/1001, 24000/1001 4:3, 16:9 NTSC SVCD 480x480 MPEG-2 2600 kbps 44100 Hz MP2 384 kbps (max) 30000/1001 4:3 NTSC VCD 352x240 MPEG-1 1150 kbps 44100 Hz MP2 224 kbps 24000/1001, 30000/1001 4:3 PAL DVD 720x576, 704x576, 352x576, 352x288 MPEG-2 9800 kbps 48000 Hz MP2,AC-3,PCM 1536 kbps (max) 25 4:3, 16:9 (csak 720x576-nál) PAL DVD 352x288 MPEG-1 1856 kbps 48000 Hz MP2,AC-3,PCM 1536 kbps (max) 25 4:3, 16:9 PAL SVCD 480x576 MPEG-2 2600 kbps 44100 Hz MP2 384 kbps (max) 25 4:3 PAL VCD 352x288 MPEG-1 1152 kbps 44100 Hz MP2 224 kbps 25 4:3 Ha a filmednek 2.35:1 méretaránya van (a legtöbb akció film), fekete keretet kell hozzáadnod vagy le kell vágnod a filmet 16:9-es méretarányra DVD vagy VCD készítéshez. Ha fekete keretet adsz hozzá, próbáld meg 16 pixel-es határra igazítani őket a kódolási teljesítményre való hatásuk minimalizálásához. Szerencsére a DVD-nek eléggé magas a bitrátája, nem kell aggódnod túlságosan a kódolás hatékonysága miatt, de az SVCD és a VCD bitráta-szegény, ezért erőfeszítéseket kell tenni az elfogadható minőségért is. A DVD, VCD és SVCD eléggé alacsony GOP (Group of Pictures) méret értékekre korlátoz le. Egy 30 fps-es anyagnál a legnagyobb megengedett GOP méret 18. 25 vagy 24 fps-nél a maximum 15. A GOP méretét a keyint opcióval lehet beállítani. A VCD videónak CBR-esnek kell lennie 1152 kbps-en. Ehhez a nagyon erős megkötéshez egy extrém alacsony, 327 kilobit-es vbv buffer méret társul. Az SVCD megengedi a bitráta változtatását 2500 kbps-ig és kicsit kevésbé korlátozó, 917 kilobit-es vbv buffer méretet engedélyez. A DVD videó bitrátája bárhol lehet 9800 kbps-ig (bár az általános bitráták ennek felénél vannak) és a vbv buffer méret is 1835 kilobit. A MEncoder rendelkezik a kimeneti formátumot beállító kapcsolókkal. Ezen opciók használatával utasíthatod, hogy helyes típusú fájlt készítsen. A VCD és SVCD opciókat xvcd-nek és xsvcd-nek hívják, mert kiterjesztett formátumúak. Nem teljesen kompatibilisek, főként mivel a kimenet nem tartalmaz scan offszet-eket. Ha SVCD CD képet kell készítened, add át a kimeneti fájlt a vcdimager-nek. VCD: -of mpeg -mpegopts format=xvcd SVCD: -of mpeg -mpegopts format=xsvcd DVD (minden kockánál időbélyeggel, ha lehetséges): -of mpeg -mpegopts format=dvd:tsaf DVD NTSC Pullup-pal: -of mpeg -mpegopts format=dvd:tsaf:telecine -ofps 24000/1001 Ez engedélyezi a 24000/1001 fps-es progresszív tartalom 30000/1001 fps-sel történő kódolását a DVD-előírások betartásával. A -lavcopts aspect argumentuma használható a fájl képarányának elkódolásához. Lejátszás közben a képarányt a videó megfelelő méretűre állításához használják. 16:9 vagy "Widescreen" -lavcopts aspect=16/9 4:3 vagy "Fullscreen" -lavcopts aspect=4/3 2.35:1 vagy "Cinemascope" NTSC -vf scale=720:368,expand=720:480 -lavcopts aspect=16/9 A helyes méretarány kiszámításához használd a 854/2.35 = 368-as kibővített NTSC szélességet. 2.35:1 vagy "Cinemascope" PAL -vf scale=720:432,expand=720:576 -lavcopts aspect=16/9 A helyes méretarány kiszámításához használd a 1024/2.35 = 432-es kibővített PAL szélességet. Az audió/videó szinkronizáció kódolás közbeni megtartásához a MEncodernek el kell dobni vagy meg kell duplázni képkockákat. Ez jobban működik ha AVI fájlba keversz, de majdnem biztosan sikertelen az A/V szinkron megtartása más muxer-ekkel, mint pl. az MPEG. Ezért van, hogy a harddup videó szűrőt hozzá kell csatolni a szűrőlánc végéhez ezen problémák elkerüléséhez. A harddup-ról további információkat a muxálás és az A/V szinkron megbízhatósága című fejezetben találsz vagy a man oldalon. Ha az eredeti fájl audió mintavételi rátája nem ugyan olyan, mint ami a cél formátumban szükséges, mintavételi ráta konvertálást kell végrehajtani. Ez a -srate és -af lavcresample kapcsolók együttes használatával érhető el. DVD: -srate 48000 -af lavcresample=48000 VCD és SVCD: -srate 44100 -af lavcresample=44100 A libavcodec használható VCD/SVCD/DVD kompatibilis videó készítéséhez a megfelelő opciókkal. Következzék egy lista a -lavcopts-ban használható mezőkről, amiknek a megváltoztatására szükséged lehet a VCD, SVCD, vagy DVD kompatibilis film készítésekor: acodec: mp2 a VCD-hez, SVCD-hez vagy PAL DVD-hez; ac3 a leggyakoribb DVD-hez. PCM audió is használható DVD-hez, de legtöbbször csak helypazarlás. Figyelj rá, hogy az MP3 audió ezen formátumok egyikével sem kompatibilis, de a lejátszóknak gyakran semmi gondot nem okoz a lejátszása. abitrate: 224 VCD-nél; 384-ig SVCD-nél; 1536-ig DVD-nél, de általában a használt értékek a sztereónál 192 kbps-étől az 5.1 csatornás hang 384 kbps-éig változnak. vcodec: mpeg1video VCD-hez; mpeg2video SVCD-hez; mpeg2video használatos általában a DVD-hez, de lehet mpeg1video is a CIF felbontásokhoz. keyint: A GOP méret beállításához használható. 18 a 30fps-es anyagé vagy 15 a 25/24 fps-esé. A kereskedelmi előállítók a 12-es kulcskocka intervallumot preferálják. Lehetséges ezen érték nagyobbra állítása is a legtöbb lejátszóval való kompatibiliítás megtartása mellett. A 25-ös keyint soha nem okoz problémát. vrc_buf_size: 327 VCD-nél, 917 SVCD-nél és 1835 DVD-nél. vrc_minrate: 1152 VCD-nél. Elhagyható SVCD és DVD esetében. vrc_maxrate: 1152 VCD-nél; 2500 SVCD-nél; 9800 DVD-nél. SVCD-hez és DVD-hez az egyéni kívánalmaidnak és igényeidnek megfelelően használhatsz magasabb értékeket is. vbitrate: 1152 VCD-nél; legfeljebb 2500 SVCD-nél; legfeljebb 9800 DVD-nél. Az utóbbi két formátumnál a vbitrate egyéni igények szerint állítható be. Például szeretnéd, hogy 20 óra vagy akörüli anyag felférjen egy DVD-re, használhatod a vbitrate=400-at. Az eredmény videó minősége valószínűleg elég rossz lesz. Ha megpróbálod kisakkozni a lehető legjobb minőséget a DVD-n, használd a vbitrate=9800-at, de emlékezz rá, hogy emiatt kevesebb, mint egy órányi videód lehet egy egyrétegű DVD-n. vstrict: vstrict=0 ajánlott DVD-k készítéséhez. Ezen opció nélkül a MEncoder egy olyan folyamot készít, amit néhány asztali lejátszó nem tud helyesen dekódolni. Általában ez a minimum -lavcopts egy videó elkódolásához: VCD: -lavcopts vcodec=mpeg1video:vrc_buf_size=327:vrc_minrate=1152:\ vrc_maxrate=1152:vbitrate=1152:keyint=15:acodec=mp2 SVCD: -lavcopts vcodec=mpeg2video:vrc_buf_size=917:vrc_maxrate=2500:vbitrate=1800:\ keyint=15:acodec=mp2 DVD: -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\ keyint=15:vstrict=0:acodec=ac3 Jobb minőségű kódoláshoz valószínűleg használni szeretnéd a lavcopts minőség-javító opcióit is, mint például a trell, mbd=2, vagy mások. Figyelj rá, hogy a qpel és a v4mv bár gyakran hasznosak MPEG-4 esetén, nem használhatóak MPEG-1 vagy MPEG-2-vel. Ha nagyon jó minőségű DVD kódolást akarsz készíteni, hasznos lehet a dc=10 opció hozzáadása a lavcopts-hoz. Ez segíti csökkenteni a blokkosodást a színtelen részeknél. Mindezt összerakva, itt egy példa jó minőségű DVD készítéséhez szükséges lavcopts-ra: -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=8000:\ keyint=15:trell:mbd=2:precmp=2:subcmp=2:cmp=2:dia=-10:predia=-10:cbp:mv0:\ vqmin=1:lmin=1:dc=10:vstrict=0 A VCD és az SVCD támogatja az MPEG-1 layer II audiót, a toolame, twolame, vagy a libavcodec MP2 kódolójának felhasználásával. A libavcodec MP2 messze nincs olyan jó, mint a másik két könyvtár, azonban az mindig elérhető és használható. A VCD csak konstans bitrátájú audiót (CBR) támogat, míg az SVCD tudja a változó bitrátát (VBR) is. De vigyázz a VBR-rel, mert néhány hibás asztali lejátszó sem támogatja. A DVD audióhoz a libavcodec AC-3 codec-je használható. VCD-hez és SVCD-hez: -oac toolame -toolameopts br=224 VCD-hez és SVCD-hez: -oac twolame -twolameopts br=224 DVD-hez két csatornás hanggal: -oac lavc -lavcopts acodec=ac3:abitrate=192 DVD-hez 5.1 csatornás hanggal: -channels 6 -oac lavc -lavcopts acodec=ac3:abitrate=384 VCD-hez és SVCD-hez: -oac lavc -lavcopts acodec=mp2:abitrate=224 Ez a rész néhány teljes parancsot mutat a VCD/SVCD/DVD kompatibilis videók készítéséhez. mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd:tsaf \ -vf scale=720:576,harddup -srate 48000 -af lavcresample=48000 \ -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\ keyint=15:vstrict=0:acodec=ac3:abitrate=192:aspect=16/9 -ofps 25 \ -o movie.mpg movie.avi mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd:tsaf \ -vf scale=720:480,harddup -srate 48000 -af lavcresample=48000 \ -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\ keyint=18:vstrict=0:acodec=ac3:abitrate=192:aspect=16/9 -ofps 30000/1001 \ -o movie.mpg movie.avi Ha a forrás már AC-3 audióval rendelkezik, használd a -oac copy kapcsolót az újrakódolása helyett. mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd:tsaf \ -vf scale=720:576,harddup -ofps 25 \ -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:\ keyint=15:vstrict=0:aspect=16/9 -o movie.mpg movie.avi Ha a forrás már AC-3 audiót tartalmaz és NTSC @ 24000/1001 fps: mencoder -oac copy -ovc lavc -of mpeg -mpegopts format=dvd:tsaf:telecine \ -vf scale=720:480,harddup -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:\ vrc_maxrate=9800:vbitrate=5000:keyint=15:vstrict=0:aspect=16/9 -ofps 24000/1001 \ -o movie.mpg movie.avi mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd -vf \ scale=480:576,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ vcodec=mpeg2video:mbd=2:keyint=15:vrc_buf_size=917:vrc_minrate=600:\ vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224:aspect=16/9 -ofps 25 \ -o movie.mpg movie.avi mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xsvcd -vf \ scale=480:480,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ vcodec=mpeg2video:mbd=2:keyint=18:vrc_buf_size=917:vrc_minrate=600:\ vbitrate=2500:vrc_maxrate=2500:acodec=mp2:abitrate=224:aspect=16/9 -ofps 30000/1001 \ -o movie.mpg movie.avi mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf \ scale=352:288,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ vcodec=mpeg1video:keyint=15:vrc_buf_size=327:vrc_minrate=1152:\ vbitrate=1152:vrc_maxrate=1152:acodec=mp2:abitrate=224:aspect=16/9 -ofps 25 \ -o movie.mpg movie.avi mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=xvcd -vf \ scale=352:240,harddup -srate 44100 -af lavcresample=44100 -lavcopts \ vcodec=mpeg1video:keyint=18:vrc_buf_size=327:vrc_minrate=1152:\ vbitrate=1152:vrc_maxrate=1152:acodec=mp2:abitrate=224:aspect=16/9 -ofps 30000/1001 \ -o movie.mpg movie.avi