h.264-video dekodet i Javascript

Sejt nok

Hvorfor er det relevant, udover at være proof of concept?

Fordi Firefox ikke har H.264 video support. De støtter OGG og Theora. Så det her kunne banen vejen for at Video ikke skal fikses specielt for Firefox fremadrettet.

Og ellers er det bare lækkert :)

"When all you have is a hammer, every problem is a nail" ?

Jeg misunder ham ikke hans job :)

Hehe det er edderspark'me fedt...

Dog ser det ud til at det er Enscripten der er den virkelig imponerende

Hvorfor er det relevant, udover at være proof of concept?David Munch (#2)

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.

Det er sku da FOR FEDT!
Jeg har i VIRKELIG lang tid, håbet på at man på et tidspunkt i fremtiden, kunne få lov til at se film i sin browseHNNNNNGHHHHHH.

Mega fedt!
Men jeg har ingen lyd på videoen. I hverken chrome eller Firefox?

Mega fedt!
Men jeg har ingen lyd på videoen. I hverken chrome eller Firefox?Abech (#8)

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! ;)

Koden kan afvikle videoen i næsten 30 billeder i sekundet
nyhed

Chrome 15 afspillede det med
Average FPS (All / Steady) 56.56 57.06

Det er da ihvertifald en måde at få brugt noget CPU på. Javascript er ikke just assembler-performance.tentakkelmonster (#10)

Ja og nej ...

JavaScirpt bliver vist optimeret ved brug af assembly, mener jeg i hvert fald de gør i Chrome.

mvh

Coooollll...

Det er god kodning :)

Brugsværdien er dog begrænset uden lyd, og uden brug af de H.264 optimerede GPU'er vi efterhånden får serveret i enhver enhed der kan vise video.

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?

#15 tror der menes at scriptet er indbygget i den seneste nightly build.

Koden kan afvikle videoen i næsten 30 billeder i sekundet, o..

Det er vel hardwaren der afgør hvor mange billeder der kan afspilles i sec. ?

#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)

ja ja, næsten 30fps med 360p. Fuld HD ved 1080p vil så kræve 9 gange mere regnekraft.

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.

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?

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?Abech (#21)

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).