1. uvedené hodnoty DCT jsou rozdíl mezi originálem a komprimovaným videem, ideálně bude nulový, což znamená, že zůstalo stejně detailů jako v originále. Čím méně skáče v čase, tedy je křivka DCT hladší, tím lépe, protože dochází k malým změnám ve ztrátě detailů ­- pokud jsou velké, tak se to projevuje tím, že je chvíli obraz pěkný a detailní, ale pak se náhle změní ­- rozostří, zablokuje apod.

2. Ano, H264 je MPEG­-4 AVC

Trocu teorie ­- MKV je stejně jako třeba AVI jen kontejner, který obsahuje zvuk, video, titulky aj. Haali media splitter umí ­"otevřít­" ­/mj.­) MKV kontejner, ale stejně jako u AVI potřebuješ potřebný kodek, který dané video dekóduje. Takže já bych si v Mediainfo http:­/­/mediainfo.sourceforge.net­/cs zjistil, o jaký kodek jde a ten si sehnal.

Já jenom doplním, že nepotřebuješ kodek, ale DirectShow filtr, konkrétně dekodér. Pro přehrání každého videa potřebuješ minimálni tři různé filtry ­- splitter, dekodér videa a dekodér zvuku. Evidentně máš splitter ­(Haali­), dekodér zvuku a chybí Ti dekodér videa. Napravíš to nainstalováním ffdshow, což je filtr, který umí dekódovat skoro všechny existující komprese videa.

Víc se dozvíš v mym článku ­- http:­/­/jech.webz.cz­/multimedia.php ­- pokud máš zájem.

Dekuji za inforamce.
Koukal jsem se VideoInspectorem na .mkv soubor ktery chci prehrat a video je kodovano kodekem MPEG 4 ISO Advanced. Mohli by jste mi doporucit jaky kodek tedy stahnout?
ffdshow znam, pouzivat ale nehci, mam rad kdyz vim co vsechno mam v systemu nainstalovano, tedy preferuji samostatne kodeky.

ffdshow je jeden samostatný program, není to žádný balík kodeků a filtrů. Navíc má vynikající možnosti povolovat a zakazovat dekódování jednotlivých formátů. Je to jediný zdarma dostupný filtr, který umí dekódovat MPEG­-4 Advanced Video Coding ­(= MPEG­-4 AVC = H.264­). Pokud by ses chtěl vyhnout ffdshow ­( i když opravdu nevidím žádný důvod proč­), máš možnost zakoupit CoreAVC, Elecard H.264 nebo Cyberlink H.264.

Pokud nechceš, aby ffdshow dekódovalo jiné formáty, můžeš ho nainstalovat s podporou pouze pro MPEG­-4 AVC. Do ostatních videí se nebude montovat. U ffdshow se opravdu nemáš čeho bát.

A ještě poznámka k terminlogii ­- rozlišuj pojmy kodek, dekodér, filtr a formát. Například to Tvé video nebylo komprimované žádným MPEG­-4 ISO kodekem ­(nic takového neexistuje­), ale dal bych ruku do ohně, že to bylo komprimované x264 enkodérem ­(viz. testy­). K přehrání nepotřebuješ kodek, ale dekodér, což jeden z druhů filtrů. Ostatně žádný kodek ­(v původním smyslu slova­) pro formát MPEG­-4 AVC ani neexistuje. x264 umí AVC jenom komprimovat a libavcodec ­(ffdshow­) to umí zase jenom dekomprimovat.

V kontejneru Matroška už se upustilo od značení, jakým kodekem bylo video zkomprimované ­(tak jak to dělá AVI nebo ASF­), ale označuje se formát, což je správné a smysluplné. Takže pokud budeš mít třeba v MKV video zkomprimované DivXem nebo XviDem, bude označené jako ISO MPEG­-4 ASP a nemáš šanci poznat, který z těch kodeků se pro kompresi použil. A kormě těchhle dvou to klidně ještě mohl být 3ivX, Nero Digital ASP nebo libavcodec.

Vyborne, to jsem potreboval vedet.
Jeste se zeptam jaky decoder je celkove nejlepsi, jaky by jste mi doporucil ­- CoreAVC, Elecard H.264, Cyberlink H.264.. ­(bez ohledu na cenu­)?

