本视频来自于Demuxed 2020,主讲人是来自Optus Sports 的Jeremy Brown,演讲内容是用于进度条滑动预览(trick view scrubbing)的四种方式。
首先,对于不了解进度条滑动预览(英文中称为Scrub thumbnail, thumb seeking, trick play…)的读者,这是我们在流媒体网站上使用进度条拖动视频内容进度时常见的一种预览辅助手段,如下图所示:
主讲人将介绍四种不同的构建预览窗口的方式,分别为取关键帧,使用Sprite API,使用VTT Playlist和使用Keyframes Playlist。
讲者首先介绍了当前该技术的最新形态,即Keyframe Playlist。这种方式单独分出一个关键帧流(keyframe renditions)与视频流和音频流并列。这种做法基于三个设想:
1.该功能已经被HLS、DASH标准化;
2.为播放器本地实现功能,无需更多的内容开发;
3.编码时只需在上传时选择“生成关键帧流”即可。
然而后两点并没有普及。实际上,并非所有播放器都能支持该功能;除此之外,很多编码器也并没有提供“生成关键帧流”。
随后作者向我们将这一技术的发展历史娓娓道来。
首先,最初开发人员的设想是简单的每5秒拉一个关键帧,然后用时间戳为这些关键帧命名即可。
但是这带来了一系列问题。首先,这些图像是在拖动进度条途中加载的,这往往是很短的一段时间,图像来不及传输则会造成严重的卡顿。而如果把所有这些关键帧都下载下来,对于一段稍长一些的视频都是不现实的。除此之外,仅仅简单的抽帧还面临不同播放器下不同的尺度等问题。
于是他们想到可以使用在游戏渲染中常用的精灵表单(sprite sheet)。精灵表单旨在解决对于不同图形硬件的适应问题,将许多不同的小图像挤在一张大图像中传输。
然而,如果是一个时长3小时的视频内容,如果以5秒为间隔抽取关键帧,这个精灵表单得有多大呢?实际上这种情况下,其尺寸已经超过了jpeg的最大图片尺寸限制。而且,进度条在屏幕上的长度并不随视频内容变化——如果始终选取5秒为间隔,播放一个较长的视频时,屏幕上几个像素的移动可能导致预览窗口内容的急剧变化,为观众操作带来麻烦。
解决上述问题的方法也非常直接,首先针对视频长度计算采样间隔;其次针对播放器尺寸动态调整关键帧的大小;最后是对于关键帧在时间上的组合与拼接,减少关键帧的急剧变化。
后来,开发者发现,用于字幕传输的WebVTT非常适合该项任务,而由于此前使用的Sprite API和VTT有许多相似之处,开发者很快实现了使用VTT Playlist。即便随后有了更完备的方案Keyframes Playlist,由于许多设备仍不支持,VTT Paylist仍然在被广泛使用。
附上演讲视频: