-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Support for Low-Latency HLS (LL-HLS) #480
Comments
LL-HLS would be a killer feature. It'd be great! |
Indeed. LL-HLS will be a killer feature. |
Is there a full reference player for playing LLHLS released? If you have any related information, please share. Until recently, I was seeing the draft of the LLHLS protocol being updated and unconfirmed. |
What do you mean with reference player? As for now all iOS Devices running iOS14 or higher are natively supporting LL-HLS, as far as I know. So it would be very useful for native iOS Apps, but Safari is supporting LL-HLS on these devices too with the native player. Also there are already some third party player frameworks, which support LL-HLS with CMAF across multiple platforms. There is to be mentioned theoplayer and also jwplayer. The developers of hls.js are also working on the integration, and should be ready soon. ShakaPlayer is also supporting LL-HLS, but doesn't support CMAF, also not with LL-Dash, if I understood correctly. The VHS extension for videojs also states that it should be all implemented, but it currently lacks testing, so it isn't ready for production, but should in near future. |
@getroot, Apple released demo scripts in PHP and GO : https://developer.apple.com/download/all/?q=hls |
hls.js supports LL-HLS. I'd suggest using that as reference player. For those here who ask for LL-HLS support, may I ask what use case there is for LL-HLS, where WebRTC is not a much better solution? |
@ezadoo you wrote Most Apple or Android devices out in the wild have decent WebRTC support, thanks to Covid19 forcing schools in many countries to use WebRTC based Online Teaching platforms like BigBlueButton or Jitsi or similar. |
@basisbit I'm going completely with your first comment, that the existing issues need to be addressed respectively must be addressed so that LL-HLS can work properly. You're right, if I simply want low latency, WebRTC could do the job too, with all the negative consequences on the server side. I don't want to start here a discussion whether using WebRTC or other protocols nor the pros and cons of WebRTC in general (Scalability, CDNs, Quality, etc). Read MoreI'm not an expert in servers or video protocols. So for multiple thousands of viewers WebRTC is a bad choice, as it generates a huge load on the servers and is therefore much more expensive in server cost than the other, better scalable ways of distribution like HLS or Dash with their low-latency extensions. Also WebRTC needs a rather stable internet connection to maintain a good image quality, and HLS and Dash can handle much better. Also WebRTC doesn't work with CDNs which is a problem for people needing worldwide distribution with CDN. So I keep my answer short: But as both can use the same CMAF-Files we would "only" need an additional playlist linking to the same files, which are already created, and not a decision between LL-Dash and LL-HLS. |
LLHLS released in pre-alpha. Please discuss further in the issues below. thank you! |
Closing this issue now that LLHLS has been released. For further discussion of LLHLS, please visit #766 or create a new issue. Thank you for contribution! |
does it support llhls fmp4 encryption ? |
Is your feature request related to a problem? Please describe.
As OME supports LL-Dash which is, as far as I researched, not working on iOS, also LL-HLS could be supported.
Describe the solution you'd like
As LL-HLS works with the same CMAF-Format, which is also already used by LL-Dash, wouldn't it be possible to generate an additional manifest linking to the same CMAF-Files?
So both, LL-HLS and LL-Dash could be supported, if the CMAF-Files are not encrypted.
Describe alternatives you've considered
Currently the only alternative for iOS is to not use low-latency streaming for iOS-Devices.
Additional context
The text was updated successfully, but these errors were encountered: