New to HLS.js and trying to make my streams as performant as possible!

[NickWoodward]

Hi all,

Sorry for the noob questions, but I'm just trying to get into HLS.js and just want to make sure I'm setting my streams up to be relatively performant.

Currently I've 1 hero video that's hosted on bunny.net, and in its original format is 238mb and 60 seconds long. I'm loading it like this:

      const hls = new Hls({
        testBandwidth: true,
        abrEwmaDefaultEstimate: 5000000, 
        startLevel: -1, 
        maxBufferLength: 30, 
        maxMaxBufferLength: 60,
        maxBufferSize: 60 * 1000 * 1000, 
      });

Here are my (probably incorrect) reasons for the above:
testBandwidth - to adapt to either mobile or desktop
abrEwmaDefaultEstimate: 5000000 - maybe too high an initial guess for bandwidth?
startLevel: -1 - uses the initial estimate to automatically pick a stream quality
the buffer properties - seem a bit aggressive for this size video? i'm basing that on absolutely nothing XD

Also - for videos further down the page, what's the best way to defer loading/streaming? Should I get every video to load their first chunk and nothing else, and use something like ScrollTrigger (i'm using gsap anyway) to trigger it to start streaming the rest? (if that's even possible). Or should I be conditionally/lazily loading in the components (I'm using react)?

Like I said, sorry for the 20 noob questions, I'm just trying to build up a mental model of how this works :)

Thanks,

Nick

[robwalch]

Here are my (probably incorrect) reasons for the above:

I wouldn't bother adding testBandwidth or abrEwmaDefaultEstimate. Let the default behavior handle startup. Looks good though.

Also - for videos further down the page, what's the best way to defer loading/streaming? Should I get every video to load their first chunk and nothing else, and use something like ScrollTrigger (i'm using gsap anyway) to trigger it to start streaming the rest? (if that's even possible). Or should I be conditionally/lazily loading in the components (I'm using react)?

If you do that, you need to limit how many active player or hls.js instances are allowed at once. Deferring calls to hls.loadSource(m3u8) OR configuring the player to not automatically load media playlists with autoStartLoad: falseand then callinghls.startLoad()when the player is almost ready is one way to go. Another is to limit the number or HTMLMediaElements on the page and only attach them to hls.js when displayed on the page and ready to play withhls.attachMedia(video)`.

[NickWoodward]

Hey Rob, thanks for the reply.

I wouldn't bother adding testBandwidth or abrEwmaDefaultEstimate. Let the default behavior handle startup. Looks good though.

I may be misremembering - I'm away from my set up right now - but I think I added this to optimistically "force" the stream to a certain quality, avoiding the pixelated start (because it's a hero video). I thought testing the bandwidth and startlevel -1 might let it change quickly if that optimistic guess was incorrect. Like I said, I'm new, so there's a good chance this is completely wrong and not how I should be doing things!

If you do that, you need to limit how many active player or hls.js instances are allowed at once. Deferring calls to hls.loadSource(m3u8) OR configuring the player to not automatically load media playlists with autoStartLoad: falseand then callinghls.startLoad()when the player is almost ready is one way to go. Another is to limit the number or HTMLMediaElements on the page and only attach them to hls.js when displayed on the page and ready to play withhls.attachMedia(video)`

Interesting, thanks. I've an HlsVideo component (below), where I register each video in a map in a context provider (so I can play and pause from elsewhere). I guess I can just also register the hls instance and call hls.startLoad. I assume this is the better option? (ie it's loading the video segments that's resource heavy, not the manifests and attaching hls to each video element?)

Basically I've videos further down the page, but more importantly I've 4 in a hero bento grid, and only want the first to play, with the others only playing when expanded. This sounds like the right option, but if you've got any more advice I'd greatly appreciate it!

Thanks again,

Nick

  export const HlsVideo = (...) => {
  const { registerVideo, unregisterVideo } = useVideoControls();

  const videoRefCallback = useCallback(
    (video: HTMLVideoElement | null) => {
      if (!video) return;

      const handleVideoLoaded = () => {
        registerVideo(id, video);
        ScrollTrigger.refresh();
      };

      const hls = new Hls({
        testBandwidth: true,
        abrEwmaDefaultEstimate: 5000000,
        startLevel: -1,
        maxBufferLength: 30,
        maxMaxBufferLength: 60,
        maxBufferSize: 60 * 1000 * 1000, 
      });

      if (Hls.isSupported()) {
        hls.loadSource(url);
        hls.attachMedia(video);
      } else if (video.canPlayType("application/vnd.apple.mpegurl")) {
        video.src = url;
      }

      video.addEventListener("loadeddata", handleVideoLoaded);

      return () => {
        video.removeEventListener("loadeddata", handleVideoLoaded);
        unregisterVideo(id);
        hls.destroy();
      };
    },
    [url, id]
  );

  return (
    <div>
      <video
        ref={videoRefCallback}
        loop={loop}
        muted
        autoPlay={autoPlay}
      />
    </div>
  );
}`

[robwalch]

This sounds like the right option, but if you've got any more advice I'd greatly appreciate it!

You can also suspend segment loading (audio, video, and subtitle data) using hls.pauseBuffering() and hls.resumeBuffering(). This does not stop loading of playlists like hls.stopLoad() and hls.startLoad(), so it can be useful to limit the amount buffered by a player instance without dynamically changing hls.config.maxMaxBufferLength (which is another option for controlling preload after calling hls.attachMedia(video)).

[NickWoodward]

This does not stop loading of playlists like hls.stopLoad() and hls.startLoad(), so it can be useful to limit the amount buffered by a player instance without dynamically changing hls.config.maxMaxBufferLength

oh nice, thanks. the videos were automatically stopping when out of view, but i hadn't considered i should actually stop the buffering.

and you think those buffer settings aren't too aggressive for a 60s video?

    maxBufferLength: 30, 
    maxMaxBufferLength: 60,
    maxBufferSize: 60 * 1000 * 1000,

i just don't have much to base it on, but that feels like a lot?

thanks again though!

[robwalch]

30-60 is fine for the active player. You might reduce maxBufferSize to hedge those values with higher bitrates.

[NickWoodward]

30-60 is fine for the active player. You might reduce maxBufferSize to hedge those values with higher bitrates.

thanks rob, really appreciate it :)

[muze-cincopa]

For your HLS.js settings with a 60-second, 238MB video on bunny.net, the current approach is mostly sound but can be optimized. The testBandwidth enabled is useful for adaptive streaming across different networks. Your abrEwmaDefaultEstimate of 5 Mbps may be too high; lowering this closer to typical user bandwidth improves initial quality selection and reduces buffering risk.

Buffer settings like maxBufferLength (30s) and maxMaxBufferLength (60s) are higher than needed for a short video and can increase memory consumption and startup delay. Reducing maxBufferLength to around 15-30 seconds is usually sufficient for smooth playback without excess buffering.

For videos further down the page, deferring loading improves performance. Use autoStartLoad: false in HLS.js to prevent preloading, then trigger streaming via hls.startLoad() when the video enters the viewport. In React, lazy loading video components or conditional mounting ensures resources load only as needed, improving page responsiveness.

Managing buffer sizes and load triggers this way balances startup speed, network adaptation, and memory use, which aligns with best practices for streaming setups like those used in Cincopa’s video delivery environment.