Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize bundle size #4936

Open
mreinstein opened this issue Sep 30, 2022 · 2 comments
Open

Optimize bundle size #4936

mreinstein opened this issue Sep 30, 2022 · 2 comments

Comments

@mreinstein
Copy link

mreinstein commented Sep 30, 2022

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:

Bundle size is important and worthy of on-going effort.

Agreed. We shouldn't close issues that actually track that as a desired feature. (#3830 )

This issue though is a question which has been answered.

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.

@mreinstein mreinstein added Feature proposal Needs Triage If there is a suspected stream issue, apply this label to triage if it is something we should fix. labels Sep 30, 2022
@robwalch
Copy link
Collaborator

robwalch commented Oct 5, 2022

Not a Contribution

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 Why has hls.js output bytesize grown 45% going from 0.14.x to 1.x? #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
Copy link

great explaination

@robwalch robwalch removed the Needs Triage If there is a suspected stream issue, apply this label to triage if it is something we should fix. label Dec 30, 2022
@robwalch robwalch changed the title hls.js should make an effort to reduce it's bundle size Optimize bundle size Jan 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants