慢动作视频处理
/文章/分享？id=9208285652934558845。s_bucket=na
& lt内联框架
高度=450
宽度=800 src=" /article/share？id=9208285652934558845。s_bucket=na "
框架边界=0
allowfullscreen & gt
& lt/iframe & gt；
文章主要解决了以下问题。
系统相册有bug。慢动作视频的时长显示的是拍摄时长，而不是视频的真实播放时长。
slo-mo模式下的视频会作为正常拍摄的原始视频存储在相册中。播放时读取本地拍摄存储的慢动作信息，控制播放速度，而不是生成慢动作视频。这个猜测是为了播放和显示效率考虑，因为视频导出很慢，ps:重要的东西高亮显示。
普通视频只有裁剪的功能，而slo-mo慢动作视频支持慢动作区域的选择，影响真实时长，但不会合成为新的慢动作视频，只是在回放时更新慢动作信息和控制回放速率。
有一个认知前提，iOS目前通过PHFetchResult获取视频和相册。
由requestAVAssetForVideo回调资产大部分是AVURLAsset。
所谓的AVURLAsset，可以直接根据URL对这个视频进行索引，但是当有这种类型的慢动作视频时，就不是这种类型了，而是AVComposition模式。
问题是，为什么大多数时候不报错？如果是类型不匹配，它将已经崩溃。
这是因为期权。version = phvideorequestoptionsversioncurrent；很多时候，这句话是作为选项来写的。version = phvideorequestoptions version original；直接拍原视频，原图，不是剪辑过的，因为相机在拍摄后肯定保存了一个原视频，按照这个原拍肯定会返回urlasset。
理解有几个层次，
RequestplayerItemForVideo api可以获取PlayerItem，里面的时长可以转换成真实时长，不耗费时间。
真正的慢动作视频是不存在的，必须通过自己的api导出。它的原理是读取当时保存的信息轨迹，逐步合成。
再次，导出时间相当长，导出一分钟的真实时间需要十几秒。在这种情况下，测试会产生bug，产品可能不会被接受。那么如何优化呢？
因为涉及到系统的api的使用，目前还无法明显的缩短导出时间。
但是，如果用户觉得时间没那么长，可以做很多事情。
有以下想法