来源:Demuxed 2021 主讲人:Robert Labonte(Fastly) 内容整理:彭 峰 流媒体格式不断更新新功能,以及一些平台和观众者开始要求实施/采用某些功能。过去,解决此问题的方法是重新编码和/或重新混合现有媒体库以添加新功能。这是昂贵、耗时的,有时需要重新设计您的编码/复用管道以适应。本次演讲将深入探讨跨多个供应商使用边缘计算平台的细节,以通过即时和全球可扩展的方法为现有媒体流实施新功能。
目录
- Dynamic Edge Application
- Segment Pre-Fetch
- Trickplay
- Stream Format Conversion
- Conclusion
Dynamic Edge Application
在许多时候,视频服务提供商或许会有一个巨大的内容库,用户会不定期选择查看这些内容,而视频服务提供商希望不断在视频流播放过程中提供新的功能,平台也还会有其他的要求。此外在满足这些新要求的同时,如何提升用户体验也是重要的。这就是动态边缘应用(Dynamic Edge Application)的设计出发点,并且该动态边缘应用还能实现视频流的格式统一,降低存储和传输开销。
Why Build Daynamic Edge Application?
动态边缘应用具有很多特点,首先其应用程序输出存储在 CDN 的缓存中而不是存储设备中,其次所有的内容都是即时动态生成的,此外也不需要对源视频进行修改,最后应用是一个无状态的形式,所以不需要担心数据库或者其他服务器出现故障而影响视频的播放。
上述的动态边缘应用是基于 Fastly 的 Compute@Edge 框架构建的,使用 Rust 语言编写,并且需要依赖 FFmpeg 库。当然,也可以在其它环境例如不同的框架下使用不同的编程语言实现。
使用边缘计算的主要好处有以下几点:
- 即时规模:当用户增多,流量增加时,可以拓展算力;
- 依据需求使用资源:使用了多少资源就为多少的资源付费;
- 计算能力强大:边缘设备并行计算的方式可以获得强大算力
接下来将展示该应用的一些特点。
Segment Pre-Fetch
片段预取是指在流媒体客户端请求之前,将流媒体段提前放入CDN缓存识别播放列表,并动态地为每个片段URL添加预取指令。当用户观看的视频内容分布呈现长尾分布时即大部分内容只有少量用户观看从而导致缓存未命中,或者当内容生成位置距离用户较远,例如处于不同的大洲,Segment Pre-Fetch 能够使得在媒体客户端发出请求之前流媒体内容被传送的距离较近的边缘设备中。
播放列表将修改段 URL 与预取指令使用查询参数。对于分段请求,当遇到这些查询参数时,它会触发边缘应用中的预取操作,一个典型的再现播放列表如下图所示。因为依赖于查询参数,能够与现有的媒体播放器兼容。并且由于减少了预取指令,减少了404情况的出现。
Rendition Playlist例子
下列的时序图展示了一个非常典型的客户端到 CDN 在到内容生成者的交互示意图,客户端在向边缘设备请求片段 1 时,边缘设备会向 CDN 缓存请求,如果没有命中,则向源端请求,同时边缘设备也会以同样的方式请求后面的一些片段,当客户端请求后续的片段时,客户端将会从临近的边缘计算中获得,
First Segment Request
Trickplay
特技模式(Trick mode)或特技播放(Trick play)是数字视频系统(包括数字视频录像机和视频点播系统)的一项功能,它模仿由VCR等模拟系统提供的快进和倒带操作期间给出的视觉反馈 。基于 JPEG 的特技模式, 动态边缘应用实现了动态生成图像流,其具有以下特点:
- 动态插入图像流播放列表到现有的主清单
- 动态生成图像流播放清单
- 使用 FFmpeg 从视频帧动态生成 JPEGs
- 使用HTTP查询参数来协商未来的处理指令
- 适用于直播和点播
在 Trickplay 过程中,动态边缘应用的请求的处理过程如下,在 Master Manifest 中首先选择 Rendition 播放列表生产 JPEG 图像,然后再使用查询参数添加图像编码到播放列表的 URL 中;在 Rendition 播放列表中,带有图像编码指令的请求返回带有包含图像编码的片段 URL 的播放列表指令;在段请求中,带有图像编码查询参数的请求将第一帧重新编码为JPEG图像返回!
Trickplay请求过程
Stream Format Conversion
视频库中存在许多的 HLS 格式的内容,大多数都是很少被观看的旧视频,因此在大规模数据数据的情况下,重新封装是困难的,但仍然需要维护这些视频流,从而确保与视频播放器的兼容,这个边缘计算应用可以转换现有的 MPEG 传输流 HLS 碎片到 MP4 HLS,并且可选择将音频和视频放入单独的流中,这适用于视频点播和直播流。
要实现上述操作,在 Master Manifests 中,如果音频和视频保持混合则不需要做任何改变,当音频和视频分离,则需要生成新的音频播放列表 URLs;在 Rendition Playlists 中,媒体段 URLs 被使用新的前缀修改,remux 指令使用查询参数被添加;在段请求中,使用复合查询指令被分解。
格式转换的请求处理
Conclusion
在实际应用之后,动态边缘应用表现出了以下特点:
- 边缘计算速度快
- 适用于直播和点播
- 与现有客户端兼容
- 应用程序无缝结合
- 即时规模
最后附上演讲视频:
http://mpvideo.qpic.cn/0b2eaiaasaaahmamhcjwhjrfaawdbebaacia.f10002.mp4?dis_k=3940436f4b5579d9bf2a37237507460c&dis_t=1649675678&vid=wxv_2318034281870491651&format_id=10002&support_redirect=0&mmversion=false