Insider

A kodekek kiválasztása nem kell, hogy nehéz legyen. Nem, tényleg nem kell. Csak az számít, hogy a megfelelő codecet válaszd ki.

A videókészítés folyamatának minden egyes lépésén végigvezetlek. Kattints egy címre, hogy az adott szakaszra ugorj. A következőkkel foglalkozom:

• A codec, amit felveszel
• A codec, amit szerkesztesz
• A codec, amit színkorrigálsz
• A codec, amit a VFX-nek küldesz
• A codec, amit exportálsz
• A codec, amit archiválsz

Minden szakaszban, Elmagyarázom, hogy milyen tényezőket kell figyelembe venned a codec kiválasztásakor. Adok néhány példát az adott szakaszban leggyakrabban használt kodekekre is.

Eközben kitérek arra, hogy az alacsony és a magas szintű kodekek miért lassíthatják a szerkesztést, a proxy/offline szerkesztés okaira, egy valós projekt végigvezetésére, néhány tárolástakarékossági stratégiára, és magyarázatot adok arra, hogy miért nem javíthatja a képminőséget az átkódolás.

A kodekek optimalizálásának előnyei óriásiak lehetnek. Válassza ki a megfelelő kodeket, és a legjobb minőségben őrizheti meg képeit. Emellett gyorsabbá teheti a munkát, és lehetővé teszi, hogy a lehető legjobban kihasználja számítógépét és tárhelyét. Egy laptopon gyorsabban dolgozhat, mint sokan egy csúcskategóriás toronnyal.

Mit csinál egy kodek

A kodek egy módszer a videofájlok kisebbé tételére, általában olyan adatok gondos kidobásával, amelyekre valószínűleg nincs igazán szükségünk. És elég okosan csinálják ezt. Néhány évvel ezelőtt készítettem egy videót, amely bemutatja a főbb tömörítési technikákat, amelyeket sok kodek használ. Nem kötelező megtekintése a cikk megértéséhez, de biztosan nem árthat.

How Codecs Work – Tutorial.

Ha kihagyod a videót, itt van néhány nagyon alapvető magyarázat:

• Chroma subsampling: Kidob néhány színadatot (a 4:4:4 nem chroma mintavételezés. A 4:2:2 némi chroma-alulmintavételezés. 4:2:0 sok chroma-alulmintavételezés). Rossz, ha színkorrekciót végzel. Nagyon rossz, ha green screen vagy VFX munkát végzel.
• Makroblokkolás: Hasonló színű (különböző méretű) blokkokat keres, és mindegyiket ugyanolyan színűvé teszi. Rossz VFX és színkorrekció esetén. Szinte minden codec használja ezt valamilyen mértékben, és a mennyisége általában a bitráta függvényében változik.
• Időbeli tömörítés: Az előző képkockákat (és néha a következő képkockákat) használja az aktuális képkocka kiszámításához. Szerkesztésnél rossz.
• Bitmélység: A lehetséges színek száma. A mélyebb bitmélység (nagyobb számok) jó a színkorrekcióhoz és a VFX-hez.

Kodec-összehasonlító táblázat

Az utómunka világában használt leggyakoribb kodekek listáját is összeállítottam. Ez a lista segíthet összehasonlítani a különböző kodekeket egymással, és meghozni a legjobb döntést a projektje számára.

A vágási folyamat során számos különböző kodek használható. Az általam felsoroltak messze a legelterjedtebbek. A népszerű kodekek használatának jelentős előnye van. Nagyobb valószínűséggel működnek a te rendszereden, az ügyfeled rendszerén, a te öt év múlva működő rendszereden, stb. És könnyebb segítséget találni, ha valami elromlik.

A táblázat megnyitása új lapon. Így a cikk olvasása közben összehasonlíthatja a kodekeket.

Nézze meg a táblázatot

Veszteség

A táblázat egyik oszlopa a “veszteségesség”, ami a kodekeknél fontos fogalom. Amikor veszteségességről beszélek, nem feltétlenül arra gondolok, amit a szemed lát. Arra az adatmennyiségre gondolok, amelyet a codec megtart, és amelynek csak egy részét láthatod. A kérdés a következő: Ha lenne egy tömörítetlen képem, és aztán tömöríteném ezzel a kodekkel, mennyire hasonlítana az új kép a régi képhez? Mennyi információ vész el az átkódolás során? Ha a két kép nagyon hasonló, akkor a kodek nem túl veszteséges. Ha pedig eléggé különböznek, akkor veszteségesebb.

A veszteségesség az adott codec által használt technikák és a bitráta kombinációja. Egy veszteségesebb codec nem feltétlenül rossz. Bizonyos esetekben (például online nézéskor) tényleg nem szükséges az eredeti kép 100%-ának megtartása. A veszteségesebb codec használata nagyon okos lépés lehet, mert sok helyet takarít meg.

Ha a kép ugyanolyan jól néz ki a szememnek, akkor miért érdekel, hogy technikailag “veszteséges”?

Ez azért érdekel, mert lehet, hogy meg akarja változtatni a képet. Ha bármilyen színkorrekciót végzel, akkor megváltoztatod a képet. Ennek az lehet az eredménye, hogy a kép olyan elemeit látja, amelyek nem voltak láthatóak (vagy kiemelkedőek), amikor rögzítette.

Itt van például egy nyersen rögzített kép.

Itt van egy H.264-gyel tömörített képernyőmentés, a YouTube által ajánlott szabványos beállításokkal.

Aztán pedig DNxHD 350x-el tömörítve:

Mindegyik nagyjából ugyanúgy néz ki, nem? A vizuális minőség nagyjából ugyanaz, és a H.264-es fájl töredéke a DNxHD fájl méretének. Ezért is ez az ajánlott beállítás a YouTube-on. Szemre körülbelül ugyanolyan jól néz ki, és a fájlt sokkal könnyebb feltölteni az internetre.

A H.264-es verzióval azonban akkor van baj, amikor megpróbálsz változtatni a képen. Mi lenne, ha növelni akarnánk az expozíciót?

Most láthatjuk, hol esik szét az erősen tömörített kép. A haja és az inge szörnyen néz ki a h.264-es képen, a folyóparti épületek pedig teljesen pépesnek tűnnek.

Ez az oka annak, hogy a kép rögzítésekor valóban jó minőségű codec-et akarsz használni. Mert később valószínűleg változtatni akarsz majd, de még nem tudod, mik lehetnek ezek a változtatások. Finomítani akarsz majd a színeken és a kontraszton, esetleg a sebességen, esetleg hozzáadsz néhány VFX-et. Egy erősen tömörített fájl nem teszi lehetővé ezeket a változtatásokat anélkül, hogy szétesne.

Ez az oka annak, hogy jó ötlet 10 biten rögzíteni a felvételeket, még akkor is, ha a végén 8 bites fájlt adsz ki. A felvételkészítéskor nem tudhatja, hogy milyen bitekre lesz szüksége.

A kódok utazása

Most itt az ideje, hogy végigmenjünk a különböző szakaszokon, amelyekkel az egyes projektek során találkozni fog.

Minden projekt egy kóddal kezdődik, amelyet a kamerában rögzít. És egy olyan codec-kel végződik, amelyet exportálsz (delivery codec) és átadsz az ügyfelednek vagy feltöltesz a webre. A legegyszerűbb esetben az összes szerkesztést és színkorrekciót közvetlenül a kamera fájljain végzi el. Ezután exportálod a szállítási kodekbe, így mindig csak két kodeket használsz.

De a legtöbbször ez egy kicsit bonyolultabb. Lehet, hogy más codec-be kódolsz át a szerkesztéshez, és esetleg a színkorrekcióhoz, és mindenképpen a VFX-hez. De minden a következőkkel kezdődik…

A codec, amellyel forgatsz

(vissza az indexhez)

Ez a rögzítési codec (más néven “kamera natív codec” vagy “felvételi codec”).

Általánosságban elmondható, hogy a legjobb minőségű codec-et kell választanod, amelyet a kamerád (vagy a költségvetésed) képes rögzíteni. A “legmagasabb minőség” alatt azt értem, hogy a lehető legtöbb információt szeretné rögzíteni. Tehát kevésbé veszteséges kodekeket szeretne: kevesebb tömörítést, nagyobb bitmélységet és kevesebb chroma-alulmintavételezést. Minél több információ áll rendelkezésre a rögzítéskor, annál nagyobb lesz a későbbi rugalmasság. Különösen a színkorrekcióban és a VFX-ben (ha ilyesmit csinálsz).

A döntés során természetesen sok más, gyakorlati tényezőt is figyelembe kell venned. Különben mindig 8K nyersen vennénk fel, nem?

Költség

Az első szempont nyilvánvalóan a költség. Általánosságban elmondható, hogy minél drágább a kamera, annál jobb minőségű kodekek állnak rendelkezésre rajta. Azért mondom, hogy általában, mert vannak olyan “sweet spot” kamerák, amelyek elfogadható áron kiváló kodekeket kínálnak. A Panasonic GH szériája (különösen a kezdeti időkben, amikor a GH2-t feltörték) arról volt ismert, hogy jobb kodekeket kínál, mint az árkategóriájába tartozó többi kamera.

Tipp: Jobb kodekek külső felvevővel
Az olcsóbb kamerákkal is jobb minőségű kodekek rögzítésének egyik módja a külső felvevő használata.

Ezek az eszközök (amelyek közül sok külső monitorként is használható) tömörítetlen jelet vesznek a kamerából HDMI-n vagy SDI-n keresztül, és azt külön tömörítik. Így a végén két másolatot kapsz a felvételekből. Az egyik példány erősen tömörített a kamerán, a másik pedig enyhén tömörített a külső felvevőn. A legfontosabb dolog itt az, hogy a kamera a jelet a tömörítés előtt küldi ki a felvevőnek.

Egy fontos megjegyzés, hogy sok olcsóbb kamera csak 8 bites kimenetet ad ki, és gyakran nem 4:4:4-ben. Egy külső felvevő esetleg képes lehet 12 bites codec-re tömöríteni. De ha a kamera csak 8 bitet küld, akkor a felvevő is csak 8 bitet tud rögzíteni. Egyes olcsóbb kamerák szintén előfordulhat, hogy nem adnak ki olyan “tiszta” HDMI-jelet, amely alkalmas a rögzítésre. A kimeneti jelet akkor nevezzük “tisztának”, ha az csak a tiszta képet tartalmazza, kamera interfész átfedések nélkül.

Tárolás

A második figyelembe veendő tényező a tárhely. A jó minőségű kodekek általában magasabb bitrátájúak, ami azt jelenti, hogy a fájlok nagyobbak. Fel kell készülnie arra, hogy ezeket a fájlokat felvétel közben tárolja és biztonsági másolatot készítsen róluk. És előfordulhat, hogy a memóriakártyákat is frissítenie kell ahhoz, hogy képes legyen a nagy bitsebességű adatok rögzítésére. Ha egyedül forgat, akkor előfordulhat, hogy végül alacsonyabb minőségű kodeket választ, mert így ritkábban kell memóriakártyát cserélnie.

Finishing

Egy másik megfontolandó tényező az, hogy mennyi színkorrekciót és VFX-et (együttesen finishingnek nevezik) tervez. Ha nagyon minimális színkorrekciót fog végezni, és nincs VFX, akkor valószínűleg megúszhatja az alacsonyabb bitmélységet, a chroma-alulmintavételezést és a makroblokkolást, amelyek a gyengébb minőségű rögzítési kodekekkel járnak.

Szerkesztő hardver

Az utolsó tényező, amelyet figyelembe kell vennie, a szerkesztőgép. A legtöbb rögzítési kodek nem alkalmas nagy teljesítményű számítógép nélküli szerkesztésre. A H.264 és néhány nyers fájl nagy teljesítményű CPU/GPU-t igényel a zökkenőmentes szerkesztéshez. A nagyon nagy bitsebességű kodekek pedig nagy sebességű merevlemezeket vagy adatkiszolgálókat igényelhetnek. Hacsak nem egy szerkesztésbarát kódkóddal készít felvételeket, előfordulhat, hogy a szerkesztés előtt át kell kódolnia a fájlokat egy másik kódkódba. Ez pedig időbe telhet. Egyesek számára a felvételek átkódolása nem jelent nagy problémát, mivel ez akár egy éjszaka alatt vagy egy tartalék számítógépen is elvégezhető. Ha azonban nagyon szoros határidővel dolgozik, érdemes olyan kodeket választania, amely lehetővé teszi, hogy a forgatás után azonnal elkezdhesse a vágást, még akkor is, ha ez magasabb költséggel vagy a képminőség feláldozásával jár. A következő részben elmagyarázom, hogy mely kodekek a legjobbak a szerkesztéshez.

A kodek, amellyel szerkeszteni kell

(vissza az indexhez)

Miért kell átkódolni a vágás előtt? Nem szerkeszthetem egyszerűen a kamerából kikerült fájlokat?

Nos, ez attól függ. Nagyjából az összes nagyobb szoftvercsomag ma már képes szerkeszteni bármilyen codec-et, amit a fényképezőgéped létrehoz. (Hacsak nem vagy egy vagány, aki vadonatúj kamerával, vadonatúj technológiával fényképez). De bár szinte mindig lehetséges a kamerával felvett codec-ek szerkesztése, nem mindig ez a legjobb ötlet.

Ha olyan szerencsés, hogy olyan codec-kel készít felvételeket, amely kiválóan alkalmas a szerkesztésre, akkor ezt a lépést kihagyhatja.

Sokunk számára azonban a felvételi codec nem lesz optimalizálva a szerkesztésre. Két fő tényezőt kell figyelembe vennie a szerkesztési kodek kiválasztásakor: a tömörítés típusát és a bitsebességet.

A nagymértékben tömörített kodek lassíthatja a szerkesztést

(vissza az indexhez)

A legtöbb alsó és középkategóriás kamera olyan kodekkel rögzít, amelyek időbeli tömörítést, más néven long-GOP tömörítést használnak. Itt egy egyszerű magyarázatot adok, de ha részletesebben szeretnéd megismerni, nézd meg a 19:00-tól kezdődően a codecekről szóló videómat.

A long-GOP egyszerű magyarázata az, hogy minden egyes képkocka esetében a codec csak azt rögzíti, ami az adott képkocka és az előző képkocka között változott. Ha a videó nem tartalmaz sok mozgást, akkor az új fájl SOKKAL kisebb lehet. A különbség e képkocka és az előző képkocka között csak néhány pixel. Tehát csak néhány képpontot kell tárolni. Ez nagyszerű!

Mindig előre

A probléma azonban az, hogy ezek a kodekek általában csak előre lejátszva működnek jól. (Ha kíváncsi vagy, hogy miért, nézd meg a videót). Ez nagyszerű a YouTube-on és a DVD-lejátszón való megtekintéshez, de nem jó szerkesztéshez. Szerkesztés közben gyakran ugrálsz, vagy visszafelé játszod le a klipet. És sokkal több feldolgozási teljesítményre van szükség ahhoz, hogy ezeket a dolgokat gyorsan elvégezzük egy hosszú GOP-kódkóddal. Egy csúcskategóriás számítógépnek talán nem okoz gondot, de még egy középkategóriás számítógép is lemarad és dadogni fog, ha gyorsan átfutod a felvételt, vagy ugrálsz.

A nem long-GOP kodekek (más néven intra-frame kodekek) ugyanolyan könnyen lejátszhatók visszafelé, mint előre. Tehát még egy középkategóriás számítógép is képes nagyon simán ugrálni. Ha eddig csak egyenesen a kamerából vágtál klipeket, nem biztos, hogy rájössz, mit hagysz ki!

A másik dolog, ami problémákat okozhat a lejátszással, a nyers videó. A nyers videót konvertálni kell, mielőtt megjeleníthető lenne (olyasmi, mint a codec). És egyes számítógépek nem tudják elég gyorsan dekódolni a nyers fájlt, különösen, ha az 4K-s. Ironikus módon mind az alsó és mind a felső kategóriás kamerák olyan fájlokat állítanak elő, amelyeket nehéz szerkeszteni!

A magas bitrátájú kodekek lelassíthatják a szerkesztést

(vissza az indexhez)

Az alsó és középkategóriás kodekek esetében egyáltalán nem kell aggódnia a bitráták miatt. Amint azonban elkezdesz felfelé haladni a ranglétrán, a magas bitrátájú kodekek problémákat okozhatnak a szerkesztésnél, különösen, ha hétköznapi számítógépen dolgozol.

Az ok az, hogy a számítógépednek legalább olyan bitrátával kell tudnia olvasni az adatokat a merevlemezről, mint a kodek bitrátája. Ennek van értelme – ha a kodek 50 Mb/s (ötven megabit másodpercenként), akkor a számítógépnek képesnek kell lennie arra, hogy 50 Mb/s sebességgel olvassa a fájlt a merevlemezről, különben lemarad és dadogni fog.

(vegye figyelembe, hogy az Mb/s a megabit másodpercenként, míg az MB/s a megabájt másodpercenként rövidítése.) Egy bájtban nyolc bit van, ezért az MB/s-ról Mb/s-ra történő átváltáskor 8-cal kell szorozni)

Egy kis jó hír

A jó hír az, hogy a merevlemezek napról napra gyorsabbak. Tehát az 50 Mb/s soha nem fog gondot okozni. De mi van akkor, ha ProRes 422HQ-t szerkesztesz 4K-ban, ami 734Mb/s? Az átlagos külső merevlemez alig elég gyors ahhoz, hogy ezt lejátssza. Néhány olcsóbb merevlemez egyáltalán nem bírja. És mi van akkor, ha egy három kamerát tartalmazó multikamerás felvételt szerkeszt? Hirtelen 3x ekkora adatátviteli sebességre van szüksége: 2,202 Mb/s! Ekkor be kell fektetnie néhány nagy teljesítményű merevlemezbe vagy RAID-be.

Itt van néhány durva iránymutatás az általános adattárolási sebességekre vonatkozóan. (Mindig lesznek bizonyos modellek, amelyek alul- vagy túlteljesítik.)

• Szokásos pörgős meghajtó: 100-120 MB/s
• Professzionális pörgős meghajtó: 150-200MB/s
• Standard SSD: 400-500 MB/s
• Alacsony szintű RAID: 200-300 MB/s
• Magas szintű RAID: 1000-2000 MB/s

A naplóban való felvétel lassíthatja a szerkesztést

A naplóban való felvétel egy módja annak, hogy a lehető legtöbb dinamikai tartományt megőrizze. Ez lehetővé teszi, hogy a jelenet világos fénypontokkal és sötét árnyékokkal rendelkezzen anélkül, hogy a fénypontokat kifújná vagy a feketéket összezúzná. Az elszállt fénypontok különösen kellemetlen mellékhatása a film helyett videóra történő felvételnek. A naplóban történő felvételkészítés tehát segíthet abban, hogy a felvételek filmszerűbbnek tűnjenek. Most, hogy a legtöbb prosumer kamerán is elérhetőek log-profilok, ez egy rendkívül népszerű munkamódszer.

A hátránya

A hátránya, hogy a kamerából kijövő kép nem néz ki olyan jól. Kontrasztot és telítettséget kell hozzáadnod ahhoz, hogy akár csak megközelítsd a végleges képet. Ennek legelterjedtebb módja, hogy LUT-ot adsz a felvételhez. Ez lényegében egy egyszerű, előre beállított színkorrekció, amely visszaadja a felvételek “normál” kinézetét.

Ha log színtérben készít felvételeket, akkor LUT-ot kell alkalmaznia a felvételekhez, hogy normál színű és kontrasztú előnézetet kapjon. Ez azt jelenti, hogy a szerkesztőjének a vágás során az összes klipre alkalmazni kell a megfelelő LUT-ot. Ennek kezelése bosszantó lehet, és a számítógépet is lelassíthatja egy kicsit. Ennek oka, hogy először minden egyes képkockát dekódolnia kell, majd a megjelenítés előtt alkalmaznia kell a LUT-ot. Természetesen lehetséges a naplófelvételek szerkesztése LUT nélkül is, de ez nem ideális. Két felvétel színe befolyásolhatja azt, hogy hogyan vágja őket egymásba.

Ha a szerkesztés előtt átkódolja a fájlokat, akkor a LUT-ot az átkódolási folyamat során is alkalmazhatja. Így a szerkesztő mindig jó kontrasztú és színű felvételekkel dolgozik, és soha nem kell a LUT-okkal bajlódnia. Ne feledje, hogy ezt csak akkor tegye, ha Proxy munkafolyamatot használ, nem pedig Direct Intermediate munkafolyamatot (lásd alább).

Figyeljen a kódolásra fordított időre

A szerkesztés előtti átkódolás legfőbb hátránya egyszerűen az átkódolás időigénye. Ha sok felvételen kell átnéznie, és a számítógépe nem gyors, ez sokáig tarthat. Ha nem sietsz nagyon, hagyhatod, hogy az átkódolás egy éjszakán át fusson, esetleg több számítógépen is, ha van hozzáférésed hozzájuk, de ez nem mindig ideális.

Amikor a Khan Academy-nél dolgoztam, az alapítónk rendszeresen rövid videoüzeneteket vett fel, amelyeket elküldött az embereknek. Akiknek gyakran nagyon szoros volt az időbeosztásuk. Általában 4K-ban, hosszú GOP-napló formátumban vettem fel, és egy MacBook Prón szerkesztettem őket. A 4K hosszú-GOP formátumban, LUT-tal (a naplófelvételek korrekciója érdekében) történő szerkesztés egy laptopon azt jelentette, hogy a Premiere Pro-ban remekül vissza tudtam játszani a videót, de nem tudtam olyan gyorsan zoomolni az idővonalon, ahogy szerettem volna, anélkül, hogy dadogott volna.

De ez nem zavart túlságosan, mert a szerkesztés rendkívül egyszerű volt. Csak néhány vágás, talán egy kis zene, egy cím, és kész is voltam. Bár a vágási sebességem nem volt ideális, több időt töltöttem volna az átkódolással, mint amennyit a vágási sebességben megtakarítottam volna, ezért csak az eredeti fájlokat használtam.

Ha azonban egy hosszabb darabot vágnék ugyanezzel a beállítással, akkor DNxHD vagy ProRes formátumba kódolnék át. Általában az átkódolás nagy részét egy éjszaka alatt végezném el, gyakran több gép egyidejű futtatásával.

Proxy Edit

(vissza az indexhez)

Ha a natív kamerafájlokat a szerkesztés előtt átkódolja, akkor egy “köztes” kodeket használ. Azért hívják köztesnek, mert a rögzítő codec és az export codec közé kerül. A köztes kodekekkel való munkának két gyakori módja van:

Az első a “proxy” munkafolyamat vagy az “offline szerkesztés”. Ez azt jelenti, hogy a rögzített felvételeket átkódolja egy köztes formátumba, azzal a formátummal szerkeszti, majd exportálás előtt visszakapcsolódik az eredeti kamerafájlokhoz. Mivel az exportáláshoz a kamera fájlokat fogja használni, nem pedig a proxy fájlokat, nem kell annyira aggódnia a nagyszerű képminőségű proxy codec kiválasztása miatt – a veszteséges codec-ek is megfelelnek. Ehelyett optimalizálhat a szerkesztési sebességre és a tárolási kényelemre.

A proxy munkafolyamat annyira elterjedt, hogy sok csúcskategóriás kamera egyszerre rögzít egy csúcskategóriás nyers fájlt *és* egy ProRes vagy DNxHD proxy fájlt. A felvétel után a nyers fájlokat lementik és tárolóba helyezik. A proxy-fájlokat elküldik a vágóknak és a rendezőnek/producernek a napijegyek elkészítéséhez.

Kerülje az időbeli tömörítést

A proxy-kódc kiválasztásakor olyat válasszon, amely nem használ időbeli tömörítést (más néven inter-frame tömörítést vagy long-GOP tömörítést), és olyat, amelynek alacsonyabb a bitrátája. Az alacsony bitráta azt jelenti, hogy a fájlok sokkal kisebbek, így kevesebb/kisebb/olcsóbb merevlemezt használhat, ami egyszerűsíti a munkafolyamatot. Woot!

Míg a proxy fájlok nagyszerűek a szerkesztéshez, a proxy fájlokkal nem szabad az alapvető színkorrekciónál többet csinálni. Ha az összes színkorrekciót a szerkesztőszoftveren belül fogja elvégezni, akkor a legjobb, ha visszahivatkozik a kamera fájljaira, mert a proxy fájlok színminősége gyengébb lehet.

A jó hír az, hogy a legtöbb szerkesztőszoftver ma már pár kattintással tud váltani a kamera fájlok és a proxy fájlok között, így akár oda-vissza is válthat, ha szükséges.

A főbb NLE-k mindegyikében részletes útmutatókat tettünk közzé a proxy-munkafolyamatokhoz:

• Final Cut Pro X proxy munkafolyamatok
• Premiere Pro proxy munkafolyamatok
• Avid Media Composer proxy munkafolyamatok

Néhány jó választás a proxy kodekekhez

A messze leggyakoribb proxy kodekek a DNxHD/DNxHR és a ProRes. Mindkettő már évek óta létezik, így nagyon széles körben támogatottak. Mindenki tudja, hogyan kell kezelni őket. Mindkettő nagyon jól alkalmas proxy munkafolyamatra (a ProRes-nek még egy “proxy” nevű előbeállítása is van), és szinte felcserélhetőek, ha proxyként használják őket.

ADNxHD-t az Avid készíti, a ProRes-t pedig az Apple. Így logikus, hogy a DNxHD jobban működne a Media Composerben, a ProRes pedig a Final Cut Pro X-ben. Régebben ez biztosan így volt, de ma már mindkét codec nagyon simán működik minden modern szerkesztőprogramon (beleértve a Premiere Pro-t is). Lehet, hogy van egy kis sebességnövekedés a rendszerhez tervezett codec használatában, de ez nagyon csekély.

Az egyetlen jelentős különbség a kettő között a proxy munkafolyamat szempontjából az, hogy a ProRes létrehozása PC-n nehézségekbe ütközhet, míg a DNxHD-t nagyon könnyű cross-platformon létrehozni. Az egyetlen hivatalosan támogatott módja a ProRes létrehozásának PC-n az Assimilate Scratch. Van néhány más, nem támogatott módszer ProRes fájlok létrehozására PC-n, de ezek nem mindig megbízhatóak. A PC-ken könnyen lejátszhatók és szerkeszthetők a ProRes fájlok, de új ProRes fájlokat nem lehet olyan könnyen kódolni PC-n, mint a DNxHD-t. Ezért egyes szerkesztők emiatt a DNxHD munkafolyamatot részesítik előnyben.

Válassz egy sávot

Függetlenül attól, hogy a két kodek közül melyiket választod, azt is ki kell választanod, hogy melyik ízt szeretnéd. Ez tényleg a tárolási korlátoktól fog függeni – ez egy kompromisszum a képminőség és a fájlméret között. A jó hír az, hogy szerkesztés közben nincs szüksége csúcsminőségű képminőségre, így választhat alacsony bitsebességű kodeket.

Kezdje a legkisebb ProRes vagy DNx kodekkel, amelyek felbontása megegyezik a felvételi kodekkel. Nézze meg a GB/óra oszlopot, és szorozza meg a rendelkezésre álló felvételek óraszámával. Ha van elég tárhelye, akkor jó – használja ezt a codecet. Ha sok extra tárhelye van, gondolkodjon el a következő legnagyobb ízlésen.

De ha nincs elég tárhelye, vagy ha nem elég erős gépen dolgozik, akkor vegye lejjebb a felbontást. Sok nagy költségvetésű hollywoodi filmet még néhány évvel ezelőtt is 480p-ben vágtak, ezért ne izgulj, ha a vágáshoz a 4K-ról 720P-re kell csökkentened a felbontást.

Direct Intermediate

A másik típusú köztes munkafolyamat az, amit én Direct Intermediate-nek nevezek. Ez azt jelenti, hogy a kamerafájlokat átkódolja egy olyan kodekbe, amely egyszerre jó a szerkesztéshez és nagyon jó minőségű (nem túl veszteséges). Mivel a kodek nagyon jó minőségű, szinte az összes eredeti információ megmarad a kamera fájljaiból, így nem szükséges visszalinkelni a kamera fájljait – egyszerűen csak közvetlenül a köztes fájlokból exportálhat. Az átkódolás során elméletileg lesz némi információveszteség, de ha elég jó köztes codec-et választ, ez elég kicsi lesz ahhoz, hogy ne kelljen emiatt aggódnia.

(Megjegyzés: Ezt a folyamatot direkt köztesnek nevezem, mert erre a munkafolyamatra nincs általános elnevezés. Az emberek általában csak “köztesnek” hívják, de ez zavaró lehet, mert a proxy munkafolyamatok is egyfajta köztes munkafolyamatok. Néhányan ezt “online” munkafolyamatnak is nevezik, de ez is zavaró, mert ez a kifejezés olyan munkafolyamat leírására született, amely offline és online szerkesztést tartalmaz, nem pedig olyan munkafolyamatra, amely az elejétől a végéig online.)

A megőrzés a kulcs

A jó Direct Intermediate codec kiválasztásának kulcsa az, hogy biztosítsuk, hogy a rögzítő codec minden információját megőrzi. Egy köztes codec soha nem teszi jobbá a képeket (részletesebb magyarázat alább), de határozottan ronthat rajtuk, ha rossz codecet választasz. A legfontosabb dolog az, hogy megértse az eredeti felvételek részleteit, és megbizonyosodjon arról, hogy a köztes codec minden területen legalább olyan jó, mint a rögzítő codec. Ha a felvételeket egy DSLR fényképezőgéppel, például egy Sony A7Sii-vel rögzíti 4K-ban, akkor 4:2:0, 8 bites, Long-GOP kódkóddal rögzít 100 Mbps sebességgel. Olyan köztes codec-et szeretne, amely legalább 4:2:0 és 8 bites. Ezen értékek túllépése (pl. 4:4:4-re és 12 bitesre) nem árt, de nem is segít. Tehát valószínűleg nem éri meg a plusz tárhelyet.

Tegyük fel, hogy például ProRes codec-et szeretnénk használni. Választhatunk 4 lehetőség közül, amelyek 4:2:2 és 10 bitesek.

• 145Mb/s ProRes 422 Proxy
• 328Mb/s ProRes 422 LT
• 471Mb/s ProRes 422
• 707Mb/s. ProRes 422 HQ

Over and above

Azt gondolhatod, hogy csak a kamera bitrátájának (100Mbps) kell megfelelned, de valójában jelentősen meg kell haladnia a kamera bitrátáját. Ennek oka, hogy a h.264 sokkal hatékonyabb codec, mint a ProRes. Mivel a h.264 hosszú GOP tömörítést használ, sokkal több információt tud belepakolni ebbe a 100 megabitbe, mint a ProRes. Ahhoz, hogy a ProRes elérje a h.264 képminőségét, sokkal magasabb bitrátára van szükség. Én csak a ProRes 422 vagy ProRes 422 HQ használatát javasolnám, ha 100 Mbps-os h.264 kodekkel kezdesz. A ProRes 422 valószínűleg tökéletesen megfelel, de ha sok tárhelye van, akkor a ProRes 422 HQ-ra való áttérés némi előnyt jelent.

Míg a köztes kódoló kiválasztásakor nem baj, ha egyszerűen csak a bitmélység és a színmintavételezés megegyezik, a bitrátát legalább egy kicsit mindig növelni kell. Ha hosszú GOP-ról egy nem hosszú GOP-kódexre váltasz, akkor a bitrátát nagyon meg kell növelned.

Mellékjegyzet: Ha ProRes helyett DNxHD-t szeretnél használni, hasonló lehetőségeid vannak, kivéve, hogy a DNxHD egy 8 bites verziót is kínál az alsóbb kategóriás kodekekhez. Mivel a mi felvételeink eleve 8 bitesek, ez egyáltalán nem fog nekünk ártani.

A proxy munkafolyamat elég jól hangzott. Miért a Direct Intermediate?

A Direct Intermediate munkafolyamat részben azért elterjedt, mert régebben sokkal nehezebb volt proxy munkafolyamatot használni. Néhány nagy szoftverszolgáltató nem tette különösebben egyszerűvé az eredeti kamerafájlokhoz való visszakapcsolást, ezért az emberek a közvetlen köztes munkafolyamatot választották. Manapság azonban ez bármelyik szerkesztőcsomagban elég könnyen elvégezhető. A fő kivétel az, ha sok vegyes típusú felvétel van. Ha ugyanabban a projektben többféle képkockasebesség és képkockaméret van, a proxykról a rögzítési kodekekre való váltás fejfájást okozhat.

Ha a vágás megkezdése előtt harmadik féltől származó eszközöket használ a felvételek előkészítésére és rendszerezésére, ezek is megnehezíthetik az újrakapcsolási folyamatot. Ilyen például a hangsávokat automatikusan szinkronizáló szoftver vagy a többkamerás felvételek.

Nincs szükség cserére

A másik ok, amiért érdemes a Direct Intermediate munkafolyamatot használni, az az, hogy közvetlenül a színkorrekciós és VFX (“befejező”) folyamatra léphet, anélkül, hogy fájlokat kellene cserélnie. Olvasson tovább, és a Színkorrekció és VFX szakaszokban bővebben kifejtem, hogy ez miért kényelmes.

Az egyik hátránya azonban az, hogy nem tudja “besütni” a LUT-okat a szerkesztőjének – a LUT-okat a szerkesztőszoftver színkorrekciós effektjén keresztül kell alkalmaznia. Ha a LUT-ot beépítené a Direct Intermediate munkafolyamathoz történő átkódolásba, akkor eleve elveszítené a naplóban történő rögzítés minden előnyét.

A másik nyilvánvaló hátránya, hogy az összes ilyen (sokkal nagyobb) fájlt tárolni kell.

A köztes codec soha nem teszi jobbá a képeket

(vissza az indexhez)

Ez nagyon fontos, mert nagyon gyakran félreértik, és rengeteg téves információ található az interneten. A felvételek szerkesztés előtti átkódolása soha nem növeli a kimenet minőségét. Van néhány extra művelet, amit az átkódolási folyamat során elvégezhetsz (például kifinomult up-res eszközök használata), amelyek bizonyos esetekben növelhetik a képminőséget, de egy új codec önmagában soha nem fogja növelni a kép minőségét.

Ha a megfelelő codecet választod, elkerülheted a képed károsodását, de soha nem tudod javítani azt.

Ez vonatkozik a h.264-ről DNxHD-ra vagy ProRes-re történő átváltásra is. Ide tartozik az is, hogy 8 bitesről 10 bitesre váltasz. És a 4:2:0-ról 4:4:4:4-re való áttérés.

Itt egy illusztráció, amely segíthet megérteni ezt a fogalmat:

Ez a fénykép egy vízcseppben tükröződő rózsáról készült. Ez 4 megapixeles, és elég szépen néz ki a 27 hüvelykes monitoromon.

Most mi van, ha egy Red Helium 8k kamerával készítek egy fotót a monitoromról. Ez egy bestiális fényképezőgép. A rózsa fotóját néhány évvel ezelőtt egy ma kb. 250 dollárt érő cheapo Canon Rebel DSLR-rel készítettem. A Red Helium beállítás körülbelül 50 000 dollárba kerül, 35 megapixeles, nyers, és a valaha gyártott egyik legjobb kameraérzékelővel rendelkezik.

Melyik lesz a jobb kép – a 4 megapixeles fotó, vagy a 35 megapixeles fotó?

A felvétel egy felvételről

A Red kamerának több megapixele van, igaz? Ez nyers, és megvan benne az összes Red digitális varázslat, nem? De mivel a nagy felbontású fényképezőgépemmel a fényképet fotózom, nem pedig a rózsát, a flancos új képem sosem lesz jobb, mint az első. Van egy fájlom, amely technikailag nagyobb felbontású, de nem rögzít többet a témámból (a rózsából), mint az első.

Ezt csinálod, amikor átkódolod. Másolatot készítesz egy másolatról, lefényképezel egy fényképet. Ha egy flancos, nagy felbontású fényképezőgéppel készítesz egy fotóról egy fotót, akkor nagyjából az eredeti kép összes információját meg tudod őrizni, de nem tudsz hozzáadni semmi többet.

A nagy kikötés az, hogy ha bármilyen feldolgozást, bármilyen átalakítást végzel a képen (például LUT-ot adsz hozzá), akkor mindenképpen át kell kódolnod egy jobb minőségű kódolóba, amely megtartja az új információkat. De ha nem módosítja a képet, akkor az átkódolás nem teszi a képet valahogy “jobbá”.”

Egy valós példa

(vissza az indexhez)

Tegyük fel, hogy egy dokumentumfilmet szerkeszt, amely 4K-s felvételeket készített egy Sony A7sii kamerával, az XAVC-S hosszú GOP verziójában rögzítve. Nem ideális a szerkesztéshez. Ha 40 órányi felvételt készítettek a nagyjátékfilmedhez, akkor a végén kb. 2,7TB kamerafájlod lesz, ami simán elfér egy merevlemezen (persze, ha készítettél más, külön biztonsági mentéseket!).

Konvertálhatná ezt egy kiváló minőségű, nem túl veszteséges kódkódba a Direct Intermediate munkafolyamathoz, talán ProRes 422 HQ 4K-ban.

A hátránya az, hogy körülbelül 12,7 TB-ra lenne szüksége ahhoz, hogy az összes ProRes fájlt tárolja. Drága RAID-beállítást kellene használnia ahhoz, hogy könnyen hozzáférhessen az összes felvételhez egy projektben, legalább 1000 dollárért. Aprópénz egy nagy létesítménynek, de jelentős befektetés egy szóló szerkesztőnek.

A proxy választása

Ezért úgy dönthet, hogy inkább proxy munkafolyamatot használ, és átkódolja a fájlokat a ProRes 422 Proxy 4K formátumba. Ekkor a felvételeid csak 2,8 TB-ot foglalnának el, ami alig több, mint a rögzített felvételeid. Ezután könnyedén szerkeszthet egyetlen merevlemezről, és a munkafolyamat sokkal egyszerűbbé válik. (A bitráták és fájlméretek kiszámításához szükséges utasításokat ebben a cikkben találja: The Simple Formula to Calculate Video Bitrates).

Tegyük fel, hogy egy másik szerkesztővel dolgozik együtt, aki az ország másik felén tartózkodik. Lehet, hogy úgy döntesz, hogy a felvételt még lejjebb kódolod ProRes 422 Proxy HD-re, ami a felvételt mindössze 640 GB-ra zsugorítja, ami gyors kapcsolat esetén megvalósíthatóbbá válik az interneten keresztül történő elküldésre. (18 óra letöltés egy 80 Mbps sebességű kapcsolaton)

Amikor a szerkesztés befejeződött, csak vissza kell kapcsolni a projektet az eredeti kamera fájljaihoz, és exportálni kell. Annak ellenére, hogy te és a távoli szerkesztőd egy elég veszteséges codec-ben dolgoztatok, a végső exportálás megkerüli azt, így nem veszítesz a minőségből.

A codec, amit színkorrigálsz

(vissza az indexhez)

Oké, most már megvan a videó szerkesztése, és itt az ideje a színkorrekciónak. Minden, amiről itt beszélünk, vonatkozik arra, hogy a színkorrekciót a szerkesztőprogramon belül végzed, vagy a szerkesztésedet elküldöd egy dedikált színkorrekciós szoftverhez.

A nagy kérdés ezen a ponton az, hogy a színkorrekciót közvetlenül az eredeti kamerafájlokon akarod-e elvégezni, vagy pedig átkódolod. Ha proxy/offline szerkesztést végeztél, akkor a proxy fájlokat semmiképpen nem akarod színkorrigálni, mert azok alacsonyabb képminőségűek. Ahhoz, hogy jó döntéseket hozhassunk a színnel kapcsolatban, a rendelkezésre álló legjobb minőségű képre van szükségünk, mert pontosan látnunk kell, hogy mivel kell dolgoznunk.

Szóval jó minőségű képekkel kell dolgoznunk, és van néhány különböző lehetőségünk:

A. A fényképezőgép fájljainak osztályozása

Ez minden bizonnyal egy egyszerű lehetőség. Ha proxy-szerkesztést végeztél, akkor a befejezéshez visszahivatkozhatsz a kamera fájljaira, és mehetsz a városba. Ez maximális képminőséget biztosít, de emlékszel, hogy a kamera fájlokkal lassan lehet dolgozni? A kamera fájlok egy kicsit lelassíthatják a folyamatot, de az Ön által használt szoftvertől és a munka mennyiségétől függően úgy dönthet, hogy az egyszerűség megéri a kis potenciális lassulást. Ha rövid, nem túl bonyolult szerkesztésről van szó, akkor ez egy nagyszerű és egyszerű munkafolyamat lehet.

Tegyük fel, hogy a színkorrekció lassulása zavarja Önt, ezért olyan codec-re van szüksége, amellyel könnyebb dolgozni. Átkódolhatnád az összes felvételedet egy jó képminőségű codec-be, hivatkozhatnál ezekre a fájlokra, majd elkezdhetnéd a színkorrekciót. De… ez meghiúsítja a proxy munkafolyamat célját, nem igaz? Azért használtunk proxyt, mert nem akartunk foglalkozni az ezzel járó nagyméretű fájlokkal. Szerencsére van egy másik lehetőség is.

B. Összevonás és átkódolás

(vissza az indexhez)

Ha proxy/offline munkafolyamatot használt a szerkesztéshez, de nem akarja színkorrigálni a kamerafájlokat, egy jó lehetőség, hogy újracsatlakozik a kamerafájlokhoz, összevonja a projektet, majd átkódolja egy csúcskategóriás kodekbe.

A projekt konszolidálásakor a szerkesztőszoftver a média másolatával együtt elkészíti a projekt másolatát, de csak azokat az adott fájlokat, amelyeket végül a szekvenciában használt. Tehát ha 7 felvételt készítettél, de csak egyet használtál fel a szerkesztésben, akkor csak azt az egy felvételt fogja lemásolni. Ez nagymértékben csökkenti a tárhelyet, ami ebben a szakaszban nagyon jól jön. Még tovább is konszolidálhat, így az egyes felvételekből csak azokat a részeket tarthatja meg, amelyeket ténylegesen felhasznált a szerkesztésben, a többit pedig elvetheti. Ebben az esetben a szoftver általában tartalmaz néhány másodpercet az egyes felvételek előtt és után (úgynevezett “fogantyúk”), arra az esetre, ha fade-et vagy motion trackinget szeretne hozzáadni.

Kezdje el az osztályozást

Most foghatja ezt az új, konszolidált projektet (miután újra összekapcsolta az eredetivel), és átkódolhatja az összes fájlt egy nagyon jó minőségű, nagy bitsebességű codec-be, és elkezdheti a színkorrekciót. Ez azért más, mint a Direct Intermediate munkafolyamat, mert nem az összes felvételt kódolja át, hanem csak azokat a felvételeket, amelyek bekerültek a végső vágásba, és amelyek 1/20-ad vagy 1/50-ad része lehet az eredetileg felvett anyag hosszának. Most már nem is hangzik olyan rosszul a nagy bitsebességű codec-re történő átkódolás, mert nem kell olyan sokat tárolni belőle. Még ProRes 4444 4K-ban is csak körülbelül 2 TB lesz egy teljes hosszú játékfilm, ami elég jól kezelhető.

Most már egy zsebben is elférő merevlemezen fejezheti be a filmjét kiváló minőségű képekkel és gyors feldolgozással. Woot!

C. Folytassa a Direct Intermediate

A harmadik lehetőség, hogy a Direct Intermediate szerkesztési munkafolyamatot választja, ebben az esetben készen áll. Az összes fájlodat már átkódoltad egy kiváló minőségű kodekbe, mielőtt elkezdted volna a szerkesztést, így a színkorrekcióhoz egyszerűen folytathatod ugyanazokkal a fájlokkal. Ez azért is kényelmes, mert ezek a fájlok mind a szerkesztéshez, mind a színkorrekcióhoz és a VFX-hez (lásd alább) egyaránt jók.

Ha a projektet egy külső színezőnek vagy VFX-személynek adja át, akkor vagy átadhatja nekik az összes jó minőségű felvételét (ami a méret miatt potenciálisan bosszantó lehet), vagy használhatja ugyanazt a konszolidációs tippet, amit fentebb használtunk. A konszolidált projekt átadása segíthet gyorsabban haladni, és a színező idejét is megspórolhatja.

Egy másik előny

A Direct Intermediate munkafolyamat egyszerűsége mellett (csak egy fájlkészletet használ), van még egy előnye: egyszerűbb az oda-vissza járás a szerkesztés és a színkorrekció között.

Képzelje el, hogy befejezte a proxy-szerkesztést – konszolidálja és átkódolja, elküldi a színezőnek, majd úgy dönt, hogy néhány változtatást kell végrehajtania a szerkesztésen. Most vissza kell menned a proxykhoz, hogy elvégezd a szerkesztést, majd újra konszolidáld és újra elküldöd a felvételt. Ennek a mechanikája elég zűrös lehet. Egy csúcskategóriás utómunkafolyamatban általában van egy “zár” a vágáson, hogy a befejező folyamatok elindulhassanak. Ez azt jelenti, hogy (hacsak nem történnek rossz dolgok) nagyon igyekszik nem visszamenni és nem változtatni a vágáson. De hé, rossz dolgok előfordulnak, ezért jobb felkészültnek lenni.

És most találunk egy másik jó okot a Direct Intermediate szerkesztésre. Ha a színes munka és a vágási munka egy részét egyszerre fogod elvégezni, vagy legalábbis néhányszor oda-vissza fogsz menni, akkor egyszerűbb lehet, ha mindkettőhöz egy codec-et használsz. Ez különösen akkor kényelmes, ha a szerkesztést és a befejezést ugyanabban a szoftvercsomagban (vagy csomagok halmazában, pl. Creative Cloud) végzi.

A VFX-nek küldött kodek

(vissza az indexhez)

Ha bármilyen VFX-munkát végez, akkor valószínűleg egy másik programba (esetleg egy másik gépre, egy másik művésznek) kell fájlokat küldenie. Ha az összes VFX-munkát a szerkesztőprogramban végzi (ami egyre inkább életképes az egyszerűbb munkákhoz), akkor ezt a részt kihagyhatja. Csak használja ugyanazt a codecet, amit a színkorrekcióhoz használt.

A legtöbbünknek azonban be kell állítanunk egy “round-trip” folyamatot, amely elküldi a klipeket a szerkesztőből a VFX-szoftverbe, majd vissza, amikor elkészültek. Ez felvételenként történik, tehát nem a teljes szekvenciát küldjük a VFX-nek, mint ahogyan azt valószínűleg a színminősítésnél tettük. Az a kérdés, hogy a folyamat során mikor küldi el a felvételeket a VFX-nek, nagyban függ az adott munkafolyamattól.

Néhányan a vágás lezárása és a színkorrekció befejezése után küldik el a VFX-nek, de az időnyomás arra kényszerítheti, hogy már korábban elkezdje elküldeni a felvételeket.

Ha Premiere Pro-ban szerkeszt, és enyhe VFX-et készít After Effects-ben Dynamic Linkkel, akkor ezt a részt át is hagyhatja. A Dynamic Link automatikusan elvégzi helyetted a körbejárást. Ha sok VFX-munkát végzel, akkor is érdemes lehet használni az ebben a szakaszban található technikákat, mert a Dynamic Link túl sok projekt esetén kissé kényes lehet. Az Adobe azonban folyamatosan dolgozik ezeken a hibákon, így ez részben a személyes ízlésen múlik.

Go big or go home

A VFX-folyamatban általában két fő okból használunk nagyon nagy teljesítményű (nagy bitrátájú) kodekeket. Az első egyszerűen az, hogy a VFX művészeknek minden információra szükségük van, amit csak meg tudsz adni nekik ahhoz, hogy jól végezzék a munkájukat. A VFX-művészek a legválogatósabbak közé tartoznak, ha a kodekekről van szó, és erre jó okuk van. Mindenki jó minőségű képeket szeretne, de a képi problémák gyakran nagyobb problémát jelentenek a VFX esetében, mint a szerkesztés, a színkorrekció és a végső exportálás során.

A VFX-munka számos feladata a kép nagyon részletes, pixelenkénti szintű elemzését igényli, amit a legtöbb szerkesztőnek soha nem kell megtennie. Ha például zöld képernyős kivonást készítesz, azt akarod, hogy a karakter és a zöld képernyő közötti él a lehető legtisztább legyen. Mindannyian láttunk már szörnyű zöld képernyős felvételeket, ahol a karakter szélei elmosódottak vagy elmosódottak. Ezek a problémák gyakran a szabad szemmel láthatatlan képtömörítési artefaktumok miatt keletkeznek. A 4:2:2 vagy 4:2:0 színalulmintavételezés például szinte semmilyen látható hatással nincs a képre. Az emberi szem elsősorban a kontraszttal törődik, és ritkán veszi észre az alacsony színfelbontást, a greenscreen-kivonatolás folyamata azonban elsősorban a színértékekre támaszkodik. Ha a kodek a 4:2:0-s chroma-alulmintavételezéssel a színértékek nagy részét kidobta, a jó színkulcs lehetetlen lehet.

Generációs veszteség

A második ok, amiért érdemes csúcskategóriás kodeket használni, a generációs veszteség. A VFX-folyamat során valószínűleg többször kell tömörítenie a fájlt. Egyszer tömöríted a fájlt, amikor elküldöd nekik. Aztán, ha több szakember között kell továbbítaniuk a fájlt, előfordulhat, hogy kétszer vagy háromszor tömörítik azt a fájlt, mielőtt visszaküldik. Ha egy fájlt többször tömörítenek, azt többszörös generációs veszteségnek nevezzük.

Ha alacsony szintű codec-et használ, a kép minden egyes alkalommal, amikor újratömöríti, fokozatosan rosszabb lesz. Az igazán jó minőségű codec-ek egyik nagyszerű tulajdonsága, hogy többször is tömörítheted őket anélkül, hogy sokat veszítenél a minőségükből. Bár mindig jobb elkerülni egy videó többszöri tömörítését, ha nagyon jó minőségű kodekeket használ, akkor általában elég jól jár.

Ezért egyes csúcskategóriás VFX munkafolyamatok csak veszteségmentes tömörítést használnak. A jó hír az, hogy a VFX-felvételek általában klipenként csak néhány másodpercig tartanak, ami azt jelenti, hogy a fájlméretek még a csúcskategóriás kodekekkel is kicsik lesznek. Legyen tehát nagy! Ha 4:4:4-ben rögzítette a kamerával, akkor mindenképpen 4:4:4:4-ben küldje el a VFX-nek. Ellenkező esetben én egy csúcsminőségű 4:2:2 codec-et választanék (ProRes 422 HQ vagy DNxHQX).

És természetesen mindig előzetesen kommunikáljon a VFX-szel arról, hogy milyen codec-et küldjön. Ha úgy gondolod, hogy rosszul választanak, küldd el nekik ezt a cikket 🙂

A kódc, amit exportálsz

(vissza az indexhez)

Most befejezted a vágást, a színezést és a VFX-et – készen állsz az exportálásra. A végső exportot általában abból a szoftverből végzi el, amelyet a színkorrekcióhoz használt, és azt a codecet használja, amelyet a színkorrekció során használt.

Ha az ügyfele a médiabizniszben dolgozik, tudnia kell, hogy milyen codecet szeretne, így ennek a szakasznak a további részét átugorhatja!

Ha az ügyfél nem videószakértő, nem biztos, hogy tudja, mit szeretne, ezért néhány döntést meg kell hoznia helyettük. Az esetek többségében az ügyfele egy olyan videót szeretne, amelyet fel tud tölteni a YouTube-ra és/vagy más közösségi oldalakra. Lehet, hogy kísértésbe esik, hogy olyan codec-et válasszon, amely jó az interneten történő streameléshez. De tévedne!

Az ok: ezek az oldalak nem ugyanazt a fájlt streamelik, amit Ön feltölt a nézőinek – a streamelés előtt *újra* tömörítik a fájlt, és Önnek egyáltalán nincs befolyása az általuk használt beállításokra. Ez azt jelenti, hogy ha alacsony minőségű codec-et töltesz fel, akkor megvan az a forgatókönyv, hogy egy alacsony minőségű fotóról egy alacsony minőségű fotót készítünk, amiről beszéltünk. Rossz! Kerülje!

A legjobb minőségre törekszik

Általános szabály, hogy ha a legjobb minőségű eredményt szeretné, akkor a legjobb minőségű forrást kell feltöltenie. Úgyis újra tömöríteni fogják, így ha több adattal adsz nekik munkát, az nem árthat, nem igaz? Ha elég gyors kapcsolatod van, akkor ProRes 422-t is feltölthetsz. Néhányan valamivel (csak valamivel) jobb eredményekről számoltak be, amikor ProRes-t töltöttek fel az ajánlott h.264 helyett.

Ha egy ügyfélnek szállítasz egy fájlt, hogy feltöltse a Youtube-ra, akkor én nem adnék ProRes-t, mivel nem tudhatod, hogy milyen sávszélességük lesz. Szerencsére ezek az oldalak általában közzéteszik az ajánlott feltöltési specifikációkat (csak guglizz rá). Én személy szerint az általuk ajánlott bitrátát veszem, és körülbelül 1,5-szeresére vagy 2-szeresére szorzom.

Az ügyfeled olyan fájlt is akarhat, amelyet közvetlenül beágyazhat a weboldalába (bár én lebeszélném őket, ha lehet). Általánosságban elmondható, hogy nagyon erősen tömörített h.264-et szeretnél. Ha kíváncsi vagy, hogy mi a jó bitráta, az én érvelésem az, hogy ha valaki tudja, hogy mi az ideális bitráta, az a YouTube. Időnként letöltök egy videót a YouTube-ról, és ellenőrzöm a bitrátáját, és ezt használom viszonyítási alapként.

Kicsibe megyek

Ha a videó nem nyilvános, akkor is lehet, hogy egy kis fájlt szeretnének, amit elküldhetnek e-mailben vagy közvetlenül a saját kliensükre linkelhetnek, hogy le tudják tölteni. Ezekben az esetekben célszerű lehet két különálló fájlnál többet szállítani, különösen, ha hosszú videóról van szó. A YouTube-ra feltöltendő fájl túl nagy lesz ahhoz, hogy kényelmesen elküldhessék e-mailben. Ebben az esetben általában lefelé reszelem a fájlt, és nagyon erősen tömörítem. Neked is reálisnak kell lenned, és el kell döntened, hogy szerinted az ügyfeled valóban meg fogja-e érteni a két fájl közötti különbséget.

Ha több fájlt kell átadnom, akkor általában az egyiket “HD”-nek, a másikat pedig “kicsinek” vagy “nem HD”-nek nevezem a fájlnévben. Ha megpróbálod leírni nekik a különböző kodekeket, szinte garantálom, hogy jövő hétre elfelejtik a különbséget, de arra valószínűleg emlékezni fognak, hogy mit jelent a HD és a “nem HD”.

A Codec, amit archiválsz

(vissza az indexhez)

A fájl(ok)at átadtad az ügyfelednek, így most már hátradőlhetsz és pihenhetsz… majdnem.

Amint minden ebben az iparágban dolgozó szakember tudja, az a nap, amikor átadod a kész terméket az ügyfelednek, gyakran nem az utolsó alkalom, amikor hozzányúlsz egy projekthez. Előfordul, hogy az ügyfél hetekkel később vissza akar menni és módosítani akar valamit, vagy egy jobb minőségű kodeket szeretne, vagy esetleg hozzá akarod adni a személyes tekercsedhez. Ezen esetek bármelyikében előfordulhat, hogy más gépre vagy más szoftverre költözött, így fejfájást okozhat az eredeti projekt megnyitása és újbóli exportálása.

Ez praktikus

Ez az a pont, ahol jól jön, ha van egy nagyszerű archívum a kész projektről egy rendkívül jó minőségű kodekben. Ha az ügyfeled nagyon jó minőségű codec-et kért a szállításhoz, akkor általában készen állsz. Csak tartson meg egy másolatot erről a fájlról, és máris készen van. Ha azonban nem csúcsminőségű szállítási kodeket kérnek, akkor mindig jó, ha a saját exportálását veszteségmentes vagy a veszteségmenteshez minél közelebb álló kodekkel végzi, amennyit csak megengedhet magának, figyelembe véve a helyigényt. Általában egy nagyon nagy bitsebességű 4:4:4:4-es kodekbe exportálok – DNxHD/HR vagy ProRes.

Kérdése van? Kommenteljen.

Valójában minden hozzászólást elolvasok. Ez a cikk egy folyamatban lévő munka, és a visszajelzések alapján további magyarázatokkal és példákkal fogom frissíteni. Ha privát visszajelzésed vagy kérdésed van, írj nekem egy e-mailt: david at frame dot io.

Szeretnél írni a Frame.io blogba? Írj nekem e-mailt: blog at frame dot io.

Nagy köszönet Larry Jordannek, Shane Rossnak és Philip Hodgettsnek a cikkhez való hozzájárulásukért!