Nandub SBC Guide CZ - I

Krátký Úvod

Nandub je nástroj pro vytváření vysoce kvalitních AVI souborů pomocí DivX kodeku a z tohoto důvodu se rychle stává populární nejen pro vytváření kvalitních záložních kopii DVDček, ale i pro účely komprimace digitálního videa obecně. Tento návod si neklade za cíle vysvětlit v češtině všechny části procesu zálohování DVDček, ale pouze části přímo spojené s Nandubem (tzn. nečekejte prosím detailní vysvětlivky jak používat DVD2Avi či VFAPI).
Tomu, kdo spěchá (anebo je líný si tento návod pořádně přečíst), doporučuji dále nepokračovat a vrátit se k Flasku. Ostatní jsou zváni k důkladnému přečtení souboru README.DOC (v Nandub adresáři), přečtení návodů na níže uvedených odkazech, důkladnému přečtení tohoto návodu a vyzkoušení si vlivu jednotlivých nastavení na nějakém krátkém klipu.

Dlouhý Úvod

Intro

Nandub je nástroj pro vytváření vysoce kvalitních AVI souborů pomocí DivX kodeku. Vyvinul jej Nando (aka vV_nn) z partičky, která si říká VcdVault (#vcdvault na DalNetu, odkud se dá poměrně hodně zajímavých věcí stáhnout) a která se kromě kromě klasického ripováni DVD, VCD a filmů obecně snaží o dosažení maximální kvality svých releasů (odtud pramení vechny jejich *DUPE* a *PROPER* releasy). V současné době je Nandub postaven na GPL kódu geniálního editovacího programu od Avery Leeho VirtualDubu (http://www186.pair.com/vdub/).
V době psaní tohoto návodu je poslední aktuální verzí verze 1.0rc.

Kde ho najit

• Samozřejmě že ho najdete na http://sweb.cz/divx.dvd/ :-)
• Dále pak má Nandub svoje vlastní stránky na http://www.nandub.org/ kde naleznete "oficialní" release od vV_nn.
• Na stránkách http://www.doom9.net/ lze většinou najít nejaktuálnější verzi a dokonce i pár starších.
• Modifikací "oficialního" kódu zatím není moc, autoři se (a to je dobře) většinou snaží o začlenění svých modifikaci do hlavni větve.
• vylepšená "Compression" od Marase - Nandub 0.21.3 na stránkách http://strony.wp.pl/wp/marek_74/index.html. (Pro ty, kdo chtějí pilovat kvalitu svých ripů a už vyčerpali všechny možná nastavení oficiální verze)
• Další vylepšená verze v0.23-maras+GUI-binary-fix3 (převážně od lidí Rock Hardy/Koepi/Maras) je na Koepiho stránkách

Návody

• Pravděpodobně nejlepší návod k Nandubu se nachází na stránkých doom9a www.doom9.net), v jehož forech (forum.doom9.net) se Nandub rozebírá a vylepšuje. Doom9 nemá rád když někdo linkuje dovnitř jeho stránek a jelikož ho plně respektuji, nebudu tak činit ani já. Tak tedy, kde návod najdete:
  • www.doom9.net
  • nalevo je sekce The Guides
  • dále pak DivX guides
  • a konečně Nandub: SBC encoding
• Jako druhotný zdroj informací mi slouži KOEPIho shrnutí (aka NANDUB OPTIONS EXPLAINED) (http://members.tripod.de/de_koepi/) (momentalne ve verzi 1.0, má tam též další info o Marasově modifikaci) z něhož jsem převážně vycházel
• a konečně také SBC fora na http://forum.doom9.net/.

Základní definice

Rozhodl jsem se přidat následující sekci ze dvou důvodů - jednak občas zaměňuji (mne bližší) anglické termíny s (ne nutné srozumitelnějšími) českými termíny, a za druhé mám pocit, že je třeba objasnit některé základní termíny digitálního videa:

Compression = komprese
Algoritmus/metoda kterak data, která zabírají hodně místa, vměstnat do místa menšího. Rozlišujeme kompresní metody bezztrátové (všechny .ZIPy . RARy apod. či např. videokodek HUFFYUV), které po encoding a následném decoding vydají naprosto stejná data jako na začátku, a kompresní metody ztrátové (např. JPEG, MP3 či většina videokodeku jako Indeo, Microsoft MPEG či jeho hack DivX), které se snaží z dat odstranit to, co lidské smysly nevnímají či to co lze odstranit tak, aby to bylo co nejméně poznat. Jinými slovy dojde během encoding k zahození části dát či jejich nahrazení komprimovatelnější sekvencí. Během decoding samozřejmě k žádné ztrátě dát nedochází.

Encoding = zakódování
Obecně proces uložení dát v nějakém formátu. Pro tuto stránku se tento pojem vztahuje k převodu videa (tj. posloupnosti RGB obrázků) do jeho zkomprimované podoby (většinou kodekem DivX). Podobně jako u mp3ojek rozlišujeme konstantí datové toky (Constant Bitrate Encoding - CBR) a proměnlivé datové toky (Variable Bitrate Encoding - VBR). Protože se snažíme data zakódovat tak, aby došlo co k nejmenší ztrátě kvality a zároveň co největšímu zmenšení, může tento proces trvat řádově až 10x déle než vlastní délka videa.

Decoding = dekodovani
Dekódování je proces rozbalení předtím zabalených dát. Protože už nic neoptimalizujeme, ale pouze nafukujeme data předem definovaným způsobem, není to proces tak CPU náročný (ale přeci jen to chce cca frekcenci 300MHz, aby bylo přehrávání videa v reálném čase ;-))

Keyframe = klíčový snímek
Snímek, který není definován pomoci předchozích snímku, ale plně sám o sobě (tj. k jeho dekódování nepotřebuji nic jiného)

Delta frame = delta snímek
Snímek, který je definován pomoci předchozích snímku (tj. k jeho dekódování potřebují nejbližší předcházející klíčový snímek a všechny delta snímky mezi)
Stručně lze vysvětlit vztah delta a klíčových snímků takto:
Kdybych měl například tato původní data:
200, 199, 201, 300, 305, 306, 400, 401
Tak po přepsání do delta/key zápisu mi vyjde:
200, -1, +2, +100, +5, +1, 400, +1
(kde klíčové snímky jsou samozřejmě 200 a 400 a delta snímky to ostatní začínající plusem či minusem)

Static Scene = statická scéna
Scéna (filmu, videa), která neobsahuje příliš mnoho "pohybu". Lépe řečeno - scéna pro jejíž zakódování pomocí delta snímků nepotřebuje kodek přiliš mnoho bitů. Například malý objekt pohybující se vůči nehybnému pozadí.

Dynamic Scene = dynamická scéna
Scéna (filmu, videa), která je pro kodek náročná. Obsahuje příliš mnoho "pohybu". Ovšem je nutno zdůraznit, že to nemusi být nutně scéna s "dvěma do sebe navzájem bušícími karatisty", ale klidně i záběr kouře, vlnění vody či chvění listů. (thx K5)

Bitrate = datový tok
Určuje kolik dát (za sekundu) daný encoding proces používá. Často se měři v kbps (kilobity za vteřinu)

• Kódujeme-li s konstantním datovým tokem (CBR = Constant BitRate), tak to znamená, že každou sekundu použijeme stejné množství dát, nezávisle na tom jestli je dána vteřina částí dynamické (akční) či statické scény (např. černá tma).
• Kódujeme-li s proměnlivým datovym tokem (VBR = Variable BitRate),tak to znamená, mže množství bitů použité každou sekundu se mění podle dynamičnosti dané scény. (Optimálně bude 'černá tma' zakódována minimálním počtem bitů a naopak dynamická scéna množstvím "dostatečným".) Samozřejmě, že lze hovořit o průměrném datovém toku.

VBR aneb proč to trvá 2x tak dlouho

Princip VBR (variable bitrate) videa spočívá v optimální alokaci více bitů scénám, které to potřebují (dynamické), a současném odebírání bitů s menší náročností na datový tok (statické scény). O to tu jde na prvném místě. Flasknout celé DVDčko s konstantním datovým tokem umí kdekdo, ale optimálně nakrmit dynamické scény a naopak přiškrtit scény statické umí jen Nandub. Protože Nandub není vševědoucí, musí nejprve film prozkoumat (tzv. First pass) a pak a na základě vytvořené statistiky provede vlastní zakódování (tzv. Second pass).

V rámci First passu určí Nandub tzv. "bitrate curve", tj. datovou náročnost každého snímku při maximální možné velikosti (tj. de facto daný vstup komprimuje jako DivX low motion 6000 kbps)(tj. DRF=2x, viz dále).(Nemusíte se bát o místo, Nandub tohle MaxiAVI defaultně nevytváří.) Čistě teoreticky by nyní již stačilo spočíst velikost tohoto největšího možného DivX souboru, dále pak vzít velikost cílovou (typicky 700MB minus zvuková stopa), tato dvě čísla podělit a získat tím jakýsi škálovací faktor pro celý film (a tímpádem i pro každý snímek). Stručně řečeno, kdyby byl svět dokonalý, tak by stačilo říci:

Bohužel jsou zde 2 základní problémy:

• Kodek se nechová lineárně
  To znamená že když nastavím poloviční bitrate, tak sice klesne velikost souboru na polovinu, ale většinou neklesne kvalita právě na polovinu. Podobně to platí i naopak. Navíc má DivX kodek určitá omezení (např. nechová se hezky při velmi malých datových tocích, neumí sám od sebe poznat kouř, mlhu apod.). Proto je v nandubu spousta možnosti, která se snaží tato omezení obcházet. (např. když klesne datový tok (bitrate) pod nějakou přijatelnou úroveň, tak ji zvýšit na únosnou mez) Z tohoto důvodů se může jevit jako poměrně komplexní a až zbytečně složitý nástroj. Pro ty kdo mají rádi věci jednoduché jsou právě k dispozici ony 1CD a 2CD profily, ale to opět nezbavuje jejich uživatele odpovědnosti rozumět tomu co používají. Pro toho kdo chce z DivX kodeku získat skutečně maximum, je možnost nastavit manuálně většinu hodnot přesně to, co hledá.
  
• Zpětná vazba a kvantování
  Divx kodek neumí uložit každý snímek s libovolně jemnou kompresí, ale umí jich přesně jen 2^5 - 1 tj. 31. (Též se jim říká DRF = Detail Removal Factor = "Faktor odstranění detailů" = což se dá nazvat kompresi). Nejnižší možná komprese (což odpovídá maximální možné kvalitě) je 2x. Naopak maximální možná komprese je 32x. Když klasický DivX kodek komprimuje pomoci zvoleného datového toku (bitrate), tak zkouší každý snímek zkomprimovat tak, aby výsledná velikost framu odpovídala žádanému datovému toku (tzn. velikost_snímku_po_kompresi * počet_snímků_za_vteřinu = bitrate). Samozřejmě že díky kvantování možností komprese (2x-32x ale jen těchto 31 hodnot, 2.5x neumí) se nedaří držet každý snímek přesně na úrovni žádaného bitrate. Proto DivX kodek používá jakousi zásobárnu = bitrate reservoir, do které ukládá informace o tom kolik bitů ušetřil tím, že kódoval 5x místo teoretického 4.7x a naopak kolik bitů si vypůjčil když kódoval 4x místo 4.7x.
  Zjednodušeně řečeno pak v průběhu kódování kodek určí (v závislosti na množství pohybu apod.) jakou kompresi by rád zvolil a vyjde mu např. že 5.5x. Podívá se tedy do zásobárny bitů (bitrate reservoir) a když zjistí že je bitů málo tak zakóduje jako 6x a naopak. (Navíc se ještě přihlíží ke kompresi předchozích framu apod.) Dá se říci, že i klasický DivX kodek dělá tak trošku VBR, ovšem jeho přizpůsobivost je jednou provždy natvrdo zakódována výrobcem.

• High Motion umí jen DRF 5x-32x zatímco Low Motion umí celé spektrum DRF 2x-32x. Proto když předložíte oběma kodekům (při stejném (a dostatečně velkém) datovém toku, samozřejmě) nějakou rozumně komprimovatelnou scénu, tak bude Low Motion vypadat lépe, protože může sáhnout k menší kompresi zatímco High Motion se maximálně sníží k 5x.
• High Motion je mnohem přizpůsobivější a může se proto rychle přizpůsobit na (dočasně) vysoký datový tok ( a proto budou krátkodobě dynamické scény vypadat lépe) zatímco Low Motion kodek si svou zásobárnu bitů hlídá mnohem pečlivěji a nedovolí, aby si z ní náročné scény půjčovaly příliš mnoho bitů.

Tím ale neříkám, že je Low Motion lepší... (nejlepší je Ferda). Jen chci říci pouze to, že kdo chce stále dělat filmy s CBR, tak optimálních výsledků dosáhne když pro většinu filmu použije Low Motion a na dynamické "akční" scény zase High Motion. To neříkám nic překvapivého, že... (vždyť i názvy kodeků tomu napovídají). Ovšem proč komplikovat věci stříháním, když Nandub umožňuje přímo nastavit jaká komprese (2x-32x) bude pro daný snímek použita, na rozdíl od Low a High Motion kodeků, které tento výpočet dělají samy. Dále umožňuje ovlivňovat přizpůsobivost kodeku mnoha způsoby (gauge, BR modulation, Crispness modulation apod.). Jinými slovy Nandub nejenže kombinuje výhody obou kodeku, on dělá mnohem víc....

Jelikož byl DviX původně navržen jako kodek pro low data-rate video, nelze se divit když při archivaci DVD (které mají relativně vysoký datový tok) nebudou komprese např. 16x a výše vůbec využity. Optimální by bylo kdyby byly všechny scény v daném filmu v rozsahu tak 2x až 5x, možná 2x až 8x pro "akční" scény, ale ne o mnoho více protože pak už dochází k přílišné ztrátě kvality.. a o tu jde v Nandubu na prvním místě.

Jak to probíhá I - "First pass" a "Second pass"

Jak již bylo řečeno, vlastní "encoding" je dvoufázový proces. Nejprve ("First pass") se daný VFAPI pseudoAVI soubor naoko zakóduje s co nejmenší kompresí. Při tomto procesu se typicky AVI soubor nevytáří, pouze se shromaždují statistické informace pro každý snímek (datový tok !!!, luminance a "pohyb"), které se uloží do .stats souboru.
V další fázi ("Second Pass") se informace o maximálním datovém toku (tj. toku odpovídajícímu minimální kompresi) přeškálují (klasická trojčlenka), mírně upraví podle typu scény (luminance, "pohyb") a předají DivX kodeku jako datový tok pro daný okamžik. V této fázi je sice taktéž možno shromaždovat informace do .stats souboru, ale hlavně již dochází k vytváření konečného AVI souboru.

Jak to probíhá II - z pohledu uživatele

Pozor tohle není Flask !!! tohle jsou techniky pro pokročilé "rippery". Záměrně následujícím přípravným postupům nevěnuji téměř žádnou pozornost, protože jsou dobře a kvalitně popsaný třeba právě na www.doom9.net.

Pro zaručené fungování Nandubu je zapotřebí mít starý, klasický (plain, vanilla, unmodified) DivX 3.11 alpha kodek

To znamená ne 3.22. (kodek OpenDIVX - většinou s jménem 4.0 alpha 48 apod. - mít nainstalován můžete. Kromě matoucího jména nemá s původním "hackem" MS kodeku nic společného.)

Příprava Videa

• Nejprve si opatřete DVDčko.
• Ripněte ho SmartRipperem
  tzn. potřebujete nejspíš VOBy vts_01_x.vob, kde x = 1-6
