youtube közbenproci100% -ra

Közösségi kerekasztal

Főleg ha YouTube videót nézek,
de akkor is, ha csak alapvető funkciókra (Gmail, Duolingo, Facebook) bármelyik böngészőt használom gyakran felugrik ez az ablak: http://imgur.com/Namifmo
Közben a videó szaggat,laggol.

Közben ahogy nézem a proci közel 100% -on megy, látszólag minden különösebb ok vagy munkafolyamat nélkül...
CPU: http://imgur.com/cxipIF0

Ha a Javascript -et letiltom akkor egész jól megy, látszólag a proci is úgy teljesít ahogy kell neki, csakhogy JS nélkül kb. egy oldal sem megy normálisan amit használok.

Rendszeradatok:
Memory: 3.6GB
CPU: AMT Athlon X2 Dual-Core QL-65x2
System: Debian 8 (Jessie) X64
Desktop: GNOME 3.14.1
Böngésző1: Firefox ESR 45.3.0
Böngésző2: Chromium Version 52.0.2743.116 Built on 8.5, running on Debian 8.5 (64-bit)

Már rég ez a rendszer van, de csak pár napja kezdődtek el a gondok, eddig még nem tudtam rájönni mi a probléma, ötletek?
------
A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.

Script: https://sdk.amazonaws.com/js/aws-sdk-2.3.6.min.js:24
------

( Czo v | 2016. 08. 31., sze – 17:41 )

Nincs fenn egy darab extension se? Minden oldalon az AWS SDK okozza a problemat?

---
Apple iMac 27"
áéíóöőúüű

toltam a GNOME -ra egy Reset -et de nem oldotta meg.

rm -rf .gnome .gnome2 .gconf .gconfd .metacity .cache .dbus .dmrc .mission-control .thumbnails ~/.config/dconf/user ~.compiz*

