search

video-dev / hls.js

HLS.js is a JavaScript library that plays HLS in browsers with support for MSE.
https://hlsjs.video-dev.org/demo
Other
14.66k stars 2.56k forks source link

LHLS Implementation #2114

Closed Prendo93 closed 4 years ago

Prendo93 commented 5 years ago

@johnBartos is doing a great job gathering input on a standard spec for LHLS (https://github.com/video-dev/hlsjs-rfcs/pull/1).

I'd love to help out with the implementation for hls.js and I couldn't find anywhere that was tracking work or architecture discussions for it, so I thought I'd start a thread here - if this is the wrong place for this please let me know where to take it.

To help get started I've patched @streamlinevideo's low-latency DASH server + encoder demo to produce an HLS playlist and segments delivered via Chunked-Transfer available here: https://github.com/Prendo93/low-latency-preview

Where should I look to help on this project?

johnBartos commented 5 years ago

Hey @Prendo93, thanks for helping out!

I'd love to help out with the implementation for hls.js and I couldn't find anywhere that was tracking work or architecture discussions for it

The reason why there isn't anything tracking LHLS right now is because JW Player (my employer) is effectively sponsoring LHLS in Hls.js - they've given my team and I time and resources in order to build it. For now, all planning has been done within Jira/Confluence/LucidChart; all of this work will be executed by the JW team. It'd be difficult for us to delegate work to FOSS contributors because we need to ensure that the work is done by a certain time. We can't compel contributors to execute by a certain date. And to be honest there isn't too much to do in the first phase of work (single-rendition playback).

Here's the rough outline of the timeline:

  1. LHLS planning - ticket writing, diagrams, grooming, etc. (we are here)
  2. Execution within the JW fork of Hls.js (public repo, jwplayer/hls.js)
  3. Testing using JW automation and SDET resources, along with partners building LHLS encoders
  4. Pull request against Hls.js master
  5. Community PR review and more testing with encoders
  6. Merge/Ship!
  7. Continued work on further LHLS features

Once planning is done I plan on opening all of the planning documents/diagrams for comments. But by this point there won't be any big architectural changes.

So how can you (or anyone) help?

  1. Encoder support
  2. Iteration on LHLS API and events, and feedback around breaking changes coming with the rearchitecture
  3. Testing and PR review
  4. LHLS spec feedback
  5. Ideation of advanced features (ABR, playback rate manipulation, synchronization).

It's great that you've patched LHLS into streamline - I've been meaning to work on gaining their support for LHLS. As for the client, there's not much in the way of execution for now, but we will definitely need community input with regards to new API/Events and breaking changes (which would necessitate a 1.0.0 version). In the future I believe that there will be more opportunity for collaboration on the advanced features, such as ABR. But the thing we need most from the community right now is encoder support and test streams.

Again, thanks a ton for taking an interest in helping. I'll help out any I can with getting LHLS merged into Streamline. If anyone else would like to help clientside, sit tight for now - when planning is done on our end all of those documents will be made public for review. It remains an ongoing challenge to delegate work from JW to Hls.js contribs but I'll see what I can make happen.

shenyute commented 5 years ago

Any timeline for when the work will be ready?

jmar777 commented 5 years ago

Apple just announced a protocol extension for Low-Latency HLS [1], which at first blush, seems to largely diverge from the community RFC.

Given that iOS Safari continues to hold off on Media Source Extensions (but presumably will support Apple's variant of LHLS), does it make sense to prioritize protocol support for Apple's version, as that would allow a single manifest and segment format to service a broader range of devices?

[1] https://developer.apple.com/documentation/http_live_streaming/protocol_extension_for_low-latency_hls_preliminary_specification?language=objc

johnBartos commented 5 years ago

Hi @jmar777, I'm aware of the new standard and am putting together some next steps. I'll keep this thread updated when I have more to share

patrickmichalina commented 5 years ago

@jmar777 it looks like MSE support is finally coming to iOS 13. But only for iPads! It’s a good start and better than nothing.

https://developer.apple.com/documentation/safari_release_notes/safari_13_beta_release_notes

jmar777 commented 5 years ago

@patrickmichalina glad they're finally making a step in that direction, but frustrating that it's just a baby step.

Fun fact: Chrome has supported MSE since before "Call Me Maybe" was a hit. 7+ years behind the competition is a pretty lousy look for a browser that wants to tout standards compliance.

kevleyski commented 5 years ago

Apple low latency test stream I set up if useful (uses CDN) https://alhls-switchmedia.global.ssl.fastly.net/lhls/master.m3u8

maxbaluev commented 4 years ago

Any updates on this?

robwalch commented 4 years ago

See feature/v1.0.0 PR for chunked transfer support ("LHLS") https://github.com/video-dev/hls.js/pull/2370

Apple's LL-HLS is still a work-in-progress. We don't have any issues or PRs tracking addition of those feature at the moment.