32bit vs 64bit: video encoding a decoding [2]

10.11.2007 10:50 | Přečteno: 1705× | Linux | poslední úprava: 10.11.2007 10:51

Toto je pokračování seriálu o srovnání výkonu 64bit a 32bit aplikací aplikací na platformě x86_64. Předchozí díl se věnoval přehrávání videa v nejruznějších formátech. Pokud jste jej nečetli tak doporučuji alespoň zběžně projiít úvodní odstavce s popisem metodiky. Tento díl se bude věnovat kompresi.

Oproti přehrávání máme v tomto případě jednu výhodu- sami si můžeme zvolit formát výstupního souboru dle vlastních preferencí. Můžeme se tedy vyhnout formátům, které mají mizernou 64bit implementaci. A to aniž bychom slevili z kvality či jiných vlastností. Proč např. použít WMV9 když je k dispozici h264? I pokud jsme limitováni cílovým zařízením tak si většinou dokážeme zvolit z několika variant.

Kromě výsledků 64bit a 32bit optimalizované verze příkládám ještě rychlost binárního balíčku mplayer-bin. Jak se tento balíček liší od optimalizované verze jsem popsal zde.

Zdrojová data

Jak získat snadno, levně a legálně vstupní data ve formátu, který je převáděn nejčastěji a navíc tak, aby k němu měli přístup i ostatní? Stačí zajít do supermarketu a vybrat nějaké DVD za 35Kč, kterých se v poslední době vyrojilo neuvěřitelné množství. Domu jsem si přinesl tituly "Šakal", "Twin peaks" a "Basic Instinct". Pro své experimenty jsem nakonec zvolil první zmíněný film. Hlavním důvodem je asi to, že jsem nedávno ve Smrtonosné pasti 4 viděl Willise holými rukami přeprat stíhačku, takže jsem to potřeboval vyvážit nějakým zážitkem, kdy dostane nakopáno zase on. Data z DVD vydolujeme osvědčeným způsobem mplayer dvd://2 -dumpstream -dumpfile sakal.dump -v > dumpinfo. Měření je prováděno z časových důvodů vždy pouze na první čtvrtině filmu (30 minut) a následně je vynásobena čtyřmi aby hodnota lépe odpovídala době převodu celého filmu.

Šetříme s Microsoftem

Že se s Microdoftem šetřit nedá? Omyl, jde to. Např. takto:

time (mencoder sakal.dump -o sakal.avi -oac mp3lame -lameopts vbr=2:q=9:aq=0 -ovc lavc -lavcopts vcodec=msmpeg4v2:vbitrate=800:vpass=1 && mencoder sakal.dump -o sakal.avi -oac mp3lame -lameopts vbr=2:q=9:aq=0 -ovc lavc -lavcopts vcodec=msmpeg4v2:vbitrate=800:vpass=2)

64bit opt- 79:20
32bit opt- 87:10
32bit bin- 171:00

Tento kodek nepodporuje více threadové zpracování.

Šetříme bez Microsoftu zato s qns

time (mencoder sakal.dump -o sakal.avi -oac mp3lame -lameopts vbr=2:q=9:aq=0 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=800:vpass=1:threads=4 && mencoder sakal.dump -o sakal.avi -oac mp3lame -lameopts vbr=2:q=9:aq=0 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=800:qns=2:vpass=2:threads=4)

Co dělá volba qns je mimo záběr tohoto článku. Najděte si to v manuálových stránkách nebo se spokojte s konstatováním, že je to výpočetně velmi náročná volba.

64bit opt- 86:40
32bit opt- 95:30
32bit bin - 180:30

Tento kodek sice volbu threads=4 neodmítne ale zatížení je kolem 29% v prvním průchodu a 33 v druhém takže z toho neni prakticky žádný užitek. Pro šťouraly- ano, "threads" v USE mám.

Střední cesta

Aneb jak dosáhnout koukatelné kvality

time (mencoder sakal.dump -o sakal.avi -oac mp3lame -lameopts vbr=2:q=5:aq=0 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1300:vpass=1:threads=4 && mencoder sakal.dump -o sakal.avi -oac mp3lame -lameopts vbr=2:q=5:aq=0 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=1300:vpass=2:threads=4)

64bit opt- 66:50
32bit opt- 74:00
32bit bin- 210:10

Střední cesta s H.264

S x264 jsem měl problém, že průměrné zatížení CPU je v 64bit verzi 78% a v 32bit 40%. Proto měřím s threads=1 i threads=4.

time (mencoder sakal.dump -o sakal.avi -oac mp3lame -lameopts vbr=2:q=9:aq=0 -ovc x264 -x264encopts bitrate=1300:threads=4:turbo=2:pass=1 && mencoder sakal.dump -o sakal.avi -oac mp3lame -lameopts vbr=2:q=9:aq=0 -ovc x264 -x264encopts bitrate=1300:threads=4:pass=2)

64bit opt 1 thread- 205:30
32bit opt 1 thread- 250:50

64bit opt 4 threads- 81:40
32bit opt 4 threads- 170:10

32bit bin- nepodporuje

Vysoká kvalita s H.264 a faad AAC

time (mencoder sakal.dump -o sakal.avi -oac faac -faacopts br=160 -ovc x264 -x264encopts bitrate=1800:threads=4:turbo=2:pass=1 && mencoder sakal.dump -o sakal.avi -oac faac -faacopts br=160 -ovc x264 -x264encopts bitrate=1800:threads=4:pass=2)

64bit opt 1 thread- 188:20
32bit opt 1 thread- 233:40

64bit opt 4 threads- 63:50
32bit opt 4 threads- 140:40

mpeg2, rychlé jednoprůchodové snížení bitrate

