Hls.js 1.0.0 is coming - please read!

[johnBartos]

Hi all,

For the past few months at JW Player, we've been hard at work designing and creating the next major version of Hls.js. We've been using (and helping maintain) this project for a few years now, and are happy to be able to dedicate resources towards making it even better. The scope of changes includes:

• Low-latency streaming support (via LHLS)
• Progressive streaming for all supported media and stream types via Streaming Fetch Requests
• Re-architecture of critical paths, including segment loading, transmuxing, and buffering
• ~100%~ More TypeScript coverage (with a ton of coverage included in 0.13.0)
• Synchronized playlist reloads
• Improved alternate audio handling
• IMSC1 support
• And many more enhancements and fixes!

The focus of this major has been primarily on two things: progressive streaming, and codebase quality. In addition to enabling LHLS, progressive streaming also gives a performance boost for regular playback (by reducing the time from request to buffer). And we think that the enhancements to the codebase make it easier understand, change, and maintain.

The tentative release date is set for early Fall. We've wrapped up most of the feature work, and have been testing it thoroughly - including A/B tests in production - to ensure that we're not introducing regressions. The results so far have been really good, and we're continuing to make them better so that you have confidence in upgrading to 1.0.0.

While we work with the Hls.js team to get 1.0.0 merged, we will be winding down changes to the current branch. 0.13.x will be the last minor release; and patches will be made if necessary. The scope of 0.13.0 is mostly set so current and future pull requests will likely be deferred until after the 1.0.0 release. However, critical changes will continue to be merged.

If you have any suggestions for breaking changes to include in 1.0.0, please include them in this thread. Improvements to the API and events are especially welcome. And as always, thanks to everyone for supporting and contributing to Hls.js!

