Crystal HD – HD video v malém balení

2. 1. 2012 | Luboš Doležel | Recenze | Návody | 7422×

Dnes se podíváme na produkty Crystal HD od společnosti Broadcom. Pod tímto obchodním názvem se skrývá skupina šikovných karet, které jsou schopné akcelerovat dekompresi videa různých formátů.

Obsah

• Kde se to dá koupit
• Podpora v Linuxu
• Přehrávače
  • MPlayer
  • VLC
  • XBMC a další
  • FFmpeg přímo
• Verdikt

Crystal HD najdete především v podobě karet BCM970012 a BCM970015, přičemž ta první karta typicky vyjde o něco levněji, ale zato je zase trochu vybíravější. Na trhu je najdete v podobě Mini PCI Express karet (ostatní varianty se moc nevyskytují) a někteří z vás možná mají netbook, kde právě tento kousek je jedinou nadějí pro plynulé přehrávání videa.

Karty oficiálně podporují MPEG-2, MPEG-4 Part 2, H.264 a VC-1. Pokrývají tak kompletně standardy používané v digitálním televizním vysílání (MPEG-2 a H.264), Blu-Ray disky (VC-1) a „pirátské“ ripy (typicky MPEG-4 Part 2 a H.264). Maximální rozlišení videa je 1920×1088, přičemž je zde ještě omezení na bitrate, a to 40 Mbps. Princip je jednoduchý: do karty se posílá komprimovaný proud videa a zpět přichází proud dekomprimovaný.

Kde se to dá koupit

To byl první problém, který jsem začal řešit. Nakonec jsem si kartu objednal přes eBay – to je trochu riziko, protože prodejci rádi označují své aukce identifikátorem jak lepšího modelu, tak horšího. Samozřejmě pak dostanete ten horší. Jako já. Obecně bych ale doporučil e-shop BuyDVB.net, kde se kromě samotných karet prodávají i různé DVB-S/T/C karty za dobrou cenu, s podporou nestandardních modulací (32APSK) a v neposlední řadě s výbornou podporou Linuxu – ta je sice v podobě ovladače udržovaného mimo jádro, ale samotný kód ovladače má podobu téměř jen wrapperu, který napojí příslušné ovladače čipsetů na samotný hardware.

Teď, když jsme si sehnali samotný HW dekodér, ještě zbývá vyřešit, jak to umístíme do svého počítače. Pokud máte notebook s vícero Mini PCI Express sloty, můžete mít štěstí – je tu šance, že po připojení začne dekodér fungovat. 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.

Pokud chcete Mini PCI Express kartu dostat do svého desktopu, nabízí se použít „redukci“ na velké PCI Express. Protože jsem šel po ceně, přeskočil jsem zaručeně fungující redukce, které se cenou blíží tisícikoruně. Místo nich jsem si koupil velmi lacinou kartu Routerboard 11E, jež je sice oficiálně pouze pro WiFi moduly, ale veřte, že funguje i s tímto HW dekodérem.

Podpora v Linuxu

O podporu v Linuxu se postaral samotný Broadcom, který dodal prvotní open source ovladač. Ten převzala komunita a začala řešit různé nedostatky – aktuální práce je dostupná v Git repozitáři. Ovladač se skládá ze dvou částí: jaderného modulu crystalhd a knihovny libcrystalhd. Nejprve si tedy stáhneme obsah repozitáře:

git clone --depth 1 git://linuxtv.org/jarod/crystalhd.git

Pak přejdeme ke kompilaci modulu:

cd crystalhd/driver/linux
autoconf
./configure
make
make install

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.

#include <linux/delay.h>

Teď zkompilujeme knihovnu:

cd ../../linux_lib/libcrystalhd
make
make install

Jaderný ovladač najdete i v novějších jádrech, skrývá se mezi staging ovladači. Našel jsem však řadu míst, kde se jeho užití nedoporučuje – a pravdou je, že se jaderný ovladač identifikoval starší verzí než ten z Gitu. Takto by mělo vypadat úspešné načtení modulu a nalezení karty:

[246711.027735] Loading crystalhd v3.10.0
[246711.027891] crystalhd 0000:04:00.0: Starting Device:0x1612
[246711.031185] crystalhd 0000:04:00.0: irq 48 for MSI/MSI-X
[246711.031205] crystalhd 0000:04:00.0: irq 49 for MSI/MSI-X
[246711.286151] crystalhd 0000:04:00.0: setting latency timer to 64

Přehrávače

Teď ale ještě nejsme u konce. Crystal HD musí podporovat váš přehrávač. Nejsnazší cesta vede přes knihovnu ffmpeg, v jejíž Git verzi je podpora přítomna (libavcodec/crystalhd.c). Pokud configure v systému zpozoruje libcrystalhd, kompilace podpory pro tento hardware se aktivuje. V repozitáři forku libav jsem podporu Crystal HD neviděl.

MPlayer

Dalším místem je například přehrávač MPlayer, v jehož repozitáři je podpora pro Crystal HD ve FFmpeg začleněna.

Jakmile máme vše zkompilované a nainstalované, nic by už nemělo přehrávání bránit. V MPlayeru se dá užití HW akcelerace zapnout použitím dekodérů nazvaných ffh264crystalhd, ffmpeg2crystalhd a dalších, kompletní výpis ukáže tento příkaz:

$ mplayer -vc help 2>/dev/null | grep crystalhd
ffmpeg2crystalhd ffmpeg    working   FFmpeg MPEG-2 (CrystalHD)  [mpeg2_crystalhd]
ffdivxcrystalhd ffmpeg    problems  FFmpeg DivX  (MSMPEG-4 v3) (CrystalHD)  [msmpeg4_crystalhd]
ffwmv3crystalhd ffmpeg    problems  FFmpeg WMV3/WMV9 (CrystalHD)  [wmv3_crystalhd]
ffvc1crystalhd ffmpeg    problems  FFmpeg WVC1 (CrystalHD)  [vc1_crystalhd]
ffh264crystalhd ffmpeg    working   FFmpeg H.264 (CrystalHD)  [h264_crystalhd]
ffodivxcrystalhd ffmpeg    working   FFmpeg MPEG-4,DIVX-4/5 (CrystalHD)  [mpeg4_crystalhd]

Otestoval jsem podporu MPEG-2, H.264 a MPEG-4 Part 2 („DivX“). První dva formáty fungovaly, MPEG-4 Part 2 ale bylo z neznámých důvodů odmítnuto. Inicializace karty je asi nejnáročnější částí celého procesu – může to výjimečně až 5 sekund a občas mi to u HD videí selhalo. dmesg rychle napovědělo proč: obávané page allocation failure, a to přesto, že v systému bylo 3,5 GB volné paměti. Ovladač si totiž potřebuje alokovat větší bloky paměti jako DMA buffer. Problém naštěstí po chvíli zmizel a mohl jsem jít testovat.

$ mplayer -vc ffh264crystalhd 'The.Simpsons.S22E02.720p.HDTV.X264-DIMENSION.mkv'
...
DtsCreateShMem:deleted shmem segment and creating a new one ...
DtsDeviceOpen: Opening HW in mode 0
Clock set to 180
Enable single threaded mode
Setting Color Mode to 1
...

A přehrávání začalo. V konzoli se zpočátku přehrávání objevují nějaké ty chybové hlášky, zejména pak tyto dvě:

[h264_crystalhd @ 0x30a86f3100]CrystalHD: No frames ready. Returning
[h264_crystalhd @ 0x30a86f3100]CrystalHD: Picture Number discontinuity

Což je podle komentářů v kódu hlavně důsledek toho, že se do hardwaru musí nejprve poslat určitý objem dat a až pak se začne vracet výsledek. Přes tyto trochu děsivé hlášky ale přehrávání fungovalo v pořádku. 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.

MPlayer se dá nastavit tak, aby se dával přednost CrystalHD, a to umístěním podobného řádku do /etc/mplayer/mplayer.conf:

