Jak nejdéle jste encodovali film?

18.6.2006 22:00 | Přečteno: 1226× | Other | poslední úprava: 19.6.2006 16:46

Včera dávali Kontakt a protože jsem si říkal, že duo Robert Zemeckis (Cast Away, Forrest Gump, Back to the Future I/II/III, ad...) a Carl Sagan by mohlo stát za to (ano, film jsem doteď neviděl), rozhodl jsem se ho zgrabnout. K tomu samořejmě přispěli jak hvězdy velkého formátu jako skvělý Tom Skerritt, vždy výborně záporňácký James Woods ale i další jako hlavní hrdinka v podání Jodie Foster, můj oblíbenec David Morse a netradičně holohlavý John Hurt. Kvalita grabu "jako obvykle", tedy realtime Xvid (kvůli místu, tentokrát Target Quantizer 2, cca 14000kbps ve výsledku), 768x576/25fps, zvuk 16bit/48kHz.

Sice mi prima celkem šumí, ...

... ale i tak jsem se rozhodl, že při encodingu ve VdubModu si začnu opět hrát s experimenty ...

A tak jsem nahodil skvělý ne-moc-starý build X.264 b532 a začal experimentovat.

Již dříve jsem si na tomto buildu ověřil, že ztráty kvality při bitrate 700kbps jsou oproti 1300kbps jen minimální v akčních scénách, statické vypadají stejně. Podotýkám ,že se bavíme o FullPAL, tohle by s XviDem nebylo možné. Tentokrát jsem však chtěl zachovat i určitou míru detailů v akčních scénách, které v tomto filmu rozhodně nehcybí (keyframy padaly při grabu v některtých pasážích jeden za druhým).

Pro začátek jako odrazový můstek pro laborování na budoucích grabech jsem ponechal většinu nastavení standardních. Změnil jsem jen následující:

• Rate Control - Min QP = 15
• Motion Estimation - Partition Decision = 6b (RDO on B-frames)
• Method = Exhaustive Search

Samozřejmě jsem si plně vědom, že takto BRUTÁLNÍ nastavení kodeku nepřinese odpovídající nárůst výkonu (v přímé úměře), ale naopak nepřiměřeně delší dobu encodingu, zejména při post-1st passech. Z dob encodingu 640x480 filmů na Duronu 1200@1333 jsem byl zvyklý dělat filmy celkem dlouho (zejména v dobách, kdy jsem experimentoval se třemi rpůchody v >=DivX 5.05), ale tentokrát jsem si říkal, že když sedím u P4 3,6@3,4GHz (podtaktováno kvůli letním horkům, abych mohl chladič držet na nízkých otáčkách, přeci jen TDP 115W není legrace při pokojové teplotě 35°C uchladit ), ale překvapení se i tak konalo.

Vše naznačoval již první průchod, který trval takřka 13 hodin (a to jsem na PC jen tu a tam surfil, v noci jsem samořejmě spal ;). Ale chvíli po startu druhého průchodu na mě vyběhl tento odhad doby, který se posléze stabilizoval na následující hodnotě:

Doba dělání jednoho průchodu déle než 1 den, to je opravdu snad jen pro pochlapené ženy nebo zženštilé muže (mají spoustu času na dělání "mejkapu" ). Až doběhne 2nd pass, tak mě samořejmě čeká ještě 3rd pass, na kterém si chci ověřit, zda má obdobný "vyhlazovací" význam, jako kdysi 3rd pass u DivX 5.11, nebo jej nemá smysl dělat. Takže, dokončení ecodingu video stopy mě čeká zhruba v úterý ve 4 odpoledne, tedy cca po ca 65 hodinách nepřetržité práce.

To samozřejmě vyústilo v pár zajímavých věcí, jako například, že já "vrcholný pecivál" jsem se s třemi dalšími lidmi vypravil do lesa na houby. Byl to příjemně strávený den, s nepříjemností na závěr, ale o tom zase příště ...

Na závěr tohoto blogu ještě malá omluva za použitý OS, ale prostě Vdub/VdubMod je jen jeden. Navíc kombinace SAA7135 a Fly2000 mi také VELMI vyhovuje.

UPDATE 19.6.06 16,44: takže právě doběhl 2nd pass a vypadá tak skvěle, že 3rd pas ani nebudu dělat

Nicméně, obligátní anketa nesmí chybět:

       

Anketa

Komentáře

[Marek Stopka]

Více než dva dny nějaké dlouhé domácí (secret ) video do oggu (video=theora + audio=vorbis), ale na to jsem si vzpoměl až po odhlasování, takže jsem hlasoval pro 1-2 dny.

[#Tom]

A jak to jde v Linuxu?

[Kníže Ignor]

v linuxu to trvá čtyři dny - jeden den na to, abys zjistil, že to v linuxu nejde, druhý den instaluješ windows a zbylé dva dny se to komprimuje

[#Tom]

Mně to pod windows šlo vždycky blbě a pod linuxem taky.

[Kozzi]

no co se tyce windows tak dokud jsem mel jako jsi staresi ati tv-pci-ve tak jsem s ni byl spokojenej aslo vse jam melo a na kovertaci jsem pouzival vdub. V linuxu jsem sni take nemel zadne problemy a ke konvertaci jsem pouzival transcode a mencoder dnes bych pouzival avidemux2. Ale pote co jsem si poridil asusku s cipem 7135 tak ve windows jsem nemel sanci jelikoz dodavanej soft stoji za p..... a s tv2000fly to slo jen tak jak se tomu chtelo ale jednou jsem to dokopal do stavu ze jsem moh i nahravat . No v linuxu jsem stouto kartou nemel prakticky zadnej problem az na to ze pokazde kdyz jsem ji naladil kanali (kdetv,tvtime,...) tak jsem musel dat jemne doladeni jinak to bylo bez zvuku nevim proc ale delatu kus od kusu.

[Luk]

Pod Linuxem to jde blbě a pod Windows ještě hůř - a hlavně se pak prakticky nedá dělat nic jiného, protože to pořád hrabe na disk (to v Linuxu nehrozí ).

[#Tom]

Výhoda Linuxu je v tom, že můžu kódováním zaměstnat počítač třeba na dálku.

[Luk]

Ale na druhou stranu mám zatím dost špatné zkušenosti s kódováním na 64-bitovém Linuxu (64-bitově zkompilované libdv a ffmpeg často padají).

[#Tom]

Snad to bude fungovat, až si jednou pořídím novej počítač... A pořád jsem línej a pořád to odkládám...

[David Ježek]

neda delat nic jineho? to jako kdy? ja behem encodovani muzu delat cokoliv, klidne treba grabovat dalsi film a do toho jeste soucasne normalne surfovat. delal jsem to treba prave ted (33 1/3). ale mozna to bude tim, ze video hazim na samostatny disk a system mam na 10k rpm raptoru

[Luk]

Zcela samostatný disk na video používám také, ale problém není v tomto. Systém prostě pořád swapuje (při 512 MB paměti), a nevím proč. Paměti má dostatek. A je vcelku jedno, v jaké aplikaci a s jakým kodekem se to zpracovává. Možná mám něco špatně v nastavení Windows, ale těžko říct (totéž jsem zažíval na různých počítačích). V Linuxu se tento problém nevyskytuje.

[David Ježek]

zajimave ... me to vubec neswapuje, i kdyz mam z 512MB RAM vyuzito cca 720MB. proste jakmile se vse potrebne natahne, neni potreba cokoliv swapovat. nebezi ti na pozadi "neco nepekneho" ??

[Luk]

nebezi ti na pozadi "neco nepekneho" ??

Těžko. Než spustím kódování, všechno pobiju. Navíc, jak už jsem říkal, jsem to zažil na více různých počítačích. Takže opravdu nevím

[Mikos]

To je přeci známá věc, že Windows mají mnohem horší správu paměti než Linux. Pokud se u nich swap zcela nevypne (nebo možná snad lze použít i nějaké záhadné nedokumentované nastavení v registrech, ale moc bych na to nesázel), tak prostě swapujou a swapujou, i když mají volné paměti dostatek... zkušeností s tím mam véc než dost a nejsem rozhodně sám

Prostě správa paměti ve Windows stojí za h*vno...

[Luk]

To sice ano. I Linux swapuje při dostatku paměti, podle toho, jak je nastaven. Nicméně i při defaultu (tzn. swapiness=60) se chová velice slušně.

[xxxxxxxx]

zkoušel jsem štelovat tuto hodnotu od 0 do 100 a nevsiml jsem si absolutne zadneho rozdilu. jen sem kvuli tomu mnhokrat rebootoval.

[Elvis]

ja bych rek ze mu tam bezeji nepekny windows, ja kdyz jsem kdysi kodoval film ve windows a potom ten samy v linuxu tak v linuxu to bylo podstatne rychlejsi

[David Ježek]

no to bych tedy rad vedel, jaky kodek si pouzil ve windwos a jaky v linuxu. vono je to docela klicova vec a takto obecne cosi prohlasit neni fer ;)

[Luk]

Pozor - co se týká času procesoru, tak tentýž kodek ve Windows, pokud se zkompiluje pomocí VC, je o cca 7 % rychlejší (v porovnání s tímtéž kodekem kompilovaným pomocí GCC 3.4 v Linuxu i ve Windows - při maximální úrovni optimalizace)! Jednotlivé kodeky se moc neliší (např. ffmpeg, dv, xvid). Je to téměř jistě způsobeno lepší kvalitou kompilátoru VC oproti GCC (generuje úspornější kód).

Ale připomínám, že uvedené platí pro GCC 3.4, výsledky pro GCC 4 neznám. Asi to bude o něco lepší. Navíc reálný čas je pod Linuxem lepší, ve Windows je problém s tím swapováním.

[David Ježek]

no ono to x264 co pouzivam je kompilovano pomoci gcc 3.4.5, ale to jen tak na okraj. jinak znovu rikam, ja neijaky zvlastni prob se swapovanim nemam.

[ALIUM]

Vidim, ze pomalu zacinas zastavat funkci JXP, ktery tu dikybohu neni...

[Mikos]

Co se s tebou Ignore stalo? V poslední době mi přijde, že se chováš čím dál víc jak blb... a taky že se z tebe stal pomalu druhý JXP, už jen schází abys začal psát blogposty o Total Commanderu a dílo bude dokonáno

Jinak co se týče grabování pod Linuxem (i do kodeku h.264), tak pod Avidemuxem to není absolutně žádný problém, jde to stejně jednoduše jako pod Windows (a některé věci i jednodušeji).

[Kyosuke]

Teoreticky by mohl jít VirtualDub zkompilovat s Winelib.

http://www.winehq.com/site/winelib#virtualdub

[Mikos]

Nechápu proč by to někdo dělal, když je tu mnohem lepší Avidemux

[Kyosuke]

No "prostě Vdub/VdubMod je jen jeden..."

[Mikos]

Jeden není, jsou dva

Každopádně nějak nechápu proč chce dotyčný používat horší software (Vdub/VdubMod), když je tu mnohem lepší alternativa (Avidemux) fungující přímo nativně pod Linuxem.

Kdyby se jednalo o nějaký složitý software tak neřeknu (chápu, že by mu mohlo vadit se přeučovat na něco jiného), ale Avidemux a Vdub/VdubMod jsou velmi jednoduché programy a jsou si ovládáním docela podobné...

[David Ježek]

mno , virtualdubu je historicky vice odnozi, namatkou jeste take nandub, virtualdub mp3, virtualdub ac3 a buhvi na jake sem zapomel. nicmene, tvoji vyzvu prijimam, prave instaluji posledni stable avidemux pro wokenice a provedu male srovnani.

[#Tom]

No proč ne, pokud Winelib podporuje Video for Windows, tak by to snad možná k něčemu bylo, ale moc tomu nevěřím.

[vencour]

Ve woknech jsem použil avidemux, v linuxu ho mam taky a ještě jsem ho nepoužil.

[wlofy]

bylo to 24h chtel sem videt dve veze a nejak mi to pocitac nechel v xvidu stihat

[#Tom]

Já jsem musel pro změnu jednou překódovat DVD do DivX (4.12), abych si ho mohl vůbec pustit, protože jsem nenašel přehrávač DVD, který by byl zadarmo a byl schopen přehrávat i na 400 MHz Pentiu II. Net jsem neměl a Mplayer jsem ještě asi neznal.

[Mikos]

Vdub/VdubMod je jen jeden

He? Avidemux je podle mě nesrovnatelně lepší než VirtualDub či VirtualDubMod. Znam dokonce i dost lidí (windowsáků), kteří ho začli místo VirtualDub(Mod)u používat i na Windows. Prostě Avidemux je špička

[zde]

3-pass ??? Proboha proč natřikrát? 2-pass jsem přestal používat v okamžiku, kdy jsem přestal cpát komprimované video na média se směšnými kapacitami jako např. 700MiB, takže teď vesele všechno honím singlepass s pevnou kvalitou, a je mi vcelku jedno jestli průměrný bitrate bude o pár procent víc nebo míň, a jestli na jedno DVD-R přijde filmů 10 nebo 15.

[David Ježek]

3-pass ??? Proboha proč natřikrát?
protoze: Až doběhne 2nd pass, tak mě samořejmě čeká ještě 3rd pass, na kterém si chci ověřit, zda má obdobný "vyhlazovací" význam, jako kdysi 3rd pass u DivX 5.11, nebo jej nemá smysl dělat. ... zkus lepe cist ;)

---

2-pass jsem přestal používat v okamžiku, kdy jsem přestal cpát komprimované video na média se směšnými kapacitami jako např. 700MiB, takže teď vesele všechno honím singlepass s pevnou kvalitou, a je mi vcelku jedno jestli průměrný bitrate bude o pár procent víc nebo míň, a jestli na jedno DVD-R přijde filmů 10 nebo 15.
wtf?! ty jako tlacis 10-15 filmu 1pass na DVD. takze mas filmy o velikosti 450 nebo take jen 300MB ?!. tak to se pred tebou sklanim, ó božský encodovači.
btw, jakej ty pouzivas kodek/rozliseni/zvukovy kodek atp, ze jsem tak smely?

[#Tom]

Třeba bere dvouvrstvá dvdčka.

[David Watzke]

Píše DVD-R.

[zde]

Sorry, napsal jsem 'filmy', ale měl jsem samozřejmě na mysli 'pořady' grabované z TV (o tom byl příspěvek, ne?). Stopáž je kratší než u filmů, a kvalita analogového vstupu (po deinterlacu a odšumění) je taková, že 600-800kbit je stejně luxus ažaž. DVDčka dávám XviDem na singlepass, vše na default, kvantizer 4, a obvykle to vyjde kolem 800MiB, takže 10-15 bych jich tam samozřejmě nenacpal.

Nemusíme se hádat, prostě jen říkám že 2-pass měl smysl pro přesný rate control, ale ten dnes už není téměř potřeba..

[kaaja]

Pokud jsou porady grabovane z digitalni tv, tak je 600-800kbit zatracene malo. Chce to nejmin 2x tolik, aby to stalo za to.

[Mikos]

On tam jasně mluví o analogovém vstupu.

[David Ježek]

ale vzdyt potrebny bitrate a to zda je zdroj analog ci digital vysilani proncipielne vubec nesouvisi! dulezita je kvalita zdrojoveho signalu a co jsem videl u nekterych lidi bydlicich "par metru" od TV vysilace, tak na to se zadnej digital a ani moje kvalita prijmu nechyta.

[Mikos]

A kolik lidí bydlí pár metrů od vysílače? Moc jich neznám

Ale jistě to má i jiné výhody... třeba jim tam lítaj pečený holuby rovnou do pusy

Btw. tak trochu OT mě napadlo, zdy by nešlo namodulovat signál wifi na 1 kW magnetron z mikrovlnky

[Luk]

tak trochu OT mě napadlo, zdy by nešlo namodulovat signál wifi na 1 kW magnetron z mikrovlnky

Když se ti to povede, je to na Nobelovku

[zde]

Nevím přesně jak funguje magnetron, ale obávám se že z toho z principu může lézt jen harmonický signál. Wifi je přímá syntéza, takže žádná modulace se bohužel nekoná.

[Mikos]

Jak funguje magnetron vím Ale jakým princip vysílání používá WiFi nemám zdání

Každopádně pravděpodobně budete mít pravdu, byl to prostě jen takový vtip

[Luk]

Ale jakým princip vysílání používá WiFi nemám zdání

STFW WiFi používá DSSS (direct-sequence spread spectrum), a rozkládá tedy vysílaný signál do poměrně širokého pásma.

[vencour]

Jj, neni nad kvalitní analog. Je to přece mpeg-2?

[kaaja]

Ja jsem kodoval asi nejdele pul dne, puvodne to sice taky vypadalo na jeden den, ale pak jsem se rozhodl, ze xvid nechci a pouzil mpeg4 z lavc. trvalo to tak pomalu, protoze jsem jeste navic tam pridal hqdn3d, ale vysledek byl proti originalu podstatne lepsi.

[brk]

Nemůžu si pomoct, ale má to cenu si s tím tak hrát a počítat to na Xkrát, když ten vstupní signál není nic moc? Kdyby to byl nějaký opravdu kvalitní analog, tak prosím, ale tohle už je zarušené a nějaké filtry nejsou samospasitelné.

[David Ježek]

no tenhle film se proste shodou okolnosti nachomejt do doby, kdy sem si hral s x264. jinak zadne filtry sem nepouzil. ty klidne mohu nasadit behem prehravani, ale rad mam zdrojove video co nejvernejsi originalu (v tomto pripade zasumene prime :-s)

[brk]

Ono je problém, že když je to vstupní video takhle zarušené, tak dost vzrůstá požadavek na datový tok, aby bylo dosaženo dobré kvality na výstupu. Nevím, do jaké míry je proti tomu odolný x264, ale určitě se to také projeví a možná by na hraní byl lepší i čistší vstup.

[David Ježek]

no odolny je samozrejme stejnym zpusobem jako jine kodeky: vyhlazuje velke plochy. jeho vyhoda ale je, ze obecne je jeho bitrate daleko nizsi nez mpeg4, takze pri bitrate co jsem pouzil to nemelo nijak fatalni dopad. xvid by vypadal aleko hnusnejs pri 150% bitratu.