[Lily/Video] add m3u8 support

[jexjws]

1. using hls.js to play m3u8
2. bundled hls.js directly into the extension

[jexjws]

if (!(await Scratch.canFetch(url))) return;

WARNING : If the resource URLs in a .m3u8 file are not on the same domain as the .m3u8 file itself, the client can fetch resources from other domains without using Scratch.fetch.

[lukeselden]

Perhaps you can do a check using a custom loader for hls.js before a playlist or fragment gets loaded. This is a quick mock up but haven't tested it at all:

this.hls = new Hls({
  loader: class CustomLoader extends Hls.DefaultConfig.loader {
    load(context, config, callbacks) {
      let { type, url } = context;

      // Custom behavior - do a check first
      Scratch.canFetch(url).then(isAllowed => {
        if (!isAllowed) {
          callbacks.onErrorCallback({
            code: 'Scratch_Error',
            text: `${err}`
          });
        } else {
          super.load(context, config, callbacks);
        }
      }).catch(err => callbacks.onErrorCallback({
        code: 'Scratch_Error',
        text: `${err}`
      }));
    }
  }
});

[CubesterYT]

If you use an outside library, you must make an offline copy of it and imbibe it into the extension directly, and include the license of said library in the extension as well.

[jexjws]

make an offline copy of it and imbibe it into the extension directly

1. Why would we bundle hls.js directly into the extension? It seems unnecessary to add a 400KB overhead for handling non-M3U8 videos. Is this intended for offline usage?

2. if we do this, when the upstream project releases important updates (such as security updates), we will need to manually update the hls.js within our repository. Manual updates can cause delays. Is there a way to solve this problem (for example, by having Dependabot manage the hls.js within extensions repository? I'm not familiar with Dependabot and wouldn't know how to set that up.)

and include the license of said library in the extension as well.

OK. I will do this.

[LilyMakesThings]

1. It's intended for offline usage and in the unlikely event it becomes inaccessible for whatever reason.
2. If it works, what reason would there be to update in a timely manner? You'd be amazed how many dependencies for Scratch and by extension TurboWarp have not been updated in half a decade.

[jexjws]

Addressed. Please review the changes.

[jexjws]

I've made a table describing the differences between each decision (we're temporarily setting aside the issue of native browser m3u8 loading violating TurboWarp's Scratch.fetch security model):

Decision	Advantages	Disadvantages
Embedding hls.js in Video.js	Allows for offline m3u8 playback	Increases size, makes future editing harder
Dynamically loading hls.js with Video.js	Loads only when needed, no unnecessary overhead	Requires clients to be able to connect to cdn.jsdelivr.net to play m3u8

If I had to pick one, I'd choose "Dynamically loading hls.js with Video.js", but that comes at the cost of offline m3u8 playback for users (e.g., using localhost).

But we need a solution that works for everyone. Giving Scratchers a consistent experience whether they're online or offline is important, but keeping future edits simple is also important for the extension's continued development.

I believe that the need for external JavaScript libraries is common for TurboWarp extensions (e.g., a math extension may require an external math-related library), and I even think that neither embedding nor dynamically loading third-party JavaScript libraries as presented in the table is the optimal solution.

[CST1229]

I even think that neither embedding nor dynamically loading third-party JavaScript libraries as presented in the table is the optimal solution.

One solution would be to host these libraries on extensions.turbowarp.org. This way, the desktop app would be able to load these offline (since it already has a full copy of extensions.turbowarp.org that it uses for everything else related to these extensions).
As for the packager, maybe the extension could also specify the dependency URLs somewhere (maybe as a header comment) so it can download them at package-time like the extension itself.

[jexjws]

That can be costly as most users will never need to play video formats that the browser does not support

This PR exists because a friend of mine wanted to play m3u8 in turbowarp (although he eventually achieved his goal by putting a webpage that includes hls.js into the iframe extension).

Leaving a large file and unused library(s) in the extension.

Please check my commits before I was asked to make the extension usable offline. Bundling hls.js within the extension was solely to meet the requirement of offline usability.

[GarboMuffin]

i know the dependency situation is bad. some ideas floating around but nothing concrete yet.

not only does the desktop need to get the extensions offline, files generated by the packager also need to embed all the extensions and their resources so they work offline. right now that is a very simple fetch() without an analysis step. at the same time i want to preserve the property that people can copy and paste an extension's unprocessed code from github and get something that works.

sure lots of the rest of this project uses ancient dependencies but that does not mean we should stop caring for the other parts. notice that this repository is pretty up-to-date.

[jexjws]

you still have no addressed part 2 of what lily said from what I can tell

If it works, what reason would there be to update in a timely manner? You'd be amazed how many dependencies for Scratch and by extension TurboWarp have not been updated in half a decade.

Because I felt this wasn't the focus of my PR, and I don't agree with this point, I remained silent on this issue and presumptuously assumed you wouldn't care.

My silence clearly hurt you, and I apologize for that.

I should have opened a new issue to discuss versioning problems unrelated to the PR, instead of including issues unrelated to this PR within the PR itself.

[jexjws]

A majority of people will never need this, 1 person doesnt overrule majority when it comes to this.

There's at least 1 person, not just 1. m3u8 is not an unpopular format; many websites use m3u8 to provide video services.

[FurryR]

@yuri-kiss @CubesterYT @jexjws
This SHOULDN'T be closed right now as we now have a new solution -- see #1591 and its related issue.

[CubesterYT]

Let's keep this open, it's a really good addition to the extension.

[LilyMakesThings]

Let's keep this open, it's a really good addition to the extension.

I strongly disagree.