There are several factors to consider in a multi-CDN delivery solution.
First, is it VoD or Live?
HLS (and DASH) have a second URL option (base URL in DASH), for the client to determine when to choose that Fallback URL. If playback falls back to the second URL, that fallback experience to the viewer, could have had some buffering, or bitrate downshifts triggering that player decision.
Although stream playback recovers/continues, the user experience could have and likely was impacted. Here a second CDN in the multi-CDN deployment was accessed by the client. There is no intelligence here, in the provider selection. Typically the (perceived) most reliable CDN gets that first spot, and the backup CDN gets the Fallback position (second URL) in the manifest/MPD.
In Live, you have the opportunity to provide intelligent CDN selection on every manifest/MPD refresh. If your multi-CDN selection layer has intelligence, access to performant metrics, in real time, that manifest can now point (directed) to the alternate CDN. This requires a level of manifest management on the session level, so that the m3u8 retains the proper historical CDN selection so as not to break playback for that session (in most if not all cases).
There are client solutions, DNS solutions, and cloud solutions that are neither client (sdks), or DNS based. You get to decide how you want integration to be managed and how much work your team can/can't invest in your solutions ongoing level of effort.
Why is most important to consider is the viewer experience, and how playback can best be delivered to avoid buffering, downshifts, the things that cause a viewer to abandon your content and possibly not come back.
If a CDN is performant, and N+1 users are now beginning to watch a stream on that providers network, capacity could be (often is) an issue. Continuing to send users to that CDN may be a sub-optimal experience. Metrics measuring playback determine that bitrates are dropping, buffering increasing, and serve new requests with an alternate CDN providing a better playback experience.
Video is a tightly controlled series of events. We work with chunks of 10s, 6s, 2s, for large buffers, and fast start times. Continually trying to balance the benefits of both.
With an SDK client based solution, you have engineering effort to keep up with OS/hardware updates, testing new code in SDKs, and then pushing out across several platforms, players, etc. Can be daunting.
With DNS, you have TTLs to manage, while lower is better, faster for that next user, there is no mid-stream switching with intelligence once the client is pulling manifests from a specific provider.
With a cloud based solution, each individual stream/user/device is measured and Can selection performed in real time for Live, and for _each_ request on VoD.
Disclaimer, I work at DLVR, and formerly Cedexis. = ]
At the time when Audion, and Soundjam were the only (real) Mac MP3 choices, I worked at MP3.com.
I recall conversations over email, phone (and even in person once (unplanned "hey I'm...")) with Cabel, a great guy. Our email exchanges led to putting Audion into the MP3.com recommended players page.
Everyone at MP3.com (on the engineering side) loved the quality Audion app. When we saw that Soundjam had become iTunes, we gasped, "how could they choose that app over Audion?"
A lot of internet history during that time. One thing is for sure, content, and the access to that content is still the fuel of internet growth.
I tip my hat to Cabel, Audion, Panic, and the team. I always felt like you were one of us, as in Panic build quality products coded by team who care about what hey send out.
Will require two things, a shift in vehicle insurance costs.
And the costs for personal insurance and fuel to be a barrier swaying public interest.
There will still be a desire to drive, although falling out of popularity including stigma against "drivers" who less safe than the systems designed to protect passengers, but are willing to pay for the pleasure.