12 ms·

A pure WebAssembly / JavaScript port of FFmpeg

362 points by pier25 6y ago

nynx 6y ago
What on earth is a "pure webassembly/javascript port"? It's gotta be one or both of those to run in a browser regardless. Is it just ffmpeg compiled to wasm through emscripten?
- xiphias2 6y ago
  It's called a port because probably more work went into making it work than just recompiling.
- simlevesque 6y ago
  there is always two part to these ports: - a webassembly blob - a javascript wrapper to call the webassembly's functions from js in a practical way.
- thdc 6y ago
  This is what it seems to be. The repo in this thread depends on another package which is the actual bulk of work: https://github.com/ffmpegwasm/ffmpeg.wasm-core https://github.com/ffmpegwasm/ffmpeg.wasm-core (fork of ffmpeg with emmake in a build script). There definitely does seem to be some other work in there in terms of getting it to actually work though. And tests.
- sp332 6y ago
  Here is a (soft paywalled) blog post about the "making of" this project. https://itnext.io/build-ffmpeg-webassembly-version-ffmpeg-js-part-2-compile-with-emscripten-4c581e8c9a16 https://itnext.io/build-ffmpeg-webassembly-version-ffmpeg-js...
  - JeromeWu 6y ago
    You can also check the same post in my blog: https://jeromewu.github.io/build-ffmpeg-webassembly-version-part-2-compile-with-emscripten/ https://jeromewu.github.io/build-ffmpeg-webassembly-version-...
jjcm 6y ago
On one hand this is great - offload the processing to the client side. On the other hand, I don't know if I'd trust a client-encoded video when serving video content to thousands of other users. Curious about the performance though. Would love to see benchmarks vs a standard ffmpeg install.
- wahern 6y ago
  Unless you're a broadcast studio, aren't most videos client-encoded one way or another? Does YouTube even let users upload raw, uncompressed video? Speaking of which, IME (mostly with audio), exploits more often seem to relate to encapsulation--container format, framing, etc--than to the low-level compressed blocks themselves; and those parts certainly are controlled by the client, at least at ingest. I don't know if that's simply because more people (albeit still small in absolute terms) are capable of understanding and breaking encapsulation implementations as opposed to the math-heavy block (de)compression routines, or because the (de)compression algorithms natural bound the scale of the output--e.g. a compressed 44.1khz AAC frame is not going to expand to more than 44.1k samples, and each sample won't be larger than the parameterized bit size. Either way, anyone distributing multimedia should account for this stuff. Alas, most don't seem to bother; they just pass off files to an ffmpeg binary or wrapper and hope for the best.
  - jjcm 6y ago
    I think you've misunderstood. I'm saying that I wouldn't want to directly serve a client-encoded video without doing an encoding pass on the server. Youtube re-encodes all video regardless of the format it's uploaded in.
    - golemiprague 6y ago
      but if it encode it in your webpage with your ffmpeg tool then unless someone interfere with it maliciously in some way it should not be different to encoding it on the server
    - kmeisthax 6y ago
      In the early days of YouTube you could upload FLVs that were served directly to users (this was back when their only playback format was Flash Video). It let you get high-quality video before that was an official option, and some people even had "fun" with malicious FLVs that crashed your browser via Flash.
