Porovnání video enkoderů

Hlavní vývojář x264 píše ve svém blogu o tom, jak si vedou různé video enkodery při kompresi animovaného videa. První čtyři místa obsazuje samotné x264 při různých nastaveních kvality, následované komerčními enkodery H.264. Je zajímavé, že svobodný kodek Theora (enkoder Thusnelda) se umístil až za FFmpeg MPEG-2 a SVQ1.

11.8.2009 10:12 | elenril | Zajímavý článek

Komentáře

[Grunt]

Je zajímavé, že svobodný kodek Theora (enkoder Thusnelda) se umístil až za FFmpeg MPEG-2 a SVQ1.

Co je na tom zajímavého? Vždyť testy s MPEG-1 jsem tady dělal i já. Závěr je IMHO vcelku jednoznačný.

[elenril]

Tento fakt je natolik zajímavý, že je hoden opakování Třeba lidem konečně dojde, že Theora opravdu není kodek budoucnosti.

[JoHnY2]

+1. Je mi zahadou jak se tenhlre kodek stal tak oslavovanym. Za dob Divx4 se nedal pouzivat. Za Xvidu vytvarel video desivy kvality. Pak jsem nekolik let s videem nic nedelal a jak se zda tak dneska je opet o tridu horsi jez jeho konkurenti.

[Mandarinka]

Theora je stará a s tím není problém, protože u ní paltí, že je kompletně free pro ty, kdož to potřebují. Problém je samozřejmě v hloupých očekávání neznalých webových mas :)

Jinak jak zmíněno v článku, rate control Thusneldy má ještě bugy, které přispívají k špatnému výsledku. Druhá důležitá věc: Theora má velikost transformace 8x8, což jí při kódování anime pořádně kousne, zejména ve srovnání s h.264, které umožňuje jít na 4x4. Pak je tu samozřejmě deficit v podobě jen jednoho referenčního snímku a absence B snímků (to už jsou však obecné nevyýhody platící pro všechan videa).

P.S. : a x264 v tomto druhu videa trahá asfalt díky "--mb-tree", což je nová metoda rate control, kterou nedávno uvedli :) Popsáno v předchozím zápisku...

[Grunt]

které umožňuje jít na 4x4.

Ježiš. Na tak malé plošce má šanci se i nějak projevit DCT?

Pak je tu samozřejmě deficit v podobě jen jednoho referenčního snímku

Bejvávalo.

Popsáno v předchozím zápisku...

Cože? Ona je tu možnost psát zápisky pro neregistrované?

[Jirka]

Rekl bych, ze ma. U animovanych filmu. V nich se stridaji jednolite plochy s ostrymi prechody. Tahle mista jsou velmi citliva na orezani ve frekvencni domene.

[Mandarinka]

Ano, 4x4 je pro animaci velice výhodné, myslím, že to ten vývojář uvádí i tam, jestli ne, tak já to od něj "slyšel".

Tím zápiskem myslím předchozí zápisek na jeho blogu ;)

[kavol]

mě to teda taky nepřekvapuje - celé hýkání okolo OGG Vorbis a OGG Theora je jen nafouknutá bublina, kdo chce vidět fakta, ten je vidí, koho zajímá jen ideologie, ten se může na toto sdělení tvářit překvapeně, a objeví-li se nějaký nový test, bude se tvářit překvapeně znova (z diskuse nad odkazem: "Viz prehistorický formát mp3, který v některých případech dosahuje na stejném bitrate až řádově horších výsledků, než jiné moderní formáty ..." - na to se nedá říct než OMG ...)

[Grunt]

celé hýkání okolo OGG Vorbis a OGG Theora je jen nafouknutá bublina

O čem je řeč? Pokud pomineme obchcávku jménem spektrální pásmová replikace u AAC+, tak aoTuV(Aoyumi Tuned Vorbis) kodek byl neoficiálně vyhlášen vítězem současné doby.

[Grunt]

aoTuV

V kterém je jen tak mimochodem také zvuk z ukázky, takže kdyby to někomu moc cinkalo, vězte, že používáte pro dekódování špatný kodek.

[kavol]

hm, a já jsem myslel, že svobodná specifikace formátu je tady od toho, aby kdokoliv napíše software tento formát čtoucí, mohl dostat stejný výsledek ... takže pokud aoTuV kóduje do něčeho, co si je po sobě schopen korektně dekódovat jen on sám, tak to "něco" nemůže být Vorbis

[Grunt]

Třeba dává a jen to pre-echo zase nějak maskuje.

[Mandarinka]

AFAIK je aotuv 100% kompatibilní. aotuv v1 nebo v2 se koneckonců dostal do upstreamu. Jako tuším jediná podstatná změna od roku 2001 nebo tak, hehe :) Doufejme že se pletu.

[trekker.dk]

Zrovna Vorbis je AFAIK podstatně lepší než mp3 - někde jsem na to viděl testy a sám jsem si ověřil poslechem - hlavně při nízkých bitrate (64kbps) je mp3 neposlouchatelné, kdežto Vorbis hraje vcelku v pohodě.

(Na druhou stranu u nízkých bitrate mi to může bejt fuk, protože je nepoužívám. A na vyšších je to - tipuju - skoro jedno.)

[David Ježek]

je lepší, neořezává vysoké frekvence a mám vyzkoušeno, že u TVripů např. ~112-192kbps vbr mp3 dokážu nahradit ~70-120kbps oggem beze slyšitelné ztráty kvality.

[kavol]

hm, u TV-ripů dokážu nahradit cokoliv ~48-128 kbps mp3 bez slyšitelné ztráty kvality - zrovna vysoké frekvence není to, co by TV vysílání přenášelo kvalitně :-p

(ach jo, a to jsem si o tobě myslel, že technickým záležitostem okolo těchto věcí trošku rozumíš ...)

[David Ježek]

