mboost-dp1
newz.dk
David Munch (2) skrev:Hvorfor er det relevant, udover at være proof of concept?
Fordi hvis du viser video direkte i browseren i stedet for at kalde et eksternt prog. undgår du nogle sikkerheds risici.
Brugeren får en bedre oplevelse hvis han ikke skal installere addons. Video kan vises på kiosk maskiner uden addons.
Der er sikkert flere fordele, men det var de første jeg kunne komme i tanke om.
Abech (8) skrev:Mega fedt!
Men jeg har ingen lyd på videoen. I hverken chrome eller Firefox?
Derer ikke lyd på videoerne.. Desuden er det kun h264 som bliver decoded= video..
Det er før set at man kan generere lyd i javascrip, så der skal nok komme en ac3/mp3 dekoder i javascript så man kan se mkv film :)
Det er da ihvertifald en måde at få brugt noget CPU på. Javascript er ikke just assembler-performance.
Hvem skriver en H.264 dekoder i QBASIC? Så tager jeg hatten af! ;)
Hvem skriver en H.264 dekoder i QBASIC? Så tager jeg hatten af! ;)
nyhed skrev:Koden kan afvikle videoen i næsten 30 billeder i sekundet
Chrome 15 afspillede det med
Average FPS (All / Steady) 56.56 57.06
Det er sgu imponerende uanset hvordan man vender og drejer det.
Dog lidt flamebait til FF.
Lidt sjovt det er mozilla programmører der står bag, med en mozilla video, og som #3 skriver så er det smart til FF da det ikke understøtter h.264. Når FF på min computer runder omkring 25 fps steady, og min Chrome runder 40fps steady på den samme video. Det viser måske klart og tydeligt at Chrome er _liiiidt_ foran med hensyn til deres JavaScript motor.
Hvis nu FF også fik shinet deres motor en tand så ville det nok være noget mere brugbart.
Jeg undre mig lidt over denne sætning
"der kan dekode en h.264 komprimeret video i den seneste nightly build af Firefox."
Jeg kører altså ikke Nightly builds, men kan sagtens kører denne demo?
Dog lidt flamebait til FF.
Lidt sjovt det er mozilla programmører der står bag, med en mozilla video, og som #3 skriver så er det smart til FF da det ikke understøtter h.264. Når FF på min computer runder omkring 25 fps steady, og min Chrome runder 40fps steady på den samme video. Det viser måske klart og tydeligt at Chrome er _liiiidt_ foran med hensyn til deres JavaScript motor.
Hvis nu FF også fik shinet deres motor en tand så ville det nok være noget mere brugbart.
Jeg undre mig lidt over denne sætning
"der kan dekode en h.264 komprimeret video i den seneste nightly build af Firefox."
Jeg kører altså ikke Nightly builds, men kan sagtens kører denne demo?
#15 tror der menes at scriptet er indbygget i den seneste nightly build.
#17
der antages vel her at brugere har uendelig regnekraft, og derfor er HW ikke en begrænsende faktor. Det eneste der begrænser her er den helt specielle codec struktur der siger:
-------
function show_next_frame();
{
//hemmelig kode
return frame_number;
}
while( last_frame != show_next_frame())
{
sleep( 1/30 second + 10 - Math.floor(Math.random()*21) );
}
show_last_frame();
--------
chrome snyder lidt ved at opdage det her hemmelige timing, og har en
if(FF sleep was x, make sleep = x / 2)
der antages vel her at brugere har uendelig regnekraft, og derfor er HW ikke en begrænsende faktor. Det eneste der begrænser her er den helt specielle codec struktur der siger:
-------
function show_next_frame();
{
//hemmelig kode
return frame_number;
}
while( last_frame != show_next_frame())
{
sleep( 1/30 second + 10 - Math.floor(Math.random()*21) );
}
show_last_frame();
--------
chrome snyder lidt ved at opdage det her hemmelige timing, og har en
if(FF sleep was x, make sleep = x / 2)
Med Canvas får jeg 35-40 fps i Chrome 15 med et CPU forbrug på ca. 25% (ca. 85% på én kerne).
Core i7-2620M 2.7 GHz med 4 logiske kerner.
Uden rendering omkring 50 fps.
Med Canvas w/ WebGL 45-50 fps, men billedet vises i sort-hvid.
Skalerer vi CPU forbruget ned så det svarer til 25 fps afspilning ender vi på 12-17%, afhængig af rendering.
Til sammenligning bruger en 360p YouTube video typisk 6-8% CPU.
Der er selvfølgelig en masse usikkerhed i målingerne, men det giver da et billede der siger ca. 2-3x mere CPU forbrug i forhold til YouTube.
Core i7-2620M 2.7 GHz med 4 logiske kerner.
Uden rendering omkring 50 fps.
Med Canvas w/ WebGL 45-50 fps, men billedet vises i sort-hvid.
Skalerer vi CPU forbruget ned så det svarer til 25 fps afspilning ender vi på 12-17%, afhængig af rendering.
Til sammenligning bruger en 360p YouTube video typisk 6-8% CPU.
Der er selvfølgelig en masse usikkerhed i målingerne, men det giver da et billede der siger ca. 2-3x mere CPU forbrug i forhold til YouTube.
Abech (21) skrev:Men når Javascript's hastighed afhænger af computerens regnekraft. Vil alle så ikke se videoen i forskellig hastighed? Det holder jo ikke at videoen afspiller vildt hurtigt hos nogle, og langsomt hos andre?
Jo, så længe der ikke gøres brug af uret i scriptet. Men nu er det jo også bare et proof of concept.
Det ville være en smal sag at begrænse frameraten til f.eks. 24fps. At det indbyggede ur så langt fra er præcist nok til at vise judderfri video er nok en anden sag. Her skal en hardware-clock til (som. f.eks. i lydkort eller grafikkort).
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund