Kódování videa a zvuku, výpočet Pí
Kapitoly článků
DivX 6.1
Na kódování videa jsme se mrkli z několika pohledů. DivX 6.1 má totiž dvoujádrové procesory docela rád a rozumí jim. To bylo ostatně vidět v nastavení kodeku ve VirtualDubu, kodek měl vedle sebe i údaj o tom, kolik vlastně procesorů vidí a tedy kolik jich na kódování využije.
|
Vytížení procesoru při kódování do DivX 6.1 pomocí VirtualDubMod
Použit byl VirtualDubMod 1.5.10.1, který z videa dlouhého 5 minut a 10 sekund ve formátu MPEG-2 a rozlišení 704 × 576 při 25 snímcích za sekundu dělal DivX v témže formátu, kódoval však jen video, zvuk byl ve výsledku v nekomprimovaném PCM formátu. Byl použit jednoprůchodový režim nastavený na 780 kbit/s, volba poměru rychlosti a kvality na výchozí „Balanced“, zkrátka všechno ve výchozím nastavení.
Vytížení procesoru při kódování do DivX 6.1 pomocí DivX Converteru
Vedle tohoto způsobu kódování byl použit i DivX Converter, což je malý a velmi jednoduchý nástroj na tvorbu videa v DivX formátu, součást balíku DivX 6.1. Ten kóduje za použití jen jednoho jádra, druhé se vyloženě fláká (což je vhodné na to, že jedním jádrem si děláte film, zatímco druhé může systém využít na jinou činnost). Vytváří při nastavení profilu na „HIGH DEF“ video v rozlišení 688 × 528, zvuk kóduje do MP3 o konstantní rychlosti 128 kbit/s.
VirtualDubMod vs. DivX Converter
Chcete-li kódovat filmy do formátu MPEG-4, pak je DivX 6.1 a vícejádrový procesor rozumná volba. Samozřejmě platí, že čím rychlejší procesor, tím kratší čas, ale těmi 200 MHz už toho moc nenaženete. DivX Converter pak jasně ukazuje, že jemu na počtu jader moc nezáleží. Určitě se to však může hodit, pokud budete chtít při kódování filmu dělat i něco jiného, třeba jiný film přehrávat. S jednojádrovým procesorem už toho vedle kódování filmu moc nenaděláte (myslím náročného na procesor).
ATI AVIVO Video Converter
Protože ATI AVIVO Video Converter lze rozchodit v podstatě na jakémkoli PC nezávisle na tom, jakou obsahuje grafickou kartu (fakt, že jsme v PC měli zrovna ATI byla spíše shoda okolností), zkusili jsme i tento program. Zvolili jsme v něm kódování do DivX (MPEG-4) s nejnižším možným nastavením, a to 1 560 kbit/s. Zvuk byl ze zpracování zcela vynechán (výsledné video jej neobsahovalo).
I AVIVO Video Converter umí těžit ze dvoujádrového procesoru. Fascinující pak je, jakou rychlostí kódování provádí, přičemž nevyužívá procesor až tak moc, jako VirtualDubMod. Více než pětiminutové video dokáže se dvoujádrovým Athlonem 64 FX na 2,8 GHz přechroupat za 35 sekund. Kvalitu výsledného videa nyní ponechme stranou, o tom tento článek není.
Vytížení procesoru při kódování do MPEG-4 (DivX) pomocí ATI AVIVO Video Converteru
Lame 3.97 Multi-threaded encoder
Kódování do MP3 jsme prováděli speciální verzí programu Lame (3.97 alpha 2), která obsahuje „multi-threaded encoder“, umí tedy využívat víceprocesorovou konfiguraci (a tedy i vícejádrové procesory). Funkce multi-threaded encoder lze jak natvrdo vypnout, tak natvrdo zapnout, což bylo využito u jednojádrového FX-57, aby měly oba procesory stejné podmínky. Kódován byl 37 minut a 8 sekund dlouhý úsek záznamu živého koncertu v CD kvalitě (44,1 kHz, 16 bitů, stereo) do formátu MP3 o konstantní rychlosti 128 kbitů/s a to několika způsoby: jednak se zapnutým či vypnutým multi-threaded encoderem a pak dvěma verzemi, jedna byla přeložena kompilátorem od Microsoftu a druhá od Intelu, kde se dají očekávat nějaké ty optimalizace kódu pro procesory Intel a jejich HyperThreading.
Výsledky korespondují s očekáváním. Že bude verze přeložená Intel kompilátorem o něco rychlejší se dalo čekat, že zapnutý multi-threaded encoder udělá na dvoujádrovém procesoru také a stejně tak se dalo čekat, že bez multi-threaded encoderu nebude mít dvoujádrový procesor význam, v takovém případě je tradičně lepší rychlejší jednojádrový. Faktem však je, že aplikace k využívání vícejádrových procesorů směřují. A o tom Athlon 64 FX-60 je.
SuperPI
Program SuperPI je určen k jedné jediné činnosti: vypočítat Ludolfovo číslo na co největší počet desetinných míst. 10 milionů desetinných míst Pí bylo počítáno Chudnovskyho metodou (nejrychlejší, kterou program obsahuje) bez použití pevného disku (pouze RAM) při nastavení FFT 1 024 kB (nejrychlejší).
SuperPI 10M
SuperPI je další typ programu, který má raději jeden rychlejší procesor než více pomalejších. Proto jsme test trochu zkomplikovali a zkusili, jak rychle se bude Pí počítat na pozadí, pokud v popředí poběží kódování zvuku do MP3. Použit byl opět Lame 3.97 alpha 2 přeložený Intel kompilátorem a to v obou variantách, jak s multi-threaded encoderem, tak i bez něj. Výsledná hodnota ukazuje opět čas výpočtu Pí.
SuperPI 10M na pozadí při kódování MP3 v Lame na popředí
Toto jsou výsledky takřka praktického testu. Zapnutý multi-threaded encoder si ze dvoujádrového procesoru vzal více, proto na SuperPI zbylo méně a test trval déle. Naopak u jednojádrového procesoru se multi-threaded encoder snažil tak zbytečně, že kódování do MP3 bylo velmi pomalé, zatímco SuperPI nerušeně pracoval. Proto jsou výsledky prvního testu takové, jaké vidíte.
U druhého testu jde čistě o spuštění dvou nezávislých „single-threaded“ aplikací. Dělí-li se obě o jedno jádro, jsou obě pomalé. Bude-li mít každá to své téměř plně k dispozici, budou samozřejmě rychlé obě. Proto SuperPI dává téměř stejné výsledky, jako v prvním případě, kdy byl spuštěn zcela sám.