Výkonnosť HD videa v internetový prehliadačoch

9.1.2016 19:22 | Linux | poslední úprava: 9.1.2016 19:22

Spriemerované výsledky môjho malého testu prehrávania HD YouTube videa v internetový prehliadačoch pod Linuxom zoradené od najmenej po najviac CPU náročný spôsob prehrávania:

1. 70% - MPV (Watch with MPV rozšírenie pre Firefox)
2. 90% - Firefox s Flashom
3. 100% - Chrome
4. 125% - Firefox s HTML5 prehravacom

Spúšťanie externého prehrávača ako MPV hoci aj formou rozšírenia nie je síce pohodlné, ale v mojom prípade prehrá video s najmenším vyťažovaním CPU vďaka HW akcelerácii cez VDPAU (mám Nvidia GPU). Flash pod Linuxom má u mňa tiež zapnutú HW akceleráciu, takže je rýchlejší ako HTML5 videá pod Firefoxom a Chrome, ktoré HW akceleráciu a skladanie (existuje lepší preklad pre HW compositing?) neumožňujú alebo umožňujú len čiastočne.        

Obrázky

Komentáře

[pc2005]

Bez VDPAU nebo něčeho ekvivalentního dá mplayer na mým C2D T7200 snad i 1080p h264, flash 720p s odřenejma ušima a html5 se seká i při 360p.

[Max]

A vem si, že už je k dispozici 4k. To jsme to dopracovali, ani na C2D si už nepřehraješ ani video :)
Zdar Max

[marek_hb]

já tohle vyřešil nožovou transformací patice 775 na 771 a výměnou C2D E6600 za XEON 5450 a flashem biosu ... - za nějakých 1100 z aukra sakra dobrá věc :) - děkuju tímto poradne na zive.cz :)

místo 2x2.4 4x3.0 se vyplatí :)

[pc2005]

Jo to se máš, já mám socket M (a u mě je rychlejší jen T7400 a T7600(g)). Kdyby neudělali socket P pinově nekompatibilní, tak jsem mohl mít až čtyřjádro .

[Dreit]

Posílám za kolegu Zaatharena:

 

Ahoj, socket M podporuje maximálně dvoujádrová Core2Duo CPU generace Merom na 65nm procesu, původně vzniknul na Core Duo, což bylo takové nedokonalé Pentium M s dvěma jádry a v době kdy neměli koupené x64 instrukce od AMD. Když přišla C2D T5xxx a T7xxx přišel i pak socket P s rychlejším FSB, správně píšeš, že top CPU na socket M je T7600. Socket P kromě rychlejšího FSB přinesl tuším lehce jiné napájení snad + digitální snímaní teplotních čidel v CPU, to ale podporuje až Penryn.

Socket P v první iteraci byl typicky z 965kou chipsetem a 800FSB v roce 2007. TOP CPU je tam T7800, v roce 2008 s příchodem Penrynu se TOP CPU stala T9600, socket P získal druhou iteraci získáním 1066FSB s Intel PM45 či GM45 chipsety a také první mobilní quad-core ale má to velká ALE.

Quad-Core CPU fungují v socketu P, ale JEN v malém množství notebooků. jednak mají TDP 45W + ale jinak trochu komunikují s chipsetem, je jen malé množství notebooků co je podporuje a umí s tím pracovat, pokude se tedy bavíme o Q9000/91000 či QX9300.

Pokud máš ntb co má socket P a FSB1066 velmi zajímavá CPU na tento socket jsou P9700, T9900 a X9100, jen ta X9100 má dsot vysoké TDP.

[pc2005]

Však jo. Tak u frekvence FSB není problém udělat zpětně kompatibilní časování, digitálního čidla, což jsou tak dva GPIO (z 478 pinů) a napájení, což by mohl být trochu problém, ale třeba u FPGA se dají IO banky napájet téměř libovolným napěťovým standardem, u Vcore není problém udělat prostě milion kroků (~20 pinů z 478) v rozsahu 0-2V a bude to stačit navždy, navíc vzhledem k tomu, že u tualatinu byl problém stejnej. Kromě toho je to pak prostě jenom o tom, že jsou ty piny na jiném místě v identickém socketu. Pořád to je 64 datovejch pinů a tak 36 adresovejch.

Tak ke quad core jsem se zatím nedostal a asi už nedostanu, to už si rovnou koupim ARM v BGA a nemusím řešit kompatibilitu podobných socketů .

[pc2005]

Tak předchozí komp byl duron 666MHz, na něm nešlo ani h264 360p v mplayeru .