no za starých analogových dob toho ve frekvenčním pásmu doputovalo z vysílače do mého tuneru celkem dost (ale bavím se jen o porovnávání frekvenčních křivek ogg a mp3, jestli tam bylo něco reálného, to už po letech nevím). jinak samozřejmě tu moji poznámku si můžeš vztáhnout i na dvdrip, na principu to nic nemění. jinak ono to není jen o vysokých frekvencích, tos mě špatně pochopil. je to o "slyšitelné kompresi v mp3" (a opět nechytat za slovíčko, nebo přiběhne Heron a to teprve bude tanec .

[kavol]

a tys' mě špatně pochopil, že bych tvrdil, že je to jen o vysokých frekvencích, to jen polemizuju s částí tvého příspěvku

nejsem teď schopen dohledat rozumný zdroj ale domnívám se, že rozsah přenášený "naší" normou je 50 Hz - 15 kHz, když si zkusím lame, tak to mi filtr odřezávající frekvence nad 15 kHz nasazuje při kompresi 56 kbps na kanál ... což samozřejmě nemusí nic vypovídat o výsledku, ale řekl bych, že to kluci maj za ty léta vychytaný

co se týče DVDripů nebo čehokoliv, toho ostatního zkreslení než jenom odříznutí výšek, když jsem si s tím naposledy hrál (kolem posledních vánoc), tak pro mě 120 kbps vorbis (oggenc, nevím, co používá jako backend, ale o nějakém aotuv jsem netušil) rozhodně znamenal slyšitelné zkreslení, tedy horší výsledek než mp3 na 192 kbps ABR ... neslyším nijak výtečně, ale některé věci vnímám trošku jinak než většina ostatních, možná tobě by to nevadilo

nicméně v dnešní době diskusi na téma jestli 192 kbps mp3 nebo 192 kbps ogg-vorbis považuju za lichou, FLAC a středně velký disk (resp. pro stahovače středně rychlá linka) silně ubere vrásek na čele

[Grunt]

Na druhou stranu u nízkých bitrate mi to může bejt fuk, protože je nepoužívám.

Co? Proč? Vždyť 24kbps rulezz!

[trekker.dk]

zz? To je zvuk, který slyšíš u vyšších tónů při nižších bitrate

[Grunt]

Přesně, ale vždyť je to paráda, ne?

[kavol]

já už viděl takových "testů" ... kdybych se trošku snažil, tak ti nějaký takový vyrobím, kde na nějakém konkrétním příkladu ti hezky v grafu ukážu, jak je Vorbis horší než mp3 :-p

ale že jsem línej, tak ti povím jenom "historku z natáčení" - kdysi dávno pradávno jsem vlastnil SonyEricson P800, do kteréhožto jsem neměl více než 128 MB MemoryStick ... no a na ten jsem si chtěl nacpat sadu nějakých písní, vesměs (více)hlas a kytara(-y), abych si je po cestách do práce a z práce naposlouchal a byl je schopen na vandrech apod. nějak rozumně zahrát ... jenže tato sada byla obrovská a ubírat jsem z ní nechtěl ... tak jsem experimentoval s různými formáty, a nakonec jsem to tam dostal celé v kvalitě sice zjevně omezené, ale takové, že mi to netrhalo uši - no a hádej jaký formát zvítězil? ... ano správně, mp3, vorbis se pod nějakých 40 kbps vůbec nechytal

leč tato historka měla ještě dohru - i stalo se jednou, že jsem si písně z onoho MemorySticku nepouštěl na sluchátkách z telefonu, nýbrž na kamarádových šumítkách k počítači s integrovanou zvukovkou ... zděsil jsem se, jaký to je skřípot, zkusil cvičmo prostřídat pár skladeb, a raděj jsem to urychleně vypnul ... leč nedalo mi to, a při první příležitosti jsem si to pustil doma na SB Live! (nicmoc chrchlák) a vlastnoručně vyrobených bednách s recyklovanými ARS-165-21/4 (starší verze, ta co má trvalý příkon uváděný 30 W, dnes má jen 10 W) - no a ono se to dalo poslouchat stejně dobře, jako na těch sluchátkách v tramvaji!

co z toho plyne?

- by default nevěřím testům od příznivců čehokoliv

- chyby se rády sčítají, pokud si nejsem jist kvalitou všech ostatních článků řetězu, nemohu o jednom prohlásit, jak moc je špatný (zpytuj svědomí, na čem sis ověřoval poslechem)

co z toho neplyne?

- netvrdím, že mp3 je (obecně) lepší než Vorbis, dokonce ani netvrdím, že Vorbis nemůže být průměrně lepší ... tvrdím pouze, že není vždy řádově lepší (poslyšte Kefalín, a co vy si vlastně představujete pod tím "řádově", jak se měří taková velikost subjektivní kvality?)

[J. M.]

On vůbec FFmpeg v tom testu docela bodoval. Jeho MPEG-4 ASP kodér (ne „enkoder“ ze zprávičky, takové slovo v češtině neexistuje) byl nejen že mnohem lepší než konkurenční Xvid, ale i než Apple H.264. Takže jednak mizerná implementace modernějšího formátu (Apple H.264) může být mnohem horší než vynikající implementace zastaralého formátu (FFmpeg MPEG-4 ASP), jednak to opět potvrzuje, že FFmpeg MPEG-4 byl celé roky nespravedlivě celým světem ignorován (lidi se ptali, proč vůbec něco takového existuje, když je tu slavný Xvid, tedy proč se asi autoři FFmpegu neoběsí a tak).

A ty problémy s Thusneldou prý byly hlavně kvůli těm problémům s ratecontrol (které jsou u animací zákeřné) a ne vyloženě kvůli formátu (ne kodeku, jak píše mylně zprávička) Theora, takže se to prý může hdně zlepšit. Rovněž mě zaujalo, jak relativně špatně v testu dopadl WMV (opět horší než FFmpeg MPEG-4)...

[elenril]

No jo že vás lidi baví pořád slovíčkařit. Pokud oba víme o čem mluvíme, tak je to snad jedno, ne? (navíc formát taky není moc dobrý výraz, protože může znamenat i kontejner)

A Theora si může být potenciálně dobrá jak chce, ale dokud nebude pořádný enkoder (což se slibuje už dost dlouho), tak ať si ji nechají vyznavači patentů.

[Grunt]

A Theora si může být potenciálně dobrá jak chce, ale dokud nebude pořádný enkoder (což se slibuje už dost dlouho), tak ať si ji nechají vyznavači patentů.

Co? Stále platí, i přesto jak na tom Theora je, že je to jediný možný použitelný formát v současné době, pokud uvažujeme zahrnutí do HTML5(teda krom MPEG-1, ale tam to také není tak žhavé). Tak mě napadlo, jak na tom je slib On2 Technologies o nedělání problémů, když ho odkoupil Google? Slib se přesouvá nebo zaniká?

[xm]

Slib rozhodně tím že je koupila jiná firma nezaniká, právně to měli ošetřeno dobře.

Navíc jsou tu spekulace, že Google opensourcuje (respektive uvolní patenty) novější kodeky od On2 (že právě proto On2 koupil - aby získal kvalitní kodeky do HTML5, které pak nebudou patentově zatížené).

[Grunt]

Navíc jsou tu spekulace, že Google opensourcuje (respektive uvolní patenty) novější kodeky od On2 (že právě proto On2 koupil - aby získal kvalitní kodeky do HTML5, které pak nebudou patentově zatížené).

Všechno k tomu směřuje. Jen abychom nebyli překvapeni. No min. by tím dobře namíchnul svého tzv. nepřítele Apple.

[xm]

Pokud by otevřeli VP7, tak to bude naprostá bomba! Podle testů které jsem viděl (třeba na TV Freaku) dává VP7 prakticky jako jediný kodek téměř stejně dobré výsledky jako x264. To by byla pro HTML5 jasná volba a Apple by se z toho mohl pos**t Pro patentově zatížené kodeky by to byl konec.

Nebo ještě lépe připravovaný (či snad už hotový? Ještě jsem ho nikde v testech neviděl...) nejnovější VP8, který by měl (pokud se dá věřit marketingu On2, takže to brát s rezervou ) H.264 drtit na plné čáře.

[Mandarinka]

VP7 na dnešní x264 nemá ani náhodou. VP7 už kdysi mělo o něco lepší výsledky v anime než na přírodním materiálu (tím myslím v době, kdy se o něj ještě někdo zajímal), takže zde v tomto testu má lepší výslešdek než normálně.

[xm]

Ano, VP7 je zcela jistě horší než současné x264. Ale v době vzniku VP7 byl ten rozdíl podstatně menší (x264 se vyvíjí a optimalizuje opravdu velmi rychle, kdežto VP7 se prakticky přestalo vyvíjet). Ovšem ten rozdíl není moc velký, VP7 je rozhodně lepší než proprietární implementace H.264 od Applu a podobných a MPEG4 ASP (i skvělou implementaci od ffmpegu či xvid) překonává na plné čáře. Takže do HTML5 by bylo VP7 zcela dostatečné.

Navíc jak jsem psal už je tu VP8, které by dle tvrzení On2 (a nějakých testů, jenže také zatím jen od On2, takže samozřejmě v tom bude marketing) mělo překonávat H.264 (obecně) na plné čáře (myslím že někde dokonce mluvili o stejné kvalitě při polovičním bitratu, ale tomu nevěřím). Byla tam jestli se nepletu i ukázka porovnávající s x264 kde výsledek VP8 byl viditelně lepší. Ale jaká bude realita se samozřejmě uvidí teprve s tím až bude kodek VP8 uvolněn pro veřejnost. Každopádně pokud by Google uvolnil patenty a VP8 opensourcoval, byl by to pro H.264 konec (no dobře, konec asi ne kvůli spoustě firem která za MPEG LA stojí, ale rozhodně by to byla bomba ).

[Mandarinka]

 

Byla tam jestli se nepletu i ukázka porovnávající s x264 kde výsledek VP8 byl viditelně lepší.

1. VP8 ještě nikdo neviděl v akci. Připomenu že bylo uvedeno před 3/4 rokem. 2. Ten obrázek s mizerným h.264 (to bylo srovnání s "h.264", nikoliv s x264) byl a) silně neprůkazný b) jasný fixl (takhle mizerně by žádný h.264 kodek nevypadal, asi ani kdyby jste mu zrušili inloop). 3. jak vidíte v testu, on2 si mohlo ke srovnání zvolit gpu enkodér, quicktime či podobného tragéda a značně si ulehčit práci... na překonání h.264 najednou má kdekdo. No a pak je tu samozřejmě stará dobrá selekce snímku (něco kde konkurence má co nješkaredější b-frame a my co nejhezčí p-frame. Nebo se postarat aby jsme ta měli rovnou Íčko...)

Zkrátka jsou to sedmilháři.

 

[elenril]

Vzhledem k tomu, že v USA je evidentně možné si nechat patentovat naprosto všechno, mám silné pochybnosti o tom, že je možné napsat jakýkoliv netriviální program, který by něco neporušoval. Proto bych se vůbec nedivil, kdyby se na Theoru taky vztahovaly nějaké patenty (nepatřící On2).

Navíc u H.264 se (nakolik je mi známo) nevyžadují poplatky za streaming přes internet, takže by v HTML5 klidně být mohlo, nebýt freetardů.

[xm]

Klidně si mě nazývej "freetardem" (budu na to jedině hrdý :-P), ale patentově zatížený kodek nemá v HTML5 co pohledávat!

Samozřejmě nejideálnější by bylo úplně zlikvidovat softwarové patenty v USA a jinde ve světě (nás se naštěstí netýkají), ale i když pevně věřím v to že se to časem podaří, bude to pomalý proces

[JeCh]

Ale od příštího roku se, pokud vím, vybírat začnou. Uvázat se k něčemu s tím, že momentálně to je zadarmo bez záruky, že to bude zadarmo i do budoucna je neskutečně krátkozraké.

[Grunt]

Mám pocit, že u H.264 se bude platit za každé přehrané video(neplatí už teď náhodou Google teď za YouTube?). A patentů,licencí a IP na něj bude asi také dost. A stačí se podívat jak dopadlo MPEG2. O něj se moc nikdo nestaral a až nabyl popularity, tak dnes existuje přes 640 známých platných patentů. Jak by dopadlo H.264 kdyby se dostalo do HTML5 specifikace asi netřeba domýšlet. Ovšem tato situace tu není poprvé, že? Pamatuje ještě někdo GIF vs. PNG? H.264 absolutně ne!(min. do té doby než těm Denverským vypálíme barák)

[xkucf03]

Mám pocit, že u H.264 se bude platit za každé přehrané video

Amerika si tímhle přímo říká o to, aby firmy zvedly kotvy a přesunuly svá sídla do nějaké svobodnější země.

[Grunt]

Kdepak. Ti ještě za takové ptákoviny lobují u zákonodárců. A pak je trh jako svině. Výrobci si skupují technologie mezi sebou, vyplácí si za licence, zisky rostou a divý se že je krize, když to s tak nabubřelou cenou jak si to handlují mezi sebou nechce normální zákazník koupit. Navíc USA má jeden z nejlepších ochranných systémů pro biznis. Ukradneš nápad, zkopíruješ chráněné dílo a ruky ti useknem.(Ale mezi sebou si to vždycky zametou pod kobereček) JiK by mohl vyprávět.

[J. M.]

