4 ms·

Yes, I really wonder if emscripten was explored here... I assume he was doing this all on the server-side (since there's a mention of $25k monthly server bills)

by rhelmer 13y ago

Yes, I really wonder if emscripten was explored here... I assume he was doing this all on the server-side (since there's a mention of $25k monthly server bills). From the link: > This was painful, expensive, and inefficient. Clients are more than capable of transcoding video; the problem is browsers aren't. > Browsers can't run Linux software like ffmpeg, can't run Python, can't reach native performance, and can't make cross-domain requests. Depending on exactly what ffmpeg is being used for, the legality of distributing codecs is going to be an issue. Virtualbox VM overhead is non-zero compared to "native performance" anyway so I'd like to see numbers on this versus running in a browser. Cross-domain requests can be an issue, but CORS headers can work (unless he does not control the site in question, or they don't want people making these sorts of requests). From the post it sounds like this was a YouTube scraper, which basically means that there's no way he could legally be distributing ffmpeg + codecs needed in any case, and also this is against YouTube's ToS of course.

azakai 13y ago
> Yes, I really wonder if emscripten was explored here... I assume he was doing this all on the server-side (since there's a mention of $25k monthly server bills). It is on the client, I believe. Literally runs VirtualBox on the client side. > Browsers can't run Linux software like ffmpeg, can't run Python, can't reach native performance, and can't make cross-domain requests. ffmpeg definitely can be run in browsers, as can python. How close to native performance needs to be measured in each case, of course. I'm curious if they compared the performance and found it lacking, or just didn't try the browser options at all.
- rhelmer 13y ago
  > It is on the client, I believe. Literally runs VirtualBox on the client side. Right, sorry I meant the situation that Arc was intended to remedy (from the site): > I want to build apps in Python and C and ship them in the browser. I can't. > I ran full steam into this problem when I built Dirpy, a web app that records MP3s from YouTube. I could have built a native app in Python and C, but to test, distribute, and maintain builds for every OS is a total nightmare. So I built Dirpy as a web app, did all the work on servers, and paid $25,000 every month in hosting costs. >> Browsers can't run Linux software like ffmpeg, can't run Python, can't reach native performance, and can't make cross-domain requests. >> ffmpeg definitely can be run in browsers, as can python. How close to native performance needs to be measured in each case, of course. I'm curious if they compared the performance and found it lacking, or just didn't try the browser options at all. Totally agreed (I was quoting the site there, to be clear) - I am a huge fan of emscripten's approach, and I think it would work really well for this use case. VirtualBox is overkill here, and getting people to install something like this is a huge barrier. However I still think that it would not be legal to distribute the codecs one would need to do this, and it'd also be against YouTube's terms of service.

by rhelmer 13y ago

azakai 13y ago

> Yes, I really wonder if emscripten was explored here... I assume he was doing this all on the server-side (since there's a mention of $25k monthly server bills). It is on the client, I believe. Literally runs VirtualBox on the client side. > Browsers can't run Linux software like ffmpeg, can't run Python, can't reach native performance, and can't make cross-domain requests. ffmpeg definitely can be run in browsers, as can python. How close to native performance needs to be measured in each case, of course. I'm curious if they compared the performance and found it lacking, or just didn't try the browser options at all.

rhelmer 13y ago
> It is on the client, I believe. Literally runs VirtualBox on the client side. Right, sorry I meant the situation that Arc was intended to remedy (from the site): > I want to build apps in Python and C and ship them in the browser. I can't. > I ran full steam into this problem when I built Dirpy, a web app that records MP3s from YouTube. I could have built a native app in Python and C, but to test, distribute, and maintain builds for every OS is a total nightmare. So I built Dirpy as a web app, did all the work on servers, and paid $25,000 every month in hosting costs. >> Browsers can't run Linux software like ffmpeg, can't run Python, can't reach native performance, and can't make cross-domain requests. >> ffmpeg definitely can be run in browsers, as can python. How close to native performance needs to be measured in each case, of course. I'm curious if they compared the performance and found it lacking, or just didn't try the browser options at all. Totally agreed (I was quoting the site there, to be clear) - I am a huge fan of emscripten's approach, and I think it would work really well for this use case. VirtualBox is overkill here, and getting people to install something like this is a huge barrier. However I still think that it would not be legal to distribute the codecs one would need to do this, and it'd also be against YouTube's terms of service.