Fine-tuning of HLS.js compile parameters

[stevendesu]

Is your feature request related to a problem? Please describe.
I would like to create the smallest possible build for my player, given that I know precisely what type of data will be fed to it (exact encodings, subtitle format, etc)

Describe the solution you'd like
Currently in order to reduce the build size of my player, instead of linking to hls.js, I link to hls.js/src/hls and then use the webpack.DefinePlugin to set values for __USE_SUBTITLES__, __USE_ALT_AUDIO__, and __USE_EME_DRM__. This has a dual benefit:

• Any third-party libraries utilized by both HLS.js and my player are no longer duplicated in the code, as I get a full dependency graph and Webpack can share the imports between HLS.js and my player
• I can create a build with subtitle support but without alternate audio and DRM support (which would not be possible if I used hls.light.js)

Even doing this, however, I noticed that several features exist in HLS.js that I simply will not use:

• CEA-608 support (all of our subtitles are WebVTT)
• Automatic bitrate switching (we only care to support manual switching)
• Many default error messages (hard-coded strings such as "Fragment loading error" that we would rather ignore in favor of our own error handling)

I also notice a couple of libraries being pulled in which I'm not sure we need:

• crypt (without EME DRM support, is this actually used for anything?)
• sample-aes (as above, is there a reason for AES support?)

Ideally I would like if additional flags, similar to __USE_SUBTITLES__, could be added for disabling these features at build time:

• __USE_CEA608__
• __USE_ABR__
• __USE_ERROR_MESSAGES__
• etc.

As well, I think it may be worth verifying that crypt and sample-aes are necessary when __USE_EME_DRM__ is false.

Describe alternatives you've considered
As mentioned above, I've utilized the flags I currently have available to get the player as small as possible (which resulting in approximately 70 KB of savings over using HLS.js directly)

Additional context
I'm using Webpack v4.30.0, NodeJS v11.10.0, NPM v6.9.0 and performing my builds on Mac OS X 10.14.6

The particular player I'm building utilizes VideoJS (with a custom VideoJS plugin for including HLS.js) along with various other plugins of my own design. Utilizing videojs/core.js (drops its internal HLS support, WebVTT support, and a few other features that are covered by HLS.js) adds 176.9 KB to the player. HLS.js (with my modifications as mentioned above) is another 179.57 KB. Additional node modules (whatwg-fetch, events, fast-text-encoding, etc) bring my final vendor.js bundle to 435.99 KB. All of my personal code total 158.07 KB, and I have 90.47 KB of language files for i18n. My final player size is therefore roughly 685 KB. Ideally (not likely) I would like to get this below 500 KB. I can work on shrinking the size of my own code (and already have a plan for refactoring that should save about 50% space) and I can load i18n stuff asynchronously, but I'm still looking for somewhere to save 15-20 KB. I believe that disabling CEA-608 support in HLS.js (roughly 13.69 KB) is a good first step towards this.

[OrenMe]

@stevendesu the incentive for this is indeed very valid.
This has been raised before and I believe the direction that we decided upon is to create a plugin system.
The pluggable parts are still a matter for discussion but they are very much based upon the current webpack options.
I believe your questions about other components are also valid for consideration, but at some point the customization is so big and specific that taking things into your own build might be the better solution.
In any case, I don’t think we have a reference issue tracking this at the moment.

[michaelcunningham19]

@OrenMe @stevendesu
I made an issue describing this a while ago: #2175

Some initial work has been performed, but needs more review and work: #2274

[stevendesu]

I felt like simply wrapping a few require statements in __USE_CEA608__ might be easier than refactoring all of HLS.js to use a plugin system, but a plugin system would be equally valid as a solution (and probably easier for different build systems to implement, since my current solution requires two Webpack-specific tools :alias to rewrite hls.js to hls.js/src/hls and webpack.DefinePlugin to rewrite __USE_SUBTITLES__ to true, etc)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.