Support for Low-Latency HLS (LL-HLS)

[ezadoo]

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

[mpisat]

LL-HLS would be a killer feature. It'd be great!

[catapop84]

Indeed. LL-HLS will be a killer feature.

[getroot]

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.

[ezadoo]

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.
Because LL-HLS was developed by Apple I would think that this could be counted as the reference implementation/player.
iOS 14 was released nearly a year ago, so there is a quite high market share among the iOS Devices.
(I call it simply iOS14, but this includes iPadOS14 and tvOS14.)

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.

[nums]

@getroot, Apple released demo scripts in PHP and GO : https://developer.apple.com/download/all/?q=hls
If you don't have an apple developper account, I can share you the dmg file or convert it to zip

[basisbit]

hls.js supports LL-HLS. I'd suggest using that as reference player.
Anyways, before implementing such new stuff, please first fix the existing features and work on implementing the basics that will also be required for LL-HLS, like HTTP-Keep-Alife or HTTP 2 support. Without that, LL-HLS would fail in production just like LL-DASH currently does.

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?

[basisbit]

@ezadoo you wrote Currently the only alternative for iOS is to not use low-latency streaming for iOS-Devices., however, we regularly used WebRTC based high quality video streaming using OvenMediaEngine just fine recently during events with 35k+ viewers, and we got many Apple iOS users reporting that they really like the approximately one second of real-life to screen latency.

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.

[ezadoo]

@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 More

I'm not an expert in servers or video protocols.
But as I understand after a bit of reading is, that WebRTC was made with latency in mind, but not quality and scalability.

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.
(Which is, at least in my situation, much more important than a bit of latency, as we're using quite expensive camera equipment and we are having text-heavy content, which needs to be readable.)

Also WebRTC doesn't work with CDNs which is a problem for people needing worldwide distribution with CDN.
(Not in my use-case but should be considered too, as it was asked for use cases.

So I keep my answer short:
LL-HLS has merely the same use case as LL-Dash but is more widely supported (as it's working on iOS-Devices, but the support of Dash on iOS Devices is quite bad), and LL-HLS is in most cases also supported too, where Dash is supported.
So LL-HLS would be the better choice over LL-Dash in my eyes.

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.

[getroot]

LLHLS released in pre-alpha. Please discuss further in the issues below. thank you!

#766

[getroot]

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!

[fastfading]

does it support llhls fmp4 encryption ?