( hajbazer | 2020. 05. 27., sze – 20:03 )

A hw teljesítményét ma is ki lehet használni, nem tiltja semmi.

A lényeg: minél optimálisabban kihasználni. Ami jelenleg az lenne, hogy minél kevesebb energiát kelljen elfogyasztania a processzornak, minél kevésbé melegedjen és öregedjen ezáltal, így minél tovább tarthasson. Ez lenne a felhasználó érdeke, bár egyesek biztos szeretik kidobálni a gépüket.

Én inkább a lehetőséget látom ezekben, sok bloat miatt egyre jobb hardverekre lesz igény, ezért ezek egyre olcsóbbak lesznek, viszont a jól megírt dolgok gyorsabban fognak futni.

Addig lehetnek egyre olcsóbbak, amíg lesz elég kínai rabszolga, aki olcsón legyártja őket és kibányássza a nyersanyagokat. Mondanom sem kell, hogy ennek örülni nagyjából olyan, mint az atomkatasztrófáknak, bár biztos, hogy Fukushima idején is voltak páran, akik örültek, mert sok mérőműszert eladhattak. Így teremti meg a kapitalizmus a káronszerzést és láttat lehetőséget önmagunk és a környezetünk elpusztításában. Büszke lehetsz magadra.

Ugyanazon videó lejátszásához nagy valószínűséggel ugyanaz a c/asm library, vagy már cpuba/gpuba integrált dekóder lesz 10 év múlva

Nem, 10 év múlva ott lesz a Google 10. dekóder-idealizmusa, miszerint "túl milliárdosak vagyunk ahhoz, hogy kifizessük a H.264 után a licencdíjakat, inkább írjunk sajátot", "jaj a VP8 nem sikerült annyira jól, írjunk VP9-et", "jaj a VP9 sem sikerült annyira jól, csináljunk AV1-et". Jelenleg ott tartunk, hogy szarrá kell kiegészítőzni egy Chrome-ot ahhoz, hogy H.264-ben jöjjön le a videósáv és ha szerencséd van azt tudja valami hardveresen dekódolni. Mert a VP9 és egyéb idealizmusokhoz csak Kaby Lake-től elérhető hardveres dekóder. Az AV1-hez meg még egyáltalán nem.

Ha szigorúan CPU-dekódolást nézünk, akkor ma egy videólejátszás egy böngészőben 2x-3x annyi CPU-t használ el, mint egy natív videolejátszóban. Azt én értem, hogy ugyanaz a libx264 és libvpx van mögötte, mint amivel a VLC is dekódol, viszont afölött meg minden más erőforráspocsékolóbb, bloatabb, gányabb, tákoltabb. Ezért is fordulhat elő, hogy egy Youtube-ról letöltött Full HD 60 FPS H.264 videót a 2007-ben vett AMD Turion 64-es laptopom is le tud játszani 70% CPU-ból, miközben böngészőben ugyanez a videó akadozik. Igen, nem csak Windows XP-n, ahol soha nem volt értelmes hardvergyorsítás, hanem Windows 7-en, ahol állítólag van. Ja nincs, mert elfelejtették megírni a régi videokártyámhoz, így jártam, vennem kéne új gépet, termelnem kéne az elektronikai hulladékot, mint minden normális™ ember. A Google pedig túl milliárdos ahhoz, hogy épkézláb API-t vagy felületet használjon videorenderelésre pl. overlay, sync, vmr9, akármi, a saját bloat szarkupaca (2D Canvas) helyett. Linuxon is ugyanez a helyzet, ott is mindkét mag 100% CPU, videó akadozik, az erőforrás nagy részét az Xorg és a chromium zabálják el. Érdekes, egy VLC-vel ott is képes jól menni, bár több CPU-t zabál, mint Windows XP-n.

Egyéni szinten inkább pl a lakásod/házad energiafelhasználásának javításával lehet sokkal kevesebb energiát fogyasztani, nem a facebookos másodperc lecsökkentésével.

Ezzel tisztában vagyok és teszek is érte. A Facebook-os másodperc nekem egy személyben sokkal jobban kiábrándító, mint környezetszennyező. Mondjuk úgy, az egész IT szakma egyik nagy szégyene. Ha viszont felszorzod a Facebook-felhasználók számával, akkor sokkal inkább környezetszennyező, mint kiábrándító.

Nem kliensre gondoltam, hanem egész videómegosztóra, állítólag a Youtube lassú :P

A Youtube webes felülete lassú, nem "a Youtube". A Youtube H.264, VP9, AAC és OPUS streameket küld, amiket le lehetne játszni natív lejátszóval is, böngésző helyett. Ehhez kéne kliens.