time mencoder sakal.dump -of mpeg -mpegopts format=mpeg2:tsaf:muxrate=2000 -o sakal.mpg -oac copy -ovc lavc -lavcopts vcodec=mpeg2video:vbitrate=2000:aspect=4/3:threads=4

64bit opt 4 threads- 11:50
32bit opt 4 threads- 12:50
32bit bin 4 threads- 13:20

V souvislosti s tímtio článkem mám dotaz do publika. Můžu si dovolit při prvním průchodu snížit kvalitu (algoritmickou) lame encoderu? Tzn. můžu při prvním průchodu použít aq=9?

Příští díl se bude věnovat převodům audio formátů- mp3 pomocí lame, flac a ogg/vorbis.

       

Komentáře

[mimi.vx]

co treba to demuxnout a zpracovat auio a video zvlast .... a potom to jen spojit .....

[Ketling]

Odpoveď z publika: Enkódovanie audia v prvom prechode je podla mňa zbytočnosť. Už som síce dosť dávno negraboval DVD dvojprechodovo, ale mám taký pocit, že som používal -oac copy alebo null

Inak fakt pekný test. Teším sa na ďalšie diely.

[Bluebear]

Dokumentace k MPlayeru uvádí, že je většinou zbytečné audio enkódovat, doporučuje ho nechat v PCM. Sám s tím souhlasím také. Na velikosti výsledného souboru se to moc nepodepíše a jen se zbytečně vystavujete riziku zhoršení kvality.

[miho]

5.1 AAC ma DVD bezne datovy tok 448kbit. A kdyz tam clovek chce zakomponovat vice zvukovych stop...

[Vláďa]

Měl jsi asi na mysli 5.1 AC3 ne? Běžnější bitrate je podle mě 384kbps.

Jinak dvoukanálový stereo PCM zvuk má 1350kbps. Takže 2 hodiny zvuku by zabraly 1200MB. U 2CD ripu s PCM zvukem mi pro obraz zbývá hezkých 200MB. Opravdu si myslíte, že použít PCM zvuk je dobrý nápad pro ripování DVD?

Jinak M$MPEG4v2 je v podstatě to samé co MPEG-4 SP. Dokonce jsem viděl program pro bezztrátový převod mezi M$MPEG4 (neboli DivX 3.xx) a MPEG-4 SP.

Komprese zvuku v prvním průchodu je nesmyslná. Zvuk bych zpracocával až v 2. průchodu. Moc ale nerozumím těm parametrům pro lame. -V2 je jasný, VBR bitrate okolo 200kbps. Pro zvukovou stopu k filmu možná zbytečně vysoký, ale na tom teď nezáleží. Co jsou ale parametry q a aq? U lame se běžně žádné další parametry nepoužívají. V dokumentaci k Mencoderu jsem nic takového nenašel...

[miho]

Opravdu nesmyslna? Kdyz pouzivam VBR tak nevim dopredu jaky bude vysledny datovy tok. Kdyz si predepisu celkovy tok 1800kbps tak jak se pozna, kolik ma zustat na video kdyz ho nezkomprimuju?

-vbr=2 zmanena metodu variabilni komprese, -q urcuje datovy tok a -aq znaci algoritmickou kvalitu.

[GeBu]

A platí to i pro moderní video kodeky? Protože stereo PCM má 1,4 Mbit/s a jestli obraz má třeba v H.264 900 kbit/s, tak to je dost rozdíl.

[xvasek]

To H264 musí být nějaká chyba - takový rozdíl mezi těma architekturama nemůže být. Mně třeba 32bit mplayer v 64bit systému odmítá používat sse, což by teoreticky mohlo +- odpovídat.

[miho]

32bit mplayer i mencoder ani netusi, ze bezi v 64 bit systemu :) Vsechno je prelozeno pro spravnou architekturu se spravnymi CFLAGy.

# uname -m i686 #mplayer MPlayer SVN-r24130 (C) 2000-2007 MPlayer Team CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (Family: 6, Model: 15, Stepping: 7) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 Přeloženo pro CPU x86 s rozšířeními: MMX MMX2 SSE SSE2 ... Proc by tam nemohl byt takovy rozdil? Muzu vam prozradit, ze v casti o kryptografii uvidite na 64bit platforme i 3x lepsi vysledky nez 32bit...

[xvasek]

Dal by se ještě pro zajímavost vytáhnout stejný výstup i pro ten druhý mplayer? Resp. který je tady tento?

Mě se totiž opravdu nepovedlo ty SSE rozjet - configure a překlad v pohodě jako že jo (32bit i SSE) a pak při spuštění SSE: 0 SSE2: 0 a výkon nikde.

V šifrování bych těm vysokým výsledkům věřil, ale multimedia bych čekal rozdíl mezi 10 a 30 procenty.

[miho]

Vzdyt tam je rozdil jen 22% v prvnim testu a 24% v druhem. Musite se koukat na vysledky jednothreadoveho zpracovani. Ctyrthreadove nedokazalo vytizit v 32bit verz vsechna jadra z neznamych pricin. V textu je to zmineno.

Nevim, kde muze byt problem s tim sse, u me i binarni balicek mplayer-bin hlasi

MPlayer 1.0rc1-4.1.1 (C) 2000-2006 MPlayer Team CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (Family: 6, Model: 15, Stepping: 7) CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1 a to je spousteny mimo chroot samozrejme.

[xvasek]

V textu je to zmineno.

Aha, teď jsem pochopil, co je myšleno pod "vytížení CPU" - já jsem to původně chápal jako vytížení jednoho jádra, ne průměrné vytížení všech jader. Tím pádem to sedí, díky za nakopnutí.