Slovíčkáření to není v žádném případě. A jde právě o to, aby se vědělo, o čem je řeč. Zmatky mezi pojmy formát a kodek (99,9999 procent lidí ten rozdíl nechápe) způsobily děsivou pohromu za celých uplynulých 10 let, kdy je toto téma populární. Úplně to zdeformovalo celou multimediální oblast, celý byznys, přiživilo parazity a ublížilo open-source projektům (jako FFmpeg) atd. Na tomto zásadním nepochopení je založena spousta naprosto pomýlených rozhodnutí.

Theora není kodek, je to formát, specifikace.

[Grunt]

I stejnojmenný kodek. Teda pokud to nechcete nazývat libencdec.

Zmatky mezi pojmy formát a kodek (99,9999 procent lidí ten rozdíl nechápe) způsobily děsivou pohromu za celých uplynulých 10 let, kdy je toto téma populární. Úplně to zdeformovalo celou multimediální oblast, celý byznys, přiživilo parazity a ublížilo open-source projektům (jako FFmpeg) atd. Na tomto zásadním nepochopení je založena spousta naprosto pomýlených rozhodnutí.

Ostatně jako jakákoliv jiná oblast, která se příliš popularizovala.

[J. M.]

I stejnojmenný kodek.

Theora není kodek. Theora je pouze specifikace. To je oficální (tzn. přímo Theora to takto rozlišuje) a technicky správná interpretace.

Teda pokud to nechcete nazývat libencdec.

Referenční implementace Theory je knihovna zvaná libtheora. Ve vývojové větvi se Thusnelda. To je kodek. Ten kodek se nejmenuje Theora.

Je velmi důležité to rozlišovat, protože řada lidí naprosto nepochopí problematiku, když se píše, že kodek Theora má špatnou kvalitu, protože z toho není zřejmé, jestli je problém ve formátu (Theora) nebo implementaci (libtheora, Thunselda).

Oficiální, encyklopedická definice slova kodek je zařízení nebo počítačový program, kódující a dekódující data. A specifikace není ani zařízení, ani program.

Ostatně jako jakákoliv jiná oblast, která se příliš popularizovala.

Ano, obecně co se týče počítačové oblasti, největší zlo je obecně nepochopení rozdílu mezi formátem a software. Pak si každý myslí, že Xvid je formát, Internet Explorer je internet a Windows jsou počítač. Jediné, co je ještě horší, je to, když na chybu někdo upozorní, je mu jen opáčeno, ať neslovíčkaří, že každý ví, o čem je řeč. Právě že vůbec neví. Skoro nikdo. V tom je ten průšvih.

[JeCh]

Přesně tak, o slovíčkaření rozhodně nejde. Je poměrně důležité to rozlišovat. Protože pokud porovnávám implementace (kodeky), ještě to nemusí nic vypovídat o formátu. Například podle testu je implementace MPEG-4 ASP v FFmpegu tak dobrá, že je lepší než MPEG-4 AVC od Applu. A někdo by z toho mohl udělat úplně chybný závěr, že ASP je lepší než AVC.

 

Mimochodem o tomhle pomatení pojmů jsem nedávno napsal i článek: http://jech.webz.cz/kodek.php

[J. M.]

Jen houšť a více takových článků. Pasáž o DivX je hezky zpracovaná a v tomto směru klíčová.

Ještě by to chtělo udělat trochu pořádek v té Wikipedii (která si někde i sama protiřečí, když v úvodu vysvětlí, že kodek je zařízení nebo program, a pak jako příklady kodeků uvádí třeba MP3 atd.)

[Mandarinka]

ffmpeg má pro hodně svých kodeků velice brutální (náročné na cpu) metody hledání optimálních způsobů uložení informace (RDO, trellis, quantizer noise shaping = v podstatě se to snaží zmanipulovat kompresní artefakty tak aby vypadaly jako že do videa patří a moc nečněly, například k simulaci zrnitosti...). Na xvidu posledních 5 let nikdo nic neudělal (jen nedávno se vydala nová verze, protože podpora vícejader byla po léta jen v cvs) a není kam u něj šponovat spotřebu CPU. COž platí o hodně kodecích, nemají zkrátka ty "šílené" možnosti pro lidi se spoustou času a silným cpu. To se týká i Theory.

[Grunt]

To se týká i Theory.

Ta by se ještě měla dát šponovat. Vždyť není tak dávno co ještě neměla vůbec žádnou adaptivní featurku a už se to začíná pomaloučku do ní plánovat.

[Mandarinka]

Ale jo, každý formát se dá šponovat... minimálně s použitím metody hrubé síly :) Například do x264 míří po dlouhé době podpora pro weighted p-prediction, což by mohlo konečně přinést nějaké to univerzální navýšení komprese :)

[Grunt]

Přesně, všelijaké predikce, adaptace a optimalizace. Těch nikdy nebude dost.

BTW: Co to zas čtu? European Patent Application?

[Mandarinka]

Predikce musí mít podporu ve formátu (aby dekodér věděl, co a jak si má takříkajíc sám uhádnout), takže Theora beze změn specifikace další takové schopnosti přidat nemůže. Je to zrovna něco, v čem VP3 dost pokulhává. Problém je zřejmě právě v tom, že zadání znělo obcházet patenty...

[Mandarinka]

Ah, zapomněl jsem: "weighted prediction" je to, co způsobuje, že lepší h.264 kodeky mají kvalitní stmívačky a rozetmívačky, zatímco zbytek světa tam má tragické čtverce (Snow pak nějaké sramdovní artefakty). I to je jedním z velkých pozitiv h.264.

[Grunt]

Přílohy:

• bez_posunuti.png (307447 bytů)
• s_posunutim.png (409263 bytů)

Mám představu. Sám jsem si nedávno zkoušel jak bude vypadat residual frame u roztmívačky bez a jen s blbým posunutím Úrovně. Docela se divím, že se to teprve tak nedávno začalo implementovat.

[Mandarinka]

Ono se to totiž musí bez této predikce kódovat intra... a takových 5-15 intra framů za sebou hodně zabolí. Buďto utratíte hodně bitů, nebo to zkrátka bude vypadat hrozně (což kodeky udělají, proto ty bloky).

Z těch zahrnutých h.264 kodeků mají weighted prediction ateme (p i b), x264 (b; vypnuto v baseline a ultrafast; p predikce by měla přijít koncem léta), elecard (p) a možná, možná Real (což je tak trochu obšlehnuté draft h.264 bez CABACu).

Nechytil jsem obrázky stejného snímku, ale pro představu to snad stačí...
x264: img41.imageshack.us/img41/9956/snapshot20090812132052.png
mpeg4 asp (ffmpeg):img208.imageshack.us/img208/2271/snapshot20090812132137.png

[Grunt]

Příloha:

• dirac_fade.png (163968 bytů)

Heh, co MPEG-4 ASP, ale to by potřeboval zvláště Dirac.

[Grunt]

Mimochodem o tomhle pomatení pojmů jsem nedávno napsal i článek: http://jech.webz.cz/kodek.php

Je, tesat. Hlavně to o těch firemních taktikách. To by si měl přečíst můj strýc.

BTW, když už je o tom řeč. Jak je to s MPEG-1 Part 2? Všude čtu, že za vývojem stála skupina ustanovená organizací ISO. Ta obsahovala i nějaké členy from various industries, universities, and research institutions

?

[J. M.]

S těmi firemními taktikami byl JeCh k firmě DivX ještě milosrdný a některé aspekty vypustil.

(S tím MPEG-1 to bylo, zdá se, opravdu hodně nepřehledné. Návrhy posílaly různé firmy, organizace a instituce, ale čert ví jaké.)

[Grunt]

Theora není kodek. Theora je pouze specifikace.

V tom případě mají něco v Xiph.org špatně, ne?:

Theora is a video codec, based on the VP3

Já si myslím, že formát se jmenuje Theora a kodek je též Theora a nebo o jiném názvu alespoň nevím.

Ve vývojové větvi se Thusnelda.

Někdo nečte zprávičky? A teď babo raď. Referenční implementace jménem trunk?

[J. M.]

V tom případě mají něco v Xiph.org špatně, ne?

Já tam čtu tohle:

„Theora is a free and open video compression format from the Xiph.org Foundation“

Jestli mají i na nějaké jiné stránce napsáno, že to je kodek, tak to je nějaký historický text, který jenom po letech aktualizací unikl pozornosti. Již před nějakým pátkem jasně vyhradili název Theora pro formát, a pro implementaci název libtheora.

Já si myslím, že formát se jmenuje Theora a kodek je též Theora a nebo o jiném názvu alespoň nevím.

Kodek se jmenuje libtheora. Je to knihovna s tímto názvem. Ta knihovna se nejmenuje Theora.

Někdo nečte zprávičky? A teď babo raď. Referenční implementace jménem trunk?

Zprávičkař nečte to, o čem píše zprávičku. :-P Tak si to přečtěme za něj:

Tag the libtheora-1.1beta1 release.

Povšimněme si názvu libtheora, nikoli Theora. Softwarová implementace Theory se nazývá libtheora, nikoli Theora. libtheora je softwarový produkt, knihovna, jak si můžeš všimnout i na oficiální stránce ke stažení této knihovny:

http://downloads.xiph.org/releases/theora/

Tato zbytečná debata mě už začíná unavovat, takže snad naposledy shrnuji: Theora je specifikace, formát, libtheora je kodek, neboli softwarová implementace.

Thusnelda byl kódový název vývojové větve, jejímž záměrem bylo posléze začlenění do „běžné“ libtheory:

http://www.xiph.org/press/2009/thusnelda-alpha-1/

Totéž platí pro Vorbis. To je též název formátu, a referenční implementace se oficiálně jmenuje libvorbis.

[J. M.]

Vlastně ty odkazy na stažení jsou obecně spíš tady:

http://xiph.org/downloads/ (stažení produktů libvorbis, libtheora a dalších)

http://www.theora.org/downloads/ (stažení libtheory, „referenční implementace“)

[Grunt]

No budiž. Přesvědčil si mě.

[Mandarinka]

 

A ty problémy s Thusneldou prý byly hlavně kvůli těm problémům s ratecontrol (které jsou u animací zákeřné) a ne vyloženě kvůli formátu (ne kodeku, jak píše mylně zprávička) Theora, takže se to prý může hdně zlepšit. Rovněž mě zaujalo, jak relativně špatně v testu dopadl WMV (opět horší než FFmpeg MPEG-4)...

To není tak docela pravda, nižší komprese je samozřejmě i zásluhou omezených schopností formátu, které se samozřejmě překonat nedají. Tipuju, že za cenu velkého úsilí vývojářů a (značného zpomalení kódování) by mohla dosáhnout někam pod xvid.

 

[Mandarinka]

Hmm, tak jsem se podíval na celé video a co nevidím, několik prvních sekund vzorku Theora je velmi fajn. Ale ouha. Stalo se to, že enkodér, byť v 2-pass módu, byl ze začátku příliš štědrý, vyplácal si zásobu a drtivá většina videa potom vypadala příšerně...

[xm]

Wow, mile mě překvapil mě Snow, který vyšel také lepší než Apple H264. Ten by měl být jestli se nepletu také patentově nezatížený (používá wavelet kompresi), podobně jako třeba Dirac. Což je tedy věc která mě docela mrzí, že Dirac tam otestován nebyl...

[Ladicek]

I was going to include Dirac as well, but I couldn’t figure out how to set the keyint to 250, and it would be very unfair to include Dirac with the default low keyint (40).

Tak mu někdo poraďte

[Grunt]

Ježiš. mencoder. No tak komu není radno, tomu není pomoci. Dirac-research obsahuje svůj přežvýkavač, který má vcelku obstojné možnosti nastavení(včetně délky GOP). Ale myslím si, že Dirac nemá cenu moc zahrnovat. Pominu-li rozbitou kompenzaci pohybu a nějaké problémy právě s frekvenčními vrstvami, tak Dirac byl konstruován absolutně na něco jiného a u tak malých bitrate by se ocitl na posledním místě. To ani netřeba testovat.

[Mandarinka]

On ví co dělá, a s testem pomáhali další lidé, včetně vývojářů ffmpegu (kterým je nakonec i autor toho blogpostu).

[Grunt]

Netvrdím že ne, ale kódit něco co má vlastní referenční přežvýkavadlo(teda krom všech těm MPEG. Zrovna pářu ten z MPEG-1 a to je fakt něco)…

[Grunt]

Wow, mile mě překvapil mě Snow, který vyšel také lepší než Apple H264.

Což pro mě též není překvapení, protože jsem ho srovnával s H.264 blivajzem z YouTubu. Akorát by mě teda zajímalo jak autor dosáhnul nějaké bitrate když rate-control má snow nefunkční. IMHO, kdyby se dodělal měl šanci šlapat x264 pořádně na paty.(i když vlnková komprese též není samospasitelná…lepší by byl nějaký hybrid spojující frekvenční vrstvy z DWT a bloky používající se u DCT)

[Grunt]

Akorát by mě teda zajímalo jak autor dosáhnul nějaké bitrate když rate-control má snow nefunkční.