[Max]

Ou ...
Já mám Phenom II X4, bráchům jsem složil PC z Phenom II X6 + všude nvidia (GTS450, nebo GTX680) + SSD.
standardní kancelářský PC v naší firmě je Intel i5 + 8GiB
Zdar Max

[marek_hb]

když si vzpomenu, že na takovém duronu jsem dohrál H&D II ....

[pc2005]

Když si vzpomenu, že jsem na něm kompiloval celý gcc .

[kotyz]

já hrál wowko pod wine na PIII 1GHz + 512MB SDRAM a šlo to. když sem to samý zkoušel pozdějc na lepšim stroji - Athlon XP 2GHz + 2GB DDR1 a lepší grafika, sekalo se to jak prase. a to byl rozdíl jen pár let a asi tři datadisky. pokrok nezastavíš...

on by ten athlon na lecos stačil ještě dneska, ale obrovskej problém je že nemá instrukční sadu SSE2, takže už hromada věcí nefunguje, včetně například všech novějších verzí openoffice, flashe, pětková plasma a kwin, steam, secondlife, google earth a spousta dalšího. prostě se to nespustí nebo to okamžitě padne na sigill :-/

mam v plánu přendat disky do jinýho kompu kde je sempron, stejně slabej, možná i slabší, ale 64bitovej postavenej na novějšim jádře se všema potřebnýma instrukcema. teď mi kde4 kterej už je vyhozenej z repozitářů blokuje i všechny ostatní updaty a přejít na pětku na tomhle procesoru nemůžu, zůstal bych jen s kurzorem na černý ploše, oveřeno 2x...

[marek_hb]

ono to tak prostě je - já s tou C2D byl v podstatě taky v pohodě na většinu věcí, ale u videa jsem byl pro změnu v hajzlu... - tenhle xeon na stejném zbytku sestavy (8600GT nvidia, 4 GB RAM a deska EP35DS4 od gigabyte) dává s klidem 4K video a ještě se nudí. před tím jsem byl rád za trochu plynulé 2.7K....

[Ovocníček]

Jojo, u Athlonu XP je to SSE2 škoda. Když kolem roku 2011 začínalo 10-bitové H.264 (u anime), tak si s nima lidi dost stěžovali, že to cpu někdy (s velkou bitrate) nedávalo ani některý scény v 720x480p24. Co jsem to zkoušel, tak 1,8GHz Thoroughbred nestíhal v některejch scénách, tipuju, že v fmpegu mohl být kód, který neměl SIMD asamblér v MMX2, ale jenom SSE2. Teď jsem našel tak nějak v popelnici 1,91 GHz Barton, možná bych to moh zkusit s ním. Ale ono dneska už jsou v těch popelnicích i K8čky, takže už to nemá praktickej smysl.

[Max]

Nemusíš zkoušet Barton 2500+ si to nedává.
Zdar Max

[Ovocníček]

Ono to záleží i na tom, kolik CPU komu sežrala režie vykreslovače v ovladačích grafiky a tak, a tak mi trošku přišlo, že to mohlo být na hraně. V těch dobách jsme sám ještě měl jenom 2Ghz A64 3200 (dokonce i na enkódování, haha), kterej problémy neměl.

Ale těch 1912 nebo kolik MHz u AXP 2600+ je proti AXP 2500+ (to mělo tuším 1833 MHz) jenom 5% taktu navíc, takže to asi dost nebude. Holt zátěžový špičky jsou u softwarovýho dekódování svistvo. Všechno vypadá v pohodě, a pak je nějakej zvláštní švenk, pohyb nebo scéna s ohňostrojem a bum, 100% CPU a je po realtime playbacku :)

[pc2005]

ffmpegu mohl být kód, který neměl SIMD asamblér v MMX2, ale jenom SSE2

Tak ve ffmpegu byly šílenosti jako dekodér pro XScale. Nějaký SSE/MMX/3DNow by tam bylo tak od začátku IMO. Nehledě na to, že se SSE generuje v gcc přímo (když není asm optimalizace a dělá se to přes C).

[Ovocníček]

Já myslel integerový SIMD asamblér v dekodéru, ten se při dnešních (a tehdejších) autovektorizačních schopnostech překladačů dá udělat jenom ručně, takže když není, tak smůla. SSE1 při dekódování H.264 není podstatné, použitelné je buď MMX/MMX2, nebo až SSE2, které mají celočíselné datové typy.

[pc2005]

Jo vlastně SSE1 byl float orientovanej (i když třeba lamemp3 používá FPU pro FFT). Ale podle wiki to gcc umí. Sice kvalita asi nebude nic moc, ale pořád to bude o trochu rychlejší než pre-PentiumMMX kompatibilní kód. BTW na duronu byla ještě 3DNow a i její povolení v x264 mírně zrychlilo enkóding (i když i tak to bylo o hodinách na pár minut reálného času videa ).

[Ovocníček]

3DNow nemohlo významně pomoct, je taky pro floating point, což x264 nepoužívá mimo propočty ratecontrol. Pravděpodobně to bylo jenom placebo nebo nějaká jiná optimalizace. Lame může SSE/3Dnow používat, protože všechny běžné ztrátové audio kodeky (vorbis, mp3, aac, opus) pracují s floating point daty.

[pc2005]

Nedělá se někde během kódovaní/dekódování h264 nějaký převod mezi frekvenční a časovou oblastí? Tam by šel použít float i když integer algoritmus bude lepší. Nejspíš to placebo bylo (a/nebo se možná použilo lépe MMX), ten duron ale SSE vůbec nepodporoval. A oproti slackware distribuční verzi to jelo rychlejc.

[Ovocníček]

Distribuční verze mají někdy neoptimální nastavení z různých důvodů (třeba PIC je taková "populární volba", IIRC). Video kodeky používají všude kde můžou integery, protože je to nativní formát dat a všechno je s nimi rychlejší + deterministiké (kdežto přes FP by člověk mohl dostat různé výsledky, což je u bit-exaktních kodeků problém).

U mpeg2/4asp se ještě floating point v DCT používal, ale novější/lepší formáty mají transformaci přesně definovanou a používaá jen integerovou matematiku. V x264 se fp používá jenom na rozpočet dat v ratecontrol. Trošku významěnšjí použití je v ní od té doby, co se používá algoritmus mbtree, který počítá důkladněji kvantizéry pro jednotlivé bloky podle jejich "referencovanosti" a ten výpočet je ve floating-point. Ale kromě nejrychlejších presetů by to neměla být významná operace co do spotřeby CPU.

[Grunt]

Tak není žádným tajemstvím že žádný z webových prohlížečů (pokud jo, prosím o opravdu), pokud vyloženě nemá nějaký plug-in nepřehrává v default do Xv. A přešmourat 2Mpix z YUV do RGB nějaký čas prostě zabere. K přehrávání videa v HD rozlišení není potřeba VDPAU. To už by měl dát s pomocí vyladěného mpv jakýkoliv dnešní počítač i softwarově, ne?

[R]

Co je "dnesny pocitac"?

[kotyz]

řek bych že minimum bude dvoujádro na 2 GHz, cokoliv horšího musí bejt cca 8-10 let starý...

[Ovocníček]

Ty kráso to je hrozný, jak to běží.

U nás doma je ještě v občasným provozu jednojádro a teď mi dochází, že už to PC má přes deset let. Bez poruchy až na příšerný 40mm větráčky na chladičích a jednu vypalovačku, co přestala vypalovat DVD. Jo a vyměněný/opravený podsvícení na LCD po necelejch třech letech, naštěstí ještě těsně v záruce.

[kotyz]

mam doma i starší kousky který fungujou, třeba to PIII 1GHz, jen to už prostě nestíhá požadavky doby. to už nemá cenu ani zapínat, je to utrpení. ale mohlo by to bejt dobrý do muzea, nahrát tam dobovej soft, třeba win 98 (dokonce to má myslim na 98 i originální COA štítek) a nějaký starý hry. a byl by to dobrej exemplář jak moh vypadat hi-end v roce 2000

[kotyz]

i ten 17" crt monitor k tomu mam, taky funguje, ale dneska už nikdo do něčeho takovýho koukat nechce. nechápu jak sme to tenkrát mohli vydržet, čumět do toho celý hodiny...

[Ovocníček]

To jo, CRT = hrůza, fakt nechápu lidi, co to ještě dneska hájí. Taky mám funkčního PIII 666 MHz, ale s 256 MB RAM se s tím moc srandy užít nedá.

[R]

Kvalitny a spravne nastaveny CRT monitor je v pohode. Lenze v X11 to bol vzdy problem - rucne sa patlat s modeline... Vo Windows staci jednoducho nastavit napr. 85 Hz.

[Agent]

Na filmy zlatý CRTčko. I na hraní se ještě donadávna používaly.

[pavlix]

