
A Simple Explanation: VLC.js - vmorgulis
http://ascii.textfiles.com/archives/5089
======
zaphar
At what point will the current trend to treat the browser and WebAssembly as a
compile target for traditionally fat client applications raise the need for a
browser package manager ala Apt or Yum? When will dynamic linking become a
necessity because due to memory usage, disk space, and patches for 0day
exploits in upstream libraries?

It seems like the more the browser takes on the role of an OS the more it will
need all the stuff that OS's have built up over the years to make it
manageable.

~~~
bastawhiz
We have (or had) that. Chrome is removing web app support (the Apps button on
your favorites bar). Firefox removed their app support after FxOS died.

Nobody wanted these things. Users didn't understand the idea. The APIs were
clumsy. The framing of the apps added little value over a traditional web app.
Portability was a joke.

The best thing to happen to the web is service workers and the new world of
"offline" APIs, like the push notification API. They allow pages to get the
goodness of a desktop app without the downsides of installing a "native" app.

(source: I helped build the Firefox Marketplace)

~~~
zaphar
Those are more of an app store and less of a package manager. Apt and Yum
solve a problem users don't know they have. The app stores solve the problem
of obtaining and installing the application. They don't solve the problem of
managing shared libraries and quickly updating those shared libraries.

For an application like VLC this sort of thing become really important. More
important than your typical email client or document editor.

~~~
bastawhiz
On the web though, you don't need the user to manage libraries. In the same
way you don't install a web page, libraries are simple script tags pointing at
URLs. Pages will never reference incompatible versions. Browser caching makes
"sharing" of libraries transparent. What's there left to manage?

~~~
zaphar
Is this still true for an application like VLC compiling to WebAssembly that
uses other downstream libraries?

What if VLC uses downstream libx and Audacity also uses downstream libx and
downstream libx has a critical 0day. I'm not super clear yet on how the
WebAssembly build pipelines works. Is dynamic linking done through script
tags? or are the binary blobs statically compiled? I'm genuinely curious here
how this is all supposed to work. How does one ensure that downstream libx is
updated for _all_ of the WebAssembly applications that use them.

------
kowdermeister
> I firmly believe that this project, fundamentally, would change the
> relationship of audio/video to the web.

Aren't they banging open doors? HTML5 video and audio is great and with
WebAudio and WebGL you can manipulate every aspect of the experience. EQ,
filters are possible. What else do you need? Subtitles?

I just don't understand what problem are they trying to solve because "I can't
run VLC in the browser" certainly isn't one.

~~~
grenoire
You can even get subtitles on top of HTML5 videos with simple positioned
elements with text shadows for borders. I can't say I understand the motive of
the project either, other than "see, everything can be done in JavaScript!"

~~~
danielsamuels
Or just use a `<track kind="subtitles">` and reference a vtt file?

~~~
kuschku
Which doesn't allow SRT subtitles, or XML subtitles (hello German public
broadcasters!), or ASS subtitles (hello anime fandub groups!)

Doing this natively in JS via canvas allows you exactly that - rendering these
things natively, in real time, with all the support for rare features you
could ever need.

------
acqq
From the previous discussion:

vespakoen noted that there is already ffmpeg library compiled with emscripten:

[http://bgrins.github.io/videoconverter.js/demo](http://bgrins.github.io/videoconverter.js/demo)

My speed test of webm to mp4 conversion (it doesn't display the video, it's
just ffmpeg) showed the JS version _around 10 times_ slower than the native
ffmpeg.

The test was on relatively recent i7 and the latest Firefox (certainly having
as fast asm.js as possible) then (around a month ago). I haven't investigated
the cause for such significant speed difference.

~~~
colek42
I have a project that decodes mpegts packets and renders the frames to a webGL
canvas using FFMpeg.
[https://github.com/colek42/streamingDemo](https://github.com/colek42/streamingDemo).
Full disclosure much of the client code is copy/pasta from
[https://github.com/opensensorhub](https://github.com/opensensorhub)

Edit: add attribution

~~~
rogerdpack
is there a live demo some/anywhere?

~~~
colek42
Sorry, I am using it to proxy UDP streams which requires a backend component
due to browser restrictions. If I hosted a demo it may end up costing a
nontrivial amount of money. I am developing this closed source for my
employer, but if there is enough interest I can push some of the changes to
the open source repo.`

------
kbutler
Power consumption and performance are big concerns, because JavaScript
(software) decoders can't leverage hardware acceleration.

But archive.org wants to preserve and publish many formats that are not high
resolution, high frame-rate video, and we can expect both performance and
power consumption to improve over time.

~~~
_joel
HTML5 canvas can use hardware acceleration, of course. If the codec being used
is suitable for HW acceleration (i.e. h/x624 yes, VP9 no - generally)

------
bambax
But wouldn't a browser plugin be easier to develop and also easier to use for
the end user? Exactly what is gained by having it run in js? (Better
portability maybe? But VLC already runs on almost all platforms natively...?)

~~~
fridek
Because every browser has different plugins and their concept tends to change
every few years, for good (security) or bad (politics) reasons. Once VLC.js
runs, you can reasonably expect it to run forever and be just another
compilation target.

~~~
throwanem
Exactly.

For example, Mozilla is deprecating NPAPI just as fast as it can, because it
long predates e10s (Chrome-style process isolation) and they do not play well
together. e10s has been so long delayed already, and Firefox's performance
problems are so intractable to solve without it, that from the perspective of
a very long-time Firefox user like me this is very obviously the correct
course of action.

This deprecation will break the existing VLC plugin for Firefox, but that's
not a huge deal because it never has worked very well in any case - developing
a reliable NPAPI plugin is a seriously hard problem in general and has been
since browsers got complicated enough to do interesting things in the first
place. You also have to restart the browser to make any changes to the set of
installed NPAPI plugins, and that's a lot more of a problem than it was before
the browser became an application runtime. Now that the JS runtime is fast and
capable enough to run "real application" code, we derive a much better
experience by leveraging that power than we do by targeting a legacy interface
that is relatively ill documented and much easier to get wrong in ways that
break the whole browser rather than just one page or tab. We also get cross-
browser compatibility of a sort that NPAPI never could offer.

I get that a lot of people think it's weird for the web browser's page
scripting language, which was nothing more than a cute toy a couple decades
ago, to be eating the world like this. I think it's weird, and it's how I earn
a living! But, weird or not, it's also the best application platform we have
or likely soon will have for a broad and widening variety of use cases, and
that is because, while no more perfect than anything else, it actually works
really well. Railing bitterly against technology that works really well seems
potentially counterproductive to me. But I appreciate there exists a diversity
of opinion on the subject.

------
antome
Does this mean that developers will go as far as maintaining a port of FFMPEG
to JavaScript? Being able to decode 10bit videos in pure JS sounds both insane
and insanely cool

~~~
acqq
> a port of FFMPEG to JavaScript

It already exists, see my other comment for more details.

~~~
kinlan
There are a number of ports powered by Emscripten
([https://github.com/Kagami/ffmpeg.js](https://github.com/Kagami/ffmpeg.js))

I wrote about some stuff here [https://paul.kinlan.me/ffmpeg-
ideas/](https://paul.kinlan.me/ffmpeg-ideas/) when building
[https://paulkinlan.github.io/deviceframe.es/](https://paulkinlan.github.io/deviceframe.es/)
(I do a lot of screencasts and need a simple way to scale this out to other
people that doesn't involve installing ffmpeg and scripting)

EDIT and Note: Also I just saw your comment about videoconvert.js

~~~
acqq
Do I understand it correctly that you want the users to do javascript ffmpeg
processing on their android devices? I admit I have no idea what deviceframe
is, so I'd also like to read some explanation on that too.

Have you compared the speed of Android javascript ffmpeg vs PC native? What
happens with the battery?

~~~
lawik
Javascript and as soon as possible WebAssembly, as I understand it.

I think mobile is a secondary consideration in this at this point. Considering
it is connected to the internet archival efforts and simply ensuring the
survival of numerous video/audio formats I imagine they are fine if it isn't
efficient but simply effective at this point.

Edit: on second thought, you might not be commenting on the VLC.js thing, I
haven't read about the ffmpeg js stuff ;)

~~~
acqq
Sadly, that answer is a completely missed conversation topic.

I've asked about

[https://paulkinlan.github.io/deviceframe.es/](https://paulkinlan.github.io/deviceframe.es/)

------
sandGorgon
This is one of the reason I'm truly excited about the future of javascript in
its ES6 or Typescript form.

If they manage to make this run and use emscripten and manage to build all the
video computation optimizations.. how far of a stretch is it really to combine
lodash+emscripten+BLAS/LAPACK to build a high performance computing platform
based on javascript ?

~~~
na85
Honest question: Why is building an HPC platform on a language designed in
less than 2 weeks something to aspire to?

Why not aspire to replace javascript entirely with something better?

~~~
sandGorgon
huh?

ES6/emscripten/Typescript was not designed in 2 weeks. could you talk about
what you mean.

~~~
Outpox
He's talking about the first JS specification which was done in 2 weeks IIRC.
I've seen such comments several times which completely discard all the effort
made to improve JS until now.

------
bmarkovic
Wouldn't webxmp (also emscripten based) be a better match for MOD/S3M/XM
support:

[http://www.wothke.ch/webxmp/](http://www.wothke.ch/webxmp/)

~~~
spacemanmatt
That's really neat! I still have a few music modules I can't part with.

------
andrewvijay
This is very exciting and to a lot of people, doing things with only a browser
is so much enabling!

