5 ms·

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

> 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 10y ago
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 10y ago
  Or just use a `<track kind="subtitles">` and reference a vtt file?
  - fridek 10y ago
    Which is a format you need to convert to rather than use existing srt or anything else really.
  - kuschku 10y ago
    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.
- vdnkh 10y ago
  Much harder than it sounds if you care about live streaming, video playlists, and cross-browser support. Don't forget to mention the 3 big subtitles formats (608/708/VTT) and some smaller ones (SRT/DFXP). Also, here's a fun quirk of the subtitles track element: you cannot remove a track once added. Another obstacle for full FCC compliance: styling. You must allow users to style your captions. Captions are put in the shadow DOM - Firefox does not allow you to style the shadow dom. Don't forget to add IE into the mix!
molf 10y ago
Support for the same wide variety of formats that VLC now supports. The author works for the Internet Archive and it obviously has a huge amount of files in a variety of formats that are not playable natively by browsers, and probably never will be.
- grenoire 10y ago
  VLC's support comes from its support for the codecs. Why not port the codecs to JavaScript so that the existing HTML5 features can make use of those formats?
  - ZeroGravitas 10y ago
    For this to work, the codecs need to be able to compile to JS via emscripten, so what you are asking for is necessarily part of the task. But playing a DVD, for example, isn't just about codecs, they have menus and various other features that need to be implemented too.
    - lawik 10y ago
      I'm curious how VLC usually draws inline UI elements, menu effects and such. If they need to be implemented separately per platform or if they just need to create an adapter for drawing the usual VLC UI.
      - matthewbauer 10y ago
        I think they just use Qt.
        lawik 10y ago
        Supported on tons of platforms, makes sense I guess. Linux has some variant for GTK as well if I recall correctly.
throwanem 10y ago
"I can't play back media in the browser that it doesn't natively support unless I transcode it first." Remember that this is the Internet Archive - they have huge quantities of content that they're seeking to make more accessible by making it one-click playable in the browser. It's worked out brilliantly for disk images from the 8-bit computer era, and I expect this new project will work out even more so.
MrBuddyCasino 10y ago
I think its mostly interesting for supporting niche file formats directly, as he says: "And completing this thought, by choosing something like VLC, with its top-down open source condition and universal approach, the “closing of the loop” from VLC being available in all browsers instantly will ideally cause people to find the time to improve and add formats that otherwise wouldn’t experience such advocacy. Images into Apple II floppy disk image? Oscilloscope captures? Morse code evaluation? Slow Scan Television? If those items have a future, it’s probably in VLC and it’s much more likely if the web uses a VLC that just appears in the browser, no fuss or muss." This makes a lot of sense for the internet archive. There are many "lets do it in js because we can" projects, this is not one of those.
ZeroGravitas 10y ago
He explains near the bottom. Rather than convert weird old formats to something the browser understands, which is what they do currently, this lets them play them directly. He hopes having that capability in the browser will inspire people to add even more obscure formats to VLC. So it's a virtous cycle.
- arthurfm 10y ago
  > Rather than convert weird old formats In theory it would also enable browsers to support 'wierd' new formats like BPG [1], FLIF [2] and Lepton [3] which are never going to get widespread support or any support at all. [1] https://en.wikipedia.org/wiki/Better_Portable_Graphics https://en.wikipedia.org/wiki/Better_Portable_Graphics [2] https://en.wikipedia.org/wiki/Free_Lossless_Image_Format https://en.wikipedia.org/wiki/Free_Lossless_Image_Format [3] https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs/ https://blogs.dropbox.com/tech/2016/07/lepton-image-compress...
lawik 10y ago
It seems to me that they would use these HTML5 features and APIs to implement audio and the actual pixel output from the VLC codecs. But this would mean support for an incredible number of input formats. At least that is how I understand their goals.
- matthewbauer 10y ago
  This seems right: just perform the conversion in the browser and play the output in a <video> tag. The alternative would be to draw frame-by-frame in a canvas which would be very difficult.
  - lawik 10y ago
    Ah, you mean transcode to something the browser actually handles? I think that transcoding might be many variants of terribly slow though. I'm not sure drawing it to canvas frame by frame would be all that hard, VLC already does some kind of frame-by-frame drawing I'm guessing, on the output end. Canvas should be plenty fast enough as long as the decoder can keep up I imagine. I'm thinking this might be a good use of Web Workers to offload decoding to another core to avoid hanging the main thread (UI). I'm mostly guessing. I wonder how heavy different encodings/formats will be to decode in JS. Haven't worked with video on that level of detail, but I imagine that there a plenty of optimizations that can be done in low-level languages to get solid performance that JS might not deliver.
_joel 10y ago
The Dash.js MPEG-DASH reference player can handle EBU-TT-D subtitles.
hamilyon2 10y ago
Correct subtitles are big deal for i18n and accessibility viewpoints.
rogerdpack 10y ago
My goal/wish would be that it could playback local DVD's somehow... :) VLC also might be "more robust" (in terms of accomodating for file corruption) than your browsers' player, might provide a more "stable" experience cross browsers, or allow things like "convert that video file for me in the browser to images and show me those instead" etc. FWIW.

grenoire 10y ago

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 10y ago
Or just use a `<track kind="subtitles">` and reference a vtt file?
- fridek 10y ago
  Which is a format you need to convert to rather than use existing srt or anything else really.
- kuschku 10y ago
  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.
vdnkh 10y ago
Much harder than it sounds if you care about live streaming, video playlists, and cross-browser support. Don't forget to mention the 3 big subtitles formats (608/708/VTT) and some smaller ones (SRT/DFXP). Also, here's a fun quirk of the subtitles track element: you cannot remove a track once added. Another obstacle for full FCC compliance: styling. You must allow users to style your captions. Captions are put in the shadow DOM - Firefox does not allow you to style the shadow dom. Don't forget to add IE into the mix!

molf 10y ago

Support for the same wide variety of formats that VLC now supports. The author works for the Internet Archive and it obviously has a huge amount of files in a variety of formats that are not playable natively by browsers, and probably never will be.

grenoire 10y ago
VLC's support comes from its support for the codecs. Why not port the codecs to JavaScript so that the existing HTML5 features can make use of those formats?
- ZeroGravitas 10y ago
  For this to work, the codecs need to be able to compile to JS via emscripten, so what you are asking for is necessarily part of the task. But playing a DVD, for example, isn't just about codecs, they have menus and various other features that need to be implemented too.
  - lawik 10y ago
    I'm curious how VLC usually draws inline UI elements, menu effects and such. If they need to be implemented separately per platform or if they just need to create an adapter for drawing the usual VLC UI.
    - matthewbauer 10y ago
      I think they just use Qt.
      - lawik 10y ago
        Supported on tons of platforms, makes sense I guess. Linux has some variant for GTK as well if I recall correctly.

throwanem 10y ago

"I can't play back media in the browser that it doesn't natively support unless I transcode it first." Remember that this is the Internet Archive - they have huge quantities of content that they're seeking to make more accessible by making it one-click playable in the browser. It's worked out brilliantly for disk images from the 8-bit computer era, and I expect this new project will work out even more so.

MrBuddyCasino 10y ago

I think its mostly interesting for supporting niche file formats directly, as he says: "And completing this thought, by choosing something like VLC, with its top-down open source condition and universal approach, the “closing of the loop” from VLC being available in all browsers instantly will ideally cause people to find the time to improve and add formats that otherwise wouldn’t experience such advocacy. Images into Apple II floppy disk image? Oscilloscope captures? Morse code evaluation? Slow Scan Television? If those items have a future, it’s probably in VLC and it’s much more likely if the web uses a VLC that just appears in the browser, no fuss or muss." This makes a lot of sense for the internet archive. There are many "lets do it in js because we can" projects, this is not one of those.

ZeroGravitas 10y ago

He explains near the bottom. Rather than convert weird old formats to something the browser understands, which is what they do currently, this lets them play them directly. He hopes having that capability in the browser will inspire people to add even more obscure formats to VLC. So it's a virtous cycle.

arthurfm 10y ago
> Rather than convert weird old formats In theory it would also enable browsers to support 'wierd' new formats like BPG [1], FLIF [2] and Lepton [3] which are never going to get widespread support or any support at all. [1] https://en.wikipedia.org/wiki/Better_Portable_Graphics https://en.wikipedia.org/wiki/Better_Portable_Graphics [2] https://en.wikipedia.org/wiki/Free_Lossless_Image_Format https://en.wikipedia.org/wiki/Free_Lossless_Image_Format [3] https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs/ https://blogs.dropbox.com/tech/2016/07/lepton-image-compress...

lawik 10y ago

It seems to me that they would use these HTML5 features and APIs to implement audio and the actual pixel output from the VLC codecs. But this would mean support for an incredible number of input formats. At least that is how I understand their goals.

matthewbauer 10y ago
This seems right: just perform the conversion in the browser and play the output in a <video> tag. The alternative would be to draw frame-by-frame in a canvas which would be very difficult.
- lawik 10y ago
  Ah, you mean transcode to something the browser actually handles? I think that transcoding might be many variants of terribly slow though. I'm not sure drawing it to canvas frame by frame would be all that hard, VLC already does some kind of frame-by-frame drawing I'm guessing, on the output end. Canvas should be plenty fast enough as long as the decoder can keep up I imagine. I'm thinking this might be a good use of Web Workers to offload decoding to another core to avoid hanging the main thread (UI). I'm mostly guessing. I wonder how heavy different encodings/formats will be to decode in JS. Haven't worked with video on that level of detail, but I imagine that there a plenty of optimizations that can be done in low-level languages to get solid performance that JS might not deliver.

_joel 10y ago

The Dash.js MPEG-DASH reference player can handle EBU-TT-D subtitles.

hamilyon2 10y ago

Correct subtitles are big deal for i18n and accessibility viewpoints.

rogerdpack 10y ago

My goal/wish would be that it could playback local DVD's somehow... :) VLC also might be "more robust" (in terms of accomodating for file corruption) than your browsers' player, might provide a more "stable" experience cross browsers, or allow things like "convert that video file for me in the browser to images and show me those instead" etc. FWIW.