移动端音视频需求实现方案探索
一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第1天，点击查看活动详情。
通过这篇文章，你将收获：1. 音视频的相关知识点和技术 2. Flutter中关于音视频操作的相关技术 3. 商用场景下，音视频需求的
主流实现方案
写作背景
最近的项目是一个健身类的Flutter App，其中核心功能是训练课程的播放。由于多种因素导致用户体验非常差，因此在接手项目的半年里我对这块功能做了2次改造，并且预研了一套长期的方案以支持课程播放这个核心功能的持续迭代。所以记录分享给大家，避免重复踩坑走弯路。
需要说明的是：音视频(或者说任何技术难题)的难点都是在于解决方案，而不是任何具体的实现代码；而方案往往不是一蹴而就，因为涉及到前端需求、开发资源、团队资源等一大堆问题，接下来我会着重聊聊我在音视频需求实现方案的整个探索过程。
落实方案的坎坷之路
一、亡羊补牢
项目初期，App的课程直接在线播放，也不做缓存机制，用户训练过程中进行出现训练5秒等待10秒的情况，而且每次都在线加载，极其耗费流量。因此我们对视频进行分析得到码率竟然达到了16000kbps+，以至于短短30秒的视频就有60MB，这是播放过程中总是缓冲的原因；同时视频的索引信息没有做优化，moov atom放在末尾，播放器解码速度慢，导致首次等待时间长。
鉴于运营能力，只能先使用压缩工具减小视频大小。我这边紧急上线一个下载功能，训练之前把所有课程章节的视频缓存到本地，训练过程使用本地资源播放。技术方面Flutter直接使用dio download按顺序下载。
二、与时俱进
通过临时上线的下载功能，用户可以顺畅训练；但很快又引出下一个问题：视频大小压不下，10个章节可能需要5 min+的下载时间，同时文件完整性没有做校验，出错率较高。如何解决？
- 从源头入手：通过跟剪辑人员的大量交流以及不断制作demo查看效果，我们发现一个尺寸为
1080 * 1080的mp4，码率在2000左右、帧数峰值25，在任何分辨率/dpi的手机屏幕上，流畅度和清晰度都完全没问题。然后再通过专业的压缩工具，基本每分钟的视频可以控制在8M以下。因此要求内容团队的同事按照这个尺寸出视频即可。 - 优化下载机制：下载的机制从最简单粗暴的按顺序下载改为：下载第一章节，进入训练页面会启动后台下载，同时支持断点下载。 由此减少用户的等待下载的时间，同时避免用户切章节的时候，原先未完成下载的章节作废，节约了重复下载的流量。（主要也给服务器节流😊） 这里聊下Flutter断点下载的实现：-
明确下载过程中的文件我们以.mp4.temp后缀名结尾，下载完成的文件以mp4结尾；-读取本地缓存中此资源未完成下载的文件长度；-把已下载的长度设置在dio get请求headers的"range": "bytes=$downloadStart-"中；-通过stream把下载进度通知给调用方。
Future<void> downloadFile({
required String url,
required String savePath, // 本地缓存的路径
required CancelToken cancelToken, // 下载凭证由调用方传入，以操作下载节点（如：取消）
ProgressCallback? onReceiveProgress,
void Function()? done,
void Function(Exception)? failed,
}) async {
int downloadStart = 0;
File f = File(savePath);
if (await f.exists()) {
downloadStart = f.lengthSync();
}
print("start: $downloadStart");
try {
var response = await downloadDio.get<ResponseBody>(
url,
options: Options(
/// Receive response data as a stream
responseType: ResponseType.stream,
followRedirects: false,
headers: {
/// Downloading key locations in segments
"range": "bytes=$downloadStart-",
},
),
);
File file = File(savePath);
RandomAccessFile raf = file.openSync(mode: FileMode.append);
int received = downloadStart;
int total = await _getContentLength(response);
Stream<Uint8List> stream = response.data!.stream;
StreamSubscription<Uint8List>? subscription;
subscription = stream.listen(
(data) {
/// Write files must be synchronized
raf.writeFromSync(data);
received += data.length;
onReceiveProgress?.call(received, total);
},
onDone: () async {
file.rename(savePath.replaceAll('.temp', ''));
await raf.close();
done?.call();
},
onError: (e) async {
await raf.close();
failed?.call(e);
},
cancelOnError: true,
);
cancelToken.whenCancel.then((_) async {
await subscription?.cancel();
await raf.close();
});
} on DioError catch (error) {
if (CancelToken.isCancel(error)) {
print("Download cancelled");
} else {
failed?.call(error);
}
}
}
- 文件完整性校验：使用md5编码对文件完整性进行校验，运营平台上传视频时进行编码，App端下载成功后进也行md5编码，二者相同则判定文件完整。
File(path).readAsBytes().then((Uint8List str) {
if (md5.convert(str).toString() == md5Str) {
// md5Str是服务端返回的编码
// 二者相同，文件完整
}
});
三、展望未来
经过两次的优化，基本能满足目前用户的使用。但还远远不够，我想对标Keep，达到如下期望：视频秒开、播放流畅、节省流量、提高安全性（比如：拥有自己的编码格式）、区分码流（不同尺寸/不同网络情况下选择最优解）。
一般情况下，视频流从加载到准备播放过程需要经过解协议、解封装、解编码等这样的过程，其中协议已定，我们用的是HTTP协议；封装通俗点说就是格式，比如mp4、m3u8、rmvb等；而格式通常是对一套编码格式的封装，如MP4的编码格式大多是h264、h265；m3u8是HLS；RMVB主要是RV40；
- 确定容器我希望能够达到区分码流的效果，客户端在播放顶级m3u8文件时，会选择码率高的流，当码流达不到时会请求码率低的流，所以m3u8本身可以直接用于多码率视频；因此
确定使用m3u8格式进行视频存储。如何做到m3u8格式转换？1. 运营平台在上传视频的时候，使用ffmpeg对源文件进行编码，处理适配多码流外；2. 服务端选用支持 转码 和 动态码率 的支持，七牛云和阿里云都有类似的支持，通过转码统一所有编码和压缩，并且提供多码率视频。 - App端的实现细节1. 缓存机制是一个难点，m3u8是ts文件的集合，在播放过程中会出现跳过部分切片的需求，所以ts文件是不会按顺序缓存的，因此如何顺序匹配是个问题；2. ts文件的完整性校验不通过时，需要请求在线播放，这个容错机制同样是个难题；3. 边播边下载的技术实现，这块我暂时还没有去了解，但肯定是一个难点😄；......
- 提高安全性爱奇艺和腾讯视频，其实都有自己的编码格式，但目前我们的项目并非完全的视频播放应用，故我认为对切片进行加解密已经足够了，比如
AES-128。 - 视频秒开视频秒开的优化主要在于
一秒内成功加载的播放数/播放总数，我们知道m3u8是由多个切片组成，因此秒开跟第一个切片的大小息息相关，一般第一个ts片段长度控制在1~3秒。视频第一帧（类似关键帧的概念）要把画面补足，最好就是在视频剪辑过程中，在降低码率的时候，包住关键帧（这个我也是道听途说，做过视频编辑的运营才能懂了😂）
写在最后
其实预研下来，目前主流的方案大多包含这些技术点：m3u8格式、hls编码、AES-128加解密、边播边下、关键帧控制......
目前主流的库：android端 gsyvideoplayer、web端 xgplayer,可惜Flutter还没有遇到很好的库，目前我们用的是官方的videoPlayer,期待更多的开源了。
对于音视频的探索，我也是逐步学习过程中，期待关于此篇文章更多的讨论！