• Pomocí DVD2AVI vytvořte DVD2AVI projekt
  tzn. otevřete první VOB, DVD2AVI automaticky zvolí i ostatní VOBy, pomocí hranatých závorek označíte tu část videa, kterou chcete zpracovávat. (To se hodí pokud si chcete vyzkoušet vliv jednotlivých nastavení na nějaké kratší sekvenci)
  Poznámka k DVDčkům z Regionu 1, tzn. v NTSC formátu. Většinu těchto filmů je potřeba zbavit "telecine" (kdo zná, ví o čem mluvím). Když spustíte v DVD2AVI Preview (F5) a necháte pár minut běžet objeví s vedle "Video Type" např. FILM 98%. Pokud je číslo větší než 95%, nastavte Video - Field Operation - Forced FILM, v opačném případě je třeba provést inverzní telecine pomocí TMPG
• Pomocí VFAPI vytvořte z Vašeho DVD2AVI projektu jakési pseudoAVI (je to de facto pointer do DVD2AVI projektu zakamuflovaný do AVI hlavičky, takže je mono na něj pustit libovolný AVI editor)
  tzn. spusťte VFAPIConv-En, dále pak "Add Job" - Váš DVD2AVI projekt, a "Convert".

Vlastní "Encoding"

• Otevřete onen pseudoAVI ve Virtual.. pardon.. Nandubu.
• Upravte vstupní video k obrazu svému
  • Je třeba ořezat černé pruhy, a upravit (a zmenšit) rozlišení, aby bylo zachováno správné aspect ratio, tj. poměr stran.
  • Video - Filters - Add - resize: nastavíte cílové rozlišení a způsob resamplování
  • Doporučená cílová rozlišení jsou (podle doom9a)
    • filmy s poměrem stran 1:2.35 : 720x304, 640x272, 576x240, 512x224, 480x208, 400x176
    • filmy s poměrem stran 1:1.85 : 720x384, 640x352, 576x304, 512x272, 480x256,400x224
    • filmy s poměrem stran 1:1.33 : 720x544, 640x480, 576x432, 512x384, 480x368, 400x304
    Tato rozlišení jsou doporučena pro zachování maximální kompatibility, tj. šířka je dělitelná 32 a výška 16
  • Způsoby resamplování (Filter Mode)
    • Precise Bilinear - pokud se snažíte o 1 CD rip (je mírně komprimovatelnější)
    • Precise Bicubic - pokud chcete maximální kvalitu např. pro 2 CD rip
• Spočtete si cílový průměrný bitrate videa některým z mnoha dostupných kalkulátorů (cílový_bitrate = cílová_velikost - velikost_audio_stopy) / celkový_čas Je možno použít i vestavěný kalkulátor Video - SBC Options - Bitrate Calculator
• Nastavíte Video - SBC Options - SBC settings a též (!!!) Options - Preferences (viz níž)
• varianta #1: spustíte "First pass" (File - First Pass = F8). Nandub se Vás zeptá na jméno stats souboru (soubor který obsahuje informace o datovém toku, pohybu ("motion") a luminanci), uloží Vaši konfiguraci do dočasného vcf souboru a nahraje konfigurační soubor default.+st.pass.vcf (nachází se v adresáři do něhož jste rozbalili Nandub), který zajišťuje, že "First Pass" bude cvičně komprimovat Vaše videos minimální kompresí (DRF = 2x). (Nandub standartně při volbě "First Pass" AVI soubor nevytváří.) Tato operace trvá několik hodin. Pokročilejčí uživatelé si mohou zapnout dbgview.exe (nachází se v adresáři do něhož jste rozbalili Nandub) a sledovat zda Nandub skutečně komprimuje s DRF = 2x. Po skončení "First Passu" Nandub opět nahraje Vaši (dočasně neplatnou) konfiguraci.
  Poté je třeba nastavit kompresi (viz níž) a je možno spustit "Second pass" (klasicky pres File - Save as AVI = F7), který již vygeneruje konečný AVI soubor bez zvuku.
