video-dev / hls.js

Protocol Extension for Low-Latency HLS (Preliminary Specification)

https://developer.apple.com/documentation/http_live_streaming/protocol_extension_for_low-latency_hls_preliminary_specification#3368929

Functionality

The first step is manifest parsing and this blocks other issues, save some parts of CDN Tune-in. Once we determine we have a Low-Latency stream from the manifest, we can engage other features. These features: playlist delta updates, playlist blocking, and CDN tune-in, can be developed and used in parallel and independently of each other.

1. Low-latency HLS Manifest parsing #2865
2. CDN Tune-in
3. Playlist Request Query Parameters (Blocking Reload with Delivery Directives) #2967
4. Playlist Delta Updates
5. Part Support
6. Hinted Part and Map Preloading
7. Rendition Report
8. Remove support for LHLS EXT-X-PREFETCH tags

Note: Consider ways to use chunk-transfer with features like preload hints (even though it breaks the rule or requiring loading at line speed)

Track issues and PRs specific to support of the HLS spec, interoperability, features and performance.

There's also a DRM track (could be moved into another project) with the ultimate goal of multi-drm and SAMPLE-AES support, with options for in and out-of-band EME configuration. From @itsjamie:

At the manifest parsing level, we don’t treat #EXT-X-KEY as possible to have two keys for the same segment. This is a requirement for Multi-DRM. Widevine/Playready for example can work on the same content but there will be multiple keys for the same segment. So we need to fix this at the data model level. Next, we don’t handle manifest detected DRM at all. I had a first cut (https://github.com/video-dev/hls.js/pull/2735) that got merged with changing it so fragment.encrypted will return true now for DRM encrypted keys that we mark as supported. That flow needs to be hooked up to the EME controller to proactively create a KeySession without waiting for the “encrypted” EME event. https://github.com/video-dev/hls.js/issues/2737 - Not all LevelKeys will be URLs, some will be base64 data (the PSSH), so we need to detect and not use the URLToolkit in those cases, but instead keep that data around to be opaque and passed to the license server.

calmbryan also put up a PR for ClearKey EME support. i’ve given similar feedback there, that for the use case of using ClearKey to add support for SAMPLE-AES, we should look to create the EME session for the user if we detect a EXT-X-KEY with a METHOD of SAMPLE-AES, rather than having users setup a EME session out-of-band. That’s not to say it isn’t useful to allow ClearKey session creation directly with the EME controller config, but for playback support for SAMPLE-AES, shouldn’t be required to config anything for a well-formed stream. Should work similar to AES-128 encrypted content.

And finally, once that internal data model is updated to support this… Adding the EME controller config properties:

• playready license url
• fairplay license url / certification URL
• manipulation hooks for the XHR request / response Promise (license retrieval)

Adding Playready and Fairplay CDM implementations Caching key sessions that are already setup for content (falls under manifest signalled DRM, preemptive session setup) (edited)

Converting HLS.js to use Typescript in the feature/v1.0.0 branch.