关于流媒体交付

　　本文我们将分析一个流行的流媒体服务。我们的目标是更好地理解如何使用传统的IT工具对这种类型的视频流进行深入分析。我们将学习广泛应用于故障排除和分析其他类型的音频和视频流的技术。

　　我们选择Netflix作为一个流媒体服务的例子。像Apple HLS 和Microsoft Smooth流媒体一样，Netflix通常使用自适应比特率 (ABR)交付的变体。传输方法与其他视频流(如会议视频、SRT或 SDVoE)非常不同。

　　Wireshark是一个免费的IT工具，了解它如何帮助我们进行分析是很有趣的。在在传统的数据应用程序中Wireshark已经使用了几十年。然而，在这里，我们的重点是它与视频的使用方式。在这里讨论的示例中，网络连接是DSL，其上下行带宽为20/2Mbps。目标播放设备是一台利用Chrome访问视频的 Windows 10电脑。为了捕获Netflix流，该流通过一个以太网交换机，运行Wireshark的分析设备连接到一个镜像端口。

　　使用Wireshark的一个叫做conversation的特性，我们可以获得如图1所示的表。通过查看顶部的各个选项卡并单击列标题对列中的条目进行排序，我们可以看到在192.168.7.116将视频发送到客户端计算机的TCP会话。前三个会话占主导地位，约传输 44 MB。如果我们右键单击该表的第一行，TCP会话的流量就会被分离并显示出来。

　　然后，使用Wireshark的I/O图形函数，得到图2的结果。这说明了发送到端口50926的单个TCP会话所使用的带宽(在图1的第一行中列出)。在前23秒，视频源使用可用的20Mb中的大部分带宽来尝试使播放缓冲区饱和。然后，以大约5-10秒的不同间隔，用小得多的视频传输更新播放缓冲区。如果我们在图1的第2 行和第3行中描述的会话上重复这个过程，我们将看到几乎相同的图。通过同时启动三个会话来发送第一个事件，Netflix可以克服TCP算法带来的一个问题。单个会话将受到连接延迟的限制。

　　那么，我们能从这些迹象中得出什么结论呢?首先，交付中使用TCP，这表明它在TCP算法的控制下。减少带宽将延长发送第一个饱和事件和所有后续事件所需的时间。第二，这个事件的长度将取决于上行路径上的通信量，上行路径传输交付数据包的确认信息。竞争流量或高网络损失率的存在也会延长每个事件的时间。如果这些事件占用了太多的时间，并且播放缓冲区空了，视频就会暂停。这可能会增加视频源切换到低分辨率的可能性。这种干扰也会增加传输中的延迟。

　　请注意，更改播放设备、操作系统或浏览器或互联网连接类型将改变您将看到的结果。然而，至少，我们已经看到了一个视频交付的例子，它与我们分析IPTV、会议视频或视频类型时看到的情况有很大的不同。