Dotaz: DivX 6.1.1 codec for Linux developers - instalace

[shadow_hk]

Zdravím Vás,

potřeboval bych pomocí s instalaci DivX® 6.1.1 codec for Linux® developers

http://labs.divx.com/DivXLinuxCodec

Nejsem totiž spokojen s kvalitou decodingu MPEG-4 videa prostřenictvím libavcodec (ffmpegu). Proprietní DivX i bez dodatečných video filtrů poskytuje lepší obraz, a tak bych ho rád rozchodil, jelikož si přechodem z Windows nechci zvykat na horší (prokazatelně lepší výstupní obrazovou kvalitu DivX codecu lze vidět asi nejlépe na hranách ideálně červeného oblečení postav ve filmech, kdy DivX takové hrany krásně vyhladí, zatímco ffmpeg i při maximálním postprocessingu nebo denoise filtru nikoliv a poskytne vždy kostičkovanou hranu;ale i samotný obraz je horší - bez PP se na to s ffmpegem pod Linuxem vůbec nedá dívat, zatímco s DivXem pod Windows úplně bez problému - obraz je s DivXem také pak ostřejší, jelikož není rozmazáván nějakými zahlazovacími filtry).

Jenomže mi to nejde ani nainstalovat.

Mám Ubuntu 7.04.

Příslušný výpis z terminálu po spuštění install.sh (pouštěno s pomocí sudo):

Do you accept the terms of this agreement? Please type yes or no.
yes
Proceeding with installation
unzip:  cannot find or open contents.dat, contents.dat.zip or contents.dat.ZIP.
cp: cannot stat `/tmp/.divx/lib/*.so': No such file or directory
cp: cannot stat `/tmp/.divx/include/*.h': No such file or directory
chown: cannot access `/usr/local/lib/libdivx.so': No such file or directory
chmod: cannot access `/usr/local/lib/libdivx.so': No such file or directory
chown: changing ownership of `/usr/local/lib/libdivx.so.0': No such file or directory

Nezkoušel to už někdo?

Nemohl by mne někdo poradit (krok za krokem), jak to nainstalovat a donutit mplayer, aby to používal místo ffmpegu?

Odpovědi

[shadow_hk]

ještě doplnm, že soubor contents.dat se v daném instalačním adresáři samozřejmě nachází.

[David Ježek]

mozna budu mimo misu, ale proc pouzivas divX? kvuli stolnimu prehravaci? pokud ne, pak se na to vydlabni a prejdi na x264.

[stativ]

Když už to musí být MPEG4-ASP tak použij xvid, je kvalitnější než divx. ffmpegová imlementace je známá svojí nízkou kvalitou, ale zato velkou rychlostí. Hodí se maximálně na realtime encoding.

[J. M.]

Což evidentně popírají výsledky nejznámějšího a nejprestižnějšího testu kodeků na Doom9.org, kde FFmpeg MPEG-4 dosáhl prakticky stejné kvality kódování jako Xvid, zato byl mnohem pomalejší. To, že je "známá svojí nízkou kvalitou", je fakt, který je známý zřejmě jen tobě (spousta lidí jej naopak celá léta doporučovala právě kvůli kvalitě). Pokud s ním dosahuješ nízké kvality a vysoké rychlosti, dokazuješ tím jen to, že jej neumíš nastavit (pokročilé volby u něj zvyšují kvalitu, ale snižují rychlost).

Jinak ale tazatel chce dekodér na dekódování, takže bavit se o kódování je mimo.

[stativ]

Tak mi řekněte, z jaké je ten test doby. Mluvím z vlastní zkušenosti, která je už delší dobu zpátky – od té doby preferuji xvid a od určité doby x264. Navíc uznáváte, že „dosáhl prakticky stejné kvality kódování jako Xvid, zato byl mnohem pomalejší“. To lze jedině za dobrého použití filtrů. Pokud chci realtime enkoding, vybral bych si FFmpeg, který byl (?je?) bez postprocesu rychlejší ale kvalitativně horší než xvid. Na slabém počítači obvykle dám přednost té rychlosti a to mi málokdo vyvrátí. A nesnažte se zamluvit, že FFmpeg je méně kvalitní než xvid a to zejména ve stavu, kdy nepoužijete další volby.

PS. To, že jde o dekoding jsem si nevšiml, vstal jsem totiž čtvrthodiny před tím, než jsem příspěvek psal, za to se omlouvám.

PPS. Díky za urážku, FFmpeg si nastavit umím, ale nemám potřebu, jsou kvalitnější kodeky (xvid).

PPPS. Doufám, že se teď nevytasíte s nějakou obskurní implementací MPEG-4 ASP.

[J. M.]

Je to test z loňska (za rok 2005 nebo 2006). A to byl (a je) doom9 k tomuto kodeku exgrémně skeptický, respektive na něj byl vysloveně alergický a naštvaný. Ale uznal, že kvalitou kódování je srovnatelný s DivX i Xvid. Nicméně jeho veliká pomalost jej odsunula v celkovém hodnocení níž.

„dosáhl prakticky stejné kvality kódování jako Xvid, zato byl mnohem pomalejší“. To lze jedině za dobrého použití filtrů.

Jakých filtrů? To byl prostě test kódování, kde se vstup překóduje na výstup. Snad jediný filtr bylo zmenšení rozlišení. Jestli myslíte filtrů posprocessingu, tak to je věc jiná - např. na artefakty videa kódovaného kodekem Xvid, který používá jiné kódovací techniky (nemá ty "statické čtverečky" jako FFmpeg, ale takový permanentně se pohybující a rozmazávající "blátivý" obraz) se postprocessing uplatňuje těžko, takže to je věc toho, čemu kdo dává přednost - jestli "zablácenému", ale hladšímu obrazu kodeku Xvid bez postprocessingu nebo kostičkovanějšímu, ale "stabilnějšímu" obrazu FFmpegu, který se dá snadno ošetřit postprocessingem (a metod postprocessingu v MPlayeru/libavcodecu je dnes na výběr mnoho, ne jen ten letitý a zastaralý hb/vb). Viděl jsem spoustu diskusí se spoustou zastánců obojího. Rozhodně to, že je FFmpeg MPEG-4 horší než Xvid nebyl nikdy nějaký jednoznačný konsenzus za celých těch pět let co to sleduji. I když je třeba Xvid kvalitnější, není to nějak jednoznačně známý fakt, léta se o tom bezvýsledně vedlo mnoho sporů.

A nesnažte se zamluvit, že FFmpeg je méně kvalitní než xvid a to zejména ve stavu, kdy nepoužijete další volby.

A proč bych ty další volby nepoužil? Od toho tam jsou - to, že dejme tomu v MEncoderu nejsou nastaveny jako výchozí nic nemění na tom, že tam jsou. Kodek Xvid si taky můžete nastavit tak, že bude kódovat ultrarychle (daleko rychleji než FFmpeg ve výchozím nastavení), ale ultranekvalitně (daleko méně kvalitně než FFmpeg ve výchozím nastavení).

Já sleduji mailing listy MPlayeru a MEncoderu již řadu let a o dosažitelné kvalitě kódování kodekem FFmpeg MPEG-4 (který je preferovaný snad všemi vývojáři MPlayeru) tam toho byla velikánská kvanta. V zásadě byl závěr takový, že kodekem FFmpeg MPEG-4 lze dosáhnout stejné, nebo s použitím moderních pokročilých voleb dokonce i o trošku lepší kvality než kodekem Xvid, nevýhodou ale je obrovská pomalost. FFmpeg MPEG-4 je rychlý jenom v tom výchozím nastavení, které je na seriózní kódování nepoužitelné.

[stativ]

takový permanentně se pohybující a rozmazávající "blátivý" obraz

… který mě vyhovuje více než ten „čtverečkovaný“ z FFmpegu.

I když je třeba Xvid kvalitnější, není to nějak jednoznačně známý fakt, léta se o tom bezvýsledně vedlo mnoho sporů.

Takže to vypadá, že se tenhle spor bude táhnout taky léta Jsem pro příměří, protože Vás asi nepřesvědčím, že xvid je lepší než ffmpeg, stejne jako Vy mně o opaku. Nejste náhodou taky beran?

Kodek Xvid si taky můžete nastavit tak, že bude kódovat ultrarychle (daleko rychleji než FFmpeg ve výchozím nastavení), ale ultranekvalitně (daleko méně kvalitně než FFmpeg ve výchozím nastavení)

Neříkal jsem snad, že pro realtime bych využil FFmpeg?

[J. M.]

Ale já se nepřu o to, jestli je lepší FFmpeg nebo Xvid. Já sám jsem na většinu videí používal Xvid, protože mi většinou dával lepší výsledky. I když jsem narazil i na věci, které lépe zakódoval FFmpeg. Já jsem protestoval pouze proti tomu tvrzení, že nekvalita FFmpeg MPEG-4 je všeobecně známý fakt - vzhledem k tomu, že léta sleduji spoustu diskusí, vím, že to tak není. Že daleko větší obliba kodeku Xvid je dána hlavně tím, že o existenci FFmpegu většina lidí neví, zatímco Xvid těží z popularity nastartované kodekem DivX a všemi těmi mýty a bludy kolem toho. Naopak jsem viděl spoustu nadšených lidí, kteří léta používali Xvid a pak najednou objevili FFmpeg a nadšeně začali básnit o jeho netušené kvalitě. A to byli někdy i "kapacity" v oboru.

Jinak pro příměří samozřejmě jsem.

[J. M.]

(byly, ne byli...)

[J. M.]

To, proč tazatel používá DivX, vysvětlil ve svém příspěvku. Tvoje rada ať místo něj použije x264 mu bude určitě hodně platná až to x264 použije k tomu účelu, kvůli kterému celý ten dotaz psal - k dekódování MPEG-4 ASP videa.

[J. M.]

Pokud je ta kvalita bez postprocessingu prokazatelně lepší, pak není nic snažšího než to prokázat Michaelu Niedermayerovi, který vyvíjí libavcodec z FFmpegu. Podle vývojářů FFmpegu a MPlayeru by totiž mezi těmi dekodéry neměl být rozdíl. Tazkže jim to prokaž a oni to opraví. To je hodně zdaleka to nejprospěšnější, co v této situaci můžeš udělat.

Pokud jsi ale porovnával obrazový výstup z Windows (DivX) a Linuxu (FFmpeg), pak bych hledal vysvětlení spíš tam - ty zubaté červené hrany totiž ukazují na rozdíl mezi grafickou kartou nebo ovladačem grafické karty (respektive způsob převzorkování chrominance při zvětšení obrazu). Takže důkaz musí být opravdu pádný a jasný - porovnat dekódovaný výstup obou kodeků (např. zachyceným obrázkem, nebo přímo i na binární úrovni).

[J. M.]

(A aniž bych tě tím chtěl urážet, vzhledem k tomu, že si s tou instalací nevíš rady i tomu, že to chceš používat v MPlayeru bych vsadil na tu druhou možnost, tedy že ta tvoje "prokazatelně lepší kvalita" vyplývá jen z tvého omylu a neznalosti.)

[stativ]

Vývojáři tedy evidentně od posledně dost zamakali

[J. M.]

Nevím přesně, co tím myslíš, ale znovu připomínám, že tahle diskuse je o dekódování. Tazatel chce DivX jenom kvůli dekódování.

[stativ]

Vizte předchozí příspěvek, nešiml jsem si toho a celou dobu mluvím o enkódování.

[shadow_hk]

Jo, bude to spíše otázka obrazového výstupu (grafického ovladače), než codecu, dokonce jsem si xvid i cely mplayer zkompiloval ze zdrojáku, a problém zubatých hran, resp. kostičkování celého obrazu ve full screenu pořád nezmizel, i když se o trochu zlepšil. Různé postprocessing filtry se nejeví, že by měly nějakej efekt.

Používám video výstup xv a proprietní ovladač fglrx od Ati (x1950Pro, C2D E6300, 2 Gb Ram)

Zajímavé je, že pokud použiju X11, tak je obraz krásně ostrý, hrany snad ještě lépe vyhlazené, než u DivXu ve Windows, a "kostičkování" (omluvte tu moji laickou terminologii) vůbec není vidět, ale má to jeden podstatný problém> trhání videa ("tearing"), tedy ne v tom smyslu, že by to CPU nějak nestíhal, ale obraz prostě není plynulý a "trhá se" - při rychlé změně scény. Přitom mám nastavený v ovladačích všechny možné volby pro vertikální synchronizaci obrazu (nebo si to aspoň myslím :) ).

Pokud byste mi poradili nějakou volbu, jak se toho trhání zbavit, byl bych vděčný.

gl výstup nemohu posoudit, protože se mi jeho podpora nezkompilovala (configure mi vyhodil, že opengl není podporováno, což nějak nechápu).

(pro úplnost: ve Windows používám samozřejmě catalysty a zajímá mě momentálně opravdu jen decoding, a to mpeg 4 videa - ano - i kvůli stolnímu přehrávači pro rodiče :) ). Jinak ten DivX 6.11 codec jsem nainstaloval s pomocí rootovské konzole a chybu, co to vyhodí, přokonal dle rady na této stránce: http://www.alionet.org/index.php?showtopic=7997 s tím, že ale nevím, jak donutit mplayer, aby to používal (zkompilovat ho s podporou toho divxu codecu - jeho knihoven). Ale jak už tady padlo, bude to problém spíše grafického výstupu, než codecu.

Předem díky za rady, jak se toho zbavit, popř. toho trhání při X11 výstupu. Ještě se kdyžtak zkusím vrátit k tomu opensourcovému původnímu ovladači. Filmy jsem začal přehrávat až s fglrx.

[J. M.]

Používej Xv, ne X11 - Xv je hardwarově akcelerovaný a je tam ta synchronizace, tedy bez "tearingu". Těch zubatých hran u Xv výstupu se snadno zbavíš tím, že místo hardwarového škálování (které je u tebe nekvalitní, ať už vinou karty nebo ovladače) budeš používat softwarové - pokud to tvůj procesor zvládá.

Například - pokud máš rozlišení 1024x768 a video s poměrem stran 4:3, přehraješ si jej takto:

mplayer -vf scale=1024:768 video.avi

Pak to bude krásně hladké.

DivX ti k ničemu nebude, MPlayer jej nepodporuje.

[shadow_hk]

J.M.: Díky, softwarové škálování u hardwarově akcelerovaného výstupu mne nenapadlo. Funguje to skvěle. Sice to není úplně praktické, protože poměr stran se mění video od videa, a tak musím vždy nastavit k 1280 bodů šířky mého rozlišení odpovídající výšku, ale je to určitě funkční. CPU je v pohodě. Využití asi 15 procent (na default), a to jen jednoho jádra (Mplayer asi zatím nepodporuje využití více jader, že jo? ).

[shadow_hk]

jo, tak sorry, ono to asi samo přescaluje do správného měřítka.

viz napr.

VDec: vo config request - 608 x 336 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1,81:1 - prescaling to correct movie aspect. VO: [xv] 1280x680 => 1280x707 Planar YV12

[J. M.]

Ještě mě napadlo, že bys(te) mohl zkusit výstup xvidix místo xv, ale s tím nemám zkušenosti a ani nevím, jestli je ta karta podporovaná.

[J. M.]

Jinak samozřejmě instalace DivX v Linuxu ti bude totálně na prd - dnes už prakticky neexistuje žádný linuxový program, který ještě DivX podporuje.