Nový formát kódování videa: H.266/VVC (Versatile Video Coding)

Fraunhofer HHI společně se svými partnery Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm a Sony oznámil schválení nového formátu kódování videa: H.266/VVC (Versatile Video Coding). Jedná se o nástupce formátů H.264/AVC (Advanced Video Coding) a H.265/HEVC (High Efficiency Video Coding).

7.7.2020 14:22 | Ladislav Hagara | IT novinky

Komentáře

[Aleš Kapica]

Zajímavé. Hlavně až se objeví nějaké použitelné enkodéry a dekodéry.

[pepa z mesta]

Je to lepsi nez AV1?

[David Heidelberg]

to se uvidí za 4-5 let, až odladí software tak, aby byl efektivní a dal se použít. Každopádně, příštích pár let bude AV1 top třída.

[perteus]

AV1 je alternativa za h265 a používá podobnou technologií. Takže tohle je rozhodně lepší jak AV1. Konkurent tomuhle novému kodeku bude AV2.

[Ovoce]

AV1 je od HEVC v lecčem odlišná, má velké množství věcí, co jdou nad jeho rámec a některé zase má už i VVC. Akorát možná AV1 často ty nové metody splácalo dohromady bez pořádného sladění, to třeba VVC dokáže udělat líp.

Jasným obšlehnutím (ovšem s limitacemi, takže striktně horším) formátu HEVC bylo už Googlí VP9. AV1 z něho evolučně taky vychází, ale nabalilo na to spoustu dalších technik.

[Ovoce]

Minimálně o něco by to mělo být lepší, AV1 je podle toho, kdo to posuzuje, buď zhruba jako HEVC nebo mezi HEVC a VVC.

Výsledná kvalita obrazu ale vždycky závisí na formátu a zároveň i na enkodéru - obě věci musí být excelentní, aby výsledek nestál za hovno. Enkodéry mají tyhle Google formáty bohužel notiricky špatný, ale VVC ještě nemá žádnej, takže se nedá srovnávat.

Já v VVC vkládám naděje kvůli tomu, že MPEG/ITU mají kvalitnější ten vývojový a standardizační proces, kdežto Google/AOM je bordel na kolečkách, kde se místo procesu akorát odkejvají věci, co tam chcou největší hráči a zbytek "účastníků" je se svými návrhy poslán do pr-ůhonic. A ještě je všechno hrozně uspěchaný.

Bohužel tady hrozí, že ten horší proces výroby standardů vyhraje, protože se půjde cestou nejnižších nákladů, díky kterým si prosadí svoje ti internetoví obři, kteří si vývoj zaplatí z reklamy/šmírování a nemusí tedy za formát požadovat licenční poplatky. Jako freetardům/open sourcářům to vyhovuje, ale technologicky to na vývoj video formátů IMHO bude mít (respektive už asi má) negativní dopad.

[mirec]

Trochu offtopic, ale existuje generický video dekóder, ktorý by vedel pomôcť pri dekódovaní budúcich kodekov? Niečo, čo by nemalo priamo podporu h.265, av1 atď, ale len generické bloky a celá logika dekódovania by bola definovaná firmvérom.

[ggg]

Ano, říká se tomu CPU.

[mirec]

No tu je problém, že CPU to už moc nezvládajú a v budúcnosti bude ešte horšie. Meniť notebook vždy keď príde na trh nový kodek len preto, že jednoducho CPU to nemôže utiahnuť a vstavaný video dekóder ešte nevedel o budúcom štandarde mi pripadá fakt blbé. Možno keby existoval samostatný vymeniteľný dekóder do expresscard / mini PCIE ...

[Ovoce]

Většinou to asi nebude moc výhodné, protože když ten dekodér nemá přímý přístup do paměti, tak pak bude nekomprimované video při vysokých rozlišeních hodně zatěžovat procesor.

ExpressCard je mrtvej, taky (bohužel).

Ona na nižší rozlišení a i 4K vcelku lepší procesory stačí, když se díky AMD začaly přidávat jádra.

Tady u VVC bude problém, že jak to není ten freeopenkodek, tak není moc zaručená existence optimalizovaného dekodéru v FFMPEGu. Například HEVC má výrazně míň efektivní dekódování než AV1, ačkoliv AV1 je o dost náročnější formát. Ale ty Google kodeky vždycky už od VP8 přitahovali fandy, takže měly vždycky nejlepší dekodéry. Zatímco enkodéry, kde by to úsilí asi bylo důležitější, paradoxně nic moc :)

