Az Intel hardveres gyorsítást fontolgat a Google WebM-jéhez

Intel

A Google a múlt héten nyílt forrásúvá tette a nem sokkal ezelőtt általa megvásárolt VP8-at, majd összehozva a Vorbis-szal és egy, a Matroska média konténer egyes részeire épülő konténer formátummal, megalkotta a WebM névre hallgató video formátumot. A bejelentés után több vállalat is jelezte, hogy beáll a WebM mögé, ahhoz támogatást szállít majd. Az Intel nem zárja ki, hogy hardveres gyorsítást kínál a jövőben a nyílt forrású formátumhoz.

A vállalat egyik képviselője tegnap azt nyilatkozta, hogy az Intel fontolóra veszi a hardveres gyorsítás beépítését a WebM-hez az Atom-alapú TV chip-jeibe, ha a formátum elég nagy népszerűségre tesz szert.

"Ahogy azt más codec-ekkel - MPEG2, H.264 & VC1 - is tettük, ha a VP8 megveti a lábát a Smart TV piacon, beleépítjük a [hardveres] dekódereinkbe," - mondta Wilfred Martis, az Intel Digital Home csoportjának igazgatója.

A részletek itt.

( ironcat | 2010. 05. 28., p – 08:30 )

Ezek szerint az intelesek nem olvassák a HUP-ot. Itt már néhány szakértő döntött arról, hogy az alkalmazott algoritmusokat egy részét nagyon nehéz hardveresen gyorsítani. A döntés ellen nincs apelláta!

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

pedig de.
"H.264 uses an extremely simplified “DCT” which is so un-DCT-like that it often referred to as the HCT (H.264 Cosine Transform) instead. This simplified transform results in roughly 1% worse compression, but greatly simplifies the transform itself, which can be implemented entirely with adds, subtracts, and right shifts by 1. VC-1 uses a more accurate version that relies on a few small multiplies (numbers like 17, 22, 10, etc). VP8 uses an extremely, needlessly accurate version that uses very large multiplies (20091 and 35468). This in retrospect is not surpising, as it is very similar to what VP3 used."

A'rpi

Ilyen megfogalmazásokkal, ködösítve lehet nagyon okosnak látszani. Ha meg lesz valósítva, akkor ő csak annyit mondott, hogy nehéz, nem azt, hogy lehetetlen. Ha meg nem lesz megvalósítva, akkor ugye ő megmondta, hogy nem fog menni. Így lehet elmondani a semmit amolyan politikus módra.

lol

sosem allitottam, hogy lehetetlen. a nagyon nehez kb annyit jelent, hogy egy nagysagrenddel bonyolultabb (tobb tranzisztor) megvalositani, mint az ipari szabvany codeceket, pl. h264 vc1 mpeg4 stb. ezeknel ugyanis fontos szempont volt a tervezesnel a hw-es megvalositas.

nyilvan meg lesz majd valositva, ha lesz ra eleg nagy piaci igeny, ill. nyomas, de kerdes mikor, es akkor is mit kezdenek a regebbi eszkozok tulajdonosai...

A'rpi

Pl. az Intel GMA950 (de azt hiszem az X3100 is, a tobbi meg nem erdekelt) behazudja, hogy 2048x2048-as texturakat tud kezelni, a valosagban viszont 1024^2-nel nagyobb texturak hasznalata eseten hw gyorsitas helyett valamilyen szoftveres megoldasra valt vissza a driver. Lenyeg a lenyeg, nem ez lenne az elso eset, hogy a beigert hw gyorsitas valojaban loturot sem ert.

---
pontscho / fresh!mindworkz

Itt nem erről van szó. Egy dolog lejátszót és kódeket fejleszteni, és a fejlesztés során a lehető legjobban kihasználni a CPU és/vagy a GPU, esetleg egy jelfeldolgozó processzor adottságait. Ehhez kell egy nagyon jó programozó, aki alaposan ismeri a kiválasztott hardverek adottságait. Egy másik dolog hardveresen megvalósítani egy algoritmust, és azt integrálni egy GPU-ba vagy DSP-be. Ehhez inkább chiptervezésben jártas villamosmérnök kell.

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

Nem zárja ki egymást, de azért a gyakorlat nem árt, mert az is egy szakma. Nem csak annyiból áll, hogy az algoritmust megadjuk, és a program kiköpi a terveket.
Ami keveset tudok A'rpiról, az alapján Ő nem chiptervezéssel foglalkozik.

-----
Innen most töltsünk tiszta vizet a nyílt kártyákba: ...

Nehez != lehetetlen. nehez azt jelenti, hogy nagyon sok tranzisztorral lehet megvalositani (p. a h264 egyszerusitett (csak osszeadast hasznal, szorzast se) integer dct-je helyett (feleslegesen) sokkal nagyobb pontossagu double dct-t hasznal a vp8, ami kb 100x annyi tranyo).
masreszt a vp8 bitstream dekodolasban is vannak erdekessegek, az aritmetikai kodolasuk nem a szabvanyos elterjedt modszert alkalmazza, hanem framenkent reseteli a tablakat es ahhoz kepest relativ ertekeket hasznal, emiatt sokkal bonyolultabb hardveresen megvalositani (egy sima linearis szamitas helyett egy elagazasokakl teli valami kell).

A masik, hogy a gyorsitas != teljesen hardveres dekodolassal. a legtobb vga csak gyorsit, ami altalaban kimerul a dct es az mc hardveres megvalositasaban (altalaban ezek teszik ki a dekodolasi ido nagy reszet), a komplex bitstream dekodolast es a perdiction-t tovabbra is a cpu vegzi. igazi full hardveres dekodert foleg embedded cuccokban, mint asztali hd lejatszok, okostelefonok lehet talalni, ahol a cpu a bitstream dekodolasra is keves lenne.

termeszetesen meg lehet oldani, maskulonben szoftveresen se lehetne dekodolni, csak az a kerdes, milyen aron, es ha ez pl. 10x annyi alkatreszt igenyel mint egy h264 akkor fog-e vele erdemben foglalkozni valaki.

A'rpi

"csak az a kerdes, milyen aron, es ha ez pl. 10x annyi alkatreszt igenyel mint egy h264 akkor fog-e vele erdemben foglalkozni valaki."

A kérdés lehet, hogy inkább az lesz, hogy olcsóbb lesz-e a VP8-at gyorsító chip-et tenni a vasakba, mint h.264-et gyorsító chip-et + h.264 licencet venni az MPEG LA-tól.

--
trey @ gépház

1. Tytso arról beszélt, hogy az alkalmazásokat úgy kéne átírni, hogy ne tételezzenek fel extra garanciákat a POSIX-ben specifikálthoz képest, nem pedig úgy, hogy "az ext4-nek jó legyen". Ez azért nagy különbség.
2. Majd miután ezt mondta, írt egy patchet, hogy mégse kelljen átírni az alkalmazásokat. Ez is elég nagy különbség.
---
Internet Memetikai Tanszék

ahol számít az adatbiztonság, ott a program írója fsync()-eljen
==
ne tételezzen fel extra garanciát a POSIX-hoz képest

Itt azért nagyon egyszerű a helyzet, mert van egy szabvány, ami alapján eldönthető, hogy kinek az implementációja jó és kié nem jó. És a Tytso annak ellenére, hogy neki volt igaza, mégis inkább kijavította a kódját, hogy ne okozzon gondot a szabványt nem teljesen jól használó alkalmazásokkal.

Várom továbbra is, hogy ez a helyzet szerinted miben hasonlít a VP8 világra rákényszerítéséhez, mert idáig én itt több különbséget látok, mint hasonlóságot. Hacsak nem az egyetlen közös vonás az, hogy utálsz mindent, ami opensource, tehát az ext4-et és Tytso-t is, és ugyancsak emiatt utálod immáron a VP8-at is.
---
Internet Memetikai Tanszék

Van egy sajátos logikája neki. Ha rájössz, fergetegeseket tudsz szórakozni azzal, hogy a logikáját direkt kijátszva hecceled. :)

Csak azért vagyok kényetelen visszafogni magamat, mert bármennyire jó szórakozás, nem itt kéne offolni, de most nem bírtam magammal (a többiektől elnézést kérek érte). Pedig milyen beszólásokat hajtottam volna még ki belőle. :)

Egyébként a kurucinfós részt utólag edittel rakta oda, mert amikor reply-t nyomtam még nem volt ott (nem is reply-oltam volna rá, ha látom).
---
Internet Memetikai Tanszék

Ez tenyleg lenyegi pont a szamitasi bonyolultsagban, hogy az egyik integer DCT-t, mig a masik double-t hasznal. De nekem ugy tunik, hogy a jovo valahol inkabb a floating pointos tomoritokben van, mert az fix relativ pontossagot ad, mig az integer fix abszolut pontossagot. Igy ha nagy pontossagra van szukseg, a floating point jobban skalazhato. Persze nem tudom, hogy emiatt dontottek-e VP8 mellett, de talan benne van.
Valoszinuleg csak gyorsan akarnak cselekedni valamit, mielott bebetonozodik a HMTL5 egy licenszelt formatumba.

( anr | 2010. 05. 28., p – 09:52 )

nesze semmi:
ha az ugyfelek igenylik, szallitani fogjuk.

