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.
Számos általános típusa van a pulldown-nak:
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:
NTSC régiók:
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ú.
PAL régiók:
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
ahol:
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,
[1]
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. [2]!
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.
mplayerforras_fajl.vob-aid 129 -dumpaudio -dumpfilehang.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:
mplayerforras_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 -okimenet_film.avi\ -audiofilebemenet_audio.mp2bemenet_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 -okimenet_film.asf-audiofilebemenet_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 -okimenet.mkvbemenet_video.avibemenet_audio1.mp3bemenet_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.
[1] 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).
[2] 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!