[jiwopene]

Něco jako bajtkód pro dekodéry videa? U televizí by to asi našlo použití — vysílač jednou za čas pošle dekodér v bajtkódu (tzn. zkompilovaný) a televize si ho převede pro svůj CPU. Mám ale pocit, že by to nebylo o moc efektivnější než dekodér běžící v QEMU nebo JVM.

[petr_p]

Ani nativním kódem by CPU nestíhal dekódovat. Všechno odedře dekodér implementovaný v hardwaru. To je to, na čem tyhle firmy vydělávají. Dnešní televize je v podstatě smartphone s velkou obrazovkou. Spíše se ptejte, kdy přejdeme na DVBT3 s H.266, abychom mohli polovinu pásma darovat našim drahým telefonním operátorům.

[R]

Ano, znovu vyhodit vsetky televizory.

[Peter Golis]

Alebo zakúpiť si SetTopBox s podporou h268 ktorý sa pripne na TV, a predĺži jej agóniu pred odchodom do kremíkového neba.

[?]

zakúpiť si SetTopBox s podporou h268

Jak to chapat? Jako pokus o chytrejsi vtip nez predesle chytre vtipy?

[Peter Golis]

Jak to chapat?

Jednoznačne, dvojzmysly v tom nehľadaj.

[podlesh]

No, i hardware se dá programovat, teoreticky by se dalo takhle posílat něco na způsob FPGA. Samozřejmě, momentálně je to čistě scifi.

[jiwopene]

+1

Při psaní mě ještě napadlo FPGA.

[Ross]

Nema to valny smysl, protoze 10ti lety procak to stejne stihat nebude. To ze mame porad lepsi kompresni algoritmy jde ruka v ruce s vykonem dostupnych CPU. Samozrejme jsou tam i jine faktory jako velikost zobrazeni PAL-2K-4K-8K nebo frekvence 25-30-60-120fps ale to je uz druhotny efekt diky tomu ze ty procaky to "stihaj".

Takze porad nejlevnejsi a nejekologictejis reseni je menit krabicku pripojenou k LED panelu (zamerne neuvadim "k televizi" protoze TV tuner dnes nepotrebuje nikdo). Takze dnes vychazi nejlepe koupit 4K panel, nez vsechno TV vysilani bude v 4K tak si pockame jeste tak 5let. K tomu aktualni AppleTV za par kacek pro podopru vsech tech Netflixu a klonu. Az budou lepsi kompresni algoritmy tak vymenis AppleTV za lepsi model a bezis dal. Tak po 10ti letech muzes zaccit premyslet o 8K ale nebude to moc nutne.

[skunkOS]

"nez vsechno TV vysilani bude v 4K tak si pockame jeste tak 5let"

V žádném případě, bude to dle mého názoru trvat podstatně déle. Pár měsíců zpátky se k tomuto vyjadřovali všechny velké TV stanice v ČR. Skoro žádné nepříslíbily ani vysílání ve FHD!!!! Kromě ČT, která FHD v DVB-T2 slíbila to budou ostatní TV přidávat velmi pomalu a to ještě nemluvím o QHD.

[orbit]

V podstate je to pro 8K. Nez se 8K stane standard za cca 10tis uplyne hodne casu.

[j]

A to pises v dobe, kdy naprosto drtiva vetsina TV vysilani neni ani v HD a i pokud ma rozliseni, tak ma tak smesny bitrate, ze by se za to stydel i kazdej domaci streamer s kamerkou na monitoru.

---

Dete s tim guuglem dopice!

[Max]

Nechápu, že se to stále ujímá a všichni to implementují a platí licence.
Zdar Max

[PetebLazar]

Licenci zaplatí zákazník v ceně produktu, přičemž moc nemá na výběr (typicky implementují komerční kodeky do SoC/GPU všichni). V desktopu/ntb může mít stejnou licenci "zaplacenu" klidně několikrát (v OS, dGPU, iGPU(CPU), app).

Vypadá to, že velké ryby (asi s nárustem náročnosti a objemu mult. obsahu) začíná trápit i encoding. Tak jim MPEG nejspíš chce vyjít vstříc s LCEVC (Low Complexity Enhancement Video Coding). Letošek je holt rokem C-19 a nových codeků (FVC, MPEG-5 EVC, ...). https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=134694

[VoDo]

Vyvoj neco stoji, jak sis určitě všiml tak free software stoji za hovno nebo se produktem stane zákazník.