Nevím jak dneska, ale ještě před pár lety byly LCD obrazovky znatelně pomalejší v překreslování. Já jsem nikdy nehrál hry, kde by to mělo vliv na hratelnost, ale viděl jsem to i při běžné práci třeba při pohybu okna.

[Ovocníček]

LCD měly spoustu chyb a tehdy ještě více než dneska, ale proti CRT to fakt už třeba v roce 2005 bylo nebe a dudy. A to jsem neměl úplně nejhorší CRTčko. I přes tu absenci problémů odezvy, pozorovacích úhlů (a ještě třeba prosvítání a nerovnoměrnost podsvícení) to byla technologie, u který jsem rád, že je pryč.

A to bych přitom klidně i odpustil tu hrůzu, jakou bylo stěhovat to ručně vlakem na kolej, hahaha.

[Michal Kubeček]

V určitých kruzích je zvykem zdůrazňovat nevýhody LCD a nevýhody CRT zamlčovat. Takže se třeba řeší (nebo spíš donedávna řešily) pozorovací úhly, ale že při pohledu z úhlu byl obraz na CRT monitoru (geometricky) zkreslený až běda (a na "plochých" CRT byl zkreslený i zepředu), to je tak nějak v pohodě. Že můj poslední CRT monitor (a to byla "pouhá" 19") měl běžnou pracovní spotřebu 90-100 W, na to se už taky nějak zapomnělo. O podivně rozmlžených pixelech, jak se paprsek náhodně trefoval do mřížky, se kupodivu také nemluví. Prostě se vybere jeden parametr a na tom se točí diskuse, aby se ukázalo, jak jsou LCD k ničemu.

(Podotýkám, že nejsem žádný evangelista, sám jsem LCD odolával výrazně déle, než bylo běžné - ale i tak jsem přešel někdy kolem roku 2006 a řešit dnes přednosti CRT v době, kdy LCD roky používají i profesionální grafici, mi přijde úsměvné.)

Problém je ale obecnější, stačí se podívat na stále se opakující litanie o tom, jak DSLR nesahají kinofilmu ani po kotníky, nesmrtelný vinylový fetišismus nebo kult Nepřekonatelné plazmy.

[Ovocníček]

+1

O podivně rozmlžených pixelech, jak se paprsek náhodně trefoval do mřížky, se kupodivu také nemluví.

+1000, to byl IMHO ten nejzásadnější humus na CRT a vůbec nechápu, proč to těm apologistům nevadí.

Ty reálné pixely u LCD - i u špatných TNek - byly velký krok vpřed v ostrosti a tak. Pro mě bylo tak během první půlhodiny následující po vybalení prvního LCDéčka (ve škole i všude tehdy byly CRT, takže jsem s ním tak trochu skákal do neznámých vod) stoprocentně jasno.

[pavlix]

Tak zrovna rozmlžení pixelů by se dalo považovat za výhodu ve srovnání s LCD s ostrou hranicí pixelů a subpixelů. Takže ač u mě zvítězila LCD a v životě jsem si nekoupil jediné zařízení s CRT obrazovkou, tohle může být stejně dobře apologetikou LCD jako antiapologetikou CRT.

Ostrost LCD mi vyhovuje při čtení perfektně vyrovnaného písma o pixelové nebo dvoupixelové šířce, což je samo o sobě malý zázrak. Ještě je to hezké u podobně vyrovnaných prvků GUI. Ale ve všech ostatních případech to na mě působilo rušivě a musel jsem si zvyknout a smířit se s tím jako s každým jiným nedostatkem.

[Michal Kubeček]

S tím bych souhlasil, kdyby rozlišení mřížky bylo aspoň dvojnásobné oproti rozlišení obrazu. V praxi bylo ale bohužel spíš stejné (typická velikost bodu 0.25 mm vs. "standardních" 96 dpi), takže pixel se běžně rozkládal mezi dva sousední body mřížky a naopak. Mnozí dokonce používali CRT monitory s rozlišením převyšujícím rozlišení mřížky. (V kancelářské praxi je ale k vidění ledacos, třeba LCD používané na nižším než nativním rozlišení, "protože se mi ta malá písmenka blbě čtou".)

[Michal Kubeček]

A to se samozřejmě bavím o perfektně seřízeném monitoru - což také nebyl úplně každý. Teď jsem se třeba zbavoval starého CRT monitoru, který jsem měl doma jako rezervu pro případ, že potřebuju připojit cizí počítač, a ten měl ke konci v levém dolním rohu barvy rozjeté asi o půl milimetru.

[Dreit]

Za mě byla nejvýznamnější výměna D-SUB kabelu za DVI-D u prvního LCD, najednou zmizelo všechno co tam nepatří a obraz byl perfektní <3

[kyknos]

vinyl neni fetisismus, vinyl proste lip hraje .)

