Sign up to save your podcasts
Or
Share The Algorithm Series: Live Event Scaling
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
The Algorithm Series: Live Event Scaling
The Algorithm Series: Live Event Scaling
After the pause in sports, concerts, festivals, and other in-person gatherings for most of 2020, there is plenty of pent-up demand for large-scale events as we head into 2021. How will the companies that deliver live-streamed events meet potentially unprecedented demand? This latest installment in our Algorithm Series delves into the math and workflow decisioning used to fine-tune live video event delivery at scale.
Unicast Delivery
Many live-streaming solutions focus on unicast delivery, in which there's a single connection between the video streaming server and the end user's streaming player (a "client" in networking terminology).
Before the advent of HTTP streaming delivery, in which a stream is broken down—at the cost of an additional 15–30 seconds of latency (or delay) for a live stream—into a series of segments or chunks, most unicast delivery was based around real-time transport protocol (RTP) and derivatives like Adobe's Real-Time Messaging Protocol (RTMP). The upside of RTP-based live streams was that they could be delivered with very low latency (low enough, in fact, that they're still in use for some forms of web-based video delivery, such as WebRTC), but the downside was scalability. For every end user who needed to receive a live stream, a server had to establish a direct delivery connection (known as a "state") to be able to deliver it. That meant having very expensive servers and large-capacity bandwidth that were often only available at major internet peering-point data centers.
Peer-to-Peer (P2P) Delivery
Research in the late 1990s and early 2000s focused on scaling beyond unicast live streams, through the use of either HTTP delivery or peer-assisted delivery.
Peer to peer (P2P) uses connections between clients that were either coordinated with the server or completely independent of the server, but which needed far fewer servers once the initial content was seeded out to a set of peers. Interestingly, the server-independent P2P approach didn't spring from streaming, per se, but was tangentially attached to it: Decentralized P2P BitTorrent servers were used to coordinate unauthorized file-sharing of premium downloadable media content.
While P2P fell away in popularity with the subsequent crackdown on file-sharing sites, the efficiency and cost-effective nature of this peer-assisted delivery—with fewer servers and a limited requirement for massive bandwidth throughput from a central data center—caught the attention of videocentric network architects.
Yet P2P didn't solve all of the problems of scalability. One reason was that not all peers were created equal (or even behaved as if they were equal), due, in part, to differing network topologies. In "Using Topology Information for Quality-Aware Peer-to-Peer Multilayer Video Streaming," a 2014 paper published in Wiley's International Journal of Communication Systems, a team of authors at Ghent University's Department of Information Technology takes on the problem of leveraging network topologies to deal with the quality of the streaming experience. Here's an excerpt from the introduction:
In this paper, we introduce a model to include network information when streaming a (multilayered) video in P2P frameworks. An important metric for video stream providers is the content quality perceived by end users. The optimization studied here aims at maximizing the number of users receiving a high-quality video.
The paper addresses the optimization problem seen from the stream provider's viewpoint, having access to network topology information. An exact optimization approach is presented for benchmarking purposes and a heuristic approach to cope with realistic network sizes.
Given the fact that the paper's focus is on service providers such as CDNs and ISPs, the authors make the assumption that the service provider would install peering nodes "on well-chosen locations in the network and [lease] sufficie...
View all episodes
By SMAdvancedForum-NewsThe Algorithm Series: Live Event Scaling
After the pause in sports, concerts, festivals, and other in-person gatherings for most of 2020, there is plenty of pent-up demand for large-scale events as we head into 2021. How will the companies that deliver live-streamed events meet potentially unprecedented demand? This latest installment in our Algorithm Series delves into the math and workflow decisioning used to fine-tune live video event delivery at scale.
Unicast Delivery
Many live-streaming solutions focus on unicast delivery, in which there's a single connection between the video streaming server and the end user's streaming player (a "client" in networking terminology).
Before the advent of HTTP streaming delivery, in which a stream is broken down—at the cost of an additional 15–30 seconds of latency (or delay) for a live stream—into a series of segments or chunks, most unicast delivery was based around real-time transport protocol (RTP) and derivatives like Adobe's Real-Time Messaging Protocol (RTMP). The upside of RTP-based live streams was that they could be delivered with very low latency (low enough, in fact, that they're still in use for some forms of web-based video delivery, such as WebRTC), but the downside was scalability. For every end user who needed to receive a live stream, a server had to establish a direct delivery connection (known as a "state") to be able to deliver it. That meant having very expensive servers and large-capacity bandwidth that were often only available at major internet peering-point data centers.
Peer-to-Peer (P2P) Delivery
Research in the late 1990s and early 2000s focused on scaling beyond unicast live streams, through the use of either HTTP delivery or peer-assisted delivery.
Peer to peer (P2P) uses connections between clients that were either coordinated with the server or completely independent of the server, but which needed far fewer servers once the initial content was seeded out to a set of peers. Interestingly, the server-independent P2P approach didn't spring from streaming, per se, but was tangentially attached to it: Decentralized P2P BitTorrent servers were used to coordinate unauthorized file-sharing of premium downloadable media content.
While P2P fell away in popularity with the subsequent crackdown on file-sharing sites, the efficiency and cost-effective nature of this peer-assisted delivery—with fewer servers and a limited requirement for massive bandwidth throughput from a central data center—caught the attention of videocentric network architects.
Yet P2P didn't solve all of the problems of scalability. One reason was that not all peers were created equal (or even behaved as if they were equal), due, in part, to differing network topologies. In "Using Topology Information for Quality-Aware Peer-to-Peer Multilayer Video Streaming," a 2014 paper published in Wiley's International Journal of Communication Systems, a team of authors at Ghent University's Department of Information Technology takes on the problem of leveraging network topologies to deal with the quality of the streaming experience. Here's an excerpt from the introduction:
In this paper, we introduce a model to include network information when streaming a (multilayered) video in P2P frameworks. An important metric for video stream providers is the content quality perceived by end users. The optimization studied here aims at maximizing the number of users receiving a high-quality video.
The paper addresses the optimization problem seen from the stream provider's viewpoint, having access to network topology information. An exact optimization approach is presented for benchmarking purposes and a heuristic approach to cope with realistic network sizes.
Given the fact that the paper's focus is on service providers such as CDNs and ISPs, the authors make the assumption that the service provider would install peering nodes "on well-chosen locations in the network and [lease] sufficie...