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

[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í.