We're using Nimble Streamer for transmuxing of RTMP stream into LL-HLS. And playback of LL-HLS stream works great when we play it directly from Nimble. But now we trying to setup CDN in front of it, and having playback issues when play it through CDN (404 for part files from time to time).
So i setup a simple reverse proxy using nginx in front of Nimble to debug this and noticed few problems. When i preload part files from EXT-X-PRELOAD-HINT tag using proxy i'm getting 404 error and when i do that directly from Nimble it works normally (block request until this part is ready and then send it). And the same happens with CAN-BLOCK-RELOAD feature, when i request playlist with _HLS_msn and _HLS_part queries through the proxy Nimble seems to return just the current version of the playlist and when i do that directly Nimble seems to block request and return playlist only when this part was encoded and added to playlist.
So it feels like Nimble behaves differently depending on some parameters of request. Do you have some specific requirements to apply LL-HLS behaviour? And do you have any proxy/CDN recommendations for LL-HLS streams?
I suggest posting a ticket at wmspanel.com/help with more details so our developers could take a look. (Additionally, we also need details on your proxy configuration and actual stream URLs.)
At the moment we do not have any special recommendations for using LL-HLS with reverse proxy.
LL-HLS is a new beast and there are no much experience and information about it’s support in proxies. Akamai and Amazon are working on LL-HLS pricing support right now. I’m sure you will not be able to setup regular nginx proxy to deal with LL. Nimble works the same way in both cases. But your CDN/proxy should support LL. It works differently than legacy hls. It’s not Nimble problem. Ask your cdn when they add support for hls ll.
I think i found the cause of different behavior for proxies requests and direct requests to Nimble server. Most of the proxies and CDNs (we are testing Fastly and Akamai, both claim to support LL-HLS) send edge to origin requests over HTTP/1.1 and LL-HLS players send it over HTTP/2. And it looks like if Nimble server receives HTTP/1.1 request for new part file from EXT-X-PRELOAD-HINT tag, it just returns 404 error. While if i send the same request over HTTP/2 Nimble would block request until part is ready and then send it. So it looks like Nimble applies LL-HLS features only for HTTP/2 requests. I setup HTTP/2 proxy in front of Nimble and now CDNs seem to work fine, but anyway it would good if Nimble can serve LL-HLS over HTTP/1.1 as well, cause current LL-HLS spec doesn't use any HTTP/2 specific features like PUSH as it was before and LL-HLS can be easily served using HTTP/1.1.
you are right. Nimble doesn't support LL-HLS delivery over HTTP/1.1 since LL-HLS requires Http2 for delivery and initially Apple was very strict and starts playback only if server serves content via http2. Latest IOS versions now support LL-HLS via HTTP/1.1 too. We will combine clients feedback and probably add LL-HLS support into Http/1.1.
For now, If you can ask you CDN to use http2 as CDN->Origin transport this will work as expected.
Sounds good, thanks.
and required to achieve the purposes illustrated in the
If you want to know more or withdraw your consent to all or some of the cookies, please
refer to the