(If you'd like a sneak peek of changes, check out the working branch in this draft PR (https://github.com/video-dev/hls.js/pull/2370))

[realeyes-matthew]

@johnBartos How would you and the rest of the team feel about still bringing in the EME support for Widevine and Playready via the PR here https://github.com/video-dev/hls.js/pull/2194 ? The PR got stale but I have bandwidth to to recreate it and address any concerns if we think this could make it into 1.0.0. It is definitely a breaking change from the current Widevine-only EME implementation but the new implementation also supports Playready, has API docs and tests, and is TypeScript.

[johnBartos]

@realeyes-matthew Since it's a breaking change we'll get it into 1.0.0. What will probably happen is that we'll merge the 1.0.0 PR, and then have you rebase against that branch.

[patrickmichalina]

This is awesome. We appreciate the update and hard work. Any word on how Apple's Low Latency HLS will be supported?

[johnBartos]

@patrickmichalina I'm still figuring out how to best tackle that. The request rate of LLHLS will likely require us to put fragment loading in a webworker; otherwise, it'll eat the main thread, or frequently become blocked by other JS running on the page. Actually processing the parts should not be difficult with our new architecture.

The more fundamental problem blocking adoption is stream support. I've been working with engineers across the industry, and we believe that the way Apple has structured LLHLS will be really bad for CDN performance. There are also uncertainties with HTTP2. We recently met with a representative from Apple to give our feedback, and it sounded like they took it to heart. So we'll see. I'm not dogmatic on which LHLS format to support; I'll happily support either.

[littlespex]

@johnBartos I would like to try out the LHLS functionality. I've cloned the JW Fork but I don't see how to enable this feature. Looking at the JW Demo Page I can see the slider is tied to a latency property of the playbackRateController, but I can't find references to them in the code base. Is there something I'm missing?

[stevendesu]

Currently in v0.12.4 it's impossible to switch to audio-only if a video rendition exists:

https://github.com/video-dev/hls.js/blob/master/src/controller/level-controller.js#L116

Is there a reason this was necessary (perhaps dropping video broke some browsers?) or was it just an aesthetic decision? If possible I would like to see a configuration option for allowAudioOnlyLevels or similar, however I fear this might count as a breaking change (hence my comment here) if there are good reasons that they were removed before.

My company streams to many people in rural locations who might be watching video on phones, and it's not uncommon for their internet to momentarily drop below the required speeds to maintain 270p video. In these cases we would prefer to switch them to an audio-only stream and let video resume when bandwidth permits.

[mtoczko]

I would add renderNatively: true to the default configuration. (Demo page)

[ronag]

Does this include progressive manifest loading as well? https://github.com/video-dev/hls.js/issues/566

[itsjamie]

@ronag no. However, Apple has added a new component to the standard for handling delta updates to the manifest that is likely will be implemented in HLS.js at some point which would resolve your issue of having large manifest updates. This would require server-side support.

[dleacock]

I would like to try the Synchronized playlist reloads as I believe it fits my needs. I'm trying to implement a stream with controls (so the playlist has a #EXT-X-ENDLIST tag) but the playlist is also ever expanding. a playlist reload would be very helpful. Any idea how I can test this 1.0.0 feature?

[saPhil]

Is there any chance HEVC support is coming or could come with 1.0.0?

[stevendesu]

@dleacock Instead of reloading a playlist with an #EXT-X-ENDLIST tag (which seems counterintuitive), perhaps a better request would be a flag to allow for seeking on videos that do not have an #EXT-X-ENDLIST tag?

[dleacock]

@stevendesu Thank you for replying. What I'm trying to accomplish is very similar to the YouTube live scrubber where you have a live stream of new footage plus the ability to scroll back and at any time you can click "live" and return back to the latest footage. You can't scrub back unless there is the #EXT-X-ENDLIST in the manifest. From my understanding this feature currently doesn't exist in hls.js. I'd be open to other solutions though.

[stevendesu]

@dleacock The hiding of the scrubber is actually not always controlled directly by the manifest or HLS.js. Most video players (native players, jwPlayer, VideoJS, etc) will hide the scrubber unless the video's duration attribute is set and finite. I know that I've worked around this issue in VideoJS before by creating a Middleware for the duration property which returns the duration of the manifest. This caused the scrubber to start appearing.

I don't have the exact code on me, and if you're not using VideoJS this isn't even that helpful, but the code looked something like:

videojs.use("*", function (player)
{
    return {
        duration: function (duration)
        {
            if (duration === Infinity)
            {
                const seekable = player.seekable();
                return seekable.end(seekable.length - 1);
            }
            else
            {
                return duration;
            }
        }
    };
});

The same general concept (overriding the duration attribute) would likely work in many other contexts, although I'm not sure if it's as simple or straight-forward in other players (for instance, I don't know if you can directly set the duration property on a <video> element or if you need to set some property on the MediaSource which is controlled by HLS.js)

[LucasMaupin]

Hello, we are a small group of devs and would like to help out. Any good first issues out there that we could address? We have within our group some javascript and streaming knowledge. We have already helped out on the TypeScript conversion part.

[OrenMe]

@LucasMaupin thanks for being so engaged and offering to help. I suggest starting by going through recent opened issues and helping triage and reproduce. In addition there is a bi-weekly call you can join, I suggest you join the video-dev slack and there’s an Hlsjs channel there.

[realeyes-matthew]

@johnBartos I pulled the current v1.0.0 branch and saw the EME controller PR I made has been merged / included as eme-controller-2.ts - thanks! Is there anything I can do to make this the primary EME controller for the v1.0.0 release? We also recently added an enhancement on our fork to reuse an EME license instead of making a license request for every variant playlist in the case that the user knows in advance that licenses can be reused on a key session for every variant, which reduces startup time.

[jmar777]

I was curious if there were any updates on this. Are we in a holding pattern until we have a stable spec from Apple?

[robwalch]

@jmar777 LHLS will be removed in favor of Apple’s LL-HLS. v1 needs a lot of work. It’s got some serious issues with live audio track sync. Maintenance of v0.x has taken most of my time. I’ll provide another update with timeline soon.

[livid]

@jmar777 LHLS will be removed in favor of Apple’s LL-HLS. v1 needs a lot of work. It’s got some serious issues with live audio track sync. Maintenance of v0.x has taken most of my time. I’ll provide another update with timeline soon.

So, the following LHLS branch will not get merged?

https://github.com/video-dev/hls.js/pull/2370

I recently managed to build that branch and got chunked transfer working with EXT-X-PREFETCH. It's not perfect, but it seems much simpler than Apple's new specs.

[robwalch]

@livid You can continue to use the feature/v1.0.0 branch in #2370 for LHLS. If and when EXT-X-PREFETCH support is removed, we'll make a new branch before that change for anyone who would like to continue using it.

hls.js aims to provide parity with Apple's media player and browser Safari. The LHLS spec is no longer maintained and the industry is moving towards supporting LL-HLS as the standard for low-latency in HLS. Because of this I plan to put my efforts towards a release which supports LL-HLS.

[AntoninGouzer]

Hello, I did understood that this Lhls version add the feature to start to play the chunk when loading (progressive streaming, maybe I'm wrong? ) Will it be ncluded in the 1.0 without LHLS?

[robwalch]

@AntoninGouzer

I did understood that this Lhls version add the feature to start to play the chunk when loading (progressive streaming, maybe I'm wrong? ) Will it be ncluded in the 1.0 without LHLS?

Yes. Set progressive: true in the config using https://github.com/video-dev/hls.js/pull/2370

[robwalch]

Moved to #2861