To záleží na Vaší konfiguraci. CoreAVC je nejrychlejší softwerový dekodér. Pokud máte dobrou grafickou kartu, tak bych použil Cyberlink H.264 ­(je bundlovaný také k nejdražší verzi PowerDVD 7.3­). S Elecardem nemám žádné osobní zkušenosti. Tyhle dva ale fungují dobře a spolehlivě. Volba závisí na tom, jestli máte grafickou kartu schopnou akcelerovat dekódování. Používat Cyberlink na SW dekódování je téměř nemožné kvůli jeho nízké rychlosti.

Porovnání Mainconcept vs. x264 je v tom odkaze na MSU, jak sem dával o post výš br4n0

Ani VP7 není MPEG4, podle toho, co jsme četl.

WMV je kodek zalozeny na MPEG­-4, ne ze je to MPEG­-4. Plati to uz od WMV4, WMV7, WMV8 i pro WMV9, je to jen evoluce stejna, jako je u DivX. Take pro jeho dekodovani vetsinou staci MPEG­-4 dekoder, pouze upraveny ­(proto lze prehrat na Linuxu­). A VC­-1 = WMV9, Microsoft protlacil ten svuj WMV9 jako standard a nazyva se VC­-1, protoze WMV by mu tezko proslo, neni to naopak. Je to jen dalsi dukaz moci Microsoftu delat si sve vlastni standardy.

MPEG­-2 prijde na radu take vcetne jmenovanych, na radu prijde i HD video.

Miku myslím si, že tady nemáš pravdu. Microsoft kdysi stvořil kodek, který se pokoušel být ISO MPEG­-4 SP kompatibilní, ale nebyl. Vznikl MS MPEG4v3, ze kterého bych následně stvořen DivX 3.11. Potom Microsoft opustil jakoukoliv snahu držet se MPEG­-4 ASP standardu a stvořil WMV1, WMV2 a WMV3 ­(číslovaný taky 7, 8 a 9 podle verzí WMP­). To, že libavcodec umí dekódovat WMV, je zásluha reverzního inženýrství vývojářů ffmpegu. WMV3 je rozumně podporovaný až od zveřejnění VC­-1 specifikace. A prokládaný VC­-1 ­(WMV3­) libavcodec stejně pořád nezvládne.

Současný postoj Microsoftu je takový, že VC­-1 vs. WMV3 je jako MPEG­-4 ASP vs. DivX nebo MPEG­-4 AVC vs. x264. Tedy VC­-1 je standard a WMV9 je jedna z jeho konkrétních implementací. Spolu s WMP 11 Microsoft dodává WMV Advanced Profile kodek, který už nemá 4CC WMV3, ale používá WVC1. Lze jej přehrát pouze pomocí WMP 11 nebo libavcodecu ­(ffdshow­). Není to prostě ten samý kodek jako WMV3­/9 dodávaný s WMP 9, který jsi zřejmě testoval. Oba se samozřejmě vejdou do VC­-1 specifikace. Stejně jako se do MPEG­-4 ASP sepcifikace vejdou DivX 4, XviD i DivX 6.

Myslím si, že VC­-1 nemá k MPEG­-4 ­(máš na mysli ASP nebo AVC?­) o nic blíž než MPEG­-2. Algoritmy a metody jako DCT nebo I­/P­/B­-frames používají snad všechny současný formáty. To není žádná výsada MPEG­-4. Dle mého je za prvé nutné důsledně rozlišovat ASP a AVC. Jsou to dva dost odlišné a vzájemně nekompatibilní formáty. Za druhé bych jako MPEG­-4 kodek bych nazýval pozue ty, které odpoovídají jednomu ze zmíněných ISO standardů. Jinak v tom uděláš lidem zmatek.

P.S. Myslím si, že motiv k přejmenování WMV3­/9 na VC­-1 byl vyhnout se patentům, které MS ve svém kodeku zneužívá. Paradoxně několik z těch patentů vlastní MPEG LA. MS zase prý má jeden patent na MPEG­-4 AVC.

Já kdysi používal bitrate=4000:frameref=6:bframes=8:b_adapt:b_pyramid:weight_b:8x8dct:
me­=umh:subq=6:chroma_me:mixed_refs:trellis=2:brdo:bime:nofast_pskip:
di­rect_pred=auto:nr=0:qcomp=0.7:partitions=all­"

Podle navodu tato nastaveni jiz prilis nepridavaji, ale kdyz jinak nedate, tak ten druhy dil jeste jednou prekomprimuju, i kdyz uz to mam hotovy ;(

Dekuji :­) ja osobne pro x264 pouzivam vyborne MeGUI, kde je vetsina prepinacu vybavena napovedou + ctu wiki a podobne stranky, kde to je dopodrobna vysvetlene. Dane nastaveni, ktere jsem sem hodil, mi pridukuje skutecne spickove vysledky. diky za vasi praci, byl to vyborny test!

