Nimble Pull By Request with ABR HLS

Have you any advice if this works (good)?

I have multi bitrate stream, republished around the world, but due to distance, I have to go UK -> West coast USA -> Australia.
but if USA server goes down - then Sydney goes down, happened recently :(

I see that pull by request has failover URLs so I want to change to that. Then Australia can pull from USA but also pull from other servers as failover.

But will PBR work with multi bitrate ABR? (Low, medium, high.)
User would be pulling just 1 bitrate? What happens if HLS decides to change bitrate, maybe there would be delay to change bitrate as it is pulled from origin?

is this a bad idea because of latency? If so any advice?

Thank you

Hi,
my advice is to use pull "origin quality" stream with fail-over on your USA and Australia and transcode for Abr on the same server and probably publish abr stream near edge server if necessary for offload. This way you save bandwidth and have enough robustness.
You cab use Nimble Transcoder for that

Please could you explain about "pull original quality"?

Is this triggered by viewer pull by request?

Or transcoder to pull all of the time?

Thanks.

OK I understand. I will try it. This would be like having multiple origin servers around the world, then smaller edges for restream etc.

Thanks

Actually, what you say is useful for failover, but I'm still wondering how to save bandwidth at my Singapore VPS edge.

If viewer isnt watching, I dont want it to receive stream 24/7.

Since the streams / playlist URL etc is set up for ABR, is it OK to have "pull by request" setup with ABR?
(Perhaps only if the edge server is close to origin server for lower latency bitrate switching?)

Thanks

You are right it was recommendation for fail-over. Unfortunately I don't have any recommendation for pull-by-request + ABR right now. encoding is close to realtime and if you want to have abr+pull by request this may not work in some cases.
If you want to save bandwidth in Singapure try to use single stream rate during low load hours and push ABR when clients most likely to view your stream. I'll think about how we can help you in this case