robwalch
commented
2 years ago v1.2.4 is just over 40% larger than v0.14.15. Many changes made over the last four years have contributed to what makes this library what it is today.
| Library URL and version | size compressed | size uncompressed |
|---|---|---|
| https://cdnjs.cloudflare.com/ajax/libs/hls.js/0.14.15/hls.min.js | 61.5 kB (Brotli encoded) | 240 kB uncompressed |
| https://cdnjs.cloudflare.com/ajax/libs/hls.js/1.2.4/hls.min.js | 82.3 kB kB (Brotli) | 337 kB uncompressed |
Besides a lot of features and fixes that did not impact the bundle size significantly, the additional 97 kB consists of support for:
- Low-Latency HLS (blocking playlist reload, delta playlists, part loading, hold-back, CDN Tune-In)
- Progressive streaming option (experimental)
- CMCD module for enhancing outgoing requests with player tracking data
- CMAF SEI Captions
- CMAF emsg ID3 metadata TextTrack Cues
- EXT-X-DATERANGE TextTrack Cues
- Basic IMSC1 subtitle support (experimental)
- Improved support GROUP-ID track selection with level switch and error handling
- Improved support for redundant variants
- Improved back-tracking on TS segments not starting with I-frames
- Live Latency tracking
- Back buffer ejection
- Improved codec support and filtering
- Improved support for SSAI/DAI streams and DISCONTINUITY handling
- Improved end-of-stream handling and Live-to-VOD support
- TypeScript src conversion (I mentioned in #3830 that changes in type safety, readability, and ES6 operators will have introduced some increase in size)
- Removal of automatic event listener callback registration (For TypeScript, each module with event listeners now explicitly adds and removes them at controller setup and tear down. This benefits performance, type safety, and readability at the cost of uncompressed file size)
- See https://github.com/video-dev/hls.js/releases for details and more features and fixes not listed here
An additional 16-20 kB of minified payload can be expected in v1.3.0 with the DRM enhancements being introduced.
One solution for users interested in only a subset of features is to leverage alternate build targets like hls-light. However, to create new build targets that meet users' core use cases, we must define what features are essential to users looking to leverage a smaller bundle. hls.light JS dist files do not include EME, subtitles, or alternate-audio support which is probably too extreme for most users in 2022. When building the player, four environment vars can be used to customize the light build:USE_SUBTITLES (and "metadata" TextTracks), USE_ALT_AUDIO, USE_EME_DRM, and USE_CMCD. These set build constants remove inline code from the build and stub these controllers. Minified size impact noted in kB:
USE_ALT_AUDIO: 18 kB (with the exception of the most basic playback or muted playback, this is not a very usable feature to disable) AudioStreamController AudioTrackController
USE_EME_DRM: 19 kB (this will increase with v1.3) EMEController
USE_SUBTITLES: 54 kB 👀 (subtitle or CC support is required for most use cases. Can you isolate your delivery format to just one, and would we save significant space by omitting support of only some formats?) SubtitleStreamController SubtitleTrackController TimelineController CuesInterface
USE_CMCD: 8 kB CMCDController
Audio and subs exclusion should probably be removed for the average HLS use case in 2022. Additionally, modules like LatencyController or KeyLoader could be excluded or reduced if Live playback and latency or content encryption are not a concern. Low latency, progressive streaming, and several other v1 features above are core to the stream-controller architecture. They would be difficult to isolate or stub out of a build (even LatencyController is used by some API features and could not be stubbed without additional work).
Which features are non-essential in a build optimized for bundle size and a common HLS use case?
dioramayuanito
Is your feature request related to a problem? Please describe.
hls@0.14 mostly worked fine for the core use case. hls@1 is approx. 45% larger. This isn't acceptable for things that load over the internet (especially when loading millions of these per week.)
Describe the solution you'd like
from the other ticket:
Agreed. We shouldn't close issues that actually track that as a desired feature. (#3830 )
The issue is not a discussion point like stack overflow, it's a feature request. Closing it simply pretends that the issue is solved, and makes it harder for other users to find/coalesce around a common place for a given issue.
Additional context
I don't know why you marked the discussion as locked/heated. Maybe it's because the internet lacks tone, but there's no malice behind my #3830 . I'm just stating that this is something your users care about.