vc=ffh264crystalhd,ffmpeg2crystalhd,

V následující tabulce najdete přehled zátěže procesoru Athlon 64 4600+. Obrázek si uděláte sami z výsledků, test probíhal bez aktivního výstupu zvuku.

Způsob	Zátěž CPU
Software	~70 %
Crystal HD	15 %
VDPAU	3 %

Vítězství VDPAU se dá vysvětlit snadno tím, že při jeho použití jde komprimované video do grafické karty a tím operace končí. S Crystal HD jde nejprve do akcelerátoru, pak se musí načíst zpět dekomprimované a v této podobě se posílá do grafické karty.

VLC

Git verze VLC sice Crystal HD skrze FFmpeg podporuje, ale výsledek byl zoufalý. Zátěž procesoru byla kolem 45 % a obraz se hrozně cukal. Nebylo to koukatelné. Celkově mi akcelerované video nikde ve VLC nechodí – na notebooku když v něm použiji VDPAU, ale dělá to tak neefektivně, že je zátěž CPU jako bez VDPAU, ne-li vyšší. Ačkoliv nemám MPlayer moc v lásce, tak v tomto ohledu mi funguje mnohem lépe.

XBMC a další

XBMC aktuálně nikde neprovozuji. Hledání na webu nicméně naznačuje, že XBMC má velmi dobrou podporu Crystal HD, dokonce je prý lepší než ta ve FFmpeg, což je mj. umožněno příznivější architekturou XBMC. MythTV se podle všeho podpoře těší také.

FFmpeg přímo

Důvod, proč jsem si kartu kupoval, byl ale docela odlišný. Výkon procesoru mám dostatečný, všude mohu použít VDPAU, ale na domácím serveru mám jiné potřeby. Tam nechci, aby mi běžel X server; i kdyby běžel, tak ffmpeg nedokáže využít VDPAU při rekompresi videa – půjde to jen při přehrávání. To neznamená, že by „read-back“ z karty byl nemožný, ale FFmpeg to prostě teď nepodporuje.

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. Server bez problémů stíhá převádět SD stanice na rozlišení ~640×480 a komprimovat obraz pomocí x264. Pokud ale chci obdobnou věc udělat s HD stanicemi (u kterých nemám k dispozici SD variantu), procesor přestane stíhat, protože je příliš zatížen dekódováním.

Moje myšlenka byla tedy taková, že v Crystal HD provedu dekódování spolu se snížením rozlišení (to karta také umí) a zbytek už procesor bude stíhat. 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í. Bohužel se ukázalo, že tento způsob užití nebyl ve ffmpeg testován (a ani se nedivím).

Dostávám chyby jako [libx264 @ 0x8269a0] Input picture width (640) is greater than stride (0) a pokud jsem se pokusil ručně opravit stride na 720 (taková je stride jdoucí z hardwaru), vedlo to k pádu ffmpeg. Aktuálně jsem v kontaktu s autorem implementace, aby se nedostatek opravil. Uvedu tedy jen, že fungovat by to mělo přidáním těchto přepínačů:

ffmpeg -strict experimental -vcodec h264_crystalhd
# Možná volba: -crystalhd_downscale_width 640

Verdikt

Na některých místech jsem četl, že Crystal HD je potenciální „VDPAU killer“, tedy že dokáže vytlačit dražší karty NVIDIA z různých doma vyrobených HTPC. Osobně bych při stavbě takového stroje dal přednost VDPAU, protože po zhodnocení zkušeností musím říci, že je to jistější volba. A ona je to podle výsledků zátěže procesoru volba dokonce i efektivnější.

Chcete-li se ale vyhnout NVIDII a máte v plánu provozovat třeba právě XBMC, nebude Crystal HD vyložená prohra – jen bych doporučil pořídit si dražší ze dvou zmiňovaných čipů. Podle komentářů v kódu má levnější čip více nedostatků, které se pak musí všemožně obcházet v ovladači.

       

Komentáře

[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 :).