mkdir ./.old-gnome-config/ && mv ./.gnome* ./.old-gnome-config/ && mv .gconf* ./.old-gnome-config/ && mv ./.metacity ./.old-gnome-config/ && mv ./.cache ./.old-gnome-config/ && mv ./.dbus ./.old-gnome-config/ && mv ./.dmrc ./.old-gnome-config/ && mv ./.mission-control ./.old-gnome-config/ && mv ./.thumbnails ./.old-gnome-config/ && mv ~/.config/dconf/* ./.old-gnome-config/

( ncc1701 | 2016. 08. 31., sze – 18:56 )

Nekem egy i3-at megfog a youtube ubuntu+chrome kombóval. Innen kezdve már semmin nem csodálkozom.

chrome://flags/

Engedélyezni kell: Override software rendering list

Akkor jó, ha a chrome://gpu/ oldalon minden zöld. Lásd: http://kepfeltoltes.hu/160831/Screenshot_at_2016-08-31_21_55_33_www.kep…

A YouTube már egy ideje VP9 codec-et használ, amit egyetlen egy GPU sem tud hardveresen gyorsítani, kivéve az Intel Skylake-be integráltakat és a mai nap bejelentett Kaby Lake generációt.

Még egy dolog: Chromium helyett érdemesebb lenne a Google Chrome-ot kipróbálni.

( hajbazer v | 2016. 08. 31., sze – 19:45 )

Nem értem, miért csodálkozik ezen bárki, amikor egy böngésző még mindig nem arra való, hogy videót játssz le rajta. A böngészőfejlesztők továbbra is képtelenek/lusták normálisan kioptimalizálni a videólejátszást, ezért továbbra is 2x-3x annyi erőforrást eszik, mint ha natív lejtászóval játszod le. Ezt világszinten gigawattórákban lehet mérni. De a közöny itt is nagy úr. Senkit nem érdekel. Vegyél új gépet, dobd ki a régit. A régivel persze semmi baj, csak az, hogy szoftverfejlesztőék szarnak bele mindenbe és időről időre csak a legcsilibb-legvilibb hardverre optimalizálnak. Ha meg megkérdőjelezed, akkor gátolod szent és sérthetetlen gazdasági növekedésünket, mert arra biza nagyobb szükség van, mint fenntarthatóságra, vagy normális szoftverekre.

Félretéve a szarkazmust, alternatíva lehet a MiniTube és megannyi alternatívája vagy a 3D YouTube Downloader, aminek saját keresője is van (ki se kell nyitnod a böngészőt), ráadásul több szálon tölt le, elég hamar megvan egy gyors nettel. Ha pedig csak zenét akarsz hallgatni, letölti neked csak a hangsávot, ezáltal 10x annyi tárterületet/sávszélességet és 40x-50x annyi erőforrást spóroltál.

Ez nagyon erős csúsztatás, ~ ugyanannyit eszik a böngészős lejátszás, mint a "natív". Csak a böngészőben letöltés is van.
Teszteld le nyugodtan, szedj le egy pl. 720p-s videót, nézd meg a natív lejátszóddal, majd nézd meg a böngészőben hdd-ről. Szinte semmi különbség. Nyilván ha letöltés közben nézed, akkor többet mutat, dehát letölt, ami használja a procit. És nyilván olyan oprendszeren kell nézni, amire a legtöbb böngészőt fejlesztik hw támogatásra. Vagy nézheted linuxon is, de akkor a natív lejátszónak mondd, hogy sima gl-lel játsza le. Most néztem W7-en egy ősrégi 32 bites Chrome-mal, amit már nem is fejlesztenek rég, ~ 8%-on játszotta le a Vlc is és a Chrome is. Ha 3x annyit zabálna, ahhoz már cefetül el kellene cseszni a kikódolást, az szándékosan is nehéz!

Általában egy natív lejátszás és egy böngészős lejátszás között a különbség SD videóknál 30% CPU, HD videóknál akár 80%, nyilván processzortól függően. Itt most régebbi, 2011 előtt gyártott gépekről van szó. Természetesen sokat belekomplikál a hardvergyorsítás hiánya, vagy a gyengén implementált hardvergyorsítás, ami a böngészőkre jellemző (gondok, lassulások és driver workaround-ok nélkül igen kevés hardveren tökéletes). Arról sem tehet az egyszerű felhasználó, hogy Google-ék és Mozilláék képtelenek voltak elszakadni a GL-től. Teljesen értelmetlen GL-ben renderelni a natív lejátszó videóját, amikor vannak ennél sokkal kifinomultabb renderelési felületek a videókhoz, persze OS-től függően. A szoftveres GL gyorsításnál pedig nincs rosszabb (amit a böngészők előszeretettel használnak fallback-nek).

Azt pedig ne magyarázd be nekem, mert itt helyben fejbelövöm magam, hogy egy letöltés ekkorát rárak. Egy 1 MB/s leöltés max. 1-2% CPU még egy 2005-ös gépen is. Ha a böngésző ezt a sokszorosával képes csak megoldani, akkor pedig ugyanott tartunk, ahonnan kiindultunk: a böngészők a legerőforráspazarlóbb teremtmények. És ez így van.

Én annyit állítottam, hogy egy böngésző nem videólejátszó és soha nem fog olyan teljesítménnyel és hatékonysággal dolgozni, mint egy videólejátszó. És ez is így van. Lassan már 10 éve, hogy a böngészőket videólejátszásra használjuk, szerencsére a világszégyene-hányadék-tákolmány Flash-t is sikerül végre elfelejteni, de a böngészők még mindig messze lemaradnak a natív lejátszóktól.

Csúsztatás helyett pedig úgy mondanám, tapasztalat. Ha nagyon szkeptikuskodsz, kimérem neked egy régi gépen pontosan a különbséget. SVPTube és társainál, amik képesek online stream-elni a videót a natív lejátszóba is kijöttek óriási különbségek.

Meg tudom erositeni, teszteleseim alapjan csak az IE Edge tud nativhoz hasonlo videoljatszasi teljesitmenyt (legalabbis win alatt):

Ebben a redddit topicban osszeszedtek kulonbozo gepek Chrome vs Edge eredmenyeit:
https://docs.google.com/spreadsheets/d/1-13z0PxIURutvTBzxaekdFUr9ImeQi0…

Ebbol latszik, hogy ugyanazon youtube video lejatszasa kozben szinte minden konfiguracion 200-300%-al tobbet eszik a Chrome, mint az Edge.

( lx | 2016. 08. 31., sze – 20:42 )

Nem tudom, ma éppen hol tart a FF (pár körülmény ahhoz köt), és már nem is járok utána: amikor utoljára megtettem, végleg tudomásul vettem, hogy akármit mond a zilla, előbb fogok én 3 herével élni, mint a FF egynél több processzorral.

( norbertkiss | 2016. 08. 31., sze – 21:42 )

Nekem hasonló gondom volt. Szintén Debian 8. Asszonynak ugyanolyan laptopja van mint nekem, csak neki Xubuntu van fent, ott minden ok. Akkor jött az ötlet, hogy mi lenne, ha az opensource nvidia drivert lecserélném zártra. Miután ez megtörtént, a video lejátszás közbeni cpu terhelés visszaesett 100%-ról 15-20%-ra...

erre én is gondoltam anno

Sajnos
Acer 5536 -ra
(ATI Radeon HD 3200)
csak open volt ,azzal kellett beérnem,
még azt is csak nehezen leltem meg ubuntu alatt, debi meg azonnal felpakolta szóval nem tudom kiféle-miféle az ami van, csak azt tudom hogy eddig nem volt vele gond

( luisex v | 2016. 09. 01., cs – 10:13 )

Szia,
Ez(https://www.x.org/wiki/RadeonFeature/) alapján az opensource radeonnak meg kellene adnia neked a kellő HW gyorsítást..
Nem futtatsz véletlenül valami kompozitort, ami megeszi a gépedet? ( Pl. compiz )
Ezenkívül milyen driver fut ténylegesen (glxinfo | grep renderer kimenetéből látszik :) )?
Üdv,
LuiseX
U.i: Ez ( https://wiki.debian.org/AtiHowTo ) esetleg ellenőrízhetnéd, hogy a firmware-t sikeresen betölti-e a radeon driverhez

Szia,
Például:
glxinfo | grep render
bemásolod ide a kimenetet, és megokoskodjuk, hogy jó driver fut-e :) (nálam minden kártyánál fglrx fut, ezért nehezen lesem meg, pontosan milyen kimenet kellene :) )
Üdv,
LuiseX
Szerk: Esetleg kicsi rókából az about:support , Grafika blokk lehet még hasznos

root@digitalmech:/home/d0m# glxinfo | grep render
direct rendering: Yes
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer,
OpenGL renderer string: Gallium 0.4 on AMD RS780
GL_MESA_texture_signed_rgba, GL_NV_conditional_render, GL_NV_depth_clamp,
GL_NV_blend_square, GL_NV_conditional_render, GL_NV_depth_clamp,
GL_OES_fbo_render_mipmap, GL_OES_get_program_binary, GL_OES_mapbuffer,
root@digitalmech:/home/d0m#

Szia,
Ez igazából rendben lévőnek fest, úgyhogy a nyomok szerint ez az ötlet mellé ment :)
(Legalábbis, ha emlékeim nem csalnak a Gallium be lett olvasztva a radeonba, így teljesen rendben van a dolog :) )
A firefox mit ad az about:support lap grafika blokkjába?
Üdv,
LuiseX

Graphics
Adapter Description X.Org -- Gallium 0.4 on AMD RS780
Asynchronous Pan/Zoom none
Device ID Gallium 0.4 on AMD RS780
Driver Version 3.0 Mesa 10.3.2
GPU Accelerated Windows 0/1 Basic (OMTC)
Supports Hardware H264 Decoding No;
Vendor ID X.Org
WebGL Renderer X.Org -- Gallium 0.4 on AMD RS780
windowLayerManagerRemote true
AzureCanvasBackend cairo
AzureContentBackend cairo
AzureFallbackCanvasBackend none
AzureSkiaAccelerated 0
CairoUseXRender 1

Szia,
Ezek alapján úgy fest, hogy a hardveres videógyorsítás üzemel, és használatban is van..
Így, a lassulás alapján inkább arra tippelnék, hogy valami más eszi meg a böngésző alól a vasat, vagy valamelyik absztrakciós réteg hibádzik.
Sajnos ezekben annyira nem vagyok járatos, de ha akad valami ötletem, akkor azonnal szólok :)
Üdv,
LuiseX

Szia,
Új nap, új ötletek:
A dns feloldásod rendben van (próbáld meg dns-nek mondjuk a 8.8.8.8-at beállítani)?
Ha megpingetsz pl. egy youtube.com-ot, milyen válaszidővel ténykedik?
A harmadik pedig, nem lehet, hogy megpróbálkozik a rendszer ipv6-al, miközben a hálózatod csak ipv4-es?
Üdv,
LuiseX

YouTube PING
root@DigitalMech:/home/d0m# ping www.youtube.com
PING youtube-ui.l.google.com (216.58.214.238) 56(84) bytes of data.
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=1 ttl=56 time=3.43 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=2 ttl=56 time=2.98 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=3 ttl=56 time=3.31 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=4 ttl=56 time=3.23 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=5 ttl=56 time=3.36 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=6 ttl=56 time=3.25 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=7 ttl=56 time=3.33 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=8 ttl=56 time=3.37 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=9 ttl=56 time=3.25 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=10 ttl=56 time=3.32 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=11 ttl=56 time=3.29 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=12 ttl=56 time=3.48 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=13 ttl=56 time=2.62 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=14 ttl=56 time=3.34 ms
64 bytes from bud02s24-in-f14.1e100.net (216.58.214.238): icmp_seq=15 ttl=56 time=3.33 ms

( LMoon | 2016. 09. 01., cs – 14:40 )

Nekem is hasonló lassulás/akadozás dolgok tűntek fel, nekem egyértelműnek tűnt,
h ahol js van ott történt ez a változás.
P. az fb (ami ugye tele van js-el) rendszeresen akad, nem válaszol állapotba kerül tőle a böngésző (FF, Chrome).
Ja és ez 3 gépen is tapasztaltam. Mind Debian alapú.
Csak böngésző frissítések kerülhettek fel, OS mostanában nem.

én múltkor teljes update & upgrade futtatást csináltam elég sok frissítés jött, de böngésző az tuti...sajnos a firefox esete egyébként linuxon és windows -on is gyakran az hogy kijön egy új aztán szar, kijön egy frissítés rá aztán megy amíg nem jön megint egy ami megint elszúrja... :/

Csak hát nem frissíteni meg veszélyes, de legalább ne ezt neveznék stabilnak, milyen lehet akkor a béta-tesztelés?!?!

Na mindegy, nem mondom hogy ez FF hiba lenne most, mert a chromium is hasonlóan szívat, de a pakliban benne van

( KaTT | 2016. 09. 01., cs – 16:21 )

Nekem Firefox alatt az volt a megoldás, hogy újratelepítettem teljesen (töröltem az összes profiles-ben lévő fájlt, stb). Üres profillal jó lett.

Sakk-matt,
KaTT :)

( ang | 2016. 09. 01., cs – 18:20 )

nekem a youtube-dl + mpv combo vált be, openwith ff extension-el meghívva

http://www.yt-dl.org/
https://mpv.io/

https://addons.mozilla.org/en-US/firefox/addon/open-with/

---

nyilván ízlés kérdése, de nálam a qutebrowser van éles használatban hétköznapi böngészésre, gyorsabban tölt mint az ff, kisebb a cpu használat sok tabbal, beépített host alapú adblock filtereket tartalmaz, és nem pazarol a toolbarokkal a látható képből

https://www.qutebrowser.org/

http://www.cnx-software.com/2016/06/29/improve-youtube-video-playback-o…

esetleg ez megoldás?

A youtube-dl+mpv-t azért szeretem, mert mintha jobb képminőséget kapnék, illetve jobban lehet scrollozni, mint a böngészős kliensekben. Eredetileg flashplayer kiváltására használtam, manapság a html5 korában már nem lenne rá szükség, de megszoktam, megszerettem.

Azt nem tudod, hogy gdrive-on levő videóknál milyen előnézeti linket kell megadni a youtube-dl-nek ha az előnézeti (azaz gúgli által generált kisebb felbontású) videót szeretném letölteni?
Pocsék internettel ellátott helyeken néha jól jönne. És az oldaluk szerint az utóbbi frissítések óta már kezeli a gdrive videókat is.

( uid_16313 | 2016. 09. 03., szo – 09:28 )

Tégy egy próbát a vivaldi-val.

--
robyboy

( uid_16313 | 2016. 09. 03., szo – 18:37 )

Mikor takarítottad a gépet, hűtőbordát, stb?
Simán lehet, hogy a por miatt már csak elégséges a gép hűtése.

--
robyboy