[BioGaia]

Protoze je to dobry model. Zaplati se vyvoj, zbydou penize na rozbehnuti dalsiho vyvoje a jeste to i vydelava na chleba. Zaroven ten paywall drzi podrztasky a socky od toho aby moving Picture Expert Group zustala skupinou kvalifikovanych expertu.

Jediny komu se ten model kolem kodeku nelibi je FOSS hnuti. Jako hezky priklad muzeme uvest jak v ramci hesla "dogonim i peregonim Ameriku" zacal vyvoj "konkurenta" mp3 - ogg/vorbis. Trval dlouha leta, nepresadil se nikde, kvalitou byl +/- to samy az nakonec byl nahrazen Opus-em, kde za vyvojem stala normalni firma, pouzila normalni BSD licenci a ne sekta GNU Svedku Stalmannovych s bedary.

[Max]

Tak jsem to ale nemyslel. Vždyť Google byl donucen koupit si, otevřít a pokračovat ve vývoji VP8/9 (nyní AV1) a evidentně se mu to vyplatí. Když už se firmy složily a vyvíjejí AV1, tak proč dávat prostor uzavřené konkurenci a platit jí licenční poplatky?
Zdar Max

[trekker.dk]

Co jsem slyšel (agentura JPP), tak enkodér na tyhle googlí věci není (nebyl) dost rychlej na to, aby se dal použít pro televizní vysílání. Zbytek je o tom, kdo má kde kamarády, pokud standard DVB-T znamená H26x, tak si holt musíte koupit licenci.

[j]

To je tak, kdyz nekdo nechape podstatu veci ze?

Bez na libovolnej torrenti tracker, a najdi tam torrent, kterej ma cokoli jinyho nez v pripade audia mp3/flac, v pripade videa 265/264/xvid.

Zadny jiny kodeky nikoho nezajimaj, at je vyviji kdokoli. Takze i to oslavovany AV ve skutecnosti nikoho nezajima, a protoze nikoho nezajima, neumi to akcelerovat HW, tudiz to nikomu poradne nefunguje.

Ve skutecnosti totiz nejaky licence a patenty jsou presne to, co je vsem zcela uprdele. Kuprikladu takovej M$ s velkou slavou celkem nedavno (je to tak rok a fous) pridal do widli nativni podporu ... mpeg2. Tzn kodek, kterej dneska uz naprosto nikoho nezajima, a kterej v dobe, kdy zajimavej byl (DVD) mel proste kazdej nainstalovanej z jinych zdroju.

Dtto tuxi distra ktery si hrajou na to jak strasne jsou koser ve skutecnosti nikdy nezvladly prehrat ani tu mp3. Opet, nikoho to nezajimalo, protoze kazdej desktop to mel doinstalovany.

Jinak receno, vyhraje ten, kdo prijde driv. Guugl stema jejich mazanicema na yt je tak maximalne vsem k smichu. Opet, muzes si dohledat, porovnani videa ktery nekdo uploadne a vysledku, kerej yt posila do sveta ... neco takovyho kdyby nekdo nahodil na libovolnej tracker, tak bude exkomunikovan. A jasne ze to neni (jen) kodekem, ale je to prezentace toho kodeku.

---

Dete s tim guuglem dopice!

[Like]

+1

[PetebLazar]

Všechny nové formáty byly svého času bez částečné(plné) akcelerace dekódování v HW (Mpeg-1, Mpeg-2,Mpeg-4 ASP, Mpeg-4 AVC, VP9, HEVC, AV1, ...), jde jen o to kde na časové ose zrovna stojíme a bude tomu pro nové kodeky i v budoucnu. Nakonec i ten zmiňovaný AV1 má již první vlaštovku. Pokud bude v tomto formátu nabízen obsah (dva z hlavních hráčů Netflix/YT již tak snad činí) zařízení vybavené touto schopností (HW decoding) budou mít výhodu nejspíš v energ. efektivitě (proti CPU decodingu).

Z jejich pohledu jde jistě o čistý business case, menší množství serverů uspokojující požadavky klientů v H.264(HEVCu) znamená menší licenční poplatky. Nemluvě o tendencích providerů vybírat poplatky za přenesená data od poskytovatelů obsahu (využít AV1 místo H.264 je tedy úspora v datovém toku při zvýšení kvality, výrazně dražší HEVC asi neplatí kdo nemusí).

[PetebLazar]

Otázkou je, jak a do jaké úrovně je podpora Mpeg-2 do Windows vlastně doplněna. Vzhledem ke stáří Mpeg-2vúvodních release je ve hře i "bezplatná" varianta, že doplněn byl jen v rozsahu vypršených patentů (v U.S.A. typicky 20 let). Případně zda daná podpora ve Windows není závislá na dostupnosti podpory v HW, kdy výrobci GPU/iGPU to mají za sebe licenčně pokryto (APL skrze OS volá pouze API DXVA ovladačů).

[j]

Oni to do tech widli dodali prave proto ze tomu vypsely patenty (ono toho bylo vic, ale tohle si pamatuju). Jenze to uz proste nikoho nezajima. Pokud si pamatuju, jedna z tech dalsich veci byla prave mp3 (duvod stejnej, konec patentu), to taky widle nikdy nativne neumely, a dneska uz nejaka podpora v systemu nikoho nezajima, protoze to umi nativne kazdej prehravac.

Ostatne v dobe kdy mpeg2/DVD prisel na trh, tak to zadny PC softwarove prehrat neumelo. Proste na to nemelo vykon. Musel si na to mit extra HW kartu. To se samozrejme pomerne rychle zmenilo. A tim se taky HW karty staly neprodejny, protoze proc by si nekdo kupoval za nemaly peniz extra HW kdyz totez muze udelat pomoci SW.

Jinak receno, funguje to presne opacne nez pises o post vejs. Obecne mpeg formaty maji v dobe uvedeni HW. Coz pochopitelne neznamena, ze existuje dostatek obecnyho vykonu na SW implementaci.

Castecna HW podpora se do obecnyho HW (prevazne GPU) dostala pomerne nedavno. Xvid a starsi varianty nikdy nic takovyho nemely, jednoduse proto, ze na to bohate stacil vykon obecnyho CPU. Ten se ale za posledni roky prakticky nemeni, zato naroky na vykon pri prehravani videa rostou pomerne razantne. Proto se vyrobci rozhodli implementovat HW podporu. Opet, pevazne nejde o HW kodek, je to v kombinaci se SW, ale resi to vykonostne kriticky casti (a proto na to vyrobci tech GPU trebas ani zadnou licenci nepotrebujou).

Funguje to vlastne stejne jako AES-NI. To samo o sobe taky nic zasifrovat neumi. Ale umi to vyrazne redukovat zatizeni CPU alternativne vyrazne zvednout vykon sifrovani.

---

Dete s tim guuglem dopice!

[billgates]

Akcelerovat DivX/Xvid slo cez 3Dnow!, co AMD samozrejme nezabudli zdoraznit v reklame. Potom neskor samozrejme aj cez SSE.

Ohladom tych mpeg2 akceleracnych kariet, na to si este osobne pamatam. V skole sme mali taky super stroj koncom 90. rokov a cumeli sme na DVD. Nieco na styl toho, co LGR ukazuje v tomto videu.

[j]

Akcelerovat libovolny video jde i na GPUckach, ktery nemaji HW podporu prehravani videa. Jenze to trpi vsema nedostatkama ktery to ma. Predevsim GPU neumej zpracovat float. A plati to nejen pro dekompresi (prehravani) ale i opacne, pomoci GPU se da video i komprimovat. Vysledky jsou ale pomerne tragicky.

A ve finale, takovahle "akcelerace" sice mozna odebere neco zateze CPUcka, ale zvedne odber v nasobcich.

Navic je to hodne zavisly na konkretnim HW a konkretni verzi ovladacu - jinak receno, pro kazdou jednu kartu bys to musel napsat zvlast. Svyho casu sem si stim hral. Fungovalo to (na my karte), coz je asi tak vse, co se k tomu da rict.

On se v GPUcku da pustit i operacni system, opet, s tunama vsemoznych ale ... proste je to na tema ze sroubovakem hrebik taky zatluces.

Viz tady vejs ten dotaz na tema obecnyho kodeku, proste HW implementace konkretniho kodeku bude ve finale levnejsi a predevsim funkcni.

---

Dete s tim guuglem dopice!

[Ovoce]

TVL co to tady vidím za pohádky...

GPU pracují s floatama, nativně! Je to jejich hlavní formát. Ale naopak video nepoužívá floaty, ale naopak funguje s 8bit nebo 16bit integery (takže BTW pro předřečníka bylo pro přehrávání DivX/XviD nejdůležitější MMX/MMXext a potom SSE2, SSSE3..., ne SSE nebo 3DNow).

Obecné jednotky GPU se pro dekódování a enkódování videa nehodí, je to zybtečně komplexní a mnohem lépe se to dá udělat pomocí SIMD kódu na CPU.

Že MPEG formáty nejdří vzačínají na hardwaru je blbost a platilo to jenom kolem poloviny 90. let, kdy byly CPU ještě příliš pomalá a proto byly třeba HW dekodéry, od té doby nikdy. Dnes jediné, co GPU bude "obecně" akcelerovat, je převov YUV na RGB a škálování, což jsou operace už nad dekomprimovaným videem. Dekódování dělá na grafikách nebo i na procesorech včetně ARMů specializovaný na to určený ASIC obvod, který se plus minus nedá přeprogramovat pro novější formát. Proto tzv. hardwarové dekódování (nebo komprese) má určité zpoždění proti době, kdy je formát dokončen. Například pro AV1 přijde až letos.

[deda.jabko]

Predevsim GPU neumej zpracovat float.

A ty vertex shadery pracuji s jakymi hodnotami? Schvalne se podivej, kolik TFLOPS maji dnesni karty, a pak se podivej na vyznam toho FL v te zkratce, a pak mudruj.

On se v GPUcku da pustit i operacni system

To nedava smysl, zjisti si, co vlastne operacni system dela, a pak mudruj.

[j]

Zas dva tupci ktery tady blabolej a netusej vo cem. Operacni system se ty negramote da spusti klidne na na libovolny disku (na tom swabovi co je na nem nalepenj). Je uplne jedno jakej to dava smysl proste to jde.

A graficky karty video pocitat neumej. A neumej ho proto, ze nezvladaj vypocty s dostatecnou prenosti. Coz opet, negramotny zvanilove ktery si to vzivote nevyzkouseli nemuzou tusit. Graficky katy umej pocitat masivne paralelene, coz by i davalo pro video smysl, ale nepresne, coz se razantne projevi na vystupu. IQ houpaciho kone to ale nepobere, to chapu.

Kdyby zelenina vejs zapojila i jen jednu mozkovou bunku, tak by trebas zvladla vyguuglit, ze soucasti kazdyho novyho mpegu je specifikace HW. A prave proto HW zadny jiny kodeky nepodporuje, protoze nikdo na planete nebude vymejslet HW podle SW, kterej se muze za tejden zmenit.

---

Dete s tim guuglem dopice!

[PetebLazar]

Z čeho usuzujete, že jde neschopnost počítat přesně (dostupné FP32/FP64 v GPU bych očekával pro daný úkol jako dostatečné) a ne o rozdíl v redukované komplexnosti(feature set) a celkové výpočetní náročnosti v GPU využitého encodovacího algoritmu?

Například pokud srovnáme feature list ve zmíněném CUDA encodéru a x264 encoderu, výhoda větších schopností je patrně na straně x264. http://acarus.uson.mx/docs/cuda-5.5/CUDA_Video_Encoder.pdf https://www.videolan.org/developers/x264.html

Vestavěné HW encodéry mají pravděpodobně jako svou prioritu spíše vysoký výkon, než vysokou kvalitu. Pokud mezi typické úkoly patří real-time encoding je kompromis v kvalitě asi na místě. Proti tomu x264 může být využit i pro velmi kvalitní výstup ovšem ne nutně real-time.

Dnešní NLE umí těchto schopností HW decodingu/encodingu v GPU dobře využít a zbývající zdroje CPU/GPU namířit pro vlastní edit/color_grading/efekty atd. Pro opakovaný náhled omezená kvalita encodingu postačí, na finální encoding lze nakonec vždy využít export z NLE v lossless formátu a následně jej zpracovat externím kvalitním encodérem.

[trekker.dk]

Já fakt nechápu, že toho trotla pořád někdo krmí.

[PetebLazar]

Jelikož jde o oblast, která mne posledních 25 let hodně zajímala dovolím si některá Vaše tvrzení doplnit.

Castecna HW podpora se do obecnyho HW (prevazne GPU) dostala pomerne nedavno.

Nevím kolik let myslíte tím nedávno, ale má historie využití akcelerace dekódování video obsahu v rámci GPU/iGPU začíná s příchodem ATI Rage II+ (1996), která pro Mpeg disponovala HW podporou (MC a iDCT) což asi nelze označit za nic jiného než částečnou HW akceleraci dekódování (ve srovnání se současným plným VLD .. bitstream decoding). Takže částečná HW akcelerace dekódování je prakticky počátkem HW dekódování v GPU (nepočítaje specializované přídavné dekódovací karty ke GPU).

Ten se ale za posledni roky prakticky nemeni, zato naroky na vykon pri prehravani videa rostou pomerne razantne. Proto se vyrobci rozhodli implementovat HW podporu.

Dostatečná výkonnost CPU je pouze jedním z důvodů (například kvůli značně širokému spektru výkonu v rámci generace), dalším důvodem pro implementaci HW dekódování v GPU/iGPU je také energetická efektivita. O dekódování se stará relativně malá speciálně navržená část GPU (rozměrově v mizivém podílu z celého GPU), která je schopna docílit téhož s daleko menšími energetickými nároky na spotřebu. I úroveň HW podpory v GPU se časem vyvíjí, tím jak se reálně uplatňují vyšší profily/levely kodeku (abychom zůstali v terminologii MPEG). Mám pocit, že generace GTX 1080Ti nepodporuje dekódování HEVC10 4:4:4, generace RTX 2xx0 již ano.

Obecne mpeg formaty maji v dobe uvedeni HW. Coz pochopitelne neznamena, ze existuje dostatek obecnyho vykonu na SW implementaci.

Od třídy karet HD2000(Geforce 8000) je tu s námi v různém rozsahu VLD (plný bitstream decoding Mpeg-2/VC-1/H.264 ... "BD trinity"), kdy CPU prakticky jen krmí příslušnou část GPU vstupními daty (po případném dešifrování). Několik let po uvedení standardu BD (2006). Ruku v ruce s pokročilými formáty jde i nezbytnou implementace DRM (HDCP 1.x) v OS/APL/DR/HW, která je podmínkou pro úspěšné oficiální přehrávání.

Opet, pevazne nejde o HW kodek, je to v kombinaci se SW, ale resi to vykonostne kriticky casti (a proto na to vyrobci tech GPU trebas ani zadnou licenci nepotrebujou).

Myslím si, že toto si žádný z výrobců (U.S.A.) nedovolí, aby ve svém řešení použil v dané chvíli patentově chráněné IP. Vychutnali by si ho právníci MPEG LA. Myslím, že tito nečiní rozdíl mezi SW a HW implementací, v opačném případě by se výrobci distribucí Linuxu v USA nerozpakovali distribuovat free dekodéry.

Obecne mpeg formaty maji v dobe uvedeni HW.

HEVC(H.265) byl uveden v roce 2013. První GK s plným HW dekódováním HEVC (VLD) byla Geforce GTX 960 (uvedení 1/2015). HW implementace dekódování/encodování je logicky ve vleku SW implementací. SW se vyvíjí(případná oprava distribuje) snadněji, než návrh, výroba specializovaného obvodu (či části návrhu GPU). Prakticky lze říci, že nový standard s očekávaným rozšířením trvá HW implementovat cca 1+ generaci, vzhledem délce vývojového cyklu mi to přijde ještě jako dobrý výsledek. Samozřejmě budou existovat specializovaná řešení, která budou na trhu dřivě (jejich konkurenční výhoda), ale ty budou většinou záležitostí specializovaného(embedded) trhu.

------------------------

Jako zajímavost, někde ve sbírce mám miniPCIe karty s chipsetem Broadcom, který umožnoval BCM70012(15) dekódování H.264/Mpeg-2 a dalších a byl zajímavým (byť ne zcela praktickým) způsobem rozšíření schopností Atomů první generace s jejich skoro "záporným" výpočetním výkonem.

Zde jsou nějaké screenshoty s nimi (BCM) z pokusů před 10+ lety.

BCM70012.png

BCM70012_Turion64_Adobe_101Beta2.png

Broadcom_Crystal_HD_N270_H264.png

Broadcom_Crystal_HD_N270_H264_8RF_L5.0_MPCHC_titulky.png

Broadcom_Crystal_HD_N270_H264_L5.0.png

Broadcom_Crystal_HD_N270_MPEG2.png

Broadcom_Crystal_HD_N270_VC1.png

Broadcom_Crystal_HD_N270_VC1_MPCHC.png

Broadcom_Crystal_HD_N270_WMV3.png

Broadcom_Crystal_HD_N270_WMV3_MPCHC.png

atom_n270_bcm70012_xbmc_playing.png (taky něco v prostředí Linuxu )

bcm70015_FF_YT1080p.png (novější verze chipu/miniPCIe)