关于iOS视频边录制边上传技术方案的总结

最近公司开发了一款给业务员使用的工具,需要拍摄一镜到底的长视频,业务诉求是要求边录制边上传,因为他们之前别的部门实施过录完之后进行上传,反映不是很好容易失败而且耗时很长…., 经过一番POC发现苹果现有API无法完美的实现该技术方案,倒不是说技术方案很复杂而是苹果没有类似的接口.

比如录制一段视频,需要从头录到尾,才能生成一个完整的视频,录制过程中去读取输出文件路径是读取不到任何数据的,也就是说需要录完整段视频才有可能…这个不是和事后上传一样了嘛.

后来又想直接上传视频流由后端去整合转码为可播放的视频,但是这事儿后端也觉得复杂不愿意干,然后想着能否封装flv格式去上传,当然这也是一种技术方案,实施起来发现复杂度依然很高,需要学习flv封包相关的知识, 后来调研到可以将音视频流buffer用AVWriter写mp4文件存到沙盒, 这样可以开个定时器循环写入多个视频片段,最后将这些片段上传给后端去整合或者本地整合之后进行分片上传.

一开始我iOS这边倾向于使用本地合并然后进行分片上传,方案如下:

1. 开启定时器,每10秒写入一个视频,写入完成之后开启下一个视频写入,直到遇见停止录制的标识即停掉定时器结束写入
2. 写入一个视频时,就开启分片上传,写入第二个视频时,将其按先后顺序追加合并到一起,分片上传读取的文件也改成合并后的这个视频,因为前面的视频数据是一样的,按顺序拼接而已,分片读取类似游标一样,上传到哪就读到哪
3. 需要注意的是合并本地分片时,暂停读取分片数据,合并完成再进行读取,所以需要设置一个合并周期和分片读取的周期,能错开最好

后来我完成基本的代码设计之后,Android老哥提出新的方案,要求后端采用ffmpeg来合并视频片段,说技术方案要统一对齐~, 然后就改成了该方案并实施了一段时间,发现链路长了很多,后端交互上也出现了比较多的问题,最后还是回滚到本地合并的方案,怎么说呢, 反正都行吧 都能够实现,都有类似的问题,比如:

1. 视频片段衔接处有闪烁一下的痕迹
2. 上传超时,丢失视频等
3. 非法合片,合片失败等

不过总的来说,客户端本地合并的话,可以缩短或者节省一些带宽和服务器资源,兜底一些报错