功能需求
•直播事件与流之间的最大延迟不超过1分钟•系统应能够适应大量用户（异构交付）•系统应能将视频转换为不同的分辨率和编解码器•系统应具备容错性
视频转换和接收
由于我们正在实时直播整个事件，因此我们不能等待整个视频结束后再开始将其转换为不同的格式和编解码器。为了实现这一点，我们可以使用一种名为RTMP（Real-Time Messaging Protocol）的协议。
•RTMP代表实时消息传输协议（Real-Time Messaging Protocol）•我们使用RTMP是因为它是基于TCP的，因此不会丢失数据，更加可靠。我们需要使用TCP，因为我们不希望在传输过程中丢失数据包。如果我们使用UDP之类的协议，虽然传输速度会更快，但在每个阶段丢失数据将导致视频质量下降。
所需组件
•转换服务：RTMP提供视频流，转换服务将该视频流转换为不同的编解码器和分辨率。它还具有作业调度器，以原始视频流为输入，将其转换为所有的分辨率和编解码器。多个工作节点执行这些任务。当有新的原始视频流时，转换服务将其推送到消息队列。工作节点订阅此消息队列。它们接受输入，并在视频转换完成后将其推送到另一个消息队列。•数据库：为了在发生灾难时不丢失视频数据（我们需要容错性），我们将使用数据库存储原始视频数据。•分布式文件服务：在工作节点处理视频后，还需要将结果存储在文件服务中以实现容错性。•消息队列
架构图
向终端用户传输视频
我们将使用内容交付网络（CDN）将视频传输给终端用户。CDN或边缘服务器在地理上更接近终端用户。
由于用户将通过HTTP连接，因此我们可以使用诸如HLS（HTTP Live Streaming）（用于iPhone）或DASH（Dynamic Adaptive Streaming over HTTP）（用于其他操作系统）的协议。
但是，为什么我们要使用HLS/DASH？
HLS/DASH具有自适应比特率。这意味着我们将根据以下因素调整比特率：
•可提供的视频质量•网络速度•客户设备支持的分辨率和格式
由于它是一种流媒体协
议，它可以根据带宽的使用情况和实时需求来合理地进行调整。
注意：与RTMP相比，HLS/DASH是较低质量的连接，因此我们在实时性和质量之间进行了权衡。
为了将视频发送到CDN，我们可以在全球范围内部署服务器。我们将处理后的视频发送到这些服务器，然后服务器将其发送到CDN。
我们将使用RTMP将视频发送到服务器。
但是，为什么我们不直接将处理后的视频发送到CDN？
跨内容交付网络的传播速度可能不太高。因此，如果我们将处理后的视频发送到CDN，而它们在不同位置拥有服务器，则SLA保证可能无法与实时直播保证相匹配。
每当客户端请求视频时，其中一个服务器将客户端引导到CDN上的一个端点。客户端可以使用此端点来获取视频。
缓存
我们将让CDN负责缓存视频。尽管您可以将热门视频片段缓存在内存中，但为了减轻服务器负载，我们可以缓存客户端 <-> 终点的映射。这样，我们可以直接获取终点，而无需每次重新路由。
容错性
为了使我们的系统更具容错性，我们可以使用负载均衡器。如果其中一个服务器离线，我们可以将请求重定向到其他服务器。
折衷方案
•使用WebRTC与使用HLS/DASH进行视频传输。HLS/DASH是基于HTTP并通过TCP工作的。它们保持有序传输。另一方面，WebRTC基于点对点，并通过UDP工作。它可能还会发送无序的数据块。由于我们希望保持视频质量，因此我们将使用HLS/DASH。
所需组件
•内容交付网络（CDN）•在不同位置的服务器
架构图
容量估算
每个直播流需要处理多少个视频？
假设：
•捕捉的视频为8k。•我们要提供的分辨率：1080p、720p、480p和360p。•编解码器数量：4•板球比赛持续时间：10小时•视频大小：10GB
720p视频大小：10/2 = 5GB
480p视频大小：10/4 = 2.5GB
360p视频大小：10/8 = 1.25GB
所有分辨率所需的总存储空间：18.75GB
所有分辨率和编解码器所
需的总存储空间：18.75 * 4 = 75GB
在单个直播流中需要向CDN传输多少数据？
假设：
•用户数量：10,000,000•使用高清分辨率的用户比例：50%•观看直播流的用户比例：50%
标准分辨率下的视频大小：10/4 = 2.5GB
因此，总数据传输量 = SUM(视频类型的大小 * 类型的用户数量) * 平均观看百分比
= (10 GB * 50/100 * 10⁶ + 2.5 GB * 50/100 * 10⁶) * 50/100 = 3.125 * 1000000GB = 3.125 PB
从事件到用户设备传输数据需要多长时间？
假设：
•用户每秒消耗的数据量 = 10GB / 10小时 = 300 kB/sec•将300kB数据传输到最近的CDN所需时间 = 1秒•从CDN向用户传输300kB数据所需时间 = 150毫秒
总传输时间 = 1秒 + 0.15秒 + 0.15秒 = 1.3秒
假设ffmpeg运行速度为视频速度的2倍，处理时间为1 / 2 = 0.5秒
总延迟时间 = 1.3秒 + 0.5秒 = 1.8秒
通过以上内容，我们设计了一个类似ESPN的实时视频流系统，该系统具备容错性、支持不同分辨率和编解码器的视频转换，以及使用CDN进行视频传输。我们还进行了容量估算，估计了处理视频、传输数据和传输延迟所需的时间。