vcodec=snow:vstrict=-2:vbitrate=250:pred=0:mbd=2:cmp=12:subcmp=12:mbcmp=12:qpel:vme=8:refs=8:keyint=250

Aha, no tak to měl autor teda štěstí.

[Mandarinka]

snow nemá bframes, nefunguje mu v4mv (zhoršuje kompresi, protože kodek špatně rozhoduje, kde to použít), a zatím žádné RDO/trellis módy....

Dělal jsem testy na anime, a v bezeztrátovém módu prohrál s x264 (obojí prakticky v nejžravějším/nejpomalejším módu) jen o 2 procenta nebo tak... 81MB proti 80MB...

To je skvělý výsledek a ukazuje potenciál, nicméně waveletová komprese je obtížná a znemožňuje mnoho fíglů, které dělá x264 (dle slov vývojářů). No a samozřejmě ho nikdo už dlouho nevyvíjí, takže už se na tom asi nic nezmění.

[Grunt]

snow nemá bframes

A kdo jo?

nefunguje mu v4mv (zhoršuje kompresi, protože kodek špatně rozhoduje, kde to použít), a zatím žádné RDO/trellis módy....

IHMO to je to oproti nefunkční rate-control jen pakatel. A přesto v současné době i když se nastaví konstantní kvantizační škála, tak si s ním nemůže Theora soupeřit. Jak by asi dopadla(i s ostatními formáty), kdyby všechny tyto funkce byly správě implementovány a plně funkční?

Dělal jsem testy na anime

Tak na to zas pozor. Díky vrstvičkám je vlnková komprese na hrany ještě náchylnější než bloková komprese pomocí DCT. Díky zmenšení rozlišení/kvantizaci (ani nevím co to vlastně pořádně dělá) u jednotlivých frekvencí to hrany jiné než horizontální a vertikální pěkně odschodkuje od nejnižších frekvencí po nejvyšší jako bicubické škálování. Ještě by to chtělo nějak trošku domyslet.

To je skvělý výsledek a ukazuje potenciál, nicméně waveletová komprese je obtížná a znemožňuje mnoho fíglů, které dělá x264 (dle slov vývojářů).

No jo, loop deblocking filtering a přichytávání k hranám u ní asi bude na nic.

No a samozřejmě ho nikdo už dlouho nevyvíjí, takže už se na tom asi nic nezmění.

Co to? Bink, Tarkin, Rududu, Snow a teď Dirac. (plus teda ještě JPEG2000). Po malých kouscích se v čase s ním tak furt nějak experimentuje.

[Grunt]

Příloha:

• schodky.png (563152 bytů)

Díky zmenšení rozlišení/kvantizaci (ani nevím co to vlastně pořádně dělá) u jednotlivých frekvencí to hrany jiné než horizontální a vertikální pěkně odschodkuje od nejnižších frekvencí po nejvyšší jako bicubické škálování.

[Mandarinka]

Bink dopadl v tom testu ještě hůř než Theora. Rududu jsem v životě nepotkal a AFAIK je mrtvé, nevím ani do jakého stádia rozpracovanosti se dostalo. Snow je nevyvíjen od roku 2007, i předtím byly práce sporadické. Začátkem tohoto roku přišlo pár bugfixů a kosmetiky (ale pořád to padá pokud zapnete analyzování chromy). Tarkin je prakticky čistý vaporware (myslím, že jediné co se kolem něj stalo byly diskuse v mailinglistech). Dirac mimochodem má bframes, ale je silně nedotažený takže ničemu nemůže konkurovat.

[Jirka]

 

Tak na to zas pozor. Díky vrstvičkám je vlnková komprese na hrany ještě náchylnější než bloková komprese pomocí DCT. Díky zmenšení rozlišení/kvantizaci (ani nevím co to vlastně pořádně dělá) u jednotlivých frekvencí to hrany jiné než horizontální a vertikální pěkně odschodkuje od nejnižších frekvencí po nejvyšší jako bicubické škálování. Ještě by to chtělo nějak trošku domyslet.

Nezapomnel jsi na HH pasmo? To totiz resi ty diagonaly.

Jinak jak pisu jinde, kvantizace se dela u vlnek uplne jinak. Zmensovani rozliseni je jen v LL pasmu, coz ale neznamena, ze se ostatni pasma zcela zahodi, nebo ze HH pasmo dopadne z tech trech LH, HL a HH pasem nutne nejhur. Vsechno zalezi na tom, jak probehne nasledujici kvantizace, ktera se prave nesikovne ridi (coz taky pisu jinde).

 

[Jirka]

Problem vlnek je ten, ze aby mely dobre vysledky, je potreba je delat na mnohem vetsi plose nez 8x8. A z toho plyne jejich velka narocnost na zdroje.

Ad kombinace DCT a vlnek, po kterych volal predrecnik... Ona takova DCT neni vlastne nic jineho nez velmi specialni vlnkova transformace, byt se to na prvni pohled nemusi vubec zdat. Je to jen o matematice. Jejich kombinace by bylo prekombinovani problemu (komprimovat vystupy nejakeho waveletu pomoci DCT je oblibene cviceni na nekterych skolach v oboru, aby se a) oboje procvicilo a b) ukazalo, jak to nicemu nepomuze, byt je to lakava myslenka).

Osobne bych DCT nezatracoval - jeji vyhoda je implementace dovedena prakticky k dokonalosti, snadna manipulace s daty a nepochybne i ideova jednoduchost. Pouzivane filtry ve vlnkove transformaci jsou vsechno, jenom ne primocare na pochopeni. DCT je proti tomu kristalove ciste, z cehoz take prameni ty moznosti dalsich figlu - proste je mozno je vubec vymyslet.

[Grunt]

Ad kombinace DCT a vlnek, po kterych volal predrecnik... Ona takova DCT neni vlastne nic jineho nez velmi specialni vlnkova transformace

Což nejsou nic jiného než speciální případy Fourierovi transformace, což není nic jiného než převod signálu z domény časové do domény frekvenční. Asi jsem se blbě vyjádřil. Spíš jde o problém rozřezání obrazu na malé segmenty vs. rozřezání obrazu na vrstvy podle frekvencí(či jiná technika). Když něco převedeme do frekvenční domény, něco ořežeme a zas to budeme replikovat, tak to většinou bude dávat stejné výsledky ať jde o transformaci jakoukoliv(samozřejmě pominu, že každá dává na jiných místech jiné koeficienty).

[Jirka]

Nerad bych se hadal, ale Fourierovu transformaci bych spis pokladal za specialni pripad vlnkove transformace. Nicmene je mozne, ze matematicky lze najit i opacne odvozeni (neznam ho).

