{Benda_11} Rotating Header Image

Fuwa Fuwa Time – Hi10p

Dřív k přehrávání videí jsem používal balík kodeků s názvem CCCP, jelikož jsem měl s K-Lite špatné zkušenosti. (Tenkrát lidi z K-lite vydávali opravdu ne moc vyhovující balík kodeků.) Byl jsem s ním hodně moc spokojen do doby než co přišel pozvolný nástup první verze h264. H264 byla tenkrát moc náročná a moje stařičká mašina ji tak tak dávala. To anime ještě nehýřili 720p a proto jsem vše relativně utáhl. Avšak pak přišel veliký boom. Já toužící po větší kvalitě jsem stahoval lepší releasy, bohužel jsem některé z nich nedokázal vůbec přehrát. A tak jsem se začal šťourat v kodekách.

K mému údivu jsem zjistil, že CCCP je ohromující balík pro všechny lamy, co hýří výkoným počítačem a nevědí, co s výkonem. CCCP pro dekódování videa používá filtr s názvem ffdshow. Je dobrý, přehrajete na něm úplně vše, až na *.mov a *.rmvb, ale tyto formáty, stejně už skoro nikdo nepoužívá. Bohužel jako daň si bere velikou zátěž na CPU. K žádným výpočtům nepoužívá grafickou kartu a vše se snaží naemulovat přes procesor, což pro stařičkou mašinu, jako jsem měl, nebylo vyhovující. (Ale tohle vše jsem zjistil až mnohem mnohem později.) Ale nevěděl jsem na co přejít. Pak jsem objevil zázrak s názvem CoreAVC pro lowend PC. Dokázal jsem na tom rozběhat snad úplně všechny videa v H264 bez jakéhokoliv trhání. A to mě zase na nějakou chvíli uklidnilo po honbou za jinými kodeky.

S příchodem notebooku, CCCP bylo nevyhovující a CoreAVC opět nějak nestíhal, jelikož se na světě objevili již další revize H264, kterou CoreAVC nedokázal přehrát, nebo alespoň s velikými záseky. Což mě opět přinutilo, že takhle by to dál nešlo. To jsem ještě do té doby používal KMPlayer. Po doporučení od mJezdce ať přejdu na K-lite pack, jsem z počátku dlouho odolával a snažil jsem se najít jinou alternativu. Avšak marně a bez úspěchu. Z počátku to byl veliký nezvyk přecházet z CCCP na K-Lite a z KMPlayeru na MPC-HC. Avšak za nějaký čas jsem si zvykl. S přechodem na MPC-HC jsem zjistil další věc. MPC-HC používá technologii s názvem DXVA. A při srovnávacích testech jsem se až divil, jak jsem byl blbí a zaostalí a nepřešel jsem už tenkrát. DXVA veškeré video žene přes grafickou kartu a procesor zatěžuje minimálně, tím se dosahuje v podstatě lepších a rychlejších výsledků pro přehrávání videa. Ovšem ne každý si tenkrát mohl dovolit na DXVA přejít. Ten je podporující až od grafických karet nVidia GeForce 8xxx/9xxx, to protože tyto karty disponují obvody pro nativní dekódování H264 bez nějakých složitých výpočtů.

A až do teď jsem žil s K-lite, u kterého využívám ostatní kodeky pro přehrávání jiných videí než jsou v H264. Na H264 mám DXVA v MPC-HC. Jenomže už tomu je měsíc co vyšla nová verze H264. Někdy označována jako 10bitová, do teď se využívá 8bitová H264, a nebo také označována jako Hi10p. V čem je lepší? Jednoduše řečeno, při stejném biteratu a rozlišení u 8bitové verze dostanete větší velikost než u 10bitové verze. Někde se velikost může lišit až o 50%. Jinak také řečeno, že při zachování stejné velikosti dosáhnete u 10bitové H264 lepší kvality, jelikož u ní navýšíte buď rozlišení a nebo biterate.

Avšak máme tu jedno veliké ALE! Hi10p se přednedávnem dostalo ven v podobě enkóderu, avšak současné dekódery s ní mají problém. Buď vytíží procesor na maximum a nebo video přehrají s kostičkama. Což je právě onen problém u DXVA. Video přehraje bez nějakých problému na zátěž procesoru a nebo grafické karty, avšak video místy kostičkuje. Říkal jsem si, že to nebudu hrotit, videí v Hi10p tolik není a určitě to nebude mít raketový vzestup a v klidu si počkám až vyjde updatovaná DXVA. Avšak záhy přišlo veliké zděšení. Většina anglických fansuberských skupin plánuje na podzimní sezónu roku 2011 přejít kompletně na Hi10p a starou verzi H264 nadobro opustit. A tak jsem se začal shánět po nečem, co by mě bez nějakých potíží dokázalo přehrát správně Hi10p.

CCCP i K-lite vydali nové verze ve kterých podporují Hi10p. Při podrobném prozkoumání zjišťuju, že dekódování Hi10p zpracovává ffdshow. Bohužel z předešlých zkušeností vím, že ffdshow není moc efektivní a tak jsem na použití této možnosti zanevřel. Tady jsem našel podrobný návod jak zprovoznit správné přehrávání Hi10p. Si říkám, že bych to mohl vyzkoušet. Stáhnu madVR, přes jednoduchý *.bat soubor zaregistruju filtr a v MPC-HC (32bitové verzi!) ho zkusím do přehrávače připojit. Udělám vše dle návodu a zkusím přehrát jedno obyčejné video v 720p, který ani moc neoplývá biteratem. Po spuštění videa jsem si vychvaloval jak to nádherně běží, avšak moje radost nevydržela dlouho. Noťas začal najednou moc topit a větrák se rozjel naplno. Si říkám co se děje. Kouknu na vytížení. CPU se pohybovalo od 95% do 100% vytížení. Tak jsem si řekl, že takhle by to nešlo. Radči oželím kvalitu v DXVA na úkor vysokého zatížení CPU a zbytečnému zahřívání notebooku. Tak jsem madVR odinstaloval.

Marně a netrpělivě jsem vyhlížel nový příchod DXVA s podporou Hi10p. Až mě to nedalo a začal jsem dále hledat, až jsem možná dočasně našel řešení.

Jak dočasně zprovoznit na windows Hi10p bez madVR a s minimální zátěží na CPU, do té doby než co vyjde nová verze DXVA

Na jednom zapadlém čínském fóru jsem našel link na projekt na googlu se jménem LAVFilters. Ten stáhneme (já volil bez instalační metodu v podobě zip 32bitovou verzi) a rozbalíme do následujícího adresáře: „c:\Program Files (x86)\LAVFilters\“. Uvnitř složky vyhledáme soubor s názvem „install_video.bat“. Tento soubor spustíme a vyčkáme, než co se zobrazí hláška o úspěšném zaregistrování. Viz obr.

Otevřeme si MPC-HC (32bit). Dále v MPC-HC vlezeme do nastavení a přepneme se na záložku Externí filtry. Tam klikneme na tlačítko přidat a vyhledáme „LAV video decoder“. Filtr přidáme a nastavíme mu prioritu na upřednostňovat. Viz obr.

Pak už stačí jen spustit nějaké video v Hi10p. Zatížení je oproti madVR až o 50% menší! Moje vytížení CPU se pohybuje okolo 44% až 50%. Což je hodně vyhovující, avšak na DXVA to stále nemá, kdy mám maximální vytížení CPU u videa 6%.

Proč jsem volil 32bitovou verzi?
Má to jednoduchý důvod… Já jako primární přehrávač používám MPC-HC 64bit, kde mám defaultně nastavený DXVA. Takže prozatím u většiny videí s 8bitovou H264 nepotřebuju využívat LAVFilters, protože zatížení je i u téhle staré verze H264 stále stejné jako u nové a proto se mě vyplatí to dekódovat přes DXVA. Když narazím na video v Hi10p, tak si už otevřu MPC-HC 32bit a v něm oné video spustím.

Vytížení CPU:

A nakonec dva porovnávací obrázky Hi10p. První je dekódován pomocí LAVFilters a druhý pomocí DXVA.


Good luck při honbě za Hi10p.

Podobné články:

  1. Fuwa Fuwa Time – Válka kontejnerů
  2. Fuwa Fuwa Time – Těžké začátky enkódera
  3. Fuwa Fuwa Time – Enkód
  4. Fuwa Fuwa Time – Anime 2010 až 2011
  5. Fuwa Fuwa Time – Daicon
NejhoršíUjde toPrůměrSkvěléNejlepší
Loading ... Loading ...