syrusakbary 6y ago
This is awesome. I tried to do something similar a long time ago (back when the html5 video tracks/codecs API were released). I'd love to see a FFmpeg compilation to WASI, so it can be run also standalone in server-side runtimes (such as Wasmer or WAVM). I wonder if threads would made a WASI compilation more challenging?
- stjohnswarts 6y ago
  Not knowing much about WASM wouldn't just using straight up native platform ffmpeg be a lot faster and more energy efficient if you're going to be running it on the backend anyway?
  - sp332 6y ago
    Faster, yes. But a WASM version would have other advantages: it wouldn't need to be recompiled for each platform, and it would run in a sandbox.
  - syrusakbary 6y ago
    The advantages of using Wasm in this case would be: multiplaform/multichipset binaries along with a completely sandboxed environment. It's true that the speed will be a bit slower (I expect to be 5-10% slower than native), but in some cases the gains could outweight the relative slowdown.
    - rndgermandude 6y ago
      The popular external encoder libraries such as x264/x265/libvpx/libaom-av1 as well as a lot of parts of ffmpeg itself have fine-tuned assembly and sometimes C for a lot of things that you'd be missing out on. So I'd guess the speed is more than a bit slower, at least when run on common x84-64 and arm targets, even considering any WASI runtime JIT.
      - syrusakbary 6y ago
        True! I haven't considered the fine-tuned assembly inside of the encoders. I would love to have it working in Wasmer so we can benchmark both paths (native vs Wasm).
thegoleffect 6y ago
I no longer see the warning on the readme, but, this relies on SharedArrayBuffer, so it is not currently supported on mobile (except Firefox for android) and some other browsers: https://caniuse.com/sharedarraybuffer https://caniuse.com/sharedarraybuffer
- ObsoleteNerd 6y ago
  I get this when I visit the OP link: > Your browser doesn't support SharedArrayBuffer, thus ffmpeg.wasm cannot execute. Please use latest version of Chromium or any other browser supports SharedArrayBuffer.
  - pteraspidomorph 6y ago
    According to caniuse some headers are necessary for it to work on Firefox. I guess the developer has to fix the demo.
    - JeromeWu 6y ago
      In fact, the header must be set in the server-side, which means I cannot do that as I am using github pages. You can check more details here: https://github.com/ffmpegwasm/ffmpeg.wasm/issues/102 https://github.com/ffmpegwasm/ffmpeg.wasm/issues/102
      - pteraspidomorph 6y ago
        I noticed you were using github and completely failed to think of that! My bad.
- JeromeWu 6y ago
  It is on the last line of the Installation section, but yes, ffmpeg.wasm still replies on SharedArrayBuffer for multi-threading.
nostrebored 6y ago
How does the licensing here work? It claims MIT Licensing but FFMpeg is GNU LGPL
- deleted 6y ago
  [deleted]
- empyrical 6y ago
  The build scripts and the JS files in the project that interact with FFmpeg and give it a JS API are licensed under the MIT license, but FFmpeg itself is still LGPL.
  - JeromeWu 6y ago
    You are right, I cannot overwrite FFmpeg license. Lol
    - nostrebored 6y ago
      Might be important to note! I can see a lot of places this would be applicable for my work but I wouldn't be able to release content using this. Really great work though, and I'm sure it will help a lot of people!
ttflee 6y ago
How power efficient would this be? Will it become a setback towards the goal of carbon neutrality if widely used?
- emteycz 6y ago
  We have much larger problems to solve than Wasm. E. g. Java. 2 billion devices run it!
- stjohnswarts 6y ago
  Watching videos for entertainment instead of working on solutions to global warming and/or new metamaterials that are created from carbon neutral sources such as biodiesel (with the use of your computer) is a setback towards the goal of carbon neutrality.
- sp332 6y ago
  That depends on how "dirty" your electricity is, and maybe on how much dirty energy your clean energy could have displaced? My laptop runs mostly on nuclear power with most of the rest from some kind of "renewable" energy.
- refulgentis 6y ago
  I don't understand
- Polylactic_acid 6y ago
  We are about 10000 steps away before worrying the power usage of websites. Transport and energy generation changes are many many order of magnitudes more important
tomrod 6y ago
Nice!
pier25 6y ago
Hey dang, I submitted this more than 12 hours ago. How come it now says "3 hours ago"?
- grimgrin 6y ago
  i think dang once said that if they think a thing is good they'll try to get it seen or whatever, idk if that is what happened
- sp332 6y ago
  You can email hn@ycombinator.com to ask mod/meta questions. It's in the "Contact" link at the bottom if you forget.
- ffhhj 6y ago
  Mods can reset its time to help it get more views.
musicale 6y ago
Somehow I have the sinking feeling that the most popular "killer app" for webassembly will be circumventing user preferences like "never auto-play" - or thwarting ad blockers.
- rlanday 6y ago
  It’s long been possible to decode H.264 using JavaScript (which obviously uses way more power than the native decoder). This is why browsers only restrict audio playback rather than actually autoplaying video.
- jniedrauer 6y ago
  After playing around with immediate mode GUIs in WebAssembly, I can envision a future which renders any kind of content blocker obsolete. The internet could be turned into cable television. I don't want to sound overly pessimistic, but it seems very plausible that this is the future we will eventually end up with.
  - maxkwallace 6y ago
    I worry a lot about this but if this is the price of competing with the Google/Apple duopoly maybe it's worth it.
  - tmccrary55 6y ago
    Wasm has a pretty simple execution model, wouldn’t be hard to write something that preprocesses wasm code during load, similar to what you can do with java classloaders.
    - pjmlp 6y ago
      Easily preventable using encrypted wasm modules.
      - roblabla 6y ago
        I don't think WASM can write to its code memory to self-decrypt. At some point, the WASM has to create a DOM node containing the decrypted script, at which point you can process the code.
devwastaken 6y ago
I'm working on porting ffplay, targeting HEVC but also all the other decoders if possible. I've had nothing but trouble from emscripten and have had to start from the beginning, just using ffplay as reference and very slowly building the application up. Emsriptens proxy_to_thread option doesn't transfer the document context correctly, so calls from SDL to change canvas size, mouse scroll events, etc, all error. I just had to comment those lines out. But then the program would infinitely lock because a mutex would not return when a pthread was created. It would just spin on mutex.wait, and there were no errors in the thread creation as I tracked it line by line. Then debugging randomly wouldn't compile anymore. There's a whole blog I'll write on it but the summary is that emscripten is cool, but the quality of it's features isn't ready to simply cross compile without the underlying code supporting it.
- JeromeWu 6y ago
  Sounds cool! Maybe you can check my build script and see if anything is helpful. :) https://github.com/ffmpegwasm/ffmpeg.wasm-core/tree/n4.3.1-wasm/wasm/build-scripts https://github.com/ffmpegwasm/ffmpeg.wasm-core/tree/n4.3.1-w...
- davidzweig 6y ago
  I'm aware of this project, but the demo doesn't work well, might just be slow access to video hosted on Chinese servers: https://github.com/sonysuqin/WasmVideoPlayer https://github.com/sonysuqin/WasmVideoPlayer I would be interested to sponsor development of a project that could reliably play large video files with different formats in the browser. I'd use it adapt our Chrome extension ('Language Learning with Netflix') into a website/SPA that could load in local video files, so you could study with movies from your hard drive. Contact email is in my profile. :-)
  - discmonkey 6y ago
    Why not use something like Webrtc? You’ll be able to use a native decoder + seek to the nearest key frame.
    - 6y ago
shmerl 6y ago
So this can finally put Apple's refusal to support Ogg container to rest and make Ogg/Opus work on Apple systems?
- Polylactic_acid 6y ago
  God that would be useful. The least enjoyable part about using an iphone is all the media elements that show up blank because it uses vorbis/vp9
  - shmerl 6y ago
    I can imagine. I'm not touching anything Apple are making due to such kind of attitude.
- goffi 6y ago
  there is already ogv.js for that.