[Michal Kubeček]

Já věděl, že se nějaký věrozvěst chytne, otázka byla jen, která návnada zabere první.

[kyknos]

staci mit usi :)

druha vec je, ze starat se o digitalni nahravky je opruz

[Ovocníček]

Cože? Tyjo, já strávil s gramodeskama dětství, nevím, jak může slovo opruz zaznít z CD/ripů ve srovnání s utíráním desky od prachu, ručním nastavováním tracku, nepraktickou velikostí vinylu, omezenou životností jehly, no ale hlavně tím zk****ným praskáním lol...

No každopádně to, že je zvuk lepší, je pěkná blbost. Může se to stát jen tehdy, když CD má zprasený master a deska ne, a to je dost irelevantní. Jako zvuk je lepší než z kazet, to jo, ale jinak se to na digitální zvuk fakt nesere. Nemluvě o tom, že to kvůli té analogové povaze pak z člověka tahá prachy, protože musí mít různej kvalitní ekvipment aby to nějak hrálo, kdežto u CD/flacu/mp3 může být všechno jednoduchý a levný a stačí, když je slušnej zesilovač/DAC na konci.

[kyknos]

CD maji zpraseny master zcela bezne, irelevantni to neni

A vinyl vydrzi skoro vecne, digitalni data odchazi (i orig CD) a je nutno se o ne starat

[pc2005]

Tak vinyl je jen nosič, klidně na něj můžeš zakódovat nějakou digitální informaci. (heh tahat program na osmibiťák z vinylu, to by bylo maso )

[Ovocníček]

A vinyl vydrzi skoro vecne, digitalni data odchazi (i orig CD) a je nutno se o ne starat

3/10, čumák se mi při čtení ani nepohl ;P

[Michal Kubeček]

Teď už je asi jasné, proč tomu říkám vinylový fetišismus a jakou souvislost to má s vychvalováním CRT monitorů.

Ač nemám rád konspirační teorie, při pohledu na tohle velebení gramodesek a neustále se opakující články o tom, jak jsou gramofonové desky jediné fyzické (hudební) médium, jehož prodeje rostou, se otázka "Qui bono?" prostě nabízí. A nemůžu si pomoci, ale jako ten, kdo z toho má největší prospěch, mi vycházejí vydavatelé. Když místo CD, které se dá triviálně bezztrátově kopírovat nebo nagrabovat, mohou za dvojnásobek prodávat gramofonovou desku, která je mechanicky choulostivější a bezztrátově z ní záznam nedostanete, to je pro vydavatele splněný sen.

[kyknos]

1) vetsinu desek co mam, jsem dostal zadarmo nebo za pakatel - levnejsi je uz jen stahovat zadarmo (ovsem naklady...)

2) gramodeska moc choulostiva neni, prezije bez problemu 40 let na pude stareho domu, zatimco nektere moje 20 let stare (a i mladsi) CD uz prehrat nejdou

3) ano, bezztratove z ni zaznam nedostanu, ale tak nejak nevim, proc bych to delal

4) netrpis digitalnim fetisismem? :)

[pavlix]

V mých kruzích nebyl důvod zdůrazňovat nevýhody CRT, protože je prostě každý znal. A zvlášť nevýhody CRT sešlých věkem. LCD jsem si koupil hned jak jsem na něj měl a hlavní problém byl, že nešlo korektně používat se stávajícím PC.

[Václav "Darm" Novák]

Spoustu těch nevýhod asi mohla řešit technologie SED, ale nějak se to nechytlo...

[pavlix]

To mi na první pohled přijde jako zcela odlišná technologie. Podle mě je hlavním rysem CRT jeden pohyblivý paprsek, což tady nevidím.

[mirec]

Ja používam LCD kúpený v roku 2004 (17" 1280x1024). Aj v tej dobe boli už LCD celkom dobré. Dosť paradoxné je, že aj pri používaní cca 8h-12h denne vrátane víkendov s vypínaním a zapínaním dosť často (keď mám hibernovaný notebook neviem prečo ale asi každých 5 minút sa prebudí VGA, na chvíľu zasvieti monitor a znovu vypne) má CCFL podsvietenie farbu ako pri kúpe. Čo sa týka podsvietenia ... no nemám reguláciu takže stále beží na 100%, svietivosť podľa kalibračnej sondy vyše 150cd/m². Nieviem nakoľko môžem veriť kalibračnej sonde pretože žiaden monitor v bývalej práci 150cd/m² s max jasom po zahriatí nedosiahol.

[R]

CCFL vydrzia dost - opravoval som monitory, co mali podla servisneho menu nasvietenych 40 tisic hodin a CCFL boli OK.

Farba sa nemeni pocas zivotnosti CCFL. Len ked je uz trubica vadna, svieti slabo a s ruzovym nadychom. Vacsinou uz vypina ochrana invertora, pretoze netecie dostatocny prud.

[mirec]

Hmm, ja som vždy predpokladal, že je to životnosťou CCFL. Na internáte som mal 2 spolubývajúcich s ASUSmi a obom 2 a pol roka po kúpe stmavlo podsvietenie a malo ružovú farbu.

[Ovocníček]

Starej Asus s Pentiem III co jsem měl teď v ruce je taky růžovej, ale třeba ten Dell, co jsem zmiňoval vejš, měl po 10-12 letech jen sníženou intenzitu (nebo aspoň počítám, že když byl novej, tak svítil víc).

[R]

Casom klesa jas CCFL. Ale ked je to ruzove, uz su trubice prakticky mrtve.

[pc2005]

Tak mě P3 zrovna běží v kompu .

[R]

Mne tiez. Ale mam 1 GB RAM.

[pc2005]

Já jenom 128MB. Jsem ještě nesehnal vhodné SO-DIMM .

[Ovocníček]

Škoda že se mi rozbil notebook s PII, to mělo ještě EDO RAM, ale kupodivu ten můj měl taky osazeno 128 MB, takže se to před pěti roky ještě jakž takž dalo používat. Teď jsem s ním moh zamachrovat :)

Jestli někdo máte využití pro 2x 64MB EDO RAM SO-DIMM, případně jiné součástky z Latitude CPi D300XT, tak ho mám funkční kromě desky (jeden nebo oba z dílů mají studeňák nebo něco a při pokusu o opravu vytekly kondíky). Líbila se mi z něho klávesnice, ale jak je notebooková, tak se asi bohužel nedá nějak přinutit k fungování na stolním PC, škoda.

[pc2005]

Aha to já už potřebuju SDR, ideálně dvě . Na aukru něco bylo, ale 300+ Kč a to se mě zdá za 3 generace zpátky přemrštěná cena :-\. Sice nějaký vraky na DRAM mám, ale že by se mě to chtělo používat...

[pc2005]

P.S. Klávesnice bývaj jen pasivní membrány (teda aspoň do P3). Bys musel udělat nějakej PS/2 nebo USB řadič z uC.

[Ovocníček]

Přesně no, tak se mi do toho nechce. Někdy člověk musí zatnout zuby a vysrat se na ten instinkt "musím to nějak využít".

[Grunt]

Rozhodně to není Celeron nataktovaný na 2.8Ghz s GeForce 5200FX.

[pavel]

Mám AMD Athlon 5050e staré cca 6 let, k tomu 16GB RAM DDR2/800, grafika GTX 750 Ti, 4xSSD v raidu10. Je to plečka?

[Josef Kufner]

Ano.

[Ovocníček]

Jestli nenaráží na limity v CPU-heavy úlohách (kterejch na desktopum zas tak moc není), tak v tom IO a hlavně RAM to bude lepší než kopa dnešních PC (když budou mít 8GB a míň). Dalo by se mluvit o omezeních třeba kvůli nepřítomnosti USB 3.0.

[R]

USB 3.0 radic tam moze mat pridany, PCI-E karta stoji par eur.

[Grunt]

Jinak YouTube cpe HTML5 videa do čeho? Do VP9?

[pc2005]

K dispozici je stream h264 i VP9 (youtube-dl -F).

2 autor: Zkus nastavit firefox takhle.

[Grunt]

A to jako Firefox dekóduje nebo to automaticky nacpe do VDPAU? To si nemyslím. Vím že třeba Chrome ti spustí i patentovaný kodeky, ale pouze tím že to předá systémovému multimediálnímu frameworku (GStreamer - a samozřejmě to v něm musíš mít nastavený). Nevím nač se s tím tak cpát. Stačí MPV zakompilovat s podporu youtube-dl a bude přehrávat automatiky OOTB nejlíp jak to dovede.

[pc2005]

Jj aspoň by se mě pořádně přehrávaly let's playe na YT .

[Grunt]