7 komentářů

  1. avatar Tigr napsal:

    Jednoduše řečeno, při stejném biteratu a rozlišení u 8bitové verze dostanete větší velikost než u 10bitové verze. Někde se velikost může lišit až o 50%.

    Při stejném bitrate bude mít 10bitová verze poloviční velikost? Tak to je buď vážný bug v x264, anebo právě vymysleli perpetuum mobile :-)

  2. avatar Benda_11 napsal:

    tigr: Mno i Morita-san, která má na délku 3minuty to skoro odpovídá.

    Třeba CG teď předělávali enkód v 1080p a nahazovalo se to na BakaBT. Bohužel si nevzpomenu co to bylo za anime. Jejich verze v Hi10p měla 11GB, kdežto u 8bit H264 to přesahovalo 18GB. Rozdíl je tam hodně patrný. Ale je možný, že se i ořezávalo na biteratu, nestudoval jsem podrobně enkódy, co jsou konkrétně zač.

    Těch skoro 50% dosáhneš u velmi krátkých videí.

    Ale pravda u klasických vycházejích anime v 720p vidím rozdíl max o 100MB, ale nezkoumal jsem, co je pod kapotou jednotlivých videí u 10bit (230MB) a 8bit (přes 330MB).

  3. avatar Tigr napsal:

    Ano, ale má výtka se netýká efektivity ukládání videa v Hi10P. Samozřejmě, že je příznivější. Jde mi o to, že pokud mají dva enkódy jednoho zdroje stejný bitrate po enkódování, není možné, aby jeden byl o polovinu menší (bitrate = datový objem / čas) – a pokud je chci enkódovat na stejný bitrate (tj. žádné CRF, ale klasický ABR mód), tak mi s toho s největší pravděpodobností také vylezou dva víceméně stejné soubory, ať už budou kvalitativní nastavení jakákoliv (tím zadaným bitrate mu přeci říkám, jak má ten soubor být velký). Ten Hi10P bude hezčí, protože je to místo využito efektivněji.

  4. avatar Benda_11 napsal:

    Tigr: Mno teoreticky je to možné, proč by to možné nebylo? Vem si rozdíl mezi DivX/xVid a H264. Už od pohledu dostaneš jinou velkost a to samé platí u 10bit a 8bit H264. Zkus se na 10bit H264 koukat jako na úplně nový kodek, který nemá nic společného s H264. A pochopíš…
    Laicky řečeno, když vezmeš 8bit H264 a pole o velikosti 8×8 a uložíš danou informaci do předem stanovené velikostní přihrádky, tak potřebuješ uložit nějaké množství informací.
    A když si vezmeš 10bit H264 a pole o velikosti 10×10 a uložíš danou informaci do stejně veliké přihrádky jako u 8bit H264, tak je jasné, že těch přihrádek bude potřeba méně => menší velikost souboru.
    Laicky řečeno, samozřejmě, že to tam funguje jinak. :)

  5. avatar Tigr napsal:

    Když vezmu 8bit enkodér H.264, dám mu jeden snímek videa a řeknu, ať mi z toho udělá 100KB soubor, dostanu ~100KB soubor. Když vezmu 10bit enkodér a řeknu mu to samé, zase dostanu ~100KB soubor (pravděpodobně „hezčí“, ale stejně veliký, plus mínus jednotky procenta). Skutečnost, že Hi10P „má něco společného“ s H.264, je naopak zásadní – DivX a spol. klidně mine cílový bitrate o desítky procent, protože na rozdíl od H.264 má jeho kvantizér výrazně menší manévrovací prostor.

    Můžeš si to ověřit sám: x264_8bit --bitrate 1000 -o 8bit.mp4 zdroj.mp4 a
    x264_10bit --bitrate 1000 -o 10bit.mp4 zdroj.mp4, binárky jsou na x264.nl. Ve zběžném testu mi vyšel bitrate 1024, resp. 1025 Kbps (tj. rozdíl mezi 8bit a 10bit asi 0,1 %). Pokud se ti na nějakém normálním videu podaří dosáhnout toho, že ta druhá verze bude o desítky procent menší, tak dej vědět :-)

    Jinak také řečeno, že při zachování stejné velikosti dosáhnete u 10bitové H264 lepší kvality, jelikož u ní navýšíte buď rozlišení a nebo biterate.

    Při zachování stejného datového objemu dosáhnete u Hi10P lepší kvality: (1) můžete zvýšit rozlišení obrazu při zachování stejné kvality obrazu (míry kompresních artefaktů), nebo (2) nechat rozlišení stejné, ale zvýšit kvalitu obrazu (méně artefaktů). Třetí možnost je zachovat rozlišení i míru artefaktů, ale zmenšit datový objem.

    Tohle jsi měl zřejmě na mysli, a to je taky úplná pravda :-) Jde mi jen o tu poněkud haluzovou formulaci, že při zachování stejné velikosti [výstupního souboru] zvětším bitrate (bitrate je funkce času a datového objemu, takže když je délka klipu stejná a velikost enkódu taky, nelze s bitratem hýbat, protože je to konkrétní číslo velikost enkódu / délka klipu).

  6. avatar Benda_11 napsal:

    Pro laika jako jsem já stačí jednoduché pravidlo. Hi10p = lepší kvalita, menší datový objem (MiB) a to mě stačí… Teda pokud enkódeři nebudou prasata a nebudou enkódy v Hi10p rvát do nebeských výšin, kdy výsledný soubor bude ještě n krát větší než u předešlé verze H264.

  7. avatar Maartyl napsal:

    Mnohokrát děkuji!! Vytížení mám +-10% a žádné čtverečky! Skvělé! (používám KMPlayer)

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *

*

Můžete používat následující HTML značky a atributy: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>