mister_hn 6y ago
Who said this is a great idea? We're backing here the new Flash, consuming resources on clients.
sam0x17 6y ago
This is HUGE in terms of lowering the barrier to entry for making a viable youtube competitor. Google spends tremendous amounts of money on video conversions that could be done in the uploader's browser. Maybe this will tip the scale.
- genidoi 6y ago
  YouTube's stronghold is because of community, not technology. It's also been around for 14 years and has so much internet history baked into it that it's just hard to conceive it being dethroned.
  - rhencke 6y ago
    I used to think similar about AOL Instant Messenger, the Wintel monopoly, SEGA and Internet Explorer.
    - DenseComet 6y ago
      For a lot of those things, competitors have a viable path to profitability if they make a better alternative. With Youtube, even if you make a better alternative, you're still loosing a ton of money due to costs of serving video and scaling (especially if you want to let people watch and upload for free).
    - rishav_sharan 6y ago
      None of those have the network effect and an existing community. Maybe MySpace would be a better counter example.
    - coldtea 6y ago
      The Windows is still a near monopoly (Mac at 8-10%, Linux at 1-3%) in the desktop globally. On mobile, they never had a stronghold. As for SEGA, AOL, and IE, they never had any real stronghold (like a lock-in), they just had the users - those are easier to switch to something new. Games for example go stale, and you don't care that much for your older played games - you want the new shiny. A browser, you switch over, and you have everything you did before, including your bookmarks. AOL, had it's stronghold when the internet was 1/100 of what it is now. I can see the internet going 100x larger now (except if it goes to 80 billion people out of the 8 billion on Earth).
szastupov 6y ago
A few years ago I was using this port https://github.com/Kagami/ffmpeg.js https://github.com/Kagami/ffmpeg.js It was still asm.js but working just fine.
jack_riminton 6y ago
Great! now if someone could do a JS port of MoviePy please :) https://zulko.github.io/moviepy/ https://zulko.github.io/moviepy/
yani 6y ago
Audio/Video/Image encoding/decoding and crypto is about all that I can find webassembly useful for. I wonder why all the hype with it.
- antihero 6y ago
  When it's more mature, being able to develop for the web in whatever language we want.
- m12k 6y ago
  There are many of us that would like to do frontend development in a language that isn't JavaScript - having a compilation target for that which even comes with speed benefits is huge.
gspr 6y ago
This is impressive and cool from a purely technical point of view. That's certainly enough for me, so I don't wanna detract from this, but: what would the real-world importance of this be?

362 points by pier25 6y ago

nynx 6y ago

What on earth is a "pure webassembly/javascript port"? It's gotta be one or both of those to run in a browser regardless. Is it just ffmpeg compiled to wasm through emscripten?

xiphias2 6y ago
It's called a port because probably more work went into making it work than just recompiling.
simlevesque 6y ago
there is always two part to these ports: - a webassembly blob - a javascript wrapper to call the webassembly's functions from js in a practical way.
thdc 6y ago
This is what it seems to be. The repo in this thread depends on another package which is the actual bulk of work: https://github.com/ffmpegwasm/ffmpeg.wasm-core https://github.com/ffmpegwasm/ffmpeg.wasm-core (fork of ffmpeg with emmake in a build script). There definitely does seem to be some other work in there in terms of getting it to actually work though. And tests.
sp332 6y ago
Here is a (soft paywalled) blog post about the "making of" this project. https://itnext.io/build-ffmpeg-webassembly-version-ffmpeg-js-part-2-compile-with-emscripten-4c581e8c9a16 https://itnext.io/build-ffmpeg-webassembly-version-ffmpeg-js...
- JeromeWu 6y ago
  You can also check the same post in my blog: https://jeromewu.github.io/build-ffmpeg-webassembly-version-part-2-compile-with-emscripten/ https://jeromewu.github.io/build-ffmpeg-webassembly-version-...

jjcm 6y ago

On one hand this is great - offload the processing to the client side. On the other hand, I don't know if I'd trust a client-encoded video when serving video content to thousands of other users. Curious about the performance though. Would love to see benchmarks vs a standard ffmpeg install.

