eldod

Thanks for noticing! We'll make sure to improve this

This is more or less what we do with our our client-side switching solution at Streamroot: we first make sure the user has enough video segments in its buffer, and then we try to get the next video segments for different CDNs, so we're able to compare the download speeds, latency and RTT between the different CDNs without adding any overhead. You don't necessarily download the segments at the same time, but with some estimation and smoothing algoriths you're able to have some meaningful scores for each CDN. The concepts and problematics here are very close to the problematic of bandwidth estimation for HTTP Adaptive Bitrate streaming formats like HLS & DASH, because you have an instable network, and you are only able to estimate the bandwidth from discrete segment measurements. [0]

If you want to do it on a sub-asset (video segment, or image or JS file) level, it's possible by doing byte-range requests (ask bytes 0-100 from CDN A and 101-200 from CDN B), but in that case you still add some overhead for establishing the TCP connection, and in the end as you need the whole asset to use it, you'll just limit the download speed to the minimum of the two.

[0]https://blog.streamroot.io/abr-algorithms-work-optimize-stac...

Both HLS and DASH support redundant streams (by adding a redundant variant URL in the HLS playlist and multiple BaseURLs in the DASH manifest). It's indeed the simplest way to have the easiest way to have a fallback client-side. If you use it, you should make sure that the player supports it, and that the retry mechanisms are rightly configured (like for instance all the MaxRetry config params in hls.js: https://github.com/video-dev/hls.js/blob/master/docs/API.md#... )

Indeed the article is more an introduction to multi-CDN concepts, but take into account that it was written for the HTTP video streaming use-case, and not static content CDNs. A client-side implementation of switching would not be very useful for that kind of content.

For Cedexis, I think the strenght is not only in the configurable DNS routing system, but also because they set up a lot of probes for different CDNs & clouds, and share global aggregated data that anyone can access, which can be useful when you don't a Alexa top1000 traffic.

Have to disagree here, you can have very different performances from different CDNs for the same user at the same time. Some CDNs have their own backbone (or at least partially), a lot of them are using different routes, and a lot of the time, the issue is not with the backbone, but with peering inter-connections, which can be different between each ISP & CDN. And a CDN's capacity is shared between all its customers, so if you get a huge peak from one of them, it can impact the others too. Old but good example: Before Apple started building out its own CDN, it was using the leading commercial one, and when Apple was doing its iOS/MacOS updates, other broadcasters were having big troubles delivering their streams at the same time because the CDN was overloaded - but it doesn't mean that other CDNs were also all down. That's also why most video broadcasters are now doing multi-CDN for their biggest live events like Superbowl or the world cup - to be able to distribute the load on several networks.

Nikolay from Streamroot.io here, co-author of the article.

Yes Conviva provides a service that can give you information about the QoS for the CDN by aggregating data from their customers (they provide a video analytics solution), but it doesn't make the switching (nor on the server side or on the client side), so the video player would need to implement its own logic themselves.

The solution from Streamroot can use this kind of APIs like Conviva Precision, or the one from its competitors like Youbora and Cedexis, and the real value it adds is the client-side switching capability to the players, so it's quite complementary to those solutions.

And indeed the devil is in the details, that's why we built this client-side SDK so the customers don't have to implement all the logic themselves on each platform and device. It was easier for us as we already have SDKs and plugins for most players for our P2P hybrid delivery solution.

Streamroot - P2P, web, backend, media developers and other positions - Paris, France All availables positions here: https://streamroot.io/careers/

By 2021, over 80% of internet traffic is going to be video. Founded in Paris by three students with a vision to revolutionize the video world, Streamroot’s mission is to build more robust and scalable streaming solutions that enable online video providers to scale profitably and offer a better video experience to billions of users around the world. Our groundbreaking patented technology allows media broadcasters to increase their online streaming capacity and to make sure that people in all corners of the world enjoy the best experience streaming GoT ;)

Streamroot is backed by top US & European venture funds including Partech, TechStars and Verizon Ventures. We are a team of ~30 passionate engineers, sales, business and marketing professionals from 14 different nationalities, spread across offices in Paris, New York and Denver. With an expanding customers base that includes media groups like Canal+, Dailymotion and Eurosport, Streamroot powers over 20 million video sessions every day, and we’re just getting started.

Streamroot.io | Backend & System Engineers | Paris, FRANCE | Full-time, on-site At Streamroot, we’re working to overcome one of the biggest challenges facing the internet today: the explosion of video traffic. Our goal is to redesign the way we deliver video online, to create more robust, cost-effective infrastructures, and to touch millions of internet users by bringing quality video to every corner of the world. With a hybrid peer-to-peer accelerated solution to video streaming, Streamroot helps VoD platforms and live broadcasters improve quality of service, scale to growing audiences and cut their bandwidth costs by up to 70%.

* QA & Releases Engineer: https://www.streamroot.io/jobs/qa-release-engineer/

* Product Owner - SDKs: https://www.streamroot.io/jobs/product-owner-compatibility/

* Senior Front-end Engineer: https://www.streamroot.io/jobs/senior-front-end-developer/

* Media SDK Engineer: https://www.streamroot.io/jobs/media-sdk-engineer/

and more on: https://www.streamroot.io/careers/

Streamroot.io | Backend & System Engineers | Paris, FRANCE | Full-time, on-site

At Streamroot, we’re working to overcome one of the biggest challenges facing the internet today: the explosion of video traffic. Our goal is to redesign the way we deliver video online, to create more robust, cost-effective infrastructures, and to touch millions of internet users by bringing quality video to every corner of the world. With a hybrid peer-to-peer accelerated solution to video streaming, Streamroot helps VoD platforms and live broadcasters improve quality of service, scale to growing audiences and cut their bandwidth costs by up to 70%

* Backend & System Engineer: https://www.streamroot.io/jobs/backend-and-system-engineer/

* Data System Engineer: https://www.streamroot.io/jobs/data-system-engineer/

* Senior Front-end Engineer: https://www.streamroot.io/jobs/senior-front-end-developer/

and more on: https://www.streamroot.io/careers/

As well as: https://streamroot.io/demo

Streamroot | Paris, FRANCE | full-time | onsite | http://www.streamroot.io/jobs

Streamroot is developing a p2p-accelerated streaming technology built upon WebRTC, that helps online broadcasters to offload more than 70% of their bandwidth costs while improving the quality of service for their users. We have offices in Paris and NYC, with a total of 20 people, hlaf of them being engineers.

Streamroot is looking for a: - Backend Scalibilty Engineer: http://www.streamroot.io/jobs/backend-scalability-engineer - JavaScript Core Developer: http://www.streamroot.io/jobs/core-javascript-developer

Apply on http://www.streamroot.io/jobs if interested !

This is great news! It will allow to hugely simplify the encoding and distributing workflows, with the same fMP4 segments for HLS, DASH, Smooth...

Hey, Nikolay from Streamroot here.

We also have whitepapers easily accessible on our website, and a free dashboard where you can test our technology in a few clicks. In terms of open-source projects, there are some projects like Bem.tv but they lack robustness when you try to scale.

WebTorrent actually implements the bittorrent protocol, and can be used as a nodejs bittorent client. It extends the bittorent protocol to do p2p sharing inside the browser (but you only can connect to other people using the webtorrent nodejs app or in-browser app, and not all the bittorent network)

FilePizza and Bitfly are much simpler implementations, doing 1-to-1 file transfers in the browser using the basic WebRTC Datachannel API.

Looks like FilePizza is now using WebTorrent too now, as it's mentionned in their FAQ:

"Where are my files sent? Your files never touch our server. Instead, they are sent directly from the uploader's browser to the downloader's browser using WebTorrent and WebRTC. This requires that the uploader leave their browser window open until the transfer is complete."

https://github.com/kern/filepizza

Actually as the article mentions, most broadcasters today are using adaptive bitrate formats like HLS and DASH, that are solving this issue by serving you a bitrate that is low enough for you to handle.

Today the major broacasters often have 6 or 7 different qualities, going from 300kbps up to 4000Mbps for HD.

most people probably don't have the patience anymore to just pause and wait 30 minutes until the download is finished.

And most of the new modern video players support adaptive bitrate streaming, that adapts the quality to your network conditions. Of course if you want to stream 4K video on 2G, you won't be able to do it today, but in that case it's probably easier to download the mp4 file directly

It talks about modern streaming indeed, but if you take a closer look, most of the video consumption today is done by streaming: on Desktop you still have a small portions of download then watch, but on mobile, Set Top Boxes like AppleTV and Roku, connected TVs, etc. You watch everything from the web.

Besides, the decoding/sync/rendering part didn't really change in the last 10 years, the innovations mostly arrived from the Web streaming use cases, with adaptive bitrate formats, that partly solved the multi-devices streaming problem we started to have with the rise of Mobile and OTT (over-the-top) video streaming.

Very true, bandwidth is very expensive today. Some comments to your post:

- Actually, and quite surprisingly, the "cache everything" mode only adds around 25% of used bandwidth in practice. But even 25% is already a big difference if you pay 10 or 50K of CDN bills per month.

- Indeed useless bytes download can create overall congestion brings harm to the network in general, and should be avoided. It's especially true for websites that don't have the money to pay big CDNs and stream with dedicated server with limited capacity.

I don't think MSE is yet enabled on Firefox mobile, it was not working the last time I tested.

It says unsupported here, I guess this one is up to date: https://developer.mozilla.org/en-US/docs/Web/API/MediaSource

A very good article for those who would like to follow the lead of NYT, Youtube or others who recently switched to all HTML5

When did you try doing it? Things evolved a lot in the last 3 years in terms of video streaming support in HTML5, and today everything that was doable in Flash is doable in HTML5 with MSN and EME. You have control over the playback almost up to the keyframe today. Do you have any specific features in mind?

Pseudo-streaming is (and should be) less and less used, and actually loads a lot slower than the new HTTP adaptive streaming formats like HLS and DASH.

HLS.js is doing great on Chrome, FF, Edge and Opera. For Safari it's better to use the native HLS player for now. The best option is to have HLS.js first on compatible latest browsers and Flashls as a fallback on older ones