Minden felvétel elkészítésénél szinte a legelső döntések egyike között van a Codec kiválasztása, mely kameránként lehet eltérő, vagy esetleg kamerán belül több féle.
A felvételi codec kiválasztása előtt mindenképpen érdemes átgondolni a teljes project workflowját, mert ez nagyban meghatározó eleme lehet a teljes munkafolyamatnak.
(Kieg. Illetve utómunka során, a vágás végeztével is érdemes átgondolni, hogy kinek és milyen célra adjuk át a fájlunkat, vagy hogyan akarjuk azt tárolni/felhasználni, mert itt is ugyanazok a lentebb felsorolt szabályok lesznek érvényesek a fájlok kompresszálása során)
Mi az a Codec?
Ahhoz, hogy egy codecet ki tudjunk választani a felvétel előtt, fontos, hogy mindenki, aki a workflow részese, legalább az alapjait értse egy codec működésének.
A codec szó a compressor – decompressor vagy coder-decoder szavak rövidített szóösszetétele. A codek az a „szabályrendszer” ami megmondja az elektromos alkatrészeknek, hogy milyen előírások szerint kezelje a média fájlokat. (lásd. az Audio fájloknak is van codec-je).
A codecek a rögzítendő képet helytakarékossági okokból tömörítik, kódolják majd a következő használat során ezt dekódolják ismét hasznos „adatfolyammá”.
Fontos: A codec és a container nem egyenlő! Egy kodek képes több fajta containerbe is kerülni, tehát példaként, attól függetlenül, hogy MOV fájlod van, nem biztos, hogy azt utómunka során könnyen tudja kezelni, mert eddig az volt a tapasztalatod, hogy a MOV fájlokkal könnyen megbírkózott a géped. Egy MOV containerben lehet akár h265 kodek is, ami nagyon erőforrás igényes, vagy akár egy ProRes fájl is, melyet utómunkára találtak ki – tehát alapvetően könnyebben kezelnek a gépek ám jóval nagyobb a hely igényük.
A codecekre legtöbbször helytakarékossági okokból van szükség, mely lehet fizikai vagy elméleti hely is.
Lásd elméleti hely esetében, arra gondolok, hogy az adatmentés, tárolás és utómunka borzasztóan költséges lenne, ha minden anyagot „lossless” azaz veszteség-mentesen, tömörítetlenül mentenénk, de előfordulhat olyan eset is amikor egy kamera „fizikai” okokból nem tud lossless-t rögzíteni. (lásd Gopro, stb.) hiszen sem a processzora, sem az adatrögzítő egysége nem képes ilyen méretű fájlt írni / olvasni – méretéből vagy teljesítményéből adódóan.
Egy lossless 4K fájl esetében 1 percnyi anyag rögzítéséhez rengeteg GB helyre van szükségünk, mely írására pl. már egy egyszerű Sata csatlakozós HDD-k, amit az átlag számítógépek használnak, vagy az egyszerűbb SDHC – vagy SDXC kártyák nem is képesek, ezért láthatunk az újabb kamerákban NVMe(m2)-SSD -t , vagy gyorsabb Cfast kártyát, stb.
( – és mindemellett természetesen a kamerán belül jó processzornak is kell lennie, mely képes ezt az adatfolyamot leképezni – )
Szerencsére a technikai évről évre rohamosan fejlődik, így egyre gyorsabban jelennek meg sokkal kisebb és gyorsabb adathordozók, valamint a Codec-ek is fejlődnek, amik mára már jóval kisebb tárhelyen tudnak rögzíteni lossless vagy szinte lossless adatot(lásd. ProresRaw, BRaw, stb.), így a nagyközönségnek számára is egyre jobban elérhetővé válik a lossless adattal történő munka, illetve a workflow sem annyira embertpróbáló és hosszadalmas mint régen.
A codecek „eredeti” célja tehát az, hogy a (fájl) méret csökkentése mellett létrehozzanak egy olyan fájlt, amivel utana könnyebben menedzselheted a számodra szükséges workflowt.
És workflow alatt értjük jelen esetben akár az adott rögzítő eszközön belüli lejátszást is.
Példa: Családi nyaralás esetében inkább az a fontos, hogy minél többet rögzítés jó minőségben, mivel jó eséllyel nincs otthon utómunka stúdiója a felhasználónak, ám egy reklámfilm vagy filmforgatás során az a fontos, hogy minél jobb végeredményt érjünk el, a file méret (szinte) nem lehet befolyásoló faktor és még arra is gondolni kell, hogy milyen jellegű VFX vagy Color Gradingen fog átesni az anyag a jövőben, mert ezeknél a munkafolyamatoknál szükség van a többlet információkra a fájlon belül.
Attól függetlenül, hogy egy kép „kompresszálva van”, nem biztos, hogy a végeredményét tekintve a különbség szemmel látható lesz.
A nagyon high-end codecek képesek úgy leképezni a képet, hogy az könnyen kezelhető marad és közel lossless a tömörítés, ám nem minden codec „egyenlő” és nem is mindegyiknek ez a célja, ezért a rossz codec kiválasztása adott munkafolyamatra komoly problémákat okozhat.
Példának okáért a H.265 ( más nevein MPEG-H part2, vagy HEVC azaz High Efficiency Video Coding) , mely borzasztóan alacsony fájlmérettel képes rögzíteni nagyon jó minőségű képet (pl. drónok,akció kamerák, stb. használják) , de utómunka során amikor dolgozni akarunk vele, szinte minden gépnek fejfájást okoz. Bizonyos munkákhoz ez tökéletes lehet, ám a fájlt ajánltott utómunka előtt leproxyzni ( – erről majd egy másik bejegyzésben … – ) , azaz átkonvertálni egy könnyebben kezelhető, más codecet használó fájlba, de ha valamiért nagyon sürgős az anyag utómunkája és proxyzni nincs idő, akkor már érdemesebb elgondolkodni egy másik codec használatán.
Legismertebb „erősen kompresszált” fájlok: h264, h265
Legismertebb utómunka fájlok: Prores, DNxHR
Példa videó, hogy milyen a munka egy erősebb gépen ( – az adott beépített processzori decoder nélkül – ) egy 4k h265 fájllal, valamint milyen könnyen kezelhető miután leproxyzzuk és ProRes – Proxy fájlt csinálunk belőle.
A post-production (azaz utómunka) komoly részét képezi a Color Correction és a VFX (Visual FX – Visual Effects) amit ha rosszul választjuk ki a codecket, könnyen teljesen tönkre tehetünk.
Egy túlságosan kompresszált kép esetében olyan – nem feltétlenül szemmel látható – információkat veszíthetünk el, mely következtében már a fájlunk bizonyos „tevékenységekre” alkalmatlan lesz.
Példa:
CON:
– Egy 8-bites 4:2:0 H264 fájl color correctionre egyáltalán nem javasolt, tekintettel arra, hogy nehéz a fájt kezelni és kevés benne az információ. Itt az egyes értékek változtatása a kép részleteinek elvesztésével jár / vagy járhat.
Lásd csatolt kép. Ez egy „elnagyolt túlzás” ami a hiba jól láthatóságát akarja megmutatni.
Azért nem látjuk szépnek a naplementét, mert a bit mélysége a képnek kevés, azaz nem látjuk adott színek között az átmenetet, azaz kevés benne az információ. (A veszteség-menteshez képest erősen tömörített)
(8bit-ről azaz Bit Depth, azaz Bit Mélységről valamint Chroma Subsamplingről majd a következő bejegyzésben írok hosszabban … )
Hasonló eredményt tud az is produkálni, hogyha pl. a fehéregyensúlyt akarjuk ilyen fájloknál drasztikusan változtatni egy rosszul rögzített white balance miatt felvételkor. Ezek a fájlok ilyen drasztikus utómunkára a részletek megtartása mellett alkmatlanok.
… vagy VFX viszonylatban, nagyobb kompresszálású codec kiválasztása miatt egyes VFX elemek „leeshetnek” a képről, azaz azok túlságosan realisztikusak lesznek a túl kompresszált anyaghoz képest, így a fotórealisztikus munkát sokkal nehezebb itt elérni, hiszen a realisztikus kép inkább tűnik majd a szemnek kevésbé realisztikusnak a részletgazdagsága miatt.
PRO:
… Nagy fájlokat viszont a gyengébb gépek nem játszanak le vagy csak nehezen, akadozva, valamint a mozgatásuk is méretükből adódóan jóval nehezebb. (lásd internetes fájl küldés, stb.)
Ugyanúgy mint a kamerák, vágógépek, stb esetében, itt is a legfontosabb kérdés:
Mire lesz az adott …. használva?
[ – jelen esetben fájl – ]
Nem létezik legjobb kamera és nem létezik legjobb codec.
Minden munkához és munkafolyamathoz más az ideális!
Ha ez a bejegyzség egy kicsit is hasznos volt számodra akkor a következőeket is olvasd el mindenképpen, mert erősen kapcsolódnak egymáshoz.
A következő bejegyzések a Bit Depthről valamint a Chroma Subsamplingről fognak szólni.
Ha tetszett és hasznosnak ítélted meg ezt a „szösszenetet” vagy esetleg túl részletesnek, vagy nem elég részletesnek, akkor kérlek jelezd egy kommenttel és a jövőben tudni fogom inkább milyen nyelvezetre lenne igény egy ilyen apróbb bejegyzés megírása során 🙂
#FeedbackNeeded #thx
várom a következő cikkeket