视频播放问题和提高性能方案_video scrubbing-CSDN博客

1.Five symptoms of poor video performance

1.1 视频加载缓慢

Perceived Wait Time

Time to first frame (TTFF):

播放开始所需的adaptive bitrate(ABR)流媒体段的数量。(我们稍后将对此进行更详细的讨论。)

视频请求发送到视频加载之间的时间(即接收到足够的数据来渲染第一帧)。如果客户端实现预取或在本地存储视频的副本，则它可能比PWT高得多。

Network-level metrics：

用于连接性能分析的技术指标。这包括DNS解析时间、连接握手时间、下载速度和带宽利用率。

1.2 Video pauses randomly:

try to measure the issue with these metrics:

Number of stalls per-play:

视频回放暂停并进入“缓冲”状态的频率。这是加权的视频长度时，我们聚合多个回放会话。

Time-to-resume (lag length):

从用户看到停止播放的视频到重新播放的时间。

1.3 Low picture quality

性能差的另一个症状是图像质量低，这通常是由于没有足够的带宽来提供更高质量的视频流的结果。这也可能是由于视频优化不佳或基础设施滞后造成的。为了确定它是哪个场景，我们回顾以下指标:

Video variant usage

测量在单个ABR段水平上使用和计数每个视频变体的次数。
A number of variant changes during playback

视频改变显示给用户的变量的频率。
Bandwidth utilization

视频流占用了多大的可用带宽

1.4 When seeking (scrubbing) through a video it takes a while for it to resume

我们使用称为“特技模式延迟”的指标来监控此滞后。

1.5 Video is out of sync with audio or doesn’t play altogether

这种现象可能是由多种原因引起的，但通常是由于终端设备功率不足所致。为了更好地理解此问题，我们使用了有关设备功能的信息，包括有关我们使用的编解码器的硬件支持数据以及回放过程中设备资源利用率的数据。

2 我们的补救措施：调整良好的自适应比特率（ABR）流

为了实现高效的流传输并减轻上面列出的一些问题，我们使用了自适应比特率流传输，这是当前视频交付的行业标准。 ABR流的两种最流行的实现是Apple的HLS和MPEG-DASH。这两种技术都通过将源视频文件编码为具有不同比特率的多个流而起作用。然后，这些流将以相似的持续时间（例如几秒钟）分成较小的段。然后，视频播放器会根据可用带宽和其他因素在流之间无缝切换。这样，当信号较差时，视频仍可以播放（质量较低），而当信号增强时，视频可以跳至较高质量的视频流。

2.1 Tuning ABR streaming

使用ABR的棘手部分是对每个流的配置进行微调，以使它们在产品中发挥最佳性能。值得一提的是，没有一种配置可以普遍应用于所有产品。这是一种高度针对产品的设置，会随着时间的推移而变化。在Pinterest，我们主要处理简短的预生成内容（例如VoD），当用户滚动浏览其家庭供稿时，这些内容会自动播放。它主要用于带宽可能受到限制的各种移动设备上。让我们讨论可以调整哪些参数以满足该条件。

整个过程本质上都是“漂洗和重复”。您选择起始参数，观察回放如何在实时流量上执行，并根据这些信号调整您的配置。随着网络基础架构和设备功能的不断变化，您可能需要继续更新配置。收集上述指标确实可以简化流程。

Number of streams, resolutions and bitrates

我们最初决定要提供多少个流以及要使用哪些分辨率是基于两条信息。首先，我们对可能出现视频的所有产品表面及其尺寸都有很好的了解。其次，我们利用我们所运营的主要市场中可用的网络基础设施的知识来设置初始比特率。

推出初始设置后，我们便开始收集指标：PWT，TTFF，视频播放器多久更改一次使用的流以及我们的流表示可用带宽的紧密程度。根据这些信号，我们进一步调整了设置以最小化PWT。

Frame rate

您为视频流选择的帧速率会显着影响平滑播放所需的必要带宽。它还可能会改变视频的感觉。有三种常用的流帧率。

24fps：过去在电影院中使用。在现代设备上可能有点生涩。
30fps：这是大多数流媒体服务的标准，并且对于大多数类型的内容都表现良好。快速动作序列（例如运动）和想要“真实生活”效果的情况（例如新闻，戏剧，自然视频）可以从更高的帧频中受益。
60fps：这非常接近人眼可以处理的信息量。除非您打算在播放过程中放慢视频播放速度，否则通常不会超出此级别。它通常用于高节奏的场景，以及当您想要视频的“真实生活”时。这不是一种很棒的电影体验，因为它看起来像真实的生活，并且揭示了太多的细节（例如，化妆，服装，风景中的瑕疵）。因此，观看者不会像使用30fps（甚至24fps）的电影那样感受到“电影魔力”。但是，这对于快速动作游戏非常有用。

对于我们的用例，根据经验，30 fps帧速率效果很好。随着媒体库的发展，我们计划向某些媒体文件添加60fps的变体。值得一提的是，降低帧速率以获得最低质量的比特率是有意义的。对于Pinterest，我们以15帧/秒的速度对视频进行重新编码，因为我们发现，用户对视频停滞不满意，而对视频的视线略有些生涩。

Segment size and duration

在互联网上有许多关于段持续时间的建议。很长一段时间以来，Apple建议的段时间为10s，最近他们将HLS流的段时间修改为6s。最适合Pinterest的分段持续时间为4s。我们使用以下准则来做出此决定

一些视频播放器（最著名的是iOS AVFoundation）会在实际开始播放之前加载一些视频片段。对于高质量的流和较长的段，这可能会导致很高的PWT。
段越长，根据网络状况的变化进行回放所花费的时间就越长。
使段非常短（例如1s）会导致对服务器的大量请求，从而增加网络和处理开销。
根据经验，每个段的字节大小应小于1MB。这导致大多数CDN提供者的驱逐率较低。

Video and audio codecs

When deciding which codec to use, there are two limiting factors:

首先是您用于流式传输的技术。例如，HLS会强制您坚持使用h.264视频编解码器和一些受支持的音频编解码器之一。 DASH可以与编解码器无关，因此更加灵活。
第二个因素是用户设备提供的功能。 Pinterest可在全球范围内使用，我们的许多用户使用的旧设备处理能力有限。为了他们的缘故，我们使用最广泛支持的配置– h.264编解码器，主要配置文件，级别为3.1，并附带用于音频通道的HE-AAC v1和v2编解码器。