Technicky vzato máš 2 možnosti ­- použít vfw verzi x264, a pak je postup jednoduchý ­(viz nějaké návody x264 a VirtualDub­), ale pokud vím, tak na vfw verzi se už nějaký pátek nepracuje, takže bych ji ani nedoporučoval.
Takže zbývá CLI ­(command line interface­) verze, kde se ale prakticky bez AVS skriptů. Tedy nezbyde než napsat jednoduchý skript, případně používat GUI jako třeba MeGUI, StaxRip, kde je lecos zautomatizované ­- už nějakou dobu s nimi nepracuju, takže možná umí vytvořit skripty automaticky. Případně lze použít x264 z příkazové řádky nebo MEncoder, který není náročný na vstupní formát.
Něco o x264 je třeba tady:
http:­/­/jech.webz.cz­/x264.php
http:­/­/iqtiqe.info­/x264.html
Jinak doporučuju zkusit najít něco o MeGUI nebo StaxRip.

Děkuji za odkazy. x264 jsem zkoušel poprvé dnes v AVIdemuxu, ale nechtěl mi dodržet cílovou velikost na 700MB a stále mi z 1.3GB videa dělal 1.2GB soubory. Tlačil mne čas a tak jsem použil Xvid s tím, že se na problematiku mrknu později. A co čert nechtěl, vyšlo pokračování ­(vlastně 1.díl­) tohoto článku. :­) Prozatím jsem prošel tebou postlé odkazy na návody a jsou přesně tím co potřebuji.
Na http:­/­/deaththesheep.uni.cc­/ jsem našel vfw verzi x264, vypadající, že je opět ve vývoji. Jelikož je tato problematika pro mne nová, požádám o radu. Je tato vfw verze stejně kvalitní jako CLI, nebo prozatím dohání zpoždění dané pauzou ve vývoji ? Bohužel mi informace ­"x264 core updated to svn­-721­" vůbec nic neříká.

PS: Děkuji autorovi za skvělý článek. Musel dát spoustu práce. Jak metodika, tak i toto pokračování..

721 svn je asi 10 stará aktualizace, vypadá to, že se na vfw vrhnul někdo další, takže rozdíl mezi CLI by být neměl.
Jen to, prosím, necpi do AVI kontejneru.

Jenže z VfW kodeku dostaneš jedině AVI. Chce to potom převést na něco rozumnýho, například MP4 nebo MKV. Do MKV to umí přímo z AVI MKVToolnix.

tak už jsem to zkusil, návod je srozumitelný, ale má to jednu chybu furt mi to při otevření skriptu hlásí chybu: UNABLE TO LOAD D2V FILE. Nevíte co s tím?

O jakem postupu mluvis? Mem nebo Vladovo? A kdy konkrétně se chyba vyskytne? Předpokládám, že při otevírání AVS skriptu, nebo se pletu?

Wolfalack> Asi bude nějaká chyba ve skriptu. Napiš, jak Tvůj skript vypadá.

Já používám Avideemux, jeho použití je zcela triviální.

Jo, to srovnání různých rozlišení a i těch různých typů filmů je výborný nápad, to bych tak bral. :­-)

Testovat jiný rozlišení zase až tak dobrý nápad není. Výsledky budou úplně stejný, akorát se posunou hodnoty bitrate pro dosažení stejný kvality. Ten posun bude samozřejmě přímo úměrný navíšení počtu pixelů. Takový test by tedy neřekl vůbec nic nového.

Ano, v rámci jednoho kodeku bude patrně lineární nárůst potřebné bitrate ­(při zachování kvality­), ale podle mě srovnání kompresibility různých kodeků při různých rozlišení bude hrát do karet AVC kodekům, které používají propracovanější výpočty, takže bude markantnější rozdíl mezi AVC a ASP kodeky oproti nižším rozlišením. Jinak řečeno, zajímá mě, jak velký bude propad mezi AVC­/ASP kodeky.

Já si myslím, že ne. Kodeky pracují na 8x8 nebo 16x16 makroblocích. V podstatě komprese HD videa spočívá v tom, že vedle sebe poskládáš 4 SD videa. Nečekal bych žádný rozdíly.

A právě o to mi jde ­- AVC můžou na rozdíl od ASP použít i 16x8, 8x4, 4x4 makrobloky, jemnější je i DCT transformace a našly by se i další věci. Jde mi o obecné srovnání ASP­/AVC, které bude markantější u HD videa. A jestli ne, tak se pletu ­- to ukáže právě ono porovnání.

Schvalne jsem toto nezahrnoval do testu, protoze zalezi i na tom, jaky mod se zvoli a podobne. Napr. malokdo u DivX pouziva Insane kvalitu apod. Planuji test rychlosti samostatne, pouze s jednim bitrate, ale otestovat vsechny druhy kvality, coz bude uzitecnejsi

Možná, ale já například prakticky nic jiného než insane nepoužívám. Ať si dvojjádro užije.

P.S. Mimochodem, DivX mi i při nejbrutálnějším nastavení nedokáže procesor zatížit naplno, což mě trochu mrzí. Sice mi systém reaguje docela svižně, ale klidně bych to obětoval za rychlejší zpracování.

Naprogramovat neco, co na jeden ukol vytizi vice procesoru na 100% temer nejde, vzdy bude jeden na druhy onekdy cekat, na to si musime zvyknout. X264 to taky nedokaze

U toho DivX jsem si toho taky všimnul. Právě že tam nejde o to, že jedno jádro by běželo na 100% a to druhé na něj čekalo, ale obě jádra jedou prakticky shodně na 80%.

To ale neznamena, ze tak jedou vlakna programu, Windows prideluji praci procesorum jak se jim to zlibi ­- vytizeni obou jader stejne je jedna z metod multiprocessingu ­(symetricky­), dokonce i jedno vlakno muze zatizit dve jadra na 25% a dohromady na 50%

x264 dokaze pri manulanim nastaveni threadu vytizit jadra temer na 100% a to i quadcore, na rozdil od ostatnich kodeku. XviD a DivX dokazi vyuzit sotva dvoujadro, VP7 ani to ne. Ve vysledku to vypada tak, ze rychlost na 4jadre x264 s brutalnim nastavenim je temer shodna s rychlosti treba XviDu, ale kvalita je trosku jinde, hlavne pri nizsich biteratech. Take by bylo dobre sovnat x264 s ruznym nastavenim deblock filtru, napr. na standardni nastaveni 0,0 trochu nici detaily, ale zase vyborne potlacuje mensi az stredni sum, ­-1,­-1 je uz trosku lepsi, co se detailu tyce. U HD ripu pouzivam nekdy az ­-3,­-3. Takteze napr. rychlost x264 je relativne vysoka na viceajdrech i pri brutalnim nastaveni, coz u treba u VP7 je naprosto nemozne, proto vidim pouziti VP7 spise pro komercni ucely, kde je zrejme pouzita jina ­(podstatne lepsi verze­).

Ale mel to o prsa :)

Jo to sice jo, ale je hlavně zdarma a stále vy vývoji, což je myslím hodně důležité. Jednoduše x264 je budoucnost kódování videa. BTW: cca. 99% HD videa je v x264, což o něčem vypovídá.

U dalsiho testu obrazky budou
S temi grafy zkusim take neco udelat, nechal jsem vsechny se stejnym rozsahem, aby to bylo lepe porovnatelne, ale u tech ruznych bitrate by to asi chtelo roztahnout

Obrázky, nebop jiné vzorky by být měly, protože pak se nedá posoudit, jestli je kodek dobrý jen v PSNR, nebo jestli má teky pěkný obraz...

A hlavně by měly být název vzorku! Aby se daly výsledky ověřit a zhodnotit. Jak známo, testy můžou v závislosti na vstupním materiálu dopadnout různě. BTW ­- podle toho popisu by to mohla být Princezna Mononoke? Dělal jsem si na ní totiž něco podobného :­)

Nero AVC je prý dobrý kodek, a dá se 30 dní zadarmo zkoušet ­- aplikace Nero Recode. Osobně si mylsím, že vyzkoušet Mainconcept a Elecard by bylo zajímavější, ale jinak jsem zase nečekal výsledky VP7 ­- dobže, že jste ho zařadili.

No, snad se příště podobných chyb vyvarujete.

Možno trochu náročná požiadavka, ale ideálne by bolo, keby boli porovnávané len P alebo len B­-snímky. Inak sa znižuje ­"objektívnosť­" vizuálneho porovnania. Mnohé testy túto skutočnosť ignorujú.