Samozrejme i vlnkove kodeky pocitaji s rozrezanim obrazku, nez jej zacnou kodovat. Jinak by to bylo velmi narocne na zdroje. Vzhledem k tomu, ze dneska musi video prehrat kde co na baterky, je to dost limitujici.

Nejsem si jisty, jestli Ti dochazi, ze ten vlastni figl neni v transformaci, ale v podeleni koeficientu po transformaci. Transformace je pomaha usporadat energii tak, aby orezani melo co nejmensi vliv pri zpetne transformaci. Snad ses opravdu jen spatne vyjadril.

Vlnkova transformace je obecnejsi, protoze a) umoznuje si vybrat z mnoho ruznych filtru (vzdy jeden funguje jako dolni a druhy jako horni propust, zjednodusene receno) a b) provadi se opakovane (obvykle jen u vysledku z dolni propuste). Prave bod b zpusobuje velkou narocnost na zdroje. A bod a zas umoznuje az neuveritelne laborovani, ktery ze ten filtr pouzivat. U vlnkove transformace se pak orezavaji  bitove vrstvy vzeslych koeficientu (neni to tedy jako u DCT, kde je empiricky vznikla kvantizacni matice - jeji vznik je spis carovani nez nejaka veda, pomoci ktere se koeficienty deli), coz se sice snadno provadi, ale mnohem hur ridi, protoze neni zas tak snadne predpovedet, jak ustrizeni jedne bitove vrstvy ovlivni dekodovany obraz. A dekodovat na zkousku je prave u vlnkove transformace narocnejsi na zdroje.

[Mandarinka]

A ještě jedna věc, Snow AFAIK nikdy nebyl psán s cílem vyhýbat se patentúm (Dirac byl). Byl/je to experimentální projekt.

[Grunt]

Byl/je to experimentální projekt.

Přesně, experiment jednoho, dvou lidí, který se moc nehýbe. A i když to nemůžu tvrdit s jistotou, tak je docela možné, že se fakt netrefil do něčeho v současné době živého. Pro kódování entropie např. používá rangecoder ze '79(vzhledem k tomu, že je v samostatné zdrojáku, předpokládám, že ho používá ještě někdo další), ale ve zdrojácích jsou zakomentovány části využívající CABAC. Kdo ví. Kdo by to chtěl zkoumat, může začít u doc/snow.txt.

[Jirka]

Existuje i implementace Rangecoderu o 20 let novejsi, nepouziva tu?

Ono se toho na kodovani entropie moc od tech 70. let nezmenilo. Zmeny vedou hlavne ke zrychleni. Ale zrovna kodovani entropie neni u kodovani videa nejak zvlast limitujici.

[Grunt]

Existuje i implementace Rangecoderu o 20 let novejsi, nepouziva tu?

IMHO na tom bude ležet ještě nějaký patent nebo bůhvíco. 20 let je málo:

* You should have received a copy of the GNU Lesser General Public
 * License along with FFmpeg; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
 */

/**
 * @file libavcodec/rangecoder.c
 * Range coder.
 * based upon
 *    "Range encoding: an algorithm for removing redundancy from a digitised
 *                     message.
 *     G. N. N. Martin                  Presented in March 1979 to the Video &
 *                                      Data Recording Conference,
 *     IBM UK Scientific Center         held in Southampton July 24-27 1979."
 *
 */

Ono se toho na kodovani entropie moc od tech 70. let nezmenilo. Zmeny vedou hlavne ke zrychleni. Ale zrovna kodovani entropie neni u kodovani videa nejak zvlast limitujici.

Monty by mohl u doušku VP3 povykládat.

[Jirka]

On nejspis vi, proc to kodovani entropie ve VP3 vypada tak, jak vypada. Pri navrhu se na to mysli az nakonec (svym zpusobem je to amaterismus, ale kazdy, kdo si zkousel napsat nejaky videokodek pro format dle vlastnich napadu, dopadl asi stejne). Nejprve je potreba pripravit poradna data. A aritmeticke kodovani se da docela hezky odhadovat (viz to odhadovane zlepseni az o 20 procent), takze pro potreby vyvoje toho opravdu esencialniho ve videokodeku je aritmeticke kodovani az na poslednim miste. Mluvim z vlastni zkusenosti, dopadl jsem kdysi stejne.

[Mandarinka]

 

Ale zrovna kodovani entropie neni u kodovani videa nejak zvlast limitujici.

Tak si u x264 srovnejte CAVLC a CABAC. Tam je zatracený rozdíl, 10-20% čistého zvýšení komprese beze ztráty kvality.

 

[Jirka]

Jenze spatne udelana predikce pohybu ma na vysledek mnohem fatalnejsi dopad.

CABAC sice produkuje kratsi kod, ale za cenu vyssi spotreby zdroju, coz je u mobilnich zarizeni velmi limitujici. Pak nastava otazka, zda-li to zkraceni kodu melo vubec smysl, jestli to bylo to, co jsme chteli opravdu zredukovat.

[Mandarinka]

Komprese je o ušetření místa, a tedy poskytnutí vyšší kvality při stejném datovém toku. H.265 půjde také cestou navyšování spotřeby, jak jinak. Co se týče mobilních přístrojů, tak prostě mají specializovanou elektroniku která si s CABACem hravě poradí...

Jinak i ten CAVLC není špatný (lepší než entropy coder v mpeg4 asp pokud si dobře pamatuju), zejména srovnáte-li si to s entropy coderem v mpeg2, jehož výstup je, jak jsem slyšel, úspěšně komprimovatelný pomocí LZMA (rofl).

[Jirka]

Ne nadarmo CABAC neni ve vsech profilech MPEG-4 AVC. Komprese je o usetreni mista. Ale ne za kazdou cenu. Jinak bychom misto DCT pouzivali KL.

Nevim, jake mas povedomi o mobilnich zarizenich, ale bojuje se v nich o kazdy miliwatt. Nejaka specializovana elektronika to v nich nezachrani. Dekodovani CABACu je o dost narocnejsi, sezere tedy vic elektriky a tim to pro prodejce takoveho zarizeni hasne. Je to pro nej nevyhodne. S radou, ze si do zarizeni ma strcit specialniho elektroniku, ho nevytrhnes.

No ano, CAVLC neni spatny, ale to je dano dobou vzniku implementace mpeg2, kdy si nemohli dovolit tam soupnout neco uspornejsiho, byt by to bylo znamo (jakoze bylo znamo leccos). V te dobe by to neslo prakticky dekodovat (ani kodovat).

[Kvakor]

Ono je to s animovaným videeom obecně špatné, protože běžné kodeky většinou používají kosinovou nebo vlnkovou tranformaci a těm se ostré přechody, kreslené obrysy a plochy obsahující jedinou barvu nelíbí. A vytvářet kodek pro anivomavné video by se nejspíš nevyplatilo, i když je možné, že by při použití originálního "čistého" vstupu mohl dosahovat úžasné kompresní poměry, například tím, že by objekty v obraze převáděl na vektory. Svým způsobem se to vlastně používá už dnes - ve flashových animacích.

[Grunt]

plochy obsahující jedinou barvu nelíbí

Ba naopak. U těch si to komprese na bázi vlnkové transformace jenom mlaská(o to víc si to ale také vybere u těch hran). A vlastně díky existenci DC koeficientů u kompresí na DCT také. Se vším ostatním ale jinak souhlas. On to ovšem není problém jen animovaného videa, ale tak videa obecně.

A vytvářet kodek pro anivomavné video by se nejspíš nevyplatilo, i když je možné, že by při použití originálního "čistého" vstupu mohl dosahovat úžasné kompresní poměry, například tím, že by objekty v obraze převáděl na vektory. Svým způsobem se to vlastně používá už dnes - ve flashových animacích.

A co nějaké filtry a lossless ffv1?

[Kvakor]

U těch si to komprese na bázi vlnkové transformace jenom mlaská

Nad jednobarevnou plochou si bude "mlaskat" i DCT (bude jí stačit jen DC koeficient), ale problém je hlavně v těch hranách - na jednobarevné ploše jsou nejvíc vidět artefakty.

[Grunt]

v těch hranách

Snad v přechodech, ne? U hran bude vidět šum a ringing artefact.

[xkucf03]

To by chtělo vektorový kodek, něco na způsob Flashe Koukat v tom pak na Simpsny by byla paráda

[Andrej Herceg]

Nemyslím si, že by také niečo produkovalo menšie súbory (a dekódovanie by pravdepodobne potrebovalo viac výkonu CPU a pamäte).

[Ladicek]

Proč ne? Připomíná mi to (jenom v principu) fraktálovou kompresi – až na to, že tady by se spíš hledaly nějaké křivky Ale možná je tenhle rozdíl větší, než bych naivně čekal.

[default]

Zredukuješ počet Anchorů užitím bezierovy křivky (nebo jiné). Holt by autoři nesměli používat Corel Draw.

[Mandarinka]

 

To by chtělo vektorový kodek, něco na způsob Flashe Koukat v tom pak na Simpsny by byla paráda

Ehm, ten kodek SVQ1 (VQ = vector quantization) je právě to. táhněte si ty vzorky a zapláčete.

 

[Grunt]

Příloha:

• vektory.png (85109 bytů)

No, nevim:

Each image is divided into a number of horizontal bands which have individual 256-color palettes transferred in the key images. Each band is subdivided into 4x4 pixel blocks. The compressor uses vector quantization to determine the one or two band palette colors which best match each block and encodes runs of blocks as either one color byte or two color bytes plus a 16-bit vector which determines which pixel gets which color, similarly to S3 Texture Compression.

To moc nevypadá na vektory v obraze(viz. příloha).

[Mandarinka]

Mrkněte se na ten vzoreg SVQ1. Místy je krásně vidět, zejména na barvené složce (na kterou očividně nezbýval prostor), že to rekonstruuje obraz ze různě velkých čtyřúhelníků. Někdy velice, velice velkých.

No jen se na tu hrůzu podívejte. Jasně, je to prastará mizerná implementace, ale ukazuje to, proč se od této techniky přešlo k transformacím. Asi to stálo za pikaču i u animace, ve které to zrovna dosahovalo pro sebe nejlepší výsledky.

[Grunt]

Příloha:

• snapshot20090812125001-YCbCr_ITU_R470.png (7841 bytů)

Aha, už jsem to asi pochopil. Tak to ale není vektorový formát určitě ale jen jakési rádoby.

[Mandarinka]

No jo, jasně že je to prastará rachotina, ale oni asi na tu větev vývoje všichni tak nějak rezignovali. Dost pochbuju, že by to dnes mělo šanci. Vermte si, že normální kodek uloží ve vysoké kvalitě klíčový snímek a pak profituje z toho, že na něj odkazuje. To je pro vektorový formát o dost těžší, protože dosáhnout nějaké vyšší kvality stojí jeho technikou čím dál víc dat.

Myslím také, že potenciální výhody vektorové techniky jsou v dnešních kodecích nahrazeny intra predikcí...

[Grunt]

Ale jo. Ono by se ještě dalo lecos vymyslet.(Bohužel je to bůhvíjak staré a Research links už bohužel nefungují)

[xkucf03]

Ale to je něco jiného, než jsem myslel – tohle video pravděpodobně vzniklo tak, že z původně vektorové animace se vyrenderovalo nevektorové video a to se následně někdo snažil zkomprimovat zpětným převedením na vektory. Když jsem psal „něco jako Flash“, tak jsem tím myslel to, že by se ta animace vzala rovnou z toho animačního programu, ve kterém ji vytvořili, a převedla se na nějaký vektorový formát, ve kterém by se dále šířila (analogie u Flashe: převod z .FLA na .SWF).

[Mandarinka]

To zdorjové video není vektorové - pozadí jsou buďto rendery nebo ruční kresba, postavičky jsou dělané s tabletem, ale ručně... jaseně že to pak šlo na DVD, ale komprese byla velmi málo destruktivní... co ten kodek v testu dělal je skutečně vektorová kvantizace. No, ne že bych do toho viděl, ale dokážu si představit proč to stojí za pokémona :)

[Jirka]

Krasa modernich formatu videa je v tom, ze jejich kodeky lze casem vyladovat. Format nerika, jak se ma dospet ke kodu, jen jak ten kod ma vypadat. Treba MPEG-2 kodery produkuji dneska pri stejnem bitrate o tolik lepsi kod nez v dobe vzniku prvni referencni implementace, ze je to az neuveritelne. Nekdy to pripomina carovani (ze >>rceni<< "formatu je jedno, kde si koder ten kod vezme, at si ho treba vycaruje"). Samozrejme dobry format musi byt dobre navrzen, aby vubec melo smysl pro nej delat kodeky.

[Petr Tomášek]

Au, co je to za blbost: Thusnelda (ffmpeg2theora)? Proč nepoužil oficiální encoder?

Zřejmě to "srovnání" asi bude pěkný FUD...