Hacker News Reader

Comment by jbk | Hacker News Reader

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

View on HN

By way of update from the standards trenches: threads are indeed a part of the WebAssembly plan, and we're also actively working on standardizing the SharedArrayBuffer API for JavaScript, which would allow an asm.js implementation with threads (either as a direct compilation target or as a WebAssembly polyfill). Shu-yu Guo has been working on drafting the SharedArrayBuffer spec and is planning to present an update in the next standards meeting in a couple weeks.

Shu here. I'm the person drafting the memory model for the SharedArrayBuffer spec, and as Dave says, it'll be the basis for the wasm story as well.

Lars Hansen deserves most of the credit for the actual spec -- I'm just doing the memory model. :)

Shu,

The concurrency/memory model nerds out here would love to see an early draft if at all possible :)

If nothing else, is it going to be weaker than sequential consistency?

The current draft is available at http://tc39.github.io/ecmascript_sharedmem/shmem.html

The two strengths provided by the model are sequentially consistent atomics and something between the strengths of C++'s non-atomics and relaxed atomics. Races are fully defined, and there is no undefined behavior or undefined values.

I'm happy to discuss things more in a new thread or in private communication and would prefer to not derail this thread about VLC.

Thank you!

There's also offscreen canvas coming soon which should help.

Offscrren canvas will let you render in a worker and display with zero copy

Interesting. Could this be used for headless browsing as well? Use case, e.g.: in-browser selenium testing

I saw a demo of ffmpeg running in emscripten at some point. It's definitely possible.

But its going to just burn up CPU and probably be pretty slow to do H.264 in the CPU without any hardware acceleration right?

Or maybe the H.264 gets handled by the JS side and the web assembly just handles weird formats that are mostly not high def video?

Yea. The idea is to get the broad codec/container/etc support that VLC has, not to supplant native rendering of modern codecs. We haven't actually written any code yet, but if you hand VLC.js an H.264 file I'm pretty sure it'll just create a <video> tag and then pretend like it did all the work.

Shouldn't there always be a fallback option in case a (modern) codec is not supported (yet) natively?

The one thing I like most about VLC is that it always works (so far).

That's what I've described. If the browser _can_ play it, then we just let the browser play it. Otherwise we use vlc to play it.

Our plan is up on the wiki too: http://www.archiveteam.org/index.php?title=VLC.js

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

Submit a new icon.

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

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

http://imgur.com/tvXmCvr

What do you think ? :)

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

I'll pass on that one then ;)

I'd created this one a while back: http://images.videolan.org/images/goodies/cone-icon-transpar...

nice! great job by the way.

You probably have already seen this, but I just found this ffmpeg library compiled with emscripten and thought it was pretty cool

http://bgrins.github.io/videoconverter.js/demo

Yea, stuff like that makes me think that while doing all codecs will be hard, a large useful subset will be not that difficult to do.

I've just tried webm to mp4, the native is at least 10 times faster.

It seems just very low-res stuff will be interactively playable if the speed difference remains. Maybe it's enough for the very old stuff, however.

Reply on news.ycombinator.com