I'm curious what features of VLC they're looking for that aren't provided by HTML5's video support. Broader codec support?
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...
I don't see what relevance that has to HTML5 video codec support. Browsers could pretty easily support arbitrary codecs.
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.
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.
You need multiple implementations of something for it to be a standard, and just try reimplementing SSA subtitles in Matroska and getting any of it right.
Only as insecure as your browser's intersection with the video codec.
> And there's no use case, because almost everything only has historical value.
You talk as if historical value is low. I'd argue it's higher than supporting 4k or whatever's used to sell TVs these days. Not much point if we just throw out our existing content!
> You need multiple implementations of something for it to be a standard, and just try reimplementing SSA subtitles in Matroska and getting any of it right.
It's not about standardness or getting it right, it's about being able to play my video file on any level. Really, anything other than current behavior would be hugely preferable. iOS has more support for autoplaying me ads without my asking than it does for my own damn home movies.
Well, commercial content can be re-encoded for new formats and usually is. Playing old files is limited to physical purchases of media, home videos, retro video games and internet porn.
And don't forget you can get VLC for iOS.
It's filled to the brim with heavily patented codecs. That's also why the browsers don't support H265. Note that Chromium and Firefox don't support H264 either exactly due to the patents. (Firefox will fall back to the system decoder, which, coincidentally, will be ffmpeg on a Linux system!)
https://developer.mozilla.org/en-US/docs/Web/API/Media_Sourc...
* XM
* MOD
* Support for playing files inside archives
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.
That's the first time I've heard of MediaSource being able to play from archives, though - do you have any more info?
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."
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.
http://modarchive.org/?article-players for more info, VLC isn't even mentioned here.