wahern 6y ago
Unless you're a broadcast studio, aren't most videos client-encoded one way or another? Does YouTube even let users upload raw, uncompressed video? Speaking of which, IME (mostly with audio), exploits more often seem to relate to encapsulation--container format, framing, etc--than to the low-level compressed blocks themselves; and those parts certainly are controlled by the client, at least at ingest. I don't know if that's simply because more people (albeit still small in absolute terms) are capable of understanding and breaking encapsulation implementations as opposed to the math-heavy block (de)compression routines, or because the (de)compression algorithms natural bound the scale of the output--e.g. a compressed 44.1khz AAC frame is not going to expand to more than 44.1k samples, and each sample won't be larger than the parameterized bit size. Either way, anyone distributing multimedia should account for this stuff. Alas, most don't seem to bother; they just pass off files to an ffmpeg binary or wrapper and hope for the best.
- jjcm 6y ago
  I think you've misunderstood. I'm saying that I wouldn't want to directly serve a client-encoded video without doing an encoding pass on the server. Youtube re-encodes all video regardless of the format it's uploaded in.
  - golemiprague 6y ago
    but if it encode it in your webpage with your ffmpeg tool then unless someone interfere with it maliciously in some way it should not be different to encoding it on the server
  - kmeisthax 6y ago
    In the early days of YouTube you could upload FLVs that were served directly to users (this was back when their only playback format was Flash Video). It let you get high-quality video before that was an official option, and some people even had "fun" with malicious FLVs that crashed your browser via Flash.

syrusakbary 6y ago

This is awesome. I tried to do something similar a long time ago (back when the html5 video tracks/codecs API were released). I'd love to see a FFmpeg compilation to WASI, so it can be run also standalone in server-side runtimes (such as Wasmer or WAVM). I wonder if threads would made a WASI compilation more challenging?

stjohnswarts 6y ago
Not knowing much about WASM wouldn't just using straight up native platform ffmpeg be a lot faster and more energy efficient if you're going to be running it on the backend anyway?
- sp332 6y ago
  Faster, yes. But a WASM version would have other advantages: it wouldn't need to be recompiled for each platform, and it would run in a sandbox.
- syrusakbary 6y ago
  The advantages of using Wasm in this case would be: multiplaform/multichipset binaries along with a completely sandboxed environment. It's true that the speed will be a bit slower (I expect to be 5-10% slower than native), but in some cases the gains could outweight the relative slowdown.
  - rndgermandude 6y ago
    The popular external encoder libraries such as x264/x265/libvpx/libaom-av1 as well as a lot of parts of ffmpeg itself have fine-tuned assembly and sometimes C for a lot of things that you'd be missing out on. So I'd guess the speed is more than a bit slower, at least when run on common x84-64 and arm targets, even considering any WASI runtime JIT.
    - syrusakbary 6y ago
      True! I haven't considered the fine-tuned assembly inside of the encoders. I would love to have it working in Wasmer so we can benchmark both paths (native vs Wasm).

thegoleffect 6y ago

I no longer see the warning on the readme, but, this relies on SharedArrayBuffer, so it is not currently supported on mobile (except Firefox for android) and some other browsers: https://caniuse.com/sharedarraybuffer https://caniuse.com/sharedarraybuffer

ObsoleteNerd 6y ago
I get this when I visit the OP link: > Your browser doesn't support SharedArrayBuffer, thus ffmpeg.wasm cannot execute. Please use latest version of Chromium or any other browser supports SharedArrayBuffer.
- pteraspidomorph 6y ago
  According to caniuse some headers are necessary for it to work on Firefox. I guess the developer has to fix the demo.
  - JeromeWu 6y ago
    In fact, the header must be set in the server-side, which means I cannot do that as I am using github pages. You can check more details here: https://github.com/ffmpegwasm/ffmpeg.wasm/issues/102 https://github.com/ffmpegwasm/ffmpeg.wasm/issues/102
    - pteraspidomorph 6y ago
      I noticed you were using github and completely failed to think of that! My bad.
JeromeWu 6y ago
It is on the last line of the Installation section, but yes, ffmpeg.wasm still replies on SharedArrayBuffer for multi-threading.

nostrebored 6y ago

How does the licensing here work? It claims MIT Licensing but FFMpeg is GNU LGPL

deleted 6y ago
[deleted]
empyrical 6y ago
The build scripts and the JS files in the project that interact with FFmpeg and give it a JS API are licensed under the MIT license, but FFmpeg itself is still LGPL.
- JeromeWu 6y ago
  You are right, I cannot overwrite FFmpeg license. Lol
  - nostrebored 6y ago
    Might be important to note! I can see a lot of places this would be applicable for my work but I wouldn't be able to release content using this. Really great work though, and I'm sure it will help a lot of people!

ttflee 6y ago

How power efficient would this be? Will it become a setback towards the goal of carbon neutrality if widely used?

emteycz 6y ago
We have much larger problems to solve than Wasm. E. g. Java. 2 billion devices run it!
stjohnswarts 6y ago
Watching videos for entertainment instead of working on solutions to global warming and/or new metamaterials that are created from carbon neutral sources such as biodiesel (with the use of your computer) is a setback towards the goal of carbon neutrality.
sp332 6y ago
That depends on how "dirty" your electricity is, and maybe on how much dirty energy your clean energy could have displaced? My laptop runs mostly on nuclear power with most of the rest from some kind of "renewable" energy.
refulgentis 6y ago
I don't understand
Polylactic_acid 6y ago
We are about 10000 steps away before worrying the power usage of websites. Transport and energy generation changes are many many order of magnitudes more important

tomrod 6y ago

Nice!

pier25 6y ago

Hey dang, I submitted this more than 12 hours ago. How come it now says "3 hours ago"?

grimgrin 6y ago
i think dang once said that if they think a thing is good they'll try to get it seen or whatever, idk if that is what happened
sp332 6y ago
You can email hn@ycombinator.com to ask mod/meta questions. It's in the "Contact" link at the bottom if you forget.
ffhhj 6y ago
Mods can reset its time to help it get more views.

musicale 6y ago

Somehow I have the sinking feeling that the most popular "killer app" for webassembly will be circumventing user preferences like "never auto-play" - or thwarting ad blockers.

rlanday 6y ago
It’s long been possible to decode H.264 using JavaScript (which obviously uses way more power than the native decoder). This is why browsers only restrict audio playback rather than actually autoplaying video.
jniedrauer 6y ago
After playing around with immediate mode GUIs in WebAssembly, I can envision a future which renders any kind of content blocker obsolete. The internet could be turned into cable television. I don't want to sound overly pessimistic, but it seems very plausible that this is the future we will eventually end up with.
- maxkwallace 6y ago
  I worry a lot about this but if this is the price of competing with the Google/Apple duopoly maybe it's worth it.
- tmccrary55 6y ago
  Wasm has a pretty simple execution model, wouldn’t be hard to write something that preprocesses wasm code during load, similar to what you can do with java classloaders.
  - pjmlp 6y ago
    Easily preventable using encrypted wasm modules.
    - roblabla 6y ago
      I don't think WASM can write to its code memory to self-decrypt. At some point, the WASM has to create a DOM node containing the decrypted script, at which point you can process the code.

devwastaken 6y ago

I'm working on porting ffplay, targeting HEVC but also all the other decoders if possible. I've had nothing but trouble from emscripten and have had to start from the beginning, just using ffplay as reference and very slowly building the application up. Emsriptens proxy_to_thread option doesn't transfer the document context correctly, so calls from SDL to change canvas size, mouse scroll events, etc, all error. I just had to comment those lines out. But then the program would infinitely lock because a mutex would not return when a pthread was created. It would just spin on mutex.wait, and there were no errors in the thread creation as I tracked it line by line. Then debugging randomly wouldn't compile anymore. There's a whole blog I'll write on it but the summary is that emscripten is cool, but the quality of it's features isn't ready to simply cross compile without the underlying code supporting it.

JeromeWu 6y ago
Sounds cool! Maybe you can check my build script and see if anything is helpful. :) https://github.com/ffmpegwasm/ffmpeg.wasm-core/tree/n4.3.1-wasm/wasm/build-scripts https://github.com/ffmpegwasm/ffmpeg.wasm-core/tree/n4.3.1-w...
davidzweig 6y ago
I'm aware of this project, but the demo doesn't work well, might just be slow access to video hosted on Chinese servers: https://github.com/sonysuqin/WasmVideoPlayer https://github.com/sonysuqin/WasmVideoPlayer I would be interested to sponsor development of a project that could reliably play large video files with different formats in the browser. I'd use it adapt our Chrome extension ('Language Learning with Netflix') into a website/SPA that could load in local video files, so you could study with movies from your hard drive. Contact email is in my profile. :-)
- discmonkey 6y ago
  Why not use something like Webrtc? You’ll be able to use a native decoder + seek to the nearest key frame.
  - 6y ago

shmerl 6y ago

So this can finally put Apple's refusal to support Ogg container to rest and make Ogg/Opus work on Apple systems?

Polylactic_acid 6y ago
God that would be useful. The least enjoyable part about using an iphone is all the media elements that show up blank because it uses vorbis/vp9
- shmerl 6y ago
  I can imagine. I'm not touching anything Apple are making due to such kind of attitude.
goffi 6y ago
there is already ogv.js for that.

mister_hn 6y ago

Who said this is a great idea? We're backing here the new Flash, consuming resources on clients.

sam0x17 6y ago

This is HUGE in terms of lowering the barrier to entry for making a viable youtube competitor. Google spends tremendous amounts of money on video conversions that could be done in the uploader's browser. Maybe this will tip the scale.

genidoi 6y ago
YouTube's stronghold is because of community, not technology. It's also been around for 14 years and has so much internet history baked into it that it's just hard to conceive it being dethroned.
- rhencke 6y ago
  I used to think similar about AOL Instant Messenger, the Wintel monopoly, SEGA and Internet Explorer.
  - DenseComet 6y ago
    For a lot of those things, competitors have a viable path to profitability if they make a better alternative. With Youtube, even if you make a better alternative, you're still loosing a ton of money due to costs of serving video and scaling (especially if you want to let people watch and upload for free).
  - rishav_sharan 6y ago
    None of those have the network effect and an existing community. Maybe MySpace would be a better counter example.
  - coldtea 6y ago
    The Windows is still a near monopoly (Mac at 8-10%, Linux at 1-3%) in the desktop globally. On mobile, they never had a stronghold. As for SEGA, AOL, and IE, they never had any real stronghold (like a lock-in), they just had the users - those are easier to switch to something new. Games for example go stale, and you don't care that much for your older played games - you want the new shiny. A browser, you switch over, and you have everything you did before, including your bookmarks. AOL, had it's stronghold when the internet was 1/100 of what it is now. I can see the internet going 100x larger now (except if it goes to 80 billion people out of the 8 billion on Earth).

szastupov 6y ago

A few years ago I was using this port https://github.com/Kagami/ffmpeg.js https://github.com/Kagami/ffmpeg.js It was still asm.js but working just fine.

jack_riminton 6y ago

Great! now if someone could do a JS port of MoviePy please :) https://zulko.github.io/moviepy/ https://zulko.github.io/moviepy/

yani 6y ago

Audio/Video/Image encoding/decoding and crypto is about all that I can find webassembly useful for. I wonder why all the hype with it.

antihero 6y ago
When it's more mature, being able to develop for the web in whatever language we want.
m12k 6y ago
There are many of us that would like to do frontend development in a language that isn't JavaScript - having a compilation target for that which even comes with speed benefits is huge.

gspr 6y ago

This is impressive and cool from a purely technical point of view. That's certainly enough for me, so I don't wanna detract from this, but: what would the real-world importance of this be?