max. annyi tortent, hogy az inteles mernokok megbecsultek mennyi penzbol megoldhato a fejlesztes, es nem lehetetlen osszeg jott ki, de nem is keves, mert akkor megcsinalnak, artani nem hasznal alapon.
--
Live free, or I f'ing kill you.

( Toma_ | 2010. 05. 28., p – 11:24 )

Valaki látott már ilyen cuccot, vagy csak urban legend?

"A new 45nm 1.2GHz Atom CE4100... is capable of handling decoding of two 1080p HD streams as well as picture-in-picture..."

Ahhoz képest, hogy a két magos 1.6-os atom izomból állóképet játszik egy 1080p-vel procszinten, van annyi tartalék a 264(like) kodekekben, hogy egy CE4100 megeszi? Vagy ez olyan parasztvakítás, hogy tesznek mellé még egy dual vga-t a settopba? Vagy WTF?

Éppen a leendő Little Susie feat. KDE4 egyik alpha teszt verzióját hegesztem fel egy kétmagos 1.66GHz Atom alapú netbookra,
(JW MINIX, 2x1.66GHz, 2GB RAM, 250GB HDD, Intel Pineview),
ki fogom próbálni rajta AZ ÖSSZES korábbi mkv tesztet, szoftverből, MPlayerrel.
(az ominózus SuSE 10.1-es Packman build-del is...)
Hétfőre már eredmény várható.
(borítékolom, hogy akadás nélkül lejátssza...)
-
"Attempting to crack SpeedLock can damage your sanity"

"A Sample_Children-es mkv-t ki ne felejtsd!"

Nem marad ki a szórásból, lesz még Killa_Sampla_x264.mkv is...
Kíváncsi vagyok, mit tud a vas!

Szerk:
Teszt megtörtént: Sample_Children_of... kicsit néha akadozik, de megy.
A BBC Life in blue szinte tökéletes, egyszer kattogott kicsit,
a Star Trek minta szintén majdnem hibátlanul,
de a Killa_Sampla_x264 azért megfogta a kis netbook gépet,
amikor már millió apró madár repül a képen, ott simán elvérzett...
Szerintem ennyi is szép eredmény volt. (szoftverből)
(ha alkalom adódik még rá, megnézem mplayer-vaapi-latest segítségével is,
elméletileg a gépben lévő integrált intel vas már alkalmas lehet rá)
-
"Attempting to crack SpeedLock can damage your sanity"

Engem nem érdekel, hogy soppolt vagy nem pajti, vagy, hogy hogyan csinálta, de kurvára érdekes, hogy ennek a filmnek már az audio rátája is egy általam leszedett sample esetében a _2,5_ szerese a hunger félének. Ha kicsit lejjebb mégy akkor láthatod, hogy én sem azt mondtam, hogy nem játszik le egyetlen 1080p filmet sem a duál atom. Lehet játszani a kódolással, de ilyen alapon bármilyen gép lejátszik bármit.
Érdekes, hogy a video bitrátát meg teljesen lelopták a screenshotról. Azémá engedtessék meg nekem egy LOLXD...

Mondjuk a linux supportját nem ismerem (az elmondottak alapján lehet, hogy szerencsére?), de a Poulsbo-ban van támogatás h264 lejátszás gyorsítására (nyilván kérdéses, hogy pontosan melyik részekre, iDCT, MC nyilván van), míg a GMA950-ben gyakorlatilag nincs. És ezt windows alatti benchmarkokban elég jól ki is hozták.
---
Internet Memetikai Tanszék

Isten ments, hogy vitatkozzam, igazad van. Ezek szerint engem átbasztak Intelék, hamis a processzorom, vagy lassú a monitorom, vagy szimplán minden harmadik 1080-as sample vírusos amit próbáltam. A youtubon is figyelik az IP-m és belassítják a hd videókat csak nekem.
Majd túlteszem magam rajta valahogy, még az a szerencse, hogy nem is érdekelnek a hd filmek.

http://imagerz.com/QEMSCktvAwJXBw1EQgVR

S mivel probalod lejatszani?

CoreAVC + cccp-project.net -es megoldast hasznalom. De DXVA-t is megprobalhatnad uj ffdshow-al.

ui.: Nekem XP fut a vas alatt, Win7 erosen overkill kategoria atomra velemenyem szerint, elegge visszafogta, nagyon lassitott, szerintem ott mar gondjai lennenek vele. (Foleg Aero-val ...ugy meg vegkepp. Rakd at klasszikusra/basic-re. (bar nekem klasszikuson porgette folyton agyon a cpu-t 100%-on... nem valo arra win7))

( bsh | 2010. 05. 28., p – 11:28 )

tulajdonképpen a cpu is egyfajta hardveres gyorsítás...