• varianta #2: Lze spustit oba passy najednou (File - Two Passes = Shift+F8) (jméno stats suboru se nastaví pod Video - SBC Options - SBC settings - Bitrate Curve ) a výsledkem je opět AVI soubor bez zvuku. (Kompresi je možno automaticky nastavit odkomentováním řádky
  //VirtualDub.video.CalcCurveCompression();
  v souboru default.+st.pass.vcf

Proč tyto 2 varianty:
Varianta #1 je starší (všem programátorům musí být jasné že pro účely ladění je lepší větší proces rozdělit na dva menší) a flexibilnější. Není pravidlem, že se povede "Second pass" hned napoprvé.
Další možností je nechat si vygenerovat AVI soubor už v "First Passu". (V tomto přápadě doporučuji zatrhnout Video - SBC Options - Generate AVI, zadat méno stats suboru pod Video - SBC Options - SBC settings - Bitrate Curve a zadat File - Save AVI = F7) Touto volbou se vygeneruje stats soubor i ono Maxi AVI (zakódované s maximálním možným datovým tokem (tzn. 6000 kbps či DRF=2x). Pro některé vysoce komprimovatelne filmy vyjde "First Passu" klidně kolem 1000MB a pokud mi jde o 2CD encode, tak jsem hotov a nepotřebují dělat 2nd pass. Varianta #2 je prostě jednodušší, protože umožňuje vše nastavit a pak spustit oba passy najednou (třeba přes noc).
Dle mého názoru je nejlepší spustit nejprve "Two passes" a poté případně znovu "Second pass" s vylepšeným nastavením.

Profily:
VirtualDub (a proto i jeho potomek Nandub) má vestavěnou možnost uložit nastavení všech možnosti do souboru (File - Save processing settings) s příponou .vsf a jejich nasledného načtení (File - Load processing settings).
Dřive byly ze snahy o zjednodušení a automatizaci celého procesu dvě nejčastější varianty (1 CD a 2CD) standartně přiloženy s Nandubem. Použití těchto profilů ovšem nedoporučuji, protože mnoho parametrů bylo pozměněno a nemusí proto odpovídat současné verzi Nandubu. Po přečtení následujících stránek by každý měl být schopen si svůj profil vygenerovat sám.
I když použijete profily, musíte nastavit datový tok !!!

Audio

• Při dělání videa je standartně audio nastaveno na "No Audio", protože audio se stejně dělá většinou někde jinde (LAME) a je zbytečné prodlužovat už i tak dlouhý čas "First & Second Passu" (které stejně vůbec nemusí být Vaše poslední, tak proč přidávat audio už teď)
• Audio lze dělat mnoha způsoby (např. pomocí Vob2Audio či Microsoft GraphEditoru) doporučuji opět stránky www.doom9.net
• Audio se přidává do hotového AVIcka stejně jako ve VirtualDubu (Otevřeš AVI, Video - Full stream copy, Audio - (XXX) Audio kde XXX je něco z následujícího..
• WAV - (nedoporučuji) - pak je ještě třeba nastavit Audio na Full Processing Mode a nastavit nějakou vhodnou kompresi (nejlépe MP3, ale to bude klasický CBR mp3. Vy ale chcete VBR mp3, který je přeci lepší, ovšm musí se dělat externě, viz níž). Nepoužívejte WMA ani DivX Audio, protože pak si svůj film na ne-Windows platformách nepřehrajete.
• AC3 - Pokud někdo chce mít AC3 zvuk tak samozřejmě jen pro 2CD ripy
• (VBR) MP3 - (doporučuji) - Pokud někdo dělá MP3 zvuk, tak pokud možno downmixováním Dolby Surround a použít LAME (když chcete kvalitu a malé místo tak LAME VBR 128 kbps je dostatečně kvalitní)
• OGG Vorbis - Nandub jej zatím nepodporuje, ale snad brzy bude - na vývoji se pracuje. Ogg je GPL free audio formát, jehož kvalita je (pro stejný datový tok) lepší nežli MP3 a navíc podporuje více zvukových stop

Next: Detailní vysvětlení různých nastavení Nandubu.
Index