5 ms·

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

voltagex_ 10y ago
The three examples from the post: * XM * MOD * Support for playing files inside archives
- duskwuff 10y ago
  XM and MOD support has been implemented -- multiple times! -- by other Javascript projects, most notably: http://mod.haxor.fi/Jester/mod.stardustmemories http://mod.haxor.fi/Jester/mod.stardustmemories Playing files from within archives should be possible using the MediaSource API. No need to port the entirety of VLC to get that.
  - voltagex_ 10y ago
    I think you'd use VLC's modular architecture to your advantage. Maybe you'd start with an Emscripten port, but then replace parts with a "native" JS implementation of tracker music support. That's the first time I've heard of MediaSource being able to play from archives, though - do you have any more info?
    - duskwuff 10y ago
      MediaSource doesn't specifically support archives; it gives Javascript the more general ability to generate data to be presented by an <audio> or <video> element. How the Javascript code decides to generate that data is up to it -- be it loading chunks over HTTP, pulling them out of an archive, generating them from scratch...
  - optionalparens 10y ago
    And nearly every one of these does not do it correctly. I haven't recently checked this in VLC either since normally I just use the original trackers and other programs for playback on the real hardware. From the github of the project you linked: "None of the player classes fully implement all the features and effects in each file format, but all the major ones should be implemented. In addition, there most certainly will be some playback bugs in each player class - let me know if you run into some bad ones." Additionally, I did not see support for some other tracker formats listed (though perhaps supported) such as IT. There seems to be some sort of culture of "cool web page" or "on github" means "works PERFECT" to many people. Worse, sometimes these things do work well, get abandoned, then something breaks them like a security change, so we're back to unsupported again. As someone who has a passion for what some describe as "scene" formats, I have to say that 99% of the stuff I come across, whether for MOD, ANSI, RIP, DIZ, whatever is fundamentally broken or missing key functionality. The same holds true to other related tech such as vt100/vtxxx emulators. Music and ANSI are some of the worst offenders. Music is interesting since even at the time, different programs would play things back differently, however there was some degree of consistency to make things playable. Literally every ANSI parser in popular places I check have some combination of horrible bugs, missing parts of the standard, abysmal performance, inaccuracies, and worse. It's as if the authors didn't read the specs, because, well, they probably did not (or at least didn't understand them). The situation gets worse when you think about preservation. Some of the formats had multiple versions and iterations, not to mention were built with different processors and architecture in mind. I was working with one format recently that used a little-endian packed struct that added fields between versions and stored this data as binary. If you read a previous version of the format with the most of the code out there (supporting the latest), it would actually crash. I've actually hit this with archives too, such as with LZH/LHA that are especially used in retro settings or on some platforms. There's a lot of complexity to older formats and the evolution of things that appeared in more wild circumstances and/or times. Implementations that work perfectly are a rarity and worthy of attention. VLC in this regard does a better job than most. So I think part of the logic whether I agree or disagree is that VLC is widely used, maintained, and active, so it's a bit better for preservation at the moment than random collections of github libraries.
    - jontro 10y ago
      For ios I can really recommend modizer: http://yoyofr.blogspot.se/p/modizer.html http://yoyofr.blogspot.se/p/modizer.html Otherwise the only good generic mod player i've used was deliplayer, unfortunately abandonware. http://modarchive.org/?article-players http://modarchive.org/?article-players for more info, VLC isn't even mentioned here.
milankragujevic 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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_media_formats https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_... 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.
mschuster91 10y ago
Raw playback of DVDs/BDs, that's what I'd like to see. This is something I miss on both the legal and the illegal streaming platforms - no way to get the "bonus content", or, especially in case of LotR, the different "editions" of a movie.
jbritton 10y ago
HTML5 does not support live streams. Live streaming of RTSP would be useful for me.
- TD-Linux 10y ago
  WebRTC is the HTML5 equivalent of RTSP (they are both based on RTP). You can use Janus to translate between the two - feed RTSP into Janus and it'll apply the necessary encryption and do the necessary firewall hole-punching to make it WebRTC compliant.
- iamleppert 10y ago
  You can certainly get streaming working with HTML5. I've done it before.
- eridius 10y ago
  HTTP Live Streaming (https://en.wikipedia.org/wiki/HTTP_Live_Streaming https://en.wikipedia.org/wiki/HTTP_Live_Streaming) is already supported in a wide array of products. Oddly enough, Chrome supports it on Android, but not on desktop OSes.
  - cpeterso 10y ago
    The Media Source Extensions API (MSE) allows streaming audio/video playback in HTML. It's used widely today, including YouTube and Netflix. JavaScript libraries like Dailymotion's HLS.js can remux container formats on top of MSE, so you don't need native support for HLS in desktop browsers. https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc... http://engineering.dailymotion.com/introducing-hls-js/ http://engineering.dailymotion.com/introducing-hls-js/
    - Matthias247 10y ago
      I used HLS (native in iOS and Edge) as well as hls.js and it works good if you use the correct codecs. A drawback is that through it's HTTP file based distribution it's not really low latency (live). A UDP based streaming protocol could for sure do better.

voltagex_ 10y ago

The three examples from the post: * XM * MOD * Support for playing files inside archives

duskwuff 10y ago
XM and MOD support has been implemented -- multiple times! -- by other Javascript projects, most notably: http://mod.haxor.fi/Jester/mod.stardustmemories http://mod.haxor.fi/Jester/mod.stardustmemories Playing files from within archives should be possible using the MediaSource API. No need to port the entirety of VLC to get that.
- voltagex_ 10y ago
  I think you'd use VLC's modular architecture to your advantage. Maybe you'd start with an Emscripten port, but then replace parts with a "native" JS implementation of tracker music support. That's the first time I've heard of MediaSource being able to play from archives, though - do you have any more info?
  - duskwuff 10y ago
    MediaSource doesn't specifically support archives; it gives Javascript the more general ability to generate data to be presented by an <audio> or <video> element. How the Javascript code decides to generate that data is up to it -- be it loading chunks over HTTP, pulling them out of an archive, generating them from scratch...
- optionalparens 10y ago
  And nearly every one of these does not do it correctly. I haven't recently checked this in VLC either since normally I just use the original trackers and other programs for playback on the real hardware. From the github of the project you linked: "None of the player classes fully implement all the features and effects in each file format, but all the major ones should be implemented. In addition, there most certainly will be some playback bugs in each player class - let me know if you run into some bad ones." Additionally, I did not see support for some other tracker formats listed (though perhaps supported) such as IT. There seems to be some sort of culture of "cool web page" or "on github" means "works PERFECT" to many people. Worse, sometimes these things do work well, get abandoned, then something breaks them like a security change, so we're back to unsupported again. As someone who has a passion for what some describe as "scene" formats, I have to say that 99% of the stuff I come across, whether for MOD, ANSI, RIP, DIZ, whatever is fundamentally broken or missing key functionality. The same holds true to other related tech such as vt100/vtxxx emulators. Music and ANSI are some of the worst offenders. Music is interesting since even at the time, different programs would play things back differently, however there was some degree of consistency to make things playable. Literally every ANSI parser in popular places I check have some combination of horrible bugs, missing parts of the standard, abysmal performance, inaccuracies, and worse. It's as if the authors didn't read the specs, because, well, they probably did not (or at least didn't understand them). The situation gets worse when you think about preservation. Some of the formats had multiple versions and iterations, not to mention were built with different processors and architecture in mind. I was working with one format recently that used a little-endian packed struct that added fields between versions and stored this data as binary. If you read a previous version of the format with the most of the code out there (supporting the latest), it would actually crash. I've actually hit this with archives too, such as with LZH/LHA that are especially used in retro settings or on some platforms. There's a lot of complexity to older formats and the evolution of things that appeared in more wild circumstances and/or times. Implementations that work perfectly are a rarity and worthy of attention. VLC in this regard does a better job than most. So I think part of the logic whether I agree or disagree is that VLC is widely used, maintained, and active, so it's a bit better for preservation at the moment than random collections of github libraries.
  - jontro 10y ago
    For ios I can really recommend modizer: http://yoyofr.blogspot.se/p/modizer.html http://yoyofr.blogspot.se/p/modizer.html Otherwise the only good generic mod player i've used was deliplayer, unfortunately abandonware. http://modarchive.org/?article-players http://modarchive.org/?article-players for more info, VLC isn't even mentioned here.

milankragujevic 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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_media_formats https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_... 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.

mschuster91 10y ago

Raw playback of DVDs/BDs, that's what I'd like to see. This is something I miss on both the legal and the illegal streaming platforms - no way to get the "bonus content", or, especially in case of LotR, the different "editions" of a movie.

jbritton 10y ago

HTML5 does not support live streams. Live streaming of RTSP would be useful for me.

TD-Linux 10y ago
WebRTC is the HTML5 equivalent of RTSP (they are both based on RTP). You can use Janus to translate between the two - feed RTSP into Janus and it'll apply the necessary encryption and do the necessary firewall hole-punching to make it WebRTC compliant.
iamleppert 10y ago
You can certainly get streaming working with HTML5. I've done it before.
eridius 10y ago
HTTP Live Streaming (https://en.wikipedia.org/wiki/HTTP_Live_Streaming https://en.wikipedia.org/wiki/HTTP_Live_Streaming) is already supported in a wide array of products. Oddly enough, Chrome supports it on Android, but not on desktop OSes.
- cpeterso 10y ago
  The Media Source Extensions API (MSE) allows streaming audio/video playback in HTML. It's used widely today, including YouTube and Netflix. JavaScript libraries like Dailymotion's HLS.js can remux container formats on top of MSE, so you don't need native support for HLS in desktop browsers. https://developer.mozilla.org/en-US/docs/Web/API/Media_Source_Extensions_API https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc... http://engineering.dailymotion.com/introducing-hls-js/ http://engineering.dailymotion.com/introducing-hls-js/
  - Matthias247 10y ago
    I used HLS (native in iOS and Edge) as well as hls.js and it works good if you use the correct codecs. A drawback is that through it's HTTP file based distribution it's not really low latency (live). A UDP based streaming protocol could for sure do better.