Crystal HD – HD video v malém balení (diskuse)

[Petr]

XBMC jako Xbox Media Center, nikoli XMBC

[Luboš Doležel (Doli)]

Díky.

[vadimo]

Napadla ma taká zaujímavá vec. Kedže nemám vo svojom asuse 2x miniPCI, bolo by možné ju vymeniť za WiFi kartu?

[Kvakor]

Pokud se tam vejde, tak po hardwarové stránce by tomu nic bránit nemělo. Softwarová stránka může být horší - setkal jsem se s notebookem, u ktereho se BIOS nevyrovnal s neexistencí modemu (bylo nutné modem vrátit a zakázat v BIOSu), Thinkpady zas nechtějí nepodporované WiFi karty (také se dá obejít úpravou BIOSu) a kdo ví, co všechno si různí výrobci ještě vymysleli.

Doporučuju na zkoušku původní kartu vyndat a pokud notebook vesele nabootuje i bez ní, je dost slušná pravděpodobnost, že to bude fungovat. Pokud naběhne i s jinou MiniPCI kartou, tak je to už téměř jistota, ale chtělo by to něco, co není síťová karta (Network/Ethernet Controler), např. modem nebo modem/bluetooth kombo.

[Lazar]

Pozn. Jde snad o miniPCIe karty, nikoli miniPCI.

Zde jsou mé dnes již zastaralé poznatky z pokusů s BCM70012 (10/2009). http://extrahardware.cnews.cz/forum/viewtopic.php?f=4&t=653&start=1350#p134046

Novější s BCM70015 (11/2010) http://extrahardware.cnews.cz/forum/viewtopic.php?f=4&t=653&p=219321&hilit=BCM70015#p219321

[lnx]

Tahle karta přinese víc problémů a starostí než užitku. V době dnešních výkonů cpu a gpu je hw dekodér k ničemu.

[Grunt]

V době dnešních výkonů cpu a gpu je hw dekodér k ničemu.

Ámen.

[Tomás Kaluza]

No ani tak ne. Já ji používám na netbooku a je tam hodně znát. Dokáže ji využít totiž i Flash. Nemůžu si jí vynachválit!

[deafboy]

Zrovna mam ten lacnejsi kus objednany. Planujem ho instlaovat do Apple TV kde nasadim XBMC :)

[Mandarinka]

Hold kdo koupí takovej bazmek jako je jmenovaný kšunt...

Mimochodem, je někde zdokumentováno, kolik reference frames to při těch 1920x1088 (1920x1080 by mělo být funkčně identické) zvládá? (Maximum co můžete potkat v pirátských vodách je 16.)

[Mandarinka]

Hmm, tak jsem se díval a zdá se, že limit odpovídá výrobcem inzerovanému HP L4.1, což je IIRC as 9 pro 1280x720 a 4 pro 1920x1080. Takže stahovačům doporučuju sosat věci u kterých je avizovaná kompatibilita s dxva.

[Jan Grmela]

Bohužel velká část výrobců notebooků vybavuje BIOSy whitelistem povolených karet – ten ale jde u mnoha modelů zablokovat, případně nějak ošidit.

Tohle je zásadní a největší problém Crystal HD. Doporučuji všem zájemcům vyzkoušet ve svém notebooku nějakou "cizí" kartu než si pořídíte Crystal HD. Problémy lze očekávat u Lenova, HP, Dellu a dost dalších značek.

Konkrétně, co se týče novějších (2010+) modelů Lenova, nepomůže nic než patchnutý BIOS. Nějaké zalepování pinů, vypínání slotů, přehazování karet a podobně nemá žádný efekt (vlastní zkušenost).

[Max]

Zde se nabízí otázka spotřeby. Zda použít SW dekoder a mizernou grafiku, nebo lepší grafiku a VDPAU + mizerný cpu, nebo mizerný cpu + mizernou grafiku + hw dekoder.
Spíš si myslím, že celkový přínos HW dekoderu je nulový, né-li záporný. Asi se hodí jen na opravdu mini prťavé stroje určené jako přehrávače, ač v poslední době už výkonově zvládají vše.
Zdar Max

[Jendа]

Podle mě nejmíň bude žrát mizerný CPU + mizerná grafika + HW dekodér. Soudě podle plochy chladiče na dekodéru…

Spíš než spešl dekodér bych zkoumal nějaký DSP, který bude umět třeba i kódovat.

[Max]

Vezmi si takové AMD Zacate. Co víc si přát. Zvládá vše potřebné a max teoretická spotřeba 18W. K tomu nějaký ntb disk + slim mechaničku a je z toho parádní mini přehrávač.
Zdar Max

[R]

A dekodovat video v Linuxe to zvlada?

[Max]

Při použití binárních ovladačů od AMD by neměl být problém.
Zdar Max

[pushkin]

Není.

[Mandarinka]

Spíš než spešl dekodér bych zkoumal nějaký DSP, který bude umět třeba i kódovat.

Quicksync u některých procesorů Intel. AMD chystá něco podobného (bude to v grafikách, a zřejmě také v příší generaci procesorů Fusion). Ovšem kvalitou jsou takové dekodéry jenom šidítka. Kdybych s tím zenkódoval nějakej fansub, tak internet vyleze ze zásuvky a nakope mi zadek.

[Mandarinka]

Kua, mělo tam být "kvalitou jsou takové ENKODÉRY jenom prdítka"

[brk]

Lepší procesor, integrovaná grafika, žádný hw dekodér a zátěž CPU cca 7% při 1080p x264, bitrate nevím, prostě standardní BD rip.

V idle má celá sestava spotřebu 33W. Tohle samozřejmě idle není, ale i tak je to zátěž spíše symbolická.

[Grunt]

Spíš si myslím, že celkový přínos HW dekoderu je nulový, né-li záporný.

Trošku fyziky: Nejnáročnější část u frekvenčně-kompresních algoritmů je právě převod z frekvenční domény do časové. Všelijaké kvantování a strukturování a MC a podobně je většinou brnkačka, protože to jde provést způsoby ALU blízkými (bitové posuny, bitové operace, vybrání z polí, atd.), ne však iD(F/C)T. Ve své čisté podobě je to hodně sinů a hodně cosinů a už takový cosinus se implementuje v číslicových strojích dost blbě, ne jejich série (ve skutečnosti dnešní úrovni předcházela spousta matematického hackingu). DSP pokud již nemají přímo dedikované obvody pro takové akce se aspoň to snaží nějak řešit. Z toho důvodu, pokud to není úplný křáp, tak varianta DSP + spící CPU musí vždy vyjít lépe než cokoliv jiného (i z pohledu spotřeby). Pokud ne, je někde chyba, ale není to chyba fyzikální, ale implementační. Osobně tuto variantu Ďolasovi velmi schvaluji. Nedělat to tak je jako třeba pouštět si do digitálního monitoru signál skrze VGA – jde to, ale podobně jako pan Monk u toho mám vždycky takový divný tik v oku.

[Mandarinka]

H.264 ale neužívá standardní (i)DCT, nedělá to ani mpeg2. Mpeg2 definoval určitý rozsah, do kterého se musí aproximace použitá dekodérem/enkodérem vejít a hotovo, udělejte si to jak chcete (libavcodec má těch algoritmů přes deset). H264 už má tu aproximaci pevně definovanou a IIRC je to udělané tak, aby se to dalo vypočíst jen jednoduchými operacemi (mrkněte třeba, jak to dělá x264 nebo libavcodec). Tuším se to někdy dokonce označovalo jako "HCT".

A u H.264 určitě není hlavní pálka v iDCT. Už je to dávno, co jsem viděl ten graf z profilování, ale IIRC iDCT nemělo ani čtvrtinu, možná že i ta MC ho předběhla, a CABAC a loopfilter oboje taky žralo víc...

Že specializovaný dekodér bude žrát méně elekřiny je však pravda.

[Grunt]

H.264 ale neužívá standardní (i)DCT, nedělá to ani mpeg2.

Vím jen, že AVC to má rozšířeno o jinou eventuální transformaci, ale jinak to slyším prvně. Tak co teda?

Mpeg2 definoval určitý rozsah, do kterého se musí aproximace použitá dekodérem/enkodérem vejít a hotovo, udělejte si to jak chcete (libavcodec má těch algoritmů přes deset)

Tak ± kvantizace koeficientů (fixed/float). Nic v tom smyslu, že by si mohl dekodér dovolit různě interpretovat koeficienty.

Tuším se to někdy dokonce označovalo jako "HCT".

Nebude to Hadamard?

loopfilter

No jo, na ten jsem zapomněl. Ale jinak stejný problém.

[Mandarinka]

Nee, hadamard je něco jiného, x264 to používá třeba pro hrubý nástřel ceny zakódovaného bloku (funkce SATD - sum of average transformed difference - asi...), je to nějaká jednoduchá transformace. Jakou roli to má přímo ve standardu, to netuším. Dvě transformace h.264 má - 4x4 a 8x8. Původně měla být jenom 4x4, ale později přilepili 8x8 (vp8 už to nestihlo obšlehnout, heh), v rámci high profile.

V čem přesně ty rozdíly v idct u mpeg2/4 jsou, neřeknu, protože nevím :). http://neuron2.net/dgmpgdec/dgmpgdec158src.zip má v sobě několik metod, tak můžete porovnat (v souboru dgdecode158src.zip). S tím, že "SSE/MMX (Skal)" ovšem nevyhovuje specifikaci; měla by tam být i ta referenční

A největší svině je podle mě CABAC :)

[Mandarinka]

To je mi náhodička... nechtělo se mi hledat, ale nakonec mi přišlo něco jako odkaz přímo pod hubu.

2012-01-05 00:27:57 < Dark_Shikari> The H.264 Cosine Transform is often referred to as the "dct", but it isn't quite the same thing (it's much simpler, and require no multiplications).

2012-01-05 00:29:32 < Dark_Shikari> Basically it's a fast dct approximation that results in improperly scaled output -- which gets corrected later as part of quantization/dequantization.

Vývojář to doufejme ví dobře :)

[Jiří Němec]

No tuhle hračku mám doma, na AMD Yukon platformě (konkurence atomu, mv-40 procesor - amd64 na 1.6GHz, 1 jádro) jsem s tím bez problému ve woknech přehrával libovolné fullhd video na fullhd monitoru.

To jsou pozitiva, negativa že procesor byl vytížený téměř na 100% + spotřeba tohodle bezmeku + spotřba GPU, takže z 6 hodin výdrže klesla výdrž takovým způsobem, že jsem byl rád když to vydrželo jeden díl seriálu. A i když jsem to nepoužíval, tak to docela žralo, výdrž klesla tak o 1/3.

Dneska už to nemá smysl řešit, crystahd je dle mého názoru naprosto k ničemu.

FullHD video v Linuxu přehrajete naprosto perfektně na téměř libovolném stroji i s open source drivery. Dokonce i bez gpu akcelerace a na minimální takt procesorů. Problémy jsou spíše v cestě obrazu z procesoru na grafiku, s closed source drivery jsem vždy zažíval různý tearing, vadný převod z 16-235 na 0-255 a podobné chuťovky.

[Grunt]

Subjektivně mi přišlo hardwarově dekomprimované video stejně kvalitní jako při softwarové dekompresi

Kdyby ne, pak by se zařízení nemohlo pyšnit podporou formátů MPEG, ale nějakých jejich podmnožin. MPEG standard nepředepisuje kodér (kvůli možnosti vylepšování), ovšem dekodér dle tohoto standardu musí vždycky dávat přesně na bit stejný výsledek jinak nesplňuje požadavky MPEG standardu (malé deviace jako zaokrouhlování tolerovány).

Subjektivně mi přišlo hardwarově dekomprimované video stejně kvalitní jako při softwarové dekompresi, nicméně autor libcrystalhd mě upozornil, že hardware dodává výstup v yuyv422, namísto yuv420.

YUV422 má větší chrominační rozlišení než YUV420, převod YUV420 -> YUV422 ničemu nevadí, protože by měl být bezeztrátový.

To neznamená, že by „read-back“ z karty byl nemožný, ale FFmpeg to prostě teď nepodporuje.

Krom jiného by to bylo jako šťárat se levou nohou v pravém uchu.

Na serveru potřebuji komprimovat v reálném čase televizní vysílání tak, aby se vešlo do uploadu mé VDSL2 linky, který činí 2 Mbit/s.

Z Ďolase se stal mediální magnát?

Zde je nutné podotknout, že Crystal HD nebude stíhat dekódování vyšší rychlostí než 1× – nejde tedy použít jako zázračně rychlý dekodér, dekódovat bude jen „přehrávací“ rychlostí.

Řešením by bylo použít nějaké DSP od TI (přecijen mají delší tradici). Některé výkonnější by dost možná zvládlo i dekódovaní + kódování na místě (mají menší buffer, ale jinak stejně používají sdílený prostor s GPP). Nicméně uvádění do chodu Broadcomu oproti TI DSP je ještě procházka růžovým sadem (i se všemi zde zmíněnými problémy).

[Luboš Doležel (Doli)]

Z Ďolase se stal mediální magnát?

Když jsem u rodičů, tak se nechci koukat na Novu

Krom jiného by to bylo jako šťárat se levou nohou v pravém uchu.

Prostě se jen snažím využít to, co je, aniž bych musel dokupovat nový procesor, a tudíž i základní desku a paměti.

[Grunt]

Když jsem u rodičů, tak se nechci koukat na Novu

Jsem si to myslel. A nepomůže ani kvalitní zesilovač k parabole?

rostě se jen snažím využít to, co je, aniž bych musel dokupovat nový procesor, a tudíž i základní desku a paměti.

Nevím, ale není VDPAU prezentační vrstva? Co vím tak zrovna s přímím zapisováním na adresy grafického portu to nikdy nebyla moc sranda (muselo se čekat na cykly) nebude to stejně i s VDPAU? DSP se to podšoupne a výsledek přecijen někde po cestě vyklopí. Jinými slovy nechci říct, že by to nešlo, ale nebude to podobné jako se zmiňovaným dvojím převodem v případě VGA? (Tedy levá noha, pravé ucho)

[Luboš Doležel (Doli)]

Jsem si to myslel. A nepomůže ani kvalitní zesilovač k parabole?

No, rodiče bydlí 200km daleko, to si spíš pořídím mobilní parabolu

Nevím, ale není VDPAU prezentační vrstva? Co vím tak zrovna s přímím zapisováním na adresy grafického portu to nikdy nebyla moc sranda (muselo se čekat na cykly) nebude to stejně i s VDPAU?

Čuně VLC to tak ale teď dělá... pošle H264 do grafiky, přečte zpátky raw video a to zase zpátky zapíše do grafiky. Je to na pár facek, ale je to důkazem toho, že se VDPAU dá využít čistě k dekódování bez zobrazování.

[Mandarinka]

Subjektivně mi přišlo hardwarově dekomprimované video stejně kvalitní jako při softwarové dekompresi

Kdyby ne, pak by se zařízení nemohlo pyšnit podporou formátů MPEG, ale nějakých jejich podmnožin. MPEG standard nepředepisuje kodér (kvůli možnosti vylepšování), ovšem dekodér dle tohoto standardu musí vždycky dávat přesně na bit stejný výsledek jinak nesplňuje požadavky MPEG standardu (malé deviace jako zaokrouhlování tolerovány).

Starší MPEGy definují odchylku do které se musíte vejít (jediná ne-exaktní část procesu je však DCT/iDCT). H.264 je celé exaktní - jakákoliv odchylka od referenčního dekodéru znamená vadnou implementaci (tedy kromě lahůdek jako že referenční dekodér prý nezvládá některé části high 4:4:4 predictive profilu protože je v něm neopravená chyba... holt to nikdo nepoužívá tak se na to kašle).

[Grunt]

H.264 je celé exaktní - jakákoliv odchylka od referenčního dekodéru znamená vadnou implementaci

Co se pamatuju, tak MPEG-1 mělo v referenční implementaci bitsream. Make test znamenalo zpracování a porovnání. Nic víc.

[jehovista]

Nema to byt 1920x1080?

[Mandarinka]

Interně jsou použité 16x16 boky, takže 1920x1080 se pro potřeby (de)kódování vycpe na 1920x1088 (další násobek 16) a po dekódování ten proužek dekodér ustřihne. Proto to umí 1920x1088 :)

[pavlix]

Kompilace pravděpodobně selže na souboru crystalhd_flea_ddr.c – stačí na jeho začátek připsat tento řádek a už se to povede.

Jo, na to je dobré alespoň uvést commit, na kterém jsi to testoval. Co když v gitu někdo ještě stihne něco pokazit :).