Tak to si binding na youtube-dl do mpv rozhodně zakompiluj. Nedávno se rozšířila cache v mpv na nějaké hodně velké číslo, takže se v tom dobře seekuje stejně jako na starém Flashovém přehrávači a na let's playe z YT nic lepšího neznam.

[Grunt]

youtube-dl -F

A tohle rozhodně není HTML5.

[pc2005]

Jo, ale měl by to být seznam formátů, který YT exportuje tomu, kdo si o ně řekne. Před časem se dalo tím samým číslem v URL nastavit rozlišení videa.

[mirec]

70% pri VDPAU? To sa mi nezdá. Na slabom ARM mi mpv používa do 10%.

[kotyz]

možná to je 70% na jedno jádro a ostatní se flákaj...

[mirec]

Je to len na jedno jadro (inak by tam nemohla byť hodnota 150%). No aj tak je to moc moc vysoká hodnta. Na allwinneri A20 s vdpau to mpv dá hlboko pod 10% na 1 jadre (pri surových predpripravených h.264 dátach bez demuxera to dokonca ide pod 1%) a to mám pozapínané blbosti ako OSD, takže ešte mixuje obraz s ovládacími prvkami. Povedal by som, že VDPAU buď vôbec nefunguje, alebo je nejak zbastardený vo inak by to muselo žrať podstatne menej.

[kotyz]

no ještě může bejt to jádro podtaktovaný třeba na 800 MHz nebo 1,2 GHz. to si ověřoval? na plnej to přepíná jenom když je to víc zatížený. htop to neukáže, ale někde by to jít vyčíst mělo (cat /proc/cpuinfo ale to neni asi nejšikovnější, podle něj mi v tu chvíli co sem ho volal běžely dvě jádra na 1,4 a druhý dvě na 1,9 GHz, plná frekvence je tušim 3,2 GHz a ještě by tam mělo bejt nějaký to turbo)...

[mirec]

Na x86 to nemám ako overiť, mám len intel X3100 bez VDPAU. Ak sa pri VDPAU podtaktoval potom sú celé výsledky "benchmarku" irelevantné. Len sa mi zdá divné, že low cost ARM za myslím 8€ či koľko to stojí pri veľkom množstve s frekvenciou 1GHz to zvláda na necelých 10% 1 jadra a druhé je nečinné.

[pc2005]

Nemá ten ARM SoC nějakej dedikovanej h264 dekodér?

[kotyz]

vsadil bych se že i má...

[mirec]

Počkať nie je náhodou VDPAU práve o tom? Nemala by dekódovať h.264 práve nvidia? A áno používam samozrejme hw dekóder cez libvdpau-sunxi (vdpau implementácia pre cedar video dekóder / enkóder) inak by to išlo tak 1-5fps

[pc2005]

Tak jedině, že to na ní nefunguje (drivery?) nebo akceleruje jen něco. Co je to za typ? ([warning] já se v Nvidia grafikách nevyznám, znechutil mě legacy driver)

[mirec]

No veď práve to mi na blogu nesedí. Podľa mňa autor síce tvrdí, že prehráva cez VDPAU, ale tipoval by som, že tam bude mať problém s driverom.

[kotyz]

Přílohy:

• vdpau1.png (97795 bytů)
• vdpau2.png (117240 bytů)
• vdpau3.png (139321 bytů)

je fakt že vdpau akceleruje jen určitý kodeky a rozlišení, seznam jde vyčíst z nvidia-settings, záložka vdpau information. novější grafiky toho zmáknou víc, něco starýho jako třeba ta 8600GT co tu někdo zmiňoval toho asi moc nedá...

[Grunt]

něco starýho jako třeba ta 8600GT co tu někdo zmiňoval toho asi moc nedá...

8600 je druhá generace a H.264 dává úplně v pohodě i na 1920x1080 (Blu-Ray ripy) tak s 10%-20% vytížením procesoru (nějakej čas se kopírování dat a správu přehrávače sežrat musí). Osobě vyzkoušeno. Pokud se dívám dobře, tak VP8 nebo VP9 nemá implementovaný ani jeden set, možná proto moc nemá smysl ho cpát přes VDPAU a něco odměřovat protože se to stejně dekóduje na procesoru.

[pc2005]

Jo aha, jestli má autor blogu youtube nastavený tak, že mu dodává VP9 a nvidia driver to neumí, tak to samozřejmě pojede softwarově (ta hlavní část dekódování).

[Grunt]

samozřejmě pojede softwarově

Samozřejmě. Na to aby se to cpalo do VDPAU by musel mít tuhle volbu v sobě Firefox zakompilovanou a nějak sem ji nepostřehl, takže pokud ji tam nenacpeš skrze nějaký plug-in tak těžko to bude cpát Firefox sám od sebe do VDPAU.

[tomvec]

Já se tedy zcela bezelstně zeptám, co tedy dělá ve Firefoxu volba

media.hardware-video-decoding.enabled true

Myslel jsem, že zapíná akceleraci přehrávání videa zrovna třeba přes to VDPAU.

[Grunt]

Tak to nemám nejmenší ponětí. Má vůbec binárka Firefoxu nějaký binding na libvdpau (ldd `which firefox`)?

[Grunt]

Ale dle tohoto bugu tomu moc nevěřím že má.

[Kvakor]

Na allwinneri A20 s vdpau to mpv dá hlboko pod 10% na 1 jadre (pri surových predpripravených h.264 dátach bez demuxera to dokonca ide pod 1%) a to mám pozapínané blbosti ako OSD, takže ešte mixuje obraz s ovládacími prvkami.

No, vzhledem k tomu, že pokud se grafické jádro krmí oněmi surovými daty (u MPEGu[2,4] to může být, pokud si dobře pamatuju, i nemultiplexovaný elementary stream), tak jediné, co procesor řeší, je režie vstupního zařízení (tj. úložiště a/nebo síťová karta) a přepínání bufferů, protože přesun dat do dekodéru uvnitř grafické karty obstarává DMA engine a věci jako OSD a spol. se dělá přes průhlednou overlay vrstvu taktéž v grafické kartě. Ostatně, s podobnou zátěží zvládnou "přehrávat" (nebo nahrávat) H264 i 200-300MHz ARMy v5 v různých zařízení typu PVR nebo IP kamery.

[tomvec]

Jenom mě trošku mrzí, že na prastarém ThinkPadu T41 ve Windows XP a Firefoxu 43 jede například video na YouTube v HTML5 při 360p naprosto plynule s vytížením procesoru okolo 80%, zatímco na Xubuntu 16.04 (ano, je to alfa) jede plynule jen na 144p (otřesná kvalita, srovnatelná s desátou kopií desáté kopie VHS za komančů) při podobném vytížení procesoru. 360p vytíží procesor na 100%, ale je zajímavé, že mezi záseky běží video vždy několik sekund plynule. Někde asi vázne přesun dat.

[tomvec]

Takže podle informací od pc2005 jsem na to mrknul a zjistil, že Firefox ve Windows XP to tahá nejspíš jako mp4/h264, má nastaveno

media.mediasource.webm.enabled false

zatímco Firefox v Xubuntu 16.04 to tahá nejspíš jako webm/vp9, má nastaveno

media.mediasource.webm.enabled true

Každopádně po úpravě parametru kleslo vytížení procesoru při sledování videa ve 360p na cca 90% a obraz se netrhá (ale je to na hraně). Odtud ale můžou pocházet i problémy s případnou akcelerací.

[Dreit]

AMD A10-6790K (4x 4GHz), driver radeon, 1080p60 v HTML5 a FF 45.0a2 naprosto plynule. Ale to rozšíření se mi líbí, zkusím

[jadd]

Nevěrohodné! Jak si měřil? Proč máš někde blokátor? K čemu to vlastně je, když se to dá přehrát ve VLC?

[lol]

a proc proboha prehravat video v prohlizeci jako nejakej manager nebo windows lama?

[R]

Existuje niekde nejaka dokumentacia k Firefoxu (alebo inemu browseru), s ktorymi grafickymi kartami je podporovana akceleracia videa (akych fomatov)?

Priklad - starsie PC (nie moje) - jedno je Athlon 64 s AGP Radeonom 9250, druhe P4 s integrovanym Intelom a volnym PCI-E slotom), videa uz sekaju (youtube, ČT). Aku graficku kartu mam kupit? Najlepsie nejaky bazarovy low-end s pasivnym chladenim.

[pc2005]

Já mám Radeon X1300 a opensource driver a dekódování fakt nejede. Možná catalyst.

[R]

Uz som aspon nasiel zoznam kariet, ktore dekodovanie podporuju. Druha vec je, ci to pojde v Linuxe. A tretia, ci aj v browseri.

https://en.wikipedia.org/wiki/Unified_Video_Decoder

https://en.wikipedia.org/wiki/Nvidia_PureVideo

Takze najlepsie zohnat Radeony HD, jeden AGP a druhy PCI-E.