Keresés

Új hozzászólás Aktív témák

  • erdoke

    titán

    válasz Thulcandra #127 üzenetére

    Leszedéskor szinte egyik progi se nyúl a filmhez, általában a kimenetén történnek változások. Ha ráfér DVD5-re, akkor nem bántja, ha nem adsz neki ilyenre utasítást. A hangot is csak elvétve tömöríti újra egy másoló progi, a legáltalánosabban használtak soha nem nyúlnak hozzá.

  • PPeter

    addikt

    válasz Thulcandra #124 üzenetére

    erdoke úgy értette, hogy ''AVI-ból'' dolgozik, hogy forrásként nem közvetlenül az eredeti MPEG, VOB állományokat nyitjuk meg a CCE-vel (mert azt nem is támogatja), hanem az avisynth segítségével egy scriptet adunk át neki, amelynek köszönhetően úgy tudja megnyitni az állományokat (közvetve), mintha egy AVI állományt nyitna ki.

    Az enkóder gyakorlatilag (attól függően persze, hogy milyen formátumokat támogat inputként) bármilyen videóállomány megnyitására képes (a CCE például az AVI állományokat szereti kimondottan), és ezekből készít MPEG adatfolyamot.

    Az MPEG veszteséges tömörítés, amely nem önálló képkockákat tárol a tömörítést követően, hanem úgynevezett képkocka-csoportokat (GOP - Group Of Pictures), amelyeken belül csak az úgynevezett I (Intra) képkockák tárolódnak el teljes mértékben. A GOP többi - többségben lévő - képkockájához csak az Intra kockákhoz képesti változást tárolja az algoritmus, kétféle módon, lehetnek P (Predicted) és B (Bi-directional) képkockák még, amelyek önállóan értelmezhetetlenek, csak a kiindulási I képkockák ismeretében jeleníthetők meg (ezért is nehézkes és nem ajánlott az MPEG, illetve bármilyen GOP alapú tárolási formátum utólagos vágása, újraszerkesztése, hiszen nem diszkrét képkockákról, hanem ezek csoportjairól van szó, és egy kocka megváltozatása érdekében a teljes GOP-ot, GOP-láncolatot újra kell kódolni, tömöríteni a kérdéses képkocka környezetében).

    A transzkóder csak egy már elkészült MPEG adatfolyam ''átkódolására képes'', a forrásként megadott MPEG stream sávszélességét, GOP felépítését megvizsgálva megpróbál a tömörített adatfolyamon még tovább optimalizálni - mivel az eredeti képanyag nem áll rendelkezésére, és jellemzően sokkal kisebb adatátviteli sévszélesség (bitráta) a cél, ezért a transzkódolás értelemszerűen jelentős minőségi veszteséggel járhat. Mivel teljes mértékű újrakódolás és analizálás nem történik, a folyamat jellemzően sokkal gyorsabb, mintha egy ''rendes'' enkódert venénk igénybe. Mivel a sávszélesség csökkentése mellett az adatfolyam felépítése lényegében nem lesz optimalizálva az új sávszélességhez igazodván (ezzel jobb eredeményt lehetne elérni, csak ugye erre nincs idő), ezért mindenképpen minőségi veszteséggel kell számolni a transzkóderek használata esetén.

  • erdoke

    titán

    válasz Thulcandra #118 üzenetére

    VEgyük példának a Cinema Craft Encodert (CCE) Multipass VBR tömörítéssel (lehet még OPV és CBR is). Ő úgy számolja a passokat, hogy először csinál egy vaf fájlt egy Vaf pass során. Ez azt jelenti, hogy átnézi a filmet, milyen a szerkezete, hol milyen a bitráta, a GOP struktúra, stb. Ezután a beállítottnak megfelelő menetben megcsinálja magát a tömörítést, ahol a létrehozott vaf fájlt használja infonak. A második pass során is ugynazt a vaf fájlt használja, ehát tulajdonképpen egy 1+1+1...+1 tömörtést csinál a beállítot passok számától függően. Más tömörítők egy pass-nak számítják az első, átvizsgálóó kört is, tehát ott egy 2 pass tömörítés valójában 1+1, míg CCE esetében ugynez a 2 pass 1+1+1.

  • erdoke

    titán

    válasz Thulcandra #115 üzenetére

    Pass = ''menet''. Hány menetben/körben csinálja a tömörítő progi az anyagot.

Új hozzászólás Aktív témák