
A Simple Request: VLC.js - Doubleguitars
http://ascii.textfiles.com/archives/5084
======
jbk
As the lead of the team of VLC, we've been discussing this since quite a bit
of time, and we believe it is totally doable.

But, we believe we need WebAssembly + Wasm-Threads. Without threads it will be
a very difficult task to port VLC: you notably need one thread for input, one
for audio output, one for video output, and one for the playlist.

However, threads are supposed to come in an update to WebAssembly. So that
will be cool.

Also, VLC is very very heavily modularized, and Wasm will bring modules.

Finally, porting all codecs will be hard (FFmpeg), but VLC has some very
simple modules for a few codecs, like theora and mpeg2, so it is easy to start
and port one module after another...

~~~
Jaruzel
Something that has always bugged me about VLC... The Traffic Cone icon.
Whereas it's was a brilliant piece of imagery to separate VLC from other 3rd
party players, nowadays that market place is way less competitive, so maybe
now is the time to switch up the icon to something more formal?

I've started seeing VLC included on work-orientated desktop builds and the
Cone icon sticks out like a sore thumb, and most lay-users have no idea what
VLC is so assume it's a system utility (based on the icon).

Maybe a combo of a Video Player icon, with a smaller traffic cone on the
side... ?

~~~
jbk
Submit a new icon.

But so far, it's very distinctive, so it will stay like that, until a better
icon is submitted.

~~~
Jaruzel
Brilliant assumption that I have the skills. Ok, I'll have a go...

[http://imgur.com/tvXmCvr](http://imgur.com/tvXmCvr)

What do you think ? :)

~~~
pvinis
woa. i know its a joke drawing, but the cone you made looks like a wizards
hat! maybe the next icon should be an awesome orange striped wizard hat. for
the end users, vlc plays all videos, _magically_ ;)

------
guitarbill
> It is my belief that a Javascript (later WebAssembly) port of VLC, the
> VideoLan Player, will fundamentally change our relationship to a mass of
> materials and files out there, ones which are played, viewed, or accessed.
> Just like we had a lot of software locked away in static formats that
> required extensive steps to even view or understand, so too do we have
> formats beyond the “usual” that are also frozen into a multi-step process.
> Making these instantaneously function in the browser, all browsers, would be
> a revolution.

Something like VLC.js is anything but "[a] [s]imple [r]equest" :)

The web experiences some kind of rot anyway. As long as you can still access
and play stuff you really want in at least one way (VLC), is the instantaneous
part such a win?

It's a technical solution to a problem most people don't face. Are people
really facing that many multi-media files that can't be played? Two bigger
issues that come to mind: 1) stuff hosted on closed, proprietary sites that
then close down 2) how to find stuff (especially with esoteric or unusual
content). So IMO, VLC.js probably wouldn't "fundamentally change our
relationship to a mass of materials and files out there".

I agree there is a delivery issue, but again I think it's findability and
hosting - hence why youtube/soundcloud/spotify/netflix is a thing.

~~~
lelandbatey
It's true, I've experienced this first hand as I've tried to build my own
simple "Netflix" which hosts my media collection and makes it available to all
my devices. And as it turns out the intersection of maximum usability vs
compatibility is a simple Apache open directory of files.

The only issues I've faced with this setup is one of codec availability and
bitrate:

Sometimes, I'll be in a situation where I only have a high-quality, high
bitrate copy of some media on my server, and I'll be trying to access it over
a low bandwidth connection. If I'm stuck in one place for a while, I can re-
encode the media on the server, but I'm unable to begin streaming to my device
until the new lower bitrate copy is finished encoding on the server side.

Other times, I'll be in a situation where I want to access a file, but I need
it in a different codec, so again I'll have to re-encode it on the server and
download once that's finished.

What would be amazing, and would solve both problems (I'm not sure this is
possible) is some kind of real time, http-based transcoding proxy. So you give
it a link to a media file somewhere on the web, and it returns an http link
which is streamed and transcoded in real time and served back to the client,
all over http (so existing http media streaming clients can use this as a drop
in replacement).

If such a thing existed (or exists) I'll donate $100 right now.

~~~
christoph
Check out Plex - [https://www.plex.tv/](https://www.plex.tv/)

I run it on an Nvidia Shield, it will transcode multiple streams on that and
handles pretty much everything I've thrown at it so far.

~~~
lelandbatey
I've used Plex before, and while it is fancy and has a nice user experience
for it's use cases, I've found it somewhat limited.

It is fundamentally locked into itself. You need to either have a device which
can run the web client, or a Plex app for the platform. And that works fine if
you're doing this just for yourself (I've run a Plex server in the past).

But sharing media is painful (or at least, more painful than simply sending a
link to someone), and the overhead of compatibility was always annoying.
Additionally, if you don't like the way the Plex app works on your device,
tough, that's the only UI there is. However, there are a tremendous number of
apps and applications with UIs galore that all support HTTP streaming.

Now, the last time I fully investigated Plex was about a year ago, but since
then I've used friends instances and it always seemed lackluster, or at least
not as straightforward as bare-bones HTTP streaming.

~~~
cormacrelf
On the other end of the flexibility + compatibility scale, if all you need is
to watch The Wire on your iPhone/iPad/Apple TV v4 on the couch instead of at
your computer, I've been using Infuse. Just turn on SMB on your computer and
fave a few directories, then stream away. It'll even pull in metadata, cover
art, descriptions and sort shows into seasons.

[https://firecore.com/infuse](https://firecore.com/infuse)

(Arguably, Infuse is very compatible with whatever your video source is, but
it only runs on iOS.)

------
hannob
This sounds like a very different goal than the port of MAME.

MAME is emulating video games, a video game is a piece of software that cannot
be easily converted into something web-playable. Therefore in order to make
the games accessible you need an emulator.

VLC is a media player. It supports more formats than a web browser, but audio
and video files can be converted. If you have a file in an arcane, outdated
video or audio format and you want to make it more easily accessible just
convert it to something that is playable in a browser.

I'm not saying that a web vlc has no value. Conversion always means some
quality loss. There are some interactive features (like dvd menus) that are
essentially like software and having access to them in a browser isn't simply
possible by conversion. But it has certainly much less value than a web mame.

~~~
joepie91_
> VLC is a media player. It supports more formats than a web browser, but
> audio and video files can be converted. If you have a file in an arcane,
> outdated video or audio format and you want to make it more easily
> accessible just convert it to something that is playable in a browser.

This is what the Internet Archive does right now. Unfortunately, transcoding
from one lossy format to another just results in more quality loss. Something
like VLC.js would sidestep that problem, and remove the need to transcode
everything (and keep multiple copies!) as a bonus. You even mention that
yourself, so I'm not sure I understand your point here.

------
captainmuon
I'm not sure I like this idea. This means even less control over my media
files. Not only do they get streamed, but also the software that views them.
I'm very likely not going to be able to use this offline, or outside of the
browser in other apps. It's likely going to be slower, unless someone adds
one-off extensions to JS to allow access to hardware decoding.

What would I suggest otherwise? Don't laugh, but something like NPAPI or
ActiveX (COM). We had all these great component models in the 2000s. We could
put them in a lightweight VM or a container for security. Instead of creating
a window, we could let them directly draw to a shared-memory texture, which
would solve some usability problems. I believe we could solve all problems
that these technologies had nowadays.

Fundamentally, something like this belongs into the OS, not the browser (or
any application). You should be able to use every codec and widget from other
applications. We had that around 2000 with COM and VB6: Drag the media player
widget from a pallette, drop it on your form, write a line of code to load a
video.

Also, nobody gets to decide what codecs you are allowed to use or not for
"political" or strategic reasons. Can't play something exotic? Just download
the best-rated codec from your OSes app store (remember, which would run in a
sandbox). Creating content and want to make sure everybody can see it without
installing? Do what you do already today, and use the greatest common codec
shipped will all OSes.

~~~
fdgdasfadsf
You put a lot of faith in sandboxes... They aren't magic.

~~~
captainmuon
Neither is a browser runtime. I would even say running code in a browser could
be more dangerous, because you have a huge complexity (HTML+JS+Network
Stack+3D Engine+kichen sink in modern browsers) and thus a large attack
surface. Whereas if you built an isolation layer around a OS process (or
bytecode), you can restrict the code to do only what it has to (render to
audio and video buffers), and you have to audit the wrapper
(sandbox/VM/runtime), which is much smaller than the whole browser.

The reason browsers are relatively safe now is that so many brilliant people
are working really hard on them, not because they are inherently safe.

~~~
fdgdasfadsf
This is an interesting perspective that I had not considered.

------
shmerl
That would be great. It can deal a final blow to Apple's refusal to support
free codecs in their browsers.

At last it will be possible to save space and encode only in high quality free
codecs, using vlc.js as a fallback for crippled Apple systems.

~~~
jaytaylor
This, a thousand times. The mess that is Plex sucks, a web browser tool which
could play media files without all the drama would be a game changer for those
of us who don't consume media through iTunes.

~~~
supercoder
Yeah, Plex is the worst.

~~~
swah
What are you talking about? I have zero pain points with the thing.

------
CiPHPerCoder
I'm filled with equal parts:

    
    
      - That will be *awesome*! Think of all the cool things
        we can do with this!
      - Oh no, we're going to be parsing video formats in
        JavaScript. :(
      - Hmm, I wonder if this will actually be better for
        security compared to a VLC browser plugin?
    

I guess we're not far from JavaScript: the one true language.

~~~
aikah
no need for Javascript with Web Assembly.

~~~
duaneb
It's still not clear whether this is actually true or whether we'll just be
writing javascript from C. It really depends on the quality of APIs available.

~~~
XorNot
My impression of web assembly was that browsers would go "oh that looks like
web assembly" and then bypass JavaScript and compile the whole thing to native
code?

~~~
duaneb
Yea, it depends on the quality of APIs available.

------
xanderstrike
I'm curious what features of VLC they're looking for that aren't provided by
HTML5's video support. Broader codec support?

~~~
milankragujevic
HTML5 can't play MKVs let alone codecs other than H.264+AAC in mp4. It's
support is so laughable it's sad.

~~~
1qaz2wsx3edc
The root cause is/and continues to be that we want HTTP to be an application
protocol, which it was never intended to be or designed to be. I feel that
until browsers behave more like independent operating systems / vms, this kind
of tension between what we want to do and what we can do will always exists on
the web as we know it...

I mean, Canvas, WebGL, Audio APIs, Video APIs, VR APIs, etc, when do we
realize that what we want is a way to run applications...

~~~
matthewmacleod
_The root cause is /and continues to be that we want HTTP to be an application
protocol,_

I don't see what relevance that has to HTML5 video codec support. Browsers
could pretty easily support arbitrary codecs.

~~~
optionalparens
You are right that certainly one could lets say edit the source of chrome and
add support. There is no technical limitation here, however see
[https://developer.mozilla.org/en-
US/docs/Web/HTML/Supported_...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Supported_media_formats)

Specifically, one thing they mention is licensing with regard to browsers.

Parent's comment has relevance IMO because we're trying to shoe horn things to
make everything work in the browser and thus via HTTP as if the browser was an
operating system. The browser was built to browse web pages, and at that,
didn't even necessarily need to be graphical (see lynx). It's becoming a
monster and many of us don't agree with the hand-waiving style justification
of adding more and more.

Once upon a time, some people had a vision of using something optimized for
files for files, another thing for chat optimized for chat, and so on. There
were protocols for these, and apps on top of those. Not all these things were
built well, efficient, and/or easy to use. The browser and http were good
compromises in many ways, but certainly not without massive problems either.
Fast forward and we've just compounded the problems and we keep working harder
to lock ourselves into another limited set of technologies we already knew had
fundamental issues (people used to/still do complain about processor
architecture in similar ways).

I like the browser as a unifying, networked experience, but HTTP + the web
browser are not really designed particularly well for some of the things we
try to use them for from many perspectives. On top of that, with the issues of
JavaScript, security, state, and other things, it gets even more messy.
Somewhere along the way we seem to have become disinterested in protocols,
lower-level networking, and generally challenging the norms.

Ironic that a lot of web developers preach things like KISS, and yet the
browser is a huge example of a project where one could argue that KISS + don't
throw in the kitchen sink has run amok. I understand this is not a popular
opinion with some people, but I still think it is a valid one. Sometimes I
think a little more pausing and thinking things through on lower-levels and
with regard to the bigger picture are undervalued and could save us from some
of the nonsense of the last few decades.

~~~
Aloha
But before that, they used a VDT - as in like a VT100, 3270 or 5250 terminal.
Everything is full circle - the web browser is just being treated as an
intelligent terminal now.

~~~
optionalparens
I agree conceptually, but this points out some fun things.

So in other words, we tried that and failed in many ways in a much simpler
domain. Now we are trying it again with a much bigger, more complicated scope
and set of technical issues. Just like in the VTxxx days, people say something
is compatible, and yet it is not 100%. Just like in those days, we deal with
the craziness around all that as developers.

I've been working on some stuff dealing with old formats, including VT100.
Diving into the source of some very big and well-known projects along with
many lesser known things, it's amazing how wrong many implementations are when
you check the standards. Related, I've seen the craziest implementations of
telnet servers, ANSI SGR codes, and more. Translation: I have 0 faith in
humanity to implement standards to the standards. I have less faith in the
standards people to create sane standards.

------
omarforgotpwd
This would definitely be cool, but I'd be worried about using this because of
mobile devices. It can't be good for battery life to be processing video
through JavaScript. I know ios and many android devices have hardware assisted
h.264 decoding that's very efficient to make video playback work well with
great battery life.

------
symlinkk
There's already a VLC web plugin, how would VLC.js be any different for the
end user?

[https://wiki.videolan.org/Documentation:WebPlugin/](https://wiki.videolan.org/Documentation:WebPlugin/)

~~~
tiles
I believe NPAPI is being deprecated; that wiki page is very out of date.

~~~
cpeterso
Neither Chrome nor Edge support NPAPI plugins today. Firefox is dropping
support for all NPAPI plugins (other than Flash) in Firefox 52 (March 2017).

------
akavel
Question: does VLC handle much more formats than ffmpeg? I imagine the latter
would be much simpler to compile (so that it'd convert Any Format™ to Some
Common Modern Format Supported By All Browsers™)

~~~
jbk
There is a lot more than just codecs and formats in a media player. :D

Also, porting ffmpeg might be hard, while VLC has some simpler codecs to port
for a start (libmpeg2 for example).

~~~
supercoder
Yes but isn't FFMpeg where the real value is ? VLC itself is a bit of a mess,
the UI is clunky and and isn't a great media player experience.

Would seem like the best of both worlds to use the web for UI but have FFMpeg
deliver the frames.

~~~
mdip
I tend to agree with you on this, personally. I can't speak to the code
quality or whether or not VLC is a mess (I've never really looked) but I think
the point here is the ability to play back (almost) any video/audio/subtitle
format around which is met by both VLC and FFMPEG quite well. Being able to do
that in a browser, without plug-ins, in a performant manner is important from
an archival perspective (broadest audience support for the broadest array of
file kinds/types).

Unfortunately, the ultimate goal -- taking the control of "what codecs are
supported for streaming" away from the browser vendors probably won't be met.
The biggest issue there is supporting reliable playback across a variety of
processors with performance/battery constraints. For desktop users it might be
a doable thing, but unlikely for mobile. Granted, we're doing things on our
mobile devices that would have been positively unimaginable 7 years ago, so
who knows?

At the end of the day, though, it's codec support that is the big win from my
perspective -- lavc/lavf or FFMPEG -- not necessarily getting all of VLC
ported.

------
indexerror
On a side note, Webchimera [1] works great from Electron/nw.js applications. I
use it for some media applications.

[1] [http://www.webchimera.org/](http://www.webchimera.org/)

------
optionalparens
I'm currently putting what little few hours I have into a few side projects
that touch things like XM/MOD and other things like ANSI, RIP, etc. I always
seem to share Jason's nostalgia and I get his meaning, but I often don't see
eye to eye with him on a lot, whether his treatment of BBSs or some things
like emulation.

There are so many red flags here, from licensing to browser vendors to
JavaScript to threading to security, I don't know where to begin. It's not
that these things aren't doable (even stupid hacks like transcoding are
readily doable), it is just that I do not agree with the notion that this must
be in the browser for the sake of digital preservation or some sort of user
experience.

I know this is a very unpopular opinion in some parts (perhaps HN), but why
must everything be in JavaScript and in the web browser? I understand we want
things to be cross-platform and network accessible, but I must say that the
drift from native to the browser is becoming increasingly disheartening and
inspiring constant wtf moments. I get that a lot of people use the web and
some people even see it as the computer itself now, but we rarely pause to ask
if this is a good thing. Moreover, we invest a lot of time and effort in
things that aren't really worth it in the end. I wish in computer science
there were more sanity checks and willingness to make progress, rather than to
paint flat tires or more crudely, shine turds. The term sunk costs comes to
mind.

I like the web and the browser as much as the next person for browsing web
pages, but it is not an operating system. Stop making it do everything and
anything; that's why I bought a computer not a web browser machine (yeah, I
know chromeos). I did not buy my computer so I could stab a few of its cores
in the face or make it feel like it is running several orders of magnitude
under-clocked. I feel like this is what my browser is doing to me when I see
<insert latest abuse> or visit a page displaying a few poorly aligned
paragraphs of text resulting in more RAM usage than total RAM I had in my
computer for several decades.

What are the benefits and do they really outweigh the costs? I understand that
building binaries is full of issues, as is compilation, processor
architecture, and so many other parts of the native experience. But the thing
is we spend so much time on maintaining and improving our already dated and
flawed OSs that at least generally run fast and sanely.

Why would we want to shoehorn yet more things we already do happily in our OS
into the browser? Why move something from efficient environments to
inefficient ones? Why have to lobby or wait on a standards committee to allow
something? Why wait on browser vendors to agree or disagree to make it more
complicated? Why am I trading taskbars, terminal sessions, or other OS
constructs for browser tabs (can we have new or other ways to mix content
types)? How is the browser better as a unifying experience than my OS? Do I
really even want videos on web pages or do I want something that is built
better for video content? Why not just use what's inside my computer, like
that expensive GPU, CPU, RAM, etc. without some ridiculous workarounds or
barriers? These are all just random topics to think about, however the point
is that it has to be more than, "Wow, that was cool but stupid" moments or
"it's in the browser."

We already have put herculean efforts into making safe, pleasant, efficient,
cross-platform languages. There are many successes and failures, and the jury
is almost universally still out. But the barriers there are much smaller and
the environments much more sane. In light of the move to multi-core
architectures and bumping up against x86 limitations/physics, and eventually
the same for others, it seems insane to me to throw away what we do have right
now and relegate it to some browser environment that often struggles to things
I can easily do faster/smoother over a terminal session.

I feel with every new "XYZ, but in the browser" we are taking a step away from
both the Internet and the general utility of the computer and stomping on what
remains. Instead, if we want experiences that must use the Internet, I would
like to see more lower-level things implemented. I want to see the next
browser, the next usenet, something new that can be built-on and other higher-
level things for the every day user. One day it is mobile apps, the next day
browser apps, and so on. Let's forget what is trendy or fun and get back to
being creative and making progress, leaving the rest to fun "because" side-
projects.

Finally, getting back to what Jason and/or archive does specifically, how does
this help preservation? It seems to me that browser vendors and browsers in
general don't have the best track record in general here and are an added
layer of complication vs. <insert OS/programming
language/VM/runtime/shim/emulator>. We've also seen any kind of
ancillary/hosted/browser-native solution come and go, whether it was applets,
flash, activex, whatever. I wish the browser were better with video, but VLC
is not what would make it better, just designing and allowing the proper
support from the ground-up would be the right way, and at worst, requires the
help of the committees and the vendors. I do love VLC.

~~~
caf
_..., but why must everything be in JavaScript and in the web browser?_

In this case, the point is to make that archived data readily accessible. An
internet archive where you need to track down and install the right native
application to view each record is a bit like those rarefied museum
collections locked away in the vast basements of large academic departments,
accessible only to those few scholars who are familiar with the hoops they
need to jump through to be allowed in.

I don't think the idea is that if you had, say, a large collection of MOD
files you enjoy, that you should throw away your native tracker and use the
browser with a JS tracker instead. Rather, the idea is that if there's a
discussion somewhere of the early 90s Amiga demoscene you can post a link to a
particular MOD file and know that everyone will be able to play it straight
from there.

~~~
db48x
Agreed. An archive where the data is preserved but you have to really work to
view things is good, but one where you can just browse is better. Since we
don't have to worry about accidental damage caused by people who are just
browsing, and people who are just browsing don't limit the ability of a
researcher to use other tools, we can both.

Another good example is MIDI. As a browser of MIDI files I just want to hear
them play. If I'm researching them, then I'll want to take the time to figure
out what hardware and software synthesizers people were actually using when
they composed them and listened to them.

Neither use-case impinges on the other, so there's no reason at all to avoid
implementing an in-browser MIDI player. Or an in-browser media player that can
play nearly everything, in this case.

On the other hand, downloading a 4gb dvd image full of mpeg2 streams is pretty
wasteful of bandwidth; if it weren't for the menus and whatnot it'd be better
to transcode it to something modern for playback.

------
draw_down
Yeah, simple.

------
profeta
mame as javascript only worked because distribution of mame is garbage.

go ahead. dont belive me? go on and try to install it now. you will waste days
just trying to figure out where you can find some version and then how to hook
up that nice frontend you saw on some video demo of a rare mame setup mame.

what they did was excellent. because the alternative was messy.

vlc is already available in a very nice package everywhere. Insead of that
futile effort, just convince everyone to just publish the media file and maybe
subtitles, in a stardard way, instead of in a proprietary flash-player
replacement or proprietary stream app. Your browser will already send it to
vlc just fine.

