摘 要：分析传统视频流传输技术与HTTP自适应流媒体技术的各自特点，提出在构建高清视频平台时HLS技术的应用优势；从技术角度分析如何测量OTT用户体验质量，重点阐述HLS视频质量测量的方法，总结出故障排除具体方法。
关键词：OTT，IPTV，HLS，视频故障分析
引言
OTT是“OverTheTop”的缩写，其意指在网络之上提供服务，强调服务与物理网络的无关性。OTT视频是指基于HTTP协议和开放互联网的视频服务，终端可以是电视机、电脑、机顶盒、PAD、智能手机等等。因此，OTT视频技术被业内普遍认为是实现多屏互动的核心技术。
当前以OTT视频技术为主导的网络电视、移动视频和多屏互动业务正以惊人速度增长，超高清智能电视和机顶盒正在悄然进入寻常百姓家庭的客厅。在人们对高清电视节目内容产生强烈需求的同时，也对高清电视的视频质量提出了极高的要求，希望看到零马赛克、零卡顿的超高清极致画面。
目前福建电信建设的2个华为,中兴高清平台均设有专门的OTT节点，为用户提供高清点播甚至4K高清体验。由于超高清视频的高码率特点，其传输时需要更大的带宽、更小的延迟。随着用户群体不断扩大,如何针对OTT技术特点进行业务保障以及故障分析也成为维护人员的重点任务。
1 基于HLS的OTT视频传输技术
1.1 传统流媒体传输技术
传统的媒体内容分发技术主要有两大类，一类是以RTSP/RTP(Real Time Streaming Protocol/Real Time Transfer Protocol)为代表的面向连接的流媒体技术，强调流媒体播放时实时性，主要针对直播节目设计；另一类则是采用的无连接的HTTP渐进式下载，目前主流的视频网站均采用了HTTP渐进式下载的方式来实现流媒体的分发，如优酷网、土豆网等等。
基于HTTP的渐进下载(Progressive Download)流媒体播放仅是在完全下载后再播放模式基础上做了一些小的改进。与下载播放模式中必须等待整个文件下载完毕后才能开始播放不同，渐进下载客户端在开始播放之前仅需等待一段较短的时间用于下载和缓冲该媒体文件最前面的一部分数据，之后便可以一边下载一边播放。
其缺点和不足也很明显。首先是带宽容易浪费。当一个用户在开始下载观看一个内容之后选择停止观看，那么已经下载完成的内容则是对带宽资源的一种浪费。其次，基于HTTP的渐进式下载仅仅适用于点播内容，而不支持直播内容。最后，此方式缺乏灵活的会话控制功能和智能的流量调节机制。
1.2 HAS技术的企业实现方案-HLS
这时HAS技术应运而生，它融合了传统RTSP/RTP流媒体技术以及基于HTTP渐进式下载技术的优点，具有高效、可扩展以及兼容性强的特点。HAS技术的一个关键就是媒体数据的切割分块，每个分块的时间长度相同，相对于传统的流媒体技术，它能够提供更好的服务质量。
APPLE公司的 HTTP Live Streaming 是HAS技术的代表性实现方案。其在渐进式下载的基础上增加了自适应功能（AS）。HLS同时支持流媒体的直播和点播服务，也支持不同bit速率的多个备用流（平时根据当前网速去自适应视频的清晰度），这样客户端也好根据当前网络的带宽去只能调整当前使用的视频流。安全方面，HLS提供了通过HTTPS加密对媒体文件进行加密并对用户进行验证，允许视频发布者去保护自己的网络。
l 以不同的比特率将视频编码成 H.264/TS 格式 (视频源可来自实时直播节目或文件）。
l 通过媒体流分段设备生成一系列的视频内容的短切片（chunk）－通常每个切片长度为10秒，并同时产生一个播放列表文件（ m3u 或 m3u8格式）用以指示在何处可以下载这些短切片。
l 通过普通的HTTP服务器来发布这些由短切片组成的视频内容，并提供适合的缓存机制。
基于HLS优越的分片机制和传输性能，福建电信公司自2016年开始大力发展高清IPTV业务时，就同步构建基于HLS的OTT视频发布平台。
2 基于HLS技术的OTT视频故障分析方法
2.1 传统的IPTV视频质量测试方法不适合OTT视频业务
传统的IPTV和广电VOD互动电视一般采用UDP/RTP协议来承载MPEG-TS视频码流。UDP和RTP协议的特点是传输实时性好，但无法保证上层数据的可靠、无损传输。因此，若视频流在传输过程中发生IP丢包或网络抖动过大的情况，会导致IPTV终端解码后的视频质量出现劣化（如的马赛克、图像模糊现象）。目前业内普遍采用的IETF RFC4445 MDI标准，就是根据媒体丢帧率（MLR）和时延系数（DF）来测量IPTV网络传输质量。
与传统的IPTV和VOD互动电视不同，OTT超高清视频一般采用标准HTTP/TCP协议来递送媒体数据文件（如FLV、MP4、MPEG-TS等格式）。TCP协议的特点是可靠连接、无损传输。当出现网络丢包或数据差错时，可通过TCP重传机制来加以恢复；网络抖动和延时一般也可被客户端的下载缓冲所消化。超高清视频很少出现马赛克等视频质量问题，只有当客户端缓冲区的视频播放完又没有及时下载到新的视频片段时，才会出现画面停顿或等待缓冲的现象。
综上所述，由于超高清视频质量不受一般的网络传输损伤（如少量丢包、网络抖动）的影响，传统的IPTV网络传输质量测试方法（如MDI）已经不适应于OTT超高清视频了。
2.2 基于AS技术的OTT视频QoE/QoS测量
影响OTT视频用户体验(QoE)的因素有：
l 技术因素：视频和音频（媒体）质量，如：清晰度、播放流畅度等。视频点播操作的响应速度，如：暂停、搜索的速度。
l 其它因素：价格、节目内容、软件易用性等。
作为从事网络维护的技术人员，本文还是以技术角度进行分析。
图1 HLS分片传输可能出现场景
1、理想情况：分片按时开始传输；分片传输时间快于分片播放时间。此时无故障，终端和视频服务器分片传输调度正常，网速快。用户体验优良。
2、缓存区持续增长：分片传输时间快于其播放时间；分片传输间隔短于分片播放时间。无故障，终端或视频服务器对分片传输的调度算法不是最优化，网速快。用户体验良好。
3、一般情况：分片基本按时开始传输；分片传输时间同分片播放时间基本相当。无故障，终端和视频服务器对分片传输的调度正常，网速偏慢。用户体验一般。
4、缓冲区下溢：分片传输时间快于其播放时间；但分片传输间隔过大，未按时开始传输。终端或视频服务器故障（分片传输调度异常），网络正常（速度快），用户体验出现卡片。
5、缓冲区严重下溢：分片传输时间慢于其播放时间；并且分片传输间隔大于其播放时延。终端或视频服务器故障（分片传输调度异常），网络拥塞（速度慢）。用户体验严重卡片。
由上可见，在视频源正常前提下，OTT视频播放流畅主要取决于视频文件分片是否能及时下载（即视频文件下载时间）。而IP网络性能和Web服务器性能都会对HTTP下载速率产生影响。
2.3 故障排查第一步：网络性能与服务器性能隔离
对OTT视频下载过程进行分段测试，可隔离网络和Web服务器性能问题。
图2 OTT视频下载过程
l TCP连接建立时间慢，TCP重传率高--IP网络性能可能存在问题。
l TCP连接建立速度快，HTTP响应时间慢--Web服务器性能可能存在问题。
2.4 故障排查第二步：服务器性能分析
CDN服务器的性能和部署位置对超高清视频质量的影响是至关重要的，为了保障超高清视频质量，就必须能有效地监测各CDN服务器的性能状况和服务质量，当CDN服务器出现性能问题时需要及时告警，并应根据CDN服务器的性能和负载情况，合理地进行CDN服务器的负载均衡调度、网络部署位置优化。CDN服务器的主要QoS指标包括：
l HTTP请求数：终端向服务器发送的视频流HTTP GET请求消息数。
l HTTP成功响应数：服务器对终端发出的视频流HTTP GET请求给予成功响应的次数，其中不成功的响应包括：在设定时间（如60秒）内无响应和返回HTTP错误响应码（包括4XX和5XX）这两种情况。
l HTTP请求成功率：计算公式为A / B，其中A为该CDN服务器向所有终端发送的HTTP成功响应总数；B为所有终端向该CDN服务器发送的HTTP请求总数。
l HTTP响应时延：计算从终端发起视频流的HTTP GET请求消息到收到该视频流的第一个数据包的时间差。
l HTTP错误返回码个数：包括“4XX“终端错误返回码和”5XX“服务器错误返回码。
2.5 故障排查第三步：中间网络故障定位
对于中间网络性能分析，基本思路是：在源端到用户端之间取多个观察点视频流数据进行分析比较，以确定故障点，但实际工作中，同时取得多点数据信息的工作量是十分繁琐艰巨的，特别在没有固定探针协助的情况下。往往我们只能获得一个测试点的视频数据（通常是用户端），在此情况下，我们依然可以依据下面数据的分析，尽可能缩小排查范围：
l 分析下载速率判断带宽是否充足，下载速率（bps）：超高清视频媒体流的有效下载吞吐率。
l 分析TCP重传率，TCP重传包的个数。TCP协议具有差错恢复机制，TCP重传包是指为补偿网络丢包所重传的TCP包。TCP重复包不被计算在TCP重传包统计中。若在某个网络中间节点检测到TCP重传包，则可判断该中间点或其上游节点存在网络丢包，并且这些丢包已经被TCP重传机制恢复。
l 分析分片下载偏移，判断网络是否存在拥堵或者丢包。严重拥堵情况下分片会出现断流。
3 案例
某用户机顶盒播放高清点播时经常出现卡屏现象，维护人员在班组测试观看正常，且观察视频CDN各HTTP响应指标均正常。由此判断CDN服务器工作正常，CDN至用户机顶盒中间网络某处存在问题。在用户端使用VLC-Player牵引视频流，在PC上使用德科仕软探针进行分析，得到视频分析数据如下图示：
图3 软探针分析数据
l HTTP响应时间正常（68ms)，说明Web服务器性能正常。
l 分片下载偏离3.449秒，这说明10秒的分片下载了13.449秒
l TCP重传率（紫色曲线）在5%左右，峰值时可达16%，这说明用户接入网络存在一定丢包。
用Wireshark对严重断流问题进行分析，发现存在TCP丢包严重导致大量重传。
图4 Wireshark分析数据
结论：用户接入网络存在一定的网络丢包，导致部分TS分片不能按时下载完成。视频的卡屏现象主要是由于IP承载网丢包导致的，建议对用户接入网络质量进行评估测试。后排查用户自家局域网排除了故障。
4 结束语
作为一名长期从事电信IPTV网络维护的技术人员，我深切体会到，视频卡顿故障原因复杂，难于定位，处理耗时长，为了提高测试效率和降低测试成本，网络工程师往往希望只在一个监测点部署单台测试设备来进行故障排查，并希望能通过关联性信息分析便可以最大限度地定位故障所在的位置。
随着OTT用户数量不断增加而使得网络流量增大，各种新业务内容的引入会使得网络流量组成更为复杂，更多OTT终端类型的引入会造成新的兼容性问题。所有这些因素，都会使得OTT用户体验质量保证变得更复杂和更具挑战性。
通过对OTT设备和网络进行有效的用户体验（QoE）性能验证、监测和故障诊断，可以帮助网络运营商和设备厂家更快速、高效地实现对OTT网络的建设、管理和维护工作，从而推进三网